JP7391330B2 - プログラム及びサーバ - Google Patents

Description

本発明は、プログラム及びサーバに関する。

従来から、電子メールがコミュニケーションツールとして利用されており、ＭＵＡ（Ｍａｉｌ Ｕｓｅｒ Ａｇｅｎｔ）から電子メールを受け付けて、電子メールを配送（配信、送信、転送）する処理を行なうＭＴＡ（Ｍａｉｌ Ｔｒａｎｓｆｅｒ Ａｇｅｎｔ）が存在する。

ここで、ＭＵＡとは、インターネット上の端末において電子メールを送受信するために使用されるクライアントプログラムであり、ＭＴＡとは、ＳＭＴＰ（Ｓｉｍｐｌｅ Ｍａｉｌ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）を通じてネットワーク上で電子メールの受信と配送を行うメールサーバのことをいう。

例えば、従来技術として、不適切な電子メールの送信を事前に防止するために、メールが組織外へ送信されると判定された場合に、メールの送信者に対して、当該送信者と関連付けられて記憶された承認者の一覧を表示し、メールの送信を承認する承認者を選択させ、承認されるまでメールの送信を保留状態とするメール送受信プログラムが存在する（特許文献１の００７３～００７６段落、図１３、及び、００９０～００９１段落参照）。

特許４２９９２８１号公報

少なくとも一の承認者の承認によって電子メールが配送される場合、電子メールを滞りなく速やかに承認される機会を与えるために承認者が複数存在することが好ましいが、特許文献１に示す従来技術は、差出人（差出元のユーザ、送信者）が複数の承認者を選択判断するものであり、差出人にとって難しい選択であった。つまり、差出人にとって電子メールが滞りなく速やかに承認されるために、適切な複数の承認者を選択判断することは困難であった。

また、各承認者においても次のような問題もある。例えば、各承認者は、他の承認者が承認待ちの電子メールをチェックするだろうという期待から、電子メールの承認に対する責任が軽視され、承認チェックが後回しにされる、という問題が生じる。また、各承認者が速やかに自ら承認待ちの電子メールをチェックすることに注力するケースでは、同じときに複数の承認者がチェックした場合において、仮に一の承認者が先に承認指示（或いは否認指示）をしてしまった場合、他の承認者は自ら承認指示（或いは否認指示）しようとする時間が無駄となってしまう事態が生じる。このように、複数の承認者の指示がかち合い、一部の承認者に無駄な時間が生じてしまう問題が発生する。そして、承認指示や否認指示そのものに時間を要すると、電子メールの承認待ちによるビジネス上の支障が生じるという問題も存在する。

本願発明は、上述した課題に鑑みたものであり、承認が必要と判定された電子メールについて、電子メールを滞りなく速やかに指示される機会を与え、複数の承認者の指示に伴う作業がかち合う事態を避け、各承認者が自身の役割を考慮した効率的な承認指示又は否
認指示を可能とし、電子メールの承認待ちによるビジネス上の支障を減らすことが可能なプログラム及びサーバを提供することにある。

（１）本発明は、
電子メールを配送するサーバのためのプログラムであって、
差出元から送信された電子メールを受け付ける受け付け部と、
所定の条件に基づいて前記電子メールの承認の要否を判定する判定部と、
前記電子メールの承認が必要と判定された場合に、前記電子メールの配送を保留する保留部と、
前記電子メールの承認が必要と判定された場合に、複数の承認者のうちの一の代表承認者の選択を受け付ける選択部と、
前記代表承認者に対して、承認要求を通知する通知部と、
前記複数の承認者の少なくとも一の承認者から、保留された前記電子メールの承認指示又は否認指示を受け付ける指示受け付け部と、
前記電子メールの承認が必要と判定された場合であって、前記複数の承認者のうちの一の承認者から最先に受け付けた指示が承認指示である場合に前記電子メールを配送する制御を行う、又は、前記複数の承認者のうちの一の承認者から最先に受け付けた指示が否認指示である場合に前記電子メールの配送を中止する制御を行う配送部として、コンピュータを機能させることを特徴とするプログラムに関する。

また、本発明は、前記プログラムを記憶した情報記憶媒体に関する。また、本発明は、前記プログラムを記憶した記憶部と、前記プログラムを実行するためのプロセッサと、を備えるサーバに関する。

本発明は、所定の条件に基づいて電子メールの承認が必要と判定された電子メールについて、承認されるまでメールの配送を保留するので、不適切な電子メールの送信を事前に防止することができる。

特に、本発明は、次のような効果がある。つまり、本発明によれば少なくとも代表承認者に対して承認要求（例えば、承認要求メール）を通知するので、保留された電子メールを滞りなく速やかに承認又は否認の指示を行うための機会を与えることができる。例えば、保留された電子メールの存在について、少なくとも代表承認者は気が付いてくれるので、電子メールが遅滞される事態を防ぐことができる。

また、本発明によれば、例えば、複数の承認者Ａ、Ｂ、Ｃが存在する場合に、代表承認者がＡであるとすると、代表承認者Ａが主として積極的に承認指示或いは否認指示を行う役割となり、承認者Ｂ、Ｃは、代表承認者Ａが何らかの理由で承認指示或いは否認指示を行うことができない場合に、代わりに承認指示或いは否認指示を行う補助的な役割となる。つまり、承認者Ｂ、Ｃは補助的な役割であることが明確であるため、自身の業務に専念でき、指示に伴う作業がかち合うことを避けることができる。その結果、本発明は、電子メールの承認待ちに伴うビジネス上の支障を極力減らすことができ、各承認者が自身の役割を考慮した効率的な承認或いは否認の指示を可能とすることができる。

（２）また、本発明のプログラム、情報記憶媒体及びサーバは、
前記選択部は、
前記差出元のユーザから、複数の承認者のうちの一の代表承認者の選択を受け付けるようにしてもよい。

本発明によれば、差出元のユーザが代表承認者を選択することができるので、代表承認
者の選択において差出元のユーザの意思を反映させることができる。

（３）また、本発明のプログラム、情報記憶媒体及びサーバは、
前記選択部は、
複数の承認者の行動情報に基づいて、当該複数の承認者のうちの一の代表承認者の選択を受け付けるようにしてもよい。

なお、本発明において、「複数の承認者の行動情報に基づいて、当該複数の承認者のうちの一の代表承認者の選択を受け付ける」とは、コンピュータが自動的に代表承認者を選択することを意味する。したがって、本発明によれば、例えば、差出元のユーザが代表承認者を選択する手間を、なくすことができる。

なお、行動情報とは、例えば、出勤情報、位置情報、スケジュール情報等とすることができる。

（４）また、本発明のプログラム、情報記憶媒体及びサーバは、
前記選択部は、
前記代表承認者から、前記代表承認者を除く他の承認者のうちの一の承認者の選択を受け付け、前記代表承認者に代えて選択された一の承認者を新たな代表承認者とし、
前記通知部は、
当該新たな代表承認者に対して承認要求を通知するようにしてもよい。

本発明によれば、代表承認者が多忙である場合等、何等かの理由で代表を辞退したい場合に代表辞退が可能となる。また、代表辞退があった場合は、新たな代表承認者が選ばれ、新たな代表承認者に承認要求を通知するので、保留された電子メールを滞りなく速やかに承認又は否認の指示を行うための機会を与えることができる。

（５）また、本発明のプログラム、情報記憶媒体及びサーバは、
承認者毎に、承認指示又は否認指示を行うことを要する承認待ちの電子メールの一覧画面を表示する制御と、前記一覧画面の中から承認者によって選択された一の電子メールについて、当該承認者が承認指示又は否認指示を行うための指示受け付け画面を表示する制御と、を行う承認者用表示制御部として、コンピュータを更に機能させ、
前記承認者用表示制御部は、
承認待ちの電子メールについて、他の承認者が前記指示受け付け画面を閲覧していることを示す閲覧状況を、前記一覧画面及び前記指示受け付け画面の少なくとも一方に表示するようにしてもよい。

本発明によれば、各承認者が他の承認者の閲覧状況を知ることができ、複数の承認者の指示に伴う作業がかち合うことを避けることができる。その結果、本発明は、電子メールの承認待ちに伴うビジネス上の支障を極力減らすことができ、効率的な承認或いは否認の指示を可能とすることができる。例えば、承認者は、他の承認者が閲覧している承認待ちの電子メールについて自身が指示することを避け、誰も閲覧されていない承認待ちの電子メールを指示することが可能となり、効率的に承認待ち電子メールを裁くことができる。

（６）また、本発明は、
電子メールを配送するサーバのためのプログラムであって、
差出元から送信された電子メールを受け付ける受け付け部と、
所定の条件に基づいて前記電子メールの承認の要否を判定する判定部と、
前記電子メールの承認が必要と判定された場合に、前記電子メールの配送を保留する保留部と、
複数の承認者の少なくとも一の承認者から、保留された前記電子メールの承認指示又は否認指示を受け付ける指示受け付け部と、
前記電子メールの承認が必要と判定された場合であって、前記複数の承認者のうちの一の承認者から最先に受け付けた指示が承認指示である場合に前記電子メールを配送する制御を行う、又は、前記複数の承認者のうちの一の承認者から最先に受け付けた指示が否認指示である場合に前記電子メールの配送を中止する制御を行う配送部と、
承認者毎に、承認指示又は否認指示を行うことを要する承認待ちの電子メールの一覧画面を表示する制御と、前記一覧画面の中から承認者によって選択された一の電子メールについて、当該承認者が承認指示又は否認指示を行うための指示受け付け画面を表示する制御と、を行う承認者用表示制御部として、コンピュータを機能させ、
前記承認者用表示制御部は、
承認待ちの電子メールについて、他の承認者が前記指示受け付け画面を閲覧していることを示す閲覧状況を、前記一覧画面及び前記指示受け付け画面の少なくとも一方に表示することを特徴とするプログラムに関する。

また、本発明は、前記プログラムを記憶した情報記憶媒体に関する。

また、本発明は、前記プログラムを記憶した記憶部と、前記プログラムを実行するためのプロセッサと、を備えるサーバに関する。

本発明は、所定の条件に基づいて電子メールの承認が必要と判定された電子メールについて、承認されるまでメールの配送を保留するので、不適切な電子メールの送信を事前に防止することができる。また、本発明によれば、差出元のユーザが承認者（或いは代表承認者）を選択する煩わしさをなくすことができる。

また、本発明によれば、各承認者が他の承認者の閲覧状況を知ることができ、複数の承認者の指示に伴う作業がかち合うことを避けることができる。その結果、本発明は、電子メールの承認待ちに伴うビジネス上の支障を極力減らすことができ、効率的な承認或いは否認の指示を可能とすることができる。例えば、承認者は、他の承認者が閲覧している承認待ちの電子メールについて自身が指示することを避け、誰も閲覧されていない承認待ちの電子メールを指示することが可能となり、効率的に承認待ち電子メールを裁くことができる。

本実施形態のサーバの機能ブロックの例。 本実施形態のサーバの処理の概要を示した図。 本実施形態の差出元のユーザＩＤと承認者のユーザＩＤとの対応関係を説明するための図。 本実施形態の代表承認者を選択するための電子メール（通知メール、選択画面）の一例。 本実施形態の承認要求メールの一例。 本実施形態の一覧画面の一例。 本実施形態に指示受け付け画面の一例。 本実施形態のフローチャートの一例。 本実施形態のフローチャートの一例。 本実施形態の電子メールの配送処理を説明するための図。 本実施形態の電子メールの配送処理を説明するための図。

以下、本実施形態について説明する。なお、以下に説明する本実施形態は、特許請求の
範囲に記載された本発明の内容を不当に限定するものではない。また本実施形態で説明される構成の全てが、本発明の必須構成要件であるとは限らない。

１．構成
図１は、本実施形態のサーバ１０の機能ブロック図の一例である。なお本実施形態のサーバ１０は、図１の各部を全て含む必要はなく、その一部を省略した構成としてもよい。

記憶部１７０は、処理部１００などのワーク領域となるもので、記憶部１７０には、本実施形態の各部としてコンピュータを機能させるためのプログラム（各部の処理をコンピュータに実行させるためのプログラム）を記憶することができる。

記憶部１７０は、プログラムやデータなどを格納するものであり、その機能は、ＲＡＭ（ＶＲＡＭ）、光ディスク（ＣＤ、ＤＶＤ）、光磁気ディスク（ＭＯ）、磁気ディスク、ハードディスク、磁気テープ、或いはメモリ（ＲＯＭ）等、によりコンピュータにより読み取り可能な情報記憶媒体で実現できる。

本実施形態の記憶部１７０には、ユーザＤＢ１７２（ＤＢはデータベースの略、以下同様。）、保留メール格納領域１７３、履歴ＤＢ１７４、ルールＤＢ１７５が記憶される。

ユーザＤＢ１７２には、ユーザ識別情報（ユーザＩＤ）に対応付けてユーザ（例えば、社員）のメールアドレス、ユーザ用表示制御の画面へのログインパスワード等が記憶される。

保留メール格納領域１７３には、保留されたメール識別情報（保留メールＩＤ、承認メールＩＤともいう。）に対応付けて、承認が必要と判定された電子メール（保留メール）が記憶される。

履歴ＤＢ１７４には、履歴識別情報（履歴ＩＤ）に対応付けて配送又は配送中止の処理がなされた電子メールの状態等が記憶される。つまり、履歴ＤＢ１７４には、承認又は否認の指示に基づき配送又は配送中止がなされた電子メールの情報が蓄積して記憶される。なお、履歴ＤＢ１７４には、各電子メールに対応付けて、当該電子メールの指示内容（承認指示又は否認指示）、承認指示又は否認指示を受け付けた際の代表承認者の情報、当該承認指示又は当該否認指示を受け付けた指示時刻、当該電子メールの配送時刻又は配送中止時刻を記憶してもよい。

ルールＤＢ１７５には、ルール識別情報（ルールＩＤ）に対応付けて、承認要否を判断するための所定の条件（ルール情報、ともいう。）等が記憶される。

処理部１００は、記憶部１７０に格納されるプログラム（データ）に基づいて本実施形態の種々の処理を行う。

処理部１００（プロセッサ）は、記憶部１７０内の主記憶部をワーク領域として各種処理を行う。処理部１００の機能は各種プロセッサ（ＣＰＵ、ＤＳＰ等）などのハードウェアや、プログラムにより実現できる。

処理部１００は、メール処理部（ＭＴＡ）１１０と、Ｗｅｂ処理部１２０と、データベース処理部１３０とを含む。

メール処理部１１０は、ＳＭＴＰを通じてネットワーク上で電子メールの受信と配送（送信）を行う。本実施形態のメール処理部１１０は、受け付け部１１１、判定部１１２、
解析部１１３、保留部１１４、選択部１１５、通知部１１６、指示受け付け部１１７、配送部１１８を含む。

受け付け部１１１は、端末２０のＭＵＡ２１１によって、差出元（差出人、差出元に対応するユーザの端末、差出人の端末）から送信され、エンベロープの宛先が指定された電子メールを受け付ける処理を行う。受け付け部１１１は、同一内容の電子メールに対して複数の宛先が指定された電子メールを受け付けてもよい。

判定部１１２は、所定の条件に基づいて、電子メールの承認の要否を判定する。つまり、判定部１１２は、受け付け部１１１によって受け付けた電子メールを、所定の条件に基づいて承認が必要か否かを判定する。例えば、電子メールの宛先が組織外へ送信されることを所定の条件としてもよい。また、電子メールのメッセージ（本文や添付ファイル）に「秘密」などの特定文字列が含まれることを、所定の条件としてもよい。

判定部１１２は、複数の宛先が指定された電子メールについて、宛先毎に、所定の条件に基づいて電子メールの承認の要否を判定してもよい。

また、判定部１１２は、電子メールの宛先にメーリングリストのメールアドレスが指定されている場合に、当該メーリングリストに登録された参加者の宛先毎に、所定の条件に基づいて、電子メールの承認の要否を判定してもよい。

解析部１１３は、受け付けた電子メールを解析する処理を行う。例えば、エンベロープの宛先（エンベロープＴｏ）、エンベロープの差出元（エンベロープＦｒｏｍ）、メッセージのヘッダ、メッセージのボディの本文部分を解析する処理を行う。例えば、エンベロープの宛先のうちドメインを抽出したり、メッセージのヘッダのうち、Ｔｏ、Ｃｃ、Ｂｃｃ、Ｓｕｂｊｅｃｔを抽出する処理を行う。また、メッセージのボディ部分のうち、本文、添付ファイル等を抽出する処理を行う。

保留部１１４は、電子メールの承認が必要と判定された場合に、当該電子メールの配送を保留する。つまり、保留部１１４は、電子メールの承認が必要と判定された場合に、複数の承認者の中の少なくとも一の承認者から、電子メールの承認指示を受け付けるまで、電子メールの配送を保留する。なお、複数の承認者は、差出元のユーザに対応付けて予め定義されたユーザ（例えば、差出人の上長等）でもよいし、電子メールの内容に基づき決められたユーザであってもよい。

また、保留部１１４は、複数の宛先が指定された電子メールについて、承認が必要と判定された宛先について、当該宛先への電子メールの配送を保留する。

また、保留部１１４は、電子メールの宛先にメーリングリストのメールアドレスが指定されている場合に、承認が必要と判定された参加者の宛先について、当該電子メールの配送を保留する。

選択部１１５は、電子メールの承認が必要と判定された場合に、複数の承認者のうちの一の代表承認者の選択を受け付ける。

例えば、選択部１１５は、電子メールの承認が必要と判定された場合に、差出元のユーザから、複数の承認者のうちの一の代表承認者の選択を受け付けるようにしてもよい。

また、選択部１１５は、電子メールの承認が必要と判定された場合に、複数の承認者の行動情報に基づいて、当該複数の承認者のうちの一の代表承認者の選択を受け付けるよう
にしてもよい。

また、選択部１１５は、代表承認者から代表辞退を受け付けてもよい。そして、選択部１１５は、例えば、代表承認者であるユーザＡから、代表承認者Ａを除く他の承認者（例えば、ユーザＢ、Ｃ）のうちの一の承認者の選択を受け付けた場合、ユーザＡから代表辞退があったとみなしてよい。そして、選択部１１５は、代表承認者Ａに代えて選択された一の承認者を新たな代表承認者とする。

通知部１１６は、代表承認者に対して、承認要求（例えば、承認要求メール）を通知する。なお、通知部１１６は、配送を中止した電子メールについて差出人に配送中止の通知を行う。

また、通知部１１６は、選択部１１５によって辞退を申し出た代表承認者（例えば、ユーザＡ）から一の承認者（例えば、ユーザＢ）の選択を受け付けた場合に、選択された一の承認者（例えば、ユーザＢ）である新たな代表承認者に対して承認要求を通知するようにしてもよい。

指示受け付け部１１７は、複数の承認者の少なくとも一の承認者から、保留された電子メールについての承認指示又は否認指示を受け付ける処理を行う。

配送部１１８は、電子メールを配送する。特に、本実施形態の配送部１１８は、電子メールの承認が必要と判定された場合であって、前記複数の承認者のうちの一の承認者から最先に受け付けた指示が承認指示である場合に前記電子メールを配送する制御を行う、又は、前記複数の承認者のうちの一の承認者から最先に受け付けた指示が否認指示である場合に前記電子メールの配送を中止する制御を行う。

Ｗｅｂ処理部１２０は、ＨＴＴＰ（Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）を通じて、端末２０にインストールされているＷｅｂブラウザ２１０などのクライアントソフトウエアの要求に応じてＨＴＭＬ（Ｈｙｐｅｒ Ｔｅｘｔ Ｍａｒｋｕｐ
Ｌａｎｇｕａｇｅ）文書や画像などのデータを送信（提供）する処理、端末のＷｅｂブラウザ２１０において受け付けたデータを受信する処理を行う。そして、サーバ１０は、管理者やユーザの各端末から受信した情報に基づき、保留メールの処理、ＤＢの更新処理等を行う。

管理者用表示制御部（管理者用ＵＩ部（ＵＩはユーザインターフェースの略、以下同様。））１２１は、管理者の端末２０のＷｅｂブラウザ２１０からのアクセス要求に応じて管理設定用のデータ等を管理者の端末２０に送信（提供）する処理を行い、端末２０から情報を受信する処理を行う。

つまり、管理者用表示制御部１２１は、管理者からの入力に基づいて、各データをＤＢへ追加、削除、更新処理等を行う。なお、管理者用の画面（Ｗｅｂページ、ＵＲＬ）へのアクセスは、管理者のみに権限が与えられる。なお、ＵＲＬは、Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒの略である）。また、ＵＲＬを照会アドレスと呼んでもよい。

ユーザ用表示制御部（ユーザ用ＵＩ部）１２２は、ログイン処理や、端末２０のＷｅｂブラウザ２１０からの要求に応じて、ログインしたユーザに関連する画面（例えば、代表承認者を選択するための選択画面、一覧画面、指示受け付け画面等）を、当該ユーザに提供（提示）する処理を行う。

ユーザ用表示制御部１２２は、差出人用表示制御部１２３、承認者用表示制御部１２４を含む。

また、差出人用表示制御部１２３は、差出元のユーザの端末から保留メールの処理の情報を閲覧する要求を受信した場合に、保留メールの画面を端末に表示する制御を行う（例えば、サーバ１０が、「表示する」或いは「表示する制御」とは、例えば、Ｗｅｂページのデータを端末に送信する処理を行うこと等である。以下同様。）。

保留メールの画面に表示される情報とは、例えば、電子メールのメッセージやエンベロープ等の情報、及び、電子メールの状態（承認待ち、配送済（承認）、配送中止（否認）等）を示す情報である。なお、本実施形態では、メールが送信や削除されても、そのメール本文の複製（コピー）のデータを記憶部（格納領域）に記憶し、ユーザが後で閲覧できるように制御してもよい。

また、差出人用表示制御部１２３は、差出元のユーザの端末から代表承認者を選択するための選択画面を閲覧する要求を受信した場合に、選択画面を端末に表示する制御を行う。

承認者用表示制御部１２４は、承認者毎に、承認指示又は否認指示を行うことを要する承認待ちの電子メールの一覧画面を表示する制御と、前記一覧画面の中から承認者によって選択された一の電子メールについて、当該承認者が承認指示又は否認指示を行うための指示受け付け画面を表示する制御とを行う。つまり、承認者用表示制御部１２４は、自身が承認者であるユーザの端末から一覧画面を閲覧する要求を受信した場合に、一覧画面を当該端末に表示する制御を行う。また、承認者用表示制御部１２４は、自身が承認者であるユーザの端末から指示受け付け画面を閲覧する要求を受信した場合に、指示受け付け画面を当該端末に表示する制御を行う。

承認者用表示制御部１２４は、承認待ちの電子メールについて、他の承認者が前記指示受け付け画面を閲覧していることを示す閲覧状況を、前記一覧画面及び前記指示受け付け画面の少なくとも一方に表示する。

データベース処理部１３０は、データベースに格納されているデータを、登録、更新、削除する処理を行う。例えば、データベース処理部１３０は、管理者用表示制御部１２１、ユーザ用表示制御部１２２において、端末２０から受信したデータに基づいて、データベースを更新する処理を行う。

なお、メール処理部１１０、Ｗｅｂ処理部１２０、データベース処理部１３０は１つの装置で実行させてもよいし、処理の用途に応じて異なる装置に分散して各処理を実行させるようにしてもよい。

２．概要
図２は、本実施形態のサーバ１０の処理の流れの概要を示す。本実施形態のサーバ１０は、配送処理に用いるエンベロープの宛先及びエンベロープの差出元、メッセージとからなる電子メールを受け付け、当該電子メールを配送するＭＴＡ機能を有する。

まず、本実施形態のサーバ１０は、差出人（差出元のユーザ）Ｘの端末２０のＭＵＡから送信された電子メールを受け付け、受け付けた電子メールを解析して電子メールの承認の要否を判断する。

サーバ１０は、承認しないと判断した場合には電子メールを配送する処理を行う。一方
、サーバ１０は、承認が必要（つまり配送を保留）と判断した場合には電子メールの配送を保留する処理を行う。つまり、本実施形態のサーバ１０によれば、所定の条件（承認用のルール）を満たす場合、電子メールを差出人Ｘ以外の承認者に見直す機会を与え、誤送信を防止することができる。なお、本実施形態の承認者は、差出人と異なるユーザである。

ここで、ＭＴＡが、電子メールを配送するとは、ＳＭＴＰを通じて、受け付けた電子メールを他のＭＴＡに配送する処理や、メールサーバが稼動する同一システム内にアカウントを持つユーザ宛に配送するためのローカル配信エージェントＭＤＡ（Ｍａｉｌ Ｄｅｌｉｖｅｒｙ Ａｇｅｎｔ）に配送する処理、ＭＤＡを介せずにメールサーバが稼動する同一システム内にアカウントを持つユーザ宛に配送する場合も含む。

そして、サーバ１０は、差出人Ｘから、差出人Ｘに対応付けられた複数の承認者Ａ、Ｂ、Ｃのうちの一の代表承認者の選択を受け付ける。つまり、差出人Ｘは、承認が必要と判定された電子メールについて、一人の代表承認者を選定する。

代表承認者が選択されると、サーバ１０は、代表承認者に対して、承認要求メールを通知する。例えば、代表承認者がユーザＡであるとすると、サーバ１０は、代表承認者Ａの端末に、承認要求メールを通知する。

サーバ１０は、最も早く承認者から指示を受信したタイミングで、その指示に従い電子メールを配送又は配送中止する。例えば、サーバ１０は、承認者Ａ、Ｂ、Ｃのうち承認者Ａ（代表承認者Ａ）から最も早く承認指示を受け付けた場合、代表承認者Ａから承認指示を受け付けたタイミングに、電子メールを配送する。一方、サーバ１０は、承認者Ａ、Ｂ、Ｃのうち承認者Ａ（代表承認者Ａ）から最も早く否認指示を受け付けた場合、代表承認者Ａから否認指示を受け付けたタイミングに、電子メールの配送を中止する制御を行う。なお、配送を中止するとは、電子メールの配送を禁止することを意味する。サーバ１０は、配送を中止された電子メールデータそのものについて削除してもよい。

つまり、サーバ１０は、複数の承認者のうち承認者から最も早く受け取った指示を優先的に適用し、当該指示が承認指示である場合には、電子メールを配送し、当該指示が否認指示である場合には電子メールの配送を中止する。

このように本実施形態によれば、代表承認者Ａが主として積極的に承認指示或いは否認指示を行う役割となり、承認者Ｂ、Ｃは、代表承認者Ａが何等かの理由で承認指示或いは否認指示を行うことができない場合に、代わりに承認指示或いは否認指示を行う補助的な役割となる。つまり、承認者Ｂ、Ｃは補助的な役割であるため自身の業務に専念できる。

特に、近年の電子メールの利用は多く、承認待ちのメールが大量にある場合に、承認者は保留中の各電子メールを裁くことに時間を要することが多い。本実施形態によれば、代表承認者に特化して承認または否認の指示を積極的に行う役割を担うようにしたので、各承認者は役割を意識して効率よく自身の業務に専念することができる。

３．承認の要否判定処理
サーバ１０は、所定の条件に基づいて電子メールの承認の要否を判定する。例えば、本実施形態では、電子メールのエンベロープの宛先（エンベロープＴｏ）、エンベロープの差出元（エンベロープＦｒｏｍ）、電子メールのメッセージのヘッダ、メッセージのボディの少なくとも一つを参照して承認の要否を判定する。

ここで、電子メールのエンベロープとは、ＳＭＴＰセッションにおいて、端末（ＭＵＡ
）がサーバに対して送信する宛先（エンベロープＴｏ）と、差出元（エンベロープＦｒｏｍ）である。つまり、サーバが電子メールを配送する際に使用するメールアドレスである。なお、エンベロープＴｏは、電子メールのメッセージデータに含まれるヘッダのＴｏ、Ｃｃ、Ｂｃｃと異なる情報となることもあり、エンベロープＦｒｏｍは、電子メールのメッセージデータに含まれるヘッダのＦｒｏｍと異なる情報となることもある。

例えば、本実施形態では、エンベロープの宛先が外部メールアドレスであること（エンベロープの宛先が組織外であること）を所定の条件の一例とし、エンベロープの宛先が外部メールアドレスである場合（エンベロープの宛先が組織外である場合）に、承認を必要と判定し、エンベロープの宛先が内部メールアドレスである場合（エンベロープの宛先が組織内である場合）に、承認を不要と判定する。

本実施形態のサーバは、エンベロープの宛先のメールアドレスのドメインが、予め登録されたネットワークシステム（組織内、社内システム）のドメイン（又はサブドメイン）ではない場合、当該メールアドレスを「外部メールアドレス」として判定する。

また、本実施形態のサーバは、エンベロープの宛先のメールアドレスのドメインが、予め登録されたネットワークシステム（組織内、社内システム）ドメイン（又はサブドメイン）である場合、当該メールアドレスを「内部メールアドレス」として判定する。

具体的に説明すると、サーバ１０は、予め登録されたネットワークシステムのドメインが「ｘｘｘ．ｎｅ．ｊｐ」である場合に、電子メールの宛先のメールアドレスが「ａｂｃ＠ｙｙｙ．ｃｏｍ」である場合には、「ａｂｃ＠ｙｙｙ．ｃｏｍ」は外部メールアドレスであるので承認が必要であると判定する。一方、宛先のメールアドレスが「ｄｅｆ＠ｘｘｘ．ｎｅ．ｊｐ」である場合には、「ｄｅｆ＠ｘｘｘ．ｎｅ．ｊｐ」は内部メールアドレスであるので承認が不要であると判定する。

つまり、サーバ１０は、電子メールのエンベロープの宛先のドメインが予め登録されたネットワークシステムのドメインか否かを判断し、電子メールのエンベロープの宛先のドメインが予め登録されたネットワークシステムのドメインである場合には承認不要（保留不要）と判断し、当該宛先への電子メールを即時配送する処理を行い、電子メールのエンベロープの宛先のドメインが予め登録されたネットワークシステムのドメインでない場合には当該宛先への電子メールの承認が必要となり配送を保留する。

本実施形態のサーバ１０は、保留された電子メールのデータを記憶部１７０の保留メール格納領域１７３に記憶する処理を行っている。

また、本実施形態のサーバ１０は、承認者の承認が必要な保留メールは、少なくとも一の承認者から承認指示又は否認指示が得られるまで永続的に保留メール格納領域に保存される。

なお、サーバ１０は、承認の要否を判定するための所定の条件を種々設定可能である。例えば、電子メールのメッセージのヘッダ、メッセージのボディに所定の文字列（例えば、「社外秘」などの文字列）がある場合を所定の条件と設定してもよいし、添付ファイルが存在する場合を所定の条件としてもよい。例えば、サーバ１０は、管理者又はユーザからの入力情報に基づいて、承認の要否を判定するための所定の条件を決めて制御する。

４．代表承認者の選択
サーバ１０は、電子メールの承認が必要と判定された場合に、差出元のユーザＸから、複数の承認者Ａ、Ｂ、Ｃのうちの一の代表承認者の選択を受け付ける。

例えば、サーバ１０は、図３に示すように、ユーザ毎に差出元のユーザＩＤに対応付けて予め複数の承認者ユーザＩＤを記憶する。このようにすれば、差出人は承認者を決める手間を取らせないようにすることができる。また、本実施形態では複数の承認者を決めることにより、一の承認者が何らかの理由で承認の認否ができない場合でも他の承認者が認否できるようにしている。

図４は、差出元のユーザＸが代表承認者を選択するための電子メール（通知メール）６０の一例を示す。差出元のユーザＸは、電子メール６０において、各承認者に対応付けられたＵＲＬ６５Ａ、６５Ｂ、６５Ｃのいずれかをクリックすることによって代表承認者を選択できる。なお、当該通知メールをＷｅｂメールとして閲覧可能としてもよい。また、サーバ１０は、差出元のユーザＸの端末２０のＷｅｂブラウザ等を用いて、ユーザＸが代表承認者を選択するための選択画面を表示するように制御してもよい。なお、ＵＲＬ６５Ａ、６５Ｂ、６５Ｃをボタンによって表示するようにしてもよい。

代表承認者を選択するための電子メール６０では、保留された電子メールで代表承認者の選択が必要であることを示す情報６１、保留メールＩＤ６２、保留された電子メールのメッセージの内容６３、代表承認者を選択するための情報６４が含まれる。なお、電子メール６０に、保留日時を含むようにしてもよい。

また、代表承認者を選択するための電子メール６０は、差出人Ｘに対応付けられた複数の承認者（例えば、Ａ、Ｂ、Ｃ）それぞれに対応するＵＲＬ６５Ａ、６５Ｂ、６５Ｃを含む。サーバ１０は、保留された電子メールの識別情報（例えば、保留メールＩＤ＝００１）と、承認者ＩＤとに基づき各承認者のＵＲＬを作成する。

差出人Ｘは、代表承認者にしたいユーザのＵＲＬをクリックすることによって選択することができる。サーバ１０は、ユーザＸからのＵＲＬ６５Ａ、６５Ｂ、６５Ｃのうちのいずれかのアクセスに基づき、いずれのユーザが代表承認者として選択されたのかを判別することができる。

例えば、サーバ１０は、ＵＲＬ６５Ａからのアクセスを検出した場合、アクセス内容に基づき、保留された電子メールの保留メールＩＤと当該保留メールで選択された承認者を特定することが可能となる。

サーバ１０は、保留メール毎に、保留メールＩＤに対応付けて、各承認者のユーザＩＤと、一名の代表承認者のユーザＩＤとを記憶して管理する。

５．承認要求メールの通知
５．１ 承認要求メールの説明
本実施形態のサーバ１０は、代表承認者の選択を受け付けた場合に、代表承認者に承認要求メールを通知する処理を行う。つまり、代表承認者に承認要求メールを通知（送信）することによって、保留された電子メールについて、少なくとも代表承認者に対して承認指示又は否認指示する機会を確実に与えることにしている。なお、サーバ１０は、代表承認者の選択を受け付けた日時を、当該代表承認者に対する承認要求の発生日時とする。

図５は、承認要求メール７０の一例を示す。本実施形態のサーバ１０が管理する各ユーザは、自身が代表承認者として選択された場合に、承認指示又は否認指示を行う必要がある。

例えば、ユーザＡが、ユーザＸから代表承認者として選択された場合、ユーザＡはユー
ザＸの電子メールの承認指示又は否認指示を速やかに行う必要がある。つまり、ユーザＸが記載した電子メールの内容に問題なければ速やかに承認指示を行って宛先に送信すべきであるし、当該電子メールの内容に問題があれば、ユーザＸに早めに否認指示を行いユーザＸの業務が滞ることがないようにすべきである。

本実施形態のサーバ１０は、代表承認者のユーザ名（ユーザＡ自身が代表承認者であることを示すメッセージ）７１、差出人Ｘの電子メールの保留メールＩＤ７２、保留された電子メールの内容７３、承認指示又は否認指示を行う指示内容７４、他の承認者に関する情報７７を含む承認要求メール７０を生成する。なお、承認要求メール７０に、保留日時や承認要求の発生日時を含むようにしてもよい。

そして、サーバ１０は、生成した承認要求メール７０の宛先を、代表承認者Ａのメールアドレス（差出人は、サーバ１０の管理者或いはシステム名等）に指定して、当該承認要求メール７０を代表承認者Ａの端末に通知（送信）する。

なお、サーバ１０は、承認要求メール７０をＷｅｂメールとして閲覧可能としてもよい。

また、承認要求メール７０は、承認指示に対応するＵＲＬ７５、否認指示に対応するＵＲＬ７６を含む。サーバ１０は、保留された電子メールの識別情報（例えば、保留メールＩＤ＝００１）、承認者のユーザＩＤ及び承認指示を識別する情報等に基づき承認指示に対応するＵＲＬ７５を作成する。保留された電子メールの識別情報（例えば、保留メールＩＤ＝００１）、承認者のユーザＩＤ及び否認指示を識別する情報等に基づき否認指示に対応するＵＲＬ７６を作成する。

そして、図５に示すように、代表承認者であるユーザＡは、保留された電子メールについて承認を行う場合は承認指示のＵＲＬ７５をクリックする。一方、ユーザＡは、保留された電子メールについて否認指示を行う場合は否認指示のＵＲＬ７６をクリックする。

サーバ１０は、ユーザＡからのＵＲＬのアクセスに基づき、承認指示又は否認指示のいずれであったのかを判別することができる。

例えば、サーバ１０は、ＵＲＬ７５からのアクセスを検出した場合、アクセス内容に基づき、保留された電子メールの保留メールＩＤ、承認者及び承認指示の情報を特定することが可能となる。また、サーバ１０は、ＵＲＬ７６からのアクセスを検出した場合、アクセス内容に基づき、保留された電子メールの保留メールＩＤ、承認者及び否認指示の情報を特定することが可能となる。

なお、サーバ１０は、最先のアクセスを優先的に適用するので、同一人物の承認者Ａから承認指示のＵＲＬ７５のアクセスを受け付けた後に、否認指示のＵＲＬ７６のアクセスを受け付けた場合、承認指示を優先的に適用する。

また、承認要求メール７０には、他の承認者（例えば、ユーザＢ、Ｃ）に関する情報７７が含まれるので、代表承認者Ａは、自身の他にユーザＢ、Ｃが承認者として存在していることを認識することができる。

５．２ 代表承認者の変更
本実施形態のサーバ１０は、代表承認者Ａから代表辞退を受け付けることが可能である。例えば、サーバ１０は、代表承認者Ａから、承認者であるユーザＢのＵＲＬ７８、承認者であるユーザＣのＵＲＬ７９のいずれかのアクセスを検出した場合に、ユーザＡから代
表辞退を受け付ける。

なお、承認者Ｂを示すＵＲＬ７８は保留された電子メールの識別情報（例えば、保留メールＩＤ＝００１）、承認者ＢのユーザＩＤ及び代表者変更を識別する情報等に基づき作成され、承認者Ｃを示すＵＲＬ７９は保留された電子メールの識別情報（例えば、保留メールＩＤ＝００１）、承認者ＣのユーザＩＤ及び代表者変更を識別する情報等に基づき作成される。

そして、サーバ１０は、ＵＲＬ７８のアクセスを検出することによって代表承認者Ａから、承認者Ｂの選択を受け付けた場合、承認者Ｂを新たな代表承認者とする。そして、サーバ１０は、当該代表承認者Ｂに対して承認要求メールを通知する。一方、サーバ１０は、ＵＲＬ７９のアクセスを検出することによって代表承認者Ａから、承認者Ｃの選択を受け付けた場合、承認者Ｃを新たな代表承認者とする。そして、サーバ１０は、当該代表承認者Ｃに対して承認要求メールを通知する。

このようにすれば、代表承認者Ａが多忙である場合等、何等かの理由で代表を辞退したい場合に代表辞退が可能となる。また、代表辞退があった場合は、新たな代表承認者が選ばれ、新たな代表承認者に承認要求を通知するので、保留された電子メールを滞りなく速やかに承認又は否認の指示を行うための機会を与えることができる。

なお、サーバ１０は、保留メール（保留メールＩＤ＝００１）の代表承認者が例えばユーザＡからユーザＢに変更された場合には、代表承認者がユーザＡからユーザＢに変更されたことを示す情報等を本文とし、差出元のユーザＸを宛先とする電子メールを作成して、当該電子メールをユーザＸに通知してもよい。

サーバ１０は、保留メール（保留メールＩＤ＝００１）の代表承認者が例えばユーザＡからユーザＢに変更された場合において、当該ユーザＢに送信した承認要求メールの他の承認者に関する情報７７において、新たな代表承認者としてユーザＡが選択されないように制御してもよい。つまり、既に代表承認者であった（辞退した）承認者を選択対象外とするように制御する。例えば、新たな代表承認者Ｂが閲覧する承認要求メールの他の承認者欄７７において、ユーザＡのＵＲＬを表示せずに、ユーザＡの名前のみを表示する。なお、当該承認要求メールの他の承認者欄７７において、代表者変更可能なユーザＣについてはＵＲＬ７９を表示するように制御する。

６．承認指示又は否認指示の受け付け
サーバ１０は、代表承認者Ａから、保留された電子メールについての承認指示又は否認指示を受け付けるが、代表承認者Ａ以外の承認者Ｂ、Ｃから、承認指示又は否認指示を受け付けることもできる。

つまり、本実施形態では、電子メールの各承認者Ａ、Ｂ、Ｃそれぞれが、サーバ１０にログインして指示受け付け画面を閲覧して承認指示又は否認指示を行うことができる。

本実施形態の代表承認者Ａは、承認要求メールから指示を行うこともできるし、指示画面によって指示を行うこともできる。一方、代表承認者Ａでない承認者Ｂ、Ｃは、端末において承認要求メールを受信しないため、自らサーバ１０にログインして指示受け付け画面によってのみ指示を行うことになる。

６．１ 承認待ち電子メールの一覧画面
図６は、承認者Ａ、Ｂ、Ｃそれぞれの承認待ちの電子メールの一覧画面８１Ａ、８１Ｂ、８１Ｃの一例を示す。

図６の例では、サーバ１０にログインした承認者Ａの端末２０に表示される一覧画面８１Ａでは、差出人Ｘ（ｘｘｘ＠ｘｘｘ．ｎｅ．ｊｐ）が送信した電子メール（保留メールＩＤ＝００１の電子メール）だけでなく、他の電子メールも承認待ちとして表示されている。なお、サーバ１０にログインした承認者Ｂの端末２０に表示される一覧画面８１Ｂ、サーバ１０にログインした承認者Ｃの端末２０に表示される一覧画面８１Ｃにおいても、差出人Ｘ（ｘｘｘ＠ｘｘｘ．ｎｅ．ｊｐ）が送信した電子メール（保留メールＩＤ＝００１の電子メール）の他に、他の電子メールも承認待ちとして表示されている。

例えば、図６に示すように、承認者Ａが差出人「ｘｘｘ＠ｘｘｘ．ｎｅ．ｊｐ」の電子メール（保留メールＩＤ＝００１の電子メール）について検討ボタン８３Ａをクリックすると、サーバ１０は、当該電子メールの選択を受け付け、当該電子メールの指示受け付け画面を、承認者Ａの端末２０に表示するように制御する。

また、図６に示すように、サーバ１０は、一覧画面において各承認待ちの電子メールの代表承認者（代表承認者のユーザ名、ユーザＩＤ、略称、マーク等）、他の承認者の「閲覧状況」を表示する。閲覧状況については後述する。

６．２ 指示受け付け画面
承認者Ａ、Ｂ、Ｃそれぞれの指示受け付け画面には、一の承認待ちの電子メールの内容が表示される。

図７は、承認者Ａの端末２０に表示される指示受け付け画面９０の一例を示す。例えば、サーバ１０は、代表承認者のユーザ名９１、差出人Ｘの電子メールの保留メールＩＤ９２、保留された電子メールの内容９３、承認指示又は否認指示を行うための指示内容９４、他の承認者の閲覧状況９７、を含む指示受け付け画面９０を生成する。なお、指示受け付け画面９０に、保留日時を含むようにしてもよい。

また、サーバ１０は、保留された電子メールの識別情報（例えば、保留メールＩＤ＝００１）と、承認者のユーザＩＤ及び承認指示を識別する情報とに基づき承認指示に対応するＵＲＬ９５を作成する。保留された電子メールの識別情報（例えば、保留メールＩＤ＝００１）と、承認者のユーザＩＤ及び否認指示を識別する情報とに基づき否認指示に対応するＵＲＬ９６を作成する。

例えば、図７に示すように、承認者であるユーザＡは、保留された電子メールについて承認を行う場合は承認指示のＵＲＬ９５をクリックする。一方、ユーザＡは、保留された電子メールについて否認指示を行う場合は否認指示のＵＲＬ９６をクリックする。

サーバ１０は、ユーザＡからのＵＲＬのアクセスに基づき、承認指示又は否認指示のいずれであったのかを判別することができる。

例えば、サーバ１０は、ＵＲＬ９５からのアクセスを検出した場合、アクセス内容に基づき、保留された電子メールの保留メールＩＤ、承認者及び承認指示の情報を特定することが可能となる。また、サーバ１０は、ＵＲＬ９６からのアクセスを検出した場合、アクセス内容に基づき、保留された電子メールの保留メールＩＤ、承認者及び否認指示の情報を特定することが可能となる。

また、他の承認者Ｂは、図６に示す一覧画面８１Ｂの検討ボタンをクリックすることによって、承認待ちの各電子メールの指示受け付け画面を閲覧することができ、承認指示又は否認指示することができる。また、他の承認者Ｃは、図６に示す一覧画面８１Ｃの検討
ボタンをクリックすることによって、承認待ちの各電子メールの指示受け付け画面を閲覧することができ、承認指示又は否認指示することができる。

なお、指示受け付け画面９０の各ＵＲＬ９５、９６をボタンによって表示するようにしてもよい。

また、サーバ１０は、承認要求メールの承認指示のＵＲＬ７５、否認指示のＵＲＬ７６、及び、指示受け付け画面の各承認者の承認指示のＵＲＬ９５、否認指示のＵＲＬ９６のうち、最先のアクセスを優先的に適用する。

つまり、サーバ１０は、同一の電子メール（例えば、保留メールＩＤ＝００１）について最先のアクセスを検出した場合、アクセス内容に基づき、特定された指示を優先適用する。また、承認者の混乱を避けるため、電子メール（例えば、保留メールＩＤ＝００１）最先の指示（承認指示又は否認指示）を受け付けた後、当該電子メール（例えば、保留メールＩＤ＝００１）を一覧画面から削除するように制御する。

６．３ 閲覧状況
サーバ１０は、承認待ちの電子メールについて、他の承認者が指示受け付け画面を閲覧していることを示す閲覧状況を、一覧画面及び指示受け付け画面の少なくとも一方に表示する。

また、サーバ１０は、他の承認者の閲覧状況に応じて、他の承認者が閲覧中の電子メールの閲覧を禁止してもよい。例えば、サーバ１０は、承認者Ａが保留メールＩＤ＝００１の電子メールを閲覧中である場合、承認者Ａの後にログインした承認者Ｂの一覧画面又は指示受け付け画面において、保留メールＩＤ＝００１の電子メールの閲覧を禁止してもよい。

また、サーバ１０は、他の承認者の閲覧状況に応じて、他の承認者が閲覧中の閲覧のみを行わせ、承認指示及び否認指示を行わせないように制御してもよい。例えば、サーバ１０は、承認者Ａが保留メールＩＤ＝００１の電子メールを閲覧中である場合、承認者Ａの後にログインした承認者Ｂの一覧画面又は指示受け付け画面において、保留メールＩＤ＝００１の電子メールの閲覧のみを行わせ、承認指示のＵＲＬ及び否認指示のＵＲＬを非表示にし、承認指示及び否認指示を禁止するように制御してもよい。

ここで「閲覧状況」とは、他の承認者が指示受け付け画面を閲覧していることを意味し、例えば、他の承認者が、当該他の承認者がログインした指示受け付け画面を閲覧している場合に、一の承認者の一覧画面又は指示受け付け画面の少なくとも一方において、当該他の承認者を示すマークを赤色で表示する。一方、当該他の承認者がログインした指示受け付け画面を閲覧していない場合に、一の承認者の一覧画面又は指示受け付け画面の少なくとも一方において、当該他の承認者を示すマークを白色で表示する。

なお、「閲覧状況」は、色によって識別するマークでなくてもよい。例えば、「閲覧状況」は、他の承認者に対応付けて閲覧の有無を示すメッセージ（「閲覧しています」又は「閲覧していません」などのメッセージ）でもよい。

例えば、サーバ１０は、代表承認者Ａが閲覧する一覧画面８１Ａにおいて、一覧画面８１Ａの表示タイミング（又はリアルタイム）に、他の承認者Ｂ、Ｃが指示受け付け画面（他の承認者が閲覧する指示受け付け画面）を閲覧しているか否かを判断する。そして、承認者Ｂが指示受け付け画面を閲覧している場合に、承認者Ｂを示すマークを赤色で表示し、承認者Ｂが指示受け付け画面を閲覧していない場合に、承認者Ｂを示すマークを白色で
表示する。承認者Ｃについて同様に承認者Ｃの閲覧有無に基づきマークの表示色を決定する。

図６の例では、承認者Ａの一覧画面８１Ａにおいて、差出人「ｘｘｘ＠ｘｘｘ．ｎｅ．ｊｐ」の電子メール（例えば、保留メールＩＤ＝００１）について、「他の承認者の閲覧状況」の欄においてユーザＢのマークが白色で表示され、ユーザＣのマークが白色で表示されており、ユーザＢ及びユーザＣ共に指示受け付け画面を閲覧していないことを示している。したがって、承認者Ａに対して、当該電子メールについて指示を行うよう促すことができる。

また、承認者Ｂの一覧画面８１Ｂにおいて、差出人「ｘｘｘ＠ｘｘｘ．ｎｅ．ｊｐ」の電子メール（例えば、保留メールＩＤ＝００１）について、「他の承認者の閲覧状況」の欄において、ユーザＡのマークが赤色表示されており、ユーザＡが承認者として閲覧していることを示している。また、ユーザＣのマークが白色で表示されており、ユーザＣが指示受け付け画面を閲覧していないことを示している。したがって、承認者Ｂに対して、当該電子メールは指示を行わないようにし、例えば、ユーザＢ自身が代表承認者であり、誰も閲覧していない保留メールＩＤ＝００３の電子メールについて、指示を行うよう促すことができる。

また、承認者Ｃの一覧画面８１Ｃにおいて、差出人「ｘｘｘ＠ｘｘｘ．ｎｅ．ｊｐ」の電子メール（例えば、保留メールＩＤ＝００１）について、「他の承認者の閲覧状況」の欄において、ユーザＡのマークが赤色表示されており、ユーザＡが承認者として閲覧していることを示している。また、ユーザＢのマークが白色で表示されており、ユーザＢが指示受け付け画面を閲覧していないことを示している。したがって、承認者Ｃに対して、当該電子メールは指示を行わないように促すことができる。なお、承認者Ｃは、承認待ちメールについて全て他の承認者が閲覧している状況となっており、承認者Ｃ自身が指示すべき承認待ちの電子メールは今のところ存在しないので、自身の他の業務に専念するよう働きかけることができる。

また、サーバ１０は、各承認者の指示受け付け画面において、他の承認者の閲覧状況を表示してもよい。例えば、サーバ１０は、代表承認者Ａが閲覧する指示受け付け画面９０において、指示受け付け画面９０の表示タイミング（又はリアルタイム）に、他の承認者Ｂ、Ｃが自身でログインした指示受け付け画面を閲覧しているか否かを判断する。そして、承認者Ｂが指示受け付け画面を閲覧している場合に、承認者Ｂを示すマークを赤色で表示し、承認者Ｂが指示受け付け画面を閲覧していない場合に、承認者Ｂを示すマークを白色で表示する。承認者Ｃについて同様に承認者Ｃの閲覧有無に基づきマークの表示色を決定する。

例えば、図７に示すように、承認者Ａが閲覧する指示受け付け画面９０の他の承認者の閲覧状況９７において、ユーザＢが閲覧していないことを示す白色のマーク９８、ユーザＣが閲覧していないことを示す白色のマーク９９を表示する。

このように、本実施形態によれば、他の承認者の閲覧状況を表示することによって、複数の承認者の指示に伴う作業がかち合うことを避けることができ、電子メールの承認に伴うビジネス上の支障を極力減らすことができ、効率的な承認或いは否認の指示を可能とすることができる。

６．４ 代表承認者の変更
本実施形態のサーバ１０は、一覧画面や指示受け付け画面においても、代表承認者の変更を行えるように制御してもよい。

例えば、図６に示すように、代表承認者Ａが閲覧する一覧画面８１Ａにおいて、代表承認者Ａから、承認者であるユーザＢのマーク９８、承認者であるユーザＣのマーク９９のいずれかのアクセスを検出した場合に、ユーザＡから代表辞退を受け付ける。

また、図７に示すように、代表承認者Ａが閲覧する指示受け付け画面９０において、代表承認者Ａから、承認者であるユーザＢのマーク９８、承認者であるユーザＣのマーク９９のいずれかのアクセスを検出した場合に、ユーザＡから代表辞退を受け付ける。

なお、承認者Ｂを示すマーク９８は、ＵＲＬにリンクされたボタン（ハイパーリンク）であり、保留された電子メールの識別情報（例えば、保留メールＩＤ＝００１）、承認者ＢのユーザＩＤ及び代表者変更を識別する情報等に基づき作成される。また、承認者Ｃを示すマーク９９は、ＵＲＬにリンクされたボタン（ハイパーリンク）であり、保留された電子メールの識別情報（例えば、保留メールＩＤ＝００１）、承認者ＣのユーザＩＤ及び代表者変更を識別する情報等に基づき作成される。

そして、サーバ１０は、一覧画面８１Ａ又は指示受け付け画面９０において、マーク９８によるアクセスを検出することによって代表承認者Ａから、承認者Ｂの選択を受け付けた場合、承認者Ｂを新たな代表承認者とする。そして、サーバ１０は、当該代表承認者Ｂに対して承認要求メールを通知する。一方、サーバ１０は、マーク９９によるアクセスを検出することによって代表承認者Ａから、承認者Ｃの選択を受け付けた場合、承認者Ｃを新たな代表承認者とする。そして、サーバ１０は、当該代表承認者Ｃに対して承認要求メールを通知する。

なお、サーバ１０は、一覧画面や指示受け付け画面において、保留メール（保留メールＩＤ＝００１）の代表承認者が例えばユーザＡからユーザＢに変更された場合においても、代表承認者がユーザＡからユーザＢに変更されたことを示す情報を本文とし、差出元のユーザＸを宛先とする電子メールを作成して、当該電子メールをユーザＸに通知してもよい。

サーバ１０は、保留メール（保留メールＩＤ＝００１）の代表承認者が例えばユーザＡからユーザＢに変更された場合において、各承認者Ａ、Ｂ、Ｃが閲覧する一覧画面又は指示受け付け画面において、新たな代表承認者としてユーザＡが選択されないように制御してもよい。つまり、既に代表承認者であった（辞退した）承認者Ａを選択対象外とするように制御する。例えば、新たな代表承認者Ｂが閲覧する一覧画面８１Ｂにおいて、ユーザＡのマークを、ＵＲＬにリンクしないようにし、ユーザＡの名前が識別できるマークのみを表示する。なお、代表者変更可能なユーザＣについてはＵＲＬにリンクするマーク９９を表示するように制御する。

７．保留された電子メールの配送又は配送中止の制御
本実施形態のサーバ１０は、承認者の指示に基づき、保留された電子メールの配送又は配送中止の制御を行う。つまり、サーバ１０は、複数の承認者のうちの一の承認者から最先に受け付けた指示（最も早く受け取った承認指示又は否認指示）に基づき、その指示に従って配送又は配送中止の制御を行う。例えば、複数の承認者Ａ、Ｂ、Ｃのうち最先に指示を受け付けたユーザが承認者Ａである場合、承認者Ａの指示に基づき配送又は配送中止の制御を行う。また、複数の承認者Ａ、Ｂ、Ｃのうち最先に指示を受け付けたユーザが承認者Ｂである場合、承認者Ｂの指示に基づき配送又は配送中止の制御を行う。また、複数の承認者Ａ、Ｂ、Ｃのうち最先に指示を受け付けたユーザが承認者Ｃである場合、承認者Ｃの指示に基づき配送又は配送中止の制御を行う。

例えば、サーバ１０は、差出人Ｘの端末から送信された電子メールについて、承認が必要で保留された場合に、保留された保留メールＩＤ＝００１の当該電子メールについて承認者Ａ，Ｂ，Ｃの中で承認者Ａから最も早く指示を受け付けたとする。かかる場合、承認者Ａの指示が承認指示である場合に、当該保留メールＩＤ＝００１の電子メールを配送し、承認者Ａの指示が否認指示である場合に、当該保留メールＩＤ＝００１の電子メールの配送を中止する。そして、サーバ１０は、指示受け付け後、当該保留メールＩＤ＝００１の電子メールについて、各承認者Ａ、Ｂ、Ｃの一覧画面から、指示済の当該電子メールを削除する。なお、サーバ１０は、いずれの承認者からも指示を受け付けていない場合、保留メールＩＤ＝００１の電子メールについては当該保留が維持される。

また、サーバ１０は、一の承認者の承認指示又は否認指示に基づき、保留中の電子メールが配送又は配送中止された場合には、当該電子メールが配送又は配送中止されたことを示す情報を、差出人Ｘに通知する。また、サーバ１０は、保留メールＩＤ＝００１の電子メールについて承認者Ａから最先に承認指示又は否認指示を受け付けた場合に、他の承認者Ｂ、Ｃの宛先に、当該保留メールＩＤ＝００１の電子メールについて承認者Ａから指示を受け付けたことを示す情報を、通知（例えば、通知メール等）する処理を行ってもよい。

なお、図示していないが、本実施形態のサーバ１０は、保留メールの処理の履歴を保存している。つまり、保留処理がなされた電子メールの識別情報に対応づけて、その電子メールの状態を履歴として保存する。電子メールの状態は、承認者からの承認指示に基づいて配送された「配送」、承認者からの否認指示に基づいて配送中止された「配送中止」、承認待ち状態の「承認待ち」がある。なお、サーバ１０は、承認者から指示（承認指示又は否認指示）に基づいて配送又は配送中止された保留メールについて履歴ＤＢ１７４に格納し、差出人や承認者が後で保留メールを確認できるように制御してもよい。

８．フローチャート
図８Ａ、図８Ｂを用いて本実施形態のサーバ１０の処理の流れについて説明する。まず、図８Ａに示すように、電子メールを受け付ける（ステップＳ１）。そして、承認が必要か否かを判定し（ステップＳ２）、承認が必要である場合（ステップＳ２のＹ）、電子メールを保留し（ステップＳ３）、差出人から代表承認者の選択を受け付ける（ステップＳ４）。そして、代表承認者に承認要求を通知する（ステップＳ５）。

一方、承認が不要である場合（ステップＳ２のＮ）、電子メールを配送する（ステップＳ６）。

そして、図８Ｂに示すように、ステップＳ５の後、承認者から指示を受け付けたか否かを判定し（ステップＳ１１）、承認者から指示を受け付けた場合（ステップＳ１１のＹ）、承認者の指示が、承認指示であるか否かを判定する（ステップＳ１２）。なお、承認者から指示を受け付けるまで電子メールの保留状態は維持される。

承認者の指示が、承認指示である場合（ステップＳ１２のＹ）、電子メールの配送を行う（ステップＳ１３）。一方、承認者の指示が、承認指示でない場合、つまり、承認者の指示が否認指示である場合、（ステップＳ１２のＮ）、電子メールの配送を中止する（ステップＳ１４）。以上で処理を終了する。

９．応用例
９．１ 複数の宛先が指定された同一内容の電子メール
本実施形態のサーバ１０は、差出人Ｘの端末２０から受け付けた同一内容の電子メールに対して複数の宛先が指定されている場合、宛先毎に所定の条件を満たすか否かを判断し
、所定の条件を満たす場合に、承認が必要であると判定する。

例えば、エンベロープの宛先が外部メールアドレスであること（エンベロープの宛先が組織外であること）を所定の条件の一例とする場合、次のように処理する。つまり、図９に示すように、サーバ１０は、差出人Ｘから受け付けた同一内容の電子メールに対して、外部メールアドレスであるユーザＪの宛先（ｊｊｊ＠ｙｙｙ．ｃｏｍ）、及び、内部メールアドレスであるユーザＫの宛先（ｋｋｋ＠ｘｘｘ．ｎｅ．ｊｐ）と内部メールアドレスであるユーザＮの宛先（ｎｎｎ＠ｘｘｘ．ｎｅ．ｊｐ）が指定されている場合、ユーザＫ宛て及びユーザＮ宛てに対して即時配送し、ユーザＪ宛てについては承認が必要であるとして保留する。かかる場合において、本実施形態では、電子メール配送済みのユーザＫ及びユーザＮを承認者としてもよい。例えば、差出人Ｘに対応付けられた承認者がユーザＡ、Ｂ、Ｃであるとすると、ユーザＡ、Ｂ、Ｃに加えてユーザＫ、Ｎも承認者としてもよい。また、差出人Ｘに対応付けられた承認者Ａ、Ｂ、Ｃに代えて、ユーザＫ、Ｎの二人を差出人Ｘの承認者にしてもよい。このようにすれば、差出人Ｘは、電子メールの内容を熟知している配送済みのユーザＫ或いはユーザＮを代表承認者に選択することができるメリットがある。

なお、本実施形態において、同一内容の電子メールとは、電子メールの本文と特定のヘッダ（例えば、ヘッダのＳｕｂｊｅｃｔ、Ｄａｔｅ、Ｆｒｏｍ、及び、Ｔｏ）が同じであることを意味する。

９．２ メーリングリストを宛先とする例
本実施形態では、電子メールの宛先にメーリングリストの宛先を指定されることがあるが、本実施形態では、メーリングリストの宛先、又は、メーリングリストに属する参加者の宛先毎に保留の要否を判断してもよい。

サーバ１０は、エンベロープの宛先がメーリングリストのメールアドレスである場合に、メーリングリスト機能（メーリングリストのサーバ（ＭＴＡ））によって、メーリングリストのメールアドレスを各参加者のメールアドレスに換えて配送することになる。

例えば、図１０に示すように、メーリングリストのメールアドレスが、「ｐａｔｅｎｔ＠ｘｘｘ．ｎｅ．ｊｐ」であり、当該メーリングリストの参加者のメールアドレスが、ユーザＫのメールアドレス「ｋｋｋ＠ｘｘｘ．ｎｅ．ｊｐ」、ユーザＮのメールアドレス「ｎｎｎ＠ｘｘｘ．ｎｅ．ｊｐ」とする場合、エンベロープの宛先「ｐａｔｅｎｔ＠ｘｘｘ．ｎｅ．ｊｐ」を、参加者のアドレス「ｋｋｋ＠ｘｘｘ．ｎｅ．ｊｐ」、「ｎｎｎ＠ｘｘｘ．ｎｅ．ｊｐ」に換えて配送する。

本実施形態では、メーリングリストの宛先「ｐａｔｅｎｔ＠ｘｘｘ．ｎｅ．ｊｐ」に基づいて承認の要否を判断してもよいし、メーリングリストに属する参加者の宛先毎（例えば、「ｋｋｋ＠ｘｘｘ．ｎｅ．ｊｐ」、「ｎｎｎ＠ｘｘｘ．ｎｅ．ｊｐ」の宛先毎）に承認の要否を判断してもよい。

つまり、メーリングリストの宛先「ｐａｔｅｎｔ＠ｘｘｘ．ｎｅ．ｊｐ」で承認要否を判断する場合、「ｐａｔｅｎｔ＠ｘｘｘ．ｎｅ．ｊｐ」は内部メールアドレスであるので「ｐａｔｅｎｔ＠ｘｘｘ．ｎｅ．ｊｐ」への電子メールについては承認不要と判定し、メーリングリストに属する参加者の宛先へ即時に配送を行う。

また、メーリングリストに属する参加者の宛先毎（例えば、「ｋｋｋ＠ｘｘｘ．ｎｅ．ｊｐ」、「ｎｎｎ＠ｘｘｘ．ｎｅ．ｊｐ」の宛先毎）に所定の条件を満たすか否かを判断し、所定の条件を満たす場合に、承認が必要であると判定する。

例えば、エンベロープの宛先が外部メールアドレスであること（エンベロープの宛先が組織外であること）を所定の条件の一例とする場合、「ｋｋｋ＠ｘｘｘ．ｎｅ．ｊｐ」、「ｎｎｎ＠ｘｘｘ．ｎｅ．ｊｐ」は内部メールアドレスであるので、「ｋｋｋ＠ｘｘｘ．ｎｅ．ｊｐ」、「ｎｎｎ＠ｘｘｘ．ｎｅ．ｊｐ」の宛先への電子メールについては所定の条件は満たさず、承認不要と判定し即時に配送を行う。

より具体的に説明すると、図１０に示すように、サーバ１０は、差出人Ｘから受け付けた電子メールに対して、外部メールアドレスであるユーザＪの宛先（ｊｊｊ＠ｙｙｙ．ｃｏｍ）、及び、メーリングリストのメールアドレスの宛先（ｐａｔｅｎｔ＠ｘｘｘ．ｎｅ．ｊｐ）が指定されている場合、メーリングリストの参加者のユーザＫ、Ｎのメールアドレスは、内部メールアドレスであるので、ユーザＫ宛て及びユーザＮ宛てに対して即時配送し、ユーザＪ宛てについては承認が必要であるとして保留する。かかる場合において、本実施形態では、電子メール配送済みのユーザＫ及びユーザＮを承認者としてもよい。例えば、差出人Ｘに対応付けられた承認者がユーザＡ、Ｂ、Ｃであるとすると、ユーザＡ、Ｂ、Ｃに加えてユーザＫ、Ｎも承認者としてもよい。また、差出人Ｘに対応付けられた承認者がユーザＡ、Ｂ、Ｃに替えて、ユーザＫ、Ｎの二人を差出人Ｘの承認者にしてもよい。このようにすれば、差出人Ｘは、電子メールの内容を熟知している配送済みのユーザＫ或いはユーザＮを代表承認者に選択することができるメリットがある。

９．３ 一括制御について
サーバ１０は、差出人Ｘの端末２０から受け付けた同一内容の電子メールに対して、所定の条件を満たす宛先が複数存在する場合がある。例えば、サーバ１０は、差出人Ｘから受け付けた同一内容の電子メールに対して、外部メールアドレスであるユーザＪの宛先（ｊｊｊ＠ｙｙｙ．ｃｏｍ）、ユーザＩの宛先（ｉｉｉ＠ｙｙｙ．ｃｏｍ）が指定されている場合、ユーザＩ宛て及び、ユーザＪ宛てについては承認が必要であるとして保留する。かかる場合において、差出人Ｘに対応付けられた承認者がユーザＡ、Ｂ、Ｃであるとし、サーバ１０が、差出人ＸからユーザＡを代表承認者として選択を受け付けた場合、ユーザＡに、ユーザＩ宛ての電子メール及びユーザＪ宛ての電子メールについて一括で承認要求を通知する。

また、サーバ１０は、承認要求について応答をする代表承認者Ａ（あるいは、他の承認者Ｂ、Ｃ）から、ユーザＩ宛ての電子メール及びユーザＪ宛ての電子メールについて一括で閲覧可能であり、ユーザＩ宛ての電子メール及びユーザＪ宛ての電子メールについて一括で承認または否認の指示を受け付けるようにしてもよい。

９．４ 代表承認者の選択の他の例
サーバ１０は、差出元のユーザＸからの代表承認者の選択を受け付けず、コンピュータ制御（ＣＰＵ制御）に基づき、自動的に代表承認者を選択してもよい。つまり、サーバ１０は、電子メールの承認が必要と判定された場合に、複数の承認者（差出元のユーザＸに対応付けられた複数の承認者）の行動情報に基づいて、当該複数の承認者のうちの一の代表承認者の選択を受け付ける。このようにすれば、差出元のユーザＸは、代表承認者を選択する手間を省くことができる。

サーバ１０は、次のようにして代表承認者を選択する。つまり、サーバ１０は、（Ａ）各承認者の出勤情報（出勤状況）、（Ｂ）各承認者の位置情報（在籍状況）、（Ｃ）各承認者のスケジュール情報（予定混み具合情報）の少なくとも１つの情報に基づいて、一の代表承認者を選択する。なお、サーバ１０は、外部のシステムによって各種情報を取得するようにしてもよい。例えば、サーバ１０は、出退勤システムによって出勤情報を取得し、位置情報システムによって位置情報を取得し、スケジュール管理システムによって、ス
ケジュール情報を取得するようにしてもよい。

まず、（Ａ）各承認者の出勤情報とは、少なくとも出勤の有無の判別可能な情報であり、出勤管理システム等によって把握される。例えば、サーバ１０は、電子メールの承認が必要と判定された時点で、承認者毎に出勤しているか否かを判定する。

また、（Ｂ）各承認者の位置情報とは、少なくとも社内、社外の判別可能な情報であり、各承認者のＧＰＳ情報や社内システムの人感センサ等によって把握される各承認者の位置情報等である。例えば、サーバ１０は、電子メールの承認が必要と判定された時点で、承認者毎に社内に位置するか否かを判定する。

また、（Ｃ）各承認者のスケジュール情報とは、承認者に対応付けて予め開始時刻と終了時刻とが予め決められた仕事の情報（打合せ、ミーティング等）である。例えば、サーバ１０は、電子メールの承認が必要と判定された時点を基準に所定期間内（例えば、１時間以内）に、承認者の中で最もスケジュール情報に空きのある承認者を１名判定する。

例えば、サーバ１０は、電子メールの承認が必要と判定された時点で、出勤している承認者が１名である場合、当該承認者を代表承認者として判定する。

例えば、サーバ１０は、電子メールの承認が必要と判定された時点で、出勤している承認者が２名以上いる場合、当該２名以上の承認者のうち社内に位置する承認者が１名である場合、社内に位置する１名の承認者を代表承認者として判定する。

例えば、サーバ１０は、電子メールの承認が必要と判定された時点で、出勤している承認者が不在であり、社内に位置する承認者が１名である場合、社内に位置する１名の承認者を代表承認者として判定する。

例えば、サーバ１０は、電子メールの承認が必要と判定された時点で電子メールの承認が必要と判定された時点で、出勤している承認者が２名以上いる場合や、社内に位置する承認者が２名以上いる場合、出勤している承認者の中から、あるいは、社内に位置する承認者の中から、電子メールの承認が必要と判定された時点を基準に所定期間内（例えば、１時間以内）に、最もスケジュール情報に空きのある１名の承認者を代表承認者として判定する。

なお、サーバ１０は、電子メールの承認が必要と判定された時点で、出勤している承認者が不在であり、かつ、社内に位置する承認者が不在である場合、電子メールの承認が必要と判定された時点を基準に所定期間内（例えば、１時間以内）に、最もスケジュール情報に空きのある１名の承認者を代表承認者として判定する。

また、サーバ１０は、ユーザ毎に予め承認要求を受け付けるか否かの設定を行い、承認要求を受け付けないユーザを、代表承認者の対象外とするように制御してもよい。なお、承認可否の判断を正確に行うために、差出人に対応付けて設定される複数の承認者のうち、承認要求を受け付けないユーザが存在する場合に、残りのユーザについては承認要求を受け付けるユーザとする。

なお、サーバ１０は、代表承認者がいない場合は、代表承認者がいない旨を差出元のユーザに提示してもよい。かかる場合、差出元のユーザから、複数の承認者のうちの一の代表承認者の選択を受け付けるように制御すればよい。

９．５ 代表承認者の候補の提示
本実施形態のサーバ１０は、電子メールの承認が必要と判定された場合に、差出元のユーザから複数の承認者のうちの一の代表承認者の選択を受け付ける例について説明したが、一の代表承認者の選択を受け付ける前に、複数の承認者のうちの一の代表承認者候補を差出元のユーザに提示してもよい。

例えば、サーバ１０は、差出元のユーザＸが代表承認者を選択するための通知メール６０において、複数の承認者Ａ、Ｂ、Ｃのうち最適な一の代表承認者候補を提示する。例えば、代表承認者候補がユーザＡである場合、通知メール６０の代表承認者の選択欄６４において、「最適な代表承認者候補はユーザＡです」というようなメッセージを加える。このようにすれば、差出元のユーザＸは選択すべき代表承認者を容易に決めることができる。

サーバ１０が代表承認者候補を抽出する手法は、上述したコンピュータ制御（ＣＰＵ制御）に基づき自動的に代表承認者を選択する手法と同様である。つまり、サーバ１０は、複数の承認者の行動情報に基づいて、当該複数の承認者の中から一の代表承認者候補を抽出する。

なお、サーバ１０は、代表承認者候補がいない場合は、代表承認者候補がいない旨を差出元のユーザに提示してもよい。

また、サーバ１０は、コンピュータによって自動的に代表承認者を選択する際に代表承認者がいない場合は、差出元のユーザによって複数の承認者の中から一の承認者を代表承認者として選択させるようにしてもよい。

９．６ 一人の承認者の例
本実施形態のサーバ１０は、図３に示すように、差出元のユーザに対応付けて承認者を複数設定するものであるが、差出元のユーザに対応付けて一人の承認者を設定してもよい。そして、承認者が一人である場合には、差出元のユーザから代表承認者の選択を受け付ける処理を省略し、当該一人の承認者を代表承認者として決定する。

９．７ 承認者の選択を受け付ける処理の省略
本実施形態のサーバ１０が、他の承認者の閲覧状況を表示する場合、各承認者の指示のかち合いを避けることができる。そのため、サーバ１０が閲覧状況を表示する場合、代表承認者の選択を受け付ける処理を省略してもよい。また、代表承認者の選択を受け付けない場合は、代表承認者という存在がないので、承認要求を代表承認者に通知する処理自体も省略してもよいし、承認要求を各承認者に通知するようにしてもよい。

９．８ ルールに基づく制御
本実施形態では、承認の要否を判断するためのルール（所定の条件）を設け、ルールに該当する場合に差出人とは異なる承認者の承認を要する保留処理の例について説明したが、種々のルールを設定し、当該ルールに該当するときの処理を行ってもよい。

例えば、サーバ１０は、自己承認型の保留（所定期間保留）の要否を判断するためのルールや、即時配送の要否を判断するためのルールを設定してもよい。サーバ１０は、受け付けた電子メールが自己承認型の保留の要否を判断するためのルールを満たす場合は、所定期間（例えば、１０分間）保留し、所定期間経過後配送する。また、サーバ１０は、受け付けた電子メールが即時配送の要否を判断するためのルールを満たす場合は、即時配送する。各ルールには優先度を設け、優先度順にルールを適用するようにしてもよい。

９．９ 一覧画面
サーバ１０は、一覧画面において「検討」ボタンの代わりに、承認を引き受ける「引受」ボタン、及び、参照のみで承認を引き受けない「参照」ボタンの少なくとも一方を表示するようにしてもよい。

例えば、サーバ１０は、保留メール（例えば、保留メールＩＤ＝００１）について、ログインした一の承認者（例えば、ユーザＡ）から最初に「引受」を受け付けた場合に、ログインした他の承認者（例えば、ユーザＢ、Ｃ）の一覧画面８１Ｂ、８１Ｃそれぞれに、「引受」を表示せずに「参照」ボタンを表示するようにしてもよい。

また、サーバ１０は、「引受」を受け付けたユーザを「引受ユーザ」として、保留メールＩＤに対応付けて一覧画面や指示受け付け画面に表示してもよい。

また、サーバ１０は、「参照」を受け付けたユーザを「参照ユーザ」として、保留メールＩＤに対応付けて一覧画面や指示受け付け画面に表示してもよい。

なお、「引受ユーザ」は、代表承認者である必要はない。例えば、代表承認者が多忙なため、個々の承認待ちの電子メールに対して他の承認者を代表承認者として選択することが困難な場合であっても、時間的余裕のあるユーザが積極的に承認待ちメールに対する承認や否認の指示を引き受けることができる。

なお、サーバ１０は、引受ユーザ（「引受」を受け付けた承認者Ａ）が、承認指示或いは否認指示を行わずに一覧画面或いは指示受け付け画面が閉じられた場合（サーバ１０と端末２０とのＷｅｂサーバにおけるセッションが途切れた場合）、引受をキャンセルし、「引受」ボタン及び「参照」ボタンを表示する初期状態に戻すようにしてもよいし、当該引受を受け付けたままの状態を所定期間又は永続的に保持するようにしてもよい。

９．１０ 承認要求
本実施形態では、承認要求メール７０において、図５に示すように、承認・否認のリンク（例えば、ＵＲＬ７５、ＵＲＬ７６）を有する例について説明したが、サーバ１０は、承認・否認のリンク、代表承認者Ａが閲覧可能な一覧画面へのリンク（ＵＲＬ等）や、代表承認者Ａからの承認要求メール７０の保留メール（保留メールＩＤ＝００１）の指示を受け付ける画面へのリンク（ＵＲＬ等）を含む承認要求メール７０を生成してもよい。

９．１１ ＵＲＬについて
本実施形態で説明した各ＵＲＬ（例えば、ＵＲＬ７５、７６、７８、７９等）について、ＨＴＭＬによる種々の機能（ボタン、テキスト、画像等のハイパーリンク）に代替してもよい。つまり、ＵＲＬだけでなく、ボタン、テキスト、画像等のリンクよってサーバ１０にアクセス可能としてもよい。つまり、各ＵＲＬをボタン、テキスト又は画像にリンクさせて、当該ボタン、テキスト又は画像を、閲覧者が選択することでリンク先のＵＲＬにアクセスできるように制御してもよい。

１０．その他
本発明は、上記実施形態で説明したものに限らず、種々の変形実施が可能である。例えば、明細書又は図面中の記載において広義や同義な用語として引用された用語は、明細書又は図面中の他の記載においても広義や同義な用語に置き換えることができる。

本発明は、実施形態で説明した構成と実質的に同一の構成（例えば、機能、方法及び結果が同一の構成、あるいは目的及び効果が同一の構成）を含む。また、本発明は、実施形態で説明した構成の本質的でない部分を置き換えた構成を含む。また、本発明は、実施形態で説明した構成と同一の作用効果を奏する構成又は同一の目的を達成することができる
構成を含む。また、本発明は、実施形態で説明した構成に公知技術を付加した構成を含む。

上記のように、本発明の実施形態について詳細に説明したが、本発明の新規事項及び効果から実体的に逸脱しない多くの変形が可能であることは当業者には容易に理解できるであろう。したがって、このような変形例はすべて本発明の範囲に含まれるものとする。

１０ サーバ、２０ 端末、
１００ 処理部、１１０ メール処理部（ＭＴＡ）、１１１ 受け付け部、１１２ 判定部、１１３ 解析部、１１４ 保留部、１１５ 選択部、１１６ 通知部、１１７ 指示受け付け部、１１８ 配送部、１２０ Ｗｅｂ処理部、１２１ 管理者用表示制御部、１２２ ユーザ用表示制御部、１２３ 差出人用表示制御部、１２４ 承認者用表示制御部、１３０ データベース処理部、１７０ 記憶部、１７２ ユーザＤＢ、１７３ 保留メール格納領域、１７４ 履歴ＤＢ、１７５ ルールＤＢ、２１０ Ｗｅｂブラウザ、２１１ ＭＵＡ

Claims (7)

1. 電子メールを配送するサーバのためのプログラムであって、
   差出元から送信された電子メールを受け付ける受け付け部と、
   所定の条件に基づいて前記電子メールの承認の要否を判定する判定部と、
   前記電子メールの承認が必要と判定された場合に、前記電子メールの配送を保留する保留部と、
   前記電子メールの承認が必要と判定された場合に、複数の承認者のうちの一の代表承認者の選択を受け付ける選択部と、
   前記代表承認者に対して、承認要求を通知する通知部と、
   前記複数の承認者の少なくとも一の承認者から、保留された前記電子メールの承認指示又は否認指示を受け付ける指示受け付け部と、
   前記電子メールの承認が必要と判定された場合であって、前記複数の承認者のうちの一の承認者から最先に受け付けた指示が承認指示である場合に前記電子メールを配送する制御を行う、又は、前記複数の承認者のうちの一の承認者から最先に受け付けた指示が否認指示である場合に前記電子メールの配送を中止する制御を行う配送部として、コンピュータを機能させることを特徴とするプログラム。
2. 請求項１において、
   前記選択部は、
   前記差出元のユーザから、複数の承認者のうちの一の代表承認者の選択を受け付けることを特徴とするプログラム。
3. 請求項１において、
   前記選択部は、
   複数の承認者の行動情報に基づいて、当該複数の承認者のうちの一の代表承認者の選択を受け付けることを特徴とするプログラム。
4. 請求項１～３のいずれかにおいて、
   前記選択部は、
   前記代表承認者から、前記代表承認者を除く他の承認者のうちの一の承認者の選択を受け付け、前記代表承認者に代えて選択された一の承認者を新たな代表承認者とし、
   前記通知部は、
   当該新たな代表承認者に対して承認要求を通知することを特徴とするプログラム。
5. 請求項１～４のいずれかにおいて、
   承認者毎に、承認指示又は否認指示を行うことを要する承認待ちの電子メールの一覧画面を表示する制御と、前記一覧画面の中から承認者によって選択された一の電子メールについて、当該承認者が承認指示又は否認指示を行うための指示受け付け画面を表示する制御と、を行う承認者用表示制御部として、コンピュータを更に機能させ、
   前記承認者用表示制御部は、
   承認待ちの電子メールについて、他の承認者が前記指示受け付け画面を閲覧していることを示す閲覧状況を、前記一覧画面及び前記指示受け付け画面の少なくとも一方に表示することを特徴とするプログラム。
6. 電子メールを配送するサーバのためのプログラムであって、
   差出元から送信された電子メールを受け付ける受け付け部と、
   所定の条件に基づいて前記電子メールの承認の要否を判定する判定部と、
   前記電子メールの承認が必要と判定された場合に、前記電子メールの配送を保留する保留部と、
   複数の承認者の少なくとも一の承認者から、保留された前記電子メールの承認指示又は否認指示を受け付ける指示受け付け部と、
   前記電子メールの承認が必要と判定された場合であって、前記複数の承認者のうちの一の承認者から最先に受け付けた指示が承認指示である場合に前記電子メールを配送する制御を行う、又は、前記複数の承認者のうちの一の承認者から最先に受け付けた指示が否認指示である場合に前記電子メールの配送を中止する制御を行う配送部と、
   承認者毎に、承認指示又は否認指示を行うことを要する承認待ちの電子メールの一覧画面を表示する制御と、前記一覧画面の中から承認者によって選択された一の電子メールについて、当該承認者が承認指示又は否認指示を行うための指示受け付け画面を表示する制御と、を行う承認者用表示制御部として、コンピュータを機能させ、
   前記承認者用表示制御部は、
   承認待ちの電子メールについて、他の承認者が前記指示受け付け画面を閲覧していることを示す閲覧状況を、前記一覧画面及び前記指示受け付け画面の少なくとも一方に表示することを特徴とするプログラム。
7. 請求項１～６のいずれかに記載のプログラムを記憶した記憶部と、
   前記プログラムを実行するためのプロセッサと、を備えるサーバ。

Images