(57)【要約】  ユーザの興味のある記事を埋没させることなくユーザに提示する。  このため情報処理装置は、ユーザの閲覧履歴にある記事に出現する頻度の高い頻出キーワードを特定する頻出キーワード特定部と、前記頻出キーワードが出現する記事を抽出記事として抽出する記事抽出部と、ユーザの閲覧頻度を記事ジャンルごとに算出する閲覧頻度算出部と、前記抽出記事のうちで前記閲覧頻度の低い低閲覧頻度記事ジャンルに属する記事を埋没候補記事として選択し、優先的な提示処理を行う提示制御部と、を備えたものである。
2018029810.tif 000002
【特許請求の範囲】
【請求項１】
ユーザの閲覧履歴にある記事に出現する頻度の高い頻出キーワードを特定する頻出キーワード特定部と、
前記頻出キーワードが出現する記事を抽出記事として抽出する記事抽出部と、
ユーザの閲覧頻度を記事ジャンルごとに算出する閲覧頻度算出部と、
前記抽出記事のうちで前記閲覧頻度の低い低閲覧頻度記事ジャンルに属する記事を埋没候補記事として選択し、優先的な提示処理を行う提示制御部と、を備えた
情報処理装置。
【請求項２】
前記記事抽出部は、前記抽出記事を抽出する際に前記頻出キーワードと類似するキーワードを含む記事についても前記抽出記事として抽出する
請求項１に記載の情報処理装置。
【請求項３】
前記提示制御部は、前記低閲覧頻度記事ジャンルが複数ある場合に、前記埋没候補記事の数が少ない前記低閲覧頻度記事ジャンルに属する埋没候補記事の提示優先度を上げて提示する
請求項１に記載の情報処理装置。
【請求項４】
前記提示制御部は、記事の概要を表す記事見出しに前記頻出キーワードを含む前記埋没候補記事の提示優先度を上げて提示する
請求項１に記載の情報処理装置。
【請求項５】
前記提示制御部は、記事の概要を表す記事見出しに前記頻出キーワードを含まない前記埋没候補記事の提示優先度を上げて提示する
請求項１に記載の情報処理装置。
【請求項６】
前記提示制御部は、前記埋没候補記事が属する記事ジャンルを初期表示ジャンルとして設定する
請求項１に記載の情報処理装置。
【請求項７】
ユーザの閲覧履歴にある記事に出現する頻度の高い頻出キーワードを特定する頻出キーワード特定ステップと、
前記頻出キーワードが出現する記事を抽出記事として抽出する記事抽出ステップと、
ユーザの閲覧頻度を記事ジャンルごとに算出する閲覧頻度算出ステップと、
前記抽出記事のうちで前記閲覧頻度の低い低閲覧頻度記事ジャンルに属する記事を埋没候補記事として選択し、優先的な提示処理を行う提示制御ステップと、を
情報処理装置が実行する情報処理方法。
【請求項８】
ユーザの閲覧履歴にある記事に出現する頻度の高い頻出キーワードを特定する頻出キーワード特定機能と、
前記頻出キーワードが出現する記事を抽出記事として抽出する記事抽出機能と、
ユーザの閲覧頻度を記事ジャンルごとに算出する閲覧頻度算出機能と、
前記抽出記事のうちで前記閲覧頻度の低い低閲覧頻度記事ジャンルに属する記事を埋没候補記事として選択し、優先的な提示処理を行う提示制御機能と、を
情報処理装置に実行させるプログラム。
【請求項９】
ユーザの閲覧履歴にある記事に出現する頻度の高い頻出キーワードを特定する頻出キーワード特定機能と、
前記頻出キーワードが出現する記事を抽出記事として抽出する記事抽出機能と、
ユーザの閲覧頻度を記事ジャンルごとに算出する閲覧頻度算出機能と、
前記抽出記事のうちで前記閲覧頻度の低い低閲覧頻度記事ジャンルに属する記事を埋没候補記事として選択し、優先的な提示処理を行う提示制御機能と、を
情報処理装置に実行させるプログラムを記憶した記憶媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理装置、情報処理方法、プログラム及び記憶媒体に関し、特に複数の記事ジャンルごとに管理された各記事の提示制御に関する。
【先行技術文献】
【特許文献】
【０００２】
【特許文献１】特開２０１３−１６１３７９号公報
【背景技術】
【０００３】
上記特許文献１には、タブ（記事ジャンル）と記事群が紐付けられており、複数のタブごとにまとめられた記事群を操作に応じて切替提示する技術が開示されている。
例えば、ニュース記事が纏められたポータルサイトなどでは、「総合」、「政治」、「経済」、「スポーツ」、「芸能」など記事ジャンルをタブの見出しとして並べて提示し、ユーザは所望のタブを選択することによって、関連づけられた記事群を閲覧できるようになっている。【０００４】
ところで、ユーザは、自身の興味に沿った記事を閲覧する傾向にある。換言すれば、興味の無い記事は閲覧しないことが多い。また、ユーザの興味のある記事は、特定の記事ジャンルに偏ることが多く、例えばサッカーに興味のあるユーザは、サッカーに関する記事が属する「スポーツ」の記事ジャンルに含まれる記事を閲覧する機会が多い。そのため、「スポーツ」に関する知見が得られやすい環境にあると言える。
【発明の概要】
【発明が解決しようとする課題】
【０００５】
一方、このユーザの興味が無い記事ジャンルとして「経済」が挙げられるとする。そういった場合、「サッカーのワールドカップ開催国における経済上の効果」などのような記事が「経済」の記事ジャンルに紐付けられていても、当該ユーザが「経済」のタブを選択しない限り目にする可能性は低くなってしまう。
そこで本発明は、このような状況を考慮し、ユーザの興味のある記事を埋没させることなくユーザに提示することを目的とする。
【課題を解決するための手段】
【０００６】
本発明に係る情報処理装置は、ユーザの閲覧履歴にある記事に出現する頻度の高い頻出キーワードを特定する頻出キーワード特定部と、前記頻出キーワードが出現する記事を抽出記事として抽出する記事抽出部と、ユーザの閲覧頻度を記事ジャンルごとに算出する閲覧頻度算出部と、前記抽出記事のうちで前記閲覧頻度の低い低閲覧頻度記事ジャンルに属する記事を埋没候補記事として選択し、優先的な提示処理を行う提示制御部と、を備えたものである。
本来なら、ユーザの閲覧頻度が低い記事ジャンルに属する記事は、記事の内容によらず未閲覧のままであることが多い。
ところが、本構成によれば、閲覧頻度が低い記事ジャンルに属する記事の中で、ユーザが興味を抱く可能性の高い頻出キーワードが含まれている記事（埋没候補記事）に関しては、優先的にユーザに提示される。
これにより、様々な記事ジャンルにユーザを導くことが可能となるため、記事を集めたポータルサイトにおけるユーザの回遊性を高めることができる。【０００７】
上記した情報処理装置の前記記事抽出部は、前記抽出記事を抽出する際に前記頻出キーワードと類似するキーワードを含む記事についても前記抽出記事として抽出することが望ましい。
これにより、「頻出キーワード」だけでなく、ユーザが興味を持つと推測される「類似キーワード」を含む記事についての抽出される。【０００８】
上記した情報処理装置の前記提示制御部は、前記低閲覧頻度記事ジャンルが複数ある場合に、前記埋没候補記事の数が少ない前記低閲覧頻度記事ジャンルに属する埋没候補記事の提示優先度を上げて提示することが望ましい。
これにより、ユーザにとってより目に付かない低閲覧頻度記事ジャンルに属する埋没候補記事に高い提示優先度が付与されて提示される。即ち、閲覧する可能性の低い記事が優先度を高くされて提示される。【０００９】
上記した情報処理装置の前記提示制御部は、記事の概要を表す記事見出しに前記頻出キーワードを含む前記埋没候補記事の提示優先度を上げて提示することが望ましい。
これにより、ユーザが記事見出し中に自身の興味のあるキーワード（頻出キーワード）を視認できる埋没候補記事が優先的に提示される。【００１０】
上記した情報処理装置の前記提示制御部は、記事の概要を表す記事見出しに前記頻出キーワードを含まない前記埋没候補記事の提示優先度を上げて提示することが望ましい。
これにより、ユーザが自力で発見できないような埋没候補記事が優先的に提示される。【００１１】
上記した情報処理装置の前記提示制御部は、前記埋没候補記事が属する記事ジャンルを初期表示ジャンルとして設定することが望ましい。
これにより、ユーザが自力で発見できないような埋没候補記事が初期表示される。【００１２】
本発明に係る情報処理方法は、ユーザの閲覧履歴にある記事に出現する頻度の高い頻出キーワードを特定する頻出キーワード特定ステップと、前記頻出キーワードが出現する記事を抽出記事として抽出する記事抽出ステップと、ユーザの閲覧頻度を記事ジャンルごとに算出する閲覧頻度算出ステップと、前記抽出記事のうちで前記閲覧頻度の低い低閲覧頻度記事ジャンルに属する記事を埋没候補記事として選択し、優先的な提示処理を行う提示制御ステップと、を情報処理装置が実行するものである。
これにより、閲覧頻度が低い記事ジャンルに属する記事の中で、ユーザが興味を抱く可能性の高い頻出キーワードが含まれている記事（埋没候補記事）に関しては、優先的にユーザに提示される。
本発明に係るプログラムは、上記情報処理方法の各ステップとしての処理を情報処理装置に実行させるプログラムである。
本発明に係る記憶媒体は、上記プログラムを記憶した記憶媒体である。これらのプログラムや記憶媒体により上記の情報処理装置を実現する。
【発明の効果】
【００１３】
本発明によれば、ユーザの興味のある記事を埋没させることなくユーザに提示することができる。
【図面の簡単な説明】
【００１４】
【図１】実施の形態のネットワークシステムの構成例についての説明図である。
【図２】運営サーバ１が備える各部についての説明図である。
【図３】キーワードＤＢ５３の例についての説明図である。
【図４】キーワードＤＢ５３の別の例についての説明図である。
【図５】情報処理装置についてのハードウェア構成図である。
【図６】バッチ処理についてのフローチャートである。
【図７】全体の処理の流れについて説明する図である。
【図８】ニュースサイトのトップページの例を示す図である。
【図９】記事詳細ページの例を示す図である。
【図１０】運営サーバの処理についてのフローチャートである。
【図１１】トップページデータ生成処理の第１例についてのフローチャートである。
【図１２】トップページデータ生成処理の第２例についてのフローチャートである。
【図１３】トップページデータ生成処理の第３例についてのフローチャートである。
【図１４】トップページデータ生成処理の第４例についてのフローチャートである。
【図１５】ニュースサイトのトップページの別の例を示す図である。
【発明を実施するための形態】
【００１５】
以下に示す実施の形態では、本発明における情報処理装置の一例として、複数の記事をジャンルごとにまとめて管理し、閲覧しやすいようにユーザに提示するニュースポータルサイト（以下、ニュースサイトと記載）を運営するサーバ（以降、運営サーバ１と記載）を例に挙げて説明する。
【００１６】
以下、実施の形態を次の順序で説明する。
＜１．全体構成＞
＜２．サーバの機能構成及びデータベース＞
［２−１．サーバの機能構成］
［２−２．データベース］
＜３．タブの提示に関する処理＞
＜４．情報記憶処理＞
［４−１．バッチ処理］
［４−２．嗜好タブ判定情報記憶処理］
［４−３．非嗜好タブ判定情報記憶処理］
［４−４．切替頻度判定情報記憶処理］
＜５．まとめ＞
＜６．プログラム及び記憶媒体＞
【００１７】
＜１．全体構成＞
本実施の形態としての運営サーバ１を含むネットワークシステム全体の構成について、図１及び図２を用いて説明する。
図１に示すように、本実施の形態の運営サーバ１は、通信ネットワーク２を介して、運営サーバ１が運営するニュースサイトの各記事を閲覧するユーザが使用するユーザ端末３，３，・・・ニュースサイトに記事を投稿する投稿者が利用する投稿者端末４，４，・・・と相互に通信可能な状態で接続されている。
【００１８】
運営サーバ１は、ニュースサイトを運営するための各種処理を実行する情報処理装置である。具体的には、投稿者からの記事の投稿を受け付ける投稿受付処理や、投稿された記事をＤＢ（Database）に記憶する処理などを行う。また、ユーザが所望する記事を提供するための検索処理を行う。
【００１９】
更に、運営サーバ１は、上記の各種機能を実現するためのユーザインタフェースとしてのウェブページを他の情報処理装置（ユーザ端末３や投稿者端末４）上に表示させるために、ウェブページデータの生成処理と送信処理を行う。
ウェブページデータは、例えば、ＨＴＭＬ（Hyper Text Markup Language）やＸＨＴＭＬ（Extensible HyperText Markup Language）などの構造化文書ファイルである。構造化文書ファイルには、記事の見出し（記事見出し）や記事の詳細（記事詳細）などのテキストデータや記事の内容を補足する画像などの画像データ（或いは動画データ）と、それらの配置や表示態様（文字色やフォントや大きさや装飾など）が記述されている。
ウェブページとしては、例えば、ユーザや投稿者にログイン情報を入力させるためのログインページや、記事一覧を表示する記事一覧ページや、記事詳細を表示する記事詳細ページなどである。
【００２０】
これらの機能を実現するために、運営サーバ１は、図１に示すように、ユーザに関する情報が記憶されるユーザＤＢ５０、ニュース記事が記憶される記事ＤＢ５１、ユーザの閲覧履歴やログイン履歴などが記憶される履歴ＤＢ５２、ユーザが閲覧したことのある記事に頻出するキーワードである「頻出キーワード」が記憶されるキーワードＤＢ５３、類似キーワードが記憶される類似キーワードＤＢ５４を管理している。
各ＤＢの詳細は、後述する。
【００２１】
通信ネットワーク２の構成は特に限定されるものではなく、例えば、インターネット、イントラネット、エキストラネット、ＬＡＮ（Local Area Network）、ＣＡＴＶ（Community Antenna TeleVision）通信網、仮想専用網（Virtual Private Network）、電話回線網、移動体通信網、衛星通信網などが想定される。
また通信ネットワーク２の全部または一部を構成する伝送媒体についても多様な例が想定される。例えばＩＥＥＥ（Institute of Electrical and Electronics Engineers）１３９４、ＵＳＢ（Universal Serial Bus）、電力線搬送、電話線などの有線でも、ＩｒＤＡ（Infrared Data Association）のような赤外線、ブルートゥース（登録商標）、８０２．１１無線、携帯電話網、衛星回線、地上波デジタル網などの無線でも利用可能である。
【００２２】
ユーザ端末３は、ニュースサイトに投稿された記事の閲覧などを行うユーザが使用する端末である。
投稿者端末４は、ニュースサイトに記事を投稿する投稿者が使用する端末である。
ユーザ端末３や投稿者端末４では、必要に応じて各種の送受信処理や表示処理などが実行される。また、ユーザ端末３や投稿者端末４は、例えば、通信機能を備えたＰＣ（Personal Computer）やフィーチャーフォンやＰＤＡ（Personal Digital Assistant）、或いは、スマートフォンやタブレット端末などのスマートデバイスなどである。
【００２３】
運営サーバ１が備える各部について、図２を参照して説明する。
運営サーバ１は、頻出キーワード特定部１ａと、類似キーワード取得部１ｂと、記事抽出部１ｃと、閲覧頻度算出部１ｄと、提示制御部１ｅと、を備える。
【００２４】
頻出キーワード特定部１ａは、あるユーザが閲覧したことのある記事に出現するキーワードのうち、頻出するキーワードを特定する処理を実行する。特定した「頻出キーワード」は、キーワードＤＢ５３に記憶される。
尚、以降の説明においては、あるユーザのことを「ユーザＡ」と記載する。
【００２５】
ユーザＡの「頻出キーワード」の特定にはいくつかの手法が考えられる。
一つ目の手法は、単純に出現数が多いキーワードを「頻出キーワード」とする手法である。例えば、ユーザＡが閲覧したことのある記事（以降、「既閲覧記事」と記載）からキーワード（例えば、名詞）を全て抜き出してカウントする。その中から、カウント数が多いキーワードを「頻出キーワード」とする。
具体的には、閲覧記事数に対する出現数が所定数以上（例えば１０記事当たり５個以上出現しているもの）のキーワードを「頻出キーワード」としてもよい。
キーワードＤＢ５３についての一例を示した図３を用いて説明する。
図３に示すキーワードＩＤ＝Ｋ２１３３９，Ｋ００１５２，Ｋ１７４７９，Ｋ２８００１とされた四つのキーワードは、１０記事当たり５個以上出現しているため、「頻出キーワード」とされる。
また、出現頻度の多い所定数のキーワード（例えば上位２０個のキーワード）を「頻出キーワード」としてもよい。
【００２６】
二つ目の手法は、キーワードごとの出現のしやすさ加味して「頻出キーワード」を決定する手法である。
キーワードＤＢ５３についての別の例を示した図４を用いて説明する。
例えば、図４に示すように、全記事（即ちユーザＡが閲覧した記事だけでなく、未閲覧の記事も含む）における出現数（個／記事）をキーワードごとに算出する。更に、ユーザＡの既閲覧記事における出現数（個／記事）を算出する。
全記事における出現数に対して、既閲覧記事における出現数が多いものを「頻出キーワード」とする。
このとき、全記事における出現数に対して、既閲覧記事における出現数が多いもの全てを「頻出キーワード」としてもよい。即ち、図４に示すキーワードＩＤ＝Ｋ３０１２５，Ｋ１８０３７，Ｋ０３０５１，Ｋ８１３６８，Ｋ２２１２７とされた各キーワードは、全て「頻出キーワード」とされる。
【００２７】
また、全記事における出現数に対して一定割合以上多いもの（例えば３倍以上出現しているなど）を「頻出キーワード」としてもよい。即ち、図４におけるキーワードＩＤ＝Ｋ３０１２５，Ｋ１８０３７とされた二つのキーワードは、全記事における出現数に対して既閲覧記事における出現数が３倍以上であるため、「頻出キーワード」とされる。
【００２８】
類似キーワード取得部１ｂは、頻出キーワード特定部１ａが特定した「頻出キーワード」に基づいて、類似キーワードＤＢ５４から類似キーワードを取得する処理を実行する。
記事抽出部１ｃは、頻出キーワード特定部１ａが特定した「頻出キーワード」や類似キーワード取得部１ｂが取得した「類似キーワード」が記事見出しや記事詳細に含まれる記事を、抽出記事として抽出する。即ち、抽出記事は、ユーザの興味が高いと推測される記事となる。
【００２９】
閲覧頻度算出部１ｄは、各ユーザの閲覧頻度を記事ジャンルごとに算出する処理を実行する。記事ジャンルとは、ユーザが興味のある記事を検索しやすいように各記事を分類するためのものであり、具体的には、「政治」、「経済」、「芸能」、「テクノロジー」、「国内」、「外国」などである。ユーザは、このような記事ジャンルに基づいて閲覧したい記事を効率よく検索することが可能である。
一つの記事に対しては、一つの記事ジャンルが付されるようにしてもよいし、複数の記事ジャンルが付されるようにしてもよい。
複数の記事ジャンルが付された記事は、それぞれの記事ジャンルにおいて検索結果として抽出され得る。
【００３０】
記事ジャンルごとに算出される閲覧頻度は、例えば、単位時間（例えば一日）当たりの閲覧回数（閲覧記事数）とされる。また、頻度ではなく、割合であってもよい。例えば、記事ジャンルに属する記事数に対する既閲覧記事数の割合（閲覧記事割合、閲覧可能性）であってもよい。具体的には、ある日に投稿された「政治」の記事ジャンルに属する記事が１００記事であったのに対し、ユーザＡが閲覧した「政治」の記事ジャンルに属する記事数が８０記事であった場合、閲覧記事割合は８０％となる。
【００３１】
以降では、閲覧頻度が高い記事ジャンルを「高閲覧頻度記事ジャンル」と記載し、閲覧頻度が低い記事ジャンルを「低閲覧頻度記事ジャンル」と記載する。「高閲覧頻度記事ジャンル」及び「低閲覧頻度記事ジャンル」は、ユーザごとに異なる。
「高閲覧頻度記事ジャンル」であるか「低閲覧頻度記事ジャンル」であるかの判定は、所定の閾値に基づいて行う。所定の閾値は、全てのユーザに対して同じ値を用いてもよいし、ユーザごとに異なる値を用いてもよい。
例えば、ニュースサイトに投稿された記事の８割に目を通すユーザＡと、１割程度しか目を通さないユーザＢでは、所定の閾値を変えることが考えられる。
【００３２】
提示制御部１ｅは、ユーザに対してニュースサイトに投稿された記事の提示制御を行う。
ここで、新しく投稿された記事の提示優先度を上げて提示すると共に、「頻出キーワード」や「類似キーワード」を含む記事として抽出された抽出記事（ユーザの興味が高いと考えられる記事）の提示優先度を上げて提示する。このとき、ユーザの記事ジャンルごとの閲覧頻度に基づいて提示制御を行う。
具体的には、抽出記事の中で、閲覧頻度算出部１ｄにおいて「低閲覧頻度記事ジャンル」とさあれた記事ジャンルに属する記事を、「埋没候補記事」として選択し、優先的にユーザに提示する。
ユーザの興味が高そうな抽出記事であっても、「低閲覧頻度記事ジャンル」に属する「埋没候補記事」はユーザが余り見ない記事ジャンルに属する記事であるため、見落としがちである。
そこで、そのような「埋没候補記事」をユーザに提示することにより、ユーザの記事の見落としを軽減することができる。
【００３３】
また、提示制御部１ｅは、その他の種々の条件を加味して各記事の提示優先度を決定し、ユーザに提示する。これらの具体的処理内容については、後述する。
【００３４】
＜２．ハードウェア構成＞
図５は、図１に示した運営サーバ１、ユーザ端末３、投稿者端末４、そして、ユーザＤＢ５０、記事ＤＢ５１、履歴ＤＢ５２、キーワードＤＢ５３、類似キーワードＤＢ５４のハードウェアを例示する図である。それぞれのサーバや端末におけるコンピュータ装置のＣＰＵ（Central Processing Unit）１０１は、ＲＯＭ（Read Only Memory）１０２に記憶されているプログラム、または記憶部１０８からＲＡＭ（Random Access Memory）１０３にロードされたプログラムに従って各種の処理を実行する。ＲＡＭ１０３にはまた、ＣＰＵ１０１が各種の処理を実行する上において必要なデータなども適宜記憶される。
ＣＰＵ１０１、ＲＯＭ１０２、およびＲＡＭ１０３は、バス１０４を介して相互に接続されている。このバス１０４には、入出力インタフェース１０５も接続されている。
入出力インタフェース１０５には、キーボード、マウス、タッチパネルなどよりなる入力装置１０６、ＬＣＤ（Liquid Crystal Display）、ＣＲＴ（Cathode Ray Tube）、有機ＥＬ（Electroluminescence）パネルなどよりなるディスプレイ、並びにスピーカなどよりなる出力装置１０７、ＨＤＤ（Hard Disk Drive）やフラッシュメモリ装置などより構成される記憶部１０８、通信ネットワーク２を介しての通信処理や機器間通信を行う通信部１０９が接続されている。
入出力インタフェース１０５にはまた、必要に応じてメディアドライブ１１０が接続され、磁気ディスク、光ディスク、光磁気ディスク、或いは半導体メモリなどのリムーバブルメディア１１１が適宜装着され、リムーバブルメディア１１１に対する情報の書込や読出が行われる。
【００３５】
このようなコンピュータ装置では、通信部１０９による通信によりデータやプログラムのアップロード、ダウンロードが行われる。また、リムーバブルメディア１１１を介したデータやプログラムの受け渡しが可能である。
ＣＰＵ１０１が各種のプログラムに基づいて処理動作を行うことで、運営サーバ１、ユーザ端末３、投稿者端末４、そして、ユーザＤＢ５０、記事ＤＢ５１、履歴ＤＢ５２、キーワードＤＢ５３、類似キーワードＤＢ５４のそれぞれにおいて後述する情報処理や通信が実行される。
尚、運営サーバ１、ユーザ端末３、投稿者端末４、そして、ユーザＤＢ５０、記事ＤＢ５１、履歴ＤＢ５２、キーワードＤＢ５３、類似キーワードＤＢ５４を構成するそれぞれの情報処理装置は、図５のようなコンピュータ装置が単一で構成されることに限らず、複数のコンピュータ装置がシステム化されて構成されてもよい。複数のコンピュータ装置は、ＬＡＮなどによりシステム化されていてもよいし、インターネットなどを利用したＶＰＮ（Virtual Private Network）などにより通信可能な状態で遠隔地に配置されたものでもよい。
【００３６】
＜３．ＤＢ＞
運営サーバ１が管理する各種ＤＢについて説明する。
ユーザＤＢ５０には運営サーバ１が提供するニュースサイトを利用するユーザの情報が記憶される。例えば、一つのユーザＩＤ（Identification）に対して、ログインパスワード、氏名、年齢、性別、住所、メールアドレス、年収、趣味などの個人的な情報が紐付けられて記憶される。
ユーザＩＤは、運営サーバ１が提供するユーザの嗜好情報を用いたサービス（例えば、ユーザの好みの記事が閲覧しやすいようにニュースサイトがカスタマイズされるサービス）を利用するためにユーザがユーザ登録を行った際に、運営サーバ１が付与するＩＤである。
【００３７】
また、ユーザＤＢ５０には、ユーザごとの閲覧頻度情報も記憶される。閲覧頻度情報は、全ての記事ジャンルの閲覧頻度が数値で記憶されてもよいし、閲覧頻度の低い記事ジャンルと閲覧頻度が紐付けられて記憶されてもよい。また、閲覧頻度の低い記事ジャンルを特定するジャンルＩＤのみが記憶されてもよい。
【００３８】
記事ＤＢ５１には、投稿者によって投稿された記事が記憶される。具体的には、一つの記事を特定可能な記事ＩＤに対して、記事見出しや記事詳細や投稿日時や投稿者ＩＤや記事ジャンルなどが紐付けられて記憶される。
また、記事ごとに関連する画像や動画が投稿された場合には、これらの情報も併せて記憶される。
更に、記事ごとに生成される記事詳細を表示するためのウェブページデータも記憶される。
【００３９】
即ち、記事詳細のウェブページデータとして、記事詳細ページのＵＲＬ情報と記事詳細ページ上に配置されるオブジェクト（画像やテキストやバナーなど）の配置情報が記憶されてもよい。配置情報とは、記事詳細ページ上における各オブジェクト（記事見出しや記事詳細）の配置態様（位置や大きさ、色等）などを特定する情報である。
記事ＤＢ５１に記憶されるウェブページデータの情報は、例えば、ＨＴＭＬなどの構造化文書ファイルで記憶される。
【００４０】
尚、記事見出しや記事詳細に含まれるキーワードを記事ごとに記憶してもよい。
これにより、あるキーワードＫ１を含む記事を検索するたびに、記事見出しや記事詳細の文章からキーワードＫ１を検索する必要がなくなり、記事ごとに紐付けられて記憶されたキーワードの中にキーワードＫ１が含まれているかどうかを確認するだけで済む。
即ち、キーワードに応じた記事検索を行う際の運営サーバ１の検索時間や処理負担の軽減を図ることができる。
【００４１】
履歴ＤＢ５２には、ユーザの記事の閲覧履歴が記憶される。
具体的には、ユーザＩＤに対して閲覧した記事の記事ＩＤ、閲覧日時などが紐付けられて記憶される。
【００４２】
キーワードＤＢ５３には、ユーザＩＤごとに一つのキーワードを一意に特定可能なキーワードＩＤと、キーワードの文字列と、各種出現数（出現頻度を表す数値）が記憶される。
即ち、各ユーザごとに興味のあるキーワードとして「頻出キーワード」が記憶される。
具体的には、先の図３，図４に示す通りである。
尚、出現数は必ずしも必要ではなく、ユーザごとの「頻出キーワード」が記憶されるだけでもよい。
【００４３】
類似キーワードＤＢ５４には、キーワードＤＢ５３に記憶される各キーワードに類似するキーワードが類似キーワードとして記憶される。
類似キーワードは、ユーザごとに記憶される必要はなく、各キーワードごとに対応する類似のキーワードが記憶される。
具体的には、キーワードを特定するキーワードＩＤに対して、当該キーワードに類似しているとされる「類似キーワード」が１または複数紐付けられて記憶される。
【００４４】
＜４．処理の流れ＞
本実施の形態の運営サーバ１は、ユーザがニュースサイトを利用する際に、ユーザの興味のある記事が閲覧されずに埋もれてしまうことを防止するものである。
そのためには、ユーザの興味を引くキーワードとして推測される「頻出キーワード」を特定する処理や、ユーザの興味のある記事ジャンルを特定するための処理を実行し、それらの処理によって埋没候補記事を特定し、ユーザに提示する必要がある。
これらの処理は、ユーザがニュースサイトを閲覧するときに実行してもよいが、処理負担の大きさによっては、ニュースサイトのウェブページの迅速な提示が阻害され、ユーザの使用感（快適さ）を悪化させてしまう虞がある。
そこで、いくつかの処理をバッチ処理によって予め実行しておくことが望ましい。
【００４５】
［４−１．バッチ処理］
ここで説明するバッチ処理では、一例として、頻出キーワード特定処理と閲覧頻度算出処理を実行する（図６参照）。
尚、バッチ処理を定期的に行うことによって、ユーザの嗜好の変化などを適切に捉え、後述する各種処理を最適な状態で実行することができる。
【００４６】
先ず、運営サーバ１は、ステップＳ１０１において、処理対象とされたユーザ（ユーザＡ）のユーザＩＤを取得する処理を実行する。
尚、処理対象とされたユーザが存在しない場合は、バッチ処理を行わない。
【００４７】
続いて、運営サーバ１はステップＳ１０２において、ユーザＡの閲覧履歴を履歴ＤＢ５２から取得する処理を実行する。
【００４８】
そして、運営サーバ１はステップＳ１０３において、ユーザＡの「頻出キーワード」を特定する処理を実行する。前述したように、ユーザＡが閲覧したことのある記事に頻出するキーワードは、ユーザの興味を引くキーワードである可能性が高い。
この処理では、そのようなキーワードを「頻出キーワード」として特定する。
【００４９】
続いて、運営サーバ１はステップＳ１０４において、特定した「頻出キーワード」をキーワードＤＢ５３に記憶する処理を実行する。
【００５０】
更に、運営サーバ１はステップＳ１０５において、閲覧頻度算出処理を実行する。
閲覧頻度は、前述したように、記事ジャンルごとのユーザＡの興味を推し量るための尺度であり、記事ジャンルごとの閲覧記事数や閲覧記事割合などに基づいて算出される。
記事ジャンルごとに算出された数値は、運営サーバ１によるステップＳ１０６の記憶処理により、ユーザＤＢ５０に記憶される。
尚、「低閲覧頻度記事ジャンル」のみをユーザＤＢ５０に記憶し、閲覧頻度を示す数値は記憶しなくてもよい。
【００５１】
続いて、運営サーバ１はステップＳ１０７において、バッチ処理の処理対象とされた全てのユーザに対して当該バッチ処理を行ったか否かを判定する処理を実行する。
全てのユーザに対してバッチ処理を行った場合、運営サーバ１は図６に示す一連の処理を終了する。
一方、全てのユーザに対してバッチ処理を行っていない場合、運営サーバ１は再びステップＳ１０１のユーザＩＤ取得処理を行い、次のユーザ（例えばユーザＢ）のユーザＩＤを取得する。
【００５２】
尚、前回のバッチ処理と今回のバッチ処理の間にニュースサイトを利用しておらず、「頻出キーワード」に変化がないユーザに関しては、ステップＳ１０４の頻出キーワード特定処理の対象外としてもよい。
これにより、運営サーバ１の処理負担を軽減することができる。
【００５３】
［４−２．全体の処理の流れ］
全体の処理の流れについて、図７を参照して説明する。
ユーザ端末３はステップＳ２０１において、ユーザがログインページを表示させる操作を行ったことに応じ、ログインページ要求処理を実行する。ログインページ要求処理によりユーザ端末３から運営サーバ１へログインページ要求（ウェブページデータ要求）が送信されると、運営サーバ１はステップＳ３０１において、ログインページデータ送信処理を実行する。
これにより、例えば、運営サーバ１から受信したニュースサイトへのログイン画面情報（ウェブページデータ）に応じたウェブページがユーザ端末３上に表示される。
【００５４】
次に、ユーザ端末３はステップＳ２０２において、ユーザによって入力されたログイン情報（例えばユーザＩＤとログインパスワード）を運営サーバ１へ送信するログイン情報送信処理を実行する。ユーザ端末３から運営サーバ１へログイン情報が送信されると、運営サーバ１はステップＳ３０２において認証処理を実行し、続くステップＳ３０３において認証結果通知処理を実行する。
具体的には、運営サーバ１は、ユーザ端末３上で入力されたユーザＩＤとログインパスワードをユーザＤＢ５０に記憶された情報と比較して当該ユーザのログイン可否を判定し、認証結果をユーザ端末３へ通知する。
尚、ユーザごとにカスタマイズされたニュースサイトを利用するためには、ログイン操作が必要である。
【００５５】
図５に示す一連の流れは、ステップＳ３０２の認証処理においてログイン可と判定された場合を示している。ステップＳ３０２においてログイン不可と判定した場合は、ユーザ端末３は再度ステップＳ２０２の処理を実行し、これに応じて運営サーバ１はステップＳ３０２，Ｓ３０３の処理を実行する。
【００５６】
続いて、ユーザ端末３は、ユーザからニュースサイトのトップページを表示させるための操作を受け付けると、ステップＳ２０３において、トップページ要求処理を実行する。
トップページのウェブページデータ要求を受信した運営サーバ１は、ステップＳ３０４において、トップページの閲覧の履歴を履歴ＤＢ５２に記憶すると共に、ステップＳ３０５においてトップページデータを生成するトップページデータ生成処理を実行し、次に、ステップＳ３０６においてトップページデータを送信する処理を実行する。
これにより、ニュースサイトのトップページがユーザ端末３上に表示される。
ステップＳ３０５のトップページデータ生成処理については、詳細を後述する。
【００５７】
尚、先のステップＳ３０３において、運営サーバ１は、認証結果をユーザ端末３へ返すと共にニュースサイトのトップページのウェブページデータの生成と送信を実行してもよい。これにより、ユーザ認証がなされると共に、ユーザ端末３上にニュースサイトのトップページが表示される。
【００５８】
ニュースサイトのトップページの一例を図８に示す。
尚、先のログインページやトップページなどの各種ウェブページは、ユーザ端末３にインストールされているウェブブラウザ５上に表示される。
図８に示すように、ウェブブラウザ５の上端部付近には、ウェブページの変更や表示態様の変更を行うための各種操作子６，６，６，・・・が設けられている。また、ウェブページを検索するための検索フォーム７や、表示されているウェブページのＵＲＬが表示されるアドレス表示部８が配置されている。
更に、その下方には、ウェブページが表示されるウェブページ表示部９が配置されている。
【００５９】
ウェブページ表示部９には、ログイン状態を表示するユーザ状態表示部１０と、各種記事の概要が表示される記事概要表示部１１と、広告が表示される広告枠１２，１２と、各種のコンテンツが表示されるコンテンツ表示部１３，１３とが設けられている。
ユーザ状態表示部１０には、ニュースサイトを利用するユーザのログイン状態が表示される。更に、ユーザ状態表示部１０には、ユーザの登録情報を変更するためのボタンやログアウトするためのボタンなどが設けられている。
【００６０】
記事概要表示部１１には、記事ジャンルごとに対応したタブ１１ａ，１１ａ，・・・と、選択されたタブ（即ち記事ジャンル）に応じた主要な記事の記事見出しが複数表示される記事見出し表示部１１ｂとが設けられている。
図８に示す状態は、記事ジャンルとして「総合」ジャンルが選択された状態を示しており、「総合」ジャンルが付された各種記事の中で、主要な記事（例えば投稿日時が新しく、且つ、閲覧数が多い記事）の記事見出しが記事見出し表示欄１１ｂに表示された状態である。即ち、タブ１１ａを切り換えることにより、記事見出し表示欄１１ｂに表示される各記事見出しは、異なる記事ジャンルに属するものへと切り替わる。
各記事見出しは選択操作（例えば、マウスを用いたクリックなどの操作）によって選択することが可能とされている。
【００６１】
記事見出しに対する選択操作がなされると、図７に示すステップＳ２０４の記事詳細ページに関するウェブページデータを要求する要求処理がユーザ端末３によって実行される。
【００６２】
続けて図７の説明を行う。
記事詳細ページに関するウェブページデータ要求を受信した運営サーバ１は、ステップＳ３０７において、記事詳細ページを閲覧したことを記憶する履歴記憶処理を実行し、続くステップＳ３０８において、選択された記事見出しに関する記事詳細ページ（ウェブページデータ）を生成する処理を実行し、次に、ステップＳ３０９において、生成した記事詳細ページデータを送信する処理を実行する。
履歴記憶処理では、選択操作を行ったユーザのユーザＩＤと、ユーザによって選択された記事の記事ＩＤと、閲覧日時（選択された日時）などが紐付けられて、履歴ＤＢ５２に記憶される。
また、記事詳細ページデータを予め生成しておき、ユーザ端末３からの要求に応じて生成済みのウェブページデータを取得してステップＳ３０９において送信するようにしてもよい。
【００６３】
記事詳細ページのウェブページデータを受信したユーザ端末３では、ウェブブラウザ５のウェブページ表示部９において、図９に示す記事詳細ページが表示される。
【００６４】
記事詳細ページには、表示する記事が何れの記事ジャンルに属するのかを示す階層表示部１４と、記事の詳細が表示される記事詳細表示部１５が設けられている。
記事詳細表示部１５には、記事見出し１５ａと記事詳細１５ｂと投稿者１５ｃと投稿日時１５ｄが表示される。
投稿者１５ｃは、記事を投稿した投稿者の投稿者ＩＤであってもよいし、別のニュースサイトのリンク情報であってもよい。
また、記事詳細表示部１５には、更に画像や動画などのコンテンツが表示されてもよい。
更に、記事詳細ページには、表示される記事と関連性の深い他の記事が表示される関連記事表示部が設けられていてもよい。
尚、図９に示す記事詳細ページには、他にも、ユーザ状態表示部１０と、記事概要表示部１１と、広告枠１２が設けられている。
【００６５】
［４−３．運営サーバの処理］
図７に示す一連の処理を実現するために運営サーバ１が実行する処理について、図１０を参照して説明する。
図１０は、運営サーバ１が実行する処理に関するフローチャートである。
運営サーバ１は、ステップＳ４０１，Ｓ４１１，Ｓ４２１，Ｓ４３１，Ｓ４４１を順に実行することにより、各種要求を受信したか否かを継続的に確認する。具体的には、ステップＳ４０１においてログイン情報を受信したか否かを判定する処理を実行し、ステップＳ４１１においてトップページとしてのウェブページデータ要求を受信したか否かを判定する処理を実行し、ステップＳ４２１において記事詳細ページとしてのウェブページデータ要求を受信したか否かを判定する処理を実行し、ステップＳ４３１においてその他のウェブページデータ要求を受信したか否かを判定する処理を実行し、ステップＳ４４１において検索要求を受信したか否かを判定する処理を実行する。
これらの各ステップにおいて情報を受信したと判定した場合は、情報に応じた対応処理を実行し、再び上記の各ステップの判定処理を実行する。
【００６６】
ログイン情報は、ユーザがユーザ端末３を用いてログイン操作を行った場合に、ユーザ端末３から運営サーバ１へ送信される。
ステップＳ４０１において、ログイン情報を受信したと判定した場合、運営サーバ１はステップＳ４０２において認証処理を実行し、ステップＳ４０３において認証結果をユーザ端末３に通知する処理を実行する。即ち、先の図７のステップＳ３０２，Ｓ３０３の処理である。
認証処理においては、ユーザ端末３から送られたログイン情報（例えば、ユーザＩＤとログインパスワード）とユーザＤＢ５０に記憶されたユーザ情報を照合し、ログインの可否を決定する。
【００６７】
ステップＳ４０３の認証結果通知を実行した後、或いは、ステップＳ４０１においてログイン情報を受信していないと判定した後、運営サーバ１はステップＳ４１１においてトップページとしてのウェブページデータ要求を受信したか否かを判定する処理を実行する。
トップページとしてのウェブページデータ要求は、ユーザがユーザ端末３を用いて、運営サーバ１が提供するニュースサイトのトップページを閲覧するための操作を行った場合に、ユーザ端末３から運営サーバ１へ送信される。
【００６８】
ステップＳ４１１において、トップページとしてのウェブページデータ要求を受信したと判定した場合、運営サーバはステップＳ４１２において、トップページの閲覧の履歴を履歴ＤＢ５２に記憶する処理を実行し（先の図７のステップＳ３０４）、続くステップＳ４１３において、トップページデータ（ウェブページデータ）を生成する処理を実行する（先の図７のステップＳ３０５）。トップページデータは、例えば、図８に示すウェブページをユーザ端末３の画面上に表示するためのデータであり、具体的には、ＨＴＭＬやＸＨＴＭＬなどの構造化文書ファイルのデータなどである。
【００６９】
尚、本実施の形態では、ニュースサイトのトップページがユーザごとにカスタマイズされる。そのため、トップページデータ生成処理では、ユーザ情報を用いたウェブページデータの生成処理（即ちユーザ毎に異なるウェブページデータを生成する処理）を実行する。生成処理についての詳細は後述する。
尚、トップページとしてのウェブページデータ自体（即ちＨＴＭＬやＸＨＴＭＬなどの構造化文書ファイル自体）は全てのユーザに対して共通で生成することも可能である。その場合には、例えば、全ユーザ共通のウェブページデータとしてＡＰＩ（Application Programming Interface）を利用可能なプログラムを備えたウェブページデータを生成し、ユーザ端末３の画面上にトップページを表示する際に、ＡＰＩを利用して取得したユーザごとの異なるコンテンツ（例えば記事見出しなど）を配置することも可能である。
【００７０】
続いて、運営サーバ１はステップＳ４１４において、トップページデータを送信する処理を実行する（図７のステップＳ３０６）。トップページデータを送信する処理により、ニュースサイトのトップページデータがユーザ端末３へ送信され、図８に示すトップページが画面上に表示される。
【００７１】
ステップＳ４１４のトップページデータ送信処理を実行した後、或いは、ステップＳ４１１においてトップページとしてのウェブページデータ要求を受信していないと判定した後、運営サーバ１はステップＳ４２１において記事詳細ページとしてのウェブページデータ要求を受信したか否かを判定する処理を実行する。
記事詳細ページとしてのウェブページデータ要求は、ユーザがユーザ端末３を用いて、記事詳細を閲覧するための操作を行った場合（例えば記事見出しをマウスでクリック操作した場合など）に、ユーザ端末３から運営サーバ１へ送信される。
【００７２】
ステップＳ４２１において、記事詳細ページとしてのウェブページデータ要求を受信したと判定した場合、運営サーバはステップＳ４２２において、記事詳細ページの閲覧の履歴を履歴ＤＢ５２に記憶する処理を実行し（先の図７のステップＳ３０７）、続くステップＳ４２３において、記事詳細ページデータ（ウェブページデータ）を生成する処理を実行する（図７のステップＳ３０８）。記事詳細ページデータは、例えば、図９に示すウェブページをユーザ端末３の画面上に表示するためのデータであり、具体的には、ＨＴＭＬやＸＨＴＭＬなどの構造化文書ファイルのデータなどである。
【００７３】
続いて、運営サーバ１はステップＳ４２４において、記事詳細ページデータを送信する処理を実行する（図７のステップＳ３０９）。記事詳細ページデータを送信する処理により、ユーザが選択した記事の詳細ページのウェブページデータがユーザ端末３へ送信され、図９に示す記事詳細ページが画面上に表示される。
【００７４】
ステップＳ４２４の記事詳細ページデータ送信処理を実行した後、或いは、ステップＳ４２１において記事詳細ページとしてのウェブページデータ要求を受信していないと判定した後、運営サーバ１はステップＳ４３１においてその他のウェブページデータ要求を受信したか否かを判定する処理を実行する。
その他のウェブページデータ要求とは、例えば、ログイン画面やユーザ情報変更画面などである。
【００７５】
ステップＳ４３１において、その他のウェブページデータ要求を受信したと判定した場合、運営サーバはステップＳ４３２において、その他のウェブページデータを生成する処理を実行し、続くステップＳ４３３において、その他のウェブページデータを送信する処理を実行する。これにより、ユーザが選択した各種のウェブページがユーザ端末３の画面上に表示される。
尚、ウェブページデータの生成自体は予め実行しておき、ステップＳ４３２では代わりにそれらのウェブページデータを取得する処理を実行してもよい。
【００７６】
ステップＳ４３３のウェブページデータ送信処理を実行した後、或いは、ステップＳ４３１においてその他のウェブページデータ要求を受信していないと判定した後、運営サーバ１はステップＳ４４１において、記事の検索要求を受信したか否かを判定する処理を実行する。尚、検索要求には、ユーザが指定した検索条件が含まれている。
【００７７】
ステップＳ４４１において、検索要求を受信したと判定した場合、運営サーバ１は、続くステップＳ４４２において、記事検索処理を実行する。記事検索処理では、ユーザが指定した検索条件に基づいて記事の検索を行う。
続いて、運営サーバ１はステップＳ４４３において、検索結果の提示処理を実行する。提示処理では、検索結果として抽出した記事を提示するためのウェブページ（例えば検索結果提示ページ）としてのウェブページデータをユーザ端末３へ送信する。
【００７８】
ステップＳ４４３の提示処理を実行した後、或いは、ステップＳ４４１において検索要求を受信していないと判定した後、運営サーバ１はステップＳ４０１の処理を再び実行する。
【００７９】
尚、ステップＳ４０１，Ｓ４１１，Ｓ４２１，Ｓ４３１，Ｓ４４１の各種判定処理の他に、ユーザ情報の変更要求を受信したかどうかを判定する処理などが含まれてもよい。
【００８０】
［４−４．トップページデータ生成処理の第１例］
トップページデータ生成処理の第１例について、図１１を参照して説明する。
運営サーバ１は、先ずステップＳ５０１において、トップページデータを要求したユーザ（以降、ユーザＡとする）のユーザＩＤを取得する。
続いて、運営サーバ１はステップＳ５０２において、ユーザＡについての「頻出キーワード」をキーワードＤＢ５３から取得する。
【００８１】
次に、運営サーバ１はステップＳ５０３において、「頻出キーワード」に基づく記事検索を行う。これにより、ユーザＡの興味があると推測される「頻出キーワード」が含まれる記事が検索結果（抽出記事）として抽出される。ここで、検索結果として記事Ａ及び記事Ｂが抽出されたとする。
更に、運営サーバ１はステップＳ５０４において、ユーザＡの閲覧頻度情報をユーザＤＢ５０から取得する。
【００８２】
続いて、運営サーバ１はステップＳ５０５において、抽出された検索結果としての各記事が「埋没候補記事」であるか否かの判定を行う。
例えば、検索結果として記事Ａと記事Ｂと記事Ｃが抽出されたとする。更に、記事Ａには、「記事ジャンルＫ」が紐付けられ、記事Ｂには、「記事ジャンルＬ」が紐付けられ、記事Ｃには「記事ジャンルＭ」が紐付けられているとする。そして、「記事ジャンルＫ」の閲覧可能性は１０％（即ち「記事ジャンルＫ」に属する記事のうち１０％の記事をユーザＡが平均的に閲覧している状態）、「記事ジャンルＬ」の閲覧可能性は２０％、「記事ジャンルＭ」の閲覧可能性は４０％とする。
このとき、記事Ｃよりも記事Ｂ、記事Ｂよりも記事Ａの方が閲覧される可能性が低いと推測される。また、閲覧可能性が３０％以下の記事ジャンルが「低閲覧頻度記事ジャンル」とすると、記事Ａ、記事Ｂは「低閲覧頻度記事ジャンル」に属する「埋没候補記事」とされる。
【００８３】
尚、各記事には複数の記事ジャンルが紐付けられることもある。その場合には、それぞれのジャンルの閲覧頻度を加味した上で、各記事の閲覧可能性を加味して提示優先度を付与することが望ましい。
例えば、記事Ｄに「記事ジャンルＫ」と「記事ジャンルＮ」が紐付けられ、記事Ｅに「記事ジャンルＬ」と「記事ジャンルＮ」が紐付けられ、「記事ジャンルＫ」の閲覧可能性が１０％、「記事ジャンルＬ」の閲覧可能性は２０％、「記事ジャンルＮ」の閲覧可能性が２０％である場合、記事Ｄ（閲覧可能性＝１００−０．９×０．８×１００＝２８％）は記事Ｅ（１００−０．８×０．８×１００＝３６％）よりも閲覧される可能性が低いと推測される。
また、記事Ｄは閲覧可能性が３０％以下であることから、「低閲覧頻度記事ジャンル」に属する記事に相当すると考えられる。一方、記事Ｅは閲覧可能性が３０％以上であることから、「低閲覧頻度記事ジャンル」に属する記事に相当しない。
よって、この場合には、記事Ｄは「埋没候補記事」とされ、記事Ｅは「埋没候補記事」とされない。
尚、３０％という数値はあくまで一例である。
【００８４】
次に、運営サーバ１はステップＳ５０６において、各「埋没候補記事」に対する提示優先度の付与を行う。
例えば、「埋没候補記事」の提示優先度は、上述した閲覧可能性の高低に基づいてもよい。即ち、先の記事Ａと記事Ｂと記事Ｃの場合、記事Ａと記事Ｂは共に「埋没候補記事」とされるが、閲覧可能性の低い記事Ａに対してより高い提示優先度を付与する。
【００８５】
また、閲覧頻度だけでなく、記事に含まれる「頻出キーワード」の数や種類数に応じて提示優先度を更に調整してもよい。
即ち、「頻出キーワード」の数が多い、或いは、複数種の「頻出キーワード」が含まれる記事は、ユーザの興味が高い記事と推測されるためである。
例えば、閲覧頻度は「埋没候補記事」を抽出するためだけに用い（即ち提示優先度には無関係とする）、「頻出キーワード」の数（或いは種類数）に応じて提示優先度を付与してもよい。
また、それ以外にも、投稿からの経過時間も加味した提示優先度付与を行うことも望ましい。即ち、投稿から数年経ってしまった記事をユーザに優先的に提示しても、ユーザにとって有意義な記事となる可能性は低くなるためである。
【００８６】
更にまた、「埋没候補記事」が属する記事ジャンルが複数ある場合、各記事ジャンルに属する「埋没候補記事」の数に応じて提示優先度を決めてもよい。
即ち、１個の「埋没候補記事」が属する記事ジャンルＡと、１０個の「埋没候補記事」が属する記事ジャンルＢがある場合、記事ジャンルＡに属する「埋没候補記事」の提示優先度を上げてもよい。埋没候補記事が少ない記事ジャンルの場合、例えタブを当該タブに切り替えたとしてもユーザが見過ごす可能性が高く、逆に埋没候補記事が多い記事ジャンルの場合、タブを当該タブに切り替えた場合にユーザが気付く可能性が高いためである。
また、埋没候補記事が多い記事ジャンルＢに属する「埋没候補記事」の提示優先度を上げることも考えられる。
記事ジャンルＢに属する「埋没候補記事」をユーザが閲覧した場合、同じ記事ジャンルＢに属する他の「埋没候補記事」をユーザが効率よく閲覧することができるためである。
【００８７】
他にも、「頻出キーワード」が記事見出しに含まれるか否かを考慮して提示優先度を決めてもよい。
例えば、「頻出キーワード」が記事見出しに含まれる「埋没候補記事」の提示優先度を上げることが考えられる。この場合、図８に示すトップページが表示され記事見出し表示欄１１ｂに当該「埋没候補記事」が提示されたときに、ユーザＡの興味が高いと推測される「頻出キーワード」が視認可能とされるため、記事の見逃しを抑制することができる。また、記事見出しに「頻出キーワード」が含まれている「埋没候補記事」は「頻出キーワード」に関する話題を主題としている可能性が高いため、ユーザＡの興味が高い記事である可能性も高くなる。そのような記事の見逃しを抑制することが可能なニュースサイトは、ユーザＡにとっても非常に使い勝手がよいと考えられる。
【００８８】
逆に、「頻出キーワード」が記事見出しに含まれず記事詳細のみに含まれる「埋没候補記事」の提示優先度を上げることも考えられる。このような「埋没候補記事」は、記事見出しを見ただけではユーザＡが興味を引かれない可能性が高い。
そのような「埋没候補記事」が図８に示すような「お勧め」タブに配置されることによって、ユーザＡが当該「埋没候補記事」を見逃す可能性を低減することができる。
【００８９】
続いて、運営サーバ１はステップＳ５０７において、トップページデータを生成する処理を実行する。この処理では、例えば図８に示すトップページについてのウェブページデータを生成する。また、このとき、先の「埋没候補記事」をユーザＡが見逃し難くするために、例えば図８に示す「お勧め」タブに属する記事として提示する。
【００９０】
尚、前述したように、ＡＰＩ等によってユーザにカスタマイズした記事情報を取得するようにトップページを構成した場合、例えば、「お勧め」タブに属する記事を取得するＡＰＩが実行されたときに、図１１のステップＳ５０１乃至Ｓ５０６が実行されて、提示優先度を付与された「埋没候補記事」が抽出されて、ユーザ端末３に送信される。
提示優先度を付与された「埋没候補記事」の情報を受信したユーザ端末３は、それらの情報を「お勧め」タブに表示する制御を行う。
【００９１】
［４−５．トップページデータ生成処理の第２例］
トップページデータ生成処理の第２例について、図１２を参照して説明する。
第２例では、ユーザの興味を推測するための情報として「頻出キーワード」だけでなく「頻出キーワード」に類似した「類似キーワード」も利用する。
尚、第１例で説明した処理と同様の処理については、同一の符号を付し、適宜説明を省略する。
【００９２】
先ず、運営サーバ１はステップＳ５０１を実行することによってユーザＡのユーザＩＤを取得し、続くＳ５０２を実行することによってユーザＡについての「頻出キーワード」をキーワードＤＢ５３から取得する。
【００９３】
続いて、運営サーバ１はステップＳ５０８において、「類似キーワード」を類似キーワードＤＢ５４から取得する処理を実行する。
次に、運営サーバ１はステップＳ５０３において、「頻出キーワード」と「類似キーワード」に基づく記事検索を行う。
更に、運営サーバ１はステップＳ５０４において、ユーザＡの閲覧頻度情報をユーザＤＢ５０から取得する。
【００９４】
続いて運営サーバ１は、ステップＳ５０５において検索結果として抽出された記事それぞれに対して「埋没候補記事」であるか否かを判定する処理を実行し、「埋没候補記事」として判定された記事に対してステップＳ５０６で提示優先度を付与する処理を実行する。
提示優先度の付与に関しては、先の第１例において「頻出キーワード」を利用した例を説明した。即ち、記事に含まれる「頻出キーワード」の数や種類数によって提示優先度を付与する例や、「頻出キーワード」が記事見出しに含まれるか否かによって提示優先度を付与する例である。第２例では、「頻出キーワード」に加えて「類似キーワード」を利用する例である。そのため、「類似キーワード」も含めたキーワードの数や種類数を考慮して提示優先度を付与することや、「類似キーワード」が記事見出しに含まれるか否かを考慮して提示優先度を付与することが望ましい。
【００９５】
また、提示優先度の付与には、「頻出キーワード」と「類似キーワード」の違いを考慮してもよい。例えば、「頻出キーワード」を一つ含む記事Ａと「類似キーワード」を一つ含む記事Ｂとでは、記事Ａに対してより高い提示優先度を付与してもよい。
【００９６】
「埋没候補記事」に提示優先度を付与した運営サーバ１は、続くステップＳ５０７において、トップページデータを生成する処理を実行する。
【００９７】
［４−６．トップページデータ生成処理の第３例］
トップページデータ生成処理の第３例について、図１３を参照して説明する。
第３例では、必要に応じて「類似キーワード」を取得する。
尚、第１例及び第２例で説明した処理と同様の処理については、同一の符号を付し、適宜説明を省略する。
【００９８】
具体的に、先ず、運営サーバ１はステップＳ５０１及びＳ５０２を実行することにより、ユーザＩＤと当該ユーザＡについての「頻出キーワード」を取得する。
続いて、運営サーバ１は、ステップＳ５０３において「頻出キーワード」に基づく記事検索処理を行い、ステップＳ５０４において閲覧頻度情報を取得し、ステップＳ５０５において検索結果として抽出された各記事が埋没候補記事であるか否かを判定する処理を実行する。
ステップＳ５０１乃至Ｓ５０５の各処理は、図１１に示す各処理と同様の処理である。
【００９９】
続いて、運営サーバ１はステップＳ５０９において、「埋没候補記事」と判定された記事数が所定数（例えば１０個）以上であるか否かを判定する処理を実行する。
「埋没候補記事」の記事数が十分であると判定した場合には、ステップＳ５０６の提示優先度付与処理に遷移する。
一方、「埋没候補記事」の記事数が十分でないと判定した場合、運営サーバ１はステップＳ５０８の処理を実行し、類似キーワードを取得する。
更に、運営サーバ１はステップＳ５０３において、「類似キーワード」を含む記事検索処理を実行し、ステップＳ５０５においてそれらの新たに検索された記事に対して「埋没候補記事」であるか否かを判定する処理を実行する。
【０１００】
続いて、運営サーバ１はステップＳ５０６において、「埋没候補記事」ごとに提示優先度を付与する処理を実行し、ステップＳ５０７において「埋没候補記事」の情報を含むトップページデータの生成を行う。
【０１０１】
［４−７．トップページデータ生成処理の第４例］
トップページデータ生成処理の第４例について、図１４，図１５を参照して説明する。
第４例では、図８のトップページに示したような「埋没候補記事」が集約された「お勧め」タブを設けない場合について説明する。
尚、第１例乃至第３例で説明した処理と同様の処理については、同一の符号を付し、適宜説明を省略する。
【０１０２】
先ず、運営サーバ１は図１４のステップＳ５０１乃至Ｓ５０６の処理を行い、ユーザＡについての「頻出キーワード」に基づく記事検索を行い、「埋没候補記事」を抽出し、「埋没候補記事」ごとの提示優先度を付与する。ここまでの処理は、図１１各処理と同様の処理である。
【０１０３】
続いて、運営サーバ１はステップＳ５１０において、初期表示ジャンルを決定する処理を実行する。この処理は、ユーザ端末３上でニュースサイトのトップページが表示されたときに、何れのタブを初期表示するかを選択する処理である。
初期表示ジャンルとしては、ユーザＡの閲覧頻度の高い記事ジャンルではなく、「低閲覧頻度記事ジャンル」（即ち「埋没候補記事」が存在する記事ジャンル）を選択する。
例えば、「スポーツ」ジャンルを頻繁に閲覧するユーザＡにとっての「低閲覧頻度記事ジャンル」にあたる「政治」ジャンルが初期表示ジャンルとして選択される。
この場合、図１５に示すように、記事見出し表示欄１１ｂに「政治」ジャンルに属する記事の記事見出しが表示される。
【０１０４】
初期表示ジャンルの選択においては、例えば、「埋没候補記事」の個数に基づくことが考えられる。即ち、「埋没候補記事」が多い記事ジャンルが初期表示ジャンルとして選択される。
また、「埋没候補記事」の中で、最も提示優先度が高いものが属する記事ジャンルを初期表示ジャンルとして選択することが考えられる。
それ以外にも、「埋没候補記事」の中で投稿日時が最も新しいものが属する記事ジャンルを初期表示ジャンルとしてもよい。
【０１０５】
初期表示ジャンルとして選択された「政治」ジャンルに属する記事の各記事見出しは、先のステップＳ５０６において付与された提示優先度に応じて記事見出し表示欄１１ｂに配置される。
「埋没候補記事」のみが表示される状態（即ち「埋没候補記事」の個数が十分にある状態）であれば、提示優先度の高い記事の記事見出しほど上部に配置される。
また、「埋没候補記事」の多少に関わらず「埋没候補記事」とそれ以外の記事が混在する状態であれば、先のステップＳ５０６において「埋没候補記事」以外の記事についても、提示優先度を付与しておくことが考えられる。この場合、「埋没候補記事」とそれ以外の記事が混在する状態においても、提示優先度という一つの指標に基づいて記事見出し表示欄１１ｂへの各記事の配置が容易となる。
【０１０６】
他にも、「埋没候補記事」の記事見出しに「頻出キーワード」や「類似キーワード」が含まれるか否かを考慮して初期表示ジャンルを決定してもよい。
【０１０７】
尚、「埋没候補記事」とそれ以外の記事が混在する状態においては、「埋没候補記事」を提示優先度に応じて記事見出し表示欄１１ｂの上部に配置し、「埋没候補記事」以外の記事を記事見出し表示欄１１ｂの下部に配置してもよい。
これにより、ユーザＡの興味が高いと推測される「埋没候補記事」が上部に配置されるため、ユーザの「埋没候補記事」の見落としを抑制することができる。
【０１０８】
図１４の説明に戻る。
ステップＳ５１０において初期表示ジャンルを決定した運営サーバ１は、続くステップＳ５０７において、ニュースサイトのトップページデータ（ウェブページデータ）を生成する処理を実行する。
このトップページデータは、初期表示ジャンルとして決定した記事ジャンルに応じたタブが選択された状態でユーザ端末３上に提示されるように生成される。
【０１０９】
尚、トップページに表示される各タブの並び順を入れ替え、初期表示ジャンルとして決定した記事ジャンルのタブを最左端のタブとしてもよい。
ウェブページは上から下に向かって、そして、左から右に向かって閲覧する癖をユーザは持っている可能性が高い。そのため、最左端のタブに初期表示ジャンルに該当するタブを移動することにより、ユーザが閲覧する可能性をより高めることができる。
【０１１０】
＜５．まとめ＞
上記の各例で説明してきたように、運営サーバ１は、ユーザの閲覧履歴にある記事に出現する頻度の高い「頻出キーワード」を特定する頻出キーワード特定部１ａと、頻出キーワードが出現する記事を抽出記事として抽出する記事抽出部１ｃと、ユーザの閲覧頻度を記事ジャンルごとに算出する閲覧頻度算出部１ｄと、抽出記事のうちで閲覧頻度の低い「低閲覧頻度記事ジャンル」に属する記事を「埋没候補記事」として選択し、優先的な提示処理を行う提示制御部１ｅと、を備えている。
本来なら、ユーザの閲覧頻度が低い記事ジャンルに属する記事は、記事の内容によらず未閲覧のままであることが多い。
ところが、本構成によれば、閲覧頻度が低い記事ジャンルに属する記事の中で、ユーザが興味を抱く可能性の高い「頻出キーワード」が含まれている記事（「埋没候補記事」）に関しては、優先的にユーザに提示される。
これにより、様々な記事ジャンルにユーザを導くことが可能となるため、ニュースサイトにおけるユーザの回遊性を高めることができる。
また、「埋没候補記事」をよりユーザの目に触れやすくすることができ、ユーザの記事の見落としを防止し、延いてはユーザにとって興味のある知識の蓄積に貢献することができる。
更に、ユーザが所定の知識を獲得するまでに要する記事検索時間や通信量を削減することができるため、情報処理装置が使用する通信帯域や処理時間を削減することができる。
加えて、領域の限られたユーザ端末３の画面上などにおいて、ユーザが閲覧したいと考える記事を効率的に提示することは、ユーザが時間を効率よく活用できるだけでなく、余分なウェブページデータを要求する処理などが省かれるため、通信帯域の有効利用や運営サーバ１（更にはユーザ端末３）のハードウェア資源の有効的な利用にも繋がる。
【０１１１】
また、トップページデータ生成処理の第２例や第３例で説明したように、記事抽出部１ｃは、抽出記事を抽出する際に「頻出キーワード」と類似するキーワード（類似キーワード）を含む記事についても抽出記事として抽出する。
これにより、「頻出キーワード」だけでなく、ユーザが興味を持つと推測される「類似キーワード」を含む記事についての抽出される。
従って、更に広い範囲の記事ジャンルから「埋没候補記事」が抽出される可能性が高まり、ユーザの興味が高い記事の見落としを抑制すると共に、ニュースサイト上におけるユーザの回遊性の向上を更に向上させることができる。
【０１１２】
更にまた、トップページデータ生成処理の第１例で説明したように、提示制御部１ｅは、「低閲覧頻度記事ジャンル」が複数ある場合に、「埋没候補記事」の数が少ない「低閲覧頻度記事ジャンル」に属する「埋没候補記事」の提示優先度を上げて提示する。
これにより、ユーザにとってより目に付かない低閲覧頻度記事ジャンルに属する埋没候補記事に高い提示優先度が付与されて提示される。即ち、閲覧する可能性の低い記事が優先度を高くされて提示される。
従って、ユーザのニュースサイト上における回遊性を一層向上させることができる。更には、上述したように、通信帯域やハードウェア資源の有効利用を促進することができる。
【０１１３】
そして、トップページデータ生成処理の第１例で説明したように、提示制御部１ｅは、記事の概要を表す記事見出しに「頻出キーワード」を含む「埋没候補記事」の提示優先度を上げて提示する。
これにより、ユーザが記事見出し中に自身の興味のあるキーワード（頻出キーワード）を視認できる「埋没候補記事」が優先的に提示される。
従って、ユーザが当該記事を選択して記事詳細を閲覧する可能性が高くなり、ユーザの知識獲得の効率を向上させることができる。
更には、上述したように、通信帯域やハードウェア資源の有効利用を促進することができる。
【０１１４】
加えて、トップページデータ生成処理の第１例で説明したように、提示制御部１ｅは、記事の概要を表す記事見出しに「頻出キーワード」を含まない「埋没候補記事」の提示優先度を上げて提示する。
これにより、ユーザが自力で発見できないような「埋没候補記事」が優先的に提示される。
従って、ユーザの興味のある記事の見逃しを回避することができ、ユーザの知識獲得に貢献することができる。
更には、上述したように、通信帯域やハードウェア資源の有効利用を促進することができる。
【０１１５】
また、トップページデータ生成処理の第４例で説明したように、提示制御部１ｅは、「埋没候補記事」が属する記事ジャンルを初期表示ジャンルとして設定する。
これにより、ユーザが自力で発見できないような埋没候補記事が初期表示される。
従って、ユーザの興味のある記事を見逃してしまうことをより回避することができる。
また、普段閲覧しないような記事をユーザが閲覧することにより、ウェブサイト上におけるユーザの回遊性を向上させることができる。
【０１１６】
尚、本実施の形態ではニュースサイトのトップページにおいて記事見出しを各タブに表示する例を示したが、記事見出しを備えない記事を表示する場合も考え得る。その場合には、例えば、記事詳細の冒頭の所定文字を記事見出しの代わりとして表示してもよい。
【０１１７】
尚、上記では、記事として文字情報で構成されたニュース記事等を例に挙げたが、これ以外のコンテンツであってもよい。即ち、動画を含むコンテンツが上述した記事とされていてもよいし、書籍などのコンテンツが上述した記事の代わりとされていてもよい。
他にも、コンテンツの例として、レビューやブログ、レシピなどが挙げられる。
【０１１８】
＜６．プログラム及び記憶媒体＞
以上、本発明の情報処理装置の実施の形態としての運営サーバ１を説明してきたが、実施の形態のプログラムは、運営サーバ１の各種処理を情報処理装置（ＣＰＵなど）に実行させるプログラムである。
【０１１９】
実施の形態のプログラムは、ユーザの閲覧履歴にある記事に出現する頻度の高い「頻出キーワード」を特定する頻出キーワード特定機能を情報処理装置に実行させる。
また、「頻出キーワード」が出現する記事を抽出記事として抽出する記事抽出機能を情報処理装置に実行させる。
更に、ユーザの閲覧頻度を記事ジャンルごとに算出する閲覧頻度算出機能を情報処理装置に実行させる。
更にまた、抽出記事のうちで前記閲覧頻度の低い「低閲覧頻度記事ジャンル」に属する記事を「埋没候補記事」として選択し、優先的な提示処理を行う提示制御機能を情報処理装置に実行させる。
即ちこのプログラムは、運営サーバ１に対して図６，図１０〜図１４の各処理、図７のステップＳ３０１乃至Ｓ３０９の各処理を実行させるプログラムである。
【０１２０】
このようなプログラムにより、上述した運営サーバ１としての情報処理装置を実現できる。
そしてこのようなプログラムはコンピュータ装置などの機器に内蔵されている記録媒体としてのＨＤＤや、ＣＰＵを有するマイクロコンピュータ内のＲＯＭなどに予め記録しておくことができる。或いはまた、半導体メモリ、メモリカード、光ディスク、光磁気ディスク、磁気ディスクなどのリムーバブル記録媒体に、一時的或いは永続的に格納（記録）しておくことができる。またこのようなリムーバブル記録媒体は、いわゆるパッケージソフトウェアとして提供することができる。
また、このようなプログラムは、リムーバブル記録媒体からパーソナルコンピュータなどにインストールする他、ダウンロードサイトから、ＬＡＮ、インターネットなどのネットワークを介してダウンロードすることもできる。
【０１２１】
また、本実施の形態においては、タブの一例として「総合」、「政治」、「経済」、「スポーツ」、「芸能」などを挙げたが、タブは記事を分類する項目であれば、どのような基準による分類項目であるかは特に限定されるものではない。例えば記事に関連する場所に応じた「国内」、「国際」、「地域」などのタブが挙げられる。或いは記事が本のレビューであれば、その本のジャンルに応じたタブや、筆者、出版社などのタブが挙げられる。
【０１２２】
最後に、上述した各実施の形態の説明は本発明の一例であり、本発明は上述の実施の形態に限定されることはない。このため、上述した各実施の形態以外であっても、本発明に係る技術的思想を逸脱しない範囲であれば、設計などに応じて種々の変更が可能であることはもちろんである。
【符号の説明】
【０１２３】
１  運営サーバ、１ａ  頻出キーワード特定部、１ｂ  類似キーワード取得部、１ｃ  記事抽出部、１ｄ  閲覧頻度算出部、１ｅ  提示制御部、２  通信ネットワーク、３  ユーザ端末、４  投稿者端末、５０  ユーザＤＢ、５１  記事ＤＢ、５２  履歴ＤＢ、５３  キーワードＤＢ、５４  類似キーワードＤＢ
【図１】
2018029810.tif 000003
【図２】
2018029810.tif 000004
【図３】
2018029810.tif 000005
【図４】
2018029810.tif 000006
【図５】
2018029810.tif 000007
【図６】
2018029810.tif 000008
【図７】
2018029810.tif 000009
【図８】
2018029810.tif 000010
【図９】
2018029810.tif 000011
【図１０】
2018029810.tif 000012
【図１１】
2018029810.tif 000013
【図１２】
2018029810.tif 000014
【図１３】
2018029810.tif 000015
【図１４】
2018029810.tif 000016
【図１５】
2018029810.tif 000017
【国際調査報告】
2018029810.tif 000018
2018029810.tif 000019