(57)【要約】【課題】端末のユーザがあるデータを与えられたとき、当該ユーザがが接した過去のデータの中から、迅速かつ容易にそのデータに類似（または関連）したデータを見つけ出すことができるようにする。【解決手段】ユーザ端末に対してデータ（例えば記事データ）を配信すると、端末の表示画面５００上にそのデータが表示される。このユーザが過去に接した過去データを特定するための特定情報は別途保存しておく。配信されたデータに対してユーザ端末からの所定の指示（例えばＲｅｃａｌｌボタン指示）に応じて、当該ユーザが接した過去データのうち、当該所定の指示を受けたデータと類似するデータが探知される。この探知されたデータは当該ユーザ端末へ送信され、表示される。【選択図】図９
2014215625.tif 000002
【特許請求の範囲】
【請求項１】
ユーザ端末に対してデータを配信するデータ配信方法であって、
ユーザ端末に対してデータを配信するステップと、
前記ユーザ端末のユーザが過去に接した過去データを特定するための特定情報を保存するステップと、
配信されたデータに対する前記ユーザ端末からの所定の指示に応じて、当該ユーザが接した過去データのうち、当該所定の指示を受けたデータと類似するデータを探知するステップと、
前記探知されたデータを当該ユーザ端末へ送信するステップと
を備えたデータ配信方法。
【請求項２】
前記ユーザ端末に配信されるデータについて、各データの特徴を表すデータ特徴ベクトルを生成するステップをさらに備え、
前記探知するステップでは、
当該データのデータ特徴ベクトルと前記過去データのデータ特徴ベクトルとを対比することにより、対比するデータ同士の類似度を求め、この求められた類似度に基づいて前記過去データの中から類似度の高い１または複数のデータを特定する
請求項１に記載のデータ配信方法。
【請求項３】
前記類似度を求めるステップでは、前記配信されたデータのデータ特徴ベクトルと前記過去データのデータ特徴ベクトルとを対比し、両特徴ベクトルにおける相関係数を類似度として求める請求項２に記載のデータ配信方法。
【請求項４】
前記データ特徴ベクトルを、その特徴を拡張した連想ベクトルに変換するステップをさらに備え、前記探知するステップでは、前記連想ベクトルを前記過去データのデータ特徴ベクトルと対比する請求項２に記載のデータ配信方法。
【請求項５】
前記探知するステップは、前記所定の指示に応じてリアルタイムで実行される請求項１〜４のいずれかに記載のデータ配信方法。
【請求項６】
前記探知するステップは、前記データを配信する際に配信対象の各データについて前もって実行しておく請求項１〜４のいずれかに記載のデータ配信方法。
【請求項７】
前記配信するステップにおいて、前記前もって実行した探知するステップにより得られた過去データを、端末において初期的に非表示となり、前記所定の指示により表示されるように配信データに埋め込んだ形態で、配信データを配信する請求項１〜６のいずれかに記載のデータ配信方法。
【請求項８】
前記「ユーザが過去に接した記事」は、ユーザが過去に読んだ記事の他、ユーザが関心を示す意思表示を表すユーザ操作を行った記事、過去に配信を受けた記事、の少なくとも１つである請求項１に記載のデータ配信方法。
【請求項９】
ユーザが外部ストレージサービスを利用して保存したデータを前記ユーザが過去に接したデータとして管理するステップをさらに備えた請求項１に記載のデータ配信方法。
【請求項１０】
前記探知されたデータが前記ユーザ端末へ送信された後に、当該ユーザ端末から当該所定の指示を受けたデータと同じデータについて再度の所定の指示を受けたとき、当該ユーザが接した過去データのうち、探知のためのアルゴリズムを変更して、再度、当該所定の指示を受けたデータと類似するデータを探知するステップと、
前記探知されたデータを再度当該ユーザ端末へ送信するステップと
をさらに備えた請求項１に記載のデータ配信方法。
【請求項１１】
ユーザ端末に対してデータを配信するデータ配信装置であって、
ユーザ端末に対して配信するデータを生成する配信データ生成手段と、
前記ユーザ端末のユーザが過去に接した過去データを特定するための特定情報を保存する過去データ保存手段と、
配信されたデータに対する前記ユーザ端末からの所定の指示に応じて、当該ユーザが接した過去データのうち、当該所定の指示を受けたデータと類似するデータを探知するデータ探知手段と、
前記探知されたデータを当該ユーザ端末へ送信する送信手段と
を備えることを特徴とするデータ配信装置。
【請求項１２】
ユーザ端末に対してデータを配信するデータ配信方法をコンピュータに実行させるコンピュータプログラムであって、
ユーザ端末に対してデータを配信するステップと、
前記ユーザ端末のユーザが過去に接した過去データを特定するための特定情報を保存するステップと、
配信されたデータに対する前記ユーザ端末からの所定の指示に応じて、当該ユーザが接した過去データのうち、当該所定の指示を受けたデータと類似するデータを探知するステップと、
前記探知されたデータを当該ユーザ端末へ送信するステップと
をコンピュータに実行させるコンピュータプログラム。
【請求項１３】
請求項１２に記載のコンピュータプログラムをコンピュータ読み取り可能に記録した記録媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ユーザ端末に対してデータを配信するデータ配信方法、データ配信装置、コンピュータプログラムおよび記録媒体に関する。
【背景技術】
【０００２】
現在、情報を入手する媒体として、広くインターネットが利用されている。利用の態様としては、ユーザが端末から、種々のホームページ、ブログ、ソーシャルネットワーキングサービス（ＳＮＳ）やニュースサイトなどに自発的にアクセスする他、登録ユーザに対して定期的にニュース等の記事が配信される情報配信サービスを利用することもできる。
【０００３】
特許文献１には、広告の提供方法として、次のような方法が提案されている。すなわち、ユーザから指定された文書を、該文書の特徴を示す複数の属性値によるベクトルで記述し、指定された文書群のベクトルを合成したベクトルを、該ユーザの嗜好を表すベクトルとして計算し、提示候補である広告を、該広告の特徴を示す複数の属性値によるベクトルで記述し、ユーザの嗜好を示すベクトルと広告の特徴を示すベクトルの類似度を計算し、類似度が高い広告を優先的に提示する。
【０００４】
特許文献２には、状況に応じて、タイミングを逸せずに関連情報を提示する情報処理装置および方法が提案されている。この従来技術では、メールの送受信によるイベントの発生に対応する文書の特徴ベクトルと、各話題（文書群）の特徴ベクトルとの内積から、両者の類似度を算出している。また、話題の特徴ベクトルとして、全話題の単語（特徴語）数の総計がｎ個の場合、全ての話題の特徴ベクトルをｎ次元空間のベクトルで表すことを示している。すなわち、複数の単語の重みからなるｎ次元ベクトルの利用を開示している。
【０００５】
特許文献３には、文書の特徴を表す文書ベクトルから文書間の類似度を算出する際、文書同士の比較にユーザの嗜好を反映させる文書処理装置が提案されている。
【０００６】
特許文献４には、ユーザが検索を望むコンテンツのジャンル、キーワードなどのアクセス情報と、ユーザのＩＤとユーザのコンテンツに対する嗜好を数値化したユーザ情報とをそれぞれ重みづけしたベクトルの和と、個々のコンテンツの属性を数値化したコンテンツ情報のベクトルの内積を求め、その演算結果に基づいてコンテンツを順序づけするコンテンツ検索装置が提案されている。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開２００４−１１８７１６号公報
【特許文献２】特開２００３−１７８０７５号公報
【特許文献３】特開２０００−１９４７２３号公報
【特許文献４】特開２００９−２４５３８２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００８】
ところで、インターネットから得られる情報は多種多様であり、特に、情報配信サービスを利用するユーザは、定期的に配信されてくる大量の情報に接することとなる。このような状況で、ユーザがある記事に接したとき、その記事の内容に類似した（または関連した）記事を過去に読んだ記憶があるが、その内容が俄に思い出せない、検索するにしても目的の記事を見つけ出すまでに手間と時間が掛かる、あるいは、検索も上手くいかない、という場合がある。
【０００９】
このような背景において、本発明は、端末のユーザがあるデータを与えられたとき、当該ユーザが接した過去のデータの中から、迅速かつ容易にそのデータに類似（または関連）したデータを見つけ出すことができるデータ配信方法、データ配信装置、コンピュータプログラムおよび記録媒体を提供しようとするものである。
【課題を解決するための手段】
【００１０】
本発明によるデータ配信方法は、ユーザ端末に対してデータを配信するデータ配信方法であって、ユーザ端末に対してデータを配信するステップと、前記ユーザ端末のユーザが過去に接した過去データを特定するための特定情報を保存するステップと、配信されたデータに対する前記ユーザ端末からの所定の指示に応じて、当該ユーザが接した過去データのうち、当該所定の指示を受けたデータと類似するデータを探知するステップと、前記探知されたデータを当該ユーザ端末へ送信するステップとを備えたことを特徴とする。
【００１１】
このデータ配信方法では、ユーザが過去に接した過去データを特定するための特定情報を保存しておき、ユーザが接したデータをきっかけ（契機）として、当該ユーザの過去データの中から、類似するデータを探知する。これにより、配信されたデータをきっかけとしてユーザが過去データの中から想起するであろうデータを自動的に推定して抽出することが可能となる。
【００１２】
そのために例えば、前記ユーザ端末に配信されるデータについて、各データの特徴を表すデータ特徴ベクトルを生成するステップをさらに備え、前記探知するステップでは、当該データのデータ特徴ベクトルと前記過去データのデータ特徴ベクトルとを対比することにより、対比するデータ同士の類似度を求め、この求められた類似度に基づいて前記過去データの中から類似度の高い１または複数のデータを特定する。
【００１３】
前記類似度を求めるステップでは、前記配信されたデータのデータ特徴ベクトルと前記過去データのデータ特徴ベクトルとを対比し、両特徴ベクトルの相関係数を類似度として求めることができる。相関係数の他に、両特徴ベクトルの内積やユークリッド距離を使うこともありえる。また、データ特徴ベクトルの情報量（情報エントロピー）を掛けて、補正することもありえる。
【００１４】
前記データ特徴ベクトルを、その特徴を拡張した連想ベクトルに変換するステップをさらに備え、前記探知するステップでは、前記連想ベクトルを前記過去データのデータ特徴ベクトルと対比するようにしてもよい。これにより、想起のきっかけとなるデータの特徴を補足して、想起の漏れを低減することができる。
【００１５】
前記探知するステップは、前記所定の指示に応じてリアルタイムで実行してもよいし、前記データを配信する際に配信対象の各データについて前もって実行しておくようにしてもよい。
【００１６】
前記配信するステップにおいて、前記前もって実行した探知するステップにより得られた過去データについては、初期的に非表示の状態で当該配信されるデータに埋め込んで配信することができる。
【００１７】
前記「ユーザが過去に接した記事」は、ユーザが過去に読んだ記事の他、ユーザが関心を示す意思表示を表すユーザ操作を行った記事、過去に配信を受けた記事、の少なくとも１つである。
【００１８】
ユーザが外部ストレージサービスを利用して保存したデータを前記ユーザが過去に接したデータとして管理するステップをさらに備えてもよい。これにより、データ配信サービスの対象となるデータの範囲を拡張することができる。
【００１９】
本発明によるデータ配信装置は、ユーザ端末に対してデータを配信するデータ配信装置であって、ユーザ端末に対して配信するデータを生成する配信データ生成手段と、前記ユーザ端末のユーザが過去に接した過去データを特定するための特定情報を保存する過去データ保存手段と、配信されたデータに対する前記ユーザ端末からの所定の指示に応じて、当該ユーザが接した過去データのうち、当該所定の指示を受けたデータと類似するデータを探知するデータ探知手段と、前記探知されたデータを当該ユーザ端末へ送信する送信手段とを備えることを特徴とする。
【００２０】
本発明によるコンピュータプログラムは、ユーザ端末に対してデータを配信するデータ配信方法をコンピュータに実行させるコンピュータプログラムであって、ユーザ端末に対してデータを配信するステップと、前記ユーザ端末のユーザが過去に接した過去データを特定するための特定情報を保存するステップと、配信されたデータに対する前記ユーザ端末からの所定の指示に応じて、当該ユーザが接した過去データのうち、当該所定の指示を受けたデータと類似するデータを探知するステップと、前記探知されたデータを当該ユーザ端末へ送信するステップとをコンピュータに実行させるコンピュータプログラムである。
【００２１】
本発明による記録媒体は、上記コンピュータプログラムをコンピュータ読み取り可能に記録した記録媒体である。
【発明の効果】
【００２２】
本発明によれば、端末のユーザがあるデータを与えられたとき、当該ユーザが接した過去のデータの中から、当該ユーザに負担をかけることなく、迅速かつ容易にそのデータに類似（または関連）したデータを見つけ出すことができる。
【図面の簡単な説明】
【００２３】
【図１】本発明の実施の形態におけるインターネットを利用したサービスが提供されるデータ配信システムの全体の概略構成を示す図である。
【図２】図１内に示した端末の各種機能を表したブロック図である。
【図３】図１内に示したサービスサーバの各種機能を表したブロック図である。
【図４】本発明の実施の形態におけるデータ配信システムの全体の機能を説明するためのブロック図である。
【図５】本発明の実施の形態においてサービスサーバの記憶部に構築されるユーザ別データベース（ＤＢ）の概念的な構造を示す図である。
【図６】本発明の実施の形態においてユーザに配信される記事データの構造例を示す図である。
【図７】本発明の実施の形態の基本的な機能を示す概念図である。
【図８】図７に示した基本的な動作（第１の動作）に対して、その変形例（第２〜第４の動作）を併せて示した図である。
【図９】本発明の実施の形態のユーザ端末における、あるユーザに対して配信された記事データの表示例を示す図である。
【図１０】本発明の実施の形態においてユーザに配信された記事に対する要求に応じて、受信、表示された元記事の表示例を示す図である。
【図１１】本発明の実施の形態において、Ｒｅｃａｌｌボタンが指示されたとき、表示されるリコール記事の表示例を示す図である。
【図１２】本発明の実施の形態におけるリコール範囲設定のための画面例を示す図である。
【図１３】本発明の実施の形態におけるサービスサーバと、複数のユーザ端末の間の連携処理の一例を表したフローチャートである。
【図１４】図１３に示した処理の変形例を示すフローチャートである。
【図１５】本発明の実施の形態における複数のリコール方式の自動最適化の第１の手法を示すフローチャートである。
【図１６】本発明の実施の形態における複数のリコール方式の自動最適化の第２の手法を示すフローチャートである。
【図１７】本発明の実施の形態における、リコール記事要求およびリコール記事データ配信の処理の変形例を説明するための図である。
【発明を実施するための形態】
【００２４】
以下、本発明の実施の形態について図面を参照しながら詳細に説明する。
【００２５】
図１に、本実施の形態における通信ネットワークを利用したサービスが提供されるデータ配信システムの全体の概略構成を示す。
【００２６】
現在、通信ネットワークとしてのインターネット２００に対して、ユーザがアクセスするための各種ツールが存在する。図では、ＰＣ１００ａ、いわゆるスマートフォンやタブレットと呼ばれる携帯端末１００ｂ、携帯電話端末１００ｃ、およびテレビ受信機１００ｄを示している。テレビ受信機１００ｄは家電機器の代表として示したものであり、これ以外にも種々の家電機器が当該アクセスツールとなりうる。本明細書では、このような任意のアクセスツールを端末（またはユーザ端末）と総称する。
【００２７】
サービスを提供する側の装置として、インターネット２００には、本実施の形態に係るサービスを提供するサービスサーバ３００、および複数のＷＥＢサーバ４００が接続されている。サービスサーバ３００が本発明のデータ配信装置を構成している。ＷＥＢサーバ４００には、情報発信サイト、ホームページ、ブログ、ツイッター（登録商標）、フェースブック（登録商標）、ｍｉｘｉ（ミクシィ）（登録商標）などのソーシャルネットワーキングサービス（ＳＮＳ）を提供するサイトを含む。
【００２８】
本実施の形態に係るサービスサーバ３００におけるサービスとして、インターネットを介して、ユーザ端末に対して定期的にデータ（典型的には記事）を配信するデータ配信サービスを例として挙げる。例えば、サービスサーバ３００は、インターネット上の各種サイトを自発的に定期的にクローリングして、文書、写真、動画など（テキストデータを利用できるもの）のデータを取得し、各ユーザ（登録ユーザ）の嗜好に合うデータを抽出して優先順位を付与し、優先順位の高いデータを選択して（または、優先順位の高い順に）データを当該ユーザの端末へ送信し、提示する。そのために、サービスサーバ３００は、ＷＥＢサーバの機能や電子メールの送受信を行う機能を有する。本明細書において「ユーザの嗜好」とはユーザの好みや関心等を表す。インターネット上の情報としては、ニュース、投稿、広告、書籍情報、企業情報、音楽情報、等あらゆる情報が含まれうる。
【００２９】
なお、本願出願人は、特願２０１２−１０８７３１号としてそのような情報配信サービスのための情報処理方法を提案している。但し、本発明はこの先願の情報処理方法を必須の前提とするものではない。
【００３０】
本実施の形態における本質的な機能は、ユーザがある記事（データ）に接したとき、自身が過去に接したデータの内、類似する（または関連する）記事を自動的に抽出して、ユーザに提示する機能である。このような機能をリコール機能という。リコール機能は、ある記事に接したユーザが過去にも同様の記事を読んだ記憶があるが、その記事はどこのサイトの誰のどのような記事であったか俄に思い出せないというような場合に、ユーザに代わって該当する記事を探知してユーザに提示するものである。
【００３１】
なお、本明細書におけるユーザに配信される記事を構成する「データ」は、基本的には文字列からなる文書のテキストデータであるが、写真などの静止画、動画、音楽など他のメディアのデータに付随したテキストデータであってもよい。
【００３２】
図２に、端末１００の各種機能を表したブロック図を示す。
【００３３】
端末１００は、ＣＰＵ１０１、記憶部１０２、入力部１０４、表示部１０５、通信部１０６を備える。端末の種類によって異なるが、例えば、通話や音楽プレーヤ機能のための音声処理部１１１、マイク１１１ａおよびスピーカ１１１ｂを備えてもよい。また、テレビ受信機１００ｄのような端末では放送受信部１１２を備える。その他、図示しないが、個々の端末に固有の処理部を備えることができる。
【００３４】
ＣＰＵ１０１は所定の各部と接続され、記憶部１０２に格納された各種プログラムを実行することにより端末１００の各部を制御する制御部を構成し、各種の機能（手段）を実現する。記憶部１０２には、コンピュータプログラムの他、フォント等の固定的なデータ、各種設定データ等を不揮発的に格納している領域、ＣＰＵ１０１により利用される作業領域、データの一時記憶領域として利用される領域を含む。さらに、記憶部１０２は、インターネット２００を経由して取得された各種の文書やデータを不揮発的に記憶する領域を含む。
【００３５】
入力部１０４は、ユーザが端末１００に対して、各種の指示やデータを入力するためのユーザインタフェースである。通常、電源キー、通話キー、テンキー、カーソル操作キー等の各種キーを含みうる。これらのキーはハードウェアキーであってもよいし、ソフトウェア的に提供されるものでもよい。表示部１０５は、端末１００がユーザに対して表示情報を提供するためのユーザインタフェースであり、液晶ディスプレイ、有機ＥＬディスプレイ等の表示デバイスを含む。入力部１０４としては、表示部１０５の表示画面に重なったタッチ入力領域を有するタッチパネルを備えてもよい。さらには、入力部１０４は、マウスのようなポインティングデバイスによる入力機能、加速度センサ等の端末の姿勢や動作を検出するセンサ機能、ユーザの表情や顔のパーツの変化等を検知するイメージセンサ機能、音声指示を受け付ける機能等を備えてもよい。入力部１０４の入力は、これらの任意の機能によるユーザ操作入力を含みうる。
【００３６】
通信部１０６は、インターネット２００に接続するための手段であり、アンテナを介して第３世代（３Ｇ），第４世代（４Ｇ）等の携帯電話無線システムにおける基地局との間での無線通信を行い、基地局を介して通信相手との間で通話やデータ通信を行うための処理部である。その他、通信部１０６としては、無線ＬＡＮ、ＢＬＵＥＴＯＯＴＨ（登録商標）等、既存の任意の通信手段を利用することができる。
【００３７】
図３に、サービスサーバ３００の各種機能を表したブロック図を示す。
【００３８】
サービスサーバ３００は、その主要な機能部として、通信部３１０、表示部３２０、入力部３３０、データ処理部３４０および記憶部３５０を備える。
【００３９】
通信部３１０は、例えばルータなどの、インターネット２００に接続されてデータ通信を行うデバイスを含む。表示部３２０は、サービスサーバ３００の保守員等に対して表示情報を提供するためのユーザインタフェースであり、任意の表示デバイスを含む。
【００４０】
入力部３３０は、保守員等がサービスサーバ３００に対して、各種の指示やデータを入力するためのユーザインタフェースであり、例えばキーボードである。
【００４１】
データ処理部３４０は、ＣＰＵ等を含み、サービスサーバ３００の各種の制御や必要なデータ処理を行う部位である。本実施の形態では、データ処理部３４０は、記事取得管理部３４１、記事配信処理部３４３、およびユーザ管理部３４５を含む。
【００４２】
記憶部３５０は、全体記事データ記憶部３５１、ユーザ別記事データ記憶部３５３、およびユーザ管理データ記憶部３５５を含む。
【００４３】
データ処理部３４０内の記事取得管理部３４１は、インターネット２００を介して、ＷＥＢサーバ４００等のサイトから種々の記事（データ）を取得し、全体記事データ記憶部３５１に保存して管理する部位である。記事取得管理部３４１は、また、全体記事データ記憶部３５１内に保存された各記事についてそのデータからデータ特徴ベクトルを生成し、ユーザ毎にユーザの嗜好に合った記事を選択し、ユーザ別記事データ記憶部３５３に保存する。
【００４４】
ユーザ管理部３４５は、個々のユーザ毎に、ユーザ管理データとしてユーザの個人情報やユーザ特徴ベクトルを、ユーザ管理データ記憶部３５５に保存する。個人情報には、登録ユーザに対するサービスを行う場合のユーザの認証情報（ユーザＩＤやパスワード等）、氏名、住所、ニックネーム、学歴（出身校）、嗜好情報、等を含みうる。データ特徴ベクトルおよびユーザ特徴ベクトルの詳細については後述する。端末１００からデータ（例えば個人情報としてのユーザプロファイルデータなど）を取得する場合もありうる。この取得されたデータは、後述するユーザ特徴ベクトルとともに、ユーザ管理データ記憶部３５５に保存される。
【００４５】
記事配信処理部３４３は、ユーザに対して記事を提供するサービスに係る処理を実行する部位である。このサービスは、上述したように、個々のユーザの嗜好をインターネットのサービス上に投影して、当該ユーザに必要な（必要そうな）情報（記事）を、効率的に判別して、ユーザに提示するものである。具体的には、
−各ユーザヘの商品および人材などのマッチングおよびレコメンド
−ユーザに最適化した事物の予測
−ユーザに最適化したデータのフィルタリング（絞り込み）
−ユーザに最適化したデータの検索
などを含みうる。
【００４６】
ここで、本明細書におけるデータ特徴ベクトルについて説明する。
【００４７】
データ特徴ベクトルとは、記事（文書）の中に現れる語に対してその重み(ある実数)を対応させる辞書であり、これによって、ある記事(文書)の特徴を表現するものである。特徴ベクトルは、語の関数としても記述できる他、現れる語の順序を固定して座標とすればベクトルの形にも記述できる。
【００４８】
例１： データ特徴ベクトルを、ある文書の中に含まれる各語とその頻度分布としての重みで表す場合。
c = {猫: 0.12, 月: 0.03, 本: 0.34, ….}
この表記は、当該文書中に「猫」という語が 12% 現れる、「月」という誤が３％現れる、「本」という用語が34％現れる、…ことを意味している。c(猫) = 0.12等 のように関数の形にも書けるし、c = (0.12, 0.03, 0.34, …) のようにベクトルの形式にも書ける。
【００４９】
例２: データ特徴ベクトルを、ある文書の中に含まれる語の集合で表す場合。
c = { 猫, 月, 本, ….}
これは重みが全て 1 の辞書、と認識してもよいし、この集合に含まれる語に対して、例えば c(猫) = 1、それ以外の語について 0 を与える関数と認識することもできる。
【００５０】
例３: 例１ での重みとして、その文書の中の頻度だけではなく、ある文書群を基準にして、各語の文書頻度(どれくらいの文書に現れるか)を加味する場合もある。情報検索の分野などで利用されるTF-IDF(Term Frequency-Inverse Document Frequency)は、その１つの例である。
【００５１】
個々のユーザの嗜好をインターネットのサービス上に投影するためには、例えば、ユーザ特徴ベクトル（嗜好ベクトル）を用いる。本明細書において、ユーザ特徴ベクトルとは、そのユーザの嗜好を反映したユーザ固有の情報をベクトルとして表現したものである。例えば、ｎ次元のユーザ特徴ベクトルtvecは、tvec＝［ａ１，ａ２，…，ａｎ］と表すことができる。ここに、ａ１，ａ２，…，ａｎはベクトルtvecのｎ個の要素である。ユーザｊ毎のユーザ特徴ベクトルtvecｊは次式のように表すことができる。
tvecｊ＝［ａｊ１，ａｊ２，…，ａｊｎ］
【００５２】
そこで、各記事のデータ特徴ベクトルをユーザ特徴ベクトルと対比して、両特徴ベクトルの類似度を算出することができる。例えば、ユーザｊに対する記事のデータＤｉの優先順位（全順序）を決定するために、次式のとおり、ユーザ特徴ベクトルtvecｊと比較対象記事のデータＤｉのデータ特徴ベクトルcvecｉとの内積を算出する。
（tvecｊ・cvecｉ）＝Σaｊｍ×vｉｍ
（ｍ＝１，２，…，ｎ）
ここに、aｊｍはユーザｊのユーザ特徴ベクトルtvecｊのｍ番目の要素の値であり、vｉｍは比較対象記事のデータＤｉのデータ特徴ベクトルのｍ番目の要素の値である。この際、内積値に、データ特徴ベクトル cvec i の情報量（情報エントロピー）を掛けて、補正することも考えられる。これにより、データの情報量が類似度に与える影響を軽減することができる。
【００５３】
この内積の大きさの順番にデータＤｉに優先順位（大きいものに高く）を付与する。データ特徴ベクトルとユーザ特徴ベクトルの内積をとる際には、両ベクトルの次元数を一致させる必要がある。その際には、後述するような仮想的な最大次元数ｎを用いる代わりに、実際上は、両ベクトルの異なる単語の総数に相当する次元数ｎを想定すれば足りる。
【００５４】
ついで、算出された類似度に従って複数の記事に優先順位を付与する。さらに、付与された優先順位に応じた記事の提示のための記事データの生成を行う。すなわち、優先順位の高い記事を優先的に当該ユーザに対して提示する。具体的には、優先順位の最も高い記事のみを提示する、優先順位の高い所定数の記事を選択してユーザに提示する、優先順位の高い順にすべての記事をユーザに提示する等、アプリケーションや状況に応じて、種々の提示の形態が考えられる。提示の際に、ユーザの要求に応じて優先順位に従って、複数の記事を段階的に提示する形態もありうる。
【００５５】
なお、特に本発明を限定するものではないが、ユーザ特徴ベクトルを生成する具体的な方法の一例として、本出願人の先願に提示したような技術を利用することができる。すなわち、ユーザに対して提示された複数の記事のうち、当該ユーザの操作に応じて、当該ユーザが関心を示した高関心文書と、ユーザが関心を示さなかった低関心文書とを特定し、高関心文書に含まれる単語群と前記低関心文書に含まれる単語群とを対比して、両文書に共通に含まれる単語の重み値を"０"とし、高関心文書のみに含まれる単語の重み値を非０値に設定した、単語群に対応する重み値の列をユーザ特徴ベクトルとして生成する。類似度は、例えば、優先順位の付与対象となる複数の記事のデータ特徴ベクトルとユーザ特徴ベクトルとを対比し、両特徴ベクトルにおける対応する単語同士の重み値の積の和を類似度として求めることができる。
【００５６】
但し、このような記事配信データ生成の具体的な処理について、本発明は特に限定するものではない。本発明の前提として、何らかの方法で個々のユーザへ記事データが配信されれば足りる。
【００５７】
ＷＥＢサーバ４００の構成および機能は本願発明に直接関係ないので説明は省略する。ＷＥＢサーバ４００は、ｈｔｔｐ（hyper text transfer protocol）に則って、インターネット経由でコンテンツの要求等の端末（クライアント）からのリクエストを受け、これに応じて、要求されたコンテンツをインターネット経由で当該端末に応答する。
【００５８】
図４は、本実施の形態におけるデータ配信システムの全体の機能を説明するためのブロック図である。
【００５９】
サービスサーバ３００のユーザ管理部３４５は、本サービスの利用に先立って、ユーザ端末１００から受信したユーザを特定する情報やユーザの個人情報をユーザ管理データ記憶部３５５に保存し管理する。
【００６０】
サービスサーバ３００の記事取得管理部３４１は、定期的に（例えば１日１回ないし複数回、または１時間毎等の周期的に）、外部の情報発信サイト、ＳＮＳサイト、ブログサイト等の特定のＷＥＢサーバ４００にアクセスし、種々の記事（データ）を収集し、全体記事データ記憶部３５１に保存する。その後、ユーザ管理データ記憶部３５５に保存されている各ユーザの嗜好を表すデータに応じて、各ユーザへ配信する所定個数の記事を含む記事データを作成し、ユーザ別記事データ記憶部３５３に保存する。このユーザ別記事データ記憶部３５３には、作成されたユーザ別記事データが逐次、蓄積されていく。また、記事毎にユーザが読んだか否かのマーク（またはフラグ）が付与される。ユーザ別記事データ記憶部３５３は、本発明における「ユーザが過去に接した過去データを特定するための特定情報」を保存する手段を構成する。
【００６１】
記事配信処理部３４３は、定期的に（例えば１日１回ないし数回）、ユーザ別記事データ記憶部３５３から、各ユーザへ配信すべき記事データを読み出し、所定の通信インタフェースを介してユーザ端末１００へ配信する。所定の通信インタフェースは例えばＷＥＢサービスや電子メールである。本実施の形態では、記事データは所定個（例えば３０個）の記事を含んでいる。この「所定個」として各ユーザが所望の個数を指定できるようにしてもよい。
【００６２】
ユーザ端末１００の記事受信・表示部１２１は、サービスサーバ３００から記事データを受信すると、表示部１０５（図１）の表示画面に表示する。WEBサービスや電子メールで配信される記事データは、例えばＨＴＭＬ（Hyper Text Markup Language）のようなマークアップ言語文書で記述される。記事受信・表示部１２１はメーラープログラムやブラウザプログラムを含む。表示された記事データに、いわゆるリンクが設定されている場合には、そのリンクがユーザにより指示（選択）されたとき、記事受信・表示部１２１はリンク先のＵＲＬにアクセスし、アクセス先のコンテンツをさらに受信し、表示することができる。
【００６３】
リコール指示検出部１２３は、表示された記事データを見たユーザが、リコール指示を入力したとき、そのリコール指示を検出し、サービスサーバ３００へリコール記事要求を送信する。リコール指示検出部１２３の機能は、既存のブラウザプログラムにより実現することができる。このようなリコール指示がなされるきっかけとなった記事を本明細書では「きっかけ記事」と呼ぶ。「リコール記事要求」にはきっかけ記事を特定するためのきっかけ記事ＩＤ（例えば後述するArticleDATA）およびユーザＩＤが含まれる。なお、リコール記事要求の他に、ユーザの操作に応じた所定の情報が適時ユーザ端末１００からサービスサーバ３００へ送信される。
【００６４】
記事配信処理部３４３は、配信された記事に対する当該ユーザ端末からの所定の指示（すなわちリコール指示）に基づくリコール記事要求を受けると、当該所定の指示を受けた記事と類似する記事をユーザ別記事データ記憶部３５３内の当該ユーザが接した過去記事（過去データ）から探知する。より具体的には、当該記事のデータ特徴ベクトルと当該ユーザの個々の過去記事のデータ特徴ベクトルとを対比することにより、対比する記事同士の類似度を求め、この求められた類似度に基づいて過去記事の中から類似度の高い１または複数の記事を特定する。さらに記事配信処理部３４３は、このような探知により得られた記事をリコール記事データとして当該ユーザ端末へ返送する。
【００６５】
ユーザ端末１００は、このリコール記事データを受信したとき、リコール記事受信・表示部１２５によりリコール記事データを表示画面上に表示する。リコール記事受信・表示部１２５の機能は、既存のブラウザプログラムにより実現さすることができる。
【００６６】
図５に、本実施の形態においてサービスサーバ３００の記憶部３５０に構築されるデータベース（ＤＢ）の概念的な構造を示す。このＤＢは、図の左側に示したユーザ別データベースと、図の右側に示した全体記事データベースとを含む。ユーザ別データベースは、各ユーザの個人情報３５５と、ユーザ別記事データ記憶部３５３に保存された各ユーザごとの配信記事（すなわち配信データ）または配信記事を特定するための情報を含む。ユーザ別記事データ記憶部３５３は、過去に配信された記事データの情報も蓄積している。
【００６７】
この例では、ユーザの個人情報は、個々のユーザを識別するためのユーザ識別情報（ＵｓｅｒＩＤ）、メールアドレス（mail address）、ユーザ特徴ベクトル（Taste Vector: tvec）を含んでいる。
【００６８】
ユーザ別記事データ記憶部３５３に保存された各記事は、作成日（Created Date）、配信日（Delivered Date）、記事ＩＤ（Article DATA）DATA1，DATA2，・・・，DATAｎ、および各記事ＩＤ毎に設けられた既読マーク（Selected Mark）の各データ項目を含んでいる。既読マーク（Selected Mark）は、ユーザがその記事を読んだか否かを表すデータである。ここでは、既読マークは初期的に「否」または「０」のような未読を示すデータが設定され、記事の配信後にその記事に対するユーザの当該操作があったときに、「有」または「１」のような既読を示すデータに変更される。他のデータ項目は記事データの作成時に設定される。
【００６９】
また、全体記事データベースは、複数の記事データを含む。各記事データは、その記事の記事ＩＤ（Article DATA）、題名（Title)、テキスト（Text)、記事ＵＲＬ（Article URL）、フィードＵＲＬ(Feed URL)、サムネイルＵＲＬ（Thumbnail URL）、特徴ベクトル（Characteristic Vector: cvec）、付随情報（Info）、等を含んでいる。
【００７０】
各記事データのテキスト（Text）は記事の文書の一部または全文または要約などを表す文字列からなる。記事ＵＲＬ（Article URL）は、その記事の配信元のアドレスを表している。フィードＵＲＬ(Feed URL)は、当該記事を提供している情報発信サイト（新聞社など）におけるニュース配信のためのＵＲＬである。サムネイルＵＲＬ（Thumbnail URL）は、その記事に関連した画像のアドレスを表している。サムネイルＵＲＬは記事によっては存在しない場合もありうる。特徴ベクトル（Characteristic Vector: cvec）は、その記事のデータ特徴ベクトルである。付随情報（Info）は、この記事に関する任意の情報であり、例えば、その記事が外部ストレージから取り込んだ記事であることを示す情報である。
【００７１】
ユーザが記事を読んだか否は、例えば、典型的にはユーザが配信記事に対してその全文を表示させる操作を行った場合にその記事をユーザが読んだと判定することができる。ユーザが読んだ記事は、ユーザが「接した」記事に含まれる。但し、ユーザが接した記事はユーザが読んだ記事に限られるものではなく、後述する各種ボタン操作をした記事なども「接した記事」に含めることができる。
【００７２】
図６は、ユーザに配信される記事データの構造例を示している。
【００７３】
配信記事データは、配信日と、所定個の記事の記事データを含む。各記事データは、題名、テキスト、ＵＲＬ、サムネイルＵＲＬ、および各種のボタンを含んでいる。ここでいうボタンとは、例えば表示画面上に表示される操作ボタンに対応するイメージおよび機能に対応するデータ要素であり、本例ではＬｉｋｅ！ボタン、Ｓｈａｒｅボタン、Ｃｏｍｍｅｎｔボタンの例（後述する図９参照）を示している。これらの各要素（項目）には、必要に応じてリンクが設定される。リンクは、その要素がユーザにより指示（選択）されたとき、そのリンク先へ移行したり、そのリンクに対応づけられた特定の機能（処理）が起動されたりする。具体的な実施の例としては、このような構造がＨＴＭＬデータなどに変換されて配信されることになる。
【００７４】
以下、本実施の形態におけるサービスの概略構成を説明し、次に、具体的な処理例を説明する。
【００７５】
図７は、本実施の形態の基本的な機能を示す概念図である。ユーザＡが、自身に配信された記事に対して、端末からリコールの指示を行ったとき、ユーザＡが過去に接した記事が蓄積されているユーザＡの過去記事を蓄積してある記事ＤＢから、きっかけ記事に類似する（関連する）記事が自動的に探し出される。過去に接した記事は、例えば、既読マークが既読を示している記事である。そのために、きっかけ記事のデータ特徴ベクトルと、既読マークが付されたユーザＡの過去記事の記事データ（過去記事データ）のデータ特徴ベクトルとに基づいて、記事同士の間の類似度が計算され、過去記事の中から類似度の高いものから所定個数の記事が抽出され、ユーザＡ（の端末）に対して提示される。
【００７６】
記事同士の類似度を求める具体例として、ここでは、記事のデータ特徴ベクトルを、上記例１に示したような、 (w1, v1), (w2, v2), … (wn, vn) といった、単語（ｗ）とその重み（ｖ）をペアにした形式で表した場合を例として説明する。
【００７７】
より具体的には、記事同士の類似度としては、一例として次式のとおり、きっかけ記事のデータ特徴ベクトルcvec0と、過去記事のデータＤｉのデータ特徴ベクトルcvecｉとの相関係数cvec0・cveci/(|cvec0||cveci|)を算出する。
cvec0・cvecｉ/(|cvec0||cveci|)＝Σaｍ×ｖiｍ  /(|cvec0||cveci|)
（ｍ＝１，２，…，ｎ）
ここに、ａｍはきっかけ記事のデータ特徴ベクトルcvec0のｍ番目の要素の値であり、ｖｉｍはデータＤｉのデータ特徴ベクトルcvecｉのｍ番目の要素の値である。
【００７８】
この相関係数値の大きさの順番にデータＤｉに優先順位（大きいものに高く）を付与する。データ特徴ベクトル同士の内積をとる際には、両ベクトルの次元数を一致させる必要がある。その際には、後述するような仮想的な最大次元数ｎを用いる代わりに、実際上は、両ベクトルの異なる単語の総数に相当する次元数ｎを想定すれば足りる。
【００７９】
ついで、算出された類似度に従って複数の過去記事（データ）に優先順位を付与する。さらに、付与された優先順位に応じた記事の提示（または処理）を行う。すなわち、優先順位の高い記事を優先的に当該ユーザに対して提示する。具体的には、優先順位の最も高い記事のみを提示する、優先順位の高い所定数の記事を選択してユーザに提示する、優先順位の高い順にすべての記事をユーザに提示する等、アプリケーションや状況に応じて、種々の提示の形態が考えられる。提示の際に、ユーザの要求に応じて優先順位に従って、複数の記事を段階的に提示する形態もありうる。
【００８０】
図８は、図７に示した基本的な動作（第１の動作）に対して、その変形例（第２の動作）を併せて示した図である。第１の動作は上述したとおりである。
【００８１】
図８に示した第２の動作は、きっかけ記事のデータ特徴ベクトルを連想ベクトルに変換（拡張）した後、この連想ベクトルを上記と同様に、ユーザＡの記事ＤＢに作用させることにより、きっかけ記事の連想ベクトルが近いデータ特徴ベクトルを有する上位所定個の記事を抽出するものである。連想ベクトルの具体例については後述する。
【００８２】
図９に、ユーザ端末における、あるユーザに対して配信された記事データの表示例を示す。この例では、データ配信サービスの各登録ユーザに対して、定期的に（例えば毎日１回）、記事データが配信される場合を想定する。
【００８３】
ユーザに一度に配信される記事の個数は設定画面（図示せず）で可変設定できるようにしてもよい。
【００８４】
配信された記事データの表示画面５００は、配信日付５０１が最上部に表示され、その下に複数の記事エリア５１０が配置されている。
【００８５】
各記事エリア５１０には、タイトル５１１、テキスト５１２、各種ボタン５１３、およびサムネイル画像５１４が所定の位置関係で配置されている。例えば、タイトル５１１には、この記事の元記事（コンテンツ）を示すＵＲＬへのリンクが設定されている。テキスト５１２は元の記事の一部または概要である。ユーザによりタイトル５１１が指示されたとき、元記事が当該ＷＥＢサーバへ要求され、表示画面５００に代えて（または重ねて）、受信した元記事が図１０の表示画面６１０のように表示される。
【００８６】
ここでは、表示画面６１０に表示されるコンテンツは元記事のサイトから取得する場合を想定した。したがって、図１０の表示画面６１０には、図９に示したような各種ボタン５１３は表示されていない。もし、元画面においても同様の各種ボタン５１３が含まれていれば、表示画面６１０上にも表示される。
【００８７】
元記事へのリンクはタイトル５１１に設定される場合を想定したが、タイトル５１１に代えて（または加えて）テキスト５１２に設定してもよい。あるいは、「全文を表示」「続きを見る」等の文字列を追加表示して、この文字列にリンクを設定するようにしてもよい。
【００８８】
また、テキスト全文の情報が配信記事データ内に元々包含され、その一部が隠された状態で表示画面５００上に表示される態様もありうる。その場合には、元記事へのリンクは設定されることなく、タイトル５１１等への指示がなされたときに全文表示に切り替わるように配信記事データを構成することもできる。このような場合には、全文表示の画面にも各種ボタン５１３を用意しておくことができる。
【００８９】
各種ボタン５１３は図６に示した例に対応している。Ｌｉｋｅ！ボタンは、この記事を読んだユーザが賛意を表するためにユーザが指示するボタンである。Ｓｈａｒｅボタンは、この記事を読んだユーザが他のユーザと共有するために自己の属するＳＮＳで公開するためにユーザが指示するボタンである。Ｃｏｍｍｅｎｔボタンは、この記事を読んだユーザがコメントを記載するためにユーザが指示するボタンである。Ｒｅｃａｌｌボタンは、この記事を読んだユーザが本発明に係るリコール機能を起動するためにユーザが指示するボタンである。これらの各種ボタン５１３はユーザがその記事に対して関心を示す意思表示を表すユーザ操作といえる。このようなユーザ操作のためのボタンは図示したものに限らない。
【００９０】
表示画面５００上のいずれかの記事に対して、ユーザによりそのＲｅｃａｌｌボタンに対するリコール指示が行われたとき、当該ユーザが接した過去の記事からその記事に類似（または関連）する１個または複数の記事が抽出され、図１１の表示画面７００に示すようにリコール記事として表示される。ここで示した表示エリア７１０は、図９に示した記事エリア５１０に相当するものとして示しているが、異なるフォーマットであってもよい。例えば、リコール記事の表示は、そのタイトルだけ、タイトルと本文、タイトルと本文と画像、など様々なフォーマットが考えられる。また、リコール記事の表示位置は、表示画面５００上の当該記事エリアの下に出す、上に出す、右に出す、かぶせて出す、など様々考えられる。
【００９１】
図１２により、リコール範囲設定のための画面例を説明する。
【００９２】
以上の説明では、ユーザによりリコール指示が行われたとき、リコール記事を探知する対象となる過去データは、ユーザが過去に接した記事を想定した。これに対して、以下のような拡張が可能である。
【００９３】
「ユーザが過去に接した記事」は上述したように、典型的にはユーザが過去に読んだ記事であるが、各種ボタン操作をした記事を含んでもよい。さらには、単に推薦された記事を含んでもよい。「推薦された記事」とは、本実施の形態では上述したように表示画面５００に表示されたような、当該ユーザに配信された記事のすべてである。
【００９４】
一方、近年、ユーザが大量のデータを保存するために、外部ストレージサービスが利用されている。外部ストレージサービスでは、キーワード検索やフォルダ整理などの方法以外で、必要な情報を引き出すことが難しい。そこで、記事配信サービスで提示（推薦）された記事以外にも、外部ストレージサービスなどを利用して、自身で任意のＷＥＢサーバから取得した記事を「過去データ」に含める。そのために、外部ストレージの記事は、全体記事データ記憶部３５１に格納され、ユーザ別記事データ記憶部３５３の内容に基づいて参照される。複数利用している外部ストレージサービスについては個別に指定できるようにしてもよい。
【００９５】
さらに、上述した説明では、「過去データ（過去記事）」はリコール指示を行ったユーザの過去データ（過去記事）に限定した。これに対して、「過去データ」を、リコール指示を行ったユーザ以外の他のユーザの過去データにまで拡張することも可能である。「他のユーザ」としては、特定のユーザをメールアドレスやユーザＩＤなどで、指定できるようにしてもよい。また、自身と「同じプロファイルのユーザ」を指定したり、「嗜好が近いユーザ」を指定したり、自分以外の「全ユーザ」を指定したり、することが可能である。
【００９６】
このような各種のオプションは、図１２に示したリコール範囲設定画面でユーザが任意に設定（Ｓａｖｅ）しておくことができる。このリコール範囲設定データは、例えば、サービスサーバ３００のユーザ管理データ記憶部３５５等に保存しておくことができる。
【００９７】
なお、プライバシーの問題を回避するために、そのような他のユーザは、自身の過去データを他者に公開することを承諾したユーザに限定することが好ましい。「他者」は自分以外のすべてのユーザとしてもよいし、指定したユーザのみに公開、または、指定したユーザ以外のユーザに公開、等のオプションを設定できるようにしてもよい。
【００９８】
図１３に、本実施の形態におけるサービスサーバと、複数のユーザ端末の間の連携処理の一例を表したフローチャートを示す。ここではユーザＡの端末とユーザＢの端末の２台のユーザ端末について説明するが、実際にはさらに多数のユーザ端末が関与しうる。
【００９９】
サービスサーバ３００は、ユーザへの記事配信に先立って、記事取得管理部３４１により、通信部３１０を介して、定期的にインターネット上の所定のサイト（例えば上述したフィードＵＲＬで表されたサイト）をクロールして、記事を収集する。収集した記事は全体記事データ記憶部３５１に蓄積される。その後、所定の時点で、各ユーザのユーザ特徴ベクトルを用いて、各ユーザ毎に所定個数（例えば３０個）の記事を抽出し、ユーザ別記事データ記憶部３５３に蓄積する（Ｓ２１１）。サービスサーバは、記事配信処理部３４３により、定時にまたは随時またはユーザの要求に応じて、通信部３１０を介して、各ユーザ端末へそのユーザ用に作成された最新の記事データを逐次、配信する（Ｓ２１２）。ユーザ毎の記事の抽出は当該ユーザへの配信の際に行ってもよい。
【０１００】
ユーザＡの端末は、通信部１０６を介して、サービスサーバから自身宛の配信記事データを受領すると（Ｓ１１０，Ｙｅｓ）、図９の表示画面５００に示したように、表示部１０５がその記事データを表示する（Ｓ１１１）。この表示された記事に対して、入力部１０４からのユーザ操作が受け付けられる（Ｓ１１２）。特に個別に説明しないが、ユーザ操作の内容によって、ユーザＡの端末は対応した応答を行う。上記既読マーク等の更新のためにサービスサーバへ操作情報の通知も行う。上述した各種ボタンが指示された場合には、ユーザＡの端末は、相応の処理を実行する。特に、ユーザ操作が「リコール指示」であった場合、ユーザＡの端末は、そのきっかけ記事に対応するリコール記事をサービスサーバへ要求する（Ｓ１１３）。
【０１０１】
サービスサーバはこのリコール記事要求に応じて、ユーザ別記事データ記憶部３５３内の当該ユーザの過去データを参照し、きっかけ記事に対応するリコール記事を抽出して、リコール記事データとして、ユーザＡの端末へ返送する（Ｓ２１３）。
【０１０２】
リコール記事データを受信したユーザＡの端末は、そのリコール記事を表示画面上に表示する（Ｓ１１４）。このリコール記事の表示に対してもユーザ操作が受け付けられる。記事データ表示を終了する指示が行われたとき（Ｓ１１５，Ｙｅｓ）、最初のステップＳ１１０へ戻る。記事データ表示へ戻る指示が行われたとき（Ｓ１１６，Ｙｅｓ）、ステップＳ１１１へ戻る。そうでなければ、ステップＳ１１２へ戻る。
【０１０３】
ユーザＢの端末についてもユーザＡの端末と同様の処理が行われる（Ｓ１２０〜Ｓ１２６、Ｓ２１４）。
【０１０４】
図１４は、図１３に示した処理の変形例を示している。図１３に示した処理と同様のステップには同じ符号を付して、重複した説明は省略する。図１３の処理では、リコール記事の抽出処理をリコール記事要求に応じてリアルタイムで実行する場合を示した。これに対して、図１４の処理では、リコール指示に応じてリアルタイムにリコール記事を抽出するのではなく、配信記事データの作成時に前もって配信対象の各記事に対してリコール記事も併せて抽出しておく。
【０１０５】
すなわち、サービスサーバ３００は、ユーザへの記事配信に先立って、記事取得管理部３４１により、各ユーザのユーザ特徴ベクトルを用いて、ユーザ毎に所定個数（例えば３０個）の記事を抽出する際（Ｓ２２１）、ユーザ毎に各記事のリコール記事も併せて抽出する（Ｓ２２２）。抽出されたリコール記事（少なくともその記事を特定するための情報）は、ユーザ別記事データ記憶部３５３に、当該ユーザおよび当該記事に対応づけて記憶される。さらに、サービスサーバは、定時にまたは随時またはユーザの要求に応じて、各ユーザ端末へそのユーザ用に作成された記事データを逐次、配信する（Ｓ２２３）。各ユーザに配信される記事データには、当該ユーザ用に作成されたリコール記事が、端末において初期的に非表示となりユーザのリコール指示により表示されるような形態で埋め込んでおく。
【０１０６】
ユーザ端末の処理は、基本的には、図１３の場合と同じであるので、以下、図１４の処理に特徴的な処理のみ説明する。ユーザ端末における記事データ表示（Ｓ１１１，Ｓ１２１）の段階では、リコール記事は隠された状態で、表示はされない。ユーザ端末は、ユーザからリコール指示を受けたとき（Ｓ１１３，Ｓ１２３，Ｙｅｓ）、受信済の記事データとともに内部（記憶部１０２）に記憶されている当該リコール記事のデータを読み出し（Ｓ１１３ａ，Ｓ１２３ａ）、表示する（Ｓ１１４，Ｓ１２４）。
【０１０７】
この図１３の方式では、リコール記事抽出をリアルタイム処理で実行するため、この処理に時間が掛かるとユーザを待たせることになるが、図１４の方式ではこのような弊害がない。これに対して、図１４の方式では必ずしも将来的にリコール指示が行われるとは限らないすべての配信記事についてリコール記事を用意するので、サービスサーバ側の処理負荷が大きくなり、配信記事のデータ量も増加するが、図１３の方式ではこのような弊害がない。
【０１０８】
なお、リコール記事を前もって抽出する場合に、配信する記事データに埋め込んで配信することを想定したが、記事データに埋め込まずに、サービスサーバ側に保存しておくことも可能である。この場合、リコール指示があった際にユーザを待たせることがなく、また、記事配信時に余分なデータを送信する必要もない。
【０１０９】
次に、複数のリコール方式の自動最適化の手法について説明する。図８で説明したように、ある記事をきっかけとするリコール記事を抽出するための手法としては複数の計算アルゴリズムが利用可能である。これらの複数の計算アルゴリズムをシステムが自動的に選択して、ユーザの嗜好に合わせてチューニングすることも考えられる。
【０１１０】
図１５はそのような複数のリコール方式の自動最適化の第１の手法を示すフローチャートである。この方式では、一度のリコール記事データの作成において、複数のリコール方式を組み合わせて利用する。ここでは、第１、第２、第３の３個のリコール方式を組み合わせて、所定個（この例では３０個）の記事を抽出する例を説明する。例えば、第１のリコール方式は図８に示した１番目のリコール方式であり、第２のリコール方式は図８に示した２番目のリコール方式であり、第３のリコール方式は図８に示した２番目のリコール方式における連想ベクトルを異ならせたものである。
【０１１１】
サービスサーバは、リコール記事データの生成時に、まず、第１のリコール方式で上位ｎ１個の記事を抽出する（Ｓ２３１）。次いで、第２のリコール方式で上位ｎ２個の記事を抽出する（Ｓ２３２）。さらに、第３のリコール方式で上位ｎ３個の記事を抽出する（Ｓ２３３）。ここで、ｎ１，ｎ２，ｎ３の初期値は同じ（ここでは１０）である。そこで、ユーザ端末からリコール指示を待って（Ｓ２３４）、これらの抽出された記事＃１〜＃３０を含むリコール記事データをユーザ端末へ送信する（Ｓ２３５）。
【０１１２】
ユーザ端末は、このリコール記事データを受信し、記事＃１〜＃３０を表示する（Ｓ１３１）。その後、いずれかのリコール記事に対する選択操作があれば（Ｓ１３２，Ｙｅｓ）、その選択記事情報をサービスサーバに通知する。
【０１１３】
ここでの「選択操作」とは、当該記事に対する、例えば、上述した全文を表示させるための指示操作、あるいは上述した種々のボタン操作である。このような選択操作がなされたということは、そのリコール記事にユーザが何らかの関心を示したことを意味する。すなわち、そのリコール記事を抽出したリコール方式が当該ユーザに対して適正であったことを意味する。
【０１１４】
また、ここでの「選択記事情報」は例えばリコール記事データに含まれるリコール記事を特定するための情報であり、例えばリコール記事データ内の何番目のリコール記事であるかを示す数値である。この情報に応じて、サービスサーバはその選択操作が向けられた記事がどのリコール方式によって抽出されたものかが分かる。
【０１１５】
ユーザ端末からの選択記事情報を受けて、サービスサーバは、適正と判断されたリコール方式に基づいて、各リコール方式による抽出記事の提示順序および／またはその抽出記事数を更新する（Ｓ２３６）。「各リコール方式による抽出記事の提示順序」とは、リコール記事データ内の記事の順序であり、この例では、第１、第２、第３のリコール方式の実行順序である（実行順に提示順が決まるとして）。優先順位の高いリコール方式から順に、第１、第２、第３のリコール方式とする。「リコール方式の抽出記事数の更新」とは、そのリコール方式による記事の抽出個数である。例えば、第１、第２、第３のリコール方式の記事の抽出記事数の総和は変えずに、分担記事数ｎ１，ｎ２，ｎ３の値を変化させることである。
【０１１６】
このような自動最適化手法により、個々のユーザに適したリコール方式の使用頻度（または優先度）を高めることができる。
【０１１７】
図１６は、複数のリコール方式の自動最適化の第２の手法を示すフローチャートである。図１５の第１の手法では、一度のリコール記事データの作成時に複数のリコール方式を利用したが、第２の手法では一度のリコール記事データの作成時には単一個のリコール方式のみを利用し、作成時毎にリコール方式を切り替えるものである。
【０１１８】
サービスサーバは、リコール指示に応じて（Ｓ２４１）、記事データの生成時に、まず、第ｎのリコール方式で上位３０個の記事＃１〜＃３０を抽出して、リコール記事データとして、ユーザ端末へ送信する（Ｓ２４２）。（変数ｎの初期値は例えば１である。）
【０１１９】
ユーザ端末は、このリコール記事データを受信し、記事＃１〜＃３０を表示する（Ｓ１４１）。その後、いずれかのリコール記事に対する選択操作があれば（Ｓ１４２，Ｙｅｓ）、その選択記事情報をサービスサーバに通知する。
【０１２０】
ユーザ端末からの選択記事情報通知を受けて、サービスサーバは、選択記事情報とリコール方式との関係を例えば記憶部３５０に蓄積する（Ｓ２４３）。
【０１２１】
そこで、現在のリコール方式のユーザ適用性が有意であるかどうかをチェックする（Ｓ２４４）。有意かどうかの判断は、リコール記事の選択操作の有無に基づく判断、または、選択操作の閾値判断等によって行える。選択操作の閾値判断とは、例えば、リコール記事の配信回数に対する選択回数の割合が所定の閾値以上かどうかの判断である。有意でなければ、変数ｎをインクリメントして（Ｓ２４５）、ステップＳ２４１へ戻る。変数ｎはサイクリックに増分される。例えば、本例では、ｎは１，２，３，１，２，３，…と変化する。
【０１２２】
有意であることが判明したら（Ｓ２４４，Ｙｅｓ）、現在のリコール方式を維持するためにｎをインクリメントすることなく、ステップＳ２４１へ戻る。このようなｎ値の処理は、ユーザ適用性が有意なリコール方式の使用頻度（または優先度）を上げることに相当する。
【０１２３】
このような自動最適化手法により、個々のユーザに適したリコール方式が使用される頻度（比重）を高めることができる。
【０１２４】
図１７に、リコール記事要求およびリコール記事データ配信の処理の変形例を説明する。上記で説明した処理では、同じ記事についてのリコール指示は高々１回のみを想定した。しかし、ユーザが１回リコール指示をしたことに対してリコール記事が提示されたとき、その（またはそれらのいずれの）記事もユーザが求めた記事でない場合がありうる。そこで、同じきっかけ記事に対してユーザがさらなるリコール指示を行うことを許容し、そのリコール指示要求に対して、前回と異なるリコール方式でリコール記事を抽出するようにする。これにより、リコール方式の不適合により求める記事が抽出されなかった場合に、更なるリコール指示により当該求める記事が抽出される可能性が高まる。
【０１２５】
図１７は、このような段階的なリコール指示に関する、図１３の要部を変形した処理ステップを示している。ユーザＡの端末からリコール指示があった場合（Ｓ１１３，Ｙｅｓ）、そのリコール指示が同記事に対する何（ｐ）回目のリコール指示かを確認して、サービスサーバへ、第ｐのリコール方式によるリコール記事を要求する（Ｓ１１３ａ）。サービスサーバは、このリコール記事要求（ｐ）に応じて、第ｐのリコール方式により当該きっかけ記事に対応するリコール記事を抽出し、ユーザＡの端末へ配信する（Ｓ２１３ａ）。この際、好ましくは、既に送信したリコール記事と重複する記事は除外する。ユーザＡの端末はこのリコール記事を受信して表示する（Ｓ１１４）。
【０１２６】
なお、数値ｐの上限はリコール方式の個数に合わせて設定する。また、「更なるリコール指示」のために、recallmoreボタン（図示せず）のような特別なボタンを用意してもよいし、元のrecallボタンの押下回数をカウントして識別してもよい。さらには、別途メニューを利用してもよい。入力手段としては、上述した任意のユーザ操作入力の手段を利用可能である。
【０１２７】
次に、上述した「連想ベクトル」について説明する。上述したように、連想ベクトルは、きっかけ記事のデータ特徴ベクトルを拡張（変更）したものであり、その変更の手法の概略および具体例を以下に説明する。
【０１２８】
本実施の形態において、連想ベクトル（rvec）は、きっかけ記事のデータ特徴ベクトルを基に、ユーザＡのユーザ特徴ベクトル、ユーザＡの嗜好を表現する何らかの重み付き単語グラフなどを作用させることにより、その特徴を拡張したベクトル、すなわち、ユーザＡが、きっかけ記事から連想する特徴を表すベクトルである。このような連想ベクトルを求めるためには、例えば、ある単語に対する関連単語を対応づけた関連単語の辞書を用いて、求められた関連する単語を当該データ特徴ベクトルcvec に追加する。
【０１２９】
例えば、データ特徴ベクトルｃvec = {(カレー 0.3), (辛い 0.2), (レストラン 0.1), … } の場合、
連想ベクトルrvec = {(カレー 0.3), (インド 0.2), (辛い 0.2), (レストラン 0.1), (インド料理 0.1), …} 
が得られる。
【０１３０】
以下、更に、関係行列Ｍを利用して連想ベクトルを求める具体例について説明する。以下、便宜上、特徴ベクトルをｃで表し、連想ベクトルをｒで表す。
【０１３１】
関係行列Ｍとは、二つの語のペアに対してその重み(実数)を対応させる辞書であり、これによって語と語の間の関係の強さを表現するものである。語の対に対する関数として書ける他、「猫」という語が第１座標、「月」という語が第２座標、…のように座標と語の対応を一つに定めれば行列の形にも表現できる。
【０１３２】
例１: ユーザが選んだ文書(記事）群に対し、同時に一つの文書に含まれている(つまり、「共起」している)語のペアの集合。
M = { (猫, 犬), (猫, 月), (月, 本), ….. }
これは同時に一つの文書に含まれる語の対に対しては値１、それ以外の語の対には値０を対応させる辞書である。関係行列M( (猫, 犬) ) = 1 のように関数の形にも書ける。
【０１３３】
例２: ユーザが選んだ文書(記事）群の各文書の特徴ベクトルを考える。同時に一つの文書(つまり、一つの特徴ベクトル)に含まれる語の対に対して、それぞれの特徴ベクトルの中の重みの積を、同時に含まれた特徴ベクトル全体で平均する。
M = { (猫, 犬): m, ….} で、m = M( (猫, 犬) ) = (1/N) Σ c(猫) c(犬) など。
(ここで、N は「猫」と「犬」を同時に含む特徴ベクトルの数である。総和Σはそのような特徴ベクトルｃ 全体を対象とする。) 
【０１３４】
このような関係行列Ｍを用いて、連想ベクトルｒは次のように求めることができる。連想ベクトル r とは、与えられた特徴ベクトルｃ と関係行列Ｍ に対し、ある汎関数Ｆ によって、
r(w) = F(M, c) (w)
のように計算される、語 w に対しその重み r(w) を対応させる辞書である。この式によって得られた連想ベクトルｒは、特徴ベクトルｃに存在しなかった語の情報を含むことができる。
【０１３５】
なお、本明細書において「連想」とは、与えられた特徴ベクトルｃ と関係行列Ｍ に対し、連想ベクトル r = F(M, c) を作成し、その連想ベクトル r に「類似した」特徴ベクトルを持つ記事(文書)を、ある記事群(文書群)から選ぶ操作のことである。
【０１３６】
これによって、単に元の特徴ベクトルｃ に近いものを探すより、連想行列で表現された関係を加味した、より広い「連想」に基く対象を探すことができる。
【０１３７】
ベクトル間の「類似度」は、相関係数 （c・r）/(|c||r|) や、ユークリッド距離 |c - r|などで求めることができる。
【０１３８】
連想ベクトルの例として、次のようなものが挙げられる。連想ベクトルは、関係行列Ｍ，汎関数Ｆの選び方によって変わりうる。(また、特徴ベクトルの定義にも依存する)。
【０１３９】
例１: F(M, c) = M c, つまり関係行列Ｍ と特徴ベクトルｃ の通常の意味での積をとる。具体的に書けば、
r (w) = Σ M(w, w') c(w'). (総和Σは全ての語 w' を対象とする)
【０１４０】
例２: 上の例で総和の代わりに全ての w' に対する最大値をとる。
【０１４１】
例３: F(M, c) = M2 c, つまり、関係行列Ｍ の二乗と特徴ベクトルｃ の積をとる。
【０１４２】
より具体的に書けば、
r(w) = Σ ( Σ M(w, w') M(w', w'') ) c(w'').
(総和Σは、内側は全ての語 w' を対象とし、外側は全ての語 w'' を対象とする)。
【０１４３】
例１、例２では、元の特徴ベクトルに含まれなかった語も、その語と関係行列で関係している語(例えば、同じ文書に同時に登場した語)なら含まれるが、例３では、同じ意味で元の語に「関係している語に関係している語」まで加味される。
【０１４４】
例４: (リゾルベント)
関係行列Ｍ と小さなパラメータεに対し、以下の逆行列が計算できるとき、
R(M) = (1 - εM) -1
を用いて、r = R(M) c と計算する。
R(M) = 1 + εＭ + ε2Ｍ2 + ε3Ｍ3 + …
であるから、これは関係の関係、関係の関係の関係、の類を全て(遠くなるほど小さくなる重みつきで)加味したものになる。
【０１４５】
以下に、連想ベクトル計算の簡単な具体例を挙げる。
【０１４６】
与えられた特徴ベクトル(ユーザが今選んだ記事のデータ特徴ベクトル)を
c = {猫: 0.3, 月: 0.5, 酒: 0.2 }
とする。また、与えられた特徴ベクトル群(以前にユーザが選んだ記事群のデータ特徴ベクトル群)を
c1 = { 猫: 0.6, 犬: 0.4 },
c2 = { 月: 0.1, 本: 0.7, 映画: 0.2 }
とする。 
【０１４７】
猫、月、酒、犬、本、映画の順に、第 1 座標から第 6 座標として、
c = (0.3, 0.5, 0.2, 0, 0, 0), 
c1 = (0.6, 0, 0, 0.4, 0, 0),
c2 = (0, 0.1, 0, 0, 0.7, 0.2)
とベクトル型に表せる。
【０１４８】
また、c, c1, c2 から作られる関係行列として(c も用いるか否かは場合に依る)、同じ一つのベクトルに共起した語に対して 1、それ以外は 0 とする６×６行列を作る。つまり、
(猫, 月), (猫, 酒), (月, 酒); (猫, 犬); (月, 本), (月, 映画), (本, 映画) に対応する、第(1, 2), (1, 3), (2, 3); (1, 4); (2, 5), (2, 6), (5, 6) 座標と、その行と列を逆にした座標、および対角要素だけが 1 で、それ以外が 0 の行列を M とする。ここに（ｐ、ｑ）座標とはｐ行ｑ列を意味する。
【０１４９】
r = Ｍｃ によって、連想ベクトル r を計算すると、次式（１）のようになる。
【数１】
2014215625.tif 000003
すなわち、r = (1, 1, 1, 0.3, 0.5, 0.5) となり、c に含まれない「犬」、「本」、「映画」もある重みをもって連想される。
【０１５０】
以上、本発明の好適な実施の形態について説明したが、上記で言及した以外にも種々の変形、変更を行うことが可能である。例えば、文書の言語は日本語についてのみ説明したが、他の言語であってもよい。データ配信システムはインターネットを介してユーザ端末とサーバとが接続される形態を示したが、インターネットの代わりにＬＡＮのようなローカルな通信ネットワークを利用する形態であってもよい。
【０１５１】
上記実施の形態で説明した機能をコンピュータで実現するためのコンピュータプログラムおよびプログラムをコンピュータ読み取り可能に格納した記録媒体も本発明に含まれる。プログラムを供給するための「記録媒体」としては、例えば、磁気記憶媒体（フレキシブルディスク、ハードディスク、磁気テープ等）、光ディスク（ＭＯやＰＤ等の光磁気ディスク、ＣＤ、ＤＶＤ等）、半導体ストレージなどを挙げることができる。
【符号の説明】
【０１５２】
１００…ユーザ端末
１００ｃ…携帯電話端末
１００ｄ…テレビ受信機
１０２…記憶部
１０４…入力部
１０５…表示部
１０６…通信部
１１１…音声処理部
１１１ａ…マイク
１１１ｂ…スピーカ
１１２…放送受信部
１２１…記事受信・表示部
１２３…リコール指示検出部
１２５…リコール記事受信・表示部
２００…インターネット
３００…サービスサーバ
３１０…通信部
３２０…表示部
３３０…入力部
３４０…データ処理部
３４１…記事取得管理部
３４３…記事配信処理部
３４５…ユーザ管理部
３５０…記憶部
３５１…全体記事データ記憶部
３５３…ユーザ別記事データ記憶部
３５５…ユーザ管理データ記憶部
４００…ＷＥＢサーバ
５００…表示画面
５０１…配信日付
５１０…記事エリア
５１１…タイトル
５１２…テキスト
５１３…各種ボタン
５１４…サムネイル画像
６１０…表示画面
７００…表示画面
７１０…表示エリア
【図１】
2014215625.tif 000004
【図２】
2014215625.tif 000005
【図３】
2014215625.tif 000006
【図４】
2014215625.tif 000007
【図５】
2014215625.tif 000008
【図６】
2014215625.tif 000009
【図７】
2014215625.tif 000010
【図８】
2014215625.tif 000011
【図９】
2014215625.tif 000012
【図１０】
2014215625.tif 000013
【図１１】
2014215625.tif 000014
【図１２】
2014215625.tif 000015
【図１３】
2014215625.tif 000016
【図１４】
2014215625.tif 000017
【図１５】
2014215625.tif 000018
【図１６】
2014215625.tif 000019
【図１７】
2014215625.tif 000020