特開 2024-144613 プログラム、サーバ及び方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2024144613

(43)【公開日】2024-10-11

(54)【発明の名称】プログラム、サーバ及び方法

(51)【国際特許分類】

   H04L 51/212 20220101AFI20241003BHJP

   G06Q 10/10 20230101ALI20241003BHJP

【ＦＩ】

H04L51/212

G06Q10/10

【審査請求】有

【請求項の数】13

【出願形態】ＯＬ

(21)【出願番号】P 2024119539

(22)【出願日】2024-07-25

(62)【分割の表示】P 2020098351の分割

【原出願日】2020-06-05

(71)【出願人】

【識別番号】500542745

【氏名又は名称】ＨＥＮＮＧＥ株式会社

(74)【代理人】

【識別番号】100090387

【弁理士】

【氏名又は名称】布施 行夫

(74)【代理人】

【識別番号】100144347

【弁理士】

【氏名又は名称】手島 愛

(72)【発明者】

【氏名】角 康広

(72)【発明者】

【氏名】田邊 兼一

(72)【発明者】

【氏名】箕浦 賢一

(57)【要約】

【課題】承認が必要と判定された電子メールについて、電子メールを滞りなく速やかに指示される機会を与え、複数の承認者の指示に伴う作業がかち合う事態を避け、各承認者が自身の役割を考慮した効率的な承認指示又は否認指示を可能とし、電子メールの承認待ちによるビジネス上の支障を減らすことが可能なプログラム及びサーバを提供すること。
【解決手段】複数の承認者それぞれの予測モデルを用いて、保留された電子メールの保留時刻から当該複数の承認者それぞれの即応性レベルを取得し、当該複数の承認者それぞれの即応性レベルに基づき、当該複数の承認者の中から一の代表承認者を選択する。代表承認者に対して、承認要求を通知する。そして、複数の承認者のうちの一の承認者から最先に受け付けた指示が承認指示である場合に電子メールを配送する制御を行う、又は、複数の承認者のうちの一の承認者から最先に受け付けた指示が否認指示である場合に電子メールの配送を中止する制御を行う。
【選択図】図２

【特許請求の範囲】

【請求項1】

電子メールを配送するサーバのためのプログラムであって、
差出元から送信された電子メールを受け付ける受け付け部と、
所定の条件に基づいて前記電子メールの承認の要否を判定する判定部と、
前記電子メールの承認が必要と判定された場合に、前記電子メールの配送を保留する保留部と、
前記電子メールの承認が必要と判定された場合に、複数の承認者のうちの一の代表承認者の選択を受け付ける選択部と、
前記代表承認者に対して、承認要求を通知する通知部と、
前記複数の承認者の少なくとも一の承認者から、保留された前記電子メールの承認指示又は否認指示を受け付ける指示受け付け部と、
前記電子メールの承認が必要と判定された場合であって、前記複数の承認者のうちの一の承認者から最先に受け付けた指示が承認指示である場合に前記電子メールを配送する制御を行う、又は、前記複数の承認者のうちの一の承認者から最先に受け付けた指示が否認指示である場合に前記電子メールの配送を中止する制御を行う配送部と、
ユーザ毎に、所与の時刻におけるユーザの即応性の程度を示す即応性レベルを算出する即応性レベル算出部と、
ユーザ毎に、所与の時刻と当該時刻におけるユーザの即応性レベルとを教師データとして機械学習を行い、当該時刻と当該時刻におけるユーザの当該即応性レベルとを関連付ける予測モデルを生成する機械学習部として、コンピュータを機能させ、
前記選択部は、
複数の承認者それぞれの予測モデルを用いて、保留された電子メールの保留時刻から当該複数の承認者それぞれの即応性レベルを取得し、当該複数の承認者それぞれの即応性レベルに基づき、当該複数の承認者の中から一の代表承認者を選択することを特徴とするプログラム。

【請求項2】

請求項１において、
前記通知部は、
前記代表承認者の情報を、前記差出元のユーザに通知することを特徴とするプログラム。

【請求項3】

請求項１又は２において、
前記選択部は、
前記差出元のユーザから、前記代表承認者を除く他の承認者のうちの一の承認者を新たな代表承認者とする変更を受け付けることを特徴とするプログラム。

【請求項4】

請求項１～３のいずれかにおいて、
複数の承認者それぞれの予測モデルを用いて、保留された電子メールの保留時刻から当該複数の承認者それぞれの即応性レベルを取得し、当該複数の承認者それぞれの即応性レベルに基づき、当該複数の承認者の中から一の代表承認者候補を抽出する抽出部として、コンピュータを更に機能させ、
前記通知部は、
前記抽出部によって抽出された代表承認者候補の情報を、前記差出元のユーザに通知し、
前記選択部は、
前記通知部によって、前記代表承認者候補の情報を前記差出元のユーザに通知後、差出元のユーザから、複数の承認者のうちの一の代表承認者の選択を受け付けることを特徴とするプログラム。

【請求項5】

請求項１～４のいずれかにおいて、
保留された電子メールの保留時刻と、当該電子メールについて承認指示又は否認指示を受け付けた際の代表承認者の情報と、当該承認指示又は当該否認指示を受け付けた指示時刻とを記憶する記憶部として、コンピュータを更に機能させ、
前記即応性レベル算出部は、
当該電子メールの保留時刻から指示時刻までの保留期間に応じて、当該保留時刻における当該代表承認者の即応性レベルを算出することを特徴とするプログラム。

【請求項6】

請求項５において、
前記即応性レベル算出部は、
代表承認者が変更された場合には、代表承認者が変更された変更時刻から指示時刻までの保留期間に応じて、当該保留時刻における変更後の代表承認者の即応性レベルを算出することを特徴とするプログラム。

【請求項7】

請求項１～６のいずれかにおいて、
前記即応性レベル算出部は、
ユーザの行動情報に基づき、所与の時刻における当該ユーザの即応性レベルを算出することを特徴とするプログラム。

【請求項8】

請求項１～７のいずれかに記載のプログラムを記憶した記憶部と、
前記プログラムを実行するためのプロセッサと、を備えるサーバ。

【発明の詳細な説明】

【技術分野】

【0001】

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

【背景技術】

【0002】

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

【0003】

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

【0004】

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

【先行技術文献】

【特許文献】

【0005】

【特許文献1】特許４２９９２８１号公報

【発明の概要】

【発明が解決しようとする課題】

【0006】

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

【0007】

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

【0008】

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

【課題を解決するための手段】

【0009】

（１）本発明は、
電子メールを配送するサーバのためのプログラムであって、
差出元から送信された電子メールを受け付ける受け付け部と、
所定の条件に基づいて前記電子メールの承認の要否を判定する判定部と、
前記電子メールの承認が必要と判定された場合に、前記電子メールの配送を保留する保留部と、
前記電子メールの承認が必要と判定された場合に、複数の承認者のうちの一の代表承認者の選択を受け付ける選択部と、
前記代表承認者に対して、承認要求を通知する通知部と、
前記複数の承認者の少なくとも一の承認者から、保留された前記電子メールの承認指示又は否認指示を受け付ける指示受け付け部と、
前記電子メールの承認が必要と判定された場合であって、前記複数の承認者のうちの一の承認者から最先に受け付けた指示が承認指示である場合に前記電子メールを配送する制御を行う、又は、前記複数の承認者のうちの一の承認者から最先に受け付けた指示が否認指示である場合に前記電子メールの配送を中止する制御を行う配送部と、
ユーザ毎に、所与の時刻におけるユーザの即応性の程度を示す即応性レベルを算出する即応性レベル算出部と、
ユーザ毎に、所与の時刻と当該時刻におけるユーザの即応性レベルとを教師データとして機械学習を行い、当該時刻と当該時刻におけるユーザの当該即応性レベルとを関連付ける予測モデルを生成する機械学習部として、コンピュータを機能させ、
前記選択部は、
複数の承認者それぞれの予測モデルを用いて、保留された電子メールの保留時刻から当該複数の承認者それぞれの即応性レベルを取得し、当該複数の承認者それぞれの即応性レベルに基づき、当該複数の承認者の中から一の代表承認者を選択することを特徴とするプログラムに関する。

【0010】

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

【0011】

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

【0012】

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

【0013】

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

【0014】

また、本発明によれば、ユーザ毎に、所与の時刻と当該時刻におけるユーザの即応性レベルとを教師データとして機械学習を行い、所与の時刻と当該時刻におけるユーザの当該即応性レベルとを関連付ける予測モデルを生成するので、例えば、予測モデルを用いた種々の処理が可能となる。

【0015】

そして、本発明によれば、複数の承認者それぞれの予測モデルを用いて、保留された電子メールの保留時刻から当該複数の承認者それぞれの即応性レベルを取得し、当該複数の承認者それぞれの即応性レベルに基づき、当該複数の承認者の中から一の代表承認者を選択することが可能となる。例えば、ユーザによって代表承認者を選択する手間を省くことができる。

【0016】

（２）また、本発明のプログラム、情報記憶媒体及びサーバは、
前記通知部は、
前記代表承認者の情報を、前記差出元のユーザに通知するようにしてもよい。

【0017】

本発明によれば、予測モデルを用いて一の代表承認者が選択された場合、当該代表承認者の情報を差出元のユーザに知らせることができる。

【0018】

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

【0019】

本発明によれば、差出元のユーザは、代表承認者が何らかの事情で承認チェックをできないことを知った場合、差出元のユーザ自身が、別の承認者に代表を変更することができる。したがって、保留された電子メールを滞りなく速やかに承認又は否認の指示を行うための機会を与えることができる。

【0020】

（４）また、本発明のプログラム、情報記憶媒体及びサーバは、
複数の承認者それぞれの予測モデルを用いて、保留された電子メールの保留時刻から当該複数の承認者それぞれの即応性レベルを取得し、当該複数の承認者それぞれの即応性レベルに基づき、当該複数の承認者の中から一の代表承認者候補を抽出する抽出部として、コンピュータを更に機能させ、
前記通知部は、
前記抽出部によって抽出された代表承認者候補の情報を、前記差出元のユーザに通知し、
前記選択部は、
前記通知部によって、前記代表承認者候補の情報を前記差出元のユーザに通知後、差出元のユーザから、複数の承認者のうちの一の代表承認者の選択を受け付けるようにしてもよい。

【0021】

本発明によれば、複数の承認者それぞれの予測モデルを用いて、保留された電子メールの保留時刻から当該複数の承認者それぞれの即応性レベルを取得し、当該複数の承認者それぞれの即応性レベルに基づき、当該複数の承認者の中から一の代表承認者候補を抽出することが可能となる。そして、本発明は、抽出された代表承認者候補の情報を差出元のユーザに通知するので、差出元のユーザは、代表承認者候補を考慮して簡易に代表承認者を選択することができる。

【0022】

（５）また、本発明のプログラム、情報記憶媒体及びサーバは、
保留された電子メールの保留時刻と、当該電子メールについて承認指示又は否認指示を受け付けた際の代表承認者の情報と、当該承認指示又は当該否認指示を受け付けた指示時刻とを記憶する記憶部として、コンピュータを更に機能させ、
前記即応性レベル算出部は、
当該電子メールの保留時刻から指示時刻までの保留期間に応じて、当該保留時刻における当該代表承認者の即応性レベルを算出するようにしてもよい。

【0023】

本発明によれば、実際に承認指示又は否認指示を行った代表承認者に対して、保留期間に応じて、当該代表承認者の即応性レベルを算出するので、即応性レベルを精度よく算出することができる。

【0024】

（６）また、本発明のプログラム、情報記憶媒体及びサーバは、
前記即応性レベル算出部は、
代表承認者が変更された場合には、代表承認者が変更された変更時刻から指示時刻までの保留期間に応じて、当該保留時刻における変更後の代表承認者の即応性レベルを算出するようにしてもよい。

【0025】

本発明によれば、新たな代表承認者に対して、変更時刻から指示時刻までの保留期間に応じて、変更後の代表承認者の即応性レベルを算出するので、即応性レベルを精度よく算出することができる。

【0026】

（７）また、本発明のプログラム、情報記憶媒体及びサーバは、
前記即応性レベル算出部は、
ユーザの行動情報に基づき、所与の時刻における当該ユーザの即応性レベルを算出するようにしてもよい。

【0027】

本発明によれば、ユーザの行動情報に基づき、所与の時刻における当該ユーザの即応性レベルを精度よく算出することができる。

【0028】

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

【図面の簡単な説明】

【0029】

【図1】本実施形態のサーバの機能ブロックの例。

【図2】本実施形態のサーバの処理の概要を示した図。

【図3】本実施形態の差出元のユーザＩＤと承認者のユーザＩＤとの対応関係を説明するための図。

【図4】本実施形態の代表承認者を選択するための電子メール（通知メール、選択画面）の一例。

【図5】本実施形態の承認要求メールの一例。

【図6】本実施形態の一覧画面の一例。

【図7】本実施形態に指示受け付け画面の一例。

【図8A】本実施形態のフローチャートの一例。

【図8B】本実施形態のフローチャートの一例。

【図9】本実施形態の電子メールの配送処理を説明するための図。

【図10】本実施形態の電子メールの配送処理を説明するための図。

【図11】本実施形態の機械学習アルゴリズムに入力する教師データであるデータセットの一例を示す図。

【発明を実施するための形態】

【0030】

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

【0031】

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

【0032】

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

【0033】

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

【0034】

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

【0035】

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

【0036】

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

【0037】

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

【0038】

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

【0039】

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

【0040】

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

【0041】

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

【0042】

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

【0043】

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

【0044】

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

【0045】

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

【0046】

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

【0047】

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

【0048】

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

【0049】

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

【0050】

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

【0051】

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

【0052】

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

【0053】

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

【0054】

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

【0055】

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

【0056】

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

【0057】

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

【0058】

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

【0059】

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

【0060】

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

【0061】

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

【0062】

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

【0063】

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

【0064】

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

【0065】

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

【0066】

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

【0067】

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

【0068】

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

【0069】

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

【0070】

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

【0071】

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

【0072】

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

【0073】

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

【0074】

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

【0075】

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

【0076】

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

【0077】

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

【0078】

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

【0079】

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

【0080】

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

【0081】

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

【0082】

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

【0083】

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

【0084】

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

【0085】

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

【0086】

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

【0087】

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

【0088】

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

【0089】

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

【0090】

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

【0091】

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

【0092】

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

【0093】

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

【0094】

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

【0095】

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

【0096】

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

【0097】

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

【0098】

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

【0099】

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

【0100】

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

【0101】

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

【0102】

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

【0103】

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

【0104】

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

【0105】

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

【0106】

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

【0107】

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

【0108】

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

【0109】

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

【0110】

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

【0111】

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

【0112】

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

【0113】

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

【0114】

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

【0115】

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

【0116】

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

【0117】

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

【0118】

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

【0119】

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

【0120】

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

【0121】

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

【0122】

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

【0123】

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

【0124】

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

【0125】

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

【0126】

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

【0127】

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

【0128】

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

【0129】

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

【0130】

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

【0131】

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

【0132】

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

【0133】

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

【0134】

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

【0135】

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

【0136】

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

【0137】

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

【0138】

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

【0139】

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

【0140】

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

【0141】

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

【0142】

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

【0143】

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

【0144】

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

【0145】

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

【0146】

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

【0147】

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

【0148】

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

【0149】

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

【0150】

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

【0151】

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

【0152】

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

【0153】

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

【0154】

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

【0155】

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

【0156】

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

【0157】

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

【0158】

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

【0159】

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

【0160】

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

【0161】

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

【0162】

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

【0163】

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

【0164】

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

【0165】

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

【0166】

例えば、図１０に示すように、メーリングリストのメールアドレスが、「[e-mail]」であり、当該メーリングリストの参加者のメールアドレスが、ユーザＫのメールアドレス「[e-mail]」、ユーザＮのメールアドレス「[e-mail]」とする場合、エンベロープの宛先「[e-mail]」を、参加者のアドレス「[e-mail]」、「[e-mail]」に換えて配送する。

【0167】

本実施形態では、メーリングリストの宛先「[e-mail]」に基づいて承認の要否を判断してもよいし、メーリングリストに属する参加者の宛先毎（例えば、「[e-mail]」、「[e-mail]」の宛先毎）に承認の要否を判断してもよい。

【0168】

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

【0169】

また、メーリングリストに属する参加者の宛先毎（例えば、「[e-mail]」、「[e-mail]」の宛先毎）に所定の条件を満たすか否かを判断し、所定の条件を満たす場合に、承認が必要であると判定する。

【0170】

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

【0171】

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

【0172】

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

【0173】

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

【0174】

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

【0175】

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

【0176】

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

【0177】

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

【0178】

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

【0179】

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

【0180】

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

【0181】

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

【0182】

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

【0183】

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

【0184】

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

【0185】

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

【0186】

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

【0187】

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

【0188】

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

【0189】

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

【0190】

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

【0191】

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

【0192】

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

【0193】

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

【0194】

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

【0195】

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

【0196】

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

【0197】

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

【0198】

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

【0199】

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

【0200】

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

【0201】

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

【0202】

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

【0203】

１０． ＡＩ関連技術の応用
本実施形態のサーバ１０は、ＡＩ（ａｒｔｉｆｉｃｉａｌ ｉｎｔｅｌｌｉｇｅｎｃｅの略）に関する機能によって、本実施形態における各種制御を行ってもよい。例えば、サーバ１０は、線形回帰、正規化、ロジスティック回帰、サポートベクトルマシン（カーネル法含む）、ナイーブベイズ、ランダムフォレスト、ｋＮＮ、ニューラルネットワークなどの機械学習アルゴリズムを用いた機械学習（教師あり機械学習）によって予測モデル（学習モデル、関数ともいう。）を生成する。そして、サーバ１０は、予測モデルを用いて入力データから予測されるデータを出力する。

【0204】

１０．１ ＡＩによる承認指示又は否認指示
サーバ１０は、ＡＩによる承認指示又は否認指示を行ってもよい。例えば、サーバ１０は、保留された電子メールの情報と、承認者が指示した当該電子メールの承認指示又は否認指示を示す情報とを教師データとして用いる。なお、保留された電子メールの情報とは、電子メールのエンベロープの宛先、エンベロープの差出元、メッセージのヘッダ、メッセージのボディの本文部分を含む電子メールの情報である。

【0205】

つまり、サーバ１０は、新たに受け付けた保留された電子メールに対する指示（承認指示又は否認指示）を判定するための機械学習を行った学習済みの予測モデルを生成する。すなわち、サーバ１０は、記憶部１７０（履歴ＤＢ１７４）に蓄積して記憶された複数の保留された各電子メールの情報と、当該各電子メールに対する承認者の指示内容（承認指示又は否認指示）を教師データとし、当該教師データを用いて、機械学習アルゴリズム（ニューラルネットワーク等）に機械学習処理を施し、予測モデルを生成する。そして、サーバ１０は、予測モデルを用いて、新たに受け付けた保留された電子メールを入力し、当該保留された電子メールに対して適切と推定される指示を出力する。なお、当該予測モデルが出力する指示は、承認指示又は否認指示でもよいし、例えば、承認指示を１、否認指示を０とした数値を用いたものでよい。

【0206】

つまり、サーバ１０は、当該予測モデルに新たに受け付けた保留された電子メールを入力することで、当該予測モデルから、当該保留された電子メールに対して適切と推定される指示（承認指示又は否認指示）を取得する。サーバ１０は、取得した指示が「承認指示」である場合に、当該保留された電子メールを配送し、取得した指示が「否認指示」である場合に、当該保留された電子メールを配送中止に制御する。

【0207】

次に、サーバ１０のＡＩによる指示（承認指示又は否認指示）に関する機能構成を追記する。

【0208】

まず、サーバ１０の記憶部１７０（履歴ＤＢ１７４）には、承認又は否認の指示に基づき配送又は配送中止がなされた全ての電子メールの情報、及び当該電子メールに対する指示内容（承認指示又は否認指示）が記憶される。

【0209】

また、サーバ１０は、機械学習部１４０を備える。機械学習部１４０は、記憶部１７０（履歴ＤＢ１７４）に記憶（蓄積記憶）された電子メールの情報、および、当該電子メールに対する承認者の指示内容（承認指示又は否認指示）を教師データとし、当該教師データを用いて、機械学習アルゴリズム（ニューラルネットワーク等）に機械学習を施し、予測モデルを生成する。

【0210】

そして、サーバ１０は、保留メール指示取得部１４２を備える。保留メール指示取得部１４２は、機械学習部１４０によって機械学習された当該予測モデルを用いて、新たに受け付けた保留された電子メールについて、適切と推定される指示（承認指示又は否認指示）を取得する。

【0211】

配送部１１８は、新たに受け付けた保留された電子メールについて保留メール指示取得部１４２によって取得した指示が「承認指示」である場合に、保留された当該電子メールを配送する制御を行う。また、配送部１１８は、新たに受け付けた保留された電子メールについて保留メール指示取得部１４２によって取得した指示が「否認指示」である場合に、保留された当該電子メールの配送を中止する制御を行う。

【0212】

なお、配送部１１８は、新たに受け付けた保留された電子メールについて保留メール指示取得部１４２によって取得した指示結果が「承認指示」である場合に、承認者に「承認指示」が適切と推定される旨を提示するのみに留め、保留された当該電子メールを配送せずに、その後、承認者（人）による承認または否認の指示を受け付けるようにしてもよい。すなわち、複数の承認者のうちの一の承認者から最先に受け付けた指示が承認指示である場合に当該電子メールを配送する制御を行い、複数の承認者のうちの一の承認者から最先に受け付けた指示が否認指示である場合に前記電子メールの配送を中止する制御を行うようにしてもよい。このようにすれば、予測モデル（ＡＩ）による判断を参考としつつ、人の判断によって承認または否認の指示を行うことができるので、予測モデル（ＡＩ）と人とのダブルチェックが可能となり、誤って承認してしまう事態を低減することができる。

【0213】

なお、サーバ１０は、承認者（人）を介して承認又は否認の指示に基づき制御された電子メールと、機械学習部１４０を利用して承認又は否認の指示に基づき制御された電子メールとを識別して、記憶部１７０（履歴ＤＢ１７４）に電子メールを蓄積記憶する。機械学習部１４０は、予測モデル（ＡＩ）と人とのダブルチェックのような最終的に承認者（人）が指示を行う場合も含め、承認者（人）を介して承認又は否認の指示に基づき配送又は配送中止がなされた電子メールだけを機械学習の対象としてもよいし、予測モデル（ＡＩ）と承認者（人）に関係なく、承認又は否認の指示に基づき配送又は配送中止がなされた全ての電子メールを機械学習の対象としてもよい。

【0214】

１０．２ ＡＩによる差出人に対応付ける承認者の選択について
サーバ１０は、ＡＩによって、差出人に対応付ける１又は複数の承認者を選択してもよい。例えば、サーバ１０は、記憶部１７０（履歴ＤＢ１７４）に蓄積して記憶された複数の保留された各電子メールの情報と、当該各電子メールに対応付けた複数の承認者（ユーザ名またはユーザＩＤ）の情報とを教師データとして用いる。なお、「承認者の情報」とは、承認者（ユーザ名またはユーザＩＤ）に加えて、当該各電子メールが保留された時刻のスケジュール情報、出勤情報、位置情報等の承認者の行動情報に関する情報を含んでもよい。そして、サーバ１０は、当該教師データを用いて、機械学習アルゴリズム（ニューラルネットワーク等）に機械学習処理を施し、予測モデルを生成する。そして、サーバ１０は、予測モデルを用いて、新たに受け付けた保留された電子メールを入力し、当該保留された電子メールに対して適切と推定される１又は複数の承認者を出力する。

【0215】

つまり、サーバ１０は、当該予測モデルに新たに受け付けた保留された電子メールを入力することで、当該予測モデルから、当該保留された電子メールに対して適切と推定される複数の承認者を選択する。なお、選択する承認者の人数は所定数とする。

【0216】

次に、サーバ１０のＡＩによって複数の承認者を選択する際の機能構成を追記する。

【0217】

まず、サーバ１０は、機械学習部１４０を備える。機械学習部１４０は、履歴ＤＢ１７４に蓄積記憶された保留された各電子メールの情報、および、当該各電子メールの差出人に対応付けた複数の承認者を示すデータを教師データとし、当該教師データを用いて、機械学習アルゴリズム（ニューラルネットワーク等）に機械学習処理を施し、予測モデルを生成する。

【0218】

そして、サーバ１０は、承認者選択部１４３を備える。承認者選択部１４３は、機械学習部１４０によって機械学習された当該予測モデルを用いて、新たに受け付けた保留された電子メールについて、適切と推定される１又は複数の承認者を選択する。なお、選択した１又は複数の承認者の行動情報（今後のスケジュール情報、出勤情報等の情報）を取得し、１又は複数の承認者を再選択するようにしてもよい。

【0219】

１０．３ ＡＩによる代表承認者の選択について
サーバ１０は、ＡＩによって、代表承認者を選択（選定）してもよい。

【0220】

例えば、サーバ１０は、ユーザ毎に、所与の時刻と当該時刻におけるユーザの即応性レベルを教師データとして機械学習を行い、当該時刻と当該時刻におけるユーザの即応性レベルとを関連付ける予測モデルを生成する。そして、サーバ１０は、複数の承認者それぞれの予測モデルを用いて、複数の承認者それぞれの即応性レベルを予測し、当該複数の承認者の即応性レベルに基づき、代表承認者を選択してもよい。

【0221】

１０．３．１ 教師データ（データセット）の説明
図１１は、機械学習アルゴリズムに入力する教師データであるデータセットの一例を示す。つまり、図１１に示すように、本実施形態では、「時刻」及び「即応性レベル」をデータセットとする。つまり、サーバ１０は、「時刻」を入力データ（特徴量、説明変数ともいう。）とし、「即応性レベル」を出力データ（目的変数、ラベル、回答データ、ともいう。）とするデータセットを予め用意する。つまり、教師データは、ユーザの即応性レベルを時間的に示した分布情報である。

【0222】

例えば、サーバ１０は、ユーザ毎に、所定の期間（例えば、過去１年間）において、所定周期の時刻（例えば、１時間単位の時刻、或いは、１分単位の時刻）と、各時刻におけるユーザの行動情報に基づく当該ユーザの即応性レベルとを、当該ユーザの教師データとして予め用意する。

【0223】

また、サーバ１０は、所定の期間（例えば、過去１年間）において、保留された電子メールを代表承認者のユーザ毎に振り分ける。そして、サーバ１０は、ユーザ毎に、保留された電子メールそれぞれについて、電子メールの当該保留時刻と、当該保留時刻における代表承認者の保留期間に応じた即応性レベルとを、当該ユーザの教師データとして用意する。

【0224】

なお、サーバ１０は、データセットの入力データに「時刻」だけでなく「出勤情報」、「位置情報」及び「スケジュール情報」の少なくとも１つを含むようにしてもよい。

【0225】

また、サーバ１０は、ユーザ毎に収集した教師データ（データセット）を記憶部１７０に記憶する。

【0226】

１０．３．２ 即応性レベルの説明
次に、即応性レベルの詳細について説明する。即応性レベルは、１日（２４時間）の期間における所与の時刻に基づき、ユーザが指示に即応する程度を示す値であり、例えば、所与の時刻において、指示に対応できるまでの時間的な長さ示す。例えば、即応性レベルは１～１０の数値であり、当該時刻に基づき、直ぐに指示対応できるユーザについて即応性レベルの数値を高くし、直ぐに指示対応できないユーザについて即応性レベルの数値を低くする。

【0227】

（Ａ）ユーザの行動情報に基づく即応性レベルの説明
サーバ１０は、ユーザの行動情報に基づき、所与の時刻における当該ユーザの即応性レベルを算出する。ユーザの行動情報とは、ユーザの出勤情報、位置情報、スケジュール情報、等である。

【0228】

つまり、サーバ１０は、所定の期間（例えば、過去１年間）において、ユーザ毎に、所定周期（例えば、１分単位）の時刻と、各時刻におけるユーザの行動情報に基づく当該ユーザの即応性レベルを算出する。

【0229】

例えば、サーバ１０は、所定周期の時刻毎のユーザの出勤情報から、ユーザの即応性レベルを判定する。例えば、ユーザＡの午前８時０分の出勤情報が「出勤」を示す場合、午前８時０分の即応性のレベルを「１０」に設定し、ユーザＡの午前８時０分の出勤情報が「欠勤」を示す場合、午前８時０分の即応性レベルを「０」に設定し、ユーザＡの午前８時０分の出勤情報が「休憩」を示す場合、午前８時０分の即応性レベルを「５」に設定する。

【0230】

また、サーバ１０は、所定周期の時刻毎のユーザの位置情報からユーザの即応性レベルを判定してもよい。例えば、ユーザＡの午前８時０分の位置情報が「社内」を示す場合、午前８時０分の即応性のレベルを「１０」に設定し、ユーザＡの午前８時０分の位置情報が「社外（自宅外）」を示す場合、午前８時０分の即応性レベルを「０」に設定し、ユーザＡの午前８時０分の位置情報が「社外（自宅）」を示す場合、午前８時０分の即応性レベルを「２」に設定する。

【0231】

また、サーバ１０は、所定周期の時刻毎のユーザのスケジュール情報からユーザの即応性レベルを判定してもよい。例えば、ユーザＡの午前８時０分のスケジュール情報が「無し」を示す場合、午前８時０分の即応性のレベルを「１０」に設定し、ユーザＡの午前８時０分のスケジュール情報が「会議」を示す場合、午前８時０分の即応性レベルを「５」に設定し、ユーザＡの午前８時０分のスケジュール情報が「休暇」を示す場合、午前８時０分の即応性レベルを「０」に設定する。

【0232】

また、サーバ１０は、所定周期の時刻毎のユーザの出勤情報、位置情報、スケジュール情報の少なくとも１つに基づき、ユーザの即応性レベルを判定してもよい。例えば、ユーザＡが午前８時０分に出勤し、会社に位置しているが重要なスケジュールがある場合には、即応性レベルを「０」に設定してもよい。また、ユーザＡが退勤した場合には、スケジュール情報にかかわらず（スケジュールが空いていても）即応性レベルを「０」に設定してもよい。また、在宅勤務者のように自宅等で仕事をするユーザは、会社に位置していないが電子メールの承認等の対応は直ぐにできると考えられる。例えば、ユーザＡが自宅で在宅勤務をしている場合には、在宅勤務中の時間帯（休憩時間帯や外出時間帯を除く）において即応性レベルを「１０」に設定する。また、出勤していたとしても会社に不在であるユーザは、承認等の指示対応は直ぐにできないと考えられる。したがって、例えば、出勤していたとしても外出予定のスケジュールのあるユーザに対して、当該外出時間帯において即応性レベルを「１」に設定する。

【0233】

なお、ユーザの行動情報（出勤情報、位置情報、スケジュール情報等）は、記憶部１７０やサーバ１０とネットワークを介して接続された出勤管理システム等に記憶されている。

【0234】

（Ｂ）ユーザの保留期間に基づく即応性レベルの説明
また、サーバ１０は、保留された電子メールに対して承認指示又は否認指示を受け付けた場合に、当該電子メールの保留期間に応じて、当該保留時刻における当該代表承認者の即応性レベルを算出する。なお、電子メールの保留期間とは、当該電子メールの保留時刻から当該電子メールに対して承認指示又は否認指示を受け付けた指示時刻までの期間である。

【0235】

つまり、サーバ１０は、所定の期間（例えば、過去１年間）において、履歴ＤＢ１７４に蓄積された保留された電子メールを参照し、保留された電子メールを代表承認者のユーザ毎に振り分ける。そして、サーバ１０は、ユーザ毎に、保留された各電子メールについて、当該各電子メールの保留時刻における当該ユーザ（代表承認者）の即応性レベルを算出する。

【0236】

例えば、電子メールの保留期間が短い程、即応性レベルを高くし、電子メールの保留期間が長い程、即応性レベルを低くするようにして、当該電子メールの代表承認者の即応性レベルを算出する。そして、保留時刻と算出された即応性レベルとを関連付ける。

【0237】

具体的に説明すると、例えば、保留メールＩＤ＝００１の電子メールの保留時刻が、午前１０時１５分に保留されたとする。すると、代表承認者のユーザＡが保留メールＩＤ＝００１の電子メールについて１時間未満に承認指示又は否認指示をした場合、ユーザＡの午前１０時１５分の即応性レベルを「１０」とする。

【0238】

また、代表承認者のユーザＡが保留メールＩＤ＝００１の電子メールについて１時間以上２時間未満に承認指示又は否認指示をした場合、ユーザＡの午前１０時１５分の即応性レベルを「９」とする。

【0239】

また、代表承認者のユーザＡが保留メールＩＤ＝００１の電子メールについて２時間以上３時間未満に承認指示又は否認指示をした場合、ユーザＡの午前１０時１５分の即応性レベルを「８」とする。

【0240】

このように、保留期間の時間経過に応じて即応性レベルを減少させる。そして、代表承認者のユーザＡが保留メールＩＤ＝００１の電子メールについて１０時間以上経過して承認指示又は否認指示をした場合、ユーザＡの午前１０時１５分の即応性レベルを「０」とする。

【0241】

また、サーバ１０は、電子メールの代表承認者の変更があった場合には、変更後の代表承認者の即応性レベルを算出する。例えば、保留時刻が午前１０時１５分である保留メールＩＤ＝００１の電子メールについて代表承認者をユーザＡからユーザＢに変更したとする。そして、変更時刻が午前１１時３２分であるとする。かかる場合、ユーザＢから当該電子メールに対して承認指示又は否認指示を受け付けた場合に、当該電子メールの変更時刻（午前１１時３２分）から指示を受け付けた指示時刻までの期間に応じてユーザＢの即応性レベルを算出する。そして、当該変更時刻（例えば、午前１１時３２分）とユーザＢの即応性レベルとを関連付ける。

【0242】

なお、サーバ１０は、電子メールの代表承認者の変更があった場合には、変更前の代表承認者（辞退した代表承認者）の即応性レベルを辞退理由に基づき算出してもよい。例えば、保留メールＩＤ＝００１の電子メールについて代表承認者をユーザＡからユーザＢに変更した場合、保留メールＩＤ＝００１の電子メールの保留時刻（例えば、午前１０時１５分）に対応付けてユーザＡの即応性レベルを算出する。例えば、ユーザＡの辞退理由が「休暇等による不在」の場合、ユーザＡの即応性レベルを「３」とし、ユーザＡの辞退理由が「対応する時間がない」に該当する場合、ユーザＡの即応性レベルを「２」とし、ユーザＡの辞退理由が「自身は代表承認者として適切ではない」に該当する場合、ユーザＡの即応性レベルを「１」とする。つまり、サーバ１０は、代表承認者の変更が生じた場合、保留された電子メールについて、辞退理由に応じて元の代表承認者の即応性レベルを低くする。

【0243】

１０．３．３ 機械学習の説明
サーバ１０は、図１１に示すように、ユーザ毎に、ユーザの即応性の程度を予測するための機械学習を行った学習済みの予測モデルを生成する。つまり、サーバ１０は、ユーザ毎に、所与の時刻と、当該時刻におけるユーザの即応性レベルとを教師データとし、機械学習を行い、各ユーザの予測モデルを生成する。

【0244】

サーバ１０は、ユーザ毎に、記憶部１７０に蓄積した全てのデータセット（教師データ）を用いて機械学習を行ってもよいし、一部のデータセットを用いて、機械学習を行ってもよい。例えば、データセットの７０％を学習用として機械学習を行い、残りの３０％を検証用として評価処理（テスト処理）を行ってもよい。

【0245】

また、本実施形態のサーバ１０は、予測モデルを生成した後、機械学習を中止してもよいし、予測モデルを生成した後においても、機械学習を継続的に行うようにしてもよい。

【0246】

なお、サーバ１０は、適宜、性能を上げるために評価処理を行い、過学習を防ぐために、機械学習を打ち切るようにしてもよい（アーリーストッピングをしてもよい）。

【0247】

また、本実施形態のサーバ１０は、（Ａ）所定周期の時刻と、当該時刻におけるユーザの行動情報に基づく即応性レベルとで構成されるデータセット、及び、（Ｂ）保留された電子メールの保留時刻と、当該電子メールの代表承認者の保留期間に基づく即応性レベルとで構成されるデータセットの両方を用いて機械学習を行って予測モデルを生成するが、（Ａ）所定周期の時刻と、当該時刻におけるユーザの行動情報に基づく即応性レベルとで構成されるデータセットのみを用いて機械学習を行って予測モデルを生成してもよいし、（Ｂ）保留された電子メールの保留時刻と、当該電子メールの代表承認者の保留期間に基づく即応性レベルとで構成されるデータセットのみを用いて機械学習を行って予測モデルを生成してもよい。

【0248】

１０．３．４ 予測モデルを使った代表承認者の選択処理の説明
そして、サーバ１０は、機械学習済みの予測モデルを用いて、代表承認者を選択する。例えば、サーバ１０は、複数の承認者それぞれの予測モデルを用いて、新たに保留された電子メールの保留時刻から当該複数の承認者それぞれの即応性レベルを取得し、当該複数の承認者それぞれの即応性レベルに基づき、当該複数の承認者の中から一の代表承認者を選択する処理を行う。

【0249】

例えば、サーバ１０は、新たに保留された電子メールの保留時刻において複数の承認者のうち最も即応性レベルの高い承認者を代表承認者として選択する。なお、即応性レベルの最も高いユーザが複数存在する場合は、任意に一のユーザを代表承認者として選択する。

【0250】

例えば、図１１に示すように、サーバ１０は、新たに受け付けた保留された電子メールの保留時刻が１０時３０分であり、１０時３０分における承認者Ａの即応性レベルが「１０」、１０時３０分における承認者Ｂの即応性レベルが「５」、１０時３０分における承認者Ｃの即応性レベルが「０」である場合、複数の承認者Ａ、Ｂ、Ｃの中から最も即応性レベルの高い承認者Ａを代表承認者として選択する。

【0251】

また、サーバ１０は、新たに保留された電子メールについて、予測モデルを用いて取得した複数の承認者の即応性レベルと、当該複数の承認者の行動情報に基づいて、当該複数の承認者のうちの一の代表承認者を選択してもよい。当該複数の承認者の行動情報については現時点を基準に参照する。

【0252】

例えば、サーバ１０は、複数の承認者のうち最も即応性レベルの高い承認者がユーザＡであるが現時点におけるユーザＡが「欠勤」である場合には、現時点において出勤しており次に即応性レベルの高い承認者であるユーザを代表承認者として選択するようにしてもよい。

【0253】

なお、例えば、サーバ１０は、選択された代表承認者に承認要求メールを通知する。また、サーバ２０は、選択された代表承認者を差出元のユーザに通知してもよい。

【0254】

また、サーバ１０は、差出元のユーザから、代表承認者を除く他の承認者のうちの一の承認者を新たな代表承認者とする変更を受け付けるようにしてもよい。例えば、複数の承認者のうち最も即応性レベルの高い承認者がユーザＡである場合において、差出元のユーザから、代表承認者Ａを除く他の承認者Ｂ、Ｃのうちの一の承認者Ｂを新たな代表承認者とする変更を受け付けてもよい。このようにすれば、差出元のユーザは、代表承認者Ａが急用など何らかの事情で承認チェックをできないことを知った場合、差出元のユーザ自身が、別の承認者Ｂに代表を変更することができる。したがって、保留された電子メールを滞りなく速やかに承認又は否認の指示を行うための機会を与えることができ、利便性の高いシステムを提供することができる。

【0255】

１０．３．５ 機能構成の説明
次に、サーバ１０のＡＩ機能に関する機能構成を追記する。

【0256】

まず、サーバ１０は、即応性レベル算出部１４４を備える。即応性レベル算出部１４４は、ユーザ毎に、所与の時刻におけるユーザの即応性の程度を示す即応性レベルを算出する。

【0257】

例えば、即応性レベル算出部１４４は、保留された電子メールに対して承認指示又は否認指示を受け付けた場合に、当該電子メールの保留時刻から当該電子メールに対して承認指示又は否認指示を受け付けた時刻までの保留期間に応じて、当該保留時刻における当該代表承認者の即応性レベルを算出する。

【0258】

なお、記憶部１７０（履歴ＤＢ１７４）には、保留された電子メールの保留時刻と、当該電子メールについて承認指示又は否認指示を受け付けた際の代表承認者の情報と、当該承認指示又は当該否認指示を受け付けた指示時刻とが記憶されている。したがって、即応性レベル算出部１４４は、記憶部１７０（履歴ＤＢ１７４）に蓄積された各電子メールについて、最終的に承認指示又は否認指示を行った代表承認者に対して、電子メールの保留期間に応じて、当該電子メールの保留時刻における即応性レベルを算出する。

【0259】

また、即応性レベル算出部１４４は、保留された電子メールの保留時刻に対応付けて、代表承認者の即応性レベルを算出する。例えば、保留メールＩＤ＝００１の電子メールの代表承認者がユーザＡであり保留時刻が１０時１５分である場合、ユーザＡの１０時１５分における即応性レベルを算出する。なお、サーバ１０は、記憶部１７０に、ユーザ毎に教師データ（例えば、ユーザ自身が代表承認者である各電子メールについて、当該電子メールの保留時刻と、保留時刻における当該即応性レベル）を蓄積して記憶する。

【0260】

また、即応性レベル算出部１４４は、代表承認者がユーザＡからユーザＢ変更された場合には、代表承認者がユーザＢに変更された変更時刻から指示時刻までの保留期間に応じて、当該保留時刻における変更後の代表承認者であるユーザＢの即応性レベルを算出するようにしてもよい。

【0261】

また、即応性レベル算出部１４４は、保留期間が長いほど即応性レベルが低くなるように設定する。

【0262】

また、即応性レベル算出部１４４は、ユーザの行動情報（出勤情報、位置情報、スケジュール情報等）に基づき、所与の時刻における当該ユーザの即応性レベルを算出する。例えば、即応性レベル算出部１４４は、所定周期の時刻（例えば、１時間単位の時刻、或いは、１分単位の時刻）において、ユーザ毎に、ユーザの行動情報に基づき、当該ユーザの即応性の程度を示す即応性レベルを算出する。なお、サーバ１０は、記憶部１７０に、ユーザ毎の教師データ（例えば、所定周期の時刻と、各時刻のユーザの行動情報に基づく当該即応性レベル）を蓄積して記憶する。

【0263】

そして、サーバ１０は、機械学習部１４０を備える。機械学習部１４０は、ユーザ毎に予測モデルを生成する。機械学習部１４０は、ユーザ毎に、所与の時刻と当該時刻におけるユーザの即応性レベルとを教師データとして機械学習を行い、当該時刻と当該時刻におけるユーザの当該即応性レベルとを関連付ける予測モデルを生成する。

【0264】

例えば、機械学習部１４０は、ユーザ毎に、所定周期の時刻（例えば、１時間単位の時刻、或いは、１分単位の時刻）と、当該時刻のユーザの行動情報に基づく当該ユーザの即応性レベルとを教師データとし、当該教師データを用いて、機械学習アルゴリズム（ニューラルネットワーク等）に機械学習処理を施し、予測モデルを生成する。

【0265】

また、機械学習部１４０は、ユーザ毎に、ユーザ自身が代表承認者である保留された電子メールの保留時刻と、当該保留時刻における当該代表承認者の即応性レベルとを教師データとし、当該教師データを用いて、機械学習アルゴリズム（ニューラルネットワーク等）に機械学習処理を施し、予測モデルを生成する。

【0266】

なお、サーバ１０は、保留された電子メールを履歴ＤＢ１７４に蓄積し、履歴ＤＢ１７４に蓄積された電子メール毎に代表承認者を参照する。そして、機械学習部１４０は、参照した代表承認者について電子メールの保留時刻と、即応性レベル算出部１４４において算出された当該保留時刻における当該代表承認者の即応性レベルとを教師データとする。機械学習部１４０は、当該教師データを用いて、機械学習アルゴリズム（ニューラルネットワーク等）に機械学習処理を施し、予測モデルを生成する。

【0267】

なお、本実施形態の機械学習部１４０は種々の機械学習のアルゴリズムを利用可能である。また、機械学習部１４０によって生成された予測モデルは記憶部１７０に記憶される。

【0268】

そして、サーバ１０の選択部１１５は、複数の承認者それぞれの予測モデルを用いて、保留された電子メールの保留時刻から当該複数の承認者それぞれの即応性レベルを取得し、当該複数の承認者それぞれの即応性レベルに基づき、当該複数の承認者の中から一の代表承認者を選択する。

【0269】

例えば、選択部１１５は、新たに受け付けた保留された電子メールの承認者のユーザ毎に、当該ユーザの予測モデルを用いて、当該電子メールの保留時刻の情報を入力し、当該電子メールについての当該ユーザの即応性レベルを取得する。そして、選択部１１５は、複数の承認者それぞれの即応性レベルに基づき、最も即応性レベルの高い一の承認者を代表承認者として選択する。

【0270】

また、選択部１１５は、保留時刻における複数の承認者の即応性レベルと、当該複数の承認者の行動情報に基づいて、当該複数の承認者のうちの一の代表承認者を選択してもよい。

【0271】

例えば、選択部１１５は、複数の承認者Ａ，Ｂ，Ｃのうち最も即応性レベルの高い承認者Ａである場合において、現時点におけるユーザＡが「欠勤」である場合には、現時点において出勤しており次に即応性レベルの高い承認者Ｂを代表承認者として選択するようにしてもよい。

【0272】

また、選択部１１５は、保留された電子メールの代表承認者を変更する場合に（例えば、代表承認者から辞退を受け付けた場合に）、当該代表承認者のユーザの次に即応性レベルの高い一の承認者を新たな代表承認者として選択してもよい。例えば、サーバ１０は、予測モデルを用いて代表承認者をユーザＡからユーザＢに変更した場合、ユーザＢの端末２０に、ユーザＢが代表承認者であることを通知するようにしてもよい。

【0273】

また、選択部１１５は、差出元のユーザから、代表承認者を除く他の承認者のうちの一の承認者を新たな代表承認者とする変更を受け付けるようにしてもよい。

【0274】

また、サーバ１０の通知部１１６は、選択部１１５によって選択された代表承認者の情報を、差出元のユーザ（当該ユーザの端末２０）に通知するようにしてもよい。

【0275】

また、サーバ１０は、複数の承認者の中から一の代表承認者候補を抽出する抽出部１１９を備えていてもよい。

【0276】

抽出部１１９は、複数の承認者それぞれの予測モデルを用いて、保留された電子メールの保留時刻から当該複数の承認者それぞれの即応性レベルを取得し、当該複数の承認者それぞれの即応性レベルに基づき、当該複数の承認者の中から一の代表承認者候補を抽出する。例えば、最も即応性レベルの高いユーザを一の代表承認者候補として抽出する。

【0277】

また、抽出部１１９は、保留された電子メールの代表承認者から辞退を受け付けた場合に、当該代表承認者のユーザの次に即応性レベルの高い一の承認者を新たな代表承認者候補として抽出する。なお、サーバ１０は、辞退する代表承認者がユーザＡであり、代表承認者候補をユーザＢとして抽出した場合、ユーザＢの端末２０に、ユーザＢが代表承認者候補であることを通知するようにしてもよい。

【0278】

また、サーバ１０の通知部１１６は、抽出部１１９によって抽出された代表承認者候補の情報を、差出元のユーザ（当該ユーザの端末２０）に通知するようにしてもよい。例えば、サーバ１０は、ユーザＡが代表承認者候補である場合、ユーザＡが代表承認者候補であることを、差出人のユーザＸの端末２０に、通知するようにしてもよい。例えば、代表承認者候補をユーザＡからユーザＢに変更された場合、サーバ１０は、ユーザＸの端末２０に、ユーザＢが代表承認者候補であることを通知するようにしてもよい。

【0279】

そして、サーバ１０の選択部１１５は、通知部１１６によって、代表承認者候補の情報を差出元のユーザに通知後、差出元のユーザから、複数の承認者のうちの一の代表承認者の選択を受け付けるようにしてもよい。

【0280】

１０．３．６ 機械学習の他の例
サーバ１０は、所定期間（例えば、過去１年間）において保留された電子メールと代表承認者とを教師データ（データセット）として記憶部１７０に蓄積し、サーバ１０は、教師データを用いて機械学習アルゴリズムによって機械学習を行い、予測モデルを生成してもよい。

【0281】

そして、サーバ１０は、機械学習済みの当該予測モデルを用いて、新たに保留された電子メールについて、当該電子メールを入力し、出力された代表承認者を選択してもよい。なお、サーバ１０は、保留された電子メールについて代表承認者が変更された場合には、当該電子メールと変更後の代表承認者とを教師データとし、更に機械学習を行ってもよい。

【0282】

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

【0283】

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

【0284】

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

【符号の説明】

【0285】

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

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8A】

【図8B】

【図9】

【図10】

【図11】

【手続補正書】

【提出日】2024-08-22

【手続補正1】

【補正対象書類名】特許請求の範囲

【補正対象項目名】全文

【補正方法】変更

【補正の内容】

【特許請求の範囲】

【請求項1】

電子メールを配送するサーバのためのプログラムであって、
差出元から送信された電子メールを受け付ける受け付け部と、
所定の条件に基づいて前記電子メールの承認の要否を判定する判定部と、
前記電子メールの承認が必要と判定された場合に、前記電子メールの配送を保留する保留部と、
複数の承認者の少なくとも一の承認者から、保留された前記電子メールの承認指示又は否認指示を受け付ける指示受け付け部と、
前記電子メールの承認が必要と判定された場合であって、前記複数の承認者のうちの一の承認者から最先に受け付けた指示が承認指示である場合に前記電子メールを配送する制御を行う、又は、前記複数の承認者のうちの一の承認者から最先に受け付けた指示が否認指示である場合に前記電子メールの配送を中止する制御を行う配送部と、
保留された電子メールの情報と、当該電子メールに対する承認者の指示内容とを教師データとして機械学習を行い、当該電子メールの情報と当該指示内容とを関連付ける予測モデルを生成する機械学習部と、
前記予測モデルを用いて、新たに保留された電子メールについて、承認指示又は否認指示を取得する保留メール指示取得部として、コンピュータを機能させることを特徴とするプログラム。

【請求項2】

請求項１において、
前記配送部は、
前記電子メールの承認が必要と判定された場合であって、前記保留メール指示取得部によって取得した指示が承認指示である場合に、前記電子メールを配送する制御を行う、又は、前記保留メール指示取得部によって取得した指示が否認指示である場合に前記電子メールの配送を中止する制御を行うことを特徴とするプログラム。

【請求項3】

請求項１において、
承認者から保留された前記電子メールの承認指示又は否認指示を受け付ける前に、前記電子メールの承認が必要と判定された場合であって、前記保留メール指示取得部によって取得した指示が承認指示である場合に、承認者に承認指示が適切と推定される旨を提示す
る提示部として、コンピュータを更に機能させることを特徴とするプログラム。

【請求項4】

請求項１～３のいずれかにおいて、
前記機械学習部は、
承認者を介して承認又は否認の指示に基づき制御された電子メールと、前記機械学習部を利用して承認又は否認の指示に基づき制御された電子メールとのうち、承認者を介して承認又は否認の指示に基づき配送又は配送中止がなされた電子メールを、機械学習の対象にすることを特徴とするプログラム。

【請求項5】

請求項１～３のいずれかにおいて、
前記機械学習部は、
承認者を介して承認又は否認の指示に基づき制御された電子メールと、前記機械学習部を利用して承認又は否認の指示に基づき制御された電子メールとを、機械学習の対象にすることを特徴とするプログラム。

【請求項6】

電子メールを配送するサーバのためのプログラムであって、
差出元から送信された電子メールを受け付ける受け付け部と、
所定の条件に基づいて前記電子メールの承認の要否を判定する判定部と、
前記電子メールの承認が必要と判定された場合に、前記電子メールの配送を保留する保留部と、
複数の承認者の少なくとも一の承認者から、保留された前記電子メールの承認指示又は否認指示を受け付ける指示受け付け部と、
前記電子メールの承認が必要と判定された場合であって、前記複数の承認者のうちの一の承認者から最先に受け付けた指示が承認指示である場合に前記電子メールを配送する制御を行う、又は、前記複数の承認者のうちの一の承認者から最先に受け付けた指示が否認指示である場合に前記電子メールの配送を中止する制御を行う配送部と、
保留された電子メールの情報と、当該電子メールの差出元に対応付けた複数の承認者を示すデータとを教師データとして機械学習を行い、当該電子メールの情報と当該複数の承認者を示すデータとを関連付ける予測モデルを生成する機械学習部と、
前記予測モデルを用いて、新たに保留された電子メールについて、適切と推定される１又は複数の承認者を選択する承認者選択部として、コンピュータを機能させることを特徴とするプログラム。

【請求項7】

請求項６において、
前記承認者選択部は、
選択した１又は複数の承認者の行動情報を取得し、１又は複数の承認者を再選択することを特徴とするプログラム。

【請求項8】

電子メールを配送するサーバのためのプログラムであって、
差出元から送信された電子メールを受け付ける受け付け部と、
所定の条件に基づいて前記電子メールの承認の要否を判定する判定部と、
前記電子メールの承認が必要と判定された場合に、前記電子メールの配送を保留する保留部と、
前記電子メールの承認が必要と判定された場合に、複数の承認者のうちの一の代表承認者の選択を受け付ける選択部と、
前記代表承認者に対して、承認要求を通知する通知部と、
前記複数の承認者の少なくとも一の承認者から、保留された前記電子メールの承認指示又は否認指示を受け付ける指示受け付け部と、
前記電子メールの承認が必要と判定された場合であって、前記複数の承認者のうちの一の承認者から最先に受け付けた指示が承認指示である場合に前記電子メールを配送する制
御を行う、又は、前記複数の承認者のうちの一の承認者から最先に受け付けた指示が否認指示である場合に前記電子メールの配送を中止する制御を行う配送部と、
所定期間において保留された電子メールの情報と代表承認者の情報とを教師データとして機械学習を行い、当該電子メールの情報と当該代表承認者の情報とを関連付ける予測モデルを生成する機械学習部と、
前記予測モデルを用いて、新たに保留された電子メールについて、適切と推定される代表承認者を選択する代表承認者選択部として、コンピュータを機能させることを特徴とするプログラム。

【請求項9】

請求項８において、
前記機械学習部は、
保留された電子メールについて代表承認者が変更された場合には、当該電子メールと変更後の代表承認者とを教師データとすることを特徴とするプログラム。

【請求項10】

請求項１～９のいずれかに記載のプログラムを記憶した記憶部と、
前記プログラムを実行するためのプロセッサと、を備えるサーバ。

【請求項11】

電子メールを配送する方法であって、
差出元から送信された電子メールを受け付けるステップと、
所定の条件に基づいて前記電子メールの承認の要否を判定するステップと、
前記電子メールの承認が必要と判定された場合に、前記電子メールの配送を保留するステップと、
複数の承認者の少なくとも一の承認者から、保留された前記電子メールの承認指示又は否認指示を受け付けるステップと、
前記電子メールの承認が必要と判定された場合であって、前記複数の承認者のうちの一の承認者から最先に受け付けた指示が承認指示である場合に前記電子メールを配送する制御を行う、又は、前記複数の承認者のうちの一の承認者から最先に受け付けた指示が否認指示である場合に前記電子メールの配送を中止する制御を行うステップと、
保留された電子メールの情報と、当該電子メールに対する承認者の指示内容とを教師データとして機械学習を行い、当該電子メールの情報と当該指示内容とを関連付ける予測モデルを生成するステップと、
前記予測モデルを用いて、新たに保留された電子メールについて、承認指示又は否認指示を取得するステップと、を含むことを特徴とする方法。

【請求項12】

電子メールを配送する方法であって、
差出元から送信された電子メールを受け付けるステップと、
所定の条件に基づいて前記電子メールの承認の要否を判定するステップと、
前記電子メールの承認が必要と判定された場合に、前記電子メールの配送を保留するステップと、
複数の承認者の少なくとも一の承認者から、保留された前記電子メールの承認指示又は否認指示を受け付けるステップと、
前記電子メールの承認が必要と判定された場合であって、前記複数の承認者のうちの一の承認者から最先に受け付けた指示が承認指示である場合に前記電子メールを配送する制御を行う、又は、前記複数の承認者のうちの一の承認者から最先に受け付けた指示が否認指示である場合に前記電子メールの配送を中止する制御を行うステップと、
保留された電子メールの情報と、当該電子メールの差出元に対応付けた複数の承認者を示すデータとを教師データとして機械学習を行い、当該電子メールの情報と当該複数の承認者を示すデータとを関連付ける予測モデルを生成するステップと、
前記予測モデルを用いて、新たに保留された電子メールについて、適切と推定される１又は複数の承認者を選択するステップと、を含むことを特徴とする方法。

【請求項13】

電子メールを配送する方法であって、
差出元から送信された電子メールを受け付けるステップと、
所定の条件に基づいて前記電子メールの承認の要否を判定するステップと、
前記電子メールの承認が必要と判定された場合に、前記電子メールの配送を保留するステップと、
前記電子メールの承認が必要と判定された場合に、複数の承認者のうちの一の代表承認者の選択を受け付けるステップと、
前記代表承認者に対して、承認要求を通知するステップと、
複数の承認者の少なくとも一の承認者から、保留された前記電子メールの承認指示又は否認指示を受け付けるステップと、
前記電子メールの承認が必要と判定された場合であって、前記複数の承認者のうちの一の承認者から最先に受け付けた指示が承認指示である場合に前記電子メールを配送する制御を行う、又は、前記複数の承認者のうちの一の承認者から最先に受け付けた指示が否認指示である場合に前記電子メールの配送を中止する制御を行うステップと、
所定期間において保留された電子メールの情報と代表承認者の情報とを教師データとして機械学習を行い、当該電子メールの情報と当該代表承認者の情報とを関連付ける予測モデルを生成するステップと、
前記予測モデルを用いて、新たに保留された電子メールについて、適切と推定される代表承認者を選択するステップと、を含むことを特徴とする方法。