JP6840962B2 - メール装置、その情報処理方法、プログラム、およびメールシステム - Google Patents

メール装置、その情報処理方法、プログラム、およびメールシステム Download PDF

Info

Publication number
JP6840962B2
JP6840962B2 JP2016175397A JP2016175397A JP6840962B2 JP 6840962 B2 JP6840962 B2 JP 6840962B2 JP 2016175397 A JP2016175397 A JP 2016175397A JP 2016175397 A JP2016175397 A JP 2016175397A JP 6840962 B2 JP6840962 B2 JP 6840962B2
Authority
JP
Japan
Prior art keywords
mail
email
approval
mailbox
approval request
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.)
Active
Application number
JP2016175397A
Other languages
English (en)
Other versions
JP2018042127A (ja
Inventor
明博 寒河江
明博 寒河江
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.)
NEC Corp
Original Assignee
NEC Corp
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 NEC Corp filed Critical NEC Corp
Priority to JP2016175397A priority Critical patent/JP6840962B2/ja
Publication of JP2018042127A publication Critical patent/JP2018042127A/ja
Application granted granted Critical
Publication of JP6840962B2 publication Critical patent/JP6840962B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Description

本発明は、メール装置、その情報処理方法、プログラム、およびメールシステムに関し、特に、第三者による配送メールの承認機能を有するメール装置、その情報処理方法、プログラム、およびメールシステムに関する。
学校、企業等の組織におけるインターネットメールにおいて、記載内容が適切であるか等を指導するためのチェックを可能にするメールシステムの一例が特許文献1に記載されている。特許文献1のシステムは、メール作成時に、組織外の相手が宛先の場合に、承認を要するメールであることを示すために、件名に承認者のユーザID等を追記してメールサーバに送信する。
そして、メールサーバでは、承認を要するメールを、承認者用の承認用保存領域に一時的に保存する。そして、承認者の端末がこの領域にアクセスすると、メールサーバはその端末に、承認を要するメールを一覧表示させる。そして、承認者は、表示された各メールの内容を確認し、配送の承認または却下を、端末に入力する。メールサーバは、端末に入力された承認者の指示に従い、承認の場合はメールの配送処理を行い、却下の場合は配送を中止する。
特許文献2および特許文献3には、アクション可能な電子メールドキュメントを作成する方法が記載されている。メール本文に、穴埋めすればデータ入力できるフィールドを含め、それを受信者に送る。受信者は、その穴埋め部分にデータを入力してそのメールを返信する。装置にて各フィールドの意味とそれに紐づくアクションが定義されたメタデータを保持しており、それに基づいて返信メールに入力されたデータを処理できる。
特許文献4に記載の装置は、承認対象となるメールの抽出の条件を自動調整するものである。事前に、「添付ファイルあり」、「A社宛」、「フリーメールアドレス宛」といった複数のルールを定めておき、ルールに優先度をつける。承認者によって1日の承認可能数が入力されると、優先度が高い順に優先的にルールを組み合わせていき、組み合わせ後のルールのそれぞれについて、各適合するメール数を特定する。そして、承認可能数に近いルールの組み合わせを承認ルールとして適用する。
特許文献5に記載のメール誤配信防止装置は、オリジナルメールの送信先メールアドレスから社外宛のメールを判別し、当該社外宛のメールを誤配信防止の対象として認識する。そして、承認キーワードを含む承認依頼メールを作成し、承認者宛に送信する。承認者は受信した承認依頼メールを見て、承認または禁止の指示および承認依頼メールに記載されていた承認キーワードを本文に記述した依頼回答メールを作成して返信する。依頼回答メールに承認キーワードと承認指示が含まれている場合に、オリジナルメールの配信が承認される。
特許文献6に記載の電子メール管理方法は、複数の承認権限者に承認依頼電子メールを送信した後、複数の承認権限者のうちのいずれか一名が承認依頼メールに対して承認処理を行ったことを検知する。そして、承認を行った承認権限者以外の承認権限者に送信された承認依頼電子メールを削除することで、複数の承認権限者により重複して承認処理が行われないようにしている。承認処理は、承認権限者が、承認依頼メールの記載内容を閲覧し、承認または否認の判断を行い、承認操作により行われる。
特開2002−063117号公報 特開2006−172444号公報 特開2012−038343号公報 特開2010−266984号公報 特開2013−102539号公報 特開2005−010923号公報
上述した文献記載の技術では、いずれにおいても、メールの配送可否の判断は、配送の確認を行う承認担当者がメールの内容を確認する必要があった。この承認作業は人手によるため、人為的なミスによるメールの誤配信を招く恐れがあった。
本発明の目的は、メールの配送可否判断の人為的なミスによりメールが誤配信されるという問題点を解決するメール装置、その情報処理方法、プログラム、およびメールシステムを提供することにある。
本発明の各側面では、上述した課題を解決するために、それぞれ以下の構成を採用する。
第一の側面は、メール装置に関する。
第一の側面に係るメール装置は、
承認対象のメールを特定する情報を取得する取得手段と、
前記メールの特定情報を含む当該メールの承認依頼メールを作成し、前記メールの承認者の受信メールボックスに格納するメール作成手段と、
予め設定された振分けルールに従って、前記受信メールボックスに格納された前記承認依頼メールを所定のメールボックスに振分ける振分け手段と、を有する。
そして、前記所定の振分けルールには、前記承認依頼メールが、承認条件に合う場合に、当該承認依頼メールを承認済みメールボックスに格納することが含まれている。
第二の側面は、少なくとも1つのコンピュータにより実行される情報処理方法に関する。
第二の側面に係る情報処理方法は、
メール装置が、
承認対象のメールを特定する情報を取得し、
前記メールの特定情報を含む当該メールの承認依頼メールを作成し、前記メールの承認者の受信メールボックスに格納し、
予め設定された振分けルールに従って、前記受信メールボックスに格納された前記承認依頼メールを所定のメールボックスに振分ける、ことを含む。
そして、前記所定の振分けルールには、前記承認依頼メールが、承認条件に合う場合に、当該承認依頼メールを承認済みメールボックスに格納することが含まれている。
なお、本発明の他の側面としては、上記第二の側面の方法を少なくとも1つのコンピュータに実行させるプログラムであってもよいし、このようなプログラムを記録したコンピュータが読み取り可能な記録媒体であってもよい。この記録媒体は、非一時的な有形の媒体を含む。
このコンピュータプログラムは、コンピュータにより実行されたとき、コンピュータに、メール装置上で、その情報処理方法を実施させるコンピュータプログラムコードを含む。
なお、以上の構成要素の任意の組合せ、本発明の表現を方法、装置、システム、記録媒体、コンピュータプログラムなどの間で変換したものもまた、本発明の態様として有効である。
また、本発明の各種の構成要素は、必ずしも個々に独立した存在である必要はなく、複数の構成要素が一個の部材として形成されていること、一つの構成要素が複数の部材で形成されていること、ある構成要素が他の構成要素の一部であること、ある構成要素の一部と他の構成要素の一部とが重複していること、等でもよい。
また、本発明の方法およびコンピュータプログラムには複数の手順を順番に記載してあるが、その記載の順番は複数の手順を実行する順番を限定するものではない。このため、本発明の方法およびコンピュータプログラムを実施するときには、その複数の手順の順番は内容的に支障のない範囲で変更することができる。
さらに、本発明の方法およびコンピュータプログラムの複数の手順は個々に相違するタイミングで実行されることに限定されない。このため、ある手順の実行中に他の手順が発生すること、ある手順の実行タイミングと他の手順の実行タイミングとの一部ないし全部が重複していること、等でもよい。
上記各側面によれば、メールの配送可否判断の精度を向上させて、メールの誤配信を防止するメール装置、その情報処理方法、プログラム、およびメールシステムを提供することができる。
本発明の実施の形態に係るメール装置を含むメールシステムのシステム構成を概念的に示す図である。 本実施形態のメール装置を含むメールサーバの構成を論理的に示す機能ブロック図である。 承認対象対応テーブルのデータ構造の一例を示す図である。 承認対象メールの一例を示す図である。 承認依頼メールの一例を示す図である。 振分けルールの一例を示す図である。 メールボックス定義情報のデータ構造の一例を示す図である。 メール装置を含むメールサーバを実現するコンピュータの構成の一例を示すブロック図である。 本実施形態のメール装置の承認依頼メールの作成に関する動作の一例を示すフローチャートである。 本実施形態のメール装置の振分け部の動作の一例を示すフローチャートである。 本実施形態のメール装置の実行部の動作の一例を示すフローチャートである。 本実施形態のメール装置の論理的な構成を示す機能ブロック図である。 送受信履歴情報のデータ構造の一例を示す図である。 送受信回数情報のデータ構造の一例を示す図である。 同報履歴情報のデータ構造の一例を示す図である。 評価値の設定ポリシの一例を示す図である。 評価値情報のデータ構造の一例を示す図である。 承認依頼メールの他の例を示す図である。 振分けルールの他の例を示す図である。 メール装置における承認依頼メールの作成手順を示すフローチャートである。 本実施形態におけるメールサーバの要部構成を示す図である。 振分けルールの他の例を示す図である。 MUAにおけるメールのプレビュー画面の一例を示す図である。 図9の承認条件に従ったメールの振り分け処理に続き、否認条件に従ったメールの振り分け処理の手順を示すフローチャートである。 本実施形態のメール装置の実行部の動作の一例を示すフローチャートである。 本実施形態のメール装置の構成を論理的に示す機能ブロック図である。 本実施形態のメール装置の動作の一例を示すフローチャートである。 承認依頼メールのヘッダの一例を示す図である。
以下、本発明の実施の形態について、図面を用いて説明する。尚、すべての図面において、同様な構成要素には同様の符号を付し、適宜説明を省略する。
(第1の実施の形態)
図1は、本発明の実施の形態に係るメール装置100を含むメールシステム1のシステム構成を概念的に示す図である。図2は、本実施形態のメール装置100を含むメールサーバ40の構成を論理的に示す機能ブロック図である。
図1に示すように、メールシステム1は、ネットワーク3上の複数のユーザ端末10と、メールサーバ40とを含む。ネットワーク3は、たとえば、イントラネット等、企業、公共機関、施設等の組織内ネットワークである。
メールサーバ40は、受信部42と、配送部48と、を有する。
受信部42は、POP(Post Office Protocol)やIMAP(Internet Message Access Protocol)等のプロトコルを用いて、ネットワーク3内のユーザ宛に配送されてきた電子メールを受信して、メールボックス領域部44のユーザ別のメールボックス領域46に保管する。配送部48は、SMTP(Simple Mail Transfer Protocol)を用いてネットワーク3または外部ネットワーク5のユーザ宛に電子メールを配送する。
たとえば、ユーザはユーザ端末10を用いてメールサーバ40の自分のメールボックス領域46にアクセスして、電子メールを受信することができる。
メール装置100は、メールシステム1のメールサーバ40の一機能として組み込むことができる。メール装置100は、ユーザ端末10から送信されたメールのうち、対象となるメールについて、メールの承認者による承認作業を補助する機能を有する。
この承認作業を補助する機能は、たとえば、所定の承認条件に従いメールの配送可否判断を自動的に行い、配送可能と判断されたメールを自動的に配送する機能を含む。さらに、自動承認による配送可否判断がつかなかったメールについて、承認者がメールの内容を確認して配送可能と判断したメールを承認者の手動操作によって配送処理する機能を含む。後者の機能については、後述する実施形態で説明する。
承認対象となるメールは、たとえば、メールの宛先(同報宛先を含む。To:, Cc:, Bcc:)が社内以外、または宛先が所定の送信先(メールアドレス(ユーザ)またはドメイン(部署)等)のもの、添付ファイルがあるもの、差出人(From:)が所定の送信元(メールアドレス(ユーザ)またはドメイン(部署)等)のもの等、あるいは、これらの組み合わせでもよい。あるいは、全ての配送メールを承認対象としてもよい。または、所定の期間内に受信または配送されるメールを承認対象としてもよい。
受信部42は、受信したメールの中から、上記の承認対象となる承認対象メールM1を抽出する。抽出された承認対象メールM1がメール装置100に受け渡され、メール装置100による承認処理が済むまで配送が保留される。なお、承認対象以外のメールM0は、配送部48にそのまま受け渡され、宛先に配送される。
そして、メール装置100によって承認済みとなったメールのみが配送部48により宛先に配送される。
メールの承認者は、メールの差出人(たとえば、ユーザU2)とは別の者で、承認権限を有する者(たとえば、ユーザU1、以下、承認者U1とも呼ぶ)である。
承認者U1が、どの差出人のメールの承認権限を有するかは予め定められているものとする。たとえば、図3に示すような承認対象対応テーブル110で予め定めることができる。図3の例では、承認対象となるユーザU2、ユーザU3等のユーザ特定情報(たとえば、メールアドレス、ユーザアカウント等)は、承認者であるユーザU1のユーザ特定情報(たとえば、メールアドレス、ユーザアカウント等)に対応付けられている。
図3は一例であり、これに限定されない。他の例では、たとえば、部署毎にドメイン名が異なり、かつ、部署の上長が承認者U1であるような場合には、承認者U1のメールアドレスに、承認対象となる部署のドメイン名(たとえば、x2.abc.comとx3.abc.com等)が対応付けられてもよい。
前記したように、承認者U1に対して送信元(メールアドレス(ユーザ)またはドメイン(部署)等)を対応付けてもよいが、承認者U1に対してメールの送信先(メールアドレス(ユーザを特定する情報)またはドメイン(部署や組織を特定する情報)等)を対応付けてもよく、これらの組み合わせでもよい。1通のメールに対する承認者U1は必ずしも1人とは限らず、複数人でもよく、たとえば、課長、部長等、メールを複数の承認者間で巡回させてもよい。この複数の承認者による承認作業については後述する他の実施形態で説明する。
各ユーザ端末10には、メーラー(MUA:Message User Agent)12がインストールされている。各ユーザはMUA12を用いてメールサーバ40にアクセスしてメールを送受信する。
次に、メール装置100について図2を用いて詳細に説明する。図2では、承認者U1のメーラーをMUA20と示し、メールの差出人のメーラーをMUA30と示して区別してある。
メールサーバ40は、メールサーバとして既存にある機能を有している。たとえばメールサーバ40は、受信部42と、メールボックス領域部44と、配送部48と、承認待ちメール記憶部50とを少なくとも有している。
そして、メールサーバ40は、さらに、メール装置100と、承認者U1の受信ボックス112および承認済みボックス114を有している。これらの機能は、新たにメールサーバ40に組み込まれる機能である。
受信ボックス112と承認済みボックス114は、メールサーバ40のメールボックス領域部44のメールボックス領域46に含まれる。メールボックス領域46は、承認者別に設けられている。受信ボックス112には、承認者U1宛の受信メールが格納される。
受信部42が受信したメールのうち、承認対象となる承認対象メールM1は、一時的に配送が保留される。そして、メール装置100により、図4に例示される承認対象メールM1から図5に例示される承認依頼メールM2が生成される。承認依頼メールM2には、承認対象メールM1の配送可否判定に必要な情報が記述される。生成された承認依頼メールM2が、承認者U1の受信ボックス112に格納される。
そして、承認依頼メールM2を用いて配送可否判定が行われる。配送可能と判定された承認依頼メールM2が受信ボックス112から承認済みボックス114に移動される。
受信ボックス112から承認済みボックス114への承認依頼メールM2の移動処理は、承認者U1のMUA20のメール振分け機能を用いて実行される。振分け処理に用いられる振分けルール22には、承認者別メールボックス領域46の受信ボックス112に格納されたメールを承認済みボックス114に振分けるための承認条件が予め設定されている。
本実施形態では、振分けルール22は、各承認者によりMUA20を用いてメールの承認条件が設定される。この振分けルール22は、メールサーバ40のメールボックス領域部44のユーザ別のメールボックス領域46に記憶されてもよいし、承認者のユーザ端末10のメモリ84またはストレージ85等の記憶装置に記憶されてもよい。
本実施形態では、振分け処理は、メールサーバ40が行う構成としているが、承認者のユーザ端末10で行う構成も排除されない。振分けルール22は、振分け処理を行う装置に記憶されるのが好ましいが、振分け処理を行わない装置に記憶されていてもよい。
たとえば、メールサーバ40が振分け処理を行う構成であっても、承認者のユーザ端末10の記憶装置に振分けルール22が記憶されてもよく、その場合は、振分時に振分け部106が、承認者のユーザ端末10の記憶装置にアクセスして振分けルール22を取得する。
本実施形態の振分け処理では、メールサーバ40上のメールボックスが操作対象となるため、IMAPが使用される。承認済みボックス114には、振分けルール22に従い振り分けられたメール、すなわち、承認条件に従い配送可能と判定(承認)されたメールが格納される。
メール装置100は、取得部102と、メール作成部104と、振分け部106と、実行部108とを備える。
取得部102は、受信部42が受信した承認対象メールM1を特定する情報(メッセージID等)を取得する。受信部42は、MUA30から受信した承認対象メールM1を承認待ちメール記憶部50に一時的に保存する。取得部102が取得する情報は、承認対象メールM1を特定する情報として、たとえば、承認対象メールM1の各種ヘッダに含まれるメッセージID(Message ID:)、差出人(From:)、宛先(To:)、同報宛先(cc:, bcc:)、件名(Subject:)、および添付ファイルの情報(添付の有無、ファイル名、ファイルサイズ、ファイル種別、作成日時、作成者等)等が含まれる。
本明細書において、「取得」とは、自装置が他の装置や記憶媒体に格納されているデータまたは情報を取りに行くこと(能動的な取得)、たとえば、他の装置にリクエストまたは問い合わせして受信すること、他の装置や記憶媒体にアクセスして読み出すこと等、および、自装置に他の装置から出力されるデータまたは情報を入力すること(受動的な取得)、たとえば、配信(または、送信、プッシュ通知等)されるデータまたは情報を受信すること等、の少なくともいずれか一方を含む。また、受信したデータまたは情報の中から選択して取得すること、または、配信されたデータまたは情報を選択して受信することも含む。
そして、メール作成部104は、図3の承認対象対応テーブル110で説明したルールに従って、承認対象メールM1に対応する承認者U1を特定する。
メール作成部104は、抽出された承認対象メールM1から承認依頼メールM2を作成し、特定された承認者U1のメールボックス領域46の受信ボックス112に格納する。承認依頼メールM2には、承認対象メールM1のメール特定情報が含まれる。メール特定情報とは、メール承認作業後に、承認依頼メールM2に対応する承認対象メールM1を特定し、承認待ちメール記憶部50から読み出す際に使用される情報であり、たとえば、メールヘッダのMessage ID:等である。
本実施形態では、メール特定情報としてメッセージIDを用いているが、他の例では、これに限定されない。承認対象メールM1と承認依頼メールM2を対応付け、承認依頼メールM2から承認対象メールM1を特定できる識別情報であればよい。
図5の例では、承認依頼メールM2のヘッダ部120の件名122(Subject:)には、メールの承認依頼であることを示す情報が記載される。宛先124(To:)には、図3の承認対象対応テーブル110から取得された承認者U1のメールアドレスが記載される。差出人126(From:)には、たとえば、メール装置100の管理者のメールアドレスが記載される。リファレンス128(References:)には、承認対象メールM1のMessage-IDヘッダ150(図4)に記載されているメッセージIDが記載される。
本文130には、承認依頼メールM2の説明を示すメッセージ132と、メール情報欄134と、添付ファイル情報欄136とが記載される。
図5の例では、メールが振分けルール22の承認条件により自動承認されなかった場合に、承認者U1がメールの内容を確認して、手動で承認することを想定している。
メッセージ132には、当該メールが承認できる場合には承認依頼メールM2を承認済みボックス114に移動することを指示する内容が記載されている。承認者U1は、MUA20を用いて、承認依頼メールM2の内容を見て、メッセージ132の指示に従い、承認依頼メールM2を承認済みボックス114に移動してもよい。
メール情報欄134には、元の承認対象メールM1の情報が記載される。宛先表示欄134aには、図4の承認対象メールM1の宛先142(To:)、同報宛先146(cc:)、非表示の同報宛先(bcc:)(不図示)のメールアドレスを全て含む情報が記載されるのが好ましい。メール情報欄134の差出人表示欄134b(From:)には、図4の承認対象メールM1の差出人144(From:)のメールアドレスが記載される。
本実施形態では、承認対象メールM1の情報を承認依頼メールM2の本文に記載しているが、他の例では、ヘッダに情報を記載してもよい。メーラーの振り分け機能に応じて、どちらにするか適宜選択すればよいし、または、本文とヘッダの両方に記載してもよい。メールヘッダに記載する例については、他の実施形態で説明する。
添付ファイル情報欄136には、承認対象メールM1に添付ファイルが付いている場合に、その旨を示す情報と、添付ファイルの情報、たとえば、ファイル名、ファイルサイズ、ファイル種別、作成日時、作成者等が記載される。図の例では、ファイル名とファイルサイズが記載されている。
添付ファイル情報欄136に記載される情報は添付ファイルに基づく承認判定に使用される。たとえば、承認条件として、ファイル名に所定文字列を含まない、ファイルサイズが所定値未満、種別がPDF(Portable Document Format)、作成者が所定のユーザ、または作成日時が所定期間内であること等が設定される。
さらに、本文130に元の承認対象メールM1の宛先に関する宛先情報138を含んでもよい。宛先情報138は、承認対象メールM1の宛先に、社外ドメインが含まれている場合に、その旨を示すメッセージを含む。メールが承認条件に合わなかったとき、承認者U1が承認依頼メールM2のこの本文の記載内容を見て承認するか否かの判断を行うことができる。この宛先情報138により、承認対象メールM1に社内以外のドメインが宛先に含まれていることを承認者U1が直ぐに理解できる。
また、承認依頼メールM2には、元の承認対象メールM1の本文と添付ファイルの少なくとも一方が添付されてもよい。承認対象メールM1の本文と添付ファイルを、承認者U1が承認を行う際の判断材料とすることができる。
振分け部106は、予め設定された振分けルール22に従って、受信ボックス112に格納された承認依頼メールM2を所定のメールボックス(ここでは承認済みボックス114)に振分ける。
振分けルール22は、図6に示すように、条件と動作とを含む。図6は振分けルール22の一例を示している。上記したように、振分けルール22は、承認者U1のMUA20上で、承認者U1が承認条件と承認者ユーザU1のメールボックスに従い作成することができる。
図6の例では、承認条件として、承認依頼メールM2であること(差出人が管理者の所定のメールアドレスであること)、かつ(and)、添付ファイルがないこと、かつ(and)、宛先に社外ドメインが含まれていないことが定義されている。さらに、承認条件に合った場合の動作として、条件に合ったメールを承認済みボックス114に移動することが定義されている。また、承認依頼メールM2であることの条件は、差出人のメールアドレス以外に、たとえば、ヘッダ部120の件名122を参照して、「メール承認依頼」の文字列が含まれていることを設定してもよい。これらの条件により、他のメールと承認依頼メールM2を区別することができる。
実行部108は、所定のメールボックス毎に設定されたアクションを、メールボックスに格納されたメールに対して実行する。本実施形態では、実行部108は、承認済みボックス114に設定されたアクションを、承認済みボックス114に格納された承認依頼メールM2に対して実行する。
図7は、メールボックス定義情報24のデータ構造の一例を示す図である。
メールボックス定義情報24は、メール装置100のメモリ84およびストレージ85のいずれかに記憶される。メールボックス定義情報24は、メールボックス毎に設定される少なくとも一つのアクションの内容を示す情報を含む。この例では、実行される順に複数のアクションが記述されている。図は説明のため、文章で示しているが、実際にはコードで記述される。他の例では、アクションを実現するプログラムの特定情報(ファイル名、パス等の情報)がメールボックスに対応付けられていてもよい。
ここでは、承認済みボックス114に設定されるアクションは、配送部48に対して、承認依頼メールM2に対応する承認対象メールM1を一時的に記憶している承認待ちメール記憶部50から読み出させ、当該承認対象メールM1の宛先へ配送させることである。
本実施形態のメール装置100は、承認者U1のメールボックス領域46に上記の所定のアクションが設定されるメールボックス(承認済みボックス114等)が予め設けられている。他の例では、MUA20または所定のアプリケーションなどのフォルダ設定機能を用いて、承認者U1により設定されてもよい。
このように構成されたメール装置100を含むメールサーバ40を実現するコンピュータ80の構成の一例を図7に示す。また、メールシステム1のユーザ端末10も、同様なコンピュータ80によって実現される。
コンピュータ80は、CPU(Central Processing Unit)82、メモリ84、メモリ84にロードされた図1のメール装置100の構成要素を実現するプログラム90、そのプログラム90を格納するストレージ85、I/O(Input/Output)86、およびネットワーク接続用インタフェース(通信I/F87)を備える。
CPU82、メモリ84、ストレージ85、I/O86、通信I/F87は、バス89を介して互いに接続され、CPU82によりメール装置100全体が制御される。ただし、CPU82などを互いに接続する方法は、バス接続に限定されない。
メモリ84は、RAM(Random Access Memory)やROM(Read Only Memory)などのメモリである。ストレージ85は、ハードディスク、SSD(Solid State Drive)、またはメモリカードなどの記憶装置である。
ストレージ85は、RAMやROMなどのメモリであってもよい。ストレージ85は、コンピュータ80の内部に設けられてもよいし、コンピュータ80がアクセス可能であれば、コンピュータ80の外部に設けられ、コンピュータ80と有線または無線で接続されてもよい。あるいは、コンピュータ80に着脱可能に設けられてもよい。
CPU82が、ストレージ85に記憶されるプログラム90をメモリ84に読み出して実行することにより、メール装置100を含むメールサーバ40の各ユニットの各機能を実現することができる。
I/O86は、コンピュータ80と他の入出力装置間のデータおよび制御信号の入出力制御を行う。他の入出力装置とは、たとえば、コンピュータ80に接続されるキーボード、タッチパネル、マウス、およびマイクロフォン等の入力装置(不図示)と、ディスプレイ、プリンタ、およびスピーカ等の出力装置(不図示)と、これらの入出力装置とコンピュータ80のインタフェースとを含む。さらに、I/O86は、他の記録媒体の読み取りまたは書き込み装置(不図示)とのデータの入出力制御を行ってもよい。
通信I/F87は、コンピュータ80と外部の装置との通信を行うためのネットワーク接続用インタフェースである。通信I/F87は、有線回線と接続するためのネットワークインタフェースでもよいし、無線回線と接続するためのネットワークインタフェースでもよい。たとえば、メール装置100を実現するコンピュータ80は、通信I/F87によりネットワーク3および外部ネットワーク5に接続される。
図1のメール装置100を含むメールサーバ40の各構成要素は、図8のコンピュータ80のハードウェアとソフトウェアの任意の組合せによって実現される。そして、その実現方法、装置にはいろいろな変形例があることは、当業者には理解されるところである。以下説明する各実施形態のメール装置を示す機能ブロック図は、ハードウェア単位の構成ではなく、論理的な機能単位のブロックを示している。
メール装置100を含むメールサーバ40は、複数のコンピュータ80により構成されてもよいし、仮想的なコンピュータ80により実現されてもよい。
本実施形態のコンピュータプログラム90は、メール装置100を実現させるためのコンピュータ80に、承認対象メールM1を特定する情報(メッセージID等)を取得する手順、メールの特定情報を含む当該承認対象メールM1の承認依頼メールM2を作成し、メールの承認者U1の受信ボックス112に格納する手順、予め設定された振分けルール22に従って、受信ボックス112に格納された承認依頼メールM2を所定のメールボックス(承認済みボックス114等)に振分ける手順、を実行させるように記述されている。
本実施形態のコンピュータプログラム90は、コンピュータ80で読み取り可能な記録媒体に記録されてもよい。記録媒体は特に限定されず、様々な形態のものが考えられる。また、プログラム90は、記録媒体からコンピュータ80のメモリ84にロードされてもよいし、ネットワークを通じてコンピュータ80にダウンロードされ、メモリ84にロードされてもよい。
コンピュータプログラム90を記録する記録媒体は、非一時的な有形のコンピュータ80が使用可能な媒体を含み、その媒体に、コンピュータ80が読み取り可能なプログラムコードが埋め込まれる。コンピュータプログラム90が、コンピュータ80上で実行されたとき、コンピュータ80に、メールサーバ40内でメール装置100を実現する以下の情報処理方法を実行させる。
このように構成された本実施形態のメール装置100を含むメールサーバ40の動作について、以下説明する。
図9は、本実施形態のメール装置100の承認依頼メールM2の作成に関する動作の一例を示すフローチャートである。図9に示す手順により、承認対象メールM1(図4)から承認依頼メールM2(図5)が生成される。
まず、メールサーバ40の受信部42が、MUA30から配送メールを受信する(ステップS101)。受信部42は、外部からSMTPでメールを受付ける処理を行う。たとえば、一般的なTCP(Transmission Control Protocol)の25番や587番ポートでメールを受け付けることができる。
受信部42は、差出人や宛先等の所定の条件により、承認対象メールM1か否かの判別を行い、承認が必要なメールを取得部102に受け渡す。この判別は、上記した承認対象対応テーブル110を用いて行うことができる。また、承認対象対応テーブル110を用いることで、その承認対象メールM1に対応する承認者を特定することができる。
承認が必要なメールは承認処理を待つ間、承認待ちメール記憶部50の承認待ちキューに保持され、配送を保留される(ステップS103)。承認が不要なメールは、配送部48に受け渡され、その後、配送部48によって配送される(不図示)。後述する振分け処理により承認されたとき、保留されていたメールは配送部48に受け渡されることとなる。
取得部102が、承認対象メールM1を特定する情報(メッセージID等)を取得し、メール作成部104が承認依頼メールM2を作成する(ステップS105)。メール作成部104は、作成した承認依頼メールM2を、承認者U1のメールボックス領域46の受信ボックス112に格納する(ステップS107)。
このようにして作成された承認依頼メールM2は、承認者U1によって予め設定された振分けルール22によって振分け部106が振り分けを行う。
図10は、本実施形態のメール装置100の振分け部106の動作の一例を示すフローチャートである。
振分け部106が図6の振分けルール22に従ってメールを振り分けることで、承認対象メールM1の承認が行われる。本図のフロー開始のタイミングは、たとえば、定期的に行うことができる。あるいは、承認者U1またはメールサーバ40の管理者によって設定されたタイミングでもよい。あるいは、メール作成部104が受信ボックス112に承認依頼メールM2を格納したとき、振分け部106に通知し、通知を受けたタイミングで開始されてもよい。または、受信ボックス112に所定数以上のメールが格納されたときや、メールが格納されてから所定時間以上経過したとき等に開始されてもよい。これらの組み合わせでもよい。開始のタイミングは、予め定められていてもよいし、承認者U1または管理者により随時設定変更できてもよい。
まず、振分け部106が、承認者U1のメールボックス領域46の受信ボックス112に届いた承認依頼メールM2を取得する(ステップS111)。
振分け部106は、受信ボックス112に格納された承認依頼メールM2が、承認者U1のMUA20により設定された振分けルール22の承認条件に合致するか否か判定する(ステップS113)。ここでは、上記したように、承認条件に承認依頼メールM2であることの条件が含まれており、承認依頼メールM2と承認者U1宛の他のメールとを区別することができる。
承認条件に合致した場合(ステップS113のYES)、振分け部106は、受信ボックス112から承認済みボックス114に承認依頼メールM2を移動する(ステップS115)。承認条件に合致しない場合(ステップS113のNO)、他の承認依頼メールM2が受信ボックス112にあればステップS111に戻り本フローの処理を繰り返す。他の承認依頼メールM2が受信ボックス112になければ、ひとまず本フローを終了する。
図10の処理により、承認依頼メールM2の承認判定に基づく振分け処理が終了する。
次に、承認済みの承認依頼メールM2の配送処理について説明する。
図11は、本実施形態のメール装置100の実行部108の動作の一例を示すフローチャートである。
上述したように、承認済みボックス114には、予めアクションが定義されている。実行部108は、承認済みボックス114に設定されたアクションを実行する。本図のフロー開始のタイミングは、たとえば、定期的に行うことができる。あるいは、承認者U1またはメールサーバ40の管理者によって設定されたタイミングでもよい。あるいは、振分け部106が承認済みボックス114に承認依頼メールM2を格納したとき、実行部108に通知し、通知を受けたタイミングで開始されてもよい。または、承認済みボックス114に所定数以上のメールが格納されたときや、メールが格納されてから所定時間以上経過したとき等に開始されてもよい。これらの組み合わせでもよい。開始のタイミングは、予め定められていてもよいし、承認者U1または管理者により随時設定変更できてもよい。
まず、実行部108が、承認者U1のメールボックス領域46の承認済みボックス114を参照し、メールが格納されているか否か確認する(ステップS121)。そして、実行部108が、承認済みボックス114に入っている承認依頼メールM2を取り出す(ステップS123)。実行部108が、取り出した承認依頼メールM2に対応する承認対象メールM1を承認待ちメール記憶部50の承認待ちキューから検索する(ステップS125)。
具体的には、実行部108が、承認依頼メールM2のリファレンス128(References:)に記載されている承認対象メールM1のメッセージIDと同じメッセージID150を有する承認対象メールM1を、承認待ちメール記憶部50の承認待ちキューから検索する。
対応する承認対象メールM1が見つかった場合(ステップS127のYES)、配送部48に承認対象メールM1を受け渡し、配送部48に承認対象メールM1の宛先(To:、cc:、bcc:)に配送させる(ステップS129)。
対応する承認対象メールM1が見つからなかった場合(ステップS127のNO)、本処理を終了する。このとき、実行部108は、所定のエラー処理を行ってもよい。たとえば、承認依頼メールM2に対応する承認対象メールM1が見つからなかった旨を当該メールの差出人に通知する通知部(不図示)をさらに備えてもよい。
通知部は、たとえば、承認依頼メールM2のメール情報欄134の差出人表示欄134b(From:)から、承認対象メールM1の差出人144(From:)のメールアドレスを取得する。取得したメールアドレスに、配送中止を示すメッセージを本文に記載したメールを送信する。配送中止を示すメッセージには、承認依頼メールM2に対応する承認対象メールM1が見つからなかったために配送が行われなかった旨が記載される。また、通知メールには、承認依頼メールM2を添付してもよい。
ステップS129の後、実行部108は、承認待ちメール記憶部50の承認待ちキューから配送済みの承認対象メールM1を削除する(ステップS131)。さらに、実行部108は、承認者U1のメールボックス領域46の承認済みボックス114のアクション実行済みの承認依頼メールM2を削除する(ステップS133)。
以上説明したように、本実施形態のメール装置100によれば、メール作成部104により承認対象メールM1のメッセージIDを含む承認依頼メールM2が作成され、承認者U1の受信メールボックスに格納される。そして、承認者U1のメーラーで設定された振分けルールに含まれる承認条件に、受信メールボックス内のメールが合致する場合に、振分け部106により承認者U1の承認済みボックス114にメールを振り分けることができる。
このように、本実施形態によれば、予め設定された承認条件を記載した振分けルールに従い、承認済みメールを承認済みボックス114に自動的に振分けることができるので、配送可否判断のために承認者U1がメールの内容を確認する必要がない。メールの配送可否判断を自動化できるので、人為的なミスを回避でき、メールの誤配信を防止できる。
また、メール内容の確認作業が人手による場合、手間がかかるが、本実施形態では、自動的に配送可否判断を行うので、確認作業の手間が省け、作業効率を向上でき、承認者U1の承認作業の負担を低減できる。
本実施形態のメール装置100では、承認済みボックス114に設定されたアクションに従い、承認済みボックス114に格納された承認依頼メールM2に対応する承認対象メールM1を承認待ちメール記憶部50の承認待ちキューから読み出して承認対象メールM1の宛先に配送することができる。
この構成により、承認者U1が不在の場合であっても、承認対象メールM1の承認作業と承認済みメールの配送処理を自動的に行うことができるので、承認可能なメールの配送を滞りなく行うことができ、メール配送の遅延を防止できる。
さらに、本実施形態のメール装置100によれば、承認者U1のMUA20を用いて、承認条件を振分けルール22に設定する簡単な操作だけで、承認処理を実現することができる。承認者U1のユーザ端末10に特別な構成を追加する必要がなく、一般的なMUA20の振分け機能を利用するだけでよい。
(第2の実施の形態)
次に、本発明の第2の実施の形態について、以下説明する。
本実施形態のメール装置200は、メールの送信元または宛先の過去のメールの履歴情報に基づく評価値を承認条件に用いる点を除いて、上記実施形態のメール装置100と同様である。本実施形態のメール装置200は、メール装置100と組み合わせた例を示しているが、後述する他の実施形態と組み合わせることもできる。
図12は、本実施形態のメール装置200の論理的な構成を示す機能ブロック図である。
本実施形態のメール装置200は、上記実施形態のメール装置100と同様な取得部102と、メール作成部104と、振分け部106と、実行部108と、を備えるとともに、さらに、評価部202を備える。
また、メール装置200は、送受信履歴記憶部210に接続される。図12の例では、送受信履歴記憶部210は、メール装置200の外部に設けられている。ただし、送受信履歴記憶部210は、メール装置200(またはメールサーバ40)を実現するコンピュータのメモリやストレージにより実現されてもよい。また、送受信履歴記憶部210は、複数の記憶装置から構成されてもよい。
送受信履歴記憶部210には、メールサーバ40を経由して送受信されたメールの送受信履歴情報212(図13)が記憶される。送受信履歴情報212に記録されるメールは、承認対象メールM1以外のメールも含んでよい。
図13に示す送受信履歴情報212のデータ構造は一例である。送受信履歴情報212は、メールのメッセージIDと、メールサーバ40がメールを受け付けた日時と、メールの宛先(To:)の情報(たとえば、メールアドレス)と、メールの差出人(From:)の情報(たとえば、メールアドレス)とを含む。
取得部102は、さらに、メールの送信元のメールの送受信履歴に基づく情報を取得し、メール作成部104は、そのメールの送受信履歴情報を承認依頼メールM2に含める。
メールの送信元とは、メールの差出人(From:)に記載されているメールアドレス、または、ユーザアカウントである。メールの送信元のメールの送受信履歴に基づく情報とは、たとえば、図14に示す送受信回数情報214である。送受信回数情報214は、送受信履歴記憶部210に記憶される。
送受信回数情報214は、メールの差出人(From:)と宛先(To:)の組み合わせ毎にメールの送受信回数をカウントして得られた結果である。この例では、メールアドレスのアカウントとドメイン名を分けて2つのデータ項目として記録しているが、メールアドレスを1つのデータ項目として記録してもよい。
図14の例では、送受信回数情報214は、社内ユーザの差出人のメールアドレスと、社外ドメインの宛先のメールアドレスの組み合わせ毎の送受信回数である。
送受信回数情報214は、メール作成部104または評価部202が送受信履歴情報212を参照して、送受信回数をカウントして記録してもよいし、他の装置によりカウントまたは記録されたものであってもよい。
振分けルール22には、承認依頼メールM2に含まれる送受信履歴情報が承認条件に合う場合に、当該承認依頼メールM2を承認済みボックス114に格納することが含まれている。
たとえば、差出人と宛先ユーザについて、送受信回数情報214の送受信回数が所定値以上であることを承認条件に含んでもよい。
さらに、メール作成部104は、そのメールの送受信履歴情報として、たとえば、図15に示す同報履歴情報216を承認依頼メールM2に含めてもよい。
同報履歴情報216には、メールの差出人(From:)と同報宛先(cc:、bcc:)の組み合わせ毎にメールの同報回数をカウントして得られた結果が記録されている。この例では、メールアドレスのアカウントとドメイン名を分けて2つのデータ項目として記録しているが、メールアドレスを1つのデータ項目として記録してもよい。また、社内ドメインが1種類の場合、各ユーザのアカウントだけをデータ項目として記録してもよい。
同報履歴情報216は、メール作成部104または評価部202が送受信履歴情報212を参照して、同報回数をカウントして記録してもよいし、他の装置によりカウントまたは記録されたものであってもよい。
振分けルール22には、承認依頼メールM2に含まれる同報履歴情報216が承認条件に合う場合に、当該承認依頼メールM2を承認済みボックス114に格納することが含まれている。
図15の例では、ユーザ1とユーザ2が同じ組織に属しているケースを示しているが、他の例では、ユーザ1とユーザ2は異なる組織に属していてもよい。そして、たとえば、差出人と宛先ユーザについて、同報履歴情報216の同報回数が所定値以上であることを承認条件に含んでもよい。
取得部102は、メールの送受信履歴に基づく情報から、メールの送信元と宛先間における送受信回数と、メールの送信元となるユーザ毎に、同報宛先の他のユーザ毎の同報回数と、を取得する。
評価部202は、メールの宛先毎に、評価値を設定する。この評価値は、送受信回数と同報回数が少ない程、大きくなり、送受信回数と同報回数が多い程、小さくなるように設定される。
図16は、評価値の設定ポリシの一例を示す図である。
評価値は承認対象メールM1の宛先の安全性を1〜5の整数で5段階で示す。評価値が小さい程、安全性が高く、評価値が大きい程、安全性が低いことを示している。
たとえば、送信元との送受信実績がない宛先は、評価値は5となる。送信元との送受信実績が第1所定値(たとえば、200回)以上、かつ、同報送信回数が第2所定値(たとえば、300回)以上のメンバとの送受信実績が第3所定値(たとえば、200回)以上の宛先は、信頼できる宛先として評価値は1となる。
第1所定値、第2所定値、第3所定値は、メール装置100の管理者または部署毎に設定できてよい。評価値および各設定値は、メール装置100のメモリ84およびストレージ85のいずれかに記憶される。
また、送信元との送受信実績が第1所定値未満と少ない宛先であっても、送信元との同報送信回数が第2所定値以上のメンバとの送受信実績が第3所定値以上と多い場合には、信頼できる可能性があるので、評価値は3となる。
評価部202により承認対象メールM1の宛先毎に設定された評価値は、たとえば、図17の評価値情報218にメール毎に一時的に記録される。
メール作成部104は、承認対象メールM1の宛先毎の評価値に基づく送受信履歴情報を承認依頼メールM2に含める。
具体的には、承認対象メールM1の宛先毎の評価値の中(評価値情報218)から最大値(図17の例では、最大値は5となる)を送受信履歴情報として承認依頼メールM2(図18)に含める。
また、承認対象メールM1の宛先毎の評価値の最大値、合計値、平均値、および最小値の少なくともいずれか一つを送受信履歴情報として承認依頼メールM2に含めてもよい。
図18の例では、承認依頼メールM2のヘッダ部120の重要度ヘッダ222(X-Priority:)に評価値が記録されている。他の例では、たとえば、承認依頼メールM2のヘッダ部120のコメントヘッダ(Comments:)(不図示)に評価値を記録してもよい。
振分けルール22には、図19に示すように、評価値が2未満という承認条件がさらに含まれてもよい。この条件下では、承認対象メールM1の全ての宛先の安全性が高い場合にのみ承認される。
このように構成された本実施形態のメール装置200の動作について、以下説明する。
図20は、メール装置200における承認依頼メールM2の作成手順を示すフローチャートである。
このフローは、図9のステップS105の詳細手順に対応する。
まず、取得部102が、承認対象メールM1の情報(差出人、宛先、添付ファイル情報)を取得する(ステップS201)。さらに、取得部102が、送受信回数情報214と同報履歴情報216を参照し、差出人と宛先に対応する送受信回数と、同報回数の情報をそれぞれ取得する(ステップS203)。
そして、評価部202が、図16の設定ポリシに従い、送受信回数と同報回数から、メールの宛先毎に評価値を算出する(ステップS205)。メール作成部104は、メールの宛先の評価値の中から最大値を取得し(ステップS207)、承認依頼メールM2のヘッダ部120の重要度ヘッダ222(X-Priority:)に記載する。さらに、メール作成部104は、ステップS201およびステップS207で取得した各情報を承認依頼メールM2のヘッダ部120および本文130に記載して、図18のような承認依頼メールM2を作成する(ステップS209)。
そして、上記実施形態で説明したように、メール作成部104により作成された承認依頼メールM2が承認者U1のメールボックス領域46の受信ボックス112に格納され、振分け部106により図10の承認依頼メールM2の承認判定に基づく振分け処理が行われる。そして、実行部108により図11の承認依頼メールM2の配送処理が行われる。
以上説明したように、本実施形態のメール装置200によれば、上記実施形態と同様な効果を奏するとともに、さらに、承認対象メールM1の送信元と宛先間のメールの送受信履歴に基づく情報を用いて送信元と宛先の関係の安全性を示す評価値を算出し、承認依頼メールM2に含めるので、承認作業の信頼性を向上することができる。
(第3の実施の形態)
次に、本発明の第3の実施の形態について、以下説明する。
本実施形態のメール装置は、第1の実施の形態のメール装置100および第2の実施形態のメール装置200のいずれか一方と同じ構成を有し、動作が上記実施形態とは異なる。ここでは、第2実施形態のメール装置200と同様な構成を有するものとする。また、本実施形態のメール装置は、後述する他の実施の形態と組み合わせてもよい。
図21は、本実施形態におけるメールサーバ40の要部である、承認者U1のメールボックス領域46とメール装置200を示す図である。
本実施形態のメール装置200は、振分けルール22に従い承認依頼メールM2が振り分けによる承認処理において、承認条件に合わないメールを要確認メールとして振り分ける点、または否認条件に従う振分け処理を行う点を除いて、上記実施形態のいずれかのメール装置と同様である。
メールボックス領域46は、受信ボックス112と、承認済みボックス114と、要確認ボックス116と、否認ボックス117と、を有する。
本実施形態のメール装置200によれば、振分けルール22による自動判定で承認されなかった承認対象メールM1について要確認ボックス116に格納し、承認者U1が内容を確認させ、承認者U1により承認されたメールを簡易な操作手順(図中、破線矢印で示す)でメールを承認済みボックス114または要確認ボックス116に移動させることができる。
所定の振分けルール22には、承認依頼メールM2が承認条件に合わない場合は、当該承認依頼メールM2を要確認ボックス116に格納することが定義されている。
振分けルール22は、複数設定可能であり、本実施形態では、承認依頼メールM2を否認する否認条件を含む振分けルール22も設定される。
図22に示すように、振分けルール22には、承認依頼メールM2を否認する否認条件として、添付ファイルがあること、宛先に社外ドメインが含まれていること、評価値が3以上であること、が定義される。さらに、振分けルール22には、否認条件の少なくともいずれか一つに合致した場合の動作として、条件に合ったメールを否認ボックス117に移動することが定義される。
さらに、MUA20を用いて、要確認ボックス116内の承認依頼メールM2を所定のメールボックス(たとえば、承認済みボックス114または否認ボックス117等)に移動する操作が承認者U1により行われた場合、実行部108は、承認者U1の移動操作により所定のメールボックスに格納された承認依頼メールM2についても、当該各メールボックスに設定されるアクションを実行する。
要確認ボックス116には、アクションは設定されなくてよい。要確認ボックス116に格納された承認依頼メールM2は、MUA20を用いて承認者U1によって内容が確認され、承認者U1が承認済みボックス114または否認ボックス117に移動操作される。
図23は、承認者U1のMUA20に表示されるメールのプレビュー画面310の一例を示す図である。
プレビュー画面310は、ボックス構成欄320と、メールリスト330と、メールプレビュー欄340と、を含む。
ボックス構成欄320には、ユーザU1のメールボックス領域46のメールボックスの構成が模式的にGUI(Graphical User Interface)で表示される。ボックス構成欄320には、要確認ボックスアイコン322と、承認済みボックスアイコン324と、否認ボックスアイコン326と、が少なくとも表示されている。
メールリスト330には、ボックス構成欄320で選択されたボックス内のメールの情報(件名、受信日時、差出人等)が一覧表示される。ここでは、破線L1で囲まれている要確認ボックスアイコン322が選択されている例が示されている。
メールプレビュー欄340には、メールリスト330で選択されたメール(破線L2で囲まれている)のプレビューが表示される。メールプレビュー欄340は、メールヘッダ欄342と、メール本文欄344と、を含む。メールヘッダ欄342に、メールのヘッダ情報(件名、受信日時、差出人、宛先等)が表示され、メール本文欄344にメール本文が表示される。
承認者U1は、プレビュー画面310で要確認ボックス116に格納されたメールを閲覧し、内容を確認した上で、承認できると判断した場合は、メールリスト330のメールをボックス構成欄320の承認済みボックスアイコン324にドラッグする操作を行う。
この操作により、メールサーバ40のユーザU1のメールボックス領域46の要確認ボックス116に格納されたメールが承認済みボックス114に移動される。
承認済みボックス114に移動されたメールは、実行部108により、承認済みボックス114に設定されたアクションに従い、配送処理される。
また、承認者U1は、メールが承認できないと判断した場合は、メールリスト330のメールをボックス構成欄320の否認ボックスアイコン326にドラッグする操作を行う。
この操作により、メールサーバ40のユーザU1のメールボックス領域46の要確認ボックス116に格納されたメールが否認ボックス117に移動される。
否認ボックス117に移動されたメールは、実行部108により、否認ボックス117に設定されたアクションに従い、配送処理が中止される。
図23に示すように、メール本文欄344には、メールを承認する場合に、承認依頼メールM2を承認済みボックス114に移動することを指示する内容が記載されるとともに、メールを承認しない場合は、承認依頼メールM2を否認ボックス117に移動することを指示する内容が記載されている。
このように、承認者U1のMUA20のプレビュー画面310上で、確認が必要なメールを承認者U1が手動で操作することができ、操作に従い、メールを処理することもできる。
図21に戻り、否認ボックス117に設定されるアクションは、否認ボックス117に格納された承認依頼メールM2に対応する承認対象メールM1を承認待ちメール記憶部50から削除することである。
このとき、実行部108は、否認ボックス117に格納された承認依頼メールM2のリファレンス128を参照し、メッセージIDを取得する。そして、承認待ちメール記憶部50を検索して、取得したメッセージIDを有する承認対象メールM1を見つけ、承認待ちメール記憶部50から削除する。これにより、否認されたメールの配送を中止できる。
さらに、実行部108は、否認ボックス117に格納されている当該承認依頼メールM2も削除する。
また、メール装置200は、否認された承認対象メールM1の配送が中止されたことを、当該メールの差出人に通知する通知部(不図示)をさらに備えてもよい。
たとえば、承認依頼メールM2のメール情報欄134の差出人表示欄134b(From:)から、承認対象メールM1の差出人144(From:)のメールアドレスを取得し、そのメールアドレスに、配送中止のメッセージを本文に記載したメールを送信する。また、通知メールには、元の承認対象メールM1を添付してもよい。
このように構成された本実施形態のメール装置200の動作について、以下説明する。
図24は、承認条件(図19の振分けルール22)に従ったメールの振り分け処理に続き、否認条件(図22の振分けルール22)に従ったメールの振り分け処理の手順を示すフローチャートである。
本フローは、振分け部106が図10のステップS113の承認条件に従ったメールの振り分け処理を行った後に、ステップS113で承認条件に構築しなかった場合に(ステップS113のNO)実行される。
まず、振分け部106が、受信ボックス112に格納された承認依頼メールM2が、承認者U1のMUA20により設定された振分けルール22の否認条件に合致するか否か判定する(ステップS301)。合致した場合(ステップS301のYES)、振分け部106は、受信ボックス112から否認ボックス117に承認依頼メールM2を移動する(ステップS303)。合致しない場合(ステップS301のNO)、当該承認依頼メールM2を受信ボックス112から要確認ボックス116に移動する(ステップS305)。
そして、他の承認依頼メールM2が受信ボックス112にあれば図10のステップS111に戻り本フローの処理を繰り返す(不図示)。他の承認依頼メールM2が受信ボックス112になければ、ひとまず本フローを終了する。
図24の処理により、承認依頼メールM2の否認振り替え処理が終了する。なお、本例では、承認条件に従った振分け処理の後に否認条件に従った振分け処理を行う構成について説明しているが、他の例では、否認条件に従った振分け処理を先に行い、その後、承認条件に従った振分け処理を行ってもよい。
次に、否認された承認依頼メールM2の配送中止処理について説明する。
図25は、本実施形態のメール装置200の実行部108の動作の一例を示すフローチャートである。
上述したように、否認ボックス117には、予めアクションが定義されている。実行部108は、否認ボックス117に設定されたアクションを実行する。本図のフロー開始のタイミングは、たとえば、定期的に行うことができる。あるいは、承認者U1またはメールサーバ40の管理者によって設定されたタイミングでもよい。あるいは、振分け部106が否認ボックス117に承認依頼メールM2を格納したとき、実行部108に通知し、通知を受けたタイミングで開始されてもよい。または、否認ボックス117に所定数以上のメールが格納されたときや、メールが格納されてから所定時間以上経過したとき等に開始されてもよい。これらの組み合わせでもよい。開始のタイミングは、予め定められていてもよいし、承認者U1または管理者により随時設定変更できてもよい。
まず、実行部108が、承認者U1のメールボックス領域46の否認ボックス117を参照し、メールが格納されているか否か確認する(ステップS311)。そして、実行部108が、否認ボックス117に入っている承認依頼メールM2を取り出す(ステップS313)。実行部108が、取り出した承認依頼メールM2に対応する承認対象メールM1を承認待ちメール記憶部50の承認待ちキューから検索する(ステップS315)。
具体的には、実行部108が、承認依頼メールM2のリファレンス128(References:)に記載されている承認対象メールM1のメッセージIDと同じメッセージID150を有する承認対象メールM1を、承認待ちメール記憶部50の承認待ちキューから検索する。
対応する承認対象メールM1が見つかった場合(ステップS317のYES)、通知部が、承認対象メールM1が否認されたことを本文に明記したメールを作成し、否認された承認対象メールM1の差出人に配送する(ステップS319)。
対応する承認対象メールM1が見つからなかった場合(ステップS317のNO)、本処理を終了する。このとき、実行部108は、図11のステップS127で説明した処理と同様な所定のエラー処理を通知部により行ってもよい。
ステップS319の後、実行部108は、承認待ちメール記憶部50の承認待ちキューから配送済みの承認対象メールM1を削除する(ステップS321)。さらに、実行部108は、承認者U1のメールボックス領域46の否認ボックス117から承認依頼メールM2を削除する(ステップS323)。
以上説明したように、本実施形態のメール装置200において、振分け部106により、振分けルール22に定義された承認条件に合致しない承認依頼メールM2は、要確認ボックス116に振分けられるので、承認者U1は、要確認ボックス116に格納された承認依頼メールM2を、MUA20を用いて閲覧し、内容を確認して承認作業を行うことができる。
このように、本実施形態のメール装置200によれば、上記実施形態と同様な効果を奏するとともに、さらに、承認条件に合致しないものについては、承認者U1が要確認ボックス116に確認された承認依頼メールM2の内容を確認して承認作業を行うことができる。承認作業はMUA20を用いてメールを承認済みボックス114または否認ボックス117の何れかに移動することで行うことができる。
たとえば、承認者U1が承認できると判断した場合は、MUA20を用いてそのメールを承認済みボックス114に移動し、承認できないと判断した場合は、MUA20を用いてそのメールを否認ボックス117に移動する操作を行えばよい。このように簡単な操作で承認作業を行うことができる。
さらに、本実施形態のメール装置200によれば、否認条件を含む振分けルール22により、承認依頼メールM2を否認ボックス117に自動的に振分けることができるので、承認者U1の承認作業の負担を低減でき、かつ、承認作業を効率化でき、人為的なミスを回避でき、メールの誤配信を防止できる。
さらに、否認ボックス117に設定されたアクションに従い、承認依頼メールM2に対応する承認対象メールM1を承認待ちメール記憶部50の承認待ちキューから削除するとともに、差出人にメールが否認され配送中止された旨を通知することができるので、差出人はメールが配送中止されたことを知ることができる。
(第4の実施の形態)
次に、本発明の第4の実施の形態について、以下説明する。
本実施形態のメール装置は、上記実施形態のメール装置のいずれか一つと同じ構成を有し、動作が上記実施形態とは異なる。ここでは、第3実施形態のメール装置200と同様な構成を有するものとする。また、本実施形態のメール装置は、後述する他の実施の形態と組み合わせてもよい。
本実施形態のメール装置200は、承認者U1とは別の承認者(たとえば、代理ユーザU5)にメールの承認を委譲できる点を除いて、上記実施形態のいずれかと同様である。本実施形態のメール装置200によれば、承認者U1が不在になる場合等に、代理ユーザU5にメールの承認作業を委譲できる。
所定の振分けルール22には、承認依頼メールM2の送受信履歴情報が承認条件に合わず、かつ、承認者U1とは別の承認者(代理ユーザU5)にメールの承認を委譲する委譲条件に合う場合に、当該承認依頼メールM2を委譲ボックス(不図示)に格納することが含まれている。
実行部108は、委譲ボックスに格納された承認依頼メールM2について、委譲ボックスに設定されたアクションに従い、当該承認依頼メールM2を代理ユーザU5の受信ボックスに転送する。
振分けルール22には、承認依頼メールM2を委譲する委譲条件として、たとえば、件名に「至急」、「緊急」、「重要」、「要返信」等の用語や、所定のキーワード(所定のプロジェクト名等)が含まれていること、差出人が所定の送信元(重要クライアント等)であること、メール受信日から所定期間以上経過したメールであること等が定義されてよい。さらに、振分けルール22には、委譲条件の少なくとも一つに合致した場合の動作として、条件に合ったメールを委譲ボックスに移動することが定義されてよい。
また、委譲ボックスには、格納されたメールに対するアクションが設定されていて、承認依頼メールM2が格納された時、アクションに従い、実行部108により承認依頼メールM2に対する処理が行われる。
委譲ボックスに設定されるアクションは、たとえば、承認依頼メールM2を、承認者U1により予め指定されている委譲先の代理ユーザU5のメールボックス領域46の受信ボックス112に配送する。委譲先の代理ユーザU5は、承認者U1から転送された承認依頼メールM2を見て、承認処理を行うことができる。
さらに、委譲先の代理ユーザU5も、MUA20において、承認者U1と同様な振分けルール22が設定されていて、かつ、代理ユーザU5のメールボックス領域46も承認者U1と同様なメールボックス(承認済みボックス114、要確認ボックス116、否認ボックス117等)を有していてもよい。これにより、承認者U1から委譲に転送された承認依頼メールM2を、代理ユーザU5のMUA20により同様に自動的に振り分け、承認処理することができてもよい。
以上説明したように、本実施形態によれば、上記実施形態と同様な効果を奏するとともに、さらに、承認者U1が不在な場合にも、予め承認作業の委譲先の代理ユーザU5を指定しておくことで、承認作業を滞りなく行うことができる。たとえば、緊急に対処が必要な内容を含む承認対象メールM1が、承認作業の停滞により配送遅延となることを防ぐことができる。委譲処理は、振分けルール22に委譲条件と委譲者(代理ユーザU5)へのメール転送のアクションが設定された委譲ボックスへの移動を設定するだけで実現できる。このように、承認者U1のMUA20を用いて、委譲条件を振分けルール22に設定する簡単な操作だけで、不在時の代理ユーザU5への承認依頼メールM2の承認作業の委譲を依頼できる。
(第5の実施の形態)
本発明の第5の実施の形態に係るメール装置は、本発明のメール装置の最小構成を有する。
図26は、本実施形態のメール装置100の構成を論理的に示す機能ブロック図である。
図27は、本実施形態のメール装置100の動作の一例を示すフローチャートである。
メール装置100は、取得部102と、メール作成部104と、振分け部106と、を備える。
取得部102は、承認対象メールM1を特定する情報(メッセージID)を取得する。
メッセージIDは、たとえば、メールヘッダのMessage ID:である。
メール作成部104は、承認対象メールM1の承認依頼メールM2を作成する。承認依頼メールM2にはメッセージIDが含められる。メール作成部104は、承認依頼メールM2を承認者U1の受信ボックス112に格納する。
振分け部106は、予め設定された振分けルール22に従って、承認者U1の受信ボックス112に格納された承認依頼メールM2を、所定のメールボックスに振り分ける。
所定の振分けルール22には、承認依頼メールM2が、承認条件に合う場合に、当該承認依頼メールM2を承認済みボックス114に格納することが含まれている。
本実施の形態のメール装置100は、コンピュータプログラムに対応する各種の処理動作をCPUが実行することにより、前述のような各種ユニットが各種機能として実現される。
本実施形態のコンピュータプログラムは、メール装置100を実現させるためのコンピュータに、承認対象メールM1を特定する情報(メッセージID)を取得する手順、承認対象メールM1の特定情報(メッセージID)を含む当該メールの承認依頼メールM2を作成する手順、メールの承認者U1の受信ボックス112に格納する手順、予め設定された振分けルール22に従って、受信ボックス112に格納された承認依頼メールM2を所定のメールボックスに振分ける手順、を実行させるように記述されている。
コンピュータプログラム90を記録する記録媒体は、非一時的な有形のコンピュータ80が使用可能な媒体を含み、その媒体に、コンピュータ80が読み取り可能なプログラムコードが埋め込まれる。コンピュータプログラム90が、コンピュータ80上で実行されたとき、コンピュータ80に、メール装置100を実現する以下の情報処理方法を実行させる。
このように構成された本実施形態のメール装置100の情報処理方法は、メール装置100が、承認対象メールM1を特定する情報(メッセージID)を取得し(ステップS501)、承認対象メールM1の特定情報(メッセージID)を含む当該メールの承認依頼メールM2を作成し(ステップS503)、メールの承認者U1の受信ボックス112に格納し(ステップS505)、予め設定された振分けルール22に従って、受信ボックス112に格納された承認依頼メールM2を所定のメールボックスに振分ける(ステップS507)、ことを含む。
以上説明したように、本実施形態のメール装置100によれば、承認対象メールM1のメッセージIDを含む承認依頼メールM2を作成し、承認者U1の受信メールボックスに格納し、承認者U1のメーラーで設定された振分けルールに含まれる承認条件に、受信メールボックス内のメールが合致する場合に、承認者U1の承認済みボックスにメールを振り分けることができる。
このように、本実施形態によれば、予め設定された承認条件を含む振分けルール22に従い、配信可能と判断されたメールは承認済みボックス114に移動することができるので、配送可否判断のために承認者U1がメールの内容を確認する必要がない。メールの配送可否判断を自動化できるので、人為的なミスを回避でき、メールの誤配信を防止できる。
また、メール内容の確認作業が人手による場合、手間がかかるが、本実施形態では、自動的に配送可否判断を行うので、確認作業の手間が省け、作業効率を向上でき、承認者U1の承認作業の負担を低減できる。
さらに、本実施形態によれば、承認者U1のMUA20を用いて、承認条件を振分けルール22に設定する簡単な操作だけで、承認処理を実現することができる。承認者U1のユーザ端末10に特別な構成を追加する必要がなく、一般的なMUA20の振分け機能を利用するだけでよい。
以上、図面を参照して本発明の実施形態について述べたが、これらは本発明の例示であり、上記以外の様々な構成を採用することもできる。
(承認依頼メールM2の他の例)
たとえば、上記実施形態では、承認対象メールM1の差出人、宛先等の情報を承認依頼メールM2の本文に記載していた。他の実施形態では、これらの情報を承認依頼メールM2のヘッダに記載してもよい。
図28は、承認依頼メールM2のヘッダの一例を示す図である。
送信者ヘッダ(Sender:)には、承認依頼用の専用のメールアドレスが記載される。
宛先ヘッダ(To:)には、承認対象メールM1の同報宛先を含む全ての宛先ヘッダ(To:, cc:, bcc:)のメールアドレスが全て記載される。
差出人ヘッダ(From:)には、承認対象メールM1の差出人ヘッダ(From:)のメールアドレスが記載される。
件名ヘッダ(Subject:)には、承認対象メールM1の件名と、添付ファイル名が記載される。たとえば、「Fw:市場規模のリサーチ報告(市場調査報告資料.doc)」となる。
返信先ヘッダ(Reply-To:)とエラー時返却先ヘッダ(Return-Path)には、承認対象メールM1の差出人ヘッダ(From:)のメールアドレスが記載される。
重要度ヘッダ(X-Piority:)には、承認対象メールM1の評価値(1〜5の整数)が記載される。
この構成によれば、MUA20の振分け機能が、ヘッダ情報のみに対応している場合であっても本発明のメール装置を実現することができる。
(複数の承認者による承認処理のための構成)
また、上記実施形態では、1人の承認者が承認作業を行う場合について説明した。他の実施形態では、複数の承認者により承認作業が行われる構成を有してもよい。
複数の承認者は、たとえば、承認権限レベルが異なる複数の承認者であってもよいし、複数の異なる部署の承認者であってもよい。第1承認者(たとえば、課長)、第2承認者(たとえば、部長)等、承認依頼メールM2を巡回させる順序を示す情報とともに対応付けておく。
たとえば、第1承認者において、振分けルール22は、承認条件と、複数の承認者による要否確認条件を設定し、第2承認者の受信メールボックス(不図示)に転送するアクションが設定される転送メールボックス(不図示)に振分けを行うように定義される。
第2承認者の承認が必要な承認対象メールM1の場合に、メール作成部104が、第2承認者の承認が必要であることを示す情報を承認依頼メールM2の本文130に含めればよい。第2承認者の承認が必要なメールか否かは、前記した承認対象対応テーブル110において、宛先または差出人のメールアドレスまたはドメイン名に、複数の承認者を巡回順序とともに対応付けることができる。
メール作成部104は、第1承認者の受信ボックス112に承認依頼メールM2を格納する。承認依頼メールM2には、本文130に、第2承認者の承認が必要なことを示す情報(たとえば、「このメールは、さらに別の承認者の承認が必要です」等のメッセージ)と、第2承認者の受信ボックス112を特定するための情報(たとえば、アカウント名やメールアドレス)を記述する。
あるいは、承認依頼メールM2のヘッダ部120の返信先ヘッダ(Reply-To)に第2承認者のメールアドレス(またはアカウント名)を記述してもよい。
承認条件に、返信先ヘッダ(Reply-To)に宛先の記載があること、または、本文130に「このメールは、さらに別の承認者の承認が必要です」等のメッセージの記載があること、等をさらに含め、条件に合致した場合に、第2承認者の承認が必要な承認依頼メールM2として転送メールボックスに振り分けることができる。
各承認者における承認処理は、上記実施形態と同様に行うことができる。第1承認者の振分けルール22による承認条件に従い、メールの振分けが行われた後、第2承認者の振分けルール22による承認条件に従い、メールの振分けが行われる。第1承認者と第2承認者の両方により承認されたメールが、宛先に配送されることになる。
この構成により、たとえば、課長と部長の複数の承認者や、異なる複数の部署の承認者による承認作業も可能となる。
以上、実施形態および実施例を参照して本願発明を説明したが、本願発明は上記実施形態および実施例に限定されるものではない。本願発明の構成や詳細には、本願発明のスコープ内で当業者が理解し得る様々な変更をすることができる。
なお、本発明において利用者に関する情報を取得、利用する場合は、これを適法に行うものとする。
上記の実施形態の一部または全部は、以下の付記のようにも記載されうるが、以下に限られない。
1. 承認対象のメールを特定する情報を取得する取得手段と、
前記メールの特定情報を含む当該メールの承認依頼メールを作成し、前記メールの承認者の受信メールボックスに格納するメール作成手段と、
予め設定された振分けルールに従って、前記受信メールボックスに格納された前記承認依頼メールを所定のメールボックスに振分ける振分け手段と、を備え、
前記所定の振分けルールには、前記承認依頼メールが、承認条件に合う場合に、当該承認依頼メールを承認済みメールボックスに格納することが含まれている、メール装置。
2. 1.に記載されたメール装置において、
前記取得手段は、さらに、前記メールの送信元のメールの送受信履歴に基づく情報を取得し、
前記メール作成手段は、前記送受信履歴に基づく情報を前記承認依頼メールに含め、
前記所定の振分けルールには、前記承認依頼メールに含まれる前記送受信履歴に基づく情報が前記承認条件に合う場合に、当該承認依頼メールを前記承認済みメールボックスに格納することが含まれている、メール装置。
3. 2.に記載されたメール装置において、
前記送受信履歴に基づく情報は、前記メールの宛先と送信元との間のメールの送受信履歴に基づく情報を含んでいる、メール装置。
4. 3.に記載のメール装置において、
前記取得手段は、前記メールの送受信履歴に基づく情報から、前記メールの送信元と宛先間における送受信回数と、前記メールの送信元となるユーザ毎に、同報宛先の他のユーザ毎の同報回数と、を取得し、
当該メール装置は、前記メールの前記宛先毎に、前記送受信回数と前記同報回数が少ない程、大きくなり、前記送受信回数と前記同報回数が多い程、小さくなる評価値を設定する評価手段をさらに備え、
前記メール作成手段は、前記メールの前記宛先毎の前記評価値に基づく前記送受信履歴情報を前記承認依頼メールに含める、メール装置。
5. 1.から4.いずれか一つに記載のメール装置において、
前記所定のメールボックスには、前記振分けルールに従って振分けられたメールが格納されたときのアクションがそれぞれ設定されており、
前記所定のメールボックス毎に設定された前記アクションを、前記メールボックスに格納されたメールに対して実行する実行手段をさらに備え、
前記実行手段は、
前記承認済みメールボックスに格納された前記承認依頼メールについて、前記アクションに従い、当該承認依頼メールに対応するメールを一時的に記憶している承認待ちメール記憶部から読み出し、当該メールの宛先へ配送する、メール装置。
6. 5.に記載のメール装置において、
前記所定の振分けルールには、前記承認依頼メールが前記承認条件に合わない場合は、当該承認依頼メールを要確認メールボックスに格納することが含まれており、
メーラーを用いて、前記要確認メールボックス内の前記承認依頼メールを前記所定のメールボックスに移動する操作が前記承認者により行われた場合、前記実行手段は、前記承認者により移動操作により前記所定のメールボックスに格納された前記承認依頼メールについても、当該メールボックスに設定される前記アクションを実行する、メール装置。
7. 5.または6.に記載のメール装置において、
前記所定の振分けルールには、前記承認依頼メールの前記送受信履歴情報が前記承認条件に合わず、かつ、前記承認者とは別の承認者に前記メールの承認を委譲する委譲条件に合う場合に、当該承認依頼メールを委譲メールボックスに格納することが含まれており、
前記実行手段は、
前記委譲メールボックスに格納された前記承認依頼メールについて、前記アクションに従い、当該承認依頼メールを前記別の承認者の受信メールボックスに転送する、メール装置。
8. メール装置が、
承認対象のメールを特定する情報を取得し、
前記メールの特定情報を含む当該メールの承認依頼メールを作成し、前記メールの承認者の受信メールボックスに格納し、
予め設定された振分けルールに従って、前記受信メールボックスに格納された前記承認依頼メールを所定のメールボックスに振分け、
前記所定の振分けルールには、前記承認依頼メールが、承認条件に合う場合に、当該承認依頼メールを承認済みメールボックスに格納することが含まれているメール装置の情報処理方法。
9. 8.に記載された情報処理方法において、
前記メール装置が、
さらに、前記メールの送信元のメールの送受信履歴に基づく情報を取得し、
前記送受信履歴に基づく情報を含めて、前記承認依頼メールを作成し、
前記所定の振分けルールには、前記承認依頼メールに含まれる前記送受信履歴に基づく情報が前記承認条件に合う場合に、当該承認依頼メールを前記承認済みメールボックスに格納することが含まれている、情報処理方法。
10. 9.に記載された情報処理方法において、
前記送受信履歴に基づく情報は、前記メールの宛先と送信元との間のメールの送受信履歴に基づく情報を含んでいる、情報処理方法。
11. 10.に記載の情報処理方法において、
前記メール装置が、
前記メールの送受信履歴に基づく情報から、前記メールの送信元と宛先間における送受信回数と、前記メールの送信元となるユーザ毎に、同報宛先の他のユーザ毎の同報回数と、を取得し、
前記メールの前記宛先毎に、前記送受信回数と前記同報回数が少ない程、大きくなり、前記送受信回数と前記同報回数が多い程、小さくなる評価値を設定し、
前記メールの前記宛先毎の前記評価値に基づく前記送受信履歴情報を含めて、前記承認依頼メールを作成する、情報処理方法。
12. 8.から11.いずれか一つに記載の情報処理方法において、
前記所定のメールボックスには、前記振分けルールに従って振分けられたメールが格納されたときのアクションがそれぞれ設定されており、
前記メール装置が、
前記所定のメールボックス毎に設定された前記アクションを、前記メールボックスに格納されたメールに対して実行し、
前記承認済みメールボックスに格納された前記承認依頼メールについて、前記アクションに従い、当該承認依頼メールに対応するメールを一時的に記憶している承認待ちメール記憶部から読み出し、当該メールの宛先へ配送する、情報処理方法。
13. 12.に記載の情報処理方法において、
前記所定の振分けルールには、前記承認依頼メールが前記承認条件に合わない場合は、当該承認依頼メールを要確認メールボックスに格納することが含まれており、
前記メール装置が、
メーラーを用いて、前記要確認メールボックス内の前記承認依頼メールを前記所定のメールボックスに移動する操作が前記承認者により行われた場合、前記承認者により移動操作により前記所定のメールボックスに格納された前記承認依頼メールについても、当該メールボックスに設定される前記アクションを実行する、情報処理方法。
14. 12.または13.に記載の情報処理方法において、
前記所定の振分けルールには、前記承認依頼メールの前記送受信履歴情報が前記承認条件に合わず、かつ、前記承認者とは別の承認者に前記メールの承認を委譲する委譲条件に合う場合に、当該承認依頼メールを委譲メールボックスに格納することが含まれており、
前記メール装置が、
前記委譲メールボックスに格納された前記承認依頼メールについて、前記アクションに従い、当該承認依頼メールを前記別の承認者の受信メールボックスに転送する、情報処理方法。
15. コンピュータに、
承認対象のメールを特定する情報を取得する手順、
前記メールの特定情報を含む当該メールの承認依頼メールを作成し、前記メールの承認者の受信メールボックスに格納する手順、
予め設定された振分けルールに従って、前記受信メールボックスに格納された前記承認依頼メールを所定のメールボックスに振分ける手順、を実行させるためのプログラムであり、
前記所定の振分けルールには、前記承認依頼メールが、承認条件に合う場合に、当該承認依頼メールを承認済みメールボックスに格納することが含まれているプログラム。
16. 15.に記載されたプログラムにおいて、
さらに、前記メールの送信元のメールの送受信履歴に基づく情報を取得する手順、
前記送受信履歴に基づく情報を前記承認依頼メールに含めて、前記承認依頼メールを作成する手順、をコンピュータに実行させるためのプログラムであり、
前記所定の振分けルールには、前記承認依頼メールに含まれる前記送受信履歴に基づく情報が前記承認条件に合う場合に、当該承認依頼メールを前記承認済みメールボックスに格納することが含まれている、プログラム。
17. 16.に記載されたプログラムにおいて、
前記送受信履歴に基づく情報は、前記メールの宛先と送信元との間のメールの送受信履歴に基づく情報を含んでいる、プログラム。
18. 17.に記載のプログラムにおいて、
前記メールの送受信履歴に基づく情報から、前記メールの送信元と宛先間における送受信回数と、前記メールの送信元となるユーザ毎に、同報宛先の他のユーザ毎の同報回数と、を取得する手順、
前記メールの前記宛先毎に、前記送受信回数と前記同報回数が少ない程、大きくなり、前記送受信回数と前記同報回数が多い程、小さくなる評価値を設定する手順、
前記メールの前記宛先毎の前記評価値に基づく前記送受信履歴情報を前記承認依頼メールに含めて、前記承認依頼メールを作成する手順、をコンピュータに実行させるためのプログラム。
19. 15.から18.いずれか一つに記載のプログラムにおいて、
前記所定のメールボックスには、前記振分けルールに従って振分けられたメールが格納されたときのアクションがそれぞれ設定されており、
前記所定のメールボックス毎に設定された前記アクションを、前記メールボックスに格納されたメールに対して実行する手順、
前記承認済みメールボックスに格納された前記承認依頼メールについて、前記アクションに従い、当該承認依頼メールに対応するメールを一時的に記憶している承認待ちメール記憶部から読み出し、当該メールの宛先へ配送する手順、をコンピュータに実行させるためのプログラム。
20. 19.に記載のプログラムにおいて、
前記所定の振分けルールには、前記承認依頼メールが前記承認条件に合わない場合は、当該承認依頼メールを要確認メールボックスに格納することが含まれており、
メーラーを用いて、前記要確認メールボックス内の前記承認依頼メールを前記所定のメールボックスに移動する操作が前記承認者により行われた場合、前記承認者により移動操作により前記所定のメールボックスに格納された前記承認依頼メールについても、当該メールボックスに設定される前記アクションを実行する手順をコンピュータに実行させるためのプログラム。
21. 19.または20.に記載のプログラムにおいて、
前記所定の振分けルールには、前記承認依頼メールの前記送受信履歴情報が前記承認条件に合わず、かつ、前記承認者とは別の承認者に前記メールの承認を委譲する委譲条件に合う場合に、当該承認依頼メールを委譲メールボックスに格納することが含まれており、
前記委譲メールボックスに格納された前記承認依頼メールについて、前記アクションに従い、当該承認依頼メールを前記別の承認者の受信メールボックスに転送する手順をコンピュータに実行させるためのプログラム。
22. メール装置を含むメールサーバと、
所定の振分けルールを設定する承認者のメーラーを有するユーザ端末と、を備え、
前記メールサーバは、
送受信されるメールを格納するメールボックス領域をユーザ別に有する記憶装置と、
ユーザ宛に配送されてきた電子メールを受信して、メールボックス領域の当該ユーザの前記メールボックス領域に保管する受信手段と、
前記ユーザから送信された電子メールを受信し、当該電子メールの宛先に配送する配送手段と、を備え、
前記メール装置は、
前記メールサーバが受信した前記電子メールの中から抽出された承認対象のメールを特定する情報を取得する取得手段と、
前記メールの特定情報を含む当該メールの承認依頼メールを作成し、前記メールの承認者の受信メールボックスに格納するメール作成手段と、
予め設定された振分けルールに従って、前記受信メールボックスに格納された前記承認依頼メールを所定のメールボックスに振分ける振分け手段と、を備え、
前記メーラーにおいて、
前記承認者の受信メールボックスに格納されたメールを振り分けるのに使用される前記所定の振分けルールが予め設定され、前記所定の振分けルールには、前記承認依頼メールが、承認条件に合う場合に、当該承認依頼メールを承認済みメールボックスに格納することが含まれている、メールシステム。
23. 22.に記載されたメールシステムにおいて、
前記メール装置において、
前記取得手段は、さらに、前記メールの送信元のメールの送受信履歴に基づく情報を取得し、
前記メール作成手段は、前記送受信履歴に基づく情報を前記承認依頼メールに含め、
前記メーラーにおいて、
前記所定の振分けルールには、前記承認依頼メールに含まれる前記送受信履歴に基づく情報が前記承認条件に合う場合に、当該承認依頼メールを前記承認済みメールボックスに格納することが含まれている、メールシステム。
24. 23.に記載されたメールシステムにおいて、
前記送受信履歴に基づく情報は、前記メールの宛先と送信元との間のメールの送受信履歴に基づく情報を含んでいる、メールシステム。
25. 24.に記載のメールシステムにおいて、
前記メール装置において、
前記取得手段は、前記メールの送受信履歴に基づく情報から、前記メールの送信元と宛先間における送受信回数と、前記メールの送信元となるユーザ毎に、同報宛先の他のユーザ毎の同報回数と、を取得し、
前記メール装置は、
前記メールの前記宛先毎に、前記送受信回数と前記同報回数が少ない程、大きくなり、前記送受信回数と前記同報回数が多い程、小さくなる評価値を設定する評価手段をさらに備え、
前記メール装置において、
前記メール作成手段は、前記メールの前記宛先毎の前記評価値に基づく前記送受信履歴情報を前記承認依頼メールに含める、メールシステム。
26. 22.から25.いずれか一つに記載のメールシステムにおいて、
前記所定のメールボックスには、前記振分けルールに従って振分けられたメールが格納されたときのアクションがそれぞれ設定されており、
前記メール装置は、
前記所定のメールボックス毎に設定された前記アクションを、前記メールボックスに格納されたメールに対して実行する実行手段をさらに備え、
前記メール装置において、
前記実行手段は、
前記承認済みメールボックスに格納された前記承認依頼メールについて、前記アクションに従い、前記メールサーバの前記配送手段に、当該承認依頼メールに対応するメールを一時的に記憶している承認待ちメール記憶部から読み出させ、当該メールの宛先へ配送させる、メールシステム。
27. 26.に記載のメールシステムにおいて、
前記所定の振分けルールには、前記承認依頼メールが前記承認条件に合わない場合は、当該承認依頼メールを要確認メールボックスに格納することが含まれており、
前記メール装置は、
前記メーラーを用いて、前記要確認メールボックス内の前記承認依頼メールを前記所定のメールボックスに移動する操作が前記承認者により行われた場合、前記実行手段は、前記承認者により移動操作により前記所定のメールボックスに格納された前記承認依頼メールについても、当該メールボックスに設定される前記アクションを実行する、メールシステム。
28. 26.または27.に記載のメールシステムにおいて、
前記所定の振分けルールには、前記承認依頼メールの前記送受信履歴情報が前記承認条件に合わず、かつ、前記承認者とは別の承認者に前記メールの承認を委譲する委譲条件に合う場合に、当該承認依頼メールを委譲メールボックスに格納することが含まれており、
前記メール装置において、
前記実行手段は、
前記委譲メールボックスに格納された前記承認依頼メールについて、前記アクションに従い、当該承認依頼メールを前記別の承認者の受信メールボックスに転送する、メールシステム。
1 メールシステム
3 ネットワーク
5 外部ネットワーク
10 ユーザ端末
12 MUA
20 承認者のMUA
30 メールの差出人のMUA
22 振分けルール
24 メールボックス定義情報
40 メールサーバ
42 受信部
44 メールボックス領域部
46 ユーザ別メールボックス領域
48 配送部
50 承認待ちメール記憶部
80 コンピュータ
82 CPU
84 メモリ
85 ストレージ
86 I/O
87 通信I/F
89 バス
90 プログラム
100 メール装置
102 取得部
104 メール作成部
106 振分け部
108 実行部
110 承認対象対応テーブル
112 受信ボックス
114 承認済みボックス
116 要確認ボックス
117 否認ボックス
M2 承認依頼メール
120 ヘッダ部
122 件名
124 宛先
126 差出人
128 リファレンス
130 本文
132 メッセージ
134 メール情報欄
134a 宛先表示欄
134b 差出人表示欄
136 添付ファイル情報欄
138 宛先情報
M1 承認対象メール
142 宛先
144 差出人
146 同報宛先
150 メッセージID
200 メール装置
202 評価部
210 送受信履歴記憶部
212 送受信履歴情報
214 送受信回数情報
216 同報履歴情報
218 評価値情報
222 重要度ヘッダ
310 プレビュー画面
320 ボックス構成欄
322 要確認ボックスアイコン
324 承認済みボックスアイコン
326 否認ボックスアイコン
330 メールリスト
340 メールプレビュー欄
342 メールヘッダ欄
344 メール本文欄
U1 承認者
U2、U3、U4 ユーザ
U5 代理ユーザ

Claims (10)

  1. 承認対象のメールを特定する情報を取得する取得手段と、
    前記メールの特定情報を含む当該メールの承認依頼メールを作成し、前記メールの承認者の受信メールボックスに格納するメール作成手段と、
    予め設定された振分けルールに従って、前記受信メールボックスに格納された前記承認依頼メールを所定のメールボックスに振分ける振分け手段と、を備え、
    前記所定の振分けルールには、前記承認依頼メールが、承認条件に合う場合に、当該承認依頼メールを承認済みメールボックスに格納することが含まれている、メール装置。
  2. 請求項1に記載されたメール装置において、
    前記取得手段は、さらに、前記メールの送信元のメールの送受信履歴に基づく情報を取得し、
    前記メール作成手段は、前記メールの送受信履歴に基づく情報から得られる情報を前記承認依頼メールに含め、
    前記所定の振分けルールには、前記承認依頼メールに含まれる前記メールの送受信履歴に基づく情報から得られる情報が前記承認条件に合う場合に、当該承認依頼メールを前記承認済みメールボックスに格納することが含まれている、メール装置。
  3. 請求項2に記載されたメール装置において、
    前記メールの送受信履歴に基づく情報から得られる情報は、前記メールの宛先と送信元との間のメールの送受信履歴に基づく情報を含んでいる、メール装置。
  4. 請求項3に記載されたメール装置において、
    前記取得手段は、前記メールの送受信履歴に基づく情報として、前記メールの送信元と宛先間における送受信回数と、前記メールの送信元となるユーザ毎に、同報宛先の他のユーザ毎の同報回数と、を取得し、
    当該メール装置は、前記メールの前記宛先毎に、前記送受信回数と前記同報回数が少ない程、大きくなり、前記送受信回数と前記同報回数が多い程、小さくなる評価値を設定する評価手段をさらに備え、
    前記メール作成手段は、前記メールの前記宛先毎の前記評価値に基づく情報を、前記メールの送受信履歴に基づく情報から得られる情報として、前記承認依頼メールに含める、メール装置。
  5. 請求項1から4いずれか一項に記載のメール装置において、
    前記所定のメールボックスには、前記振分けルールに従って振分けられたメールが格納されたときのアクションがそれぞれ設定されており、
    前記所定のメールボックス毎に設定された前記アクションを、前記メールボックスに格納されたメールに対して実行する実行手段をさらに備え、
    前記実行手段は、
    前記承認済みメールボックスに格納された前記承認依頼メールについて、前記アクションに従い、当該承認依頼メールに対応するメールを一時的に記憶している承認待ちメール記憶部から読み出し、当該メールの宛先へ配送する、メール装置。
  6. 請求項5に記載のメール装置において、
    前記所定の振分けルールには、前記承認依頼メールが前記承認条件に合わない場合は、当該承認依頼メールを要確認メールボックスに格納することが含まれており、
    メーラーを用いて、前記要確認メールボックス内の前記承認依頼メールを前記所定のメールボックスに移動する操作が前記承認者により行われた場合、前記実行手段は、前記承認者により移動操作により前記所定のメールボックスに格納された前記承認依頼メールについても、当該メールボックスに設定される前記アクションを実行する、メール装置。
  7. 請求項5または6に記載のメール装置において、
    前記所定の振分けルールには、前記承認依頼メールが前記承認条件に合わず、かつ、前記承認者とは別の承認者に前記メールの承認を委譲する委譲条件に合う場合に、当該承認依頼メールを委譲メールボックスに格納することが含まれており、
    前記実行手段は、
    前記委譲メールボックスに格納された前記承認依頼メールについて、前記アクションに従い、当該承認依頼メールを前記別の承認者の受信メールボックスに転送する、メール装置。
  8. メール装置が、
    承認対象のメールを特定する情報を取得し、
    前記メールの特定情報を含む当該メールの承認依頼メールを作成し、前記メールの承認者の受信メールボックスに格納し、
    予め設定された振分けルールに従って、前記受信メールボックスに格納された前記承認依頼メールを所定のメールボックスに振分け、
    前記所定の振分けルールには、前記承認依頼メールが、承認条件に合う場合に、当該承認依頼メールを承認済みメールボックスに格納することが含まれているメール装置の情報処理方法。
  9. コンピュータに、
    承認対象のメールを特定する情報を取得する手順、
    前記メールの特定情報を含む当該メールの承認依頼メールを作成し、前記メールの承認者の受信メールボックスに格納する手順、
    予め設定された振分けルールに従って、前記受信メールボックスに格納された前記承認依頼メールを所定のメールボックスに振分ける手順、を実行させるためのプログラムであり、
    前記所定の振分けルールには、前記承認依頼メールが、承認条件に合う場合に、当該承認依頼メールを承認済みメールボックスに格納することが含まれているプログラム。
  10. メール装置を含むメールサーバと、
    所定の振分けルールを設定する承認者のメーラーを有するユーザ端末と、を備え、
    前記メールサーバは、
    送受信されるメールを格納するメールボックス領域をユーザ別に有する記憶装置と、
    ユーザ宛に配送されてきた電子メールを受信して、メールボックス領域の当該ユーザの前記メールボックス領域に保管する受信手段と、
    前記ユーザから送信された電子メールを受信し、当該電子メールの宛先に配送する配送手段と、を備え、
    前記メール装置は、
    前記メールサーバが受信した前記電子メールの中から抽出された承認対象のメールを特定する情報を取得する取得手段と、
    前記メールの特定情報を含む当該メールの承認依頼メールを作成し、前記メールの承認者の受信メールボックスに格納するメール作成手段と、
    予め設定された振分けルールに従って、前記受信メールボックスに格納された前記承認依頼メールを所定のメールボックスに振分ける振分け手段と、を備え、
    前記メーラーにおいて、
    前記承認者の受信メールボックスに格納されたメールを振り分けるのに使用される前記所定の振分けルールが予め設定され、前記所定の振分けルールには、前記承認依頼メールが、承認条件に合う場合に、当該承認依頼メールを承認済みメールボックスに格納することが含まれている、メールシステム。
JP2016175397A 2016-09-08 2016-09-08 メール装置、その情報処理方法、プログラム、およびメールシステム Active JP6840962B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2016175397A JP6840962B2 (ja) 2016-09-08 2016-09-08 メール装置、その情報処理方法、プログラム、およびメールシステム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2016175397A JP6840962B2 (ja) 2016-09-08 2016-09-08 メール装置、その情報処理方法、プログラム、およびメールシステム

Publications (2)

Publication Number Publication Date
JP2018042127A JP2018042127A (ja) 2018-03-15
JP6840962B2 true JP6840962B2 (ja) 2021-03-10

Family

ID=61624004

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2016175397A Active JP6840962B2 (ja) 2016-09-08 2016-09-08 メール装置、その情報処理方法、プログラム、およびメールシステム

Country Status (1)

Country Link
JP (1) JP6840962B2 (ja)

Also Published As

Publication number Publication date
JP2018042127A (ja) 2018-03-15

Similar Documents

Publication Publication Date Title
US7640307B2 (en) Universal recallable, erasable, secure and timed delivery email
US9100356B2 (en) Method of adding a postscript message to an email
US7818385B2 (en) Method and apparatus for forwarding emails to previous recipients
US7945629B2 (en) Active removal of e-mail recipient from replies and subsequent threads
JP4299281B2 (ja) メール送受信プログラムおよびメール送受信装置
US20040054733A1 (en) E-mail management system and method
CN101663684A (zh) 安全交易通信
US7877448B2 (en) Granularly selecting a subset of recipients who can reply to a sender's e-mail
US20150150091A1 (en) Enabling content protection and management of electronic mail
US10250543B2 (en) Deduplication of e-mail content by an e-mail server
US9299063B2 (en) Receiver side indication of preview content for template emails
JP6840962B2 (ja) メール装置、その情報処理方法、プログラム、およびメールシステム
JP2007267019A (ja) 作業依頼管理システム、方法、およびプログラム
US9106601B2 (en) Selective delivery of content via electronic mail
JP6299166B2 (ja) 通知方法、装置及びプログラム
JP2013012228A (ja) 情報処理装置およびその制御方法、プログラム
JP2021082862A (ja) 誤送信防止装置、誤送信防止方法、及び誤送信防止プログラム
KR20130086014A (ko) 검색 서비스 제공 방법
JP5081287B2 (ja) 情報処理装置およびその制御方法、プログラム
JP7078570B2 (ja) サーバ装置、端末、方法、及びプログラム
KR101014109B1 (ko) 수신자별 보호가 가능한 개인화된 다수 수신자 이메일 시스템
JP6845296B1 (ja) メール送信制御装置及びプログラム
Allen et al. TAPAs: How to Reduce Spam (not the Lunch Meat!).
TR2021021007A2 (tr) Bi̇rden fazla gönderi̇ci̇ye sahi̇p mai̇l si̇stemi̇
JP4320006B2 (ja) メール送受信プログラムおよびメール送受信装置

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20190808

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20201020

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20201216

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: 20210119

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20210201

R150 Certificate of patent or registration of utility model

Ref document number: 6840962

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150