(57)【要約】  複数の通信事業者に加入しているユーザに対して効率的にメッセージの配信を行うことができるようにする。  サービス事業者がユーザを識別するためのユーザ識別子と、該ユーザが加入している通信事業者が該ユーザを識別するためのユーザ識別子とを対応づけたＩＤ連携情報を記憶するＩＤ連携情報記憶部と、サービス事業者から、メッセージの内容と、配信対象として当該サービス事業者におけるユーザ識別子とを受信する配信要求受信部と、ＩＤ連携情報に基づいて、ユーザがどの通信事業者に加入しているかを判定し、加入している通信事業者の中から所定の条件に従い該ユーザに対するメッセージの配信依頼先とする通信事業者を決定する配信要求処理部と、配信依頼先として決定された通信事業者の配信システムに、メッセージの内容と、配信対象として前記ユーザの当該通信事業者におけるユーザ識別子とを送信する配信要求送信部とを備える。
2009022568.tif 000002
【特許請求の範囲】
【請求項１】
通信事業者を介して、サービス事業者がユーザに配信する情報であるメッセージの配信を行う情報配信システムであって、
サービス事業者がユーザを識別するためのユーザ識別子と、該ユーザが加入している通信事業者が該ユーザを識別するためのユーザ識別子とを対応づけた情報であるＩＤ連携情報を記憶するＩＤ連携情報記憶部と、
サービス事業者が運営するサービス提供システムから、メッセージの内容と、該メッセージの配信対象とするユーザを示す情報として当該サービス事業者におけるユーザ識別子とを受信する配信要求受信部と、
前記ＩＤ連携情報記憶部に記憶されているＩＤ連携情報に基づいて、前記メッセージの配信対象として指定されたユーザがどの通信事業者に加入しているかを判定し、ユーザが加入していると判定した通信事業者の中から所定の条件に従い該ユーザに対するメッセージの配信依頼先とする通信事業者を決定する配信要求処理部と、
前記配信要求処理部によって配信依頼先として決定された通信事業者の配信システムに、前記配信要求受信部が受信したメッセージの内容と、該メッセージの配信対象とするユーザを示す情報として当該通信事業者を配信依頼先とするユーザの当該通信事業者におけるユーザ識別子とを送信する配信要求送信部とを備えた
ことを特徴とする情報配信システム。
【請求項２】
配信要求処理部は、複数の通信事業者に加入しているユーザについて、該ユーザが加入している通信事業者のうちのいずれか１つの通信事業者を、メッセージの配信依頼先に決定する
請求項１に記載の情報配信システム。
【請求項３】
配信要求処理部は、複数の通信事業者に加入しているユーザについて、該ユーザが加入している通信事業者のうちの指定された数以内の通信事業者を、メッセージの配信依頼先に決定する
請求項１に記載の情報配信システム。
【請求項４】
配信要求処理部は、複数の通信事業者に加入しているユーザについて、あらかじめ決められている方法に従って、配信依頼先とする通信事業者を決定する
請求項１から請求項３のうちのいずれか１項に記載の情報配信システム。
【請求項５】
配信要求処理部は、複数の通信事業者に加入しているユーザについて、あらかじめ設定されている通信事業者の優先順位に従って、配信依頼先とする通信事業者を決定する
請求項１から請求項４のうちのいずれか１項に記載の情報配信システム。
【請求項６】
配信要求処理部は、あらかじめ設定されている通信事業者の順番に沿って、所定のタイミングで優先順位を入れ替えつつ、複数の通信事業者に加入しているユーザについて、その時点における優先順位に従って、配信依頼先とする通信事業者を決定する
請求項１から請求項４のうちのいずれか１項に記載の情報配信システム。
【請求項７】
配信要求処理部は、複数の通信事業者に加入しているユーザについて、ランダムに配信依頼先とする通信事業者を決定する
請求項１から請求項４のうちのいずれか１項に記載の情報配信システム。
【請求項８】
配信要求処理部は、複数の通信事業者に加入しているユーザについて、あらかじめ設定されている通信事業者に対する配信割合に従って、配信依頼先とする通信事業者を決定する
請求項１から請求項４のうちのいずれか１項に記載の情報配信システム。
【請求項９】
配信要求処理部は、通信事業者の配信システムに問い合わせることによって得られる情報に基づいて、配信依頼先とする通信事業者を決定する
請求項１から請求項４のうちのいずれか１項に記載の情報配信システム。
【請求項１０】
配信要求処理部は、通信事業者の配信システムにメッセージ配信にかかる金額を問い合わせ、その結果得られる通信事業者毎のメッセージ配信にかかる金額に応じて、配信依頼先とする通信事業者を決定する
請求項９に記載の情報配信システム。
【請求項１１】
配信要求処理部は、通信事業者の配信システムにメッセージ配信処理の負荷状態をせ、その結果得られる通信事業者毎のメッセージ配信処理の負荷状態に応じて、配信依頼先とする通信事業者を決定する
請求項９に記載の情報配信システム。
【請求項１２】
配信要求処理部は、通信事業者の配信システムにユーザの利用頻度を問い合わせ、その結果得られる通信事業者毎のユーザの利用頻度に応じて、配信依頼先とする通信事業者を決定する
請求項９に記載の情報配信システム。
【請求項１３】
配信要求処理部は、通信事業者の配信システムにメッセージ配信能力を問い合わせ、その結果得られるメッセージ配信能力に基づき、該通信事業者が配信したいメッセージを配信可能か否かを判定した上で、配信したいメッセージを配信可能な通信事業者の中から、配信依頼先とする通信事業者を決定する
請求項１から請求項１２に記載の情報配信システム。
【請求項１４】
配信要求処理部は、メッセージの配信対象として指定されるユーザについて、該ユーザが加入している通信事業者の配信システムに、該配信システムが保持している該ユーザのメッセージ受信能力を問い合わせ、その結果得られる該通信事業者における該ユーザのメッセージ受信能力に基づき、該ユーザが該通信事業者を介して配信したいメッセージを受信可能か否かを判定した上で、配信したいメッセージを該ユーザに受信させることができる通信事業者の中から、配信依頼先とする通信事業者を決定する
請求項１から請求項１３に記載の情報配信システム。
【請求項１５】
配信要求処理部は、配信依頼先を決定するための方法と、該方法を実施するための条件とを定めた配信先決定ルールに従って、配信依頼先とする通信事業者を決定する
複数の通信事業者に加入しているユーザに対して、ルールに従って通信事業者を決定する
請求項１から請求項４のうちのいずれか１項に記載の情報配信システム。
【請求項１６】
配信先決定ルールに、ユーザのプレゼンス情報にかかる条件が設定され、
配信要求処理部は、通信事業者の配信システムから得られるユーザのプレゼンス情報に基づいて、各ユーザが配信先決定ルールの条件に合致しているか否かを判定することによって、ユーザ毎に配信依頼先とする通信事業者を決定する
請求項１６に記載の情報配信システム。
【請求項１７】
通信事業者を介して、サービス事業者がユーザに配信する情報であるメッセージの配信を行うための配信先制御方法であって、
サービス事業者がユーザを識別するためのユーザ識別子と、該ユーザが加入している通信事業者が該ユーザを識別するためのユーザ識別子とを対応づけた情報であるＩＤ連携情報を保持しておき、
サービス事業者が運営するサービス提供システムから、メッセージの内容と、該メッセージの配信対象とするユーザを示す情報として当該サービス事業者におけるユーザ識別子とを受信し、
前記ＩＤ連携情報記憶部に記憶されているＩＤ連携情報に基づいて、前記メッセージの配信対象として指定されたユーザがどの通信事業者に加入しているかを判定し、ユーザが加入していると判定した通信事業者の中から所定の条件に従い該ユーザに対するメッセージの配信依頼先とする通信事業者を決定し、
配信依頼先として決定された通信事業者の配信システムに、受信したメッセージの内容と、該メッセージの配信対象とするユーザを示す情報として当該通信事業者を配信依頼先とするユーザの当該通信事業者におけるユーザ識別子とを送信する
ことを特徴とする配信先制御方法。
【請求項１８】
複数の通信事業者に加入しているユーザについて、該ユーザが加入している通信事業者のうちのいずれか１つの通信事業者を、メッセージの配信依頼先に決定する
請求項１７に記載の配信先制御方法。
【請求項１９】
複数の通信事業者に加入しているユーザについて、該ユーザが加入している通信事業者のうちの指定された数以内の通信事業者を、メッセージの配信依頼先に決定する
請求項１７に記載の配信先制御方法。
【請求項２０】
通信事業者を介して、サービス事業者がユーザに配信する情報であるメッセージの配信を行うための配信先制御用プログラムであって、
コンピュータに、
サービス事業者が運営するサービス提供システムから、メッセージの内容と、該メッセージの配信対象とするユーザを示す情報として当該サービス事業者におけるユーザ識別子とを受信する処理、
サービス事業者がユーザを識別するためのユーザ識別子と、該ユーザが加入している通信事業者が該ユーザを識別するためのユーザ識別子とを対応づけた情報であるＩＤ連携情報に基づいて、前記メッセージの配信対象として指定されたユーザがどの通信事業者に加入しているかを判定し、ユーザが加入していると判定した通信事業者の中から所定の条件に従い該ユーザに対するメッセージの配信依頼先とする通信事業者を決定する処理、および
配信依頼先として決定された通信事業者の配信システムに、受信したメッセージの内容と、該メッセージの配信対象とするユーザを示す情報として当該通信事業者を配信依頼先とするユーザの当該通信事業者におけるユーザ識別子とを送信する処理
を実行させるための配信先制御用プログラム。
【請求項２１】
コンピュータに、
複数の通信事業者に加入しているユーザについて、該ユーザが加入している通信事業者のうちのいずれか１つの通信事業者を、メッセージの配信依頼先に決定させる
請求項２０に記載の配信先制御用プログラム。
【請求項２２】
コンピュータに、
複数の通信事業者に加入しているユーザについて、該ユーザが加入している通信事業者のうちの指定された数以内の通信事業者を、メッセージの配信依頼先に決定する
請求項２０に記載の配信先制御用プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信事業者を介してメッセージの配信を行う情報配信システム、配信先制御方法、および配信先制御用プログラムに関し、特に、複数の通信事業者に加入しているユーザに対しメッセージを配信する際のメッセージの配信先を制御する情報配信システム、配信先制御方法、および配信先制御用プログラムに関する。
【背景技術】
【０００２】
従来、サービス事業者は、通信事業者の機能を利用してサービスを構築し、例えば、通信事業者がもつユーザのメールアドレスをサービス利用のためのユーザＩＤとして利用し、ユーザにメッセージを送るなどのサービスを提供していた。【０００３】
また、ユーザは、自宅では固定網を使った通信事業者を使う、移動中は移動網を使った通信事業者を使うというように、複数の通信事業者に加入し複数のメールアドレスを持つことが多くなってきている。【０００４】
このような状況下において、サービス事業者が通信事業者に加入しているユーザに対してメッセージの配信を行う際には、サービス事業者が通信事業者にメッセージの配信を依頼し、通信事業者が指定されたユーザに対してメッセージを配信していた。【０００５】
また、ユーザが複数のサービス事業者からサービスを受けている場合、それぞれのサービス毎に別々のユーザＩＤで管理されると、個々のサービスに対してユーザ認証を行うのが面倒であるという問題があった。なお、このような問題を解決するために、例えば、個々のサービスにおけるユーザＩＤを連携させたＩＤ連携情報を利用したシングルサインオン技術が使用されている（非特許文献１参照。）。【０００６】
このようなＩＤ連携に関連する技術として、例えば、特許文献１には、複数のサイトに登録されているユーザＩＤ同士を連結させて、ユーザに関する情報を収集し、収集した結果を配信する技術が記載されている。【０００７】
また、例えば、特許文献２には、様々なサービス事業者用のユーザに関する情報を収集し、収集した情報に基づいて条件に従ったユーザを抽出して、そのユーザにメッセージを配信する技術が記載されている。
【特許文献１】特開２００５−１２８６７２号公報
【特許文献２】特開２００４−５４３１２号公報
【非特許文献１】"Liberty ID-FF Architecture Overview", [online], Liberty Alliance project, [平成１９年８月１５日検索], インターネット<http://www.projectliberty.org/liberty/content/download/318/2366/file/draft-liberty-idff-arch-overview-1.2-errata-v1.0pdf>
【発明の開示】
【発明が解決しようとする課題】
【０００８】
しかし、ユーザが複数の通信事業者に加入している場合に、次のような問題があった。すなわち、ユーザが加入しているそれぞれの事業者から同一のメッセージを受信してしまう可能性がある。また、サービス事業者が、メッセージの配信数に応じて通信事業者に支払いを行う場合、実際に配信したいユーザ数以上の料金を通信事業者に支払うことになってしまう可能性がある。【０００９】
なお、特許文献１に記載されている技術は、ＩＤ連携情報を作成するための技術であって、それをメッセージの配信依頼の割り振りに利用しようということまでは考えられていない。また、特許文献２に記載の技術は、複数のサービス提供事業者からユーザの特性，特徴に関する情報を集めることで、一人一人により望ましい情報を配信できるようにしようということを目的としているのであって、複数の通信事業者に加入しているユーザに対して効率的にメッセージ配信を行うことはできない。【００１０】
そこで、本発明は、複数の通信事業者に加入しているユーザに対して効率的にメッセージの配信を行うことができるようにすることを目的とする。
【課題を解決するための手段】
【００１１】
本発明による情報配信システムは、通信事業者を介して、サービス事業者がユーザに配信する情報であるメッセージの配信を行う情報配信システムであって、サービス事業者がユーザを識別するためのユーザ識別子と、該ユーザが加入している通信事業者が該ユーザを識別するためのユーザ識別子とを対応づけた情報であるＩＤ連携情報を記憶するＩＤ連携情報記憶部と、サービス事業者が運営するサービス提供システムから、メッセージの内容と、該メッセージの配信対象とするユーザを示す情報として当該サービス事業者におけるユーザ識別子とを受信する配信要求受信部と、ＩＤ連携情報記憶部に記憶されているＩＤ連携情報に基づいて、メッセージの配信対象として指定されたユーザがどの通信事業者に加入しているかを判定し、ユーザが加入していると判定した通信事業者の中から所定の条件に従い該ユーザに対するメッセージの配信依頼先とする通信事業者を決定する配信要求処理部と、配信要求処理部によって配信依頼先として決定された通信事業者の配信システムに、配信要求受信部が受信したメッセージの内容と、該メッセージの配信対象とするユーザを示す情報として当該通信事業者を配信依頼先とするユーザの当該通信事業者におけるユーザ識別子とを送信する配信要求送信部とを備えたことを特徴とする。【００１２】
また、本発明による配信先制御方法は、通信事業者を介して、サービス事業者がユーザに配信する情報であるメッセージの配信を行うための配信先制御方法であって、サービス事業者がユーザを識別するためのユーザ識別子と、該ユーザが加入している通信事業者が該ユーザを識別するためのユーザ識別子とを対応づけた情報であるＩＤ連携情報を保持しておき、サービス事業者が運営するサービス提供システムから、メッセージの内容と、該メッセージの配信対象とするユーザを示す情報として当該サービス事業者におけるユーザ識別子とを受信し、ＩＤ連携情報記憶部に記憶されているＩＤ連携情報に基づいて、メッセージの配信対象として指定されたユーザがどの通信事業者に加入しているかを判定し、ユーザが加入していると判定した通信事業者の中から所定の条件に従い該ユーザに対するメッセージの配信依頼先とする通信事業者を決定し、配信依頼先として決定された通信事業者の配信システムに、受信したメッセージの内容と、該メッセージの配信対象とするユーザを示す情報として当該通信事業者を配信依頼先とするユーザの当該通信事業者におけるユーザ識別子とを送信することを特徴とする。【００１３】
また、本発明による配信先制御用プログラムは、通信事業者を介して、サービス事業者がユーザに配信する情報であるメッセージの配信を行うための配信先制御用プログラムであって、コンピュータに、サービス事業者が運営するサービス提供システムから、メッセージの内容と、該メッセージの配信対象とするユーザを示す情報として当該サービス事業者におけるユーザ識別子とを受信する処理、サービス事業者がユーザを識別するためのユーザ識別子と、該ユーザが加入している通信事業者が該ユーザを識別するためのユーザ識別子とを対応づけた情報であるＩＤ連携情報に基づいて、メッセージの配信対象として指定されたユーザがどの通信事業者に加入しているかを判定し、ユーザが加入していると判定した通信事業者の中から所定の条件に従い該ユーザに対するメッセージの配信依頼先とする通信事業者を決定する処理、および配信依頼先として決定された通信事業者の配信システムに、受信したメッセージの内容と、該メッセージの配信対象とするユーザを示す情報として当該通信事業者を配信依頼先とするユーザの当該通信事業者におけるユーザ識別子とを送信する処理を実行させることを特徴とする。
【発明の効果】
【００１４】
本発明によれば、ユーザが複数の通信事業者に加入しているユーザに対して効率的にメッセージの配信を行うことができる。
【発明を実施するための最良の形態】
【００１５】
まず、本発明の実施形態において使用する用語の説明をする。ＩＤとは、通信事業者やサービス事業者などのサービスを利用するユーザを一意に特定する識別子のことである。また、ＩＤ連携とは、ＩＤとＩＤとを関連付けることである。また、認証とは、アクセスしてきたユーザが、本人であることを確認することである。例えば、ユーザＩＤとパスワードによって、ユーザが本人であることを確認することである。また、シングルサインオンとは、あるユーザのＩＤに対して認証が行われると、ＩＤ連携された他のＩＤに対しても認証が行われたとみなすことをいう。例えば、あるユーザが複数にサービスを利用し、それぞれのサービス用に別々のユーザＩＤを持っている場合に、ユーザがあるサービス用のユーザＩＤに対して認証されると、そのサービス以外の他のサービス用のユーザＩＤにたいしても認証されたとみなされ、サービスを利用することができるようになる。もし、シングルサインオンの機能がないとすると、ユーザはそれぞれのサービスに対して、個別に認証作業(例えば、ユーザＩＤとパスワードを入力するなど)が必要になり、不便になってしまう。また、メッセージとは、広告やクーポンなどのサービス事業者がユーザに伝えたい情報であり、文字だけでなく静止画や動画などの画像情報や音声情報などを含む。【００１６】
実施形態１．
以下、本発明の第１の実施形態を図面を参照して説明する。図１は、本発明の第１の実施形態による情報配信システムの概略構成図である。図１に示すように、本実施形態による情報配信システムは、配信要求受信部１１と、配信要求処理部１２と、配信要求送信部１２と、ＩＤ連携情報保持部１２０とを備える。なお、図１におけるサービス提供システム２００は、サービス事業者によって運営されている特定のサービスを提供するシステムであって、メッセージの配信依頼元の例である。また、配信システム４００Ａ，４００Ｂは、通信事業者Ａまたは通信事業者Ｂによって運営されている各々のユーザに対して通信サービスを提供するシステムであって、メッセージの配信依頼先の例である。また、ユーザ端末３００−１〜４は、サービス事業者が提供するサービスを利用するユーザが、通信事業者Ａ、通信事業者Ｂが提供する通信サービスを利用する際に使用している端末であって、メッセージの配信先の例である。【００１７】
なお、図１において、ユーザ端末３００−１は、ユーザ１が通信事業者Ａによって提供される通信サービスを利用する際に使用している端末の例である。また、ユーザ端末３００−２は、ユーザ２が通信事業者Ａによって提供される通信サービスを利用する際に使用している端末の例である。また、ユーザ端末３００−３は、ユーザ３が通信事業者Ｂによって提供される通信サービスを利用する際に使用している端末の例である。また、ユーザ端末３００−４は、ユーザ１が通信事業者Ｂによって提供される通信サービスを利用する際に使用している端末の例である。図１に示す例では、ユーザ１が、通信事業者Ａによる通信サービスと通信事業者Ｂによる通信サービスとを利用していることが示されている。【００１８】
配信要求受信部１１は、サービス事業者が運営するサービス提供システム２００から、メッセージの内容と、該メッセージの配信対象とするユーザを示す情報として当該サービス事業者におけるユーザＩＤとを含むメッセージの配信要求を受信する。【００１９】
配信要求処理部１２は、ＩＤ連携情報記憶部２０に記憶されているＩＤ連携情報に基づいて、メッセージの配信対象として指定されたユーザがどの通信事業者に加入しているかを判定し、ユーザが加入していると判定した通信事業者の中から所定の条件に従い該ユーザに対するメッセージの配信依頼先とする通信事業者を決定する。【００２０】
本実施形態において、ＩＤ連携情報とは、メッセージの配信対象として指定されるユーザを識別するためのユーザＩＤ（すなわち、依頼元となるサービス事業者におけるユーザＩＤ）と、そのユーザが加入している通信事業者におけるユーザＩＤとを連携させた（対応づけた）情報である。なお、あるユーザが複数の通信事業者に加入している場合には、それぞれの通信事業者におけるユーザＩＤと連携される。ＩＤ連携情報保持部１２０は、ＩＤ連携情報を記憶する。ＩＤ連携情報保持部１２０は、例えば、記憶装置によって実現される。【００２１】
配信要求送信部１３は、配信要求処理部１２によって配信依頼先として決定された通信事業者の配信システムに、配信要求受信部１１が受信したメッセージの内容と、該メッセージの配信対象とするユーザを示す情報として当該通信事業者を配信依頼先とするユーザの当該通信事業者におけるユーザＩＤとを含むメッセージの配信要求を送信する。【００２２】
なお、配信要求受信部１１および配信要求送信部１３は、ＬＡＮカード等のネットワークインタフェースとプログラムに従って動作するＣＰＵとによって実現される。また、配信要求処理部１２は、プログラムに従って動作するＣＰＵによって実現される。【００２３】
図２は、図１に示す構成におけるＩＤ連携情報の例を示す説明図である。図２に示す例では、ＩＤ連携情報として、当該情報配信システムに対してメッセージの配信要求を行うサービス事業者における各ユーザＩＤ毎に、そのユーザが加入している通信事業者におけるユーザＩＤを対応づけたＩＤ連携テーブルの例を示している。【００２４】
なお、図２に示す例では、メッセージの配信要求を行うサービス事業者におけるユーザＩＤを” ｕｓｅｒＸ＠ｓｐ．ｃｏｍ”と示し、通信事業者ＡにおけるユーザＩＤを”ｕｓｅｒＸ＠ａ．ｃｏｍ”，通信事業者ＢにおけるユーザＩＤを”ｕｓｅｒＸ＠ｂ．ｃｏｍ”と示している。なお、Ｘにはユーザ１〜３に対応する数値１〜３が入る。【００２５】
配信要求処理部１２は、メッセージの配信対象として指定されたユーザＩＤ（図２に示す例では、サービス事業者におけるユーザＩＤ）に対して、ＩＤ連携情報に登録されている各通信事業者におけるユーザＩＤとの対応づけの有無を判定することによって、そのユーザがどの通信事業者に加入しているかを判定する。例えば、通信事業者ＡにおけるユーザＩＤと対応づけられている場合には、そのユーザは通信事業者Ａに加入していると判定すればよい。また、通信事業者ＢにおけるユーザＩＤと対応づけられている場合には、そのユーザは通信事業者Ｂに加入していると判定すればよい。【００２６】
なお、通信事業者ＡにおけるユーザＩＤしか対応づけられていない場合には、そのユーザは通信事業者Ａにのみ加入していると判定することができる。同様に、通信事業者ＢにおけるユーザＩＤしか対応づけられていない場合には、そのユーザは通信事業者Ｂにのみ加入していると判定することができる。また、通信事業者ＡにおけるユーザＩＤと対応づけられ、かつ通信事業者ＢにおけるユーザＩＤと対応づけられている場合には、そのユーザは、通信事業者Ａおよび通信事業者Ｂに加入していると判定することができる。【００２７】
また、図３は、ＩＤ連携情報の他の例を示す説明図である。図３に示すように、ＩＤ連携情報は、複数のＩＤ連携テーブルによって構成することも可能である。ここで、図３（ａ）は、通信事業者ＡにおけるユーザＩＤ毎に、そのユーザが加入しているサービス事業者（配信制御部１００にメッセージの配信依頼を行うサービス事業者）におけるユーザＩＤを対応づけたＩＤ連携テーブルの例を示している。また、図３（ｂ）は、通信事業者ＢにおけるユーザＩＤ毎に、そのユーザが加入しているサービス事業者（配信制御部１００にメッセージの配信依頼を行うサービス事業者）におけるユーザＩＤを対応づけたＩＤ連携テーブルの例を示している。【００２８】
なお、図１に示す例では、メッセージの配信に用いる配信システムの例として、２つの配信システム（配信システム４００Ａ，４００Ｂ）を例示している。【００２９】
以下、より具体的な構成例を図面を用いて説明する。図４は、図１に示す配信要求受信部１１，配信要求処理部１２，配信要求送信部１３を配信制御部１００によって実現し、その配信制御部１００をシングルサインオン機能を提供するＩＤ管理システムに組み込んだ情報配信システムの構成例を示すブロック図である。図４に示す情報配信システムは、サービス提供システム２００と、配信システム４００Ａと、配信システム４００Ｂと、ＩＤ管理システム７００と、ユーザ端末３００と、サービス提供システム管理者端末８００とによって構成されている。なお、図４に示す例は、サービス提供システム２００のユーザが、配信システム４００Ａおよび配信システム４００Ｂのいずれかまたは両方が提供する通信サービスを利用し、さらにＩＤ管理システム７００が提供するシングルサインオン機能を利用している環境において、サービス提供システム２００を運営しているサービス事業者が該ユーザに対して広告メッセージを配信する場合における情報配信システムの構成例を示している。【００３０】
サービス提供システム２００は、サービス事業者によって運営される特定のサービスを提供するシステムであって、配信依頼送信部２０１と、ユーザ認証部２０２と、サービス提供部２０３とを備える。なお、本例では、サービス提供システム２００のユーザが、広告メッセージの配信対象のユーザとなる。【００３１】
配信システム４００Ａ，４００Ｂは、通信事業者Ａまたは通信事業者Ｂによって運営される、各々のユーザ（各通信事業者におけるユーザ）に対して通信サービスを提供するシステムであって、配信要求受信部４０１と、配信部４０２と、ユーザ認証部４０３と、サービス提供部４０４とを備える。なお、配信システム４００Ａが備える配信要求受信部４０１，配信部４０２，ユーザ認証部４０３，サービス提供部４０４を、配信要求受信部４０１Ａ，配信部４０２Ａ，ユーザ認証部４０３Ａ，サービス提供部４０４Ａと表現する場合がある。また、配信システム４００Ｂが備える配信要求受信部４０１，配信部４０２，ユーザ認証部４０３，サービス提供部４０４を、配信要求受信部４０１Ｂ，配信部４０２Ｂ，ユーザ認証部４０３Ｂ，サービス提供部４０４Ｂと表現する場合がある。【００３２】
ＩＤ管理システム７００は、ＩＤ管理事業者によって運営されるメッセージの配信制御およびシングルサインオンの機能を提供するためのシステムであって、配信制御部１００と、ＩＤ連携情報保持部１２０と、認証実行部７０１とを備える。また、配信制御部１００は、配信依頼受信部１０１と、加入通信事業者判定部１０２と、配信先決定部１０３と、配信要求送信部１０４とを含む。なお、本例においてＩＤ管理事業者は、サービス事業者にとっての広告配信事業者であるとも言える。【００３３】
ユーザ端末３００は、サービス事業者、通信事業者Ａ、通信事業者Ｂが提供するサービスを利用するユーザが使用する端末である。【００３４】
以下、各処理部の機能について説明する。サービス提供システム２００の配信依頼送信部２０１は、ＩＤ管理システム７００の配信制御部１００にメッセージの配信依頼を送信する。ここで、メッセージの配信依頼とは、ＩＤ管理システム７００に対してメッセージの配信を求める情報であって、少なくともメッセージの配信対象とするユーザのユーザＩＤのリストと、メッセージの内容とを含む。なお、メッセージの配信対象とするユーザのユーザＩＤとは、具体的には、サービス提供システム２００においてユーザを識別するために割り当てられたユーザＩＤである。例えば、配信依頼送信部２０１は、サービス提供システム２００の管理者が入力した配信したいユーザのユーザＩＤのリストと、メッセージ内容とを含むメッセージの配信依頼を、ＩＤ管理システム７００（具体的には、配信制御部１００の配信依頼受信部１０１）に送信する。なお、本例では、配信システム４００に対してメッセージの配信を求める情報であるメッセージ配信要求と区別するために、ＩＤ管理システム７００に対してメッセージの配信を求める情報を「メッセージ配信依頼」と呼称している。【００３５】
また、サービス提供部２０３は、ユーザ端末３００からのユーザリクエストに応じて、サービス（当該サービス提供部２０３を備えるシステムとして提供しているサービス）の提供を行う。ここで、サービスリクエストとは、サービスの提供を求める情報であって、少なくともユーザＩＤ（ここでは、ＩＤ管理システム７００の配信制御部１００が認識できるユーザＩＤ）を含む。なお、サービス提供部２０３は、サービスリクエストを受け付けた場合に、その要求元のユーザについてユーザ認証部２０２に認証を依頼し、正しく認証されたユーザに対してのみサービスを提供する。また、ユーザ認証部２０２は、サービス提供部２０３がサービスリクエストを受け付けた場合に、その要求元のユーザを認証する。なお、本実施形態では、ＩＤ管理システム７００の認証実行部７０１に、そのユーザが認証済みであるか否かを確認することによって、ユーザの認証を行う。【００３６】
なお、配信システム４００Ａ，４００Ｂにおけるユーザ認証部４０３およびサービス提供部４０４の機能は、上記サービス提供システム２００におけるユーザ認証部２０２とサービス提供部２０３と同様である。【００３７】
配信システム４００Ａ，４００Ｂの配信要求受信部４０１は、当該配信システムにおけるユーザに対するメッセージの配信要求を受け付ける。配信部４０２は、配信要求受信部４０１が受け付けたメッセージの配信要求に従って、メッセージ内容を該当するユーザ端末３００（具体的には、要求されたユーザＩＤと対応づけられているユーザ端末３００）に配信する。【００３８】
ＩＤ管理システム７００の認証実行部７０１は、当該システムにアクセスしてきたユーザ端末３００に対してユーザの認証を行うとともに、シングルサインオンサービスを提携しているシステム（ここでは、サービス提供システム２００と配信システム４００Ａと配信システム４００Ｂ）からの依頼により、既にそのユーザが認証済みであるか否かを確認する機能を有する。認証実行部７０１は、ＩＤ連携情報保持部１２０が保持しているＩＤ連携情報を参照して、各システムにアクセスしてきたユーザが認証ずみであるか否かを判定する。【００３９】
配信制御部１００の配信依頼受信部１０１は、サービス提供システム２００の配信依頼送信部２０１からメッセージの配信依頼を受け付ける（受信する）。通信事業者ユーザ取得部１０２は、配信依頼受信部１０１が受け付けたメッセージの配信制御依頼に含まれるユーザＩＤのリストが示す配信対象として指定されたユーザについて、ＩＤ連携情報を参照して、そのユーザがどの通信事業者に加入しているかを判定する。そして、各ユーザがどの通信事業者に加入しているかを示す情報を配信先決定部１０３に出力する。なお、各ユーザがどの通信事業者に加入しているかを示す情報とは、例えば、配信対象として指定されたユーザのユーザＩＤに対して、そのユーザが加入している通信事業者におけるユーザＩＤを対応づけた情報であってもよいし、各通信事業者ごとに、その通信事業者に加入しているユーザの配信対象として指定されたユーザＩＤ（ここでは、サービス提供システム２００におけるユーザＩＤ）のリストであってもよい。【００４０】
配信先決定部１０３は、通信事業者ユーザ取得部１０２から入力される各ユーザがどの通信事業者に加入しているかを示す情報に基づいて、各ユーザに対しどの通信事業者に配信依頼を出すかを決定する。配信要求送信部１０４は、配信先決定部１０３によって決定された依頼先配信システムに従って、各配信システムに、その配信システムにおけるユーザへのメッセージの配信要求を行う。配信要求送信部１０４は、例えば、各配信システムの配信要求受信部４０１に、その配信システムを配信先配信システムとする旨が決定されたユーザの該配信システムにおけるユーザＩＤのリストと、メッセージ内容とを含むメッセージ配信要求を送信することによって、メッセージの配信要求を行ってもよい。【００４１】
配信システム４００Ａ，４００Ｂの配信要求受信部４０１は、配信制御部１００からメッセージの配信要求を受け付ける。配信部４０２は、配信要求受信部４０１が受け付けたメッセージの配信要求に応じて、メッセージ内容をユーザＩＤで示されたユーザのユーザ端末３００に配信する。例えば、配信部４０２は、指定されたユーザＩＤを宛先としてメッセージの送信を行うことによって、そのユーザＩＤと対応づけられたユーザ端末３００にメッセージが到達するようにすればよい。【００４２】
ユーザ端末３００は、ＩＤ管理システム７００（具体的には、認証実行部７０１）と通信して認証処理を行ったり、配信システム４００Ａ，配信システム４００Ｂ，またはサービス提供システム２００のいずれか、またはそれら２以上のシステムのサービス提供部と通信してサービスを受けたり、配信システム４００Ａ，配信システム４００Ｂのいずれかまたは両方の配信部からのメッセージを受信したりする、ユーザに表示する機能を備える。なお、本システムにおいて、少なくとも１台以上のユーザ端末３００は、配信システム４００Ａおよび配信システム４００Ｂのサービス提供部４０４と通信し、サービスを受ける機能と、配信システム４００Ａおよび配信システム４００Ｂの配信部４０２と通信し、メッセージ内容を受信し、ユーザに表示する機能を備えているものとする。【００４３】
サービス提供システム管理端末８００は、サービス提供システム２００の管理者からの、ユーザに配信したいメッセージの内容と配信したいユーザに関する情報を受け付け、配信依頼送信部２０１に送信する。【００４４】
次に、本実施形態の動作について説明する。なお、本実施形態の動作は、以下のような前提で説明することとする。
・ユーザは、５名存在する。それぞれをｕｓｅｒ１〜５と表記して識別する。
・ｕｓｅｒ１〜５は、サービス事業者のサービスに加入しており、サービス事業者のサービス提供システム２００内では、ｕｓｅｒ１〜５を、それぞれ”ｕｓｅｒＸ＠ｓｐ．ｃｏｍ”（Ｘにはｕｓｅｒ１〜５に対応する数値１〜５が入る。以下、同じ。）というユーザＩＤで識別している。
・ｕｓｅｒ１〜３は、通信事業者Ａに加入している。通信事業者Ａの配信システム４００Ａ内では、ｕｓｅｒ１〜３を、それぞれ”ｕｓｅｒＸ＠ａ．ｃｏｍ”というユーザＩＤで識別している。
・ｕｓｅｒ１，３〜５は通信事業者Ｂに加入している。通信事業者Ｂの配信システム４００Ｂ内では、ｕｓｅｒ１，３〜５を、それぞれ”ｕｓｅｒＸ＠ｂ．ｃｏｍ”というユーザＩＤで識別している。以下、配信システム４００ＢにおけるユーザＩＤをユーザＩＤ＃４００Ｂと表記する場合がある。また、配信システム４００におけるユーザＩＤを総称してユーザＩＤ＃４００と表記する場合がある。
・ｕｓｅｒ１〜５はＩＤ管理事業者のＩＤ管理システム７００内で、”ｕｓｅｒＸ＠ｉｄｐ．ｃｏｍ”というユーザＩＤで識別されている。【００４５】
なお、それぞれのシステムにおけるユーザＩＤを区別するために、サービス提供システム２００におけるユーザＩＤをユーザＩＤ＃２００と表記し、配信システム４００ＡにおけるユーザＩＤをユーザＩＤ＃４００Ａと表記し、配信システム４００ＢにおけるユーザＩＤをユーザＩＤ＃４００Ｂと表記し、ＩＤ管理システム７００におけるユーザＩＤをユーザＩＤ＃７００と表記する場合がある。また、いずれの配信システム４００におけるユーザＩＤを総称してユーザＩＤ＃４００と表記する場合がある。【００４６】
次に、本例において保持されるＩＤ連携情報について説明する。図５は、本例においてＩＤ連携情報として保持される情報の例を示す説明図である。図５に示すように、本例におけるＩＤ連携情報として、ＩＤ管理システム７００におけるユーザＩＤ（ユーザＩＤ＃７００）に対して、配信システム４００ＡにおけるユーザＩＤ（ユーザＩＤ＃４００Ａ）と、配信システム４００ＢにおけるユーザＩＤ（ユーザＩＤ＃４００Ｂ）と、サービス提供システム２００におけるユーザＩＤ（ユーザＩＤ＃７００）とを対応づけた情報を保持することとする。これは、少なくともユーザＩＤ＃２００は、ユーザＩＤ＃７００とのＩＤ連携を介して、そのユーザが加入している通信事業者に応じてユーザＩＤ＃４００とＩＤ連携されることを示している。これにより、ｕｓｅｒ１〜５は、ＩＤ管理システム７００から認証を受けると、サービス提供システム２００や配信システム４００Ａや配信システム４００Ｂに対しても認証を受けたとして扱われることが可能になる（シングルサインオンが可能になる）。なお、ＩＤ管理システム７００が、サービス提供システム２００のサービス事業者だけでなく、他のサービス提供システムのサービス事業者に対してもメッセージ配信制御サービスを提供する場合には、ユーザＩＤ＃７００とユーザＩＤ＃２００とが１対１で対応しない場合がある。なお、ＩＤ管理システム７００が、１つのサービス事業者にだけメッセージ配信制御サービスを提供する場合には、ユーザＩＤ＃７００を介さずに、ユーザＩＤ＃２００とユーザＩＤ＃４００とを対応づけた情報をＩＤ連携情報として保持するようにしてもよい。そのような場合には、ＩＤ管理システム７００は、ユーザＩＤ＃２００をもって、ユーザの認証管理を行えばよい（すなわち、ユーザＩＤ＃７００をユーザＩＤ＃２００と同一の情報として扱えばよい）。【００４７】
本実施形態では、大きく３つの動作に分けられる。ＩＤ連携の動作と、ＩＤ連携を用いた認証とサービス提供の動作と、ＩＤ連携を用いた広告配信の動作である。【００４８】
まず、ＩＤ連携の動作について説明する。ここでは、あるユーザがＩＤ管理システム７００におけるユーザＩＤ（ユーザＩＤ＃７００）と、配信システム４００ＡにおけるユーザＩＤ（ユーザＩＤ＃４００Ａ）とでＩＤ連携を行う際の動作を例に説明する。また、ユーザ端末３００では、標準的なリダイレクト（要求の転送）機能を持つＷＷＷブラウザを利用するものとする。【００４９】
まず、ユーザ端末３００は、ユーザ操作に応じて、ＩＤ管理システム７００にアクセスし、ユーザＩＤ＃７００に対してユーザの認証を受ける（ステップＳ０−１）。ＩＤ管理システム７００の認証実行部７０１は、ユーザ端末３００からのアクセスに応じて、例えば、ユーザＩＤ＃７００（例えば、”ｕｓｅｒ１＠ｉｄｐ．ｃｏｍ”）と、そのユーザＩＤ＃７００に対応するユーザ認証のための情報（パスワード等）の入力を促す画面情報をユーザ端末３００に送信することによって、ユーザ端末３００からユーザＩＤ＃７００とユーザ認証のための情報とを受け取り、それらを予め登録されているユーザ情報と比較することによって、そのユーザが正規のユーザであるか否かを確認すればよい。なお、ＩＤ管理システム７００におけるユーザＩＤ＃７００と、そのユーザＩＤ＃７００に対してユーザ認証のための情報とは、初めてＩＤ管理システム７００にアクセスした際に、ユーザによって設定できるようになっていてもよい。ユーザが正規のユーザであることが確認できた場合、認証実行部７０１は、その旨を知らせるとともに、認証したユーザＩＤに関する認証情報をユーザ端末３００に保持させる。なお、認証情報には、認証されたユーザＩＤ＃７００を特定できる情報を含める。なお、その認証が有効な期間を示す情報などを含めてもよい。【００５０】
続いて、ユーザ端末３００は、ユーザ操作に応じて、配信システム４００Ａにアクセスする（ステップＳ０−２）。この際、ユーザはユーザＩＤ＃４００Ａ（例えば、”ｕｓｅｒ１＠ａ．ｃｏｍ”）を入力する。配信システム４００Ａのサービス提供部４０４Ａは、ユーザ認証部４０３Ａに、入力されたユーザＩＤ＃４００Ａに対して、ユーザを認証するように依頼する（ステップＳ０−３）。ユーザ認証部４０３Ａは、サービス提供部４０４Ａから受け付けたユーザＩＤ＃４００Ａを指定した認証確認依頼をＩＤ管理システム７００の認証実行部７０１に送信する（ステップＳ０−４）。【００５１】
ＩＤ管理システム７００の認証実行部７０１は、依頼されたユーザＩＤ＃４００Ａを元にＩＤ連携情報を参照し、ユーザＩＤ＃４００Ａについて、ユーザＩＤ＃７００（ここでは、認証管理をしているユーザＩＤの意。）とＩＤ連携されていないことによって認証の確認ができない旨を返信する（ステップＳ０−５）。【００５２】
配信システム４００Ａのユーザ認証部４０３Ａは、ＩＤ連携されていないことによって認証の確認ができない旨を示す情報を受け取ると、ユーザ端末３００にユーザＩＤが連携されていない旨を示す情報を送信して、その旨をユーザに提示させる（ステップＳ０−６）。例えば、ユーザ認証部４０３は、サービス提供部４０４を介してユーザＩＤが連携されていない旨を提示するとともにユーザＩＤの連携を行うかを問い合わせる画面情報を送信するようにしてもよい。【００５３】
ユーザ端末３００は、ユーザの指示に応じて、配信システム４００ＡにＩＤ連携を要求する旨の情報（ＩＤ連携要求）を送信する（ステップＳ０−７）。【００５４】
配信システム４００Ａのユーザ認証部４０３Ａは、ＩＤ連携要求を受け取ると、当該配信システム４００Ａにおけるユーザ認証を実行した上で、ユーザが正しく認証された場合には、そのユーザＩＤ＃４００を指定したＩＤ連携要求を、ＩＤ管理システム７００の認証実行部７０１にリダイレクトされるような情報にして、ユーザ端末３００に返信する（ステップＳ０−８）。【００５５】
ユーザ端末３００は、配信システム４００Ａにおいて認証されたユーザＩＤ＃４００を指定したＩＤ連携要求を、ＩＤ管理システム７００の認証実行部７０１にリダイレクトによって送信する（ステップＳ０−９）。【００５６】
ＩＤ管理システム７００の認証実行部７０１は、ユーザ端末３００からＩＤ連携要求を受け取ると、そのユーザ端末３００で保持されているユーザＩＤ＃７００に関する認証情報（ステップＳ０−１において認証実行部７０１がユーザＩＤ＃７００に対してユーザ認証を行ったことにより生成される認証情報）を確認し、その認証情報からユーザＩＤ＃７００を特定する。そして、ＩＤ連携情報保持部１２０に、指定されたユーザＩＤ＃４００Ａと、認証情報から特定したユーザＩＤ＃７００とを対応づけてＩＤ連携情報として登録する（ステップＳ０−１０）。すなわち、上記例において、”ｕｓｅｒ１＠ｉｄｐ．ｃｏｍ”と”ｕｓｅｒ１＠ａ．ｃｏｍ”とがＩＤ連携されることになる。【００５７】
同様に、配信システム４００Ｂやサービス提供システム２００にアクセスすることによって、認証情報から特定されるユーザＩＤ＃７００と、ユーザＩＤ＃４００ＢやユーザＩＤ＃２００とを対応づけることができる。なお、メッセージの配信制御を行うためには、ＩＤ連携情報保持部１２０に少なくともメッセージの配信先として指定されるユーザのユーザＩＤとそのユーザが加入している通信システムにおけるユーザＩＤとが対応づけられているＩＤ連携情報が保持されていればよく、例えば、ユーザの同意を得て各ユーザＩＤを入力することによって作成されてもよい。【００５８】
次に、ＩＤ連携を用いた認証とサービス提供の動作について説明する。ここでは、あるユーザがサービス提供システム２００にアクセスする際の動作を例に説明する。【００５９】
まず、ユーザ端末３００は、サービス提供システム２００のサービスを利用するために、ＩＤ管理システム７００にアクセスして、そのユーザに割り当てられているユーザＩＤ＃７００に対する認証を受ける（ステップＳ１−１）。なお、ＩＤ管理システム７００におけるユーザ認証動作は、ステップＳ０−１と同様でよい。【００６０】
続いて、ユーザ端末３００は、ユーザ操作に応じて、サービス提供システム２００にアクセスする（ステップＳ１−２）。この際、ユーザはユーザＩＤ＃２００（例えば、”ｕｓｅｒ１＠ｓｐ．ｃｏｍ”）を入力する。サービス提供システム２００のサービス提供部２０３は、ユーザ認証部２０２に、入力されたユーザＩＤ＃２００に対して、ユーザを認証するように依頼する（ステップＳ１−３）。ユーザ認証部４０３Ａは、サービス提供部２０３から受け付けたユーザＩＤ＃２００を指定した認証確認依頼をＩＤ管理システム７００の認証実行部７０１に送信する（ステップＳ１−４）。【００６１】
ＩＤ管理システム７００の認証実行部７０１は、認証確認依頼を受け取ると、ＩＤ連携情報保持部１２０を参照し、指定されたユーザＩＤ＃２００（ここでは、”ｕｓｅｒ１＠ｓｐ．ｃｏｍ”）とＩＤ連携されている当該ＩＤ管理システム７００におけるユーザＩＤ＃７００を得る（ステップＳ１−５）。ここでは、”ｕｓｅｒ１＠ｉｄｐ．ｃｏｍ”を得たとする。そして、認証実行部７０１は、得られたユーザＩＤ＃７００が認証済みであるか否かを確認し、本例では、ステップＳ１−１によって既に認証済みであることから、指定されたユーザＩＤ＃２００も認証済みとみなし、サービス提供システム２００のユーザ認証部２０２に、指定されたユーザＩＤ＃２００は認証済みである旨の情報を含む認証確認応答を送信する（ステップＳ１−６）。【００６２】
サービス提供システム２００のユーザ認証部２０２は、ＩＤ管理システム７００の認証実行部７０１から、指定したユーザＩＤ＃２００が認証済みである旨の情報を受信すると、サービス提供部２０３に、アクセスしてきたユーザが正しく認証されたことを通知する（ステップＳ１−７）。なお、指定したユーザＩＤ＃２００が認証済みでない旨の情報が受信された場合には、ユーザ認証部２０２は、例えば、ＩＤ管理システム７００でのユーザ認証を促す画面情報をユーザ端末３００に送信してサービス提供を拒否してもよいし、当該サービス提供システム２００においてユーザ認証を行うための情報の入力を促す画面情報を送信して独立してユーザ認証を行うようにしてもよい。【００６３】
サービス提供部２０３は、ユーザ認証部２０２からアクセスしてきたユーザが正しく認証されると、そのユーザにサービスを提供する（ステップＳ１−８）。【００６４】
なお、上記動作は、ユーザが、通信事業者Ａの配信システム４００Ａや通信事業者Ｂの配信システム４００Ｂのサービス提供部４０４にアクセスする場合も同様である。なお、ＩＤ管理システム７００がユーザＩＤ＃２００をもって、ユーザの認証管理を行っている場合には、ステップＳ１−１において入力されるユーザＩＤがユーザＩＤ＃２００となる。また、ステップＳ１−５においてＩＤ連携情報を参照してユーザＩＤ＃７００を得る必要はない。すなわち、指定されたユーザＩＤ＃２００をそのまま用いて認証済みであるか否かを確認すればよい。なお、シングルサインオン機能を実装しない場合には、ユーザ認証部２０２がサービス提供部２０３からの要求に応じて、独立してユーザ認証を行えばよい。【００６５】
次に、ＩＤ連携を用いた広告配信の動作について説明する。図６は、ＩＤ連携を用いて広告を配信する場合の配信制御部１００の動作例を示すフローチャートである。【００６６】
配信依頼受信部１０１は、サービス提供システム２００の配信依頼送信部２０１から広告配信してほしいメッセージの内容と広告配信してほしいユーザＩＤ＃２００のリストを配信要求（配信依頼）として受け取ると、通信事業者ユーザ取得部１０２に受け取ったユーザＩＤ＃２００のリストを送信する（ステップＳ２−１）。ここでは、｛”ｕｓｅｒ１＠ｓｐ．ｃｏｍ”，”ｕｓｅｒ２＠ｓｐ．ｃｏｍ”，”ｕｓｅｒ３＠ｓｐ．ｃｏｍ”，”ｕｓｅｒ４＠ｓｐ．ｃｏｍ”，”ｕｓｅｒ５＠ｓｐ．ｃｏｍ”｝（ｕｓｅｒ１〜５に対応するユーザＩＤ＃２００を含んだリスト）を受け取ったとする。【００６７】
通信事業者ユーザ取得部１０２は、配信対象として指定された各ユーザがどの通信事業者に加入しているかを判定する。通信事業者ユーザ取得部１０２は、例えば、受け取ったユーザＩＤ＃２００のリストに含まれる全ユーザを対象に、ＩＤ連携している各通信事業者について以下の処理を行う（ステップＳ２−２）。【００６８】
例えば、通信事業者Ａについて、通信事業者ユーザ取得部１０２は、「通信事業者Ａに加入しているユーザ」のリスト（加入ユーザリスト）を得る（ステップＳ２−２−１）。通信事業者ユーザ取得部１０２は、ＩＤ連携情報を参照し、指定されたユーザＩＤ＃２００に対して、配信システム４００ＡにおけるユーザＩＤ＃４００ＡがＩＤ連携されている場合に、そのユーザＩＤ＃２００のユーザを「通信事業者Ａに加入しているユーザ」と判定する。なお、ユーザＩＤ＃２００とユーザＩＤ＃４００ＡとがＩＤ連携されている場合とは、直接に対応づけられている場合だけでなく、例えば、ユーザＩＤ＃７００を介して対応づけられている場合も含む。【００６９】
本例では、図６を見ると、広告配信してほしいリストに含まれるユーザＩＤ＃２００のうち、配信システム４００ＡにおけるユーザＩＤ＃４００とＩＤ連携されているのは、”ｕｓｅｒ１＠ｓｐ．ｃｏｍ”と”ｕｓｅｒ２＠ｓｐ．ｃｏｍ”と”ｕｓｅｒ３＠ｓｐ．ｃｏｍ”（すなわちｕｓｅｒ１〜３のユーザＩＤ）である。この「通信事業者Ａに加入しているユーザ」の集合を集合Ａとする。【００７０】
また、通信事業者ユーザ取得部１０２は、通信事業者Ｂについても、「通信事業者Ｂに加入しているユーザ」のリスト（加入ユーザリスト）を得る（ステップＳ２−２−１）。ここでは、「通信事業者Ｂに加入しているユーザ」として、”ｕｓｅｒ１＠ｓｐ．ｃｏｍ”と”ｕｓｅｒ３＠ｓｐ．ｃｏｍ”と”ｕｓｅｒ４＠ｓｐ．ｃｏｍ”と”ｕｓｅｒ５＠ｓｐ．ｃｏｍ” （すなわちｕｓｅｒ１，３〜５のユーザＩＤ）を得る。この「通信事業者Ｂに加入しているユーザ」の集合を集合Ｂとする。通信事業者ユーザ取得部１０２は、このようにして得られた各通信事業者の加入ユーザリストを、配信対象として指定された各ユーザがどの通信事業者に加入しているかを示す情報として、配信先決定部１０３に送信する（ステップＳ２−３）。【００７１】
配信先決定部１０３は、通信事業者ユーザ取得部１０２から配信対象として指定された各ユーザがどの通信事業者に加入しているかを示す情報を受け取ると、各ユーザに対しどの通信事業者に配信依頼を出すかを決定する。本例では、通信事業者Ａ＞通信事業者Ｂという優先順位で、重複なく配信を行うという設定がされているものとする。配信先決定部１０３は、各通信事業者について、以下の処理を行うことによって、各通信事業者に配信依頼するユーザを決定する（ステップＳ２−４）。なお、配信先決定部１０３は、各通信事業者について、その通信事業者に配信依頼するユーザを決定することによって、各ユーザに対しどの通信事業者に配信依頼を出すかを決定している。まず、通信事業者の優先順位を確認し（ステップＳ２−４−１）、最も高い通信事業者について、その通信事業者に配信依頼するユーザを決定する（ステップＳ２−４−２）。ここでは、通信事業者Ａは通信事業者Ｂよりも優先順位が高いため、まず、通信事業者Ａに配信依頼するユーザを決定する。本例においては、最も高い通信事業者については、その通信事業者に加入している全ユーザを配信依頼するユーザとする。具体的には、集合Ａに含まれる全ユーザを通信事業者Ａに配信依頼するユーザとすればよい。【００７２】
次に、それ以外の通信事業者について、その通信事業者に配信依頼するユーザを決定する（ステップＳ２−４−３）。なお、ステップＳ２−４−３においては、優先順位が次に高い通信事業者から、その通信事業者に配信依頼するユーザを決定すればよい。本例においては、最も高い優先順位でない通信事業者については、その通信事業者の加入ユーザから、その通信事業者より優先度の高い通信事業者の配信要求ユーザを除いたものを配信要求ユーザとする。具体的には、集合Ｂから集合Ａのユーザを削除した集合Ｂ−Ａを通信事業者Ｂに配信依頼するユーザとすればよい。そして、配信先決定部１０３は、配信要求送信部１０４に、各通信事業者について、その通信事業者に配信依頼するユーザの情報を送信する（ステップＳ２−５）。例えば、配信先決定部１０３は、「通信事業者Ａには集合Ａ、通信事業者Ｂには集合Ｂ−Ａ」という情報を送る。【００７３】
なお、この例では、通信事業者Ａと通信事業者Ｂの２つの通信事業者に対し、通信事業者Ａ＞通信事業者Ｂという優先度に従って配信先を決定する例であるが、例えば、通信事業者を通信事業者Ａと通信事業者Ｂと通信事業者Ｃに対し、通信事業者Ａ＞通信事業者Ｂ＞通信事業者Ｃという優先度に従って配信先を決定する場合には、さらに、ステップＳ２−４−２において、通信事業者Ｃに配信依頼するユーザが計算されることになる。なお、この場合には、集合Ｃから集合Ａおよび集合Ｂのユーザを削除した集合Ｃ−Ａ−Ｂ（重複するユーザは省略）を通信事業者Ｃに配信依頼するユーザとして計算すればよい。【００７４】
配信要求送信部１０４は、配信先決定部１０３から配信先情報を受け取り、各通信事業者の配信システム４００に対して配信要求を行う（ステップＳ２−６）。配信要求送信部１０４は、配信システム４００Ａの配信要求受信部４０１に対して、配信依頼受信部１０１が受け取ったメッセージ内容と、配信先として集合Ａに含まれる各ユーザの通信事業者ＡにおけるユーザＩＤ（ここでは、ｕｓｅｒ１〜３＠ａ．ｃｏｍ）とを送ればよい（ステップＳ２−６−１）。また、配信システム４００Ｂの配信要求受信部４０１に対して、配信依頼受信部１０１が受け取ったメッセージ内容と、配信先として集合Ｂ−Ａに含まれる各ユーザの通信事業者ＢにおけるユーザＩＤ（ここでは、ｕｓｅｒ４，５＠ｂ．ｃｏｍ）とを送ればよい（ステップＳ２−６−１）。【００７５】
通信事業者Ａ，４００Ｂの配信要求受信部４０１は、受け取ったメッセージ内容と送信先を配信部４０２に送る（ステップＳ２−７）。配信部４０２は、受け取ったメッセージ内容を配信先で指定されたユーザ端末３００に送る（ステップＳ２−８）。【００７６】
ユーザ端末３００は、受け取ったメッセージ内容をユーザに提示する（ステップＳ２−９）。【００７７】
なお、上記例では、通信事業者Ａ＞通信事業者Ｂという優先順位で、重複なく配信するために、ステップＳ２−４−１およびステップＳ２−４−２のステップで通信事業者Ａと通信事業者Ｂに配信依頼するユーザを計算したが、ステップＳ２−４−１およびステップＳ２−４−２の処理を以下の処理で置き換えてもよい。【００７８】
例えば、配信先決定部１０３は、以下の集合を計算する（ステップＳ２−４−１’）。配信先決定部１０３は、通信事業者Ａと通信事業者Ｂの両方に加入しているユーザの集合（Ａ∧Ｂ）ｏｎｌｙを計算する。また、通信事業者Ａのみに加入しているユーザの集合（Ａ）ｏｎｌｙを計算する。また、通信事業者Ｂのみに加入しているユーザの集合（Ｂ）ｏｎｌｙを計算する。【００７９】
そして、通信事業者Ａと通信事業者Ｂのいずれかを配信先とするユーザの集合を以下のように計算する（ステップＳ２−４−２’）。ここで、「α＋β」は、αかβのどちらかの集合に属するユーザを計算することを示している。【００８０】
通信事業者Ａに配信依頼するユーザの集合Ａ’＝（Ａ）ｏｎｌｙ＋（Ａ∧Ｂ）ｏｎｌｙ
通信事業者Ｂに配信依頼するユーザの集合Ｂ’＝（Ｂ）ｏｎｌｙ【００８１】
なお、この例においても、例えば、通信事業者を通信事業者Ａと通信事業者Ｂと通信事業者Ｃに対し、通信事業者Ａ＞通信事業者Ｂ＞通信事業者Ｃという優先度に従って配信先を決定する場合には、以下のように計算すればよい。【００８２】
通信事業者Ａに配信依頼するユーザの集合Ａ’＝（Ａ）ｏｎｌｙ＋（Ａ∧Ｂ）ｏｎｌｙ＋（Ａ∧Ｃ）ｏｎｌｙ＋（Ａ∧Ｂ∧Ｃ）ｏｎｌｙ
通信事業者Ｂに配信依頼するユーザの集合Ｂ’＝（Ｂ）ｏｎｌｙ＋（Ｂ∧Ｃ）ｏｎｌｙ
通信事業者Ｃに配信依頼するユーザの集合Ｃ’＝（Ｃ）ｏｎｌｙ【００８３】
なお、（Ａ∧Ｂ）ｏｎｌｙとは、通信事業者Ａと通信事業者Ｂとだけに加入しているユーザを示し、通信事業者Ａと通信事業者Ｂと通信事業者Ｃに加入しているユーザは含まれないものとして示している。【００８４】
なお、本実施例では、配信対象として指定されたユーザＩＤ＃２００を識別子として、配信依頼するユーザを決定する例を示したが、例えば、ＩＤ管理システム７００におけるユーザＩＤであるユーザＩＤ＃７００を介して、依頼元のサービス提供システム２００におけるユーザＩＤ（ユーザＩＤ＃２００）と、配信システム４００Ａ，４００ＢにおけるユーザＩＤ（ユーザＩＤ＃４００Ａ，ユーザＩＤ＃４００Ｂ）とを対応づけている場合には、配信先として指定されたユーザＩＤ＃２００をユーザＩＤ＃７００に変換した上で、配信依頼するユーザを決定するようにしてもよい。【００８５】
なお、上記方法によれば、例えば、複数のサービス事業者が共同して広告メッセージの配信を依頼してきた場合であっても、それぞれのサービス事業者のユーザＩＤによって指定されたユーザをユーザＩＤ＃７００によって一意に識別することができるので、容易に配信対象として指定されたユーザについてどの通信事業者に配信依頼を出すかを決定することができる。また、各サービス事業者にとっても、どのユーザが重複しているかを知らなくても重複させずに広告メッセージを配信することができる。【００８６】
また、本実施例では、ＩＤ連携情報保持部１２０が保持しているＩＤ連携情報として、図５を例示して説明したが、配信制御部１００において配信先ユーザを識別できるユーザＩＤ（本例では、ユーザＩＤ＃２００）から、実際の配信先として用いる通信事業者内でユーザを識別できるユーザＩＤ（すなわち、ユーザＩＤ＃４００ＡやユーザＩＤ＃４００Ｂ）をその通信事業者とともに識別できるような形式で保存されていればよい。【００８７】
例えば、ＩＤ管理事業者が広告配信を依頼するサービス事業者と同じユーザＩＤを用いている場合は、図７のように、ユーザＩＤ＃２００とユーザＩＤ＃４００とを区別することなく、一つのユーザＩＤとして、各通信事業者内でユーザを識別できるユーザＩＤとＩＤ連携させればよい。【００８８】
また、例えば、ＩＤ管理事業者、サービス事業者、通信事業者で同一のユーザＩＤを利用する場合は、それまでの形式のままで図８のようなＩＤ連携情報を持つことも可能であるし、図９のように、ユーザＩＤとＩＤ連携先の情報を対応づけることによって、ＩＤ連携させることも可能である。【００８９】
また、本例では、通信事業者が通信事業者Ａと通信事業者Ｂの２つであったが、通信事業者が３つ以上になる場合は、ユーザに配信可能なメッセージ数をあらかじめ設定しておき、ユーザに配信可能なメッセージ数を超える数を配信しないように制御してもよい。【００９０】
このように、本実施形態によれば、ユーザが複数の通信事業者に加入しているユーザに対して効率的にメッセージの配信を行うことができる。例えば、図６に示す動作例のように、予め定めておいた優先順位に従って重複なく配信を行うという設定をしておけば、ユーザが複数の通信事業者に加入していても、同一のメッセージを受信してしまうことがなくなる。また、サービス事業者が、メッセージ配信数に応じて通信事業者に対して支払いを行わなければならない場合であっても、実際に配信したユーザ数以上の料金を通信事業者に支払うことがなくなる。【００９１】
また、ＩＤ連携情報が作成されることによって、サービス事業者は、通信事業者への加入情報を開示したくないユーザに対しても、広告メッセージを送信することができる。同様に、ユーザは、通信事業者への加入情報を開示しなくても、ＩＤ連携しているシステムからメッセージの配信サービスを受けることができる。また、ＩＤ連携情報をシングルサインオン機能に利用すれば、ユーザは、各システムごとにユーザを認証する煩雑さから解放される。【００９２】
実施形態２．
次に、本発明の第２の実施形態について説明する。本実施形態では、配信制御部１００が配信先の通信事業者を決定する際に、あらかじめ設定されている順番に沿って優先順位を入れ替えつつ、通信事業者を決定する。【００９３】
図１０は、本発明の第２の実施形態の構成例を示すブロック図である。図１０に示すように、本実施形態における配信制御部１００は、図４に示す配信制御部１００の配信先決定部１０３が、順序処理配信先決定部１０３１に置き換えられている。順序処理配信先決定部１０３１は、あらかじめ設定されている通信事業者の順番に沿って、所定のタイミングで通信事業者の優先順位を入れ替えつつ、各ユーザに対しどの通信事業者に配信依頼を出すかを決定する。【００９４】
次に、本実施形態の動作について説明する。図１１は、順序処理配信先決定部１０３１が行う配信先決定動作の一例を示すフローチャートである。なお、図１１に示す動作は、ＩＤ連携を用いた広告配信時における配信先決定動作の例である。なお、本動作は、図４に示す例において、ステップＳ２−４〜Ｓ２−５に置き換えることができる。【００９５】
順序処理配信先決定部１０３１は、通信事業者ユーザ取得部１０２から、配信対象として指定された各ユーザがどの通信事業者に加入しているかを示す情報（ここでは、集合Ａおよび集合Ｂ）を受け取ると、各通信事業者に配信依頼するユーザを決定する（ステップＳ２−４ａ）。なお、本例では、通信事業者Ａ→通信事業者Ｂという優先順序で、重複なく配信を行うという設定になっているものとする。順序処理配信先決定部１０３１は、まず、現時点における通信事業者の優先順位を確認する。なお、優先順位は、最も早い順番が設定されている通信事業者から順に高い優先度が設定されているものとみなす。そして、順序処理配信先決定部１０３１は、現時点における通信事業者の優先順位に従って、各ユーザに対しどの通信事業者に配信依頼を出すかを決定する。【００９６】
なお、優先順位に従った配信先決定処理は、第１の実施形態と同様である。すなわち、順序処理配信先決定部１０３１は、各通信事業者について、以下の処理を行うことによって、各通信事業者に配信依頼するユーザを決定する（ステップＳ２−４ａ）。まず、通信事業者の優先順位を確認し（ステップＳ２−４ａ−１）、最も高い通信事業者について、その通信事業者に配信依頼するユーザを決定する（ステップＳ２−４ａ−２）。現時点における通信事業者の優先順位は、通信事業者Ａ＞通信事業者Ｂであるため、まず、通信事業者Ａに配信依頼するユーザを決定すればよい。次に、それ以外の通信事業者について、その通信事業者に配信依頼するユーザを決定する（ステップＳ２−４ａ−３）。ここでは、通信事業者Ｂに配信依頼するユーザを決定すればよい。【００９７】
各ユーザに対しどの通信事業者に配信依頼を出すかを決定すると、順序処理配信先決定部１０３１は、配信要求送信部１０４に、各通信事業者について、その通信事業者に配信依頼するユーザの情報を送信する（ステップＳ２−５ａ−１）。また、順序処理配信先決定部１０３１は、次回の配信先決定処理のために、通信事業者の優先順位を入れ替える（ステップＳ２−５ａ−２）。ここでは、最も早い順番となっていた通信事業者Ａを、最も遅い順番となるように入れ替える。具体的には、通信事業者Ｂ→通信事業者Ａとなるように入れ替える。こうすることによって、次回の配信先決定処理では、最も優先順位が高かった通信事業者Ａは最も低い優先順位となる。【００９８】
なお、上記例では、通信事業者Ａと通信事業者Ｂの２つの通信事業者の例を説明したが、例えば、通信事業者Ａ→通信事業者Ｂ→通信事業者Ｃという順番が設定されていた場合には、順序処理配信先決定部１０３１は、配信依頼がある度に、以下のように優先順位を入れ替える。【００９９】
１回目の配信の優先順位：Ａ＞Ｂ＞Ｃ
２回目の配信の優先順位：Ｂ＞Ｃ＞Ａ
３回目の配信の優先順位：Ｃ＞Ａ＞Ｂ
４回目の配信の優先順位：Ａ＞Ｂ＞Ｃ【０１００】
本実施形態によれば、各通信事業者への配信依頼の偏りをなくすことができる。なお、優先順位を入れ替えるタイミングは、配信依頼がある度に限らない。例えば、配信依頼が所定の数に達する毎であってもよいし、月単位であってもよい。【０１０１】
実施形態３．
次に、本発明の第３の実施形態について説明する。本実施形態では、配信制御部１００が配信先の通信事業者を決定する際に、ランダムに通信事業者を決定する。【０１０２】
図１２は、本発明の第３の実施形態の構成例を示すブロック図である。図１２に示すように、本実施形態における配信制御部１００は、図４に示す配信制御部１００の配信先決定部１０３が、ランダム処理配信先決定部１０３２に置き換えられている。ランダム処理配信先決定部１０３２は、複数の通信事業者に加入しているユーザについて、ランダムに配信先とする通信事業者を決定する。【０１０３】
次に、本実施形態の動作について説明する。図１３は、ランダム処理配信先決定部１０３２が行う配信先決定動作の一例を示すフローチャートである。なお、図１３に示す動作は、ＩＤ連携を用いた広告配信時における配信先決定動作の例である。なお、本動作は、図４に示す例において、ステップＳ２−４〜Ｓ２−５に置き換えることができる。【０１０４】
ランダム処理配信先決定部１０３２は、通信事業者ユーザ取得部１０２から、配信対象として指定された各ユーザがどの通信事業者に加入しているかを示す情報（ここでは、集合Ａおよび集合Ｂ）を受け取ると、各通信事業者に配信依頼するユーザを決定する。なお、本例では、ランダムに配信を行うという設定になっているものとする。ランダム処理配信先決定部１０３２は、具体的には、各ユーザについて以下の処理を行う（ステップＳ２−４ｂ）。【０１０５】
ランダム処理配信先決定部１０３２は、そのユーザがどの通信事業者に加入しているかを確認する（ステップＳ２−４ｂ−１）。ここで、ユーザが単一の通信事業者に加入している場合は、その通信事業者をそのユーザの配信先とする（ステップＳ２−４ｂ−２）。一方、ユーザが複数の通信事業者に加入している場合は、そのユーザが加入している通信事業者の中からランダムに通信事業者を選び、そのユーザの配信先とする（ステップＳ２−４ｂ−３）。なお、ユーザがどの通信事業者に加入しているか否かは、通信事業者ユーザ取得部１０２から受け取った各通信事業者の加入ユーザのリストに当該ユーザのユーザＩＤが含まれているか否かを確認すればよい。その際、ある通信事業者の加入ユーザのリストに含まれるユーザＩＤが他の通信事業者の加入ユーザのリストに含まれているか否かを確認することによって、そのユーザが複数の通信事業者に加入しているか否かがわかる。【０１０６】
各ユーザに対しどの通信事業者に配信依頼を出すかを決定すると、ランダム処理配信先決定部１０３２は、配信要求送信部１０４に、各通信事業者について、その通信事業者に配信依頼するユーザの情報を送信する（ステップＳ２−５ｂ）。【０１０７】
なお、ランダム処理配信先決定部１０３２は、メッセージの最大送信数が指定されている場合には、その設定情報をもとに、各通信事業者に配信依頼するユーザを決定すればよい。例えば、ＩＤ連携している通信事業者が３つ（通信事業者Ａ，Ｂ，Ｃ）あり、最大送信数が２と設定されている場合には、ステップＳ２−４ｂ−１〜Ｓ２−４ｂ−３を以下の処理で置き換えてもよい。【０１０８】
ステップＳ２−４ｂ−１において、ランダム処理配信先決定部１０３２は、そのユーザがどの通信事業者を確認する。ここでは、さらに、最大送信数より多く通信事業者に加入しているか否かを判定する。そして、ユーザが最大送信数以内の数の通信事業者に加入している場合には、その通信事業者をそのユーザの配信先とする（ステップＳ２−４ｂ−２’）。一方、ユーザが最大送信数より多い数の通信事業者に加入している場合は、そのユーザが加入している通信事業者の中から、最大送信数分だけランダムに通信事業者を選び、そのユーザの配信先とする（ステップＳ２−４ｂ−３’）。【０１０９】
なお、第１の実施形態で示した配信先決定部１０３や第２の実施形態で示した順序処理配信先決定部１０３１が、ランダム処理配信先決定部１０３２のように各ユーザについて通信事業者を決定する繰り返し処理を行い、その繰り返し処理で、そのユーザが加入している通信事業者の中から、優先順位に沿って最大送信数分の通信事業者を選ぶことも可能である。【０１１０】
実施形態４．
次に、本発明の第４の実施形態について説明する。本実施形態では、配信制御部１００が配信先の通信事業者を決定する際に、あらかじめ設定されている配信割合の設定に従って、通信事業者を決定する。【０１１１】
図１４は、本発明の第４の実施形態の構成例を示すブロック図である。図１４に示すように、本実施形態における配信制御部１００は、図４に示す配信制御部１００の配信先決定部１０３が、配信割合配信先決定部１０３３に置き換えられている。配信割合配信先決定部１０３３は、ランダムに通信事業者を決定する際に、あらかじめ設定されている配信割合に従って配信先を決定する。【０１１２】
配信割合配信先決定部１０３３は、例えば、配信割合の設定として「通信事業者Ａの重みＷａ＝２、通信事業者Ｂの重みＷｂ＝１」とされている場合、通信事業者Ｂよりも２倍の確率で、通信事業者Ａを配信先とするように決定する。【０１１３】
具体的には、図１３に示した第３の実施形態におけるランダム決定処理（ステップＳ２−４ｂ−３）において、０．０以上１．０未満の浮動小数点値をとるランダム値Ｒを計算するようにし、もし、Ｒ≦Ｗａ／（Ｗａ＋Ｗｂ）であれば、通信事業者Ａを配信先として決定すればよい。そうでないならば、通信事業者Ｂを配信先として決定すればよい。【０１１４】
なお、通信事業者Ａ，Ｂ，Ｃに加入しているユーザについては、例えば「通信事業者Ａの重みＷａ＝２、通信事業者Ｂの重みＷｂ＝１、通信事業者Ｃの重みＷｃ＝３」と設定されている場合、以下のように配信先を決定すればよい。例えば、Ｒ≦Ｗａ／（Ｗａ＋Ｗｂ＋Ｗｃ）であれば、通信事業者Ａを配信先とし、Ｒ≦（Ｗａ＋Ｗｂ）／（Ｗａ＋Ｗｂ＋Ｗｃ）であれば、通信事業者Ｂを配信先とし、そうでなければ通信事業者Ｃを配信先として決定すればよい。【０１１５】
本実施形態によれば、予め定めておいた配信割合に応じた確率で配信させることができる。【０１１６】
実施形態５．
次に、本発明の第５の実施形態について説明する。本実施形態では、配信制御部１００が配信先の通信事業者を決定する際に、各配信システム４００のメッセージ配信にかかる金額の情報に応じて、通信事業者を決定する。【０１１７】
図１５は、本発明の第５の実施形態の構成例を示すブロック図である。図１５に示すように、本実施形態では、図４に示す配信制御部１００の構成に配信金額情報取得部１０５が追加となっている。また、配信システム４００の構成に、配信金額情報送信部４０５が追加となっている。また、配信先決定部１０３の動作が異なる。【０１１８】
配信金額情報取得部１０５は、ＩＤ連携している各配信システム４００について、その配信システム４００の配信金額情報送信部４０５に問い合わせを行い、該配信システム４００において配信にかかる金額（以下、配信金額という。）の情報を取得する。配信金額情報送信部４０５は、配信金額情報取得部１０５からの問い合わせに応じて、当該配信システム４００の配信金額を送信する。【０１１９】
また、本実施形態における配信先決定部１０３は、配信金額情報取得部１０５が取得した配信金額に基づいて、どの通信事業者に配信依頼を出すかを決定する。【０１２０】
次に、本実施形態の動作について説明する。図１６は、本実施形態における配信先決定処理の動作例を示すフローチャートである。なお、図１６に示す動作は、ＩＤ連携を用いた広告配信時における配信先決定動作の例である。なお、本動作は、図４に示す例において、ステップＳ２−４〜Ｓ２−５に置き換えることができる。【０１２１】
配信先決定部１０３は、通信事業者ユーザ取得部１０２から、配信対象として指定された各ユーザがどの通信事業者に加入しているかを示す情報を受け取ると、各通信事業者に配信依頼するユーザを決定する（ステップＳ２−４ｃ）。なお、本例では、通信事業者から取得した配信金額の情報に応じて、配信にかかる金額が安いほうの通信事業者に配信を依頼するという設定になっているものとする。【０１２２】
配信先決定部１０３は、各通信事業者に配信依頼するユーザの集合について、すべての組み合わせを求める（ステップＳ２−４ｃ−１）。配信先決定部１０３は、例えば、各通信事業者に配信依頼するユーザ数について、すべての組み合わせを計算してもよい。配信先決定部１０３は、例えば、第１の実施形態で示した前提条件によれば、以下のような組み合わせを求めることになる。なお、以下の組み合わせは、配信先として指定されたユーザＩＤ＃２００をユーザＩＤ＃７００に変換した上で、配信依頼するユーザを決定する方法を用いた例で示している。【０１２３】
組み合わせ１．（通信事業者Ａ：３人／通信事業者Ｂ：２人）
｛通信事業者Ａ｛”ｕｓｅｒ１＠ｉｄｐ．ｃｏｍ”，”ｕｓｅｒ２＠ｉｄｐ．ｃｏｍ”，”ｕｓｅｒ３＠ｉｄｐ．ｃｏｍ”｝，通信事業者Ｂ｛”ｕｓｅｒ４＠ｉｄｐ．ｃｏｍ”，”ｕｓｅｒ５＠ｉｄｐ．ｃｏｍ”｝｝【０１２４】
組み合わせ２．（通信事業者Ａ：２人／通信事業者Ｂ：３人）
｛通信事業者Ａ｛”ｕｓｅｒ１＠ｉｄｐ．ｃｏｍ”，”ｕｓｅｒ２＠ｉｄｐ．ｃｏｍ”｝，通信事業者Ｂ｛”ｕｓｅｒ３＠ｉｄｐ．ｃｏｍ”，”ｕｓｅｒ４＠ｉｄｐ．ｃｏｍ”，”ｕｓｅｒ５＠ｉｄｐ．ｃｏｍ”｝｝【０１２５】
組み合わせ３．（通信事業者Ａ：１人／通信事業者Ｂ：４人）
｛通信事業者Ａ｛”ｕｓｅｒ２＠ｉｄｐ．ｃｏｍ”｝，通信事業者Ｂ｛”ｕｓｅｒ１＠ｉｄ．ｃｏｍ”，”ｕｓｅｒ３＠ｉｄｐ．ｃｏｍ”，”ｕｓｅｒ４＠ｉｄｐ．ｃｏｍ”，”ｕｓｅｒ５＠ｉｄｐ．ｃｏｍ”｝｝【０１２６】
配信先決定部１０３は、それぞれの組み合わせについて、その組み合わせで配信を行った場合に、メッセージ配信にかかる金額を求める（ステップＳ２−４ｃ−２）。配信先決定部１０３は、例えば、配信金額情報取得部１０５に、各配信システム４００へのメッセージ配信にかかる金額の問い合わせを依頼し、配信金額情報取得部１０５が、各配信システム４００の配信金額情報送信部４０５に、各組み合わせにおいて該配信システムを配信先とするユーザ数でメッセージを配信した場合にかかる金額を問い合わせることによって得られる各配信システム４００の配信金額に基づいて、メッセージ配信にかかる金額を求めればよい。なお、メッセージ配信にかかる金額が定量設定である場合などには、予め各配信システム４００の配信金額情報取得部１０５にメッセージ配信にかかる金額を問い合わせることで、設定としてその金額を保持しておくようにし、配信先決定部１０３が、その保持された金額に基づいてメッセージ配信にかかる金額を計算してもよい。【０１２７】
配信先決定部１０３は、各組み合わせについてメッセージ配信にかかる金額が求まると、一番金額が安い組み合わせで配信するよう、配信先を決定する（ステップＳ２−４ｃ−３）。【０１２８】
各ユーザに対しどの通信事業者に配信依頼を出すかを決定すると、配信先決定部１０３は、配信要求送信部１０４に、各通信事業者について、その通信事業者に配信依頼するユーザの情報を送信する（ステップＳ２−５ｃ）。【０１２９】
本実施形態によれば、配信にかかる金額が一番安い組み合わせで配信を行うことが可能になる。例えば、通信事業者Ａではユーザ１名あたり１００円の通信料がかかり、通信事業者Ｂではユーザが何名でも２００円の通信料がかかる場合には、通信事業者Ｂに多く配信させた方が全体の配信料は安くなる。上記で示した組み合わせの例では、組み合わせ１の場合にかかる金額＝５００円，組み合わせ２の場合にかかる金額＝４００円，組み合わせ３の場合にかかる金額＝３００円となり、組み合わせ３を採用することで、一番安い組み合わせで配信を行うことが可能になる。【０１３０】
なお、上記例では、ユーザ数の組み合わせで配信金額を比較する例を示したが、以下のように、配信対象として指定されたユーザについてのすべての組み合わせを求めるようにしてもよい。このような場合には、配信先決定部１０３は、例えば、第１の実施形態で示した前提条件によれば、以下のような組み合わせを求めることになる。【０１３１】
組み合わせ１．（通信事業者Ａ：ｕｓｅｒ１，２，３／通信事業者Ｂ：ｕｓｅｒ４，５）
｛通信事業者Ａ｛”ｕｓｅｒ１＠ｉｄｐ．ｃｏｍ”，”ｕｓｅｒ２＠ｉｄｐ．ｃｏｍ”，”ｕｓｅｒ３＠ｉｄｐ．ｃｏｍ”｝，通信事業者Ｂ｛”ｕｓｅｒ４＠ｉｄｐ．ｃｏｍ”，”ｕｓｅｒ５＠ｉｄｐ．ｃｏｍ”｝｝【０１３２】
組み合わせ２．（通信事業者Ａ：ｕｓｅｒ１，２／通信事業者Ｂ：ｕｓｅｒ３，４，５）
｛通信事業者Ａ｛”ｕｓｅｒ１＠ｉｄｐ．ｃｏｍ”，”ｕｓｅｒ２＠ｉｄｐ．ｃｏｍ”｝，通信事業者Ｂ｛”ｕｓｅｒ３＠ｉｄｐ．ｃｏｍ”，”ｕｓｅｒ４＠ｉｄｐ．ｃｏｍ”，”ｕｓｅｒ５＠ｉｄｐ．ｃｏｍ”｝｝【０１３３】
組み合わせ３．（通信事業者Ａ：ｕｓｅｒ２，３／通信事業者Ｂ：ｕｓｅｒ１，４，５）
｛通信事業者Ａ｛”ｕｓｅｒ２＠ｉｄｐ．ｃｏｍ”，”ｕｓｅｒ３＠ｉｄｐ．ｃｏｍ”｝，通信事業者Ｂ｛”ｕｓｅｒ１＠ｉｄｐ．ｃｏｍ”，”ｕｓｅｒ４＠ｉｄｐ．ｃｏｍ”，”ｕｓｅｒ５＠ｉｄｐ．ｃｏｍ”｝｝【０１３４】
組み合わせ４．（通信事業者Ａ：ｕｓｅｒ２／通信事業者Ｂ：ｕｓｅｒ１，３，４，５）
｛通信事業者Ａ｛”ｕｓｅｒ２＠ｉｄｐ．ｃｏｍ”｝，通信事業者Ｂ｛”ｕｓｅｒ１＠ｉｄ．ｃｏｍ”，”ｕｓｅｒ３＠ｉｄｐ．ｃｏｍ”，”ｕｓｅｒ４＠ｉｄｐ．ｃｏｍ”，”ｕｓｅｒ５＠ｉｄｐ．ｃｏｍ”｝｝【０１３５】
例えば、ユーザがその通信事業者に加入している通信プランによって配信料が変化する場合や、依頼主とユーザとの関係によって配信料が変化する場合であっても、一番金額が安い組み合わせで配信を行うことができる。【０１３６】
なお、図１７に示すように、配信制御部１００は、さらに課金管理部１０６を備えていてもよい。課金管理部１０６は、配信にかかる金額を管理しておき、依頼元のサービス提供システム２００へ、メッセージ配信にかかる金額を送信する。なお、金額を通知するだけでなく請求するようにしてもよい。【０１３７】
実施形態６．
次に、本発明の第６の実施形態について説明する。本実施形態では、配信制御部１００が配信先の通信事業者を決定する際に、各配信システム４００のメッセージ配信処理の負荷状態に応じて、通信事業者を決定する。【０１３８】
図１８は、本発明の第６の実施形態の構成例を示すブロック図である。図１８に示すように、本実施形態では、図４に示す配信制御部１００の構成に配信負荷情報取得部１０７が追加となっている。また、配信システム４００の構成に、配信負荷情報送信部４０７が追加となっている。また、配信先決定部１０３の動作が異なる。【０１３９】
配信負荷情報取得部１０７は、ＩＤ連携している各配信システム４００について、その配信システム４００の配信負荷情報送信部４０７に問い合わせを行い、該配信システム４００の負荷状態を示す負荷情報を取得する。配信負荷情報送信部４０７は、配信負荷情報取得部１０７からの問い合わせに応じて、該配信システム４００の負荷状態を調べ、その情報を送信する。なお、配信負荷情報送信部４０７は、例えば、配信部４０２が保持している現在配信待ちのメッセージ（現在配信中のメッセージを含んでもよい。）の個数を参照し、この個数を負荷情報としてもよい。【０１４０】
また、本実施形態における配信先決定部１０３は、配信負荷情報取得部１０７が取得した各配信システム４００の負荷情報に基づいて、どの通信事業者に配信依頼を出すかを決定する。【０１４１】
次に、本実施形態の動作について説明する。図１９は、本実施形態における配信先決定処理の動作例を示すフローチャートである。なお、図１９に示す動作は、ＩＤ連携を用いた広告配信時における配信先決定動作の例である。なお、本動作は、図４に示す例において、ステップＳ２−４〜Ｓ２−５に置き換えることができる。【０１４２】
配信先決定部１０３は、通信事業者ユーザ取得部１０２から、配信対象として指定された各ユーザがどの通信事業者に加入しているかを示す情報（ここでは、集合Ａおよび集合Ｂ）を受け取ると、各通信事業者に配信依頼するユーザを決定する。なお、本例では、通信事業者から取得した負荷情報に応じて、負荷が小さいほうの通信事業者に配信を依頼するという設定になっているものとする。【０１４３】
配信先決定部１０３は、通信事業者ユーザ取得部１０２から、配信対象として指定された各ユーザがどの通信事業者に加入しているかを示す情報を受け取ると、まず、各配信システム４００の現在の処理負荷を求める（ステップＳ２−４ｄ−１）。配信先決定部１０３は、例えば、配信負荷情報取得部１０７に、各配信システム４００への処理負荷の問い合わせを依頼し、配信負荷情報取得部１０７が、各配信システム４００の配信負荷情報送信部４０７に、現在の処理負荷を問い合わせることによって得られる各配信システム４００の負荷情報に基づいて、各配信システム４００の現在の処理負荷を求めればよい。【０１４４】
配信先決定部１０３は、各配信システム４００の現在の処理負荷が求まると、それに基づき、各通信事業者の優先順位を定める（ステップＳ２−４ｄ−２）。そして、定めた優先順位に従い、各通信事業者に配信依頼するユーザを決定する（ステップＳ２−４ｄ−３〜Ｓ２−４ｄ−３−３）。なお、優先順位に従った配信先決定処理は、第１の実施形態におけるステップＳ２−４〜Ｓ２−４−２と同様であるため、説明は省略する。【０１４５】
各ユーザに対しどの通信事業者に配信依頼を出すかを決定すると、配信先決定部１０３は、配信要求送信部１０４に、各通信事業者について、その通信事業者に配信依頼するユーザの情報を送信する（ステップＳ２−５ｄ）。【０１４６】
本実施形態によれば、各配信システム４００の処理負荷が均一になるように、配信処理を依頼できる。【０１４７】
実施形態７．
次に、本発明の第７の実施形態について説明する。本実施形態では、配信制御部１００が配信先の通信事業者を決定する際に、配信システム４００毎のユーザの利用頻度の情報に応じて、通信事業者を決定する。【０１４８】
図２０は、本発明の第７の実施形態の構成例を示すブロック図である。図２０に示すように、本実施形態では、図４に示す配信制御部１００の構成に利用頻度情報取得部１０８が追加となっている。また、配信システム４００の構成に、利用頻度情報送信部４０８が追加となっている。また、配信先決定部１０３の動作が異なる。【０１４９】
利用頻度情報取得部１０８は、各配信システム４００の利用頻度情報送信部４０８に問い合わせを行い、指定したユーザの該配信システム４００における利用頻度を示す利用頻度情報を取得する。利用頻度情報送信部４０８は、利用頻度情報取得部１０８からの問い合わせに応じて、該配信システム４００における指定されたユーザの利用頻度を調べ、その情報を送信する。なお、利用頻度情報取得部１０８は、例えば、サービス提供部４０４がカウントしているユーザからの１日あたりのアクセス数を参照し、このアクセス数を利用頻度情報としてもよい。【０１５０】
また、本実施形態における配信先決定部１０３は、利用頻度情報取得部１０８が取得した各配信システム４００におけるユーザの利用頻度情報に基づいて、どの通信事業者に配信依頼を出すかを決定する。【０１５１】
次に、本実施形態の動作について説明する。図２１は、本実施形態における配信先決定処理の動作例を示すフローチャートである。なお、図２１に示す動作は、ＩＤ連携を用いた広告配信時における配信先決定動作の例である。なお、本動作は、図４に示す例において、ステップＳ２−４〜Ｓ２−５に置き換えることができる。【０１５２】
配信先決定部１０３は、通信事業者ユーザ取得部１０２から、配信対象として指定された各ユーザがどの通信事業者に加入しているかを示す情報を受け取ると、各通信事業者に配信依頼するユーザを決定する。なお、本例では、ユーザの利用頻度が高い通信事業者に配信を依頼するという設定になっているものとする。配信先決定部１０３は、具体的には、各ユーザについて以下の処理を行う（ステップＳ２−４ｅ）。【０１５３】
配信先決定部１０３は、そのユーザがどの通信事業者に加入しているかを確認する（ステップＳ２−４ｅ−１）。ここで、ユーザが単一の通信事業者に加入している場合は、その通信事業者をそのユーザの配信先とする（ステップＳ２−４ｅ−２）。一方、ユーザが複数の通信事業者に加入している場合は、そのユーザが加入している通信事業者の配信システム４００におけるそのユーザの利用頻度を求める（ステップＳ２−４ｅ−３）。配信先決定部１０３は、例えば、利用頻度情報取得部１０８に、そのユーザが加入している配信システム４００へのそのユーザの利用頻度の問い合わせを依頼し、利用頻度情報取得部１０８が、依頼された各配信システム４００の利用頻度情報送信部４０８に、そのユーザの該配信システム４００におけるユーザＩＤを指定した利用頻度を問い合わせることによって得られる各配信システム４００の利用頻度情報に基づいて、複数の通信事業者に加入しているユーザの、加入先配信システム４００における利用頻度を求めればよい。【０１５４】
配信先決定部１０３は、複数の通信事業者に加入しているユーザの、加入先配信システム４００における利用頻度が求まると、それに基づき、そのユーザについてどの通信事業者に配信依頼するかを決定する（ステップＳ２−４ｅ−４）。例えば、通信事業者Ａと通信事業者Ｂとに加入しているユーザであって、通信事業者Ａの方が利用頻度が高いことが求まれば、利用頻度が高い通信事業者Ａに配信依頼をする旨決定すればよい。【０１５５】
各ユーザに対しどの通信事業者に配信依頼を出すかを決定すると、配信先決定部１０３は、配信要求送信部１０４に、各通信事業者について、その通信事業者に配信依頼するユーザの情報を送信する（ステップＳ２−５ｅ）。【０１５６】
本実施形態によれば、ユーザが良く使う通信事業者に対してメッセージ配信依頼をすることができ、ユーザがよく使う端末（または宛先アドレス）にメッセージが配信されるようになる。【０１５７】
実施形態８．
次に、本発明の第８の実施形態について説明する。本実施形態では、配信制御部１００が、各配信システム４００のメッセージ配信能力に応じて、配信先を決定する。【０１５８】
図２２は、本発明の第８の実施形態の構成例を示すブロック図である。図２２に示すように、本実施形態における配信制御部１００は、図４に示す配信制御部１００の構成に配信依頼先候補決定部１０９が追加となっている。また、配信システム４００の構成に、配信能力情報送信部４０９が追加となっている。また、通信事業者ユーザ取得部１０２の動作が異なる。【０１５９】
配信依頼先候補決定部１０９は、各配信システム４００の配信能力情報送信部４０９に問い合わせを行い、依頼されたメッセージ内容を配信できるか否かを判定するための情報である配信能力情報を取得する。そして、各配信システム４００から得た配信能力情報に基づいて、依頼されたメッセージの配信依頼をする通信事業者の候補を決定する。具体的には、配信依頼先候補決定部１０９は、依頼されたメッセージ内容を配信できない通信事業者を、配信依頼先の候補から除外する。配信能力情報送信部４０９は、配信依頼先候補決定部１０９からの問い合わせに応じて、該配信システム４００において、指定されたメッセージの内容を配信可能か否かを判定するための情報（配信能力情報）を送信する。【０１６０】
例えば、配信依頼先候補決定部１０９が、依頼されたメッセージの配信に必要な能力（最大送信バイト数や、添付ファイル配信能力や、動画配信能力等）を判定し、その能力を備えているか否かを配信能力情報送信部４０９に問い合わせるようにし、配信能力情報送信部４０９が、該配信システム４００が備えている配信能力と比較して要求を満たしているか否かを示す送信可能情報を返信するようにしてもよい。【０１６１】
また、例えば、配信依頼先候補決定部１０９は、配信能力情報送信部４０９に、該配信システム４００が備えている配信能力（又は配信可能なメッセージの条件）を問い合わせるようにしてもよい。この場合、配信依頼先候補決定部１０９が、問い合わせによって得られた配信システム４００の配信能力と依頼されたメッセージの配信に必要な能力とを比較して、配信システム４００が、依頼されたメッセージの配信に必要な能力を全て備えているか否かを判定するようにしてもよい。【０１６２】
また、本実施形態における通信事業者ユーザ取得部１０２は、配信対象として指定されたユーザについて、ＩＤ連携情報を参照して、そのユーザが配信依頼先候補決定部１０９によって決定された配信依頼先候補のうちのどの通信事業者に加入しているかを判定する。そして、各ユーザが配信依頼先候補のうちのどの通信事業者に加入しているかを示す情報を配信先決定部１０３に出力する。【０１６３】
次に、本実施形態の動作について説明する。図２３は、本実施形態における配信依頼先候補の決定動作および加入ユーザ取得動作の一例を示すフローチャートである。なお、図２３に示す動作は、ＩＤ連携を用いた広告配信時における配信依頼先候補の決定動作および加入ユーザ取得動作の例である。なお、本動作は、図４に示す例において、ステップＳ２−２〜Ｓ２−３に置き換えることができる。【０１６４】
配信依頼受信部１０１がメッセージの配信制御依頼を受け付けると、配信依頼先候補決定部１０９および通信事業者ユーザ取得部１０２は、ＩＤ連携している各通信事業者について以下の処理を行う（ステップＳ２−２ｆ）。まず、配信依頼先候補決定部１０９は、その通信事業者の配信システム４００におけるメッセージの配信能力（具体的には、依頼されたメッセージを配信可能か否か）を求める（ステップＳ２−２ｆ−１）。配信依頼先候補決定部１０９は、例えば、その配信システム４００の配信能力情報送信部４０９に、依頼されたメッセージ内容を指定して問い合わせることによって得られる配信能力情報に基づいて、その配信システム４００が依頼されたメッセージ内容を配信できるか否かを求めればよい。【０１６５】
なお、配信システム４００の配信能力情報送信部４０９は、配信依頼先候補決定部１０９からの問い合わせに応じて、当該配信システム４００において、指定されたメッセージの内容に対するを配信可能か否かを判定するための情報（配信能力情報）を送信すればよい。【０１６６】
その通信事業者の配信システム４００におけるメッセージの配信能力が求まると、配信依頼先候補決定部１０９は、該配信システム４００が、依頼されたメッセージを配信可能か否かを判定する（ステップＳ２−２ｆ−２）。ここで、依頼されたメッセージを配信できない配信システム４００を配信依頼先候補から除外する（ステップＳ２−２ｆ−３）。なお、通信事業者ユーザ取得部１０２に、その通信事業者に加入しているか否かの判定を行わせないことにより、だれも加入していないものとしてもよい。【０１６７】
一方、依頼されたメッセージを配信できる配信システム４００については、通信事業者ユーザ取得部１０２が、その通信事業者に加入しているか否かの判定を行い、その通信事業者に加入しているユーザのリスト（加入ユーザリスト）を得る（ステップＳ２−２ｆ−４）。【０１６８】
通信事業者ユーザ取得部１０２は、ＩＤ連携されている通信事業者のうち、広告配信してほしいメッセージ内容を配信可能な通信事業者（すなわち、配信依頼先候補とされた通信事業者）に加入しているユーザの集合を得て、配信先決定部１０３に送信する（ステップＳ２−３ｆ）。【０１６９】
なお、配信依頼先候補決定部１０９が全通信事業者に対して、配信先候補とするか否かを判定した上で、通信事業者ユーザ取得部１０２に、配信依頼先候補とする通信事業者のリストを送り、通信事業者ユーザ取得部１０２は、配信先候補決定部１０９から受け取った配信依頼先候補とする通信事業者に対して、加入ユーザのリストを得るための処理を行うようにしてもよい。【０１７０】
本実施形態によれば、メッセージ内容を配信できない通信事業者に対して、配信依頼をすることがなくなる。なお、本実施形態は、第１の実施形態に限らず、他の実施形態とも組み合わせて実施することも可能である。【０１７１】
実施形態９．
次に、本発明の第９の実施形態について説明する。本実施形態では、配信制御部１００が、各配信システム４００が把握できる各ユーザのメッセージ受信能力に応じて、配信先を決定する。【０１７２】
図２４は、本発明の第９の実施形態の構成例を示すブロック図である。図２４に示すように、本実施形態における配信制御部１００は、図４に示す配信制御部１００の構成に端末情報取得部１１０が追加となっている。また、配信システム４００の構成に、端末情報送信部４１０１と、端末情報取得部４１０２とが追加となっている。また、配信先決定部１０３の動作が異なる。【０１７３】
端末情報取得部４１０２は、該端末情報取得部４１０２を含んでいる配信システム４００のユーザＩＤと対応づけられているユーザ端末３００から、少なくともメッセージの受信能力についての情報を取得する。端末情報取得部４１０２は、例えば、携帯端末のように、メッセージ受信に用いる端末が固定である場合には、その端末の型番を取得してもよい。また、端末情報取得部４１０２は、そのユーザが契約している回線容量やメモリ容量などを保持しておいてもよい。【０１７４】
端末情報送信部４１０１は、端末情報取得部１１０からの問い合わせに応じて、該配信システム４００における指定されたユーザＩＤに対応づけられているユーザ端末３００が、指定されたメッセージの内容を受信可能か否かを判定できる情報を送信する。端末情報取得部１１０は、指定されたユーザが加入している配信システム４００の端末情報送信部４１０１に問い合わせを行い、指定したユーザのユーザＩＤと対応づけられたユーザ端末３００が、依頼されたメッセージ内容を受信できるか否かを判定するための情報（端末受信能力情報）を取得する。【０１７５】
また、本実施形態における配信先決定部１０３は、通信事業者ユーザ取得部１０２によって得られた各ユーザがどの通信事業者に加入しているかを示す情報に基づいて、各ユーザについて、そのユーザが加入している通信事業者から依頼されたメッセージを受信することができるか否かを判定する。配信先決定部１０３は、通信事業者に加入している場合であっても、依頼されたメッセージを受信できないと判定された場合には、その通信事業者をそのユーザの配信依頼先候補から除外する。【０１７６】
次に、本実施形態の動作について説明する。図２５は、本実施形態の動作の一例を示すフローチャートである。なお、図２５に示す動作は、ＩＤ連携を用いた広告配信時における配信先決定動作の前処理（例えば、図４におけるステップＳ２−４の前に行われる動作）として行われる動作の例として示している。【０１７７】
なお、本実施形態では、予め以下の処理が実行されているものとする。
・端末情報取得部４１０２は、少なくともメッセージ受信に用いる端末が固定されている配信システム４００の場合、ユーザ端末３００からその端末の型番を取得する。なお、契約時に人手から入力されることによって取得してもよい。
・端末情報取得部４１０２は、少なくともメッセージ受信にかかる回線容量やメモリ容量に制限がある配信システム４００の場合、各ユーザが契約している回線容量やメモリ容量を取得する。なお、契約時に人手から入力されることによって取得してもよい。【０１７８】
なお、本例では、通信事業者から取得したユーザ端末のメッセージ受信能力の情報に応じて、メッセージを受信できないユーザ端末３００には配信しないという設定になっているものとする。配信先決定部１０３は、通信事業者ユーザ取得部１０２から、配信対象として指定された各ユーザがどの通信事業者に加入しているかを示す情報を受け取ると、各ユーザについて、以下の処理を行う（ステップＳ２−４ｈ−１）。【０１７９】
配信先決定部１０３は、そのユーザについて、該ユーザが加入している通信事業者の配信システム４００におけるメッセージ受信能力（具体的には、依頼されたメッセージを受信可能か否か）を求める（ステップＳ２−４ｈ−１−１）。配信先決定部１０３は、例えば、端末情報取得部１１０に、そのユーザについてそのユーザが加入している通信事業者の配信システム４００を指定したメッセージ受信能力の問い合わせを依頼し、端末情報取得部１１０が、指定された配信システム４００の端末情報送信部４１０１にそのユーザのメッセージ受信能力を問い合わせることによって得られる端末受信能力情報に基づいて、そのユーザが加入している通信事業者の配信システム４００におけるメッセージ受信能力を求めればよい。【０１８０】
なお、配信システム４００の端末情報送信部４１０１は、端末情報取得部１１０からの問い合わせに応じて、端末情報取得部４１０２によって予め取得されているそのユーザのユーザ端末３００の型番や、そのユーザが契約している回線容量やメモリ容量等の情報を送信すればよい。【０１８１】
そのユーザについて、加入している通信事業者の配信システム４００におけるメッセージ受信能力が求まると、配信先決定部１０３は、該ユーザが加入している通信事業者毎に、該通信事業者の配信システム４００を介して該ユーザが依頼されたメッセージを受信することができるか否かを判定する（ステップＳ２−４ｈ−１−２）。例えば、配信先決定部１０３は、該ユーザが加入している通信事業者の配信システム４００において、そのユーザが依頼されたメッセージを受信できるユーザ端末３００を使用しているか否かを判定してもよい。ここで、依頼されたメッセージを受信できないと判定した場合には、その通信事業者の配信システム４００を配信依頼先候補から除外する（ステップＳ２−４ｈ−１−３）。具体的には、通信事業者ユーザ取得部１０２が作成したその通信事業者の加入ユーザのリストから、該ユーザのユーザＩＤを削除すればよい。【０１８２】
配信先決定部１０３は、以上の処理を各ユーザに対して行った後に、更新後の加入ユーザリストを用いて、配信先を決定する（ステップＳ２−４ｈ−２）。なお、本実施形態は、第１の実施形態に限らず、他の実施形態とも組み合わせて実施することも可能である。【０１８３】
本実施形態によれば、ユーザのメッセージ受信能力に応じたメッセージ配信先制御を行うことができる。具体的には、各ユーザについて、ユーザ側の要因でメッセージ内容を受信できない通信事業者に対して、配信依頼をすることがなくなる。【０１８４】
実施形態１０．
次に、本発明の第１０の実施形態について説明する。本実施形態では、配信制御部１００が、ルールに従って通信事業者を決定する。【０１８５】
図２６は、本発明の第１０の実施形態の構成例を示すブロック図である。図２６に示すように、本実施形態における配信制御部１００は、図４に示す配信制御部１００の構成に、配信先決定ルール保存部１１１が追加となっている。また、情報配信システムとして、ルール設定端末１３０を備える。【０１８６】
配信先決定ルール保存部１１１は、配信先を決定するためのルール（以下、配信先決定ルールという。）を記憶する。配信先決定ルールは、例えば、「条件」と「配信先決定処理」との組によって表現される情報であってもよい。図２７に配信先決定ルールの例を示す。図２７に示す例では、「条件」として”平日”の場合と”休日”の場合とが定められていることが示されている。また、”平日”の条件に合致した場合に”通信事業者Ａを優先させる”という設定が、”休日”の条件に合致した場合に”通信事業者Ｂを優先させる”という設定がされていることが示されている。これにより、例えば、平日は会社用の端末にメッセージが来るようにし、休日はプライベート用の端末にメッセージが来るようにすることもできる。なお、時間帯よって通信事業者の優先順位を変更するようなルールを設定することも可能である。【０１８７】
なお、配信先決定ルールは、あらかじめ設定されていても、ユーザや通信事業者やサービス事業者が動的に設定してもよい。また、システム全体として１つのルールを定めても、ユーザ毎に定めてもよい。【０１８８】
また、ルール設定端末１３０は、配信先決定ルールを設定するための端末である。具体的には、配信先決定ルール保存部１１１に配信先決定ルールを記憶させたり、配信先決定ルール保存部１１１に記憶されている配信先決定ルールを変更したりする。【０１８９】
また、本実施形態における配信先決定部１０３は、配信先決定ルール保存部１１１に記憶されている配信先決定ルールに従って、配信先を決定する。例えば、配信先決定部１０３は、配信先を決定する際に、配信先決定ルール保存部１１１に記憶されている配信先決定ルールを参照し、その配信先決定ルールで示される「条件」に合致した「配信先の決定処理」に従って処理を行うことにより、配信先を決定する。【０１９０】
本実施形態によれば、複雑な配信決定処理により配信先を決定することが可能になる。【０１９１】
実施形態１１．
なお、図２８に示すように、第１０の実施形態に、さらに、配信制御部１００にプレゼンス情報取得部１１２を追加し、配信システム４００にプレゼンス情報送信部４１２を追加してもよい。図２８は、本発明の第１１の実施形態の構成例を示すブロック図である。【０１９２】
なお、本実施形態は、配信システム４００がユーザのプレゼンス情報に応じたサービスを行っている場合において、そのプレゼンス情報を配信先決定ルールの「条件」に利用する例である。なお、プレゼンス情報とは、ユーザの現在の状況（例えば、どこにいるかとか現在電話中とか離席中とか等）を示す情報である。なお、プレゼンス情報は、配信システム４００がＧＰＳ等を用いて自動で取得する場合もあるし、ユーザ入力によって取得される場合もある。【０１９３】
プレゼンス情報取得部１１２は、各配信システム４００のプレゼンス情報送信部４１２に問い合わせを行い、指定したユーザの該配信システム４００におけるプレゼンス情報を取得する。プレゼンス情報送信部４１２は、プレゼンス情報取得部１１２からの問い合わせに応じて、該配信システム４００における指定されたユーザのプレゼンス情報を送信する。【０１９４】
また、本実施形態における配信先決定部１０３は、配信先決定ルール保存部１１１に記憶されている配信先決定ルールの「条件」に合致するか否かを、プレゼンス情報取得部１１２によって取得されたプレゼンス情報によって判定する。そして、配信先決定ルールの「条件」に合致した「配信先の決定処理」に従って処理を行うことにより、配信先を決定する。【０１９５】
配信先決定部１０３は、例えば、各ユーザについて、そのユーザが加入している通信事業者の配信システム４００のうち、配信先決定ルールの「条件」にかかるプレゼンス情報に応じたサービスを行っている配信システム４００に、そのユーザのプレゼンス情報を問い合わせるようプレゼンス情報取得部１１２に依頼してもよい。そして、プレゼンス情報取得部１１２がその配信システム４００のプレゼンス情報送信部４１２に問い合わせることによって得られたユーザのプレゼンス情報に基づいて、配信先決定ルールの「条件」を判定すればよい。【０１９６】
図２９は、本実施形態における配信先決定ルールの例を示す説明図である。図２９に示す例では、「条件」として”ユーザが自宅にいる”場合と、”ユーザが会社にいる”場合とが定められていることが示されている。また、”ユーザが自宅にいる”という条件に合致した場合に”通信事業者Ａを優先させる”という設定が、”ユーザが会社にいる”という条件に合致した場合に”通信事業者Ｂを優先させる”という設定がされていることが示されている。【０１９７】
このような配信先決定ルールが設定されている場合には、配信先決定部１０３は、各ユーザについて、そのユーザが加入している通信事業者の配信システム４００のうち、位置情報に応じたサービスを行っている配信システム４００に、そのユーザの位置情報を問い合わせるようプレゼンス情報取得部１１２に依頼して、ユーザの位置情報を取得すればよい。なお、配信システム４００がユーザの位置情報を、ＧＰＳ等による現在位置で保持している場合には、ユーザの住所の情報も併せて問い合わせて、ユーザの住所と近い位置にいるか否かを判定することで、”ユーザが自宅にいる”か否かを判定してもよい。または、プレゼンス情報として、ユーザが自宅にいるか否かを示す情報を問い合わせるようにし、その判定を配信システム４００側で行うようにしてもよい。【０１９８】
本実施形態によれば、ユーザの状況に合わせた条件で配信先を決定することが可能になる。【０１９９】
なお、上記実施形態の多くは、１つの通信事業者を配信依頼先として決定する場合を例を用いて説明しているが、いずれの実施形態においても、メッセージの最大送信数が指定されている場合には、その設定情報をもとに、配信先としての条件を満たす通信事業者のうちの最大送信数以内の通信事業者を配信依頼先として決定することが可能である。なお、配信先としての条件を満たすか否か、また配信先としての条件を満たす通信事業者の中からどのように選定するかは、各実施形態における配信依頼先候補の選定条件（具体的には、メッセージ配信能力やメッセージ受信能力や配信先設定ルールの条件等）や通信事業者の決定方法（具体的には、優先順位に基づく決定やランダムによる決定、配信割合に基づく決定等）に従えばよい。なお、複数の通信事業者を決定する方法として、１つの通信事業者を決定する動作を、既に決定された通信事業者を配信依頼先候補から除外しながら繰り返し行ってもよい。【０２００】
また、上記実施形態には、サービス事業者がユーザを識別するためのユーザ識別子と、該ユーザが加入している通信事業者が該ユーザを識別するためのユーザ識別子とを対応づけた情報であるＩＤ連携情報を記憶するＩＤ連携情報記憶部と、サービス事業者が運営するサービス提供システムから、メッセージの内容と、該メッセージの配信対象とするユーザを示す情報として当該サービス事業者におけるユーザ識別子とを含むメッセージの配信要求を受信する配信要求受信部と、ＩＤ連携情報記憶部に記憶されているＩＤ連携情報に基づいて、メッセージの配信対象として指定されたユーザがどの通信事業者に加入しているかを判定し、ユーザが加入していると判定した通信事業者の中から所定の条件に従い該ユーザに対するメッセージの配信依頼先とする通信事業者を決定する配信要求処理部と、配信要求処理部によって配信依頼先として決定された通信事業者の配信システムに、配信要求受信部が受信したメッセージの内容と、該メッセージの配信対象とするユーザを示す情報として当該通信事業者を配信依頼先とするユーザの当該通信事業者におけるユーザ識別子とを含むメッセージの配信要求を送信する配信要求送信部とを備えた情報配信システムの構成が示されている。なお、上記実施例において、ＩＤ連携情報記憶部は、例えば、ＩＤ連携情報保持部１２０によって実現されている。また、配信要求受信部は、例えば、配信要求受信部１１や配信依頼受信部１０１によって実現されている。また、配信要求処理部は、例えば、配信要求処理部１２や通信事業者ユーザ取得部１０２および配信先決定部１０３によって実現されている。配信要求送信部は、例えば、配信要求送信部１３や配信要求送信部１０４によって実現されている。【０２０１】
また、上記実施形態には、配信要求処理部が、複数の通信事業者に加入しているユーザについて、該ユーザが加入している通信事業者のうちのいずれか１つの通信事業者を、メッセージの配信依頼先に決定する情報配信システムの構成が示されている。また、上記実施形態には、配信制御部が、複数の通信事業者に加入しているユーザについて、該ユーザが加入している通信事業者のうちの指定された数以内の通信事業者を、メッセージの配信依頼先に決定する情報配信システムの構成が示されている。【０２０２】
また、上記実施形態には、配信要求処理部が、複数の通信事業者に加入しているユーザについて、あらかじめ決められている方法に従って、配信依頼先とする通信事業者を決定する情報配信システムの構成が示されている（例えば、実施形態１〜９参照。）。【０２０３】
また、上記実施形態には、配信要求処理部が、複数の通信事業者に加入しているユーザについて、あらかじめ設定されている通信事業者の優先順位に従って、配信依頼先とする通信事業者を決定する情報配信システムの構成が示されている。なお、上記実施例において、配信要求処理部は、例えば、第１の実施形態における通信事業者ユーザ取得部１０２と配信先決定部１０３とによって実現されている。【０２０４】
また、上記実施形態には、配信要求処理部が、あらかじめ設定されている通信事業者の順番に沿って、所定のタイミングで優先順位を入れ替えつつ、複数の通信事業者に加入しているユーザについて、その時点における優先順位に従って、配信依頼先とする通信事業者を決定する情報配信システムの構成が示されている。なお、上記実施例において、配信要求処理部は、例えば、第２の実施形態における通信事業者ユーザ取得部１０２と順序処理配信先決定部１０３１とによって実現されている。【０２０５】
また、上記実施形態には、配信要求処理部が、複数の通信事業者に加入しているユーザについて、ランダムに配信依頼先とする通信事業者を決定する情報配信システムの構成が示されている。なお、上記実施例において、配信要求処理部は、例えば、第３の実施形態における通信事業者ユーザ取得部１０２とランダム処理配信先決定部１０３２とによって実現されている。【０２０６】
また、上記実施形態には、配信要求処理部が、複数の通信事業者に加入しているユーザについて、あらかじめ設定されている通信事業者に対する配信割合に従って、配信依頼先とする通信事業者を決定する情報配信システムの構成が示されている。なお、上記実施例において、配信要求処理部は、例えば、第４の実施形態における通信事業者ユーザ取得部１０２と配信割合配信先決定部１０３３とによって実現されている。【０２０７】
また、上記実施形態には、配信要求処理部が、通信事業者の配信システムに問い合わせることによって得られる情報に基づいて、配信依頼先とする通信事業者を決定する情報配信システムの構成が示されている（例えば、実施形態５〜１１参照。）。【０２０８】
また、上記実施形態には、配信要求処理部が、通信事業者の配信システムにメッセージ配信にかかる金額を問い合わせ、その結果得られる通信事業者毎のメッセージ配信にかかる金額に応じて、配信依頼先とする通信事業者を決定する情報配信システムの構成が示されている。なお、上記実施例において、配信要求処理部は、例えば、第５の実施形態における通信事業者ユーザ取得部１０２と配信先決定部１０３と配信金額情報取得部１０５とによって実現されている。【０２０９】
また、上記実施形態には、配信要求処理部が、通信事業者の配信システムにメッセージ配信処理の負荷状態を問い合わせ、その結果得られる通信事業者毎のメッセージ配信処理の負荷状態に応じて、配信依頼先とする通信事業者を決定する情報配信システムの構成が示されている。なお、上記実施例において、配信要求処理部は、例えば、第６の実施形態における通信事業者ユーザ取得部１０２と配信先決定部１０３と配信負荷情報取得部１０７とによって実現されている。【０２１０】
また、上記実施形態には、配信要求処理部が、通信事業者の配信システムにユーザの利用頻度を問い合わせ、その結果得られる通信事業者毎のユーザの利用頻度に応じて、配信依頼先とする通信事業者を決定する情報配信システムの構成が示されている。なお、上記実施例において、配信要求処理部は、例えば、第７の実施形態における通信事業者ユーザ取得部１０２と配信先決定部１０３と利用頻度情報取得部１０８とによって実現されている。【０２１１】
また、上記実施形態には、配信要求処理部が、通信事業者の配信システムにメッセージ配信能力を問い合わせ、その結果得られるメッセージ配信能力に基づき、該通信事業者が配信したいメッセージを配信可能か否かを判定した上で、配信したいメッセージを配信可能な通信事業者の中から、配信依頼先とする通信事業者を決定する情報配信システムの構成が示されている。なお、上記実施例において、配信要求処理部は、例えば、第８の実施形態における通信事業者ユーザ取得部１０２と配信先決定部１０３と配信依頼先候補決定部１０９とによって実現されている。【０２１２】
また、上記実施形態には、配信要求処理部が、メッセージの配信対象として指定されるユーザについて、該ユーザが加入している通信事業者の配信システムに、該配信システムが保持している該ユーザのメッセージ受信能力を問い合わせ、その結果得られる該通信事業者における該ユーザのメッセージ受信能力に基づき、該ユーザが該通信事業者を介して配信したいメッセージを受信可能か否かを判定した上で、配信したいメッセージを該ユーザに受信させることができる通信事業者の中から、配信依頼先とする通信事業者を決定する情報配信システムの構成が示されている。なお、上記実施例において、配信要求処理部は、例えば、第９の実施形態における通信事業者ユーザ取得部１０２と配信先決定部１０３と端末情報取得部１１０とによって実現されている。【０２１３】
また、上記実施形態には、配信要求処理部が、配信依頼先を決定するための方法と、該方法を実施するための条件とを定めた配信先決定ルールに従って、配信依頼先とする通信事業者を決定する情報配信システムの構成が示されている。なお、上記実施例において、配信要求処理部は、例えば、第１０の実施形態における通信事業者ユーザ取得部１０２と配信先決定部１０３と配信先決定ルール保存部１１１とによって実現されている。【０２１４】
また、上記実施形態には、配信先決定ルールに、ユーザのプレゼンス情報にかかる条件が設定され、配信要求処理部が、通信事業者の配信システムから得られるユーザのプレゼンス情報に基づいて、各ユーザが配信先決定ルールの条件に合致しているか否かを判定することによって、ユーザ毎に配信依頼先とする通信事業者を決定する情報配信システムの構成が示されている。なお、上記実施例において、配信要求処理部は、例えば、第１１の実施形態における通信事業者ユーザ取得部１０２と配信先決定部１０３とプレゼンス情報取得部１１２とによって実現されている。【０２１５】
この出願は、２００７年８月１６日に出願された日本出願特願２００７−２１２０６３を基礎とする優先権を主張し、その開示の全てをここに取り込む。
【産業上の利用可能性】
【０２１６】
本発明は、ＩＤによって管理されたユーザへのメッセージの配信を行うシステムであれば、どのようなシステムに対しても適用可能である。例えば、移動通信システムにおけるユーザＩＤと、他のインターネットサービスプロバイダシステムにおけるユーザＩＤとＩＤ連携させて、通信事業者間でメッセージの配信先を制御するといった適用方法も可能である。また、例えば、システムを用いてサービスを提供していない百貨店等に対して、メッセージの配信を依頼する装置を介して、メッセージの配信先を制御するといった適用方法も可能である。
【図面の簡単な説明】
【０２１７】
【図１】第１の実施形態による情報配信システムの概略構成図である。
【図２】ＩＤ連携情報の例を示す説明図である。
【図３】ＩＤ連携情報の他の例を示す説明図である。
【図４】第１の実施形態による情報配信システムの構成例を示すブロック図である。
【図５】ＩＤ連携情報として保持される情報の例を示す説明図である。
【図６】ＩＤ連携を用いて広告を配信する場合の配信制御部１００の動作例を示すフローチャートである。
【図７】ＩＤ連携情報として保持される情報の他の例を示す説明図である。
【図８】ＩＤ連携情報として保持される情報の他の例を示す説明図である。
【図９】ＩＤ連携情報として保持される情報の他の例を示す説明図である。
【図１０】第２の実施形態の構成例を示すブロック図である。
【図１１】順序処理配信先決定部１０３１が行う配信先決定動作の一例を示すフローチャートである。
【図１２】第３の実施形態の構成例を示すブロック図である。
【図１３】ランダム処理配信先決定部１０３２が行う配信先決定動作の一例を示すフローチャートである。
【図１４】第４の実施形態の構成例を示すブロック図である。
【図１５】第５の実施形態の構成例を示すブロック図である。
【図１６】第５の実施形態における配信先決定処理の動作例を示すフローチャートである。
【図１７】第５の実施形態の他の構成例を示すブロック図である。
【図１８】第６の実施形態の構成例を示すブロック図である。
【図１９】第６の実施形態における配信先決定処理の動作例を示すフローチャートである。
【図２０】第７の実施形態の構成例を示すブロック図である。
【図２１】第７の実施形態における配信先決定処理の動作例を示すフローチャートである。
【図２２】第８の実施形態の構成例を示すブロック図である。
【図２３】第８の実施形態における配信先候補の決定動作および加入ユーザ取得動作の一例を示すフローチャートである。
【図２４】第９の実施形態の構成例を示すブロック図である。
【図２５】第９の実施形態の動作の一例を示すフローチャートである。
【図２６】第１０の実施形態の構成例を示すブロック図である。
【図２７】配信先決定ルールの例を示す説明図である。
【図２８】第１１の実施形態の構成例を示すブロック図である。
【図２９】第１１の実施形態における配信先決定ルールの例を示す説明図である。
【符号の説明】
【０２１８】
１００    配信制御部
１２０    ＩＤ連携情報保持部
７００    ＩＤ管理システム
７０１    認証実行部
１０１    配信依頼受信部
１０２    通信事業者ユーザ取得部
１０３    配信先決定部
２００    サービス提供システム
２０１    配信依頼送信部
２０２    ユーザ認証部
２０３    サービス提供部
３００    ユーザ端末
４００Ａ，４００Ｂ    配信システム
４０１    配信要求受信部
４０２    配信部
４０３    ユーザ認証部
４０４    サービス提供部
８００    サービス提供システム管理端末
１０３１    順序処理配信先決定部
１０３２    ランダム処理配信先決定部
１０３３    配信割合配信先決定部
１０４    配信要求送信部
４１２    プレゼンス情報送信部
１０５    配信金額情報取得部
４０５    配信金額情報送信部
１０６    課金管理部
１０７    配信負荷情報取得部
４０７    配信負荷情報送信部
１０８    利用頻度情報取得部
４０８    利用頻度情報送信部
１０９    配信依頼先候補決定部
４０９    配信能力情報送信部
１１０    端末情報取得部
４１０１    端末情報送信部
４１０２    端末情報取得部
１１１    配信先決定ルール保存部
１３０    ルール設定端末
１１２    プレゼンス情報取得部
４１２    プレゼンス情報送信部
【図１】
2009022568.tif 000003
【図２】
2009022568.tif 000004
【図３】
2009022568.tif 000005
【図４】
2009022568.tif 000006
【図５】
2009022568.tif 000007
【図６】
2009022568.tif 000008
【図７】
2009022568.tif 000009
【図８】
2009022568.tif 000010
【図９】
2009022568.tif 000011
【図１０】
2009022568.tif 000012
【図１１】
2009022568.tif 000013
【図１２】
2009022568.tif 000014
【図１３】
2009022568.tif 000015
【図１４】
2009022568.tif 000016
【図１５】
2009022568.tif 000017
【図１６】
2009022568.tif 000018
【図１７】
2009022568.tif 000019
【図１８】
2009022568.tif 000020
【図１９】
2009022568.tif 000021
【図２０】
2009022568.tif 000022
【図２１】
2009022568.tif 000023
【図２２】
2009022568.tif 000024
【図２３】
2009022568.tif 000025
【図２４】
2009022568.tif 000026
【図２５】
2009022568.tif 000027
【図２６】
2009022568.tif 000028
【図２７】
2009022568.tif 000029
【図２８】
2009022568.tif 000030
【図２９】
2009022568.tif 000031
【国際調査報告】
2009022568.tif 000032
2009022568.tif 000033
2009022568.tif 000034