(57)【要約】【課題】配信される予定のメールに関連するサービスを提供するサーバーの負荷の状況に応じてメールの配信を制御する情報処理装置を提供する。【解決手段】情報処理装置の取得手段は、配信される予定のメールに関連するサービスを提供するサーバーの現在の負荷に関する情報を取得し、記憶手段は、前記メールが配信された場合に、前記サーバーにかかると想定される負荷を記憶し、制御手段は、前記取得手段が取得した前記サーバーの現在の負荷と、前記記憶手段に記憶された前記サーバーにかかると想定される負荷とに基づいて、前記メールの複数のユーザーに対する配信を制御する。【選択図】図１
2017049754.tif 000002
【特許請求の範囲】
【請求項１】
配信される予定のメールに関連するサービスを提供するサーバーの現在の負荷に関する情報を取得する取得手段と、
前記メールが配信された場合に、前記サーバーにかかると想定される負荷を記憶する記憶手段と、
前記取得手段が取得した前記サーバーの現在の負荷と、前記記憶手段に記憶された前記サーバーにかかると想定される負荷とに基づいて、前記メールの複数のユーザーに対する配信を制御する制御手段と、
を有する情報処理装置。
【請求項２】
前記取得手段は、前記メールに記載された文字列に基づいて、関連するサービスを提供するサーバーを特定する、
請求項１に記載の情報処理装置。
【請求項３】
前記取得手段は、前記メールの属性情報に基づいて、関連するサービスを提供するサーバーを特定する、
請求項１又は２に記載の情報処理装置。
【請求項４】
前記記憶手段は、前記メールが配信された場合に、前記サーバーにアクセスするユーザーの割合と、前記サーバーにかかると想定される負荷とを対応づけて記憶し、
前記制御手段は、前記記憶手段に記憶されたサービスを利用するユーザーの割合を用いて、前記メールの複数のユーザーに対する配信を制御する、
請求項１から３のいずれか一項に記載の情報処理装置。
【請求項５】
前記配信される予定のメールに関連するサービスを提供するサーバーの現在の負荷に関する情報は、前記サーバーが許容可能な負荷に関する情報を含み、
前記制御手段は、前記記憶手段に記憶された負荷が、前記取得した許容可能な負荷を超えない場合にメールを配信するよう制御する、
請求項１から４のいずれか一項に記載の情報処理装置。
【請求項６】
前記取得手段は、前記関連するサービスの代替サービスを提供する前記サーバー又は代替サーバーの許容可能な負荷に関する情報を更に取得し、
前記制御手段は、前記記憶手段に記憶された負荷が前記許容可能な負荷を超える場合であって、前記代替サービスが前記サーバー又は前記代替サーバーの許容可能な負荷を超えない場合には、前記メールに含まれる文字列を、前記サーバー又は前記代替サーバーの代替サービスを利用するための文字列に変更してメールを配信するよう制御する、
請求項１から５のいずれか一項に記載の情報処理装置。
【請求項７】
コンピュータを、
配信される予定のメールに関連するサービスを提供するサーバーの現在の負荷に関する情報を取得する取得手段と、
前記メールが配信された場合に、前記サーバーにかかると想定される負荷を記憶する記憶手段と、
前記取得手段が取得した前記サーバーの現在の負荷と、前記記憶手段に記憶された前記サーバーにかかると想定される負荷とに基づいて、前記メールの複数のユーザーに対する配信を制御する制御手段
として機能させるための情報処理プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理装置及び情報処理プログラムに関する。
【背景技術】
【０００２】
特許文献１には、メッセージングプラットフォーム、例えばｅメール又は音声メールは、オーバーロード状態を検出し、次にプラットフォームのローディングを制御するように動作するオーバーロード制御装置を用意し、オーバーロード制御装置は、例えばサービスプロバイダとメッセージプラットフォームとの間の通信に使用される制御インタフェースと関係し、オーバーロード状態が検出されると、このインタフェース上で受け取られた要求のいくつかを選択的に拒絶できることが開示されている。
【０００３】
特許文献２には、ネットワークの伝送特性や受信端末の処理能力などを考慮して、該端末に送信するデータを適応的に可変制御する分散制御型の通信制御システムを提供することを課題とし、画像データ等の情報を提供するサーバー及びこの情報を取得しようとするクライアントのそれぞれの端末にデータ通信制御を行うためのエージェントをそれぞれ実装するようにし、サーバーとクライアントが接続されるネットワーク上のゲートウェイにもデータ通信を制御するエージェントを設け、これら、エージェントは、互いにダミーパケット等をやり取りするなどの方法で、ネットワークの伝送帯域やその他のネットワークの構成等に関する情報や、クライアントの端末の処理能力等に関する情報を取得し、この情報に基づいてサーバーの端末からクライアントの端末に送信すべきデータを変換して送受信することが開示されている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特表２００２−５３１００６号公報
【特許文献２】特開平１１−０５５３２４号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
本発明は、配信される予定のメールに関連するサービスを提供するサーバーの負荷の状況に応じてメールの配信を制御する情報処理装置及び情報処理プログラムを提供することを目的としている。
【課題を解決するための手段】
【０００６】
かかる目的を達成するための本発明の要旨とするところは、次の各項の発明に存する。
請求項１の発明は、配信される予定のメールに関連するサービスを提供するサーバーの現在の負荷に関する情報を取得する取得手段と、前記メールが配信された場合に、前記サーバーにかかると想定される負荷を記憶する記憶手段と、前記取得手段が取得した前記サーバーの現在の負荷と、前記記憶手段に記憶された前記サーバーにかかると想定される負荷とに基づいて、前記メールの複数のユーザーに対する配信を制御する制御手段と、を有する情報処理装置である。
【０００７】
請求項２の発明は、前記取得手段は、前記メールに記載された文字列に基づいて、関連するサービスを提供するサーバーを特定する、請求項１に記載の情報処理装置である。
【０００８】
請求項３の発明は、前記取得手段は、前記メールの属性情報に基づいて、関連するサービスを提供するサーバーを特定する、請求項１又は２に記載の情報処理装置である。
【０００９】
請求項４の発明は、前記記憶手段は、前記メールが配信された場合に、前記サーバーにアクセスするユーザーの割合と、前記サーバーにかかると想定される負荷とを対応づけて記憶し、前記制御手段は、前記記憶手段に記憶されたサービスを利用するユーザーの割合を用いて、前記メールの複数のユーザーに対する配信を制御する、請求項１から３のいずれか一項に記載の情報処理装置である。
【００１０】
請求項５の発明は、前記配信される予定のメールに関連するサービスを提供するサーバーの現在の負荷に関する情報は、前記サーバーが許容可能な負荷に関する情報を含み、前記制御手段は、前記記憶手段に記憶された負荷が、前記取得した許容可能な負荷を超えない場合にメールを配信するよう制御する、請求項１から４のいずれか一項に記載の情報処理装置である。
【００１１】
請求項６の発明は、前記取得手段は、前記関連するサービスの代替サービスを提供する前記サーバー又は代替サーバーの許容可能な負荷に関する情報を更に取得し、前記制御手段は、前記記憶手段に記憶された負荷が前記許容可能な負荷を超える場合であって、前記代替サービスが前記サーバー又は前記代替サーバーの許容可能な負荷を超えない場合には、前記メールに含まれる文字列を、前記サーバー又は前記代替サーバーの代替サービスを利用するための文字列に変更してメールを配信するよう制御する、請求項１から５のいずれか一項に記載の情報処理装置である。
【００１２】
請求項７の発明は、コンピュータを、配信される予定のメールに関連するサービスを提供するサーバーの現在の負荷に関する情報を取得する取得手段と、前記メールが配信された場合に、前記サーバーにかかると想定される負荷を記憶する記憶手段と、前記取得手段が取得した前記サーバーの現在の負荷と、前記記憶手段に記憶された前記サーバーにかかると想定される負荷とに基づいて、前記メールの複数のユーザーに対する配信を制御する制御手段として機能させるための情報処理プログラムである。
【発明の効果】
【００１３】
請求項１の情報処理装置によれば、配信される予定のメールに関連するサービスを提供するサーバーの負荷の状況に応じてメールの配信を制御することができる。
【００１４】
請求項２の情報処理装置によれば、メールに記載された文字列に基づいて、関連するサービスを提供するサーバーを特定することができる。
【００１５】
請求項３の情報処理装置によれば、メールの属性情報に基づいて、関連するサービスを提供するサーバーを特定することができる。
【００１６】
請求項４の情報処理装置によれば、サービスを利用するユーザーの割合を用いて、メールの配信を制御することができる。
【００１７】
請求項５の情報処理装置によれば、サーバーの許容可能な負荷を超えない場合にメールを配信するよう制御することができる。
【００１８】
請求項６の情報処理装置によれば、サーバーの許容可能な負荷を超える場合は、代替サービスを利用させるようにすることができる。
【００１９】
請求項７の情報処理プログラムによれば、配信される予定のメールに関連するサービスを提供するサーバーの負荷の状況に応じてメールの配信を制御することができる。
【図面の簡単な説明】
【００２０】
【図１】第１の実施の形態の構成例についての概念的なモジュール構成図である。
【図２】本実施の形態を利用したシステム構成例を示す説明図である。
【図３】第１の実施の形態による処理例を示す説明図である。
【図４】第１の実施の形態による処理例を示すフローチャートである。
【図５】第１の実施の形態による処理例を示すフローチャートである。
【図６】回帰率テーブルのデータ構造例を示す説明図である。
【図７】回帰率−影響負荷テーブルのデータ構造例を示す説明図である。
【図８】メール内容−影響負荷テーブルのデータ構造例を示す説明図である。
【図９】第１の実施の形態による処理例を示すフローチャートである。
【図１０】ＣＰＵ負荷テーブルのデータ構造例を示す説明図である。
【図１１】第１の実施の形態による処理例を示す説明図である。
【図１２】第１の実施の形態による処理例を示す説明図である。
【図１３】第１の実施の形態による処理例を示す説明図である。
【図１４】第２の実施の形態の構成例についての概念的なモジュール構成図である。
【図１５】第２の実施の形態による処理例を示す説明図である。
【図１６】本実施の形態を実現するコンピュータのハードウェア構成例を示すブロック図である。
【発明を実施するための形態】
【００２１】
以下、図面に基づき本発明を実現するにあたっての好適な各種の実施の形態の例を説明する。
図１は、第１の実施の形態の構成例についての概念的なモジュール構成図を示している。
なお、モジュールとは、一般的に論理的に分離可能なソフトウェア（コンピュータ・プログラム）、ハードウェア等の部品を指す。したがって、本実施の形態におけるモジュールはコンピュータ・プログラムにおけるモジュールのことだけでなく、ハードウェア構成におけるモジュールも指す。それゆえ、本実施の形態は、それらのモジュールとして機能させるためのコンピュータ・プログラム（コンピュータにそれぞれの手順を実行させるためのプログラム、コンピュータをそれぞれの手段として機能させるためのプログラム、コンピュータにそれぞれの機能を実現させるためのプログラム）、システム及び方法の説明をも兼ねている。ただし、説明の都合上、「記憶する」、「記憶させる」、これらと同等の文言を用いるが、これらの文言は、実施の形態がコンピュータ・プログラムの場合は、記憶装置に記憶させる、又は記憶装置に記憶させるように制御するという意味である。また、モジュールは機能に一対一に対応していてもよいが、実装においては、１モジュールを１プログラムで構成してもよいし、複数モジュールを１プログラムで構成してもよく、逆に１モジュールを複数プログラムで構成してもよい。また、複数モジュールは１コンピュータによって実行されてもよいし、分散又は並列環境におけるコンピュータによって１モジュールが複数コンピュータで実行されてもよい。なお、１つのモジュールに他のモジュールが含まれていてもよい。また、以下、「接続」とは物理的な接続の他、論理的な接続（データの授受、指示、データ間の参照関係等）の場合にも用いる。「予め定められた」とは、対象としている処理の前に定まっていることをいい、本実施の形態による処理が始まる前はもちろんのこと、本実施の形態による処理が始まった後であっても、対象としている処理の前であれば、そのときの状況・状態に応じて、又はそれまでの状況・状態に応じて定まることの意を含めて用いる。「予め定められた値」が複数ある場合は、それぞれ異なった値であってもよいし、２以上の値（もちろんのことながら、すべての値も含む）が同じであってもよい。また、「Ａである場合、Ｂをする」という意味を有する記載は、「Ａであるか否かを判断し、Ａであると判断した場合はＢをする」の意味で用いる。ただし、Ａであるか否かの判断が不要である場合を除く。
また、システム又は装置とは、複数のコンピュータ、ハードウェア、装置等がネットワーク（一対一対応の通信接続を含む）等の通信手段で接続されて構成されるほか、１つのコンピュータ、ハードウェア、装置等によって実現される場合も含まれる。「装置」と「システム」とは、互いに同義の用語として用いる。もちろんのことながら、「システム」には、人為的な取り決めである社会的な「仕組み」（社会システム）にすぎないものは含まない。
また、各モジュールによる処理毎に又はモジュール内で複数の処理を行う場合はその処理毎に、対象となる情報を記憶装置から読み込み、その処理を行った後に、処理結果を記憶装置に書き出すものである。したがって、処理前の記憶装置からの読み込み、処理後の記憶装置への書き出しについては、説明を省略する場合がある。なお、ここでの記憶装置としては、ハードディスク、ＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）、外部記憶媒体、通信回線を介した記憶装置、ＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）内のレジスタ等を含んでいてもよい。
【００２２】
第１の実施の形態である情報処理装置１００は、メール配信基盤としての機能を有しており、図１の例に示すように、インフラ負荷状況監視モジュール１０５、サービス負荷状況監視モジュール１１０、配信メール解析モジュール１１５、配信メール情報記憶モジュール１２０、配信メール生成モジュール１２５、配信スケジューラーモジュール１３０、メール配信モジュール１３５を有している。特に、メール配信における負荷制御に関するものである。
サービス提供装置１５０へのサービス依頼を内容として含めたメール（電子メール）を、ユーザー１９５に配信（送信）することが行われている。サービス提供装置１５０が提供するサービスとして、例えば、ユーザー１９５が管理、利用等している機器（複写機、ファックス、スキャナ、プリンタ、複合機（スキャナ、プリンタ、複写機、ファックス等のいずれか２つ以上の機能を有している画像処理装置）等）の使用状況を閲覧すること、それらの機器の使用料の請求書作成処理等がある。メール内に、それらのサービスを行わせるＵＲＬ（Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｌｏｃａｔｏｒ）が書き込まれており、ユーザー１９５の操作によって、そのＵＲＬが選択された場合は、サービス提供装置１５０がそのサービスを行うものである。一般的に、そのメールを配信すると、受け取った複数のユーザー１９５によってサービス提供装置１５０にサービス依頼が集中し、サービス提供装置１５０を含めたシステム全体の性能低下や、場合によってはサービスの停止を招く可能性がある。なお、サービス提供装置１５０は連携処理サーバー、そのサービス提供装置１５０が提供するサービスは連携サービスとも言われる。
情報処理装置１００は、サービス提供装置１５０の負荷状況に応じて、ユーザー１９５へのメールの配信を制御する。
【００２３】
配信メールの影響負荷とは、対象のメールを配信することにより、各サービス提供装置１５０（又は各サービス）に与える負荷である。
サービス提供装置１５０（又はサービス）の許容負荷とは、サービス提供装置１５０（又はサービス）が許容できる（処理できる）負荷である。
本明細書における影響負荷や許容負荷は、数値として比較可能な値として記載している。つまり、「影響負荷１、許容負荷１００」と記載されている場合、単純に１と１００を比較し、影響負荷は許容負荷内である、とする。
【００２４】
インフラ負荷状況監視モジュール１０５は、配信スケジューラーモジュール１３０と接続されている。インフラ負荷状況監視モジュール１０５は、通信回線やＳＭＴＰ（Ｓｉｍｐｌｅ  Ｍａｉｌ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）サーバー等のインフラの負荷状況を監視する。
【００２５】
サービス負荷状況監視モジュール１１０は、配信スケジューラーモジュール１３０、サービス提供装置Ａ１５０Ａ、サービス提供装置Ｂ１５０Ｂ、サービス提供装置Ｃ１５０Ｃと接続されている。サービス負荷状況監視モジュール１１０は、配信される予定のメールに関連するサービスを提供するサーバーであるサービス提供装置１５０の現在の負荷に関する情報を取得する。サービスを提供するサービス提供装置１５０が複数ある場合は、その複数のサービス提供装置１５０から現在の負荷に関する情報を取得する。サービス提供装置１５０の負荷状況は、サービスの負荷状況ともいえる。
また、サービス負荷状況監視モジュール１１０は、は、メールに記載された文字列に基づいて、関連するサービスを提供するサービス提供装置１５０を特定するようにしてもよい。
また、サービス負荷状況監視モジュール１１０は、メールの属性情報に基づいて、関連するサービスを提供するサービス提供装置１５０を特定するようにしてもよい。
また、「配信される予定のメールに関連するサービスを提供するサービス提供装置１５０の現在の負荷に関する情報」は、そのサービス提供装置１５０が許容可能な負荷に関する情報を含んでいてもよい。
【００２６】
配信メール解析モジュール１１５は、配信メール生成モジュール１２５、配信スケジューラーモジュール１３０と接続されている。配信メール解析モジュール１１５は、配信メール生成モジュール１２５によって生成されたメールの内容を解析し、そのメールによるサービスへ与える影響負荷（予想）を算出する。
【００２７】
配信メール情報記憶モジュール１２０は、配信メール生成モジュール１２５と接続されている。配信メール情報記憶モジュール１２０は、メールが配信された場合に、各サービス提供装置１５０にかかると想定される負荷を記憶する。また、配信メール情報記憶モジュール１２０は、メールを生成するための情報（テンプレート、配信先であるメールアドレス等含む）や過去のメールによる回帰率等を記憶していてもよい。なお、「回帰率」とは、配信したメール内で提示したサービスのうち、配信先のユーザー１９５によって、そのサービスが利用された割合を示すものである。例えば、サービスを行わせるためのＵＲＬが記載されたメール数に対して、そのＵＲＬが選択された回数（サービスが提供された回数）の割合をいう。
また、配信メール情報記憶モジュール１２０は、メールが配信された場合に、サービス提供装置１５０にアクセスするユーザーの割合と、サービス提供装置１５０にかかると想定される負荷とを対応づけて記憶していてもよい
【００２８】
配信メール生成モジュール１２５は、配信メール解析モジュール１１５、配信メール情報記憶モジュール１２０、配信スケジューラーモジュール１３０、メール配信モジュール１３５と接続されている。配信メール生成モジュール１２５は、配信メール情報記憶モジュール１２０に記憶されているメールテンプレート等から配信するメールを生成する。ただし、配信メール生成モジュール１２５での生成に限定はしない。例えば、各サービス提供装置１５０が生成したメールを取得する構成でもよい。また、メール内には、サービスを特定するための記載（例えば、ＵＲＬ等）がある。
【００２９】
配信スケジューラーモジュール１３０は、インフラ負荷状況監視モジュール１０５、サービス負荷状況監視モジュール１１０、配信メール解析モジュール１１５、配信メール生成モジュール１２５、メール配信モジュール１３５と接続されている。配信スケジューラーモジュール１３０は、サービス負荷状況監視モジュール１１０が取得したサービス提供装置１５０の現在の負荷と、配信メール情報記憶モジュール１２０に記憶されたサービス提供装置１５０にかかると想定される負荷とに基づいて、メールの複数のユーザー１９５に対する配信を制御する。ここで「配信を制御する」には、メールを配信すること又は配信しないこと、メールの配信時期、配信するメール数等の決定が含まれる。
また、配信スケジューラーモジュール１３０は、インフラ負荷状況監視モジュール１０５によって取得されたインフラ負荷、サービス負荷状況監視モジュール１１０によって取得されたサービス提供装置１５０の現在の負荷、配信したメールによる予想負荷を考慮したメール配信スケジュールを策定する。
また、配信スケジューラーモジュール１３０は、配信メール情報記憶モジュール１２０に記憶されたサービスを利用するユーザーの割合を用いて、メールの複数のユーザーに対する配信を制御するようにしてもよい。
また、配信スケジューラーモジュール１３０は、配信メール情報記憶モジュール１２０に記憶された負荷が、サービス負荷状況監視モジュール１１０が取得した許容可能な負荷を超えない場合にメールを配信するよう制御するようにしてもよい。
【００３０】
メール配信モジュール１３５は、配信メール生成モジュール１２５、配信スケジューラーモジュール１３０、ユーザー用端末１９０と接続されている。メール配信モジュール１３５は、配信スケジューラーモジュール１３０によって策定されたメール配信スケジュールにしたがって、メールをユーザー用端末１９０に配信する。
【００３１】
サービス提供装置１５０は、情報処理装置１００のサービス負荷状況監視モジュール１１０と接続されている。サービス提供装置１５０は、ユーザー１９５（ユーザー用端末１９０）に対して、サービスを提供する。サービス提供装置１５０が提供するサービスとして、例えば、前述したように、機器の使用状況を閲覧すること、それらの機器の使用料の請求書作成処理があり、これらの他に、電子的な処理であれば、文字認識処理、文書変換処理、文書格納処理等であってもよい。図１では、３つのサービス提供装置１５０を例示しているが、１つであってもよいし、複数のサービス提供装置１５０であってもよい。
ユーザー用端末１９０は、情報処理装置１００のメール配信モジュール１３５と接続されている。ユーザー用端末１９０は、ユーザー１９５によって利用され、情報処理装置１００からのメールを受け取る。また、そのメールに記載された内容に対するユーザー１９５の操作に応じて、サービス提供装置１５０に対してサービスの依頼を行う。例えば、パーソナルコンピュータ、携帯端末（タブレット型携帯端末、スマートフォン、携帯電話等）等がある。図１では、１つのユーザー用端末１９０を例示しているが、１つであってもよいし、複数のユーザー用端末１９０であってもよい。
【００３２】
図２は、本実施の形態を利用したシステム構成例を示す説明図である。
情報処理装置１００、サービス提供装置Ａ１５０Ａ、サービス提供装置Ｂ１５０Ｂ、サービス提供装置Ｃ１５０Ｃ、ユーザー用端末１９０Ａ、ユーザー用端末１９０Ｂ、ユーザー用端末１９０Ｃは、通信回線２９０を介してそれぞれ接続されている。通信回線２９０は、無線、有線、これらの組み合わせであってもよく、例えば、通信インフラとしてのインターネット、イントラネット等であってもよい。また、情報処理装置１００、サービス提供装置１５０による機能は、クラウドサービスとして実現してもよい。
情報処理装置１００は、各ユーザー１９５（ユーザー用端末１９０）にメールを送信する。そのメール内には、サービス提供装置１５０のサービスを提供するための文字列（例えば、ＵＲＬ等）が記載されており、メールを受信したユーザー１９５の操作に応じて、各ユーザー用端末１９０は、サービス提供装置１５０へアクセスし、そのサービスの提供を受けることとなる。情報処理装置１００は、サービス提供装置１５０の現在の負荷状況等に応じて、メールの配信を制御して、サービス提供装置１５０のレンポンスの低下等を防ぐようにする。
【００３３】
図３は、第１の実施の形態による処理例の概略を示す説明図である。情報処理装置１００は、メールの配信を制御し、ユーザー用端末１９０からサービス提供装置１５０へのアクセスによるシステム負荷をコントロールするものである。
情報処理装置１００は、サービス提供装置１５０に対して、サービス提供装置１５０が提供しているサービスの状況をモニタリングする監視処理３１０を行う。そして、インフラやサービスの負荷チェック処理３２０を行い、配信メール３５０の内容を解析し、サービス提供装置１５０への影響を抽出するメール解析処理３３０を行う。インフラやサービスの負荷チェック処理３２０、メール解析処理３３０による処理結果を用いて、配信メール生成＆配信処理３４０を行う。具体的には、サービス提供装置１５０の状況、配信メール３５０の影響を考慮し、配信スケジュールを決定する。その配信スケジュールにしたがって、配信メール３５０をユーザー１９５（ユーザー用端末１９０）に配信処理３６０する。例えば、配信メール３５０として、サービス提供装置１５０が提供するサービスの紹介やお知らせ等がある。
ユーザー用端末１９０は、そのメールを表示し、ユーザー１９５の操作によって、サービス提供装置１５０に対して、配信メールに伴うアクセス３７０を行う。サービス提供装置１５０は、そのサービスの処理を行い、処理結果等をユーザー用端末１９０に返信する。
【００３４】
図４は、第１の実施の形態による処理例（配信スケジュール策定処理例）を示すフローチャートである。
ステップＳ４０２では、インフラ負荷状況監視モジュール１０５は、インフラ負荷より配信可能メール数を算出する。具体的には、通信回線やＳＭＴＰサーバーのインフラ負荷より、配信可能メール数やスループットを算出する。具体例を用いて説明すると、通信回線の帯域の５０％以上利用した場合は、配信可能メール数として１０００通／ｈに制限し、３０％以上利用した場合は、配信可能メール数として２０００通／ｈに制限する。また、ＳＭＴＰサーバーのキューの使用状況が８０％以上である場合は、配信可能メール数として５００通／ｈに制限し、５０％以上である場合は、配信可能メール数として１０００通／ｈに制限する。
なお、対象とするインフラは、通信回線とＳＭＴＰサーバーに限定しているわけではない。その他、サービスを提供するための環境要因を含んでよい。
また、通信回線の負荷は、メール配信基盤のネットワークトラフィックのみに限定しているわけではない。情報処理装置１００とユーザー用端末１９０との間、ユーザー用端末１９０とサービス提供装置１５０との間のトラフィック情報も含んでよい。
また、ＳＭＴＰサーバーの負荷は、そのＳＭＴＰサーバーのキューのみにより算出されるわけではない。ＣＰＵ、メモリ等、ＳＭＴＰサーバーが動作を制限する指標を含んでよい。
また、予め定められた時間毎の配信設定を参照してもよい。そして、メール数ではなく、配信可能バイト数を見積もり（配信可能バイト数を算出し）、バイト数での制限も可能としてよい。
【００３５】
ステップＳ４０４では、インフラ負荷状況監視モジュール１０５は、配信枠があるか否か（配信可能であるか否か）を判断し、配信枠がある場合はステップＳ４０６へ進み、それ以外の場合はステップＳ４０２へ戻る。つまり、配信枠なしの場合（ステップＳ４０４でＮＯ）は、ネットワークやＳＭＴＰサーバーのインフラ負荷を再チェック（次のタイミングまで待機）し、配信枠ありの場合（ステップＳ４０４でＹＥＳ）はステップＳ４０６へ進む。
【００３６】
ステップＳ４０６では、回帰率や配信メールを解析した結果よりサービス影響負荷を算出する。具体的には、回帰率や配信メールを解析し、該当メール配信によりサービス提供装置１５０のサービスへ与える負荷（影響負荷）を算出する。ステップＳ４０６の処理の詳細については、図５の例に示すフローチャートを用いて後述する。
ステップＳ４０８では、サービス許容負荷より配信可能メール数を算出する。具体的には、ＣＰＵ等の情報より、サービス提供装置１５０が許容できる負荷（許容負荷）を算出し、配信可能メール数やスループットを算出する。ステップＳ４０８の処理の詳細については、図９の例に示すフローチャートを用いて後述する。
【００３７】
ステップＳ４１０では、配信枠があるか否かを判断し、配信枠がある場合はステップＳ４１２へ進み、それ以外の場合はステップＳ４０８へ戻る。具体的には、配信枠なしの場合（ステップＳ４１０でＮＯ）は、サービス許容負荷を再チェックし、配信枠ありの場合（ステップＳ４１０でＹＥＳ）はステップＳ４１２へ進む。
ステップＳ４１２では、メール配信モジュール１３５は、ステップＳ４０８の処理結果にしたがって、メールを配信する。
【００３８】
図５は、第１の実施の形態による処理例（図４の例に示したフローチャートのステップＳ４０６の処理例）を示すフローチャートである。
ステップＳ５０２では、配信メール（候補）データを取得する。
ステップＳ５０４では、定期的に配信されるメールであるか否かを判断し、定期的に配信されるメールである場合はステップＳ５０６へ進み、それ以外の場合はステップＳ５１６へ進む。例えば、配信メールに付加されている属性（定期的配信メールか否かを示す属性）によって判断する。
ステップＳ５０６では、既定のメールであるか否かを判断し、既定のメールである場合はステップＳ５１０へ進み、それ以外の場合はステップＳ５０８へ進む。具体的には、予めスケジューリングされていたもの、特定のサービスから目的を指定してアドホックにインプットされたものは、その情報を元にサービス（又はそのサービスのタイプ（種類））を特定する。それらが不明の場合は、メールの内容を解析して、特定する。なお、ステップＳ５０６のかわりにステップＳ５０８の処理を行って、すべての配信メールを解析の対象としてもよい。
【００３９】
ステップＳ５０８では、メール内容を解析する。
ステップＳ５１０では、サービス（又はそのサービスのタイプ）を特定する。
【００４０】
ステップＳ５１２では、回帰率を特定する。例えば、図６に示す回帰率テーブル６００を用いて、回帰率を特定する。図６は、回帰率テーブル６００のデータ構造例を示す説明図である。回帰率テーブル６００は、サービス欄６１０、タイプ欄６２０、回帰率欄６３０を有している。サービス欄６１０は、サービス（サービスの名称、サービスＩＤ（ＩＤｅｎｔｉｆｉｃａｔｉｏｎ）等）を記憶している。タイプ欄６２０は、そのサービスのタイプを記憶している。回帰率欄６３０は、そのサービスのタイプにおける回帰率を記憶している。
【００４１】
ステップＳ５１４では、回帰率の影響負荷を算出する。例えば、図７に示す回帰率−影響負荷テーブル７００を用いて、回帰率の影響負荷を算出する。図７は、回帰率−影響負荷テーブル７００のデータ構造例を示す説明図である。回帰率−影響負荷テーブル７００は、回帰率欄７１０、影響負荷欄７２０を有している。回帰率欄７１０は、回帰率を記憶している。影響負荷欄７２０は、その回帰率の場合における影響負荷を記憶している。
ステップＳ５１６では、メール内容を解析する。
ステップＳ５１８では、影響情報を抽出する。
【００４２】
ステップＳ５２０では、影響サービスを特定する。
ステップＳ５２２では、メール内容の影響負荷を算出する。ステップＳ５１８〜ステップＳ５２２では、メールの内容より、例えば、図８に示すメール内容−影響負荷テーブル８００にあるような影響情報の文字列を抽出する。影響を受けるサービスとその影響負荷を算出する。図８は、メール内容−影響負荷テーブル８００のデータ構造例を示す説明図である。メール内容−影響負荷テーブル８００は、サービス欄８１０、影響情報欄８２０、影響負荷欄８３０を有している。サービス欄８１０は、サービスを記憶している。影響情報欄８２０は、そのサービスに対する影響情報（配信メール内に記載される文字列）を記憶している。影響負荷欄８３０は、そのサービスの影響情報における影響負荷を記憶している。
ステップＳ５２４では、サービス毎の影響負荷を算出する。そして、算出した影響負荷を用いて、配信メールによる各サービスに対する影響負荷を算出する。
【００４３】
なお、図５の例に示すフローチャートでは、ステップＳ５０４で２つの処理に分かれるが、両方の処理を行うようにしてもよい。具体的には、ステップＳ５０２、ステップＳ５０６〜ステップＳ５１４、ステップＳ５１８〜ステップＳ５２２の処理を行い、ステップＳ５１４、ステップＳ５２２で算出された影響負荷を用いて、ステップＳ５２４の処理を行うようにしてもよい。
【００４４】
図６、図７、図８の例に示した回帰率テーブル６００、回帰率−影響負荷テーブル７００、メール内容−影響負荷テーブル８００を用いて、具体的に処理例を説明する。
（例１）配信メールが帳票サービスの督促メールであり、本文に「ｈｔｔｐ：／／ｘｘｘ.ｘｘｘ／ｙｙｙ」が含まれる場合は、以下のように影響負荷を算出する。
回帰率テーブル６００を用いて、帳票サービスの督促メール回帰率は８％である（回帰率テーブル６００の２行目）。したがって、回帰率−影響負荷テーブル７００から、影響負荷は０．３となる（回帰率−影響負荷テーブル７００の１行目）。
また、配信メールを解析した結果（メール解析情報）から、その配信メールには帳票サービスのＵＲＬが含まれているので、メール内容−影響負荷テーブル８００を用いて、影響負荷は０．５となる（メール内容−影響負荷テーブル８００の１行目）。
したがって、この配信メールによって、帳票サービスを提供するサービス提供装置１５０への影響負荷は、「０．３＋０．５  →  ０．８」となる。
【００４５】
（例２）配信メールが申込サービスのお知らせメールで、本文に「オンデマンド帳票」が含まれる場合は、以下のように影響負荷を算出する。
回帰率テーブル６００を用いて、申込サービスのお知らせメール回帰率は２％である（回帰率テーブル６００の３行目）。したがって、回帰率−影響負荷テーブル７００から、申込サービスの影響負荷は０．１となる（回帰率−影響負荷テーブル７００の２行目）。
また、メール解析情報から、その配信メールには帳票サービスの文字列である「オンデマンド帳票」が含まれているので、メール内容−影響負荷テーブル８００を用いて、帳票サービスの影響負荷は０．１となる。したがって、申込サービスへの影響負荷は０．１であり、帳票サービスへの影響負荷は０．１である。このことは、別サービス（申込サービス以外の帳票サービス）への影響も考慮可能であることを示している。
【００４６】
回帰率は、対象サービス、タイプからのみ決定されるわけではなく、配信時間、対象ユーザー等の様々な情報より統計解析した結果から決定してもよい。また、特に解析手法等については限定しない。また、影響負荷を和で求めることに限定するわけではない。
（例２）に示したように、サービスＡ関連の配信メールであっても、影響負荷の算出結果はそのサービスＡに限らない場合がある。また、別サービスへの影響を算出する際に、そのまま適用してもよいし、係数を乗算する等をしてもよい。
配信メールの解析例としては、配信メールの本文に記載されるＵＲＬや文字列、タイトルに含まれる文字列、送信元アドレス等が挙げられるが、特にそれらには限定しない。
算出した影響負荷の情報は、情報処理装置１００が保持するだけでなく、各サービス提供装置１５０のサービス毎に保持し、情報処理装置１００が必要とした都度に問い合わせて、取得する構成としてもよい。
【００４７】
図９は、第１の実施の形態による処理例（図４の例に示したフローチャートのステップＳ４０８の処理例）を示すフローチャートである。
ステップＳ９０２では、サービスのＣＰＵ情報を取得する。
ステップＳ９０４では、サービスの許容負荷を算出する。例えば、図１０に示すＣＰＵ負荷テーブル１０００より許容負荷を算出する。図１０は、ＣＰＵ負荷テーブル１０００のデータ構造例を示す説明図である。ＣＰＵ負荷テーブル１０００は、利用率欄１０１０、許容負荷欄１０２０を有している。利用率欄１０１０は、利用率を記憶している。許容負荷欄１０２０は、その利用率に対応する許容負荷を記憶している。
ステップＳ９０６では、影響サービスがあるか否かを判断し、影響サービスがある場合はステップＳ９０８へ進み、それ以外の場合はステップＳ９１０へ進む。
ステップＳ９０８では、影響サービスの負荷情報を補正する。
ステップＳ９１０では、サービス毎の許容負荷を算出する。
ステップＳ９１２では、配信可能メール数を算出する。
【００４８】
図１０の例に示したＣＰＵ負荷テーブル１０００を用いて、具体的に処理例を説明する。
（例３）ユーザー管理サービスのＣＰＵ利用率が７５％というＣＰＵ状況で、ユーザー管理サービスへの影響を及ぼす可能性のある配信における負荷を確認する場合は、ＣＰＵ負荷テーブル１０００から、ユーザー管理サービスのＣＰＵ利用率が７５％に対応する許容負荷は１００となる（ＣＰＵ負荷テーブル１０００の２行目）。
サービス許容負荷は、サービスのネットワークトラフィックやＣＰＵ、メモリ使用率等のハードウェア負荷、予め設定されたサービスの処理上限等を用いた算出が挙げられるが、特にそれらに限定しているわけではない。サービスの処理を阻害する要因となり得る条件を含んでいればよい。
サービス許容負荷はある特定のサービスに限ったものではない。サービス間での連携があるような場合、その連携するサービスも考慮したサービス許容負荷を算出してもよい。
算出した許容負荷の情報は、情報処理装置１００が保持するだけでなく、各サービス提供装置１５０のサービス毎に保持し、情報処理装置１００が必要とした都度に問い合わせて、取得する構成としてもよい。
【００４９】
図４の例に示したフローチャートのステップＳ４１０について、具体的な処理例を用いて説明する。
（例４）配信メールが１通の場合、配信メールの影響負荷として、申込サービスが０．１であり、帳票サービスが０．１である。そして、各サービスの許容負荷として、申込サービスが１００であり、帳票サービスが１０００であるとする。つまり、その配信メールによる各サービスへの影響負荷は０．１であり、また各サービスが許容可能な負荷は最小で１００（申込サービスの許容負荷）である。したがって、「０．１＜１００」であるため、配信メールによってサービスが受ける影響は許容可能と判断し、配信枠ありと判断する。
（例４）では、１通の配信メールに関しての処理であるが、例えば、メーリングリストのように、受信者が１万人存在する場合は、「０．１×１万⇒１０００」となり、申込サービスの許容負荷を超えるため配信は控えることとなる。
【００５０】
前述のステップＳ４１０の処理では、単純に負荷を比較し、配信する、配信しないを判断しているが、影響負荷と許容負荷より配信スループットを算出し、配信するか否かを判断してもよい。例えば、影響負荷が許容負荷の９０％である場合は、１０００通／ｈで配信すると判断し、影響負荷が許容負荷の３０％である場合は、５０００通／ｈで配信すると判断してもよい。
配信枠の算出ロジックは特に規定しない。（例４）のように、影響負荷が許容負荷内であれば「配信すると判断」してもよいし、また、判定用のテーブルを用いてもよい。
なお、配信枠の有無はシステム全体（サービス提供装置１５０を含めた）で判定する。例えば、（例４）に示す配信メールが１万通存在した場合であっても、配信枠ありと判定されるのは、申込サービスが許容する１０００通までとなる。つまり、サービス提供装置１５０の処理量を限度とした配信メール数としてもよい。
【００５１】
図１１は、第１の実施の形態による処理例を示す説明図である。
図１１（ａ）、（ｂ）の例では、配信メール（Ｍａｉｌ１）１１１０、配信メール（Ｍａｉｌ２）１１２０を示している。そして、配信メール（Ｍａｉｌ１）１１１０は、文字列（オンデマンド帳票）１１１２を含んでいる。配信メール（Ｍａｉｌ２）１１２０は、ＵＲＬ（ｈｔｔｐ：／／ｘｘｘ．ｘｘｘ／ｙｙｙ）１１２２を含んでいる。
図１１（ｃ）は、帳票サービス許容負荷情報テーブル１１３０のデータ構造例を示す説明図である。帳票サービス許容負荷情報テーブル１１３０は、許容負荷欄１１３２、影響情報欄１１３４を有している。許容負荷欄１１３２は、許容負荷を記憶している。影響情報欄１１３４は、影響情報を記憶している。影響情報に対応する許容負荷を記憶している。
図１１（ｄ）は、オンライン申し込みサービス許容負荷情報テーブル１１４０のデータ構造例を示す説明図である。オンライン申し込みサービス許容負荷情報テーブル１１４０は、許容負荷欄１１４２、影響情報欄１１４４を有している。許容負荷欄１１４２は、許容負荷を記憶している。影響情報欄１１４４は、影響情報を記憶している。
図１１（ｅ）は、配信メール解析情報テーブル１１５０のデータ構造例を示す説明図である。配信メール解析情報テーブル１１５０は、メールＩＤ欄１１５２、影響サービス欄１１５４、影響情報欄１１５６、影響負荷欄１１５８を有している。メールＩＤ欄１１５２は、配信メールを、第１の実施の形態において一意に識別するための情報（メールＩＤ）を記憶している。影響サービス欄１１５４は、その配信メールで影響を及ぼすサービスを記憶している。影響情報欄１１５６は、その配信メールに含まれている文字列である影響情報を記憶している。影響負荷欄１１５８は、そのサービスにおける影響負荷を記憶している。
配信判断処理１１７０として、オンライン申し込みサービス許容負荷情報テーブル１１４０の許容負荷値（２）１１４６と、配信メール解析情報テーブル１１５０の影響負荷値（４）１１６２を比べて、「Ｍａｉｌ２はオンライン申し込みサービスの許容負荷を超えるため配信見送り（配信しない）」と判断する。
配信判断処理１１８０として、帳票サービス許容負荷情報テーブル１１３０の許容負荷値（１０）１１３６と、配信メール解析情報テーブル１１５０の影響負荷値（２）１１６０を比べて、「Ｍａｉｌ１は帳票サービスの許容負荷内のため配信」と判断する。
【００５２】
図１２は、第１の実施の形態による処理例を示す説明図である。この例は、サービス詳細状況解析機能を有している。つまり、提供機能レベルでの負荷を把握するものである。サービス提供装置１５０が提供するサービスの機能毎の負荷に対して、メール配信をコントロール可能とするものである。
例えば、同期、非同期の２パターンで情報を提供する機能を持つサービスにおいて、非同期は負荷が低く、同期は負荷が高いような場合、同期処理へのアクセスを増加させるメール配信は控え、非同期処理へのアクセスを促すメール配信は継続する、といった細かい制御が可能となる。
【００５３】
図１２（ａ）、（ｂ）の例では、配信メール（Ｍａｉｌ１）１２１０、配信メール（Ｍａｉｌ２）１２２０を示している。そして、配信メール（Ｍａｉｌ１）１２１０は、文字列（オンデマンド帳票）１２１２を含んでいる。配信メール（Ｍａｉｌ２）１２２０は、ＵＲＬ（ｈｔｔｐ：／／ｘｘｘ．ｘｘｘ／ｙｙｙ）１２２２を含んでいる。
図１２（ｃ）は、帳票サービス許容負荷情報（機能毎テーブル）１２３０のデータ構造例を示す説明図である。帳票サービス許容負荷情報（機能毎テーブル）１２３０は、機能欄１２３２、許容負荷欄１２３４、影響情報欄１２３６を有している。機能欄１２３２は、機能を記憶している。許容負荷欄１２３４は、許容負荷を記憶している。影響情報欄１２３６は、影響情報を記憶している。
図１２（ｄ）は、配信メール解析情報テーブル１２５０のデータ構造例を示す説明図である。配信メール解析情報テーブル１２５０は、メールＩＤ欄１２５２、影響サービス欄１２５４、影響機能欄１２５６、影響情報欄１２５８、影響負荷欄１２６０を有している。メールＩＤ欄１２５２は、メールＩＤを記憶している。影響サービス欄１２５４は、影響サービスを記憶している。影響機能欄１２５６は、影響機能を記憶している。影響情報欄１２５８は、影響情報を記憶している。影響負荷欄１２６０は、影響負荷を記憶している。
配信判断処理１２７０として、許容負荷値（１０）１２３８、影響負荷値（２）１２６４を比べて、「Ｍａｉｌ２は配信」と判断する。
配信判断処理１２８０として、許容負荷値（２）１２４０、影響負荷値（３）１２６２を比べて、「Ｍａｉｌ１は配信見送り（配信しない）」と判断する。
【００５４】
図１３は、第１の実施の形態による処理例を示す説明図である。図１３に示した例は、図１２に示した例の帳票サービス許容負荷情報（機能毎テーブル）１２３０を、静的情報である帳票サービス機能影響情報テーブル１３３０と動的情報である帳票サービス機能許容負荷情報テーブル１３４０に分けたものである。
図１３（ａ）、（ｂ）の例では、配信メール（Ｍａｉｌ１）１３１０、配信メール（Ｍａｉｌ２）１３２０を示している。そして、配信メール（Ｍａｉｌ１）１３１０は、文字列（オンデマンド帳票）１３１２を含んでいる。配信メール（Ｍａｉｌ２）１３２０は、ＵＲＬ（ｈｔｔｐ：／／ｘｘｘ．ｘｘｘ／ｙｙｙ）１３２２を含んでいる。
図１３（ｃ）は、帳票サービス機能影響情報テーブル１３３０のデータ構造例を示す説明図である。帳票サービス機能影響情報テーブル１３３０は、機能欄１３３２、影響情報欄１３３４を有している。機能欄１３３２は、機能を記憶している。影響情報欄１３３４は、影響情報を記憶している。
図１３（ｄ）は、帳票サービス機能許容負荷情報テーブル１３４０のデータ構造例を示す説明図である。
帳票サービス機能許容負荷情報テーブル１３４０は、機能欄１３４２、許容負荷欄１３４４を有している。機能欄１３４２は、機能を記憶している。許容負荷欄１３４４は、許容負荷を記憶している。
この場合、配信メール（Ｍａｉｌ１）１３１０内の文字列（オンデマンド帳票）１３１２と帳票サービス機能影響情報テーブル１３３０から帳票サービス機能許容負荷情報テーブル１３４０の２行目の許容負荷値１３４８を抽出し、配信メール（Ｍａｉｌ２）１３２０内のＵＲＬ（ｈｔｔｐ：／／ｘｘｘ．ｘｘｘ／ｙｙｙ）１３２２と帳票サービス機能影響情報テーブル１３３０から帳票サービス機能許容負荷情報テーブル１３４０の１行目の許容負荷値１３４６を抽出する。
配信判断処理１３７０として、許容負荷値１３４６、影響負荷値１３６４を比べて、「Ｍａｉｌ２は配信」と判断する。
配信判断処理１３８０として、許容負荷値１３４８、影響負荷値１３６２を比べて、「Ｍａｉｌ１は配信見送り（配信しない）」と判断する。
【００５５】
図１４は、第２の実施の形態の構成例についての概念的なモジュール構成図である。
情報処理装置１４００は、インフラ負荷状況監視モジュール１０５、サービス負荷状況監視モジュール１１０、配信メール解析モジュール１１５、配信メール情報記憶モジュール１２０、配信メール生成モジュール１２５、配信スケジューラーモジュール１３０、メール配信モジュール１３５を有している。情報処理装置１４００は、図１の例に示す情報処理装置１００のサービス負荷状況監視モジュール１１０内にフィードバックモジュール１４４０を付加したものである。なお、第１の実施の形態と同種の部位には同一符号を付し重複した説明を省略する。
【００５６】
インフラ負荷状況監視モジュール１０５は、配信スケジューラーモジュール１３０と接続されている。
サービス負荷状況監視モジュール１１０は、フィードバックモジュール１４４０を有しており、配信スケジューラーモジュール１３０、サービス提供装置Ａ１４５０Ａ、サービス提供装置Ｂ１４５０Ｂ、サービス提供装置Ｃ１４５０Ｃと接続されている。サービス負荷状況監視モジュール１１０は、第１の実施の形態のサービス負荷状況監視モジュール１１０と同等の処理を行う。
フィードバックモジュール１４４０は、関連するサービスの代替サービスを提供するサーバーであるサービス提供装置１４５０又は代替のサービス提供装置１４５０の許容可能な負荷に関する情報を取得する。代替サービスを提供するサービス提供装置１４５０は、そのサービス提供装置１４５０自身であってもよいし、他のサービス提供装置１４５０であってもよい。他のサービス提供装置１４５０として、例えば、前者のサービス提供装置１４５０がサービス提供装置Ａ１４５０Ａである場合、サービス提供装置Ｂ１４５０Ｂ等となる。
【００５７】
配信メール解析モジュール１１５は、配信メール生成モジュール１２５、配信スケジューラーモジュール１３０と接続されている。
配信メール情報記憶モジュール１２０は、配信メール生成モジュール１２５と接続されている。
配信メール生成モジュール１２５は、配信メール解析モジュール１１５、配信メール情報記憶モジュール１２０、配信スケジューラーモジュール１３０、メール配信モジュール１３５と接続されている。
【００５８】
配信スケジューラーモジュール１３０は、インフラ負荷状況監視モジュール１０５、サービス負荷状況監視モジュール１１０、配信メール解析モジュール１１５、配信メール生成モジュール１２５、メール配信モジュール１３５と接続されている。配信スケジューラーモジュール１３０は、第１の実施の形態の配信スケジューラーモジュール１３０と同等の処理を行う。
更に、配信スケジューラーモジュール１３０は、配信メール情報記憶モジュール１２０に記憶された負荷が許容可能な負荷を超える場合であって、代替サービスがサービス提供装置１４５０又は代替のサービス提供装置１４５０の許容可能な負荷を超えない場合には、メールに含まれる文字列を、サービス提供装置１４５０又は代替のサービス提供装置１４５０の代替サービスを利用するための文字列に変更してメールを配信するよう制御する。ここで「メールに含まれる文字列」は、当初のサービスを特定するもの、つまり、配信メール情報記憶モジュール１２０に記憶された負荷が許容可能な負荷を超える場合におけるサービスを特定するものである。
【００５９】
メール配信モジュール１３５は、配信メール生成モジュール１２５、配信スケジューラーモジュール１３０、ユーザー用端末１９０と接続されている。
サービス提供装置１４５０は、情報処理装置１４００のサービス負荷状況監視モジュール１１０と接続されている。サービス提供装置１４５０は、情報処理装置１４００のフィードバックモジュール１４４０から、配信できない旨の情報を受け取ると、当初のサービスの代替サービスをフィードバックモジュール１４４０に返す。
ユーザー用端末１９０は、情報処理装置１４００のメール配信モジュール１３５と接続されている。
【００６０】
例えば、以下に示すような処理を行う。
配信を見送られたメール情報をサービス提供装置１４５０へフィードバックし、サービス提供装置１４５０が代替サービスを提供可能としたものである。そして、情報処理装置１４００は、その情報を元にして、配信メールを再作成し、配信の制御を行うものである。
例えば、同期、非同期の２パターンで情報を提供する機能を持つサービス提供装置１４５０において、非同期は負荷が低く、同期は負荷が高いために、同期処理へアクセスさせるメール配信が控えられたことを情報処理装置１４００がサービス提供装置１４５０へフィードバックする。それを受けたサービス提供装置１４５０側が非同期処理用の情報を生成し、非同期処理へのアクセスを代替サービスとして情報処理装置１４００へ提示し、情報処理装置１４００は、非同期処理用のメールを再作成し配信する。
【００６１】
図１５は、第２の実施の形態による処理例を示す説明図である。
帳票サービス提供装置１５５０は、許容負荷テーブル１５６０を記憶している。許容負荷テーブル１５６０は、機能欄１５６２、許容負荷欄１５６４を有している。機能欄１５６２は、機能を記憶している。許容負荷欄１５６４は、許容負荷を記憶している。図１５の例では、機能「帳票公開（同期）」における許容負荷は「２」であるが、機能「帳票公開（非同期）」における許容負荷は「１０」であることを示している。つまり、「帳票公開（同期）」よりも「帳票公開（非同期）」の方が、許容負荷は多いこと（多くの処理が可能であること）を示している。
【００６２】
まず、第１の実施の形態（情報処理装置１００）での処理を比較のために説明する。
ステップＳ１５０２Ａでは、帳票サービス提供装置１５５０が情報処理装置１００に対して、帳票（同期）案内メールの配信を依頼する。
ステップＳ１５０４Ａでは、負荷制御により配信が制御される。
ステップＳ１５０６Ａでは、負荷収束後に遅延して配信する。
ステップＳ１５０８Ａでは、ユーザー用端末１９０が帳票サービス提供装置１５５０に対して、配信メールに伴うアクセスを行う。
したがって、ステップＳ１５０２Ａ〜ステップＳ１５０８Ａの処理によって、配信が遅れ、適切なタイミングでのサービス提供ができない可能性がある。
【００６３】
第２の実施の形態（情報処理装置１４００）での処理を説明する。
ステップＳ１５０２Ｂでは、帳票サービス提供装置１５５０が情報処理装置１４００に対して、帳票（同期）案内メールの配信を依頼する。
ステップＳ１５０４Ｂでは、負荷制御により配信が制御される。
ステップＳ１５０６Ｂでは、情報処理装置１４００が帳票サービス提供装置１５５０に対して、帳票（同期）案内メールが負荷制御により配信制御された情報（配信遅延されること、配信遅延されるサービスを示すＵＲＬや負荷等）をフィードバックする。
【００６４】
ステップＳ１５０８Ｂでは、帳票サービス提供装置１５５０は、非同期帳票は許容負荷に余裕があるため、非同期用の帳票を代替手段として準備する。
ステップＳ１５１０Ｂでは、帳票サービス提供装置１５５０が情報処理装置１４００に対して、代替手段情報（ＵＲＬ等）を提供する。
ステップＳ１５１２Ｂでは、代替手段用のメールを配信する。
ステップＳ１５１４Ｂでは、ユーザー用端末１９０が帳票サービス提供装置１５５０に対して、配信メールに伴うアクセスを行う。
ステップＳ１５０２Ｂ〜ステップＳ１５１４Ｂの処理によって、ステップＳ１５０２Ａ〜ステップＳ１５０８Ａの処理よりも配信の遅延を少なくすることが可能となる。
【００６５】
なお、本実施の形態としてのプログラムが実行されるコンピュータのハードウェア構成は、図１６に例示するように、一般的なコンピュータであり、具体的にはパーソナルコンピュータ、サーバーとなり得るコンピュータ等である。つまり、具体例として、処理部（演算部）としてＣＰＵ１６０１を用い、記憶装置としてＲＡＭ１６０２、ＲＯＭ１６０３、ＨＤ１６０４を用いている。ＨＤ１６０４として、例えばハードディスク、ＳＳＤ（Ｓｏｌｉｄ  Ｓｔａｔｅ  Ｄｒｉｖｅ）を用いてもよい。インフラ負荷状況監視モジュール１０５、サービス負荷状況監視モジュール１１０、配信メール解析モジュール１１５、配信メール生成モジュール１２５、配信スケジューラーモジュール１３０、メール配信モジュール１３５、フィードバックモジュール１４４０等のプログラムを実行するＣＰＵ１６０１と、そのプログラムやデータを記憶するＲＡＭ１６０２と、本コンピュータを起動するためのプログラム等が格納されているＲＯＭ１６０３と、配信メール情報記憶モジュール１２０等の機能を有する補助記憶装置（フラッシュメモリ等であってもよい）であるＨＤ１６０４と、キーボード、マウス、タッチパネル、マイク等に対する利用者の操作に基づいてデータを受け付ける受付装置１６０６と、ＣＲＴ、液晶ディスプレイ、スピーカー等の出力装置１６０５と、ネットワークインタフェースカード等の通信ネットワークと接続するための通信回線インタフェース１６０７、そして、それらをつないでデータのやり取りをするためのバス１６０８により構成されている。これらのコンピュータが複数台互いにネットワークによって接続されていてもよい。
【００６６】
前述の実施の形態のうち、コンピュータ・プログラムによるものについては、本ハードウェア構成のシステムにソフトウェアであるコンピュータ・プログラムを読み込ませ、ソフトウェアとハードウェア資源とが協働して、前述の実施の形態が実現される。
なお、図１６に示すハードウェア構成は、１つの構成例を示すものであり、本実施の形態は、図１６に示す構成に限らず、本実施の形態において説明したモジュールを実行可能な構成であればよい。例えば、一部のモジュールを専用のハードウェア（例えば特定用途向け集積回路（Ａｐｐｌｉｃａｔｉｏｎ  Ｓｐｅｃｉｆｉｃ  Ｉｎｔｅｇｒａｔｅｄ  Ｃｉｒｃｕｉｔ：ＡＳＩＣ）等）で構成してもよく、一部のモジュールは外部のシステム内にあり通信回線で接続しているような形態でもよく、更に図１６に示すシステムが複数互いに通信回線によって接続されていて互いに協調動作するようにしてもよい。また、特に、パーソナルコンピュータの他、携帯情報通信機器（携帯電話、スマートフォン、モバイル機器、ウェアラブルコンピュータ等を含む）、情報家電、ロボット、複写機、ファックス、スキャナ、プリンタ、複合機などに組み込まれていてもよい。
【００６７】
また、前述の実施の形態の説明において、予め定められた値との比較において、「以上」、「以下」、「より大きい」、「より小さい（未満）」としたものは、その組み合わせに矛盾が生じない限り、それぞれ「より大きい」、「より小さい（未満）」、「以上」、「以下」としてもよい。
【００６８】
なお、説明したプログラムについては、記録媒体に格納して提供してもよく、また、そのプログラムを通信手段によって提供してもよい。その場合、例えば、前記説明したプログラムについて、「プログラムを記録したコンピュータ読み取り可能な記録媒体」の発明として捉えてもよい。
「プログラムを記録したコンピュータ読み取り可能な記録媒体」とは、プログラムのインストール、実行、プログラムの流通等のために用いられる、プログラムが記録されたコンピュータで読み取り可能な記録媒体をいう。
なお、記録媒体としては、例えば、デジタル・バーサタイル・ディスク（ＤＶＤ）であって、ＤＶＤフォーラムで策定された規格である「ＤＶＤ−Ｒ、ＤＶＤ−ＲＷ、ＤＶＤ−ＲＡＭ等」、ＤＶＤ＋ＲＷで策定された規格である「ＤＶＤ＋Ｒ、ＤＶＤ＋ＲＷ等」、コンパクトディスク（ＣＤ）であって、読出し専用メモリ（ＣＤ−ＲＯＭ）、ＣＤレコーダブル（ＣＤ−Ｒ）、ＣＤリライタブル（ＣＤ−ＲＷ）等、ブルーレイ・ディスク（Ｂｌｕ−ｒａｙ（登録商標）  Ｄｉｓｃ）、光磁気ディスク（ＭＯ）、フレキシブルディスク（ＦＤ）、磁気テープ、ハードディスク、読出し専用メモリ（ＲＯＭ）、電気的消去及び書換可能な読出し専用メモリ（ＥＥＰＲＯＭ（登録商標））、フラッシュ・メモリ、ランダム・アクセス・メモリ（ＲＡＭ）、ＳＤ（Ｓｅｃｕｒｅ  Ｄｉｇｉｔａｌ）メモリーカード等が含まれる。
そして、前記のプログラム又はその一部は、前記記録媒体に記録して保存や流通等させてもよい。また、通信によって、例えば、ローカル・エリア・ネットワーク（ＬＡＮ）、メトロポリタン・エリア・ネットワーク（ＭＡＮ）、ワイド・エリア・ネットワーク（ＷＡＮ）、インターネット、イントラネット、エクストラネット等に用いられる有線ネットワーク、又は無線通信ネットワーク、更にこれらの組み合わせ等の伝送媒体を用いて伝送させてもよく、また、搬送波に乗せて搬送させてもよい。
更に、前記のプログラムは、他のプログラムの一部分であってもよく、又は別個のプログラムと共に記録媒体に記録されていてもよい。また、複数の記録媒体に分割して記録されていてもよい。また、圧縮や暗号化等、復元可能であればどのような態様で記録されていてもよい。
【符号の説明】
【００６９】
１００…情報処理装置
１０５…インフラ負荷状況監視モジュール
１１０…サービス負荷状況監視モジュール
１１５…配信メール解析モジュール
１２０…配信メール情報記憶モジュール
１２５…配信メール生成モジュール
１３０…配信スケジューラーモジュール
１３５…メール配信モジュール
１５０…サービス提供装置
１９０…ユーザー用端末
１９５…ユーザー
１４００…情報処理装置
１４４０…フィードバックモジュール
１４５０…サービス提供装置
１５５０…帳票サービス提供装置
【図１】
2017049754.tif 000003
【図２】
2017049754.tif 000004
【図３】
2017049754.tif 000005
【図４】
2017049754.tif 000006
【図５】
2017049754.tif 000007
【図６】
2017049754.tif 000008
【図７】
2017049754.tif 000009
【図８】
2017049754.tif 000010
【図９】
2017049754.tif 000011
【図１０】
2017049754.tif 000012
【図１１】
2017049754.tif 000013
【図１２】
2017049754.tif 000014
【図１３】
2017049754.tif 000015
【図１４】
2017049754.tif 000016
【図１５】
2017049754.tif 000017
【図１６】
2017049754.tif 000018