JP2010176252A - 情報提供方法 - Google Patents

Abstract

【課題】サービス利用者から送信された画像が似ている利用者を自動的に結びつけること。
【解決手段】本発明による情報提供方法は、複数のサービス利用者から送信された画像に標題を付与する処理と、付与した標題をサービス利用者ごとに登録する処理と、同じ標題が登録されているサービス利用者を標題ごとにグループ化する処理とを含む。
【選択図】図１２

Description

本発明は、情報提供方法に関する。

ネットワークで結ばれた画像蓄積サーバーに画像を蓄積してアルバムのように利用する、いわゆるオンラインアルバムが知られている（特許文献１参照）。

特開２００２−３４２４６３号公報

従来技術では、サービス利用者が登録した利用者自身のプロフィール情報に基づいてサービス利用者を分類することはあっても、サービス利用者がサーバーへ送信した画像に基づいてサービス利用者を分類することは困難であった。

本発明による情報提供方法は、複数のサービス利用者から送信された画像に標題を付与する処理と、付与した標題をサービス利用者ごとに登録する処理と、同じ標題が登録されているサービス利用者を標題ごとにグループ化する処理とを含むことを特徴とする。

本発明によれば、送信画像が似ているサービス利用者をグループ化できる。

本発明の一実施形態によるサービス提供システムを例示する図である。 メインＣＰＵが実行するグルーピング処理の流れを説明するフローチャートである。 クラスタリング処理を説明するフローチャートである。 画像ごとのイベント判定処理を説明するフローチャートである。 クラスタごとのイベント判定処理を説明するフローチャートである。 クラスタの統合処理を説明するフローチャートである。 代表画像を決める処理を説明するフローチャートである。 イベント候補テーブルを例示する図である。 クラスタに対するイベント判定（運動会）を例示する図である。 クラスタに対するイベント判定（結婚式）を例示する図である。 クラスタに対するイベント判定（花見）を例示する図である。 イベントリストを例示する図である。 端末に表示されるコミュニティ全体を示す画像を例示する図である。 端末に表示されるイベント表示画像を例示する図である。 端末に表示される標題イベントに対応する画像群表示を例示する図である。 端末に表示されるサービス利用者間の密接度を示す画像を例示する図である。

以下、図面を参照して本発明を実施するための形態について説明する。図１は、本発明の一実施の形態によるサービス提供システムを例示する図である。サービス提供システムは、コミュニケーションサイトを運営するサービス提供者が、サービス利用者によってサイトの電子掲示板に書き込まれた情報や、サービス利用者によってサイトに登録された画像に関する情報を、サービス利用者へ提供するためのシステムである。図１において、ネットワークに管理サーバー１１、端末（ＰＣ）１２、アクセスポイント１３がそれぞれ接続されている。

管理サーバー１１は、サービス提供者によってデータセンターなどに配置される。管理サーバー１１は、サービス利用者ごとの管理情報、登録された画像情報、および書き込み情報などを管理する。情報の記録は、不図示の記録装置で行う。ＰＣ１２はサービス利用者が自宅などに保有するインターネットアクセス端末（たとえば、パーソナルコンピュータ）であり、インターネットを介して管理サーバー１１へアクセス可能に構成される。

アクセスポイント１３は、サービス提供者または通信事業者によって交通ターミナルや店舗等に設けられた無線アクセス端末である。電子カメラ１０が通信機能を有する場合、サービス利用者は電子カメラ１０からアクセスポイント１３を介して管理サーバー１１へアクセス可能である。

上記サービス提供システムにおいて、サービス利用者は以下のいずれかの態様によって管理サーバー１１へアクセスし、情報提供サービスを利用する。
（１）サービス利用者は、端末１２からインターネットに接続して情報提供サービスを利用する。電子カメラ１０および端末１２間をＵＳＢケーブルなどで接続し、電子カメラ１０内のデータを管理サーバー１１へ送信可能にする。

（２）サービス利用者は、端末１２からインターネットに接続して情報提供サービスを利用する。電子カメラ１０に装着されている記録媒体１０Ａを、電子カメラ１０から取り出して端末１２のカードスロット（不図示）へ実装し、記録媒体１０Ａ内のデータを管理サーバー１１へ送信可能にする。この場合、電子カメラ１０および端末１２間の接続は不要である。

（３）サービス利用者は、電子カメラ１０をアクセスポイント１３経由でインターネットに接続し、情報提供サービスを利用する。アクセスポイント１３との間で通信が成立した電子カメラ１０は、電子カメラ１０内のデータを管理サーバー１１へ送信可能にする。

（４）サービス利用者は、不図示の携帯電話機などのモバイル端末からインターネットに接続して情報提供サービスを利用する。当該携帯電話機がカメラ機能を備えている場合、撮影画像のデータを管理サーバー１１へ送信可能にする。

サービス提供システムは、サイトに画像を登録したサービス利用者に対し、サービス利用者自身が登録した画像の閲覧を許可するだけでなく、当該サービス利用者にコミュニティ参加を許可する。

サービス利用者はコミュニティに参加することで、コミュニケーションサイト内にコミュニティごとに設けられた電子掲示板に書き込みを行ったり、書き込み情報を同じコミュニティに参加する他のサービス利用者との間で共有、交換したりする他、同じコミュニティに参加する他のサービス利用者が登録した画像を閲覧することもできる。なお、登録画像が他の利用者によって閲覧されないようにすることも可能に構成されている。

サービス提供システムは、サービス利用者が管理サーバー１１へ画像を登録した場合に、登録画像に基づいて該サービス利用者に対して参加を許可するコミュニティを自動的に決定する。なお、サービス利用者自身が、参加しようとするコミュニティを指定することも可能に構成されている。

以下、コミュニティの決定方法の詳細について説明する。コミュニティ決定の流れは、(I)サービス利用者が管理サーバー１１へ画像を登録する。
(II)管理サーバー１１が登録画像に対して標題イベントを決定する。
(III)管理サーバー１１がイベントリストを作成する。
(IV)管理サーバー１１がサービス利用者に参加を許可すべきコミュニティを決定する。
の順に行う。

(I)画像登録
上記(I)の画像登録は、サービス利用者が上述した（１）〜（４）のいずれかの態様によって管理サーバー１１へアクセスすることによって行う。

(II)標題イベント決定
上記(II)の標題イベント決定について、以下に説明する。
＜撮影画像のグルーピング＞
本実施形態の管理サーバー１１は、登録画像を自動的にグルーピングする機能を備える。具体的には、登録時にアップロードされた画像ファイルに対してグループ分けを行い、画像ファイルをグループごとに設けたフォルダ内に格納する。管理サーバー１１はさらに、各フォルダ内に含まれる画像群に基づいて、画像群の撮影対象を表す標題（たとえば、撮影シーン）を決める。そして、この標題に基づいて、各フォルダ（グループ）の画像群を代表する画像ファイルをフォルダ（グループ）ごとにそれぞれ選ぶ。なお、画像ファイルをグループごとに設けたフォルダ内に格納しなくても、画像ファイルの管理テーブルを作成し、該テーブルに画像ファイルに対するグループ分け情報を格納するようにしてもよい。

図２は、管理サーバー１１のＣＰＵ（不図示）が実行する上記グルーピング処理の流れを説明するフローチャートである。ＣＰＵは、サービス利用者側から登録画像がアップロードされると、アップロードされた画像群を対象に図２による処理を開始する。

図２のステップＳ１０において、管理サーバー１１は、アップロードされた画像ファイルに対してクラスタリング手法によってグループ分けを行い、ステップＳ２０へ進む。クラスタリング処理の詳細については後述する。ステップＳ２０において、管理サーバー１１は、クラスタ（グループ分け後の画像ファイルの集合）に含まれる画像ごとにイベント判定を行ってステップＳ３０へ進む。「イベント」は画像の撮影シーンを表すもので、たとえば、「運動会」、「結婚式」、「花見」、「海水浴」、「北海道旅行」などをいう。画像ごとのイベント判定処理の詳細については後述する。

ステップＳ３０において、管理サーバー１１は、クラスタごとにイベント判定を行ってステップＳ４０へ進む。「イベント」が標題である点は上記ステップＳ２０の場合と共通であるが、ステップＳ２０におけるイベント判定が個々の画像を対象とするものであるのに対し、ステップＳ３０におけるイベント判定がクラスタを代表する「イベント」を判定する点において異なる。クラスタごとのイベント判定処理の詳細については後述する。

ステップＳ４０において、管理サーバー１１は、必要に応じてクラスタを統合し、ステップＳ５０へ進む。クラスタの統合処理の詳細については後述する。ステップＳ５０において、管理サーバー１１は、クラスタを代表する画像ファイルを決定して図２による処理を終了する。

＜クラスタリング処理＞
クラスタリング処理（Ｓ１０）の詳細について、図３に例示するフローチャートを参照して説明する。クラスタリング処理は、たとえば、撮影日時情報を用いて行う。図３のステップＳ１１において、管理サーバー１１はアップロードされた全ての画像ファイルを対象に、画像ファイルの付加情報部に記録されている撮影日時を示す情報を抽出してステップＳ１２へ進む。

ステップＳ１２において、管理サーバー１１は、全ての画像ファイルから撮影日時を示す情報を抽出したか否かを判定する。管理サーバー１１は、全画像ファイルから必要な情報を抽出済みの場合にステップＳ１２を肯定判定してステップＳ１３へ進み、必要な情報を全画像ファイルから抽出済みでない場合にはステップＳ１２を否定判定してステップＳ１１へ戻る。ステップＳ１１へ戻る場合は、上記抽出処理を繰り返す。

ステップＳ１３において、管理サーバー１１は、階層的クラスタリングを用いる。その中で、たとえば最短距離法を用いてクラスタリングを行う。具体的には、１画像につき１クラスタを処理の起点として、撮影時刻が近いクラスタを逐次併合する処理を繰り返すことにより、画像ファイルを複数のクラスタ（撮影時刻が近い画像ファイルの集合）に分ける。管理サーバー１１は、クラスタ数が所定の数まで減った場合にステップＳ１４へ進む。または、近接するクラスタ間において、一方の集合内で最も遅い撮影時刻と、他方の集合内で最も早い撮影時刻との差が所定時間（たとえば３時間）以上になった場合にステップＳ１４へ進む。なお、階層的クラスタリングの中でも最短距離法以外の手法を用いてもよい。さらに、階層的クラスタリング以外の手法（たとえば、分割最適化法）を用いてもよい。

ステップＳ１４において、管理サーバー１１は、上記クラスタに対応させてフォルダを記録媒体３０内に生成してステップＳ１５へ進む。ステップＳ１５において、管理サーバー１１は、生成したフォルダ内へ対応する画像ファイルを移動させて図３による処理を終了する。これにより、クラスタに対応する各フォルダの中に、各クラスタに属する画像ファイルが格納される。なお、画像ファイルをグループごとに設けたフォルダ内に格納しなくても、画像ファイルの管理テーブルを作成し、該テーブルに画像ファイルに対するグループ分け情報を格納するようにしてもよい。

＜画像ごとのイベント判定処理＞
画像単位のイベント判定処理（Ｓ２０）の詳細について、図４に例示するフローチャートを参照して説明する。図４のステップＳ２１において、管理サーバー１１は、複数のクラスタの中からクラスタを１つ特定してステップＳ２２へ進む。特定順は、たとえば、撮影日時が古い順（最も早い撮影時刻の画像ファイルを有するクラスタを優先）とする。

ステップＳ２２において、管理サーバー１１は、判定対象とするイベント（イベント候補と呼ぶ）を決定する。管理サーバー１１は、図８に例示するイベント候補テーブルを参照し、クラスタを構成する画像ファイルの撮影日が属する月に対応するイベントを選ぶ。たとえば、画像ファイルが５月に撮影されたものである場合には、「花見」、「運動会」、および「結婚式」をイベント候補とする。イベント候補テーブルは、月ごとに発生頻度が高いイベントを記したものであり、過去のイベント発生月に基づいてあらかじめ作成され、サーバー１１内に記録されている。

図８によれば、発生月や季節との相関が強いイベントは該当月のみに含まれ、「結婚式」のように発生月との相関が弱いイベントは複数の月に含まれる。管理サーバー１１は、クラスタを構成する画像ファイルの撮影日が複数の月に属する場合は、一例として、より多くの画像ファイルが属する月に対応するイベント候補を選ぶ。管理サーバー１１は、以上のように判定対象とするイベントを決定したら、ステップＳ２３へ進む。

ステップＳ２３において、管理サーバー１１は、特定したクラスタを構成する画像ファイルの中から画像ファイルを１つ特定してステップＳ２４へ進む。ステップＳ２４において、管理サーバー１１は、特定した画像ファイルに含まれる画像データに基づいて、当該画像の特徴量を算出してステップＳ２５へ進む。

管理サーバー１１は、ステップＳ２２において決定したイベント候補の判定に適した画像の特徴量を算出する。イベント候補と算出すべき特徴量との関係は、あらかじめテーブル化されてサーバー１１内に記録されている。特徴量は、たとえば、画像の所定領域を構成する画素データに基づいて算出される色情報、鮮鋭度情報、質感情報、模様情報、および明るさ情報などである。また、画像サイズやカラーヒストグラムの情報を特徴量として扱ってもよい。特徴量算出は公知技術であるため、本説明では特徴量算出に関する詳細な説明を省略する。

ステップＳ２５−ステップＳ２７において、管理サーバー１１は、ステップＳ２２において決定したイベント候補に対応した識別器をそれぞれ用いて、各イベントらしさを表す確率を算出する。識別器は、複数のサンプル画像データに基づいてＳＶＭ(Support Vector Machine)手法を用いる機械学習によって算出された特徴量情報である。たとえば、「花見」用の識別器は、複数の「花見」および「非花見」のサンプル画像に基づいて算出された特徴量情報である。「運動会」用の識別器は、複数の「運動会」および「非運動会」のサンプル画像に基づいて算出された特徴量情報である。「結婚式」用の識別器は、複数の「結婚式」および「非結婚式」のサンプル画像に基づいて算出された特徴量情報である。本実施形態では、複数のイベント候補のそれぞれに対応する識別器があらかじめ生成され、サーバー１１内に記録されている。本稿では、イベント候補の数が３つの場合を例に説明している。管理サーバー１１は、ステップＳ２３において特定した１画像ごとに、イベント候補に挙げられたイベントらしさ（確率）Ｐを算出してステップＳ２８へ進む。

イベントらしさを表す確率Ｐは、識別器によって表される特徴量空間において空間を仕切る境界（たとえば、「運動会」領域と、「非運動会」領域との境界）と、ステップＳ２４において算出された特徴量との距離に対応する。ある画像から算出した特徴量が、「運動会」用の識別器によって表される特徴量空間で「運動会」に対応する特徴量領域の奥に位置し、「非運動会」に対応する特徴量領域までの距離が長ければ、「運動会」らしさの確率が高い。一方、画像から算出した特徴量が、「運動会」に対応する特徴量領域の端に位置し、「非運動会」に対応する特徴量領域までの距離が短ければ、「運動会」らしさの確率が低い。管理サーバー１１は、上記距離に応じて確率を算出する。

ステップＳ２８において、管理サーバー１１は、特定したクラスタ内の全画像ファイルに対して処理を終了したか否かを判定する。管理サーバー１１は、クラスタ内の全ての画像について特徴量算出、およびイベントらしさ（確率）Ｐの算出を行った場合にステップＳ２８を肯定判定してステップＳ２９へ進む。管理サーバー１１は、クラスタ内の全ての画像について特徴量算出、およびイベントらしさ（確率）Ｐの算出を行っていない場合には、ステップＳ２８を否定判定してステップＳ２３へ戻る。ステップＳ２３へ戻った管理サーバー１１は、特定したクラスタを構成する画像ファイルのうち他の１つの画像ファイルを特定してステップＳ２４へ進む。

ステップＳ２９において、管理サーバー１１は、全てのクラスタに対して処理を終了したか否かを判定する。管理サーバー１１は、全てのクラスタについて特徴量算出、およびイベントらしさ（確率）Ｐの算出を行った場合にステップＳ２９を肯定判定して図４による処理を終了する。管理サーバー１１は、全てのクラスタについて特徴量算出、およびイベントらしさ（確率）Ｐの算出を行っていない場合には、ステップＳ２９を否定判定してステップＳ２１へ戻る。ステップＳ２１へ戻った管理サーバー１１は、他の１つのクラスタを特定してステップＳ２２へ進む。

＜クラスタごとのイベント判定処理＞
クラスタ単位のイベント判定処理（Ｓ３０）の詳細について、図５に例示するフローチャートを参照して説明する。図５のステップＳ３１において、管理サーバー１１は、複数のクラスタの中からクラスタを１つ特定してステップＳ３２へ進む。特定順は、たとえば、撮影日時が古い順（最も早い撮影時刻の画像ファイルを有するクラスタを優先）とする。

ステップＳ３２において、管理サーバー１１は、イベント候補の中から判定対象とするイベントを１つ特定してステップＳ３３へ進む。ステップＳ３３において、管理サーバー１１は、Ｓ３１において特定したクラスタを構成する画像ファイルの中から画像ファイルを１つ特定してステップＳ３４へ進む。ステップＳ３４において、管理サーバー１１は、Ｓ３２において特定したイベントに対するイベントらしさ（確率）Ｐが所定の判定閾値Ｐth以上か否かを判定する。管理サーバー１１は、イベントらしさ（確率）Ｐが判定閾値Ｐth以上の場合にステップＳ３４を肯定判定してステップＳ３５へ進む。管理サーバー１１は、イベントらしさ（確率）Ｐが判定閾値Ｐth未満の場合にはステップＳ３４を否定判定し、ステップＳ３６へ進む。

ステップＳ３５において、管理サーバー１１は、Psum=Psum+Ｐを算出してステップＳ３６へ進む。ステップＳ３６において、管理サーバー１１は、特定したクラスタ内の全画像ファイルに対して処理を終了したか否かを判定する。管理サーバー１１は、クラスタ内の全ての画像について処理を行った場合にステップＳ３６を肯定判定してステップＳ３７へ進む。管理サーバー１１は、クラスタ内の全ての画像について処理を行っていない場合には、ステップＳ３６を否定判定してステップＳ３３へ戻る。ステップＳ３３へ戻った管理サーバー１１は、特定したクラスタを構成する画像ファイルのうち他の１つの画像ファイルを特定してステップＳ３４へ進む。

ステップＳ３７において、管理サーバー１１は、上記Psumへ加算したイベントらしさ（確率）Ｐの個数がクラスタ内の全画像ファイル数のＮパーセント以上か否かを判定する。管理サーバー１１は、加算したＰの個数がＮパーセント以上の場合にステップＳ３７を肯定判定してステップＳ３８へ進む。管理サーバー１１は、加算したＰの個数がＮパーセント未満の場合にはステップＳ３７を否定判定し、ステップＳ４１へ進む。ステップＳ４１において、管理サーバー１１は、Psum=０としてステップＳ３８へ進む。

ステップＳ３８において、管理サーバー１１は、イベント候補の全てについてPsumを算出する処理を終了したか否かを判定する。管理サーバー１１は、全てのイベントについて算出処理を終了した場合にステップＳ３８を肯定判定してステップＳ３９へ進む。管理サーバー１１は、全てのイベントについて算出処理を終了していない場合にはステップＳ３８を否定判定し、ステップＳ３２へ戻る。ステップＳ３２へ戻った管理サーバー１１は、イベント候補のうち判定対象とする他のイベント１つを特定してステップＳ３３へ進む。

ステップＳ３９において、管理サーバー１１は、イベント候補ごとに算出したPsumのうち、その最大値に対応するイベント候補を当該クラスタの標題イベントに決定してステップＳ４２へ進む。

ステップＳ４２において、管理サーバー１１は、全てのクラスタについてPsumの算出、および標題イベントを決定する処理を終了したか否かを判定する。管理サーバー１１は、全てのクラスタについて処理を終了した場合にステップＳ４２を肯定判定して図５による処理を終了する。管理サーバー１１は、全てのクラスタについて処理を終了していない場合にはステップＳ４２を否定判定し、ステップＳ３１へ戻る。ステップＳ３１へ戻った管理サーバー１１は、他のクラスタ１つを特定してステップＳ３２へ進む。

図９−図１１は、画像ファイルの集合（画像数＝５）を含むクラスタに対するイベント判定を例示する図である。イベント候補は、たとえば「運動会」、「結婚式」、および「花見」であり、画像１−画像５のそれぞれについて、「運動会」らしさ、「結婚式」らしさ、および「花見」らしさの確率Ｐが算出されている。本例では、判定閾値Ｐth＝４０パーセントとし、判定閾値Ｎ＝４０パーセントとする。

図９の場合、「運動会」らしさについてのPsumは、「運動会」らしさを示すＰが判定閾値Ｐth以上の画像（すなわち、画像４以外の画像１−画像３、および画像５）について、それぞれのＰを加算する（ステップＳ３５）。この場合のPsumは、85（画像１）+90（画像２）+80（画像３）+75（画像５）=330である。

図１０の場合、「結婚式」らしさを示すＰが判定閾値Ｐth以上となるのは画像４のみであるため、「結婚式」らしさについてのPsumは、画像４について算出されているＰのみを加算対象にする。これにより、Psum=45（画像４）を得る。ここで、画像４（１画像）は、画像数５のうち２０パーセントに相当するため上記Ｎ（４０パーセント）に満たない。そこで管理サーバー１１は、図１０の場合のPsumを０とする（ステップＳ４１）。

図１１において、「花見」らしさについてのPsumは、「花見」らしさを示すＰが判定閾値Ｐth以上の画像（すなわち、画像３以外の画像１−画像２、および画像４−画像５）について、それぞれのＰを加算する（ステップＳ３５）。この場合のPsumは、60（画像１）+70（画像２）+65（画像４）+75（画像５）=270である。

管理サーバー１１は、イベント候補（「運動会」、「結婚式」、および「花見」）のうち、最大Psumに対応する「運動会」を、当該クラスタの標題イベントとする。

＜クラスタの統合処理＞
クラスタの統合処理（Ｓ４０）の詳細について、図６に例示するフローチャートを参照して説明する。図６のステップＳ５１において、管理サーバー１１は、複数のクラスタのうち、近接するクラスタ間の時間差が判定閾値Ｔ以下か否かを判定する。管理サーバー１１は、たとえば、一方のクラスタで最も遅い撮影時刻と、他方のクラスタ内で最も早い撮影時刻との差が上記Ｔ以下の場合にステップＳ５１を肯定判定してステップＳ５２へ進む。管理サーバー１１は、時間差が上記Ｔを超える場合にはステップＳ５１を否定判定して図６による処理を終了する。ステップＳ５１を否定判定する場合は、クラスタの統合を行わない。

ステップＳ５２において、管理サーバー１１は、時間差Ｔ以下で近接するクラスタ同士の標題イベントが同一か否かを判定する。管理サーバー１１は、標題イベントが同一の場合にステップＳ５２を肯定判定してステップＳ５３へ進む。管理サーバー１１は、標題イベントが同一でない場合にはステップＳ５２を否定判定して図６による処理を終了する。ステップＳ５２を否定判定する場合は、クラスタの統合を行わない。

ステップＳ５３において、管理サーバー１１は、２つのクラスタを１つのクラスタに統合して図６による処理を終了する。管理サーバー１１は、全クラスタに対してクラスタの統合処理を繰り返す。以上の処理により、クラスタ数が減少する。

＜クラスタごとの代表画像の決定処理＞
クラスタ単位の代表画像決定処理の詳細について、図７に例示するフローチャートを参照して説明する。図７のステップＳ６１において、管理サーバー１１は、複数のクラスタの中からクラスタを１つ特定してステップＳ６２へ進む。特定順は、たとえば、撮影日時が古い順（最も早い撮影時刻の画像ファイルを有するクラスタを優先）とする。

ステップＳ６２において、管理サーバー１１は、クラスタ内に含まれる画像のうち最もスコアが高いもの、すなわち、当該クラスタの標題イベントに対応するイベントらしさを示す確率Ｐが最大となる画像を代表画像として選んでステップＳ６３へ進む。ステップＳ６３において、管理サーバー１１は、全てのクラスタについて代表画像を選んだか否かを判定する。管理サーバー１１は、全てのクラスタについて処理を終了した場合にステップＳ６３を肯定判定して図７による処理を終了する。管理サーバー１１は、全てのクラスタについて処理を終了していない場合にはステップＳ６３を否定判定し、ステップＳ６１へ戻る。ステップＳ６１へ戻った管理サーバー１１は、他のクラスタ１つを特定してステップＳ６２へ進む。

(III)イベントリスト作成
上記(III)のイベントリスト作成について説明する。管理サーバー１１は、サービス利用者から登録された画像群に付与した標題イベント、および標題イベントを決定する際に取得した情報に基づいて図１２に例示するイベントリストを作成する。なお、既にイベントリストが作成されている場合は、最新の内容に合致するように更新すればよい。

図１２において、画像ファイルの集合であるクラスタの標題イベントの欄には、上から順に各クラスタに付与されたイベント「海」、「海」、「運動会」、「ディズニー(登録商標)」、「花見」…が記されている。撮影日の欄には、各クラスタに含まれる画像の中で最も頻出の撮影日が記されている。

スコアの欄には、付与された標題イベントに関するイベントらしさを示すＰについて、当該クラスタに含まれる全画像の平均値が記される。たとえば、図１２の１番上のクラスタについてのスコア（＝６０）は、当該クラスタに含まれる各画像（２０枚）についてのイベントらしさを示すＰ（本例では「海」らしさの確率）の平均値である。

撮影場所の欄には、各クラスタに含まれる画像が撮影地情報を有する場合に、当該画像群の撮影地の中心位置を示す情報（たとえば、緯度経度情報）が記されている。撮影枚数の欄には、当該クラスタに含まれる画像数（たとえば、２０枚）が記されている。

管理サーバー１１は、サービス利用者ごとに上述したイベントリストを作成し、作成したイベントを示す情報をサーバー１１側のストレージ装置（不図示）に保存する。

(IV)コミュニティ決定
管理サーバー１１は、イベントリストの内容に基づいてサービス利用者に参加を許可するコミュニティを決定する。たとえば、同じ標題イベントが付与されている複数のサービス利用者が同じコミュニティへ参加できるように、各サービス利用者のコミュニティを決定し、登録する。

たとえば、図１２に例示したイベントリストが、サービス利用者であるＣさんについてのイベントリストであると仮定する。図１２により、Ｃさんが登録した画像群（クラスタ）に付与された標題イベントは、「海」、「海」、「運動会」、「ディズニー(登録商標)」、「花見」…である。

この場合において、サービス利用者であるＦさんについて作成されたイベントリストの中に、「海」、「運動会」、「ディズニー(登録商標)」、「花見」…のいずれかと同じ標題イベント（たとえば「海」）が存在する場合には、管理サーバー１１は、サービス利用者の中からＦさんを抽出する。そして、ＣさんとＦさんとを同じコミュニティ（コミュニティ名を「海」とする）に参加するように登録する。

また、サービス利用者であるＤさんについて作成されたイベントリストの中に、「海」、「運動会」、「ディズニー(登録商標)」、「花見」…のいずれかと共通する標題イベント（たとえば「運動会」）が存在する場合には、管理サーバー１１は、ＣさんとＤさんとを同じコミュニティ（コミュニティ名を「運動会」とする）に参加するように登録する。この場合のＣさんは、２つのコミュニティ（「海」と「運動会」）に参加が許可される。

このように、管理サーバー１１は、「海」や「運動会」など、内容が共通する画像を登録したサービス利用者同士を結びつけるように、関心がある事象や趣味、嗜好が似ているサービス利用者が同じコミュニティにおいて情報交換できるサービスを提供する。

管理サーバー１１は、サービス利用者ごとに作成したイベントリストの情報に基づいて、サービス利用者に対してコミュニティ全体を知らせる情報の提供を行う。図１３は、サービス利用者のＣさんの端末１２（図１）に表示されるコミュニティ全体を示す画像を例示する図である。

図１３において、管理サーバー１１が登録した全コミュニティをそれぞれ表すアイコン５２〜５７が表示されている。コミュニティアイコン５２〜５７の中の文字は、対応するコミュニティの名称を表す。コミュニティアイコン５２〜５７の態様は、後述するイベントアイコン６２〜６９（図１４）の態様と異ならせている。たとえば、コミュニティアイコン５２〜５７は右上に影を有し、イベントアイコン６２〜６９（図１４）は右下に影を有する。

図１３は、サービス利用者のＣさんの端末１２（図１）へ提供される情報であるため、画面中央のサークル５１内に表示されるコミュニティアイコン５２〜５４は、サービス利用者のＣさんに参加が許可されている（登録されている）コミュニティを表す。画面中央のサークル５１の外に表示されるコミュニティアイコン５５〜５７は、サービス利用者のＣさんに参加が許可されていない（登録されていない）コミュニティを表す。管理サーバー１１は、図１３に例示した画像表示に必要な情報を、端末１２からの要求に応じて該端末１２へ提供する。端末１２に表示された画像をサービス利用者が閲覧する。

図１４は、サービス利用者のＣさんの端末１２（図１）に表示されるイベント表示画像を例示する図である。管理サーバー１１は、図１４に例示した画像表示に必要な情報を、図１３のコミュニティアイコン５２（「海」に対応）が選択されたことを示す端末１２からの信号に応じて該端末１２へ提供する。端末１２に表示された画像をサービス利用者が閲覧する。

図１４において、「海」に対応する標題イベントをそれぞれ表すアイコン６２〜６９が表示されている。イベントアイコン６２〜６９の中の文字は、対応する標題イベントの名称を表す。図１４は、サービス利用者のＣさんの端末１２（図１）へ提供される情報であるため、画面中央のサークル６１内に表示されるイベントアイコン６２、６３は、サービス利用者のＣさんが登録した画像群（クラスタ）を表す。画面中央のサークル６１の外に表示されるイベントアイコン６４〜６９は、サービス利用者のＣさん以外のサービス利用者が登録した画像群（クラスタ）を表す。

図１５は、サービス利用者のＣさんの端末１２（図１）に表示される標題イベントに対応する画像群（クラスタ）の画像表示を例示する図である。管理サーバー１１は、図１５に例示した画像表示に必要な情報を、図１４のイベントアイコン６２（「海」に対応）が選択されたことを示す端末１２からの信号に応じて該端末１２へ提供する。

図１５において、「海」に対応する２つの画像群（クラスタ）を構成するサムネイル画像６２ａ、６２ｂ、６３ａ、６３ｂ、６４ａ〜６４ｃ、６５ａ〜６５ｃ、６６ａ〜６６ｆ、６７ａ〜６７ｄ、６８ａ〜６８ｃ、および６９ａ〜６９ｄがそれぞれ表示されている。図１５は、サービス利用者のＣさんの端末１２（図１）へ提供される情報であるため、画面中央のサークル６１内に表示されるサムネイル画像６２ａ、６２ｂ、６３ａおよび６３ｂは、サービス利用者のＣさんが登録した画像群（クラスタ）であって、標題イベントが「海」であるものを表す。画面中央のサークル６１の外に表示されるサムネイル画像は、サービス利用者のＣさん以外のサービス利用者が登録した画像群（クラスタ）であって、標題イベントが「海」であるものを表す。

管理サーバー１１は、図１５の表示画面を表示した状態でいずれかのサムネイル画像が選択されたことを示す信号を端末１２から受けた場合、当該サムネイル画像に対応する本画像のデータを該端末１２へ提供する。これにより、端末１２側に当該本画像データによる再生画像が表示され、サービス利用者によって閲覧される。

管理サーバー１１は、サービス利用者間の密接度を示す情報を提供することもできる。管理サーバー１１は、密接度情報を要求する信号を端末１２から受けた場合、図１６に例示する画像表示に必要なデータを該端末１２へ提供する。これにより、端末１２側に図１６による画像が表示され、サービス利用者によって閲覧される。

図１６において、Ｃさんは、Ｄさんと共通の２つのコミュニティに登録されている（Ｃ−Ｄ間の直線に数値「２」が記される）。また、Ｃさんは、Ａさんと共通の４つのコミュニティに登録されている（Ｃ−Ａ間の直線に数値「４」が記される）。さらに、Ｃさんは、Ｆさんと共通の４つのコミュニティに登録されている（Ｃ−Ｆ間の直線に数値「４」が記される）。

以上説明した実施形態によれば、以下の作用効果が得られる。
（１）サービス提供システムの管理サーバー１１は、複数のサービス利用者から登録された画像に標題イベントを付与し、付与した標題イベントをサービス利用者ごとに登録し、同じ標題イベントが登録されているサービス利用者を標題イベントごとにグループ化するようにした。内容が共通する画像を登録したサービス利用者をグループ化することで、関心がある事象や趣味、嗜好が似ている利用者同士を結びつけることができる。

（２）上記グループ化する処理は、同じ標題イベントが登録されているサービス利用者のうち、類似する画像を送信したサービス利用者をグループ化するようにしたので、登録画像の内容がより共通するサービス利用者を結びつけることができる。

（３）上記グループ化する処理では、画像の撮影日時、撮影位置、撮影枚数および付与された標題イベントらしさを示す情報の少なくとも１つを用いて類似する画像を判定するようにしたので、登録画像の内容がより共通するサービス利用者を結びつけることができる。

（４）上記標題イベントを付与する処理は、サービス利用者から登録された画像の特徴量を算出する特徴量算出処理と、算出された画像の特徴量に基づいて画像に標題イベントを付与する標題付与処理とを含むので、内容が共通する画像に対して同じ標題イベントを付与できる。

（５）グループ化したサービス利用者間で情報を共有させるようにしたので、グループ内のサービス利用者に同じコミュニティサービスを提供できる。

（変形例１）
管理サーバー１１は、「海」や「運動会」など、標題イベントが同じである画像を登録したサービス利用者同士が同じコミュニティで情報を共有できるように当該サービス利用者をグループ化し、該グループのサービス利用者を同じコミュニティに登録するように構成した。標題イベントが同じであることに加えて、登録画像の類似度に基づいてサービス利用者をグループ化するようにしてもよい。類似度の判定は、イベントリストの撮影日時が共通する（両者の差が所定範囲内）か否か、イベントリストのスコアが共通する（両者の差が所定範囲内）か否か、イベントリストの撮影場所が共通する（両者の差が所定範囲内）か否か、イベントリストの撮影枚数が共通する（両者の差が所定範囲内）か否か、に基づいて行う。これにより、登録画像が類似するサービス利用者をグループ化することが可能である。

（変形例２）
また、画像に写っている人の数が所定数（たとえば３人）以上か否か、イベントリストの撮影枚数の中で人が含まれる撮影枚数の割合が所定値以上か否か、コミュニティの制限人数を超えたか否か、に基づいて同じコミュニティに登録するか否かを決定するようにしてもよい。

（変形例３）
さらに、変形例１および変形例２に記載した各判定事項を適宜組み合わせて、同じコミュニティに登録するか否かを決定するようにしてもよい。

以上の説明はあくまで一例であり、上記の実施形態の構成に何ら限定されるものではない。

１０…電子カメラ
１１…管理サーバー
１２…利用者の端末
１３…アクセスポイント

Claims (5)

1. 複数のサービス利用者から送信された画像に標題を付与する処理と、
   前記付与した標題を前記サービス利用者ごとに登録する処理と、
   同じ標題が登録されているサービス利用者を前記標題ごとにグループ化する処理とを含むことを特徴とする情報提供方法。
2. 請求項１に記載の情報提供方法において、
   前記グループ化する処理は、前記同じ標題が登録されているサービス利用者のうち、類似する画像を送信したサービス利用者をグループ化することを特徴とする情報提供方法。
3. 請求項２に記載の情報提供方法において、
   前記グループ化する処理では、画像の撮影日時、撮影位置、撮影枚数および前記付与された標題らしさを示す情報の少なくとも１つを用いて前記類似する画像を判定することを特徴とする情報提供方法。
4. 請求項１に記載の情報提供方法において、
   前記標題を付与する処理は、前記サービス利用者から送信された画像の特徴量を算出する特徴量算出処理と、前記算出された前記画像の特徴量に基づいて前記画像に標題を付与する標題付与処理とを含むことを特徴とする情報提供方法。
5. 請求項１に記載の情報提供方法において、
   前記グループ化したサービス利用者間で情報を共有させる処理をさらに含むことを特徴とする情報提供方法。

Images