以下、本発明を実施するための形態を図面を参照して説明する。
図1は、本発明の情報処理装置の一実施形態に係るサーバ・クライアント・システムの構成を示すブロック図である。
このサーバ・クライアント・システムは、インターネット、WAN、LANなどからなるネットワークN上にそれぞれ接続されたサーバ装置10と複数のクライアント装置20とを備える。
サーバ装置10は、Webコンテンツ生成処理プログラム,登録ユーザ管理処理プログラム,Webページ配信処理プログラムなど、当該サーバ装置10の本体操作により機能する複数のアプリケーションプログラムを有し、例えば本サーバ装置10にユーザ登録されたクライアント装置20からの指定のWebサイトへのアクセス要求に応じて当該要求されたWebサイトにおけるWebコンテンツ15aのページを各クライアント装置20へ配信する。
クライアント装置20は、携帯電話,PDA(Personal Digital Assistant),PCなどからなり、インターネット接続処理プログラム、Webブラウザプログラム23a,Web印刷プログラムなど、当該クライアント装置20の本体操作により機能する複数のアプリケーションプログラムを有する。そして、例えば所望のWebサイトのサーバ装置10にアクセスしてそのWebコンテンツ15aを取得し、当該Webコンテンツ15aのHTML(Hyper Text Markup Language)を解析してカラムに分割し、その単位で要約を生成して、表示面積に従ったプレビュー用の表示形態に適応させて表示する。
なお、サーバ装置10から受信したWebコンテンツを扱う処理を、中間サーバなどに担わせても良い。例えば、ProxyサーバなどWebコンテンツを中継するサーバや、クライアント装置20とつながるその他外部サーバ上でWebコンテンツのカラム要約をして、クライアント装置20に渡すようにしても構わない。
図2は、前記サーバ・クライアント・システムにおけるサーバ装置10の回路構成を示すブロック図である。
サーバ装置10は、コンピュータとしてのCPU11を備え、このCPU11には、バス12を介してROM13、フレームバッファRAM14、外付けハードディスクなどの外部記憶装置15が接続される。
また、CPU11には、バス12を介してキーボード,マウスなどの入力装置16、LCD(Liquid Crystal Display)などの表示装置17、前記クライアント装置20との通信I/F(インターフェイス)18が接続される。
CPU11は、ROM13に予め記憶されているシステムプログラムや種々のアプリケーションプログラムに従ってフレームバッファRAM14を作業用メモリとし回路各部の動作を制御するもので、入力装置16からのキー入力信号や通信I/F18を介して受信されるクライアント装置20からのユーザ操作に応じたWebコンテンツ取得要求信号などに応じて前記種々のプログラムが起動・実行される。
前記Webコンテンツ15aは、例えば外部記憶装置15に適宜更新生成されて記憶されている。
図3は、前記サーバ・クライアント・システムにおけるクライアント装置20の回路構成を示すブロック図である。
クライアント装置20は、コンピュータとしてのCPU21を備え、このCPU21には、バス22を介してROM23、RAM24、メモリカードや光ディスク読み書き部などの外部記憶装置25が接続される。
また、CPU21には、バス22を介してキーボード,マウスなどの入力装置26、LCDからなる表示装置27、前記サーバ装置10との通信I/F(インターフェイス)28が接続される。
CPU21は、ROM23に予め記憶されているシステムプログラムおよび種々のアプリケーションプログラムに従ってRAM24を作業用メモリとし回路各部の動作を制御するもので、入力装置26からの入力信号に応じて前記種々のアプリケーションプログラムが起動され実行される。
前記サーバ装置10をインターネット(N)上のWebサイト、前記クライアント装置20を前記Webサイトにアクセス可能なユーザ端末とした場合、ユーザ端末(20)からWebサイト(10)へのアクセス要求に応じて、当該Webサイト(10)においてHTMLにより記述生成されたWebコンテンツ15aがアクセス要求元のユーザ端末(20)へ配信され、そのWebブラウザプログラム23aによりWebページに展開されて表示装置27に表示される。
このクライアント装置(ユーザ端末)20のWebブラウザプログラム23aは、ユーザ指定のWebサイトのサーバ装置10へのアクセスに伴い、そのWebコンテンツ15aを取得し、当該Webコンテンツ15aのHTMLを解析してカラム(詳細は後述する)に分割し、その単位で要約を生成して、表示面積に従ったプレビュー用の表示形態に適応させてプレビュー表示する、カラムプレビュー制御機能を有する。このカラムプレビュー制御機能は、例えば前記Webブラウザプログラム23aにプラグインあるいはアドオンするプログラムにより実現される。
以下、前記クライアント装置20のWebブラウザプログラム23aにおける前記カラムプレビュー制御機能を詳細に説明する。
図4は、前記クライアント装置20においてサーバ装置10から取得されたWebコンテンツ15aの例を示す図である。
Webコンテンツは、数種類の異なる種類の情報を持った部分(ヘッダ/フッタ,記事本文,ユーザをリンク誘導するための部分,等)から成るのが一般的であり、この区切られた部分をカラムと呼ぶ。図4に例示したWebコンテンツ15aでは、カラムC1〜カラムC5の5つのカラムを有している。
なお、クライアント装置20のWebブラウザプログラム23aでのカラムの抽出、分割の処理については、Opera(登録商標)等の携帯電話用フルブラウザで採用されている手法等、既存の何れかの手法を用いて実施することができるので、ここではその説明は省略する。
図5は、図4に示すようなWebコンテンツ15aを、一般的なWebブラウザプログラムにより表示装置27で表示した場合の表示を示す図である。
表示装置27で表示可能なブラウザウィンドウの表示範囲27aは、Webコンテンツ15aの一部分しかカバーできず、ここでは、カラムC2,C3,C4の各一部分を表示している。この場合、カラムC2は広い部分が表示されており、横部分が多少切れているとはいえ、どういう内容のカラムかは特にスクロールしなくても判別できる。これに対して、カラムC3,C4については、表示されているのは当該カラムのほんの切れ端であり、これだけでユーザがこのカラムが何のためのカラムであるのか、さらに自分が興味を持ちそうな情報がありそうかを判断するのは難しい。
そこで、本実施形態によるWebブラウザプログラム23aでは、カラムC3,C4のような表示範囲が狭すぎるカラムについては、カラム概要のわかるプレビュー用要約コンテンツに置き換え、プレビュー表示に応じたUI(User Interface)をつけることで、少ない表示面積のままカラムの全容を把握し易くする。また、カラムの表示面積がスクロールやズーム等で増減するのに応じて、カラムの要約の度合いも増減させ、画面から要約が溢れないようにする。
一方、カラムC2のような表示面積が十分あるカラムについては、何の加工もなくそのまま表示するが、適宜他の見易くする加工をしても良い。例えば、ウィンドウ幅に合わせてレイアウト調整し、横スクロールなく全文が読めるようにするなどである。
以下、具体的に説明する。
図6(A)は、Webコンテンツのプレビュー用要約コンテンツに使うカラム要約の種類を示す図であり、図6(B)は、プレビュー用要約コンテンツをユーザに提示するためのプレビュー用UIの種類を示す図である。
図6(A)に示すように、カラム要約は、カラム内のテキストの「テキスト要約」または要約でない「全文」で生成する。カラムの表示面積によってカラム要約の度合いは変わり、表示面積が狭いほどより要約度合いを上げ、短いカラム要約を生成する。
テキスト要約の生成方法には、「テキスト強度別切り出し」、「更新部分抜き出し」、「一般的意味での要約(あらすじ)」の3種類がある。
まず、「テキスト強度別切り出し」によるカラム要約の生成方法について説明する。これは、テキストがより目立つと値が大きくなるような「テキスト強度」を定義し、より強いテキスト強度を持つカラム内の行を優先的に切り出すことで、カラムの要約とするものである。
テキスト強度は、例えば、行内テキストの持つスタイルに応じて定めることができる。スタイルとは、フォントサイズやフォントウェイト(太さ値)、背景のことであり、フォントサイズ/ウェイトが大きく、また、そこだけ背景が違うなど、より目立つスタイル値を持つ場合に、テキスト強度が高くなるようにすれば良い。
より目立つ強いテキストは、記事やカテゴリのタイトルなどの重要なテキストである可能性が高く、カラム要約の内容として効果的なので、そこを優先的に切り出すというのが、この生成方法の基本思想である。
図7は、この「テキスト強度別切り出し」によるカラム要約生成方法により、図4のWebコンテンツ15a内のカラムを要約した例を示す図である。なお、Webブラウザプログラム23aでのカラム要約作成の具体的な処理動作については、後述する。
この生成方法によれば、カラムC1は、「ニュースサイト」の文字だけが切り出されている。この行は、フォントが大きく、他のテキストと違う背景が使われているので、テキスト強度が強い。
カラムC2は、より目立ちテキスト強度が強いタイトルとサブタイトルの全てが切り出されている。強度の弱い記事本文については、行の冒頭から画面内に納まる程度の分量のみが切り出され、省略部分は「・・・」に置き換えられている。
カラムC3では、横幅を維持したまま縦幅を縮め、カテゴリタイトルと記事タイトルのみになっている。この例では、記事タイトルに添えられた小さく太字でないテキスト行は、表示面積内に入らないため、行ごと省かれている。また、記事タイトルについても、表示面積が足りないために、後ろの方でいくつか行ごと省かれている。
カラムC4は、縦幅を維持したまま横幅を縮め、テキストが表示範囲に納まるよう、折り返しを調整している。
カラムC5は、縦・横ともに極端に縮めた場合のカラム要約の例である。
次に、「更新部分抜き出し」によるカラム要約の生成方法について説明する。これは、カラムの中で、最近更新した部分のみを抜き出してカラムの要約とするものである。
ニュースサイトやポータルサイトなどでは、古い情報やいつもある情報は、読んだことがあったり、価値が低かったりする。そこで、新しく価値の高い情報のみを抜き出せば、ユーザは素早くそのカラムをきちんと見るべきか判断し易くなる。
本実施形態では、この更新部分を抜き出す手法の一例として、RSS(RDF Site Summary)を使用する。RSSは、Webサイト内の個々のページ等のリソースを目録的に記述するための言語であり、現在はWebサイトやWebサイト内のカテゴリ毎の更新情報の目録として配信されるのが一般的である。どのWebページに、どのRSSが紐付けられるかは、Webコンテンツ15aのHTMLソース内に、<link>タグでRSSのURLを記述することで示している。
図8は、図4のWebコンテンツ15aに紐付けられたRSSのソース15bの例を示す図である。
この図に示すように、RSSには所定の階層構造があり、その中に個々の更新情報は<item>タグで記述されている。記述される情報には、<title>タグで記述される更新されたページのタイトル15bT、<link>タグで記述される記事本文のURL15bL、<description>タグで記述されるWebサイト配信者が用意した記事の要約15bA、<category>タグで記述されるカテゴリ15bC、<dc:date>タグで記述される更新日時15bD、等がある。
RSSで記述される情報の多くは、あくまでサイト内の枝葉に当たるページ(ニュースサイトで言えば、トップではなく記事の詳細な本文ページ)のどれが更新されたかという情報にすぎない。しかし、この枝葉ページへのリンクにタイトルが使われる等、RSS内の情報が他のページにも散りばめられている。このため、RSS内の情報を参照すれば、RSS内に記述された枝葉ページやそこにリンクする他のページのどの部分の情報が新しいのか推定することができる。
図9は、この「更新部分抜き出し」によるカラム要約の生成方法により、図4のWebコンテンツ15a内のカラムを要約した例、つまり、RSSによる情報から更新部分を抜き出して要約した結果の例を示す図である。なお、Webブラウザプログラム23aでのカラム要約作成の具体的な処理動作については、後述する。
カラムC1は、常に固定的な情報を示すガイドメニュー的な部分であり、RSSには何の関連記述もない部分、つまり新着記事がない部分である。従って、この生成方法によれば、カラムC1内にはコンテンツは何も抜き出されていない。
カラムC2は、RSSにタイトル・URLのある新着記事が存在するので、RSSにある記事のメインタイトル(更新されたページのタイトル15bT)が抜き出される。また、Webコンテンツ15aにおいてその下にあった記事本文は、RSS内にあった、Webコンテンツ配信者が用意した記事の要約15bAに置き換えられる。
カラムC3は、RSS内の更新されたページのタイトル15bTのみでなく、カテゴリ15bCも使った例である。カテゴリ名はしばしばWebコンテンツ15a内にカテゴリ別のタイトルとして使われているし、カラムが何に関するコンテンツを持っているか端的に示すキーワードでもある。新たに更新された部分ではないが、カテゴリ名も要約コンテンツとしては有望である。
また、このカラムC3は、更新部分を多く含む上に非常に表示範囲が小さいため、要約しても表示範囲に納まらない。そこで、表示範囲が限られている場合は、RSS内の更新日時15bDを参照し、より新しいものを優先的に抜き出す。
カラムC4,C5は更新日時15aDが古い昨日の記事へのリンクを含むカラム要約の例である。昨日の古い記事はRSSから消えたか、更新日時がより新しい記事が優先されたために、抜き出されない。
また、カラムC5に関しては、RSSに含まれない広告部分も抜き出されず削除されている。このように、RSSを使うことには、広告のようなWebサイトに関係ない情報を除外できるという利点もある。
なお、本実施形態では、RSSを用いたが、Webコンテンツ15aの更新情報を示すメタ情報であるならAtomなど他のフォーマットの情報も利用できる。
また、更新部分を抜き出す方法自体についても、RSS等の配信される更新情報を使う方法に限定されるものではない。
例えば、クライアント装置20内に保存した前回訪問時のWebコンテンツとの差分を取ったり、タイトル等に添えられた更新日時をキーに判別したり、“New”や“Update”の文字列・アイコン画像を検出したりする手法が考えられる。
さらに、図9のカラムC1など、更新部分が全くなかったり非常に少なかったりするカラムだけは、本「更新部分抜き出し」によるカラム要約の生成方法とは別のカラム要約作成方法と組み合わせても良い。
次に、「一般的意味での要約(あらすじ)」によるカラム要約の生成方法について説明する。これは、文章をあらすじ化する、いわゆる一般的な意味でカラム内の文章を要約するものである。
この一般的な要約技術内容については、既存の技術を用いれば良く、本発明の要旨ではないので、その説明は省略する。
この生成方法を用いた結果は、例えば、図9のカラムC2のようなものになる。
なお、要約の他に、カラム内の文章から、キーワードのみを自動ピックアップし、それを列挙するなどしても良い。
一方、以上のようなテキスト要約に対して、Webコンテンツのプレビュー用要約コンテンツに使うカラム要約として「全文」を用いる場合には、要約としての意味はほぼ無い。このパターンは、図6(B)に示されるようなプレビュー用UIと組み合わせて初めて意味の出るパターンである。
なお、プレビュー用要約コンテンツ生成時の画像の取り扱いとしては、プレビュー用要約コンテンツ生成時、カラム内の画像は、カラム要約に含めなくても、あるいは縮小して含めても良い(図7の例では、画像はカラム要約から除外しており、図11の例ではカラムC4のように含めている)。また、画像を含める場合であっても、大きな画像は除外したり、アイコン状のサイズの小さいものだけを含める等しても良い。
但し、サイトによっては、タイトルに凝ったフォント・背景を使うために文字入り画像にしたり、入力フォームのボタンを画像にするなど、大事なテキストが画像化されている場合がある。このような場合に対応するために、「文字程度の高さを持ち、横長な画像」のみをカラム要約に含める、等しても良い。
次に、プレビュー用要約コンテンツをユーザに提示するためのプレビュー用UIの種類について、説明する。
本実施形態では、上述した作成方法により作成したプレビュー用要約コンテンツを、図6(B)に示したような手法でユーザに提示する。即ち、呈示の種類としては、「縮小」、「スクロール/スライド」、「バルーン」、「加工なし」の4種類がある。このうち、「縮小」には、「フォント縮小」と「サムネイル縮小」の2種類の縮小方法があり、「スクロール/スライド」には、「自動スクロール」、「マーキー」、「分割スライドショー」の3種類がある。
なお、これらの手法は必ず単独で用いる必要はなく、例えば「フォント縮小」+「自動スクロール」等、適宜組み合わせて用いることができる。
以下、プレビュー用UIの各種類について説明する。
図10は、プレビュー用UIとして「フォント縮小」UIを適用した画面遷移の例を示す図である。
この「フォント縮小」UIは、図10に(a)で示すように、プレビュー用要約コンテンツをフォントを縮小して表示し、表示範囲27aにおける当該カラム(この例ではカラムC3,C4)の表示領域からテキストが溢れないように表示するものである。なお、この例では、要約手法はカラム要約の「テキスト強度別切り出し」を用いている。勿論、このプレビュー用UIは、図6(A)に示した全種類のプレビュー用要約コンテンツを表示することができる。
この図10(a)の状態から、ユーザのスクロール操作やズーム操作等のユーザ操作が行なわれて、表示範囲27aにおける当該カラムの表示領域の面積が増えた場合には、図10に(b)で示すように、自動的にカラム要約の度合いを下げ、より長くオリジナルに近いプレビュー用要約コンテンツに差し替えたり、フォントの縮小度合いを下げてより大きいフォントで表示したりする。
そして、表示範囲27aにおける当該カラム(この例ではカラムC3)の表示領域の面積が閾値よりも大きくなったならば、図10に(c)で示すように、要約でないオリジナル表示に切り換える。また、表示領域の面積が閾値以下となったカラム(この例ではカラムC1)については、オリジナル表示画像からプレビュー用要約コンテンツの表示に切り換える。
図11は、プレビュー用UIとして「サムネイル縮小」UIを適用した画面遷移の例を示す図である。この「サムネイル縮小」UIは、図11に(a)で示すように、カラムのプレビュー用要約コンテンツのサムネイル画像を、表示範囲27aにおける当該カラム(この例ではカラムC3,C4)の表示領域の面積に合わせて縮小率や縦横比を変えることで、該表示領域内に縮小表示するものである。なお、この例では、要約手法は要約なしの「全文(そのまま)」を用い、また、サムネイルの縦横比は可変にしている。
この場合も、ユーザのスクロール操作やズーム操作等のユーザ操作が行なわれて、表示範囲27aにおける当該カラムの表示領域の面積の増減に応じて、縮小率や縦横比を自動で変更する。例えば、表示領域の面積が増えたならば、図11に(b)で示すように拡大表示する。加えて、プレビュー用要約コンテンツのカラム要約の度合いを適宜変えるようにしても良い。
そして、表示範囲27aにおける当該カラム(この例ではカラムC3)の表示領域の面積が閾値よりも大きくなったならば、図11に(c)で示すように、要約でないオリジナル表示に切り換える。また、表示領域の面積が閾値以下となったカラム(この例ではカラムC1)については、オリジナル表示画像からプレビュー用要約コンテンツの表示に切り換える。
なお、縦横比が極端に変わると見づらくなるので、縦横比の変更に上限を設けたり、あるいは、縦横比を全く変えず、サムネイルの上下または左右に余白を作る形で表示しても良い。
図12は、プレビュー用UIとして「自動スクロール」UIを適用した画面の例を示す図である。この「自動スクロール」UIは、カラムのプレビュー用要約コンテンツを、表示範囲27aにおける当該カラムの表示領域内で自動で繰り返しスクロールさせるものである。即ち、図12において双方向矢印で示す表示範囲内で、当該カラム(この例ではカラムC3)のプレビュー用要約コンテンツを、自動的に上端からゆっくりスクロールさせていき、下端に到達したら、また上端からスクロールさせていく、等の表示を行なう。なお、このプレビュー用UIは、図6(A)に示したプレビュー用要約コンテンツの何れの種類のカラム要約であっても表示することができる。
また、プレビュー用UIとしての「マーキー」UIや「分割スライドショー」UIは、特に図示はしないが、表示範囲27aにおける当該カラムの表示領域内で、スクロールではなく、当該表示領域に納まる行数ごとにプレビュー用要約コンテンツを分割し、マーキーで流す即ち左右方向のスクロールを行なったり、自動スライドショーのように切り換えて行うものである。
これら「スクロール/スライド」の何れのプレビュー用UIにおいても、前記「縮小」の場合と同様に、カラムの表示領域の面積が閾値よりも大きくなったならば、要約でないオリジナル表示に切り換える。
図13は、プレビュー用UIとして「バルーン」UIを適用した画面の例を示す図である。この「バルーン」UIは、カラムのプレビュー用要約コンテンツのサムネイル画像を、カラムにマウスポインタ27bが乗った、不図示のバルーンボタンが押された、等のタイミングで、バルーン27cの形態で表示するものである。このプレビュー用UIは、図6(A)に示したプレビュー用要約コンテンツの何れの種類のカラム要約であっても表示することができる。
なお、バルーン表示するカラムが非常に大きかったり、バルーン27cの面積を十分小さく抑えたいなど、要求事項により適宜要約コンテンツの要約の度合いを調整して良い。
一方、プレビュー用UIとして「加工なし」UIを適用した場合は、カラムのプレビュー用要約コンテンツを、縮小等なく同じ文字サイズのまま表示する。但し、全く何の処理も行なわないわけではなく、カラムの表示領域の面積の増減に従い、要約の度合いを調整する。
この場合も、カラムの表示領域の面積が閾値よりも大きくなったならば、要約でないオリジナル表示に切り換える。
このプレビュー用UIも、図6(A)に示した全種類のプレビュー用要約コンテンツを表示することができる。
なお、図6(B)に示した、プレビュー用UIの何れの種類を用いてプレビュー用要約コンテンツをユーザに提示するかは、ユーザが適宜選択できるようになっていることが好ましい。しかしながら、何れか一種類のみに固定されていても良いし、全種類ではなくてその内の幾つかが選択可能になっていても構わない。
次に、以上説明したようなプレビュー用要約コンテンツ表示を行なうための、前記クライアント装置20の動作を詳細に説明する。
図14(A)は、前記クライアント装置20におけるWebブラウザプログラム23aのメイン処理フローチャートである。
ユーザ操作に応じて、ROM23に記憶されているWebブラウザプログラム23aが起動されることで、ユーザ指定のWebサイトのサーバ装置10により配信されるWebコンテンツ15aが受信され取得されると、当該Webコンテンツ15aはそのHTMLのソース構造が解析されてRAM24内のフレームバッファ(図示せず)に描画される(ステップS1)。また、この処理は、ブラウザ起動操作だけでなく、リンクのクリックなど、新規Webページを読み込むユーザ操作をトリガにしても行われる。
ここまでは、通常のブラウザと同じ処理である。なお、通常のブラウザでは、RAM24内のフレームバッファに描画したWebコンテンツ15aを、図5に示すように、予め記憶している当該クライアント装置20の表示装置27のハードウェア情報および現在の拡大率等の表示モードの情報に基づいて決まるブラウザウィンドウの表示範囲27aで表示することとなる。
これに対して、本実施形態では、更に、カラムプレビュー制御処理を実行する。
Opera(登録商標)やNetFront(登録商標)など、多くの携帯端末向けブラウザが実装している機能である既存のアルゴリズムを用いて、RAM24内のフレームバッファに描画したWebコンテンツ15aをカラムに分割する(ステップS2)。
そして、ブラウザウィンドウの表示範囲27a内にあるが表示量が十分でないカラムを判別して、当該カラムに対してプレビュー化処理を行うことで、先に説明したようなプレビュー用要約コンテンツ表示を行なう(ステップS3)。このプレビュー化処理の詳細については後述する。
この後は、ユーザ操作によるスクロールやズームが行われたか否かを判別する(ステップS4)。ここで、そのようなユーザ操作があったと判別した場合には、そのユーザ操作に応じたスクロールやズームを行なう(ステップS5)。そして、表示範囲27a内の各カラムの表示量に変化がある度ごとに、再度、カラムのプレビュー化処理を行う(ステップS6)。
そしてその後、あるいは、前記ステップS4においてスクロールやズームのユーザ操作がないと判別した場合には、ユーザ操作により別のWebページに遷移するか、ブラウザの終了が指示されたか否かを判別する(ステップS7)。ここで、別のWebページへの遷移やブラウザ終了指示のユーザ操作がないと判別した場合には、前記ステップS4に戻って、前述の動作を繰り返す。
而して、別のWebページへの遷移またはブラウザ終了指示のユーザ操作が行なわれたと判別したならば、処理を終了する。
図14(B)は、前記ステップS3あるいはステップS6で実行されるカラムのプレビュー化処理の詳細を示すフローチャートである。
先ず、ブラウザウィンドウの表示範囲27a内つまり画面内にある全カラムを特定する(ステップS11)。
そして、全カラムに対し、個別のプレビュー化処理を行っていく。そのため、先ず、処理したカラム数を計数するためのメモリ(RAM24)上に設けたカウンタnに「1」をセットする(ステップS12)。その後、処理対象のn番目カラムの表示領域の面積が、プレビュー化閾値以下であるか否かを判定する(ステップS13)。
ここで、処理対象カラムの表示領域面積がプレビュー化閾値以下であると判別した場合には、カラム要約処理を実行して、当該カラムの表示領域の面積に合わせてプレビュー用要約コンテンツを生成する(ステップS14)。なお、このカラム要約処理の詳細については後述する。そして、生成したプレビュー用要約コンテンツをカラム表示領域に表示し、図6(B)で示した何れかのプレビュー用UIを付与する(ステップS15)。その後、カウンタnを「+1」して(ステップS16)、その結果が画面内にあるカラムの個数を超えたか否かを判別する(ステップS17)。そして、未だ越えていないならば、未処理のカラムがあるとして、前記ステップS13に戻って、次のカラムに対する処理を実行する。
一方、前記ステップS13において、処理対象カラムの表示領域面積がプレビュー化閾値を上回っていると判別した場合には、当該カラムがプレビュー用要約コンテンツを表示している状態であるのか否かを判別する(ステップS18)。ここで、プレビュー用要約コンテンツの表示ではなくオリジナル表示画像の表示状態であると判別したならば、前記ステップS16に進む。これに対して、プレビュー用要約コンテンツの表示状態であると判別した場合には、そのプレビュー化を解除、つまりプレビュー用要約コンテンツからオリジナル表示画像に表示を戻して(ステップS19)、前記ステップS16に進む。
こうして、ブラウザウィンドウの表示範囲27a内つまり画面内にある全てのカラムに対する処理が終了したならば、カウンタnの値は「その全カラム個数+1」となるので、前記ステップS17で、カウンタnの値が画面内にあるカラムの個数を超えたと判別して、当該カラムのプレビュー化処理を終了することとなる。
なお、前記ステップ14で実行されるカラム要約処理は、図6(A)に示した何れかの手法で、カラムを要約したプレビュー用要約コンテンツを生成する処理である。以下、テキスト要約の「テキスト強度別切り出し」と「更新部分抜き出し」の2例について説明する。テキスト要約の「一般的意味での要約(あらすじ)」については、既存の技術を用いれば良く、また、カラム要約として「全文」を用いる場合には、格別の処理は不要であるので、ここでは説明を省略する。
図15は、「テキスト強度別切り出し」によりプレビュー用要約コンテンツを生成する場合のカラム要約処理のフローチャートである。これは、図7で画面例を挙げた、カラム内の各行のテキスト強度を算出し、より強い(目立つ)テキストを優先的に切り出すことで、カラムの重要部分のみを抜き出す手法を実現するものである。
即ち、先ず、今処理中のカラムに対し、既にテキスト強度が算出されて、メモリ(RAM24)上に保存されているか否かを確認する(ステップS21)。これは、初回の要約処理では、必ずnoになる。算出済みであれば、前回の算出結果をそのまま再利用するため、後述するステップS25に進む。
テキスト強度が算出済みでないと判別した場合には、カラムを行に分割して、行ごとのテキスト強度を算出する(ステップS22)。このテキスト強度の算出の詳細については、後述する。次に、算出した強度の強い順、行番号の小さい(カラム内でより上にある)順にソートし(ステップS23)、そのソート結果をメモリに保存する(ステップS24)。
次に、メモリ(RAM24)上に設けた残り面積カウンタを、カラム表示領域の面積の値に初期化する(ステップS25)。そして、処理した行数を計数するためのメモリ(RAM24)上に設けたカウンタmに「1」をセットする(ステップS26)。その後、テキスト強度の強い順・行番号の小さい順にソートされた行からm個目の行を取り出し、前記残り面積カウンタの値で示される残り面積に表示可能な文字数だけ当該行から取り出す、つまり残り面積で許す限りの文字数を切り出して、メモリに保存する(ステップS27)。この切り出しによって残り面積が減るので、残り面積カウンタからm個目の行の表示面積を減算する(ステップS28)。
その後、残り面積カウンタで示される残り面積が0より大きいか否かを判別する(ステップS29)。ここで、まだ0よりも大きいと判別した場合には、カウンタmを「+1」して(ステップS30)、その結果がカラム内の行数を超えたか否かを判別する(ステップS31)。そして、未だ越えていないならば、未処理の行があるとして、前記ステップS27に戻って、次の行に対する処理を実行する。
こうして、前記ステップS29において残り面積が0以下となったと判別されるか、前記ステップS31においてカウンタmがカラム内の行数を超えた、つまり当該カラムの全ての行を処理したと判別されたならば、前記ステップS27にて切り出されてメモリに保存されている全テキストを結合することで、プレビュー用要約コンテンツを生成して(ステップS32)、該カラム要約処理を終了する。
なお、各切り出しテキストは、プレビュー用UIにおけるスタイル変更(フォント縮小等)がない限りは、オリジナル表示時と同じスタイルを維持するようにし、オリジナル表示と比べた時の違和感がないようにする。
また、図15のフローチャートでは、同じテキスト強度を持つ行に関しては、より上にあるものを優先して切り出すようにし、場合によっては下の方の行は全く表示されないこととなってしまう。そこで、同じレベルの強度にある行に関して、残り面積が足りず全行の全テキストが表示不可能な場合は、行ごとの切り出し文字数を均等配分で決め、全行の行頭が切り出されて表示されるようにしてもよい。この方法では、行の末尾は省略されてしまうが、全部の行が見えるので、下の方に重要なコンテンツがある場合も少なくとも行頭部分はユーザの目に入るようになる。
次に、前記ステップS22で算出される行ごとのテキスト強度について説明する。
「行ごとのテキスト強度」とは、テキストの「フォントサイズ」、「フォントウェイト(太さ)」、「背景」、等のスタイル情報のそれぞれについて強度ポイントを算出し、それらを合計したものである。
即ち、フォントサイズとフォントウェイトの値が大きくなる程、テキストの文字自体が目立つものになる。また、背景を1行だけ変えてその行を目立たせ、視覚的な区切りを作るのもWebサイトのよくあるデザインである。このような目立つテキストを含む行に対し、テキスト強度が大きくなるように算出方法を定める。
なお、ここで述べている算出方法はあくまで一例であり、「目立つ重要なテキストを特定する」という基本思想に則っていれば、どのような算出方法を用いても良い。
フォントサイズやフォントウェイトのような、スタイルの値が大きければテキストが目立つようになる指標値に対しては、まず、カラム内テキストが持つ指標値の最小値fminと最大値fmaxを求める。そして、指標値の最小値fminが0ポイント、最大値fmaxが100ポイントとなるように正規化し、その行内の指標値の最頻値fを代表値として、以下の(1)式により強度ポイントを算出する。
強度ポイント={(f−fmin)/(fmax−fmin)}×100 …(1)
即ち、行ごとの強度を出す場合は、その行内のフォントサイズ(またはウェイト)の最頻値fを代表値とし、上記式により求めた値がフォントサイズ(またはウェイト)強度ポイントの値となる。
一方、背景のような、より少数派であるほど強い指標値に関しては、まず、指標の各値ごとに文字数を集計する。
図16は、カラムの中の背景ごとの文字数を集計した結果の一例を示す図である。これは、カラムの中で、背景色#xxxを持つ文字数、背景画像○○.gifを持つ文字数、というように、背景ごとに文字数sを集計した結果である。
そして、最も文字数の多い多数派の背景は0ポイント、最も少ない少数派の背景は100ポイントとなるように正規化し、その行内の文字数をs、カラム内の行当たりの最大文字数をsmax、最小文字数をsminとして、以下の(2)式により背景強度ポイントを算出する。
背景強度ポイント={(s−smin)/(smax−smin)}×100 …(2)
即ち、文字数が少ないほど、ポイント数が高くなるようになっている。
そして、こうして算出したフォントサイズ,フォントウェイト,背景の各強度ポイント全てを加味した総合的な強度としてのテキスト強度ポイントは、各強度ポイントを以下の(3)式により重みづけ加算することで算出される。
テキスト強度ポイント= 重みfs×フォントサイズ強度ポイント
+重みfw×フォントウェイト強度ポイント
+重みbg×背景強度ポイント …(3)
個々の指標値の強度は0〜100ポイントに正規化されているが、テキストが目立つかどうかは、フォントサイズよりはフォントウェイト、背景による所が大きかったりする。そこで、個別に重みをつけることで調整している。
図17は、前記の算出式で計算した行ごとのテキスト強度の一例を示す図である。
これは、図4のカラムC3を題材とした例である。また、フォントサイズの重みfsは「1」、フォントウェイトの重みfwは「1.5」、背景の重みbgは「2」としている。
この例の場合では、テキスト強度ポイントは、カテゴリ名を示すタイトル(「社会・国際」等)が最も強く(400ポイント)、そのカテゴリ内の記事タイトルがその次に強い(250ポイント)。最も弱い(0ポイント)のは、記事タイトルの下に添えられる説明文である。
このように、より目立つ順に強くなるようテキスト強度が定められている。
図18は、「更新部分抜き出し」によりプレビュー用要約コンテンツを生成する場合のカラム要約処理のフローチャートである。これは、図9で画面例を挙げた、カラム内の最近更新された部分のみを抜き出し、カラムのプレビュー用要約コンテンツとする手法を実現するものである。
即ち、先ず、今処理中のWebページのWebコンテンツ15aに紐付けられたRSSが既に取得され、メモリ(RAM24)上に保存されているか否かを確認する(ステップS41)。これは、初回の要約処理では、必ずnoになる。取得済みであれば、前回取得したものをそのまま再利用するため、後述するステップS44に進む。
RSSが取得済みでないと判別した場合には、当該WebページのWebコンテンツ15aに紐付けられたRSSが存在するか否かを確認する(ステップS42)。ここで、RSSが存在しないと判別した場合には、この手法による要約は不可能であり、出力としてのプレビュー用要約コンテンツを空として、該カラム要約処理を終了させる。
これに対して、RSSが存在すると判別した場合には、そのRSSを新たに取得し、次回処理時に利用できるようにメモリに保存する(ステップS43)。
そして、当該WebページのWebコンテンツ15a内のテキスから、RSS内の更新情報に含まれるタイトルと一致するものを検索し、メモリに抽出保存する(ステップS44)。一致したテキストを、以降、タイトルテキストと称する。そして、このタイトルテキストが存在するか否かを判別し(ステップS45)、それが存在しなければ、このカラムに更新部分はないので、プレビュー用要約コンテンツを空として、該カラム要約処理を終了させる。
タイトルテキストが存在すると判別した場合には、そのそれぞれにつき、RSS内に要約文があれば取得する。そのため、まず、処理したタイトルテキストの数を計数するためのメモリ(RAM24)上に設けたカウンタmに「1」をセットする(ステップS46)。その後、RSSにm個目のタイトルテキストに対する要約があるか否かを判定する(ステップS47)。ここで、要約がなければ、後述するステップS49に進む。これに対して、要約があれば、RSSからその要約を取得して、m個目のタイトル用要約文としてメモリに保存する(ステップS48)。そして、カウンタmを「+1」して(ステップS49)、その結果がタイトルテキスト数を超えたか否かを判別する(ステップS50)。未だ越えていないならば、未処理のタイトルがあるとして、前記ステップS47に戻って、次のタイトルテキストに対する処理を実行する。
こうして、前記ステップS50においてカウンタmがタイトルテキスト数を超えた、つまり全てのタイトルテキストに対する処理を行なったと判別されたならば、メモリに保存されている全てのタイトルテキストとRSSから得た対応するタイトル用要約文を順番に結合することで、プレビュー用要約コンテンツを生成して(ステップS51)、該カラム要約処理を終了する。
なお、前記ステップS51のプレビュー用要約コンテンツの生成においては、RSSから得たタイトル用要約文は、対応するタイトルテキストの下に添える形で配置する。
また、各タイトルテキストは、プレビュー用UIによるスタイル変更(フォント縮小等)がない限りは、オリジナル表示と時同じスタイルを維持するようにし、オリジナル表示と比べた時の違和感がないようにする。
なお、前記ステップS42においてRSSがないと判別された場合や、前記ステップS47においてカラム内に更新部分が存在しないと判別された場合等、プレビュー用要約コンテンツを空にせざるを得ない場合は、そのカラムだけ図6(A)に挙げた別の手法でプレビュー用要約コンテンツを生成するようにしても良い。
以上のように、本発明の情報処理装置の一実施形態に係るサーバ・クライアント・システムによれば、ブラウザ上のWebページの表示において、Webコンテンツ15aをカラム単位に分割し、今ブラウザウィンドウの表示範囲27a内にあるカラムの表示面積が十分でない場合は、そのカラムの内容の要約であるプレビュー用要約コンテンツを作成して、その部分に表示するようにし、また、表示の方法もフォント縮小や自動スクロールなどプレビュー用UIをつけて表示することで、表示領域の小ささを補うようにしたので、小画面でズームしているなど一覧性の低い状態でも、画面の端に見えるカラムがどんな内容なのか概略を知ることができ、ユーザはカラム内容を確認するためだけに無駄にスクロールする手間が大幅に減るので、ユーザはより快適にWebブラウジングすることができる。なお、カラムをどのくらいの度合いで要約するか(短くするか、長めにするか)は、カラムの表示面積に応じて自動的に調整される。
また、スクロールやズーム等でカラムの表示領域の面積に変動があった場合は、テキストの強度の大きいものを優先に要約、更新部分を抜き出して要約、一般的意味での要約、というように、自動で要約の度合いを調整してプレビュー用要約コンテンツを作成するようにしているので、表示領域の面積に相応しい表示が行え、且つ、表示領域の面積が増えるに従ってよりオリジナルに近い表示になるようにすることができるので、その時々の表示の状態に合わせて、限られた画面スペースを有効に使うことが可能となる。
また、カラムの表示領域の面積が小さすぎ、十分な要約が表示できない場合でも、数回スクロールすれば十分な要約が表示できるので、通常の(要約を表示しない)場合と比して、ずっと少ない回数でカラムの内容を把握し、自分の興味ある情報か判断することができる。
さらに、プレビュー用要約コンテンツの生成時に、要約のために抜き出したテキストを、プレビュー用UI上のフォント縮小などの要求がない限り、オリジナル表示時と同じフォント・背景などのスタイルで表示するようにしているので、要約コンテンツの外観はオリジナル表示と違和感なく統一され、ユーザは「スクロールしたらいきなり背景色が変わった」「縮小状態から拡大したら、元と全く違うのでどこを表示しているのかわからない」等の戸惑いなくWebブラウジングができる。
また、フォント縮小、サムネイル縮小、自動スクロール、マーキー、分割スライドショー、サムネイルのバルーン、の何れかを含むプレビュー表示を行うことで、表示領域の小ささを補うことが可能であり、更に、どのようなプレビュー用UIを付加するかをユーザが任意に選択できるようにすれば、ユーザが最も見易いと感じる表示形態で表示を行なうことが可能となる。
なお、前記一実施形態は、通常のサーバ・クライアント・システムにおけるクライアント装置20のWebブラウザプログラム23aに対し、前記カラムプレビュー制御機能を搭載してユーザ指定のWebサイトのコンテンツ15aを取得し表示制御する場合について説明した。これに対し、サーバベース・コンピューティング・システム(SBC)におけるシン・クライアント端末にてユーザ指定のWebサイトのコンテンツ15aを取得し表示する場合には、当該シン・クライアント端末からの入力イベントによって起動するサーバ装置のWebブラウザに対し、前記同様のカラムプレビュー制御機能を搭載すればよい。
なお、前記一実施形態において記載した情報処理装置による各処理の手法、すなわち、図14,図15,図18のフローチャートに示す処理の各手法は、何れもコンピュータに実行させることができるプログラムとして、メモリカード(ROMカード、RAMカード等)、磁気ディスク(フロッピディスク、ハードディスク等)、光ディスク(CD−ROM、DVD等)、半導体メモリ等の外部記憶装置25(15)の媒体に格納して配布することができる。そして、情報処理装置のコンピュータ(CPU21(11))は、この外部記憶装置25(15)の媒体に記憶されたプログラムを記憶装置(フラッシュROM23(13)やRAM24(14))に読み込み、この読み込んだプログラムによって動作が制御されることにより、前記一実施形態において説明したカラムプレビュー制御機能を実現し、前述した手法による同様の処理を実行することができる。
また、前記各手法を実現するためのプログラムのデータは、プログラムコードの形態として通信ネットワーク(N)上を伝送させることができ、この通信ネットワーク(N)に接続されたコンピュータ装置(プログラムサーバ)から前記のプログラムデータを取り込んで記憶装置(フラッシュROM23(13)やRAM24(14))に記憶させ、前述したカラムプレビュー制御機能を実現することもできる。
なお、本願発明は、前記一実施形態に限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で種々に変形することが可能である。さらに、前記一実施形態には種々の段階の発明が含まれており、開示される複数の構成要件における適宜な組み合わせにより種々の発明が抽出され得る。