JP5482842B2 - 情報処理装置およびその制御プログラム - Google Patents

Description

本発明は、コンテンツ情報を表示するための情報処理装置およびそのプログラムに関する。

従来から、ＬＡＮ（Local Area Network）やＷＡＮ（Wide Area Network）、インターネットなど、通信ネットワークにおけるサーバ・クライアント・システムでは、クライアント装置が備えるＷｅｂブラウザにより、サーバ装置が生成保存している種々のＷｅｂコンテンツを取得表示して閲覧することが行われる。

一般に、Ｗｅｂコンテンツは、ＨＴＭＬ（Hyper Text Markup Language）により記述されており、そのドキュメント構造をＷｅｂブラウザが解析してＷｅｂページとして表示するものである。

近年、様々なデバイスの発展により、携帯端末やデジタル家電など、ＰＣ（Personal Computer）以外の端末でＷｅｂコンテンツを閲覧する機会が増えている。しかしながら、既存のＷｅｂコンテンツは大多数がＰＣ向けである。このようなＰＣ向けのＷｅｂコンテンツを、前記ＰＣ以外の端末でも快適に閲覧できることが望まれるが、画面サイズ・解像度の違いや入力手段が貧弱であることなど端末形状等の物理的制限に起因し、ＰＣにおけるマウス主体の閲覧環境と同等の操作性・効率性を得るのは難しい。

そこで、Ｗｅｂコンテンツを解析し、当該Ｗｅｂコンテンツ内のリンクだけを抜き出したリストを、コンテンツ本体と別途独立表示することで、携帯端末などにおいても、リンク先へのアクセス性を改善できる情報表示装置が考えられている（例えば、特許文献１参照。）。

特開２００６−１１５３６号公報

前記従来の情報表示装置では、例えばＷｅｂコンテンツ全体を一画面上に表示できなくても、当該コンテンツ内に存在するリンクへのアクセス性を改善できるものの、Ｗｅｂコンテンツ全体の閲覧に伴う手間の削減に寄与するものではない。また、最近のＷｅｂコンテンツのように、広告リンク等の不要な多数のリンクがある場合には、リンクのリストが膨大になり、特に、携帯端末の小画面では、当該リンクリスト用に独立表示のためのスペースをコンテンツ本体の邪魔にならないよう設けるのは難しく、と同時にリンクへのアクセス性も悪化してしまう。

また、携帯端末で快適にＷｅｂコンテンツ全体を閲覧するための手段として、Ｏｐｅｒａ（登録商標）を初めとした携帯電話用フルブラウザでは、Ｗｅｂコンテンツ上のカラムを縦に並べるモードを提供しているものが多い。このモードでは、コンテンツが必ず画面の横幅に納まり、コンテンツが分断されるストレスはなくなるが、必要な縦スクロール量が増え、一覧性の制限による問題を根本的に解決するものではない。

他に、ＮｅｔＦｒｏｎｔ（登録商標）Ｂｒｏｗｓｅｒ等のスマートフォン用ブラウザでは、ＰＣと同じレイアウトで表示し、優れたズーム機能で一覧性の制限を補おうとする流れもある。

しかし、一旦文字等が見易い大きさまでズームしてしまえば、周りのコンテンツが把握できなくなるのは同じである。一覧性を確保するためには大幅に縮小する必要があるが、その状態では文字が読めず、それが本当に自分の興味ある情報であるかはズームしてみないと確認出来ない。

結果として、ユーザはまた当てずっぽうでズームしたり戻ったりを繰り返すことになる。

本発明は、受信したコンテンツの閲覧の利便性を高めることが可能な情報処理装置を提供することを目的とする。

請求項1は、コンテンツ情報を表示画面上に表示する情報処理装置であって、ネットワークを介してコンテンツ情報を受信する受信手段と、前記受信手段により今回受信したコンテンツ情報の内で新規に更新された部分を抜き出す抜出手段と、前記受信手段で受信した前記コンテンツ情報を前記表示画面上に表示する際は、その表示画面の中で前記コンテンツ情報を表示する表示領域の大きさを所定閾値と比較し、その比較結果に基づいて、前記コンテンツ情報を要約のないオリジナルのコンテンツ情報としてそのまま表示するか、あるいは当該コンテンツ情報のオリジナルを表示することはせずに前記抜出手段で抜き出された部分の部分コンテンツ情報を前記オリジナルのコンテンツ情報の表示に代わって表示するか、を制御する表示制御手段と、を備えたことを特徴としている。

本発明によれば、コンテンツの内で新規に更新された部分の内容を直ちに確認することができる。

図１は、本発明の情報処理装置の一実施形態に係るサーバ・クライアント・システムの構成を示すブロック図である。 図２は、前記サーバ・クライアント・システムにおけるサーバ装置の回路構成を示すブロック図である。 図３は、前記サーバ・クライアント・システムにおけるクライアント装置の回路構成を示すブロック図である。 図４は、前記クライアント装置においてサーバ装置から取得されたＷｅｂコンテンツの例を示す図である。 図５は、前記クライアント装置における図４に示すＷｅｂコンテンツの一般的なＷｅｂブラウザプログラムでの表示状態を示す図である。 図６は、Ｗｅｂコンテンツのプレビュー用要約コンテンツに使うカラム要約の種類及びプレビュー用要約コンテンツをユーザに提示するためのプレビュー用ＵＩの種類を示す図である。 図７は、「テキスト強度別切り出し」によるカラム要約生成方法により、図４のＷｅｂコンテンツ内のカラムを要約した例を示す図である。 図８は、図４のＷｅｂコンテンツに紐付けられたＲＳＳのソースの例を示す図である。 図９は、「更新部分抜き出し」によるカラム要約の生成方法により、図４のＷｅｂコンテンツ内のカラムを要約した例を示す図である。 図１０は、プレビュー用ＵＩとして「フォント縮小」ＵＩを適用した画面遷移の例を示す図である。 図１１は、プレビュー用ＵＩとして「サムネイル縮小」ＵＩを適用した画面遷移の例を示す図である。 図１２は、プレビュー用ＵＩとして「自動スクロール」ＵＩを適用した画面の例を示す図である。 図１３は、プレビュー用ＵＩとして「バルーン」ＵＩを適用した画面の例を示す図である。 図１４（Ａ）は、前記クライアント装置におけるＷｅｂブラウザプログラムのメインフローチャートであり、図１４（Ｂ）は、図１４（Ａ）中のカラムのプレビュー化処理の詳細を示すフローチャートである。 図１５は、「テキスト強度別切り出し」によりプレビュー用要約コンテンツを生成する場合のカラム要約処理のフローチャートである。 図１６は、背景強度ポイントの算出を説明するため、カラムの中の背景ごとの文字数を集計した結果の一例を示す図である。 図１７は、行ごとのテキスト強度の一例を示す図である。 図１８は、「更新部分抜き出し」によりプレビュー用要約コンテンツを生成する場合のカラム要約処理のフローチャートである。

以下、本発明を実施するための形態を図面を参照して説明する。

図１は、本発明の情報処理装置の一実施形態に係るサーバ・クライアント・システムの構成を示すブロック図である。

このサーバ・クライアント・システムは、インターネット、ＷＡＮ、ＬＡＮなどからなるネットワークＮ上にそれぞれ接続されたサーバ装置１０と複数のクライアント装置２０とを備える。

サーバ装置１０は、Ｗｅｂコンテンツ生成処理プログラム，登録ユーザ管理処理プログラム，Ｗｅｂページ配信処理プログラムなど、当該サーバ装置１０の本体操作により機能する複数のアプリケーションプログラムを有し、例えば本サーバ装置１０にユーザ登録されたクライアント装置２０からの指定のＷｅｂサイトへのアクセス要求に応じて当該要求されたＷｅｂサイトにおけるＷｅｂコンテンツ１５ａのページを各クライアント装置２０へ配信する。

クライアント装置２０は、携帯電話，ＰＤＡ（Personal Digital Assistant），ＰＣなどからなり、インターネット接続処理プログラム、Ｗｅｂブラウザプログラム２３ａ，Ｗｅｂ印刷プログラムなど、当該クライアント装置２０の本体操作により機能する複数のアプリケーションプログラムを有する。そして、例えば所望のＷｅｂサイトのサーバ装置１０にアクセスしてそのＷｅｂコンテンツ１５ａを取得し、当該Ｗｅｂコンテンツ１５ａのＨＴＭＬ（Hyper Text Markup Language）を解析してカラムに分割し、その単位で要約を生成して、表示面積に従ったプレビュー用の表示形態に適応させて表示する。

なお、サーバ装置１０から受信したＷｅｂコンテンツを扱う処理を、中間サーバなどに担わせても良い。例えば、ＰｒｏｘｙサーバなどＷｅｂコンテンツを中継するサーバや、クライアント装置２０とつながるその他外部サーバ上でＷｅｂコンテンツのカラム要約をして、クライアント装置２０に渡すようにしても構わない。

図２は、前記サーバ・クライアント・システムにおけるサーバ装置１０の回路構成を示すブロック図である。

サーバ装置１０は、コンピュータとしてのＣＰＵ１１を備え、このＣＰＵ１１には、バス１２を介してＲＯＭ１３、フレームバッファＲＡＭ１４、外付けハードディスクなどの外部記憶装置１５が接続される。

また、ＣＰＵ１１には、バス１２を介してキーボード，マウスなどの入力装置１６、ＬＣＤ（Liquid Crystal Display）などの表示装置１７、前記クライアント装置２０との通信Ｉ／Ｆ（インターフェイス）１８が接続される。

ＣＰＵ１１は、ＲＯＭ１３に予め記憶されているシステムプログラムや種々のアプリケーションプログラムに従ってフレームバッファＲＡＭ１４を作業用メモリとし回路各部の動作を制御するもので、入力装置１６からのキー入力信号や通信Ｉ／Ｆ１８を介して受信されるクライアント装置２０からのユーザ操作に応じたＷｅｂコンテンツ取得要求信号などに応じて前記種々のプログラムが起動・実行される。

前記Ｗｅｂコンテンツ１５ａは、例えば外部記憶装置１５に適宜更新生成されて記憶されている。

図３は、前記サーバ・クライアント・システムにおけるクライアント装置２０の回路構成を示すブロック図である。

クライアント装置２０は、コンピュータとしてのＣＰＵ２１を備え、このＣＰＵ２１には、バス２２を介してＲＯＭ２３、ＲＡＭ２４、メモリカードや光ディスク読み書き部などの外部記憶装置２５が接続される。

また、ＣＰＵ２１には、バス２２を介してキーボード，マウスなどの入力装置２６、ＬＣＤからなる表示装置２７、前記サーバ装置１０との通信Ｉ／Ｆ（インターフェイス）２８が接続される。

ＣＰＵ２１は、ＲＯＭ２３に予め記憶されているシステムプログラムおよび種々のアプリケーションプログラムに従ってＲＡＭ２４を作業用メモリとし回路各部の動作を制御するもので、入力装置２６からの入力信号に応じて前記種々のアプリケーションプログラムが起動され実行される。

前記サーバ装置１０をインターネット（Ｎ）上のＷｅｂサイト、前記クライアント装置２０を前記Ｗｅｂサイトにアクセス可能なユーザ端末とした場合、ユーザ端末（２０）からＷｅｂサイト（１０）へのアクセス要求に応じて、当該Ｗｅｂサイト（１０）においてＨＴＭＬにより記述生成されたＷｅｂコンテンツ１５ａがアクセス要求元のユーザ端末（２０）へ配信され、そのＷｅｂブラウザプログラム２３ａによりＷｅｂページに展開されて表示装置２７に表示される。

このクライアント装置（ユーザ端末）２０のＷｅｂブラウザプログラム２３ａは、ユーザ指定のＷｅｂサイトのサーバ装置１０へのアクセスに伴い、そのＷｅｂコンテンツ１５ａを取得し、当該Ｗｅｂコンテンツ１５ａのＨＴＭＬを解析してカラム（詳細は後述する）に分割し、その単位で要約を生成して、表示面積に従ったプレビュー用の表示形態に適応させてプレビュー表示する、カラムプレビュー制御機能を有する。このカラムプレビュー制御機能は、例えば前記Ｗｅｂブラウザプログラム２３ａにプラグインあるいはアドオンするプログラムにより実現される。

以下、前記クライアント装置２０のＷｅｂブラウザプログラム２３ａにおける前記カラムプレビュー制御機能を詳細に説明する。
図４は、前記クライアント装置２０においてサーバ装置１０から取得されたＷｅｂコンテンツ１５ａの例を示す図である。

Ｗｅｂコンテンツは、数種類の異なる種類の情報を持った部分（ヘッダ／フッタ，記事本文，ユーザをリンク誘導するための部分，等）から成るのが一般的であり、この区切られた部分をカラムと呼ぶ。図４に例示したＷｅｂコンテンツ１５ａでは、カラムＣ１〜カラムＣ５の５つのカラムを有している。

なお、クライアント装置２０のＷｅｂブラウザプログラム２３ａでのカラムの抽出、分割の処理については、Ｏｐｅｒａ（登録商標）等の携帯電話用フルブラウザで採用されている手法等、既存の何れかの手法を用いて実施することができるので、ここではその説明は省略する。

図５は、図４に示すようなＷｅｂコンテンツ１５ａを、一般的なＷｅｂブラウザプログラムにより表示装置２７で表示した場合の表示を示す図である。

表示装置２７で表示可能なブラウザウィンドウの表示範囲２７ａは、Ｗｅｂコンテンツ１５ａの一部分しかカバーできず、ここでは、カラムＣ２，Ｃ３，Ｃ４の各一部分を表示している。この場合、カラムＣ２は広い部分が表示されており、横部分が多少切れているとはいえ、どういう内容のカラムかは特にスクロールしなくても判別できる。これに対して、カラムＣ３，Ｃ４については、表示されているのは当該カラムのほんの切れ端であり、これだけでユーザがこのカラムが何のためのカラムであるのか、さらに自分が興味を持ちそうな情報がありそうかを判断するのは難しい。

そこで、本実施形態によるＷｅｂブラウザプログラム２３ａでは、カラムＣ３，Ｃ４のような表示範囲が狭すぎるカラムについては、カラム概要のわかるプレビュー用要約コンテンツに置き換え、プレビュー表示に応じたＵＩ（User Interface）をつけることで、少ない表示面積のままカラムの全容を把握し易くする。また、カラムの表示面積がスクロールやズーム等で増減するのに応じて、カラムの要約の度合いも増減させ、画面から要約が溢れないようにする。

一方、カラムＣ２のような表示面積が十分あるカラムについては、何の加工もなくそのまま表示するが、適宜他の見易くする加工をしても良い。例えば、ウィンドウ幅に合わせてレイアウト調整し、横スクロールなく全文が読めるようにするなどである。

以下、具体的に説明する。
図６（Ａ）は、Ｗｅｂコンテンツのプレビュー用要約コンテンツに使うカラム要約の種類を示す図であり、図６（Ｂ）は、プレビュー用要約コンテンツをユーザに提示するためのプレビュー用ＵＩの種類を示す図である。

図６（Ａ）に示すように、カラム要約は、カラム内のテキストの「テキスト要約」または要約でない「全文」で生成する。カラムの表示面積によってカラム要約の度合いは変わり、表示面積が狭いほどより要約度合いを上げ、短いカラム要約を生成する。

テキスト要約の生成方法には、「テキスト強度別切り出し」、「更新部分抜き出し」、「一般的意味での要約（あらすじ）」の３種類がある。

まず、「テキスト強度別切り出し」によるカラム要約の生成方法について説明する。これは、テキストがより目立つと値が大きくなるような「テキスト強度」を定義し、より強いテキスト強度を持つカラム内の行を優先的に切り出すことで、カラムの要約とするものである。

テキスト強度は、例えば、行内テキストの持つスタイルに応じて定めることができる。スタイルとは、フォントサイズやフォントウェイト（太さ値）、背景のことであり、フォントサイズ／ウェイトが大きく、また、そこだけ背景が違うなど、より目立つスタイル値を持つ場合に、テキスト強度が高くなるようにすれば良い。

より目立つ強いテキストは、記事やカテゴリのタイトルなどの重要なテキストである可能性が高く、カラム要約の内容として効果的なので、そこを優先的に切り出すというのが、この生成方法の基本思想である。

図７は、この「テキスト強度別切り出し」によるカラム要約生成方法により、図４のＷｅｂコンテンツ１５ａ内のカラムを要約した例を示す図である。なお、Ｗｅｂブラウザプログラム２３ａでのカラム要約作成の具体的な処理動作については、後述する。

この生成方法によれば、カラムＣ１は、「ニュースサイト」の文字だけが切り出されている。この行は、フォントが大きく、他のテキストと違う背景が使われているので、テキスト強度が強い。

カラムＣ２は、より目立ちテキスト強度が強いタイトルとサブタイトルの全てが切り出されている。強度の弱い記事本文については、行の冒頭から画面内に納まる程度の分量のみが切り出され、省略部分は「・・・」に置き換えられている。

カラムＣ３では、横幅を維持したまま縦幅を縮め、カテゴリタイトルと記事タイトルのみになっている。この例では、記事タイトルに添えられた小さく太字でないテキスト行は、表示面積内に入らないため、行ごと省かれている。また、記事タイトルについても、表示面積が足りないために、後ろの方でいくつか行ごと省かれている。

カラムＣ４は、縦幅を維持したまま横幅を縮め、テキストが表示範囲に納まるよう、折り返しを調整している。

カラムＣ５は、縦・横ともに極端に縮めた場合のカラム要約の例である。

次に、「更新部分抜き出し」によるカラム要約の生成方法について説明する。これは、カラムの中で、最近更新した部分のみを抜き出してカラムの要約とするものである。

ニュースサイトやポータルサイトなどでは、古い情報やいつもある情報は、読んだことがあったり、価値が低かったりする。そこで、新しく価値の高い情報のみを抜き出せば、ユーザは素早くそのカラムをきちんと見るべきか判断し易くなる。

本実施形態では、この更新部分を抜き出す手法の一例として、ＲＳＳ（RDF Site Summary）を使用する。ＲＳＳは、Ｗｅｂサイト内の個々のページ等のリソースを目録的に記述するための言語であり、現在はＷｅｂサイトやＷｅｂサイト内のカテゴリ毎の更新情報の目録として配信されるのが一般的である。どのＷｅｂページに、どのＲＳＳが紐付けられるかは、Ｗｅｂコンテンツ１５ａのＨＴＭＬソース内に、＜ｌｉｎｋ＞タグでＲＳＳのＵＲＬを記述することで示している。

図８は、図４のＷｅｂコンテンツ１５ａに紐付けられたＲＳＳのソース１５ｂの例を示す図である。

この図に示すように、ＲＳＳには所定の階層構造があり、その中に個々の更新情報は＜ｉｔｅｍ＞タグで記述されている。記述される情報には、＜ｔｉｔｌｅ＞タグで記述される更新されたページのタイトル１５ｂＴ、＜ｌｉｎｋ＞タグで記述される記事本文のＵＲＬ１５ｂＬ、＜ｄｅｓｃｒｉｐｔｉｏｎ＞タグで記述されるＷｅｂサイト配信者が用意した記事の要約１５ｂＡ、＜ｃａｔｅｇｏｒｙ＞タグで記述されるカテゴリ１５ｂＣ、＜ｄｃ：ｄａｔｅ＞タグで記述される更新日時１５ｂＤ、等がある。

ＲＳＳで記述される情報の多くは、あくまでサイト内の枝葉に当たるページ（ニュースサイトで言えば、トップではなく記事の詳細な本文ページ）のどれが更新されたかという情報にすぎない。しかし、この枝葉ページへのリンクにタイトルが使われる等、ＲＳＳ内の情報が他のページにも散りばめられている。このため、ＲＳＳ内の情報を参照すれば、ＲＳＳ内に記述された枝葉ページやそこにリンクする他のページのどの部分の情報が新しいのか推定することができる。

図９は、この「更新部分抜き出し」によるカラム要約の生成方法により、図４のＷｅｂコンテンツ１５ａ内のカラムを要約した例、つまり、ＲＳＳによる情報から更新部分を抜き出して要約した結果の例を示す図である。なお、Ｗｅｂブラウザプログラム２３ａでのカラム要約作成の具体的な処理動作については、後述する。

カラムＣ１は、常に固定的な情報を示すガイドメニュー的な部分であり、ＲＳＳには何の関連記述もない部分、つまり新着記事がない部分である。従って、この生成方法によれば、カラムＣ１内にはコンテンツは何も抜き出されていない。

カラムＣ２は、ＲＳＳにタイトル・ＵＲＬのある新着記事が存在するので、ＲＳＳにある記事のメインタイトル（更新されたページのタイトル１５ｂＴ）が抜き出される。また、Ｗｅｂコンテンツ１５ａにおいてその下にあった記事本文は、ＲＳＳ内にあった、Ｗｅｂコンテンツ配信者が用意した記事の要約１５ｂＡに置き換えられる。

カラムＣ３は、ＲＳＳ内の更新されたページのタイトル１５ｂＴのみでなく、カテゴリ１５ｂＣも使った例である。カテゴリ名はしばしばＷｅｂコンテンツ１５ａ内にカテゴリ別のタイトルとして使われているし、カラムが何に関するコンテンツを持っているか端的に示すキーワードでもある。新たに更新された部分ではないが、カテゴリ名も要約コンテンツとしては有望である。

また、このカラムＣ３は、更新部分を多く含む上に非常に表示範囲が小さいため、要約しても表示範囲に納まらない。そこで、表示範囲が限られている場合は、ＲＳＳ内の更新日時１５ｂＤを参照し、より新しいものを優先的に抜き出す。

カラムＣ４，Ｃ５は更新日時１５ａＤが古い昨日の記事へのリンクを含むカラム要約の例である。昨日の古い記事はＲＳＳから消えたか、更新日時がより新しい記事が優先されたために、抜き出されない。

また、カラムＣ５に関しては、ＲＳＳに含まれない広告部分も抜き出されず削除されている。このように、ＲＳＳを使うことには、広告のようなＷｅｂサイトに関係ない情報を除外できるという利点もある。

なお、本実施形態では、ＲＳＳを用いたが、Ｗｅｂコンテンツ１５ａの更新情報を示すメタ情報であるならＡｔｏｍなど他のフォーマットの情報も利用できる。

また、更新部分を抜き出す方法自体についても、ＲＳＳ等の配信される更新情報を使う方法に限定されるものではない。

例えば、クライアント装置２０内に保存した前回訪問時のＷｅｂコンテンツとの差分を取ったり、タイトル等に添えられた更新日時をキーに判別したり、“Ｎｅｗ”や“Ｕｐｄａｔｅ”の文字列・アイコン画像を検出したりする手法が考えられる。

さらに、図９のカラムＣ１など、更新部分が全くなかったり非常に少なかったりするカラムだけは、本「更新部分抜き出し」によるカラム要約の生成方法とは別のカラム要約作成方法と組み合わせても良い。

次に、「一般的意味での要約（あらすじ）」によるカラム要約の生成方法について説明する。これは、文章をあらすじ化する、いわゆる一般的な意味でカラム内の文章を要約するものである。

この一般的な要約技術内容については、既存の技術を用いれば良く、本発明の要旨ではないので、その説明は省略する。

この生成方法を用いた結果は、例えば、図９のカラムＣ２のようなものになる。

なお、要約の他に、カラム内の文章から、キーワードのみを自動ピックアップし、それを列挙するなどしても良い。

一方、以上のようなテキスト要約に対して、Ｗｅｂコンテンツのプレビュー用要約コンテンツに使うカラム要約として「全文」を用いる場合には、要約としての意味はほぼ無い。このパターンは、図６（Ｂ）に示されるようなプレビュー用ＵＩと組み合わせて初めて意味の出るパターンである。

なお、プレビュー用要約コンテンツ生成時の画像の取り扱いとしては、プレビュー用要約コンテンツ生成時、カラム内の画像は、カラム要約に含めなくても、あるいは縮小して含めても良い（図７の例では、画像はカラム要約から除外しており、図１１の例ではカラムＣ４のように含めている）。また、画像を含める場合であっても、大きな画像は除外したり、アイコン状のサイズの小さいものだけを含める等しても良い。

但し、サイトによっては、タイトルに凝ったフォント・背景を使うために文字入り画像にしたり、入力フォームのボタンを画像にするなど、大事なテキストが画像化されている場合がある。このような場合に対応するために、「文字程度の高さを持ち、横長な画像」のみをカラム要約に含める、等しても良い。

次に、プレビュー用要約コンテンツをユーザに提示するためのプレビュー用ＵＩの種類について、説明する。

本実施形態では、上述した作成方法により作成したプレビュー用要約コンテンツを、図６（Ｂ）に示したような手法でユーザに提示する。即ち、呈示の種類としては、「縮小」、「スクロール／スライド」、「バルーン」、「加工なし」の４種類がある。このうち、「縮小」には、「フォント縮小」と「サムネイル縮小」の２種類の縮小方法があり、「スクロール／スライド」には、「自動スクロール」、「マーキー」、「分割スライドショー」の３種類がある。

なお、これらの手法は必ず単独で用いる必要はなく、例えば「フォント縮小」＋「自動スクロール」等、適宜組み合わせて用いることができる。

以下、プレビュー用ＵＩの各種類について説明する。

図１０は、プレビュー用ＵＩとして「フォント縮小」ＵＩを適用した画面遷移の例を示す図である。

この「フォント縮小」ＵＩは、図１０に（ａ）で示すように、プレビュー用要約コンテンツをフォントを縮小して表示し、表示範囲２７ａにおける当該カラム（この例ではカラムＣ３，Ｃ４）の表示領域からテキストが溢れないように表示するものである。なお、この例では、要約手法はカラム要約の「テキスト強度別切り出し」を用いている。勿論、このプレビュー用ＵＩは、図６（Ａ）に示した全種類のプレビュー用要約コンテンツを表示することができる。

この図１０（ａ）の状態から、ユーザのスクロール操作やズーム操作等のユーザ操作が行なわれて、表示範囲２７ａにおける当該カラムの表示領域の面積が増えた場合には、図１０に（ｂ）で示すように、自動的にカラム要約の度合いを下げ、より長くオリジナルに近いプレビュー用要約コンテンツに差し替えたり、フォントの縮小度合いを下げてより大きいフォントで表示したりする。

そして、表示範囲２７ａにおける当該カラム（この例ではカラムＣ３）の表示領域の面積が閾値よりも大きくなったならば、図１０に（ｃ）で示すように、要約でないオリジナル表示に切り換える。また、表示領域の面積が閾値以下となったカラム（この例ではカラムＣ１）については、オリジナル表示画像からプレビュー用要約コンテンツの表示に切り換える。

図１１は、プレビュー用ＵＩとして「サムネイル縮小」ＵＩを適用した画面遷移の例を示す図である。この「サムネイル縮小」ＵＩは、図１１に（ａ）で示すように、カラムのプレビュー用要約コンテンツのサムネイル画像を、表示範囲２７ａにおける当該カラム（この例ではカラムＣ３，Ｃ４）の表示領域の面積に合わせて縮小率や縦横比を変えることで、該表示領域内に縮小表示するものである。なお、この例では、要約手法は要約なしの「全文（そのまま）」を用い、また、サムネイルの縦横比は可変にしている。

この場合も、ユーザのスクロール操作やズーム操作等のユーザ操作が行なわれて、表示範囲２７ａにおける当該カラムの表示領域の面積の増減に応じて、縮小率や縦横比を自動で変更する。例えば、表示領域の面積が増えたならば、図１１に（ｂ）で示すように拡大表示する。加えて、プレビュー用要約コンテンツのカラム要約の度合いを適宜変えるようにしても良い。

そして、表示範囲２７ａにおける当該カラム（この例ではカラムＣ３）の表示領域の面積が閾値よりも大きくなったならば、図１１に（ｃ）で示すように、要約でないオリジナル表示に切り換える。また、表示領域の面積が閾値以下となったカラム（この例ではカラムＣ１）については、オリジナル表示画像からプレビュー用要約コンテンツの表示に切り換える。

なお、縦横比が極端に変わると見づらくなるので、縦横比の変更に上限を設けたり、あるいは、縦横比を全く変えず、サムネイルの上下または左右に余白を作る形で表示しても良い。

図１２は、プレビュー用ＵＩとして「自動スクロール」ＵＩを適用した画面の例を示す図である。この「自動スクロール」ＵＩは、カラムのプレビュー用要約コンテンツを、表示範囲２７ａにおける当該カラムの表示領域内で自動で繰り返しスクロールさせるものである。即ち、図１２において双方向矢印で示す表示範囲内で、当該カラム（この例ではカラムＣ３）のプレビュー用要約コンテンツを、自動的に上端からゆっくりスクロールさせていき、下端に到達したら、また上端からスクロールさせていく、等の表示を行なう。なお、このプレビュー用ＵＩは、図６（Ａ）に示したプレビュー用要約コンテンツの何れの種類のカラム要約であっても表示することができる。

また、プレビュー用ＵＩとしての「マーキー」ＵＩや「分割スライドショー」ＵＩは、特に図示はしないが、表示範囲２７ａにおける当該カラムの表示領域内で、スクロールではなく、当該表示領域に納まる行数ごとにプレビュー用要約コンテンツを分割し、マーキーで流す即ち左右方向のスクロールを行なったり、自動スライドショーのように切り換えて行うものである。

これら「スクロール／スライド」の何れのプレビュー用ＵＩにおいても、前記「縮小」の場合と同様に、カラムの表示領域の面積が閾値よりも大きくなったならば、要約でないオリジナル表示に切り換える。

図１３は、プレビュー用ＵＩとして「バルーン」ＵＩを適用した画面の例を示す図である。この「バルーン」ＵＩは、カラムのプレビュー用要約コンテンツのサムネイル画像を、カラムにマウスポインタ２７ｂが乗った、不図示のバルーンボタンが押された、等のタイミングで、バルーン２７ｃの形態で表示するものである。このプレビュー用ＵＩは、図６（Ａ）に示したプレビュー用要約コンテンツの何れの種類のカラム要約であっても表示することができる。

なお、バルーン表示するカラムが非常に大きかったり、バルーン２７ｃの面積を十分小さく抑えたいなど、要求事項により適宜要約コンテンツの要約の度合いを調整して良い。

一方、プレビュー用ＵＩとして「加工なし」ＵＩを適用した場合は、カラムのプレビュー用要約コンテンツを、縮小等なく同じ文字サイズのまま表示する。但し、全く何の処理も行なわないわけではなく、カラムの表示領域の面積の増減に従い、要約の度合いを調整する。

この場合も、カラムの表示領域の面積が閾値よりも大きくなったならば、要約でないオリジナル表示に切り換える。

このプレビュー用ＵＩも、図６（Ａ）に示した全種類のプレビュー用要約コンテンツを表示することができる。

なお、図６（Ｂ）に示した、プレビュー用ＵＩの何れの種類を用いてプレビュー用要約コンテンツをユーザに提示するかは、ユーザが適宜選択できるようになっていることが好ましい。しかしながら、何れか一種類のみに固定されていても良いし、全種類ではなくてその内の幾つかが選択可能になっていても構わない。

次に、以上説明したようなプレビュー用要約コンテンツ表示を行なうための、前記クライアント装置２０の動作を詳細に説明する。

図１４（Ａ）は、前記クライアント装置２０におけるＷｅｂブラウザプログラム２３ａのメイン処理フローチャートである。

ユーザ操作に応じて、ＲＯＭ２３に記憶されているＷｅｂブラウザプログラム２３ａが起動されることで、ユーザ指定のＷｅｂサイトのサーバ装置１０により配信されるＷｅｂコンテンツ１５ａが受信され取得されると、当該Ｗｅｂコンテンツ１５ａはそのＨＴＭＬのソース構造が解析されてＲＡＭ２４内のフレームバッファ（図示せず）に描画される（ステップＳ１）。また、この処理は、ブラウザ起動操作だけでなく、リンクのクリックなど、新規Ｗｅｂページを読み込むユーザ操作をトリガにしても行われる。

ここまでは、通常のブラウザと同じ処理である。なお、通常のブラウザでは、ＲＡＭ２４内のフレームバッファに描画したＷｅｂコンテンツ１５ａを、図５に示すように、予め記憶している当該クライアント装置２０の表示装置２７のハードウェア情報および現在の拡大率等の表示モードの情報に基づいて決まるブラウザウィンドウの表示範囲２７ａで表示することとなる。

これに対して、本実施形態では、更に、カラムプレビュー制御処理を実行する。

Ｏｐｅｒａ（登録商標）やＮｅｔＦｒｏｎｔ（登録商標）など、多くの携帯端末向けブラウザが実装している機能である既存のアルゴリズムを用いて、ＲＡＭ２４内のフレームバッファに描画したＷｅｂコンテンツ１５ａをカラムに分割する（ステップＳ２）。

そして、ブラウザウィンドウの表示範囲２７ａ内にあるが表示量が十分でないカラムを判別して、当該カラムに対してプレビュー化処理を行うことで、先に説明したようなプレビュー用要約コンテンツ表示を行なう（ステップＳ３）。このプレビュー化処理の詳細については後述する。

この後は、ユーザ操作によるスクロールやズームが行われたか否かを判別する（ステップＳ４）。ここで、そのようなユーザ操作があったと判別した場合には、そのユーザ操作に応じたスクロールやズームを行なう（ステップＳ５）。そして、表示範囲２７ａ内の各カラムの表示量に変化がある度ごとに、再度、カラムのプレビュー化処理を行う（ステップＳ６）。

そしてその後、あるいは、前記ステップＳ４においてスクロールやズームのユーザ操作がないと判別した場合には、ユーザ操作により別のＷｅｂページに遷移するか、ブラウザの終了が指示されたか否かを判別する（ステップＳ７）。ここで、別のＷｅｂページへの遷移やブラウザ終了指示のユーザ操作がないと判別した場合には、前記ステップＳ４に戻って、前述の動作を繰り返す。

而して、別のＷｅｂページへの遷移またはブラウザ終了指示のユーザ操作が行なわれたと判別したならば、処理を終了する。

図１４（Ｂ）は、前記ステップＳ３あるいはステップＳ６で実行されるカラムのプレビュー化処理の詳細を示すフローチャートである。

先ず、ブラウザウィンドウの表示範囲２７ａ内つまり画面内にある全カラムを特定する（ステップＳ１１）。

そして、全カラムに対し、個別のプレビュー化処理を行っていく。そのため、先ず、処理したカラム数を計数するためのメモリ（ＲＡＭ２４）上に設けたカウンタｎに「１」をセットする（ステップＳ１２）。その後、処理対象のｎ番目カラムの表示領域の面積が、プレビュー化閾値以下であるか否かを判定する（ステップＳ１３）。

ここで、処理対象カラムの表示領域面積がプレビュー化閾値以下であると判別した場合には、カラム要約処理を実行して、当該カラムの表示領域の面積に合わせてプレビュー用要約コンテンツを生成する（ステップＳ１４）。なお、このカラム要約処理の詳細については後述する。そして、生成したプレビュー用要約コンテンツをカラム表示領域に表示し、図６（Ｂ）で示した何れかのプレビュー用ＵＩを付与する（ステップＳ１５）。その後、カウンタｎを「＋１」して（ステップＳ１６）、その結果が画面内にあるカラムの個数を超えたか否かを判別する（ステップＳ１７）。そして、未だ越えていないならば、未処理のカラムがあるとして、前記ステップＳ１３に戻って、次のカラムに対する処理を実行する。

一方、前記ステップＳ１３において、処理対象カラムの表示領域面積がプレビュー化閾値を上回っていると判別した場合には、当該カラムがプレビュー用要約コンテンツを表示している状態であるのか否かを判別する（ステップＳ１８）。ここで、プレビュー用要約コンテンツの表示ではなくオリジナル表示画像の表示状態であると判別したならば、前記ステップＳ１６に進む。これに対して、プレビュー用要約コンテンツの表示状態であると判別した場合には、そのプレビュー化を解除、つまりプレビュー用要約コンテンツからオリジナル表示画像に表示を戻して（ステップＳ１９）、前記ステップＳ１６に進む。

こうして、ブラウザウィンドウの表示範囲２７ａ内つまり画面内にある全てのカラムに対する処理が終了したならば、カウンタｎの値は「その全カラム個数＋１」となるので、前記ステップＳ１７で、カウンタｎの値が画面内にあるカラムの個数を超えたと判別して、当該カラムのプレビュー化処理を終了することとなる。

なお、前記ステップ１４で実行されるカラム要約処理は、図６（Ａ）に示した何れかの手法で、カラムを要約したプレビュー用要約コンテンツを生成する処理である。以下、テキスト要約の「テキスト強度別切り出し」と「更新部分抜き出し」の２例について説明する。テキスト要約の「一般的意味での要約（あらすじ）」については、既存の技術を用いれば良く、また、カラム要約として「全文」を用いる場合には、格別の処理は不要であるので、ここでは説明を省略する。

図１５は、「テキスト強度別切り出し」によりプレビュー用要約コンテンツを生成する場合のカラム要約処理のフローチャートである。これは、図７で画面例を挙げた、カラム内の各行のテキスト強度を算出し、より強い（目立つ）テキストを優先的に切り出すことで、カラムの重要部分のみを抜き出す手法を実現するものである。

即ち、先ず、今処理中のカラムに対し、既にテキスト強度が算出されて、メモリ（ＲＡＭ２４）上に保存されているか否かを確認する（ステップＳ２１）。これは、初回の要約処理では、必ずｎｏになる。算出済みであれば、前回の算出結果をそのまま再利用するため、後述するステップＳ２５に進む。

テキスト強度が算出済みでないと判別した場合には、カラムを行に分割して、行ごとのテキスト強度を算出する（ステップＳ２２）。このテキスト強度の算出の詳細については、後述する。次に、算出した強度の強い順、行番号の小さい（カラム内でより上にある）順にソートし（ステップＳ２３）、そのソート結果をメモリに保存する（ステップＳ２４）。

次に、メモリ（ＲＡＭ２４）上に設けた残り面積カウンタを、カラム表示領域の面積の値に初期化する（ステップＳ２５）。そして、処理した行数を計数するためのメモリ（ＲＡＭ２４）上に設けたカウンタｍに「１」をセットする（ステップＳ２６）。その後、テキスト強度の強い順・行番号の小さい順にソートされた行からｍ個目の行を取り出し、前記残り面積カウンタの値で示される残り面積に表示可能な文字数だけ当該行から取り出す、つまり残り面積で許す限りの文字数を切り出して、メモリに保存する（ステップＳ２７）。この切り出しによって残り面積が減るので、残り面積カウンタからｍ個目の行の表示面積を減算する（ステップＳ２８）。

その後、残り面積カウンタで示される残り面積が０より大きいか否かを判別する（ステップＳ２９）。ここで、まだ０よりも大きいと判別した場合には、カウンタｍを「＋１」して（ステップＳ３０）、その結果がカラム内の行数を超えたか否かを判別する（ステップＳ３１）。そして、未だ越えていないならば、未処理の行があるとして、前記ステップＳ２７に戻って、次の行に対する処理を実行する。

こうして、前記ステップＳ２９において残り面積が０以下となったと判別されるか、前記ステップＳ３１においてカウンタｍがカラム内の行数を超えた、つまり当該カラムの全ての行を処理したと判別されたならば、前記ステップＳ２７にて切り出されてメモリに保存されている全テキストを結合することで、プレビュー用要約コンテンツを生成して（ステップＳ３２）、該カラム要約処理を終了する。

なお、各切り出しテキストは、プレビュー用ＵＩにおけるスタイル変更（フォント縮小等）がない限りは、オリジナル表示時と同じスタイルを維持するようにし、オリジナル表示と比べた時の違和感がないようにする。

また、図１５のフローチャートでは、同じテキスト強度を持つ行に関しては、より上にあるものを優先して切り出すようにし、場合によっては下の方の行は全く表示されないこととなってしまう。そこで、同じレベルの強度にある行に関して、残り面積が足りず全行の全テキストが表示不可能な場合は、行ごとの切り出し文字数を均等配分で決め、全行の行頭が切り出されて表示されるようにしてもよい。この方法では、行の末尾は省略されてしまうが、全部の行が見えるので、下の方に重要なコンテンツがある場合も少なくとも行頭部分はユーザの目に入るようになる。

次に、前記ステップＳ２２で算出される行ごとのテキスト強度について説明する。
「行ごとのテキスト強度」とは、テキストの「フォントサイズ」、「フォントウェイト（太さ）」、「背景」、等のスタイル情報のそれぞれについて強度ポイントを算出し、それらを合計したものである。

即ち、フォントサイズとフォントウェイトの値が大きくなる程、テキストの文字自体が目立つものになる。また、背景を１行だけ変えてその行を目立たせ、視覚的な区切りを作るのもＷｅｂサイトのよくあるデザインである。このような目立つテキストを含む行に対し、テキスト強度が大きくなるように算出方法を定める。

なお、ここで述べている算出方法はあくまで一例であり、「目立つ重要なテキストを特定する」という基本思想に則っていれば、どのような算出方法を用いても良い。

フォントサイズやフォントウェイトのような、スタイルの値が大きければテキストが目立つようになる指標値に対しては、まず、カラム内テキストが持つ指標値の最小値ｆ_ｍｉｎと最大値ｆ_ｍａｘを求める。そして、指標値の最小値ｆ_ｍｉｎが０ポイント、最大値ｆ_ｍａｘが１００ポイントとなるように正規化し、その行内の指標値の最頻値ｆを代表値として、以下の（１）式により強度ポイントを算出する。

強度ポイント＝｛（ｆ−ｆ_ｍｉｎ）／（ｆ_ｍａｘ−ｆ_ｍｉｎ）｝×１００ …（１）
即ち、行ごとの強度を出す場合は、その行内のフォントサイズ（またはウェイト）の最頻値ｆを代表値とし、上記式により求めた値がフォントサイズ（またはウェイト）強度ポイントの値となる。

一方、背景のような、より少数派であるほど強い指標値に関しては、まず、指標の各値ごとに文字数を集計する。

図１６は、カラムの中の背景ごとの文字数を集計した結果の一例を示す図である。これは、カラムの中で、背景色＃ｘｘｘを持つ文字数、背景画像○○．ｇｉｆを持つ文字数、というように、背景ごとに文字数ｓを集計した結果である。

そして、最も文字数の多い多数派の背景は０ポイント、最も少ない少数派の背景は１００ポイントとなるように正規化し、その行内の文字数をｓ、カラム内の行当たりの最大文字数をｓ_ｍａｘ、最小文字数をｓ_ｍｉｎとして、以下の（２）式により背景強度ポイントを算出する。

背景強度ポイント＝｛（ｓ−ｓ_ｍｉｎ）／（ｓ_ｍａｘ−ｓ_ｍｉｎ）｝×１００ …（２）
即ち、文字数が少ないほど、ポイント数が高くなるようになっている。

そして、こうして算出したフォントサイズ，フォントウェイト，背景の各強度ポイント全てを加味した総合的な強度としてのテキスト強度ポイントは、各強度ポイントを以下の（３）式により重みづけ加算することで算出される。

テキスト強度ポイント＝ 重み_ｆｓ×フォントサイズ強度ポイント
＋重み_ｆｗ×フォントウェイト強度ポイント
＋重み_ｂｇ×背景強度ポイント …（３）
個々の指標値の強度は０〜１００ポイントに正規化されているが、テキストが目立つかどうかは、フォントサイズよりはフォントウェイト、背景による所が大きかったりする。そこで、個別に重みをつけることで調整している。

図１７は、前記の算出式で計算した行ごとのテキスト強度の一例を示す図である。
これは、図４のカラムＣ３を題材とした例である。また、フォントサイズの重み_ｆｓは「１」、フォントウェイトの重み_ｆｗは「１．５」、背景の重み_ｂｇは「２」としている。

この例の場合では、テキスト強度ポイントは、カテゴリ名を示すタイトル（「社会・国際」等）が最も強く（４００ポイント）、そのカテゴリ内の記事タイトルがその次に強い（２５０ポイント）。最も弱い（０ポイント）のは、記事タイトルの下に添えられる説明文である。

このように、より目立つ順に強くなるようテキスト強度が定められている。

図１８は、「更新部分抜き出し」によりプレビュー用要約コンテンツを生成する場合のカラム要約処理のフローチャートである。これは、図９で画面例を挙げた、カラム内の最近更新された部分のみを抜き出し、カラムのプレビュー用要約コンテンツとする手法を実現するものである。

即ち、先ず、今処理中のＷｅｂページのＷｅｂコンテンツ１５ａに紐付けられたＲＳＳが既に取得され、メモリ（ＲＡＭ２４）上に保存されているか否かを確認する（ステップＳ４１）。これは、初回の要約処理では、必ずｎｏになる。取得済みであれば、前回取得したものをそのまま再利用するため、後述するステップＳ４４に進む。

ＲＳＳが取得済みでないと判別した場合には、当該ＷｅｂページのＷｅｂコンテンツ１５ａに紐付けられたＲＳＳが存在するか否かを確認する（ステップＳ４２）。ここで、ＲＳＳが存在しないと判別した場合には、この手法による要約は不可能であり、出力としてのプレビュー用要約コンテンツを空として、該カラム要約処理を終了させる。

これに対して、ＲＳＳが存在すると判別した場合には、そのＲＳＳを新たに取得し、次回処理時に利用できるようにメモリに保存する（ステップＳ４３）。

そして、当該ＷｅｂページのＷｅｂコンテンツ１５ａ内のテキスから、ＲＳＳ内の更新情報に含まれるタイトルと一致するものを検索し、メモリに抽出保存する（ステップＳ４４）。一致したテキストを、以降、タイトルテキストと称する。そして、このタイトルテキストが存在するか否かを判別し（ステップＳ４５）、それが存在しなければ、このカラムに更新部分はないので、プレビュー用要約コンテンツを空として、該カラム要約処理を終了させる。

タイトルテキストが存在すると判別した場合には、そのそれぞれにつき、ＲＳＳ内に要約文があれば取得する。そのため、まず、処理したタイトルテキストの数を計数するためのメモリ（ＲＡＭ２４）上に設けたカウンタｍに「１」をセットする（ステップＳ４６）。その後、ＲＳＳにｍ個目のタイトルテキストに対する要約があるか否かを判定する（ステップＳ４７）。ここで、要約がなければ、後述するステップＳ４９に進む。これに対して、要約があれば、ＲＳＳからその要約を取得して、ｍ個目のタイトル用要約文としてメモリに保存する（ステップＳ４８）。そして、カウンタｍを「＋１」して（ステップＳ４９）、その結果がタイトルテキスト数を超えたか否かを判別する（ステップＳ５０）。未だ越えていないならば、未処理のタイトルがあるとして、前記ステップＳ４７に戻って、次のタイトルテキストに対する処理を実行する。

こうして、前記ステップＳ５０においてカウンタｍがタイトルテキスト数を超えた、つまり全てのタイトルテキストに対する処理を行なったと判別されたならば、メモリに保存されている全てのタイトルテキストとＲＳＳから得た対応するタイトル用要約文を順番に結合することで、プレビュー用要約コンテンツを生成して（ステップＳ５１）、該カラム要約処理を終了する。

なお、前記ステップＳ５１のプレビュー用要約コンテンツの生成においては、ＲＳＳから得たタイトル用要約文は、対応するタイトルテキストの下に添える形で配置する。

また、各タイトルテキストは、プレビュー用ＵＩによるスタイル変更（フォント縮小等）がない限りは、オリジナル表示と時同じスタイルを維持するようにし、オリジナル表示と比べた時の違和感がないようにする。

なお、前記ステップＳ４２においてＲＳＳがないと判別された場合や、前記ステップＳ４７においてカラム内に更新部分が存在しないと判別された場合等、プレビュー用要約コンテンツを空にせざるを得ない場合は、そのカラムだけ図６（Ａ）に挙げた別の手法でプレビュー用要約コンテンツを生成するようにしても良い。

以上のように、本発明の情報処理装置の一実施形態に係るサーバ・クライアント・システムによれば、ブラウザ上のＷｅｂページの表示において、Ｗｅｂコンテンツ１５ａをカラム単位に分割し、今ブラウザウィンドウの表示範囲２７ａ内にあるカラムの表示面積が十分でない場合は、そのカラムの内容の要約であるプレビュー用要約コンテンツを作成して、その部分に表示するようにし、また、表示の方法もフォント縮小や自動スクロールなどプレビュー用ＵＩをつけて表示することで、表示領域の小ささを補うようにしたので、小画面でズームしているなど一覧性の低い状態でも、画面の端に見えるカラムがどんな内容なのか概略を知ることができ、ユーザはカラム内容を確認するためだけに無駄にスクロールする手間が大幅に減るので、ユーザはより快適にＷｅｂブラウジングすることができる。なお、カラムをどのくらいの度合いで要約するか（短くするか、長めにするか）は、カラムの表示面積に応じて自動的に調整される。

また、スクロールやズーム等でカラムの表示領域の面積に変動があった場合は、テキストの強度の大きいものを優先に要約、更新部分を抜き出して要約、一般的意味での要約、というように、自動で要約の度合いを調整してプレビュー用要約コンテンツを作成するようにしているので、表示領域の面積に相応しい表示が行え、且つ、表示領域の面積が増えるに従ってよりオリジナルに近い表示になるようにすることができるので、その時々の表示の状態に合わせて、限られた画面スペースを有効に使うことが可能となる。

また、カラムの表示領域の面積が小さすぎ、十分な要約が表示できない場合でも、数回スクロールすれば十分な要約が表示できるので、通常の（要約を表示しない）場合と比して、ずっと少ない回数でカラムの内容を把握し、自分の興味ある情報か判断することができる。

さらに、プレビュー用要約コンテンツの生成時に、要約のために抜き出したテキストを、プレビュー用ＵＩ上のフォント縮小などの要求がない限り、オリジナル表示時と同じフォント・背景などのスタイルで表示するようにしているので、要約コンテンツの外観はオリジナル表示と違和感なく統一され、ユーザは「スクロールしたらいきなり背景色が変わった」「縮小状態から拡大したら、元と全く違うのでどこを表示しているのかわからない」等の戸惑いなくＷｅｂブラウジングができる。

また、フォント縮小、サムネイル縮小、自動スクロール、マーキー、分割スライドショー、サムネイルのバルーン、の何れかを含むプレビュー表示を行うことで、表示領域の小ささを補うことが可能であり、更に、どのようなプレビュー用ＵＩを付加するかをユーザが任意に選択できるようにすれば、ユーザが最も見易いと感じる表示形態で表示を行なうことが可能となる。

なお、前記一実施形態は、通常のサーバ・クライアント・システムにおけるクライアント装置２０のＷｅｂブラウザプログラム２３ａに対し、前記カラムプレビュー制御機能を搭載してユーザ指定のＷｅｂサイトのコンテンツ１５ａを取得し表示制御する場合について説明した。これに対し、サーバベース・コンピューティング・システム（ＳＢＣ）におけるシン・クライアント端末にてユーザ指定のＷｅｂサイトのコンテンツ１５ａを取得し表示する場合には、当該シン・クライアント端末からの入力イベントによって起動するサーバ装置のＷｅｂブラウザに対し、前記同様のカラムプレビュー制御機能を搭載すればよい。

なお、前記一実施形態において記載した情報処理装置による各処理の手法、すなわち、図１４，図１５，図１８のフローチャートに示す処理の各手法は、何れもコンピュータに実行させることができるプログラムとして、メモリカード（ＲＯＭカード、ＲＡＭカード等）、磁気ディスク（フロッピディスク、ハードディスク等）、光ディスク（ＣＤ−ＲＯＭ、ＤＶＤ等）、半導体メモリ等の外部記憶装置２５（１５）の媒体に格納して配布することができる。そして、情報処理装置のコンピュータ（ＣＰＵ２１（１１））は、この外部記憶装置２５（１５）の媒体に記憶されたプログラムを記憶装置（フラッシュＲＯＭ２３（１３）やＲＡＭ２４（１４））に読み込み、この読み込んだプログラムによって動作が制御されることにより、前記一実施形態において説明したカラムプレビュー制御機能を実現し、前述した手法による同様の処理を実行することができる。

また、前記各手法を実現するためのプログラムのデータは、プログラムコードの形態として通信ネットワーク（Ｎ）上を伝送させることができ、この通信ネットワーク（Ｎ）に接続されたコンピュータ装置（プログラムサーバ）から前記のプログラムデータを取り込んで記憶装置（フラッシュＲＯＭ２３（１３）やＲＡＭ２４（１４））に記憶させ、前述したカラムプレビュー制御機能を実現することもできる。

なお、本願発明は、前記一実施形態に限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で種々に変形することが可能である。さらに、前記一実施形態には種々の段階の発明が含まれており、開示される複数の構成要件における適宜な組み合わせにより種々の発明が抽出され得る。

Ｎ…ネットワーク
１０…サーバ装置
１１…ＣＰＵ
１２…バス
１３…ＲＯＭ
１４…フレームバッファＲＡＭ
１５…外部記憶装置
１５ａ…Ｗｅｂコンテンツ
１５ｂ…ＲＳＳのソース
１５ｂＴ…更新されたページのタイトル
１５ｂＬ…記事本文のＵＲＬ
１５ｂＡ…記事の要約
１５ｂＣ…カテゴリ
１５ｂＤ…更新日時
１６…入力装置
１７…表示装置
１８…通信Ｉ／Ｆ
２０…クライアント装置
２１…ＣＰＵ
２２…バス
２３…ＲＯＭ
２３ａ…Ｗｅｂブラウザプログラム
２４…ＲＡＭ
２５…外部記憶装置
２６…入力装置
２７…表示装置
２７ａ…ブラウザウィンドウの表示範囲
２７ｂ…マウスポインタ
２７ｃ…バルーン
２８…通信Ｉ／Ｆ
Ｃ１，Ｃ２，Ｃ３，Ｃ４，Ｃ５…カラム

Claims (7)

1. コンテンツ情報を表示画面上に表示する情報処理装置であって、
   ネットワークを介してコンテンツ情報を受信する受信手段と、
   前記受信手段により今回受信したコンテンツ情報の内で新規に更新された部分を抜き出す抜出手段と、
   前記受信手段で受信した前記コンテンツ情報を前記表示画面上に表示する際は、その表示画面の中で前記コンテンツ情報を表示する表示領域の大きさを所定閾値と比較し、その比較結果に基づいて、前記コンテンツ情報を要約のないオリジナルのコンテンツ情報としてそのまま表示するか、あるいは当該コンテンツ情報のオリジナルを表示することはせずに前記抜出手段で抜き出された部分の部分コンテンツ情報を前記オリジナルのコンテンツ情報の表示に代わって表示するか、を制御する表示制御手段と、
   を備えたことを特徴とする情報処理装置。
2. 前記受信手段で受信した前記コンテンツ情報の中に新規に更新された部分が存在するか否かを判別する判別手段と、を更に備え、
   前記表示制御手段は、前記判別手段で更新された部分があると判別された場合には、前記抜出手段で抜き出された部分のコンテンツ情報を前記全体コンテンツ情報に代わって表示するよう制御し、前記判別手段で更新された部分がないと判別された場合には表示しないように制御する、
   ことを特徴とする請求項１記載の情報処理装置。
3. 前記表示画面には、複数のカラム領域がレイアウトされたページ情報が表示され、
   前記表示制御手段は、前記各カラム領域毎に、そのカラム領域内に表示すべきコンテンツ情報の内で前記抜出手段で抜き出された部分のコンテンツ情報を表示する、
   ことを特徴とする請求項１又は２に記載の情報処理装置。
4. 前記抜出手段は、前記更新された部分を、そのコンテンツ情報に含まれる各コンテンツ部分のＲＳＳに基づいて抜き出す、
   ことを特徴とする請求項１〜３の何れかに記載の情報処理装置。
5. 前記抜出手段は、前記更新された部分を、そのコンテンツに含まれる各コンテンツ部分の日時情報に基づいて抜き出す、
   ことを特徴とする請求項１〜３の何れかに記載の情報処理装置。
6. 前記抜出手段は、前記更新された部分を、前回受信したコンテンツ情報との差分に基づいて抜き出す、
   ことを特徴とする請求項１〜３の何れかに記載の情報処理装置。
7. コンテンツ情報を表示画面上に表示する情報処理装置のコンピュータを制御するためのプログラムであって、
   前記コンピュータを、
   ネットワークを介してコンテンツ情報を受信する受信手段、
   前記受信手段により今回受信したコンテンツ情報の内で新規に更新された部分を抜き出す抜出手段、
   前記受信手段で受信した前記コンテンツ情報を前記表示画面上に表示する際は、その表示画面の中で前記コンテンツ情報を表示する表示領域の大きさを所定閾値と比較し、その比較結果に基づいて、前記コンテンツ情報を要約のないオリジナルのコンテンツ情報としてそのまま表示するか、あるいは当該コンテンツ情報のオリジナルを表示することはせずに前記抜出手段で抜き出された部分の部分コンテンツ情報を前記オリジナルのコンテンツ情報の表示に代わって表示するか、を制御する表示制御手段、
   として機能させるようにしたコンピュータ読み取り可能なプログラム。

Images