(57)【要約】  ブログサービスを提供するサーバにおいてブログの数やサイズの増大によりメモリリソースが徐々に圧迫されていくため、このメモリ負担を低減する。そこでブログ全体の人気度を示す第１指標値と、そのブログに含まれる記事ごとのアクセス可能性を示す第２指標値を取得する。そして第１指標値と第２指標値に基づいて、記事ごとに、その記事を圧縮するか否かを判定する。
2018073941.tif 000002
【特許請求の範囲】
【請求項１】
１又は複数の記事が含まれるブログの人気度を示す第１指標値を取得する第１取得部と、
前記ブログに含まれる複数の記事ごとに、当該記事に対するアクセス可能性を示す第２指標値を取得する第２取得部と、
ブログに含まれる記事について、前記第１指標値と前記第２指標値とに基づいて、圧縮するか否かを判定する判定部と、を備えた
情報処理装置。
【請求項２】
前記判定部によって圧縮すると判定された記事について圧縮を行い、また既に圧縮された記事に対してのアクセスが発生した場合に該記事の解凍を行う圧縮解凍部を備えた
請求項１に記載の情報処理装置。
【請求項３】
前記判定部は、前記第１指標値と前記第２指標値とに基づいて、既に圧縮した記事を解凍するか否かを判定する
請求項１に記載の情報処理装置。
【請求項４】
前記判定部は、記事内容に基づいて、既に圧縮した記事を解凍するか否かを判定する
請求項１に記載の情報処理装置。
【請求項５】
前記判定部は、ブログの人気度の変化を監視し、或るブログについて人気度の上昇傾向を検知した場合に、該ブログに含まれる圧縮済の記事の全部又は一部を解凍する記事と判定する
請求項１に記載の情報処理装置。
【請求項６】
圧縮された記事についてアクセスに応じて解凍が行われた場合、前記判定部は、解凍から所定期間、当該記事を圧縮する記事と判定しない
請求項１に記載の情報処理装置。
【請求項７】
前記第１指標値は、ブログ全体についての総ページビュー数、ブログにアクセスしたユニークユーザ数、ブログに設定された総被リンク数、ブログに記述された総コメント数、ブログのページランクを示す値、ブログ全体についてのページビューの増加傾向を示す値、ブログ全体についてのデータ量の増加傾向を示す値、の少なくとも一部に基づいて求められた値である
請求項１に記載の情報処理装置。
【請求項８】
前記第２指標値は、記事ごとのページビュー数、記事にアクセスしたユニークユーザ数、記事に設定された被リンク数、記事のページランクを示す値、記事のページビューの増加傾向を示す値、記事のアクセスのない期間の長さを示す値、特定語句の有無を示す値、の少なくとも一部に基づいて求められた値である
請求項１に記載の情報処理装置。
【請求項９】
情報処理装置が実行する情報処理方法として、
１又は複数の記事が含まれるブログの人気度を示す第１指標値を取得するステップと、
前記ブログに含まれる複数の記事ごとに、当該記事に対するアクセス可能性を示す第２指標値を取得するステップと、
ブログに含まれる記事について、前記第１指標値と前記第２指標値とに基づいて、圧縮するか否かを判定するステップと、を行う
情報処理方法。
【請求項１０】
１又は複数の記事が含まれるブログの人気度を示す第１指標値を取得する手順と、
前記ブログに含まれる複数の記事ごとに、当該記事に対するアクセス可能性を示す第２指標値を取得する手順と、
ブログに含まれる記事について、前記第１指標値と前記第２指標値とに基づいて、圧縮するか否かを判定する手順と、
を情報処理装置に実行させるプログラム。
【請求項１１】
１又は複数の記事が含まれるブログの人気度を示す第１指標値を取得する手順と、
前記ブログに含まれる複数の記事ごとに、当該記事に対するアクセス可能性を示す第２指標値を取得する手順と、
ブログに含まれる記事について、前記第１指標値と前記第２指標値とに基づいて、圧縮するか否かを判定する手順と、
を情報処理装置に実行させるプログラムを記憶した記憶媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は情報処理装置、情報処理方法、プログラム、記憶媒体に関し、特にブログを管理するサーバ装置への適用に好適な技術に関する。
【背景技術】
【０００２】
インターネットを利用したサービスの１つとしてブログ環境を提供するサービスが知られている。ユーザはブログとしての任意の文章や画像による記事をサーバにアップロードし、当該ユーザの書き込み記事として保存してもらう。保存されたブログは、例えばウェブページの形式で一般に公開される。また公開範囲を限定したり、非公開のものもある。
多くのユーザは、自己発信のツールとしたり、或いは個人的な日記代わりなどとして、このようなブログサービスを利用している。
特許文献１には、ブログに関する技術、例えば記事のアップロードに関する技術が開示されている。
特許文献２には、サーバの残容量不足に応じたコンテンツ削除に関する技術が開示されている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００７−３２８７５０号公報
【特許文献２】特開２０１０−４４４６８号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
ブログは無料で始められるものも多く、とりあえず始めてみたがほとんど更新しないユーザも多い。一方で頻繁に記事を更新して人気を集めるユーザまで玉石混交であり、ブログや個々の記事におけるアクセス数はさまざまである。
例えば、あるユーザがブログを開設して２、３の記事をアップしたものの、その後更新せず、或いはログインもせず、アクセスもないまま長期間放置されているようなブログも存在する。このようなブログはユーザにとっても不要である場合があり、ブログサービスを提供する事業者にとっても徒に記憶リソースを圧迫するものとなっている。【０００５】
そこで、アクセス可能性の低い記事については圧縮しておき、アクセスがあった場合に解凍して配信することが考えられる。
ただし圧縮や解凍の処理は負荷が高い。また、アクセスの際に解凍が必要となると、その処理時間により閲覧ユーザにページアクセスの遅れを感じさせるなど閲覧時のパフォーマンス低下を生じさせる恐れがある。これらのことから、できるだけ圧縮や解凍の処理回数を減らしたい。
そこで本発明は、圧縮する記事を適切に選択し、なるべく圧縮や解凍の処理を少なくしつつ、記憶リソースの有効な利用を図ることを目的とする。
【課題を解決するための手段】
【０００６】
本発明に係る情報処理装置は、１又は複数の記事が含まれるブログの人気度を示す第１指標値を取得する第１取得部と、前記ブログに含まれる複数の記事ごとに、当該記事に対するアクセス可能性を示す第２指標値を取得する第２取得部と、ブログに含まれる記事について、前記第１指標値と前記第２指標値とに基づいて、圧縮するか否かを判定する判定部と、を備える。
ブログに含まれる記事の内で、アクセス可能性の小さい記事（例えば不人気記事）を圧縮することを考える。このときに、アクセス可能性の小さい記事が、人気の高いブログ内の記事であるか、人気の低いブログ内の記事であるかも考慮して、圧縮するか否かを判定する。【０００７】
上記した情報処理装置においては、前記判定部によって圧縮すると判定された記事について圧縮を行い、また既に圧縮された記事に対してのアクセスが発生した場合に該記事の解凍を行う圧縮解凍部を備えることが考えられる。
この圧縮解凍部は、判定部の判定に沿って適切に選択された記事の圧縮を行う。またアクセス可能性が小さいとして圧縮された記事であっても、アクセスが発生することは当然あり得る。そのような場合、解凍処理を行うことで、アクセスしたユーザに対して記事を適切に提供する。【０００８】
上記した情報処理装置においては、前記判定部は、前記第１指標値と前記第２指標値とに基づいて、既に圧縮した記事を解凍するか否かを判定することが考えられる。
一旦圧縮した記事についても、その後、定期的又は不定期に第１、第２指標値を取得して、アクセス可能性の変化を確認する。もし最新の状況としてアクセス可能性が高くなっていたら、解凍しておくように判定する。【０００９】
上記した情報処理装置においては、前記判定部は、記事内容に基づいて、既に圧縮した記事を解凍するか否かを判定することが考えられる。
例えば圧縮した記事の内容として、或る設定したキーワードや時事語を含む記事、特定のテーマの記事などを抽出し、これらを解凍対象とする。【００１０】
上記した情報処理装置においては、前記判定部は、ブログの人気度の変化を監視し、或るブログについて人気度の上昇傾向を検知した場合に、該ブログに含まれる圧縮済の記事の全部又は一部を解凍する記事と判定することが考えられる。
或るブログが何らかの人気記事によってアクセス数が顕著に上昇したような場合、そのブログに含まれる別の記事は、これまでアクセスされていなかったとしても、今後アクセスされる可能性が高まる。そこで解凍するように判定する。【００１１】
上記した情報処理装置においては、圧縮された記事についてアクセスに応じて解凍が行われた場合、前記判定部は、解凍から所定期間、当該記事を圧縮する記事と判定しないことが考えられる。
つまりアクセス時に解凍した記事は、所定期間の間は解凍したままとする。【００１２】
上記した情報処理装置においては、前記第１指標値は、ブログ全体についての総ページビュー数、ブログにアクセスしたユニークユーザ数、ブログに設定された総被リンク数、ブログに記述された総コメント数、ブログのページランクを示す値、ブログ全体についてのページビューの増加傾向を示す値、ブログ全体についてのデータ量の増加傾向を示す値、の少なくとも一部に基づいて求められた値であることが考えられる。
これらの値はブログ全体の人気度に応じた値となりやすい。【００１３】
上記した情報処理装置においては、前記第２指標値は、記事ごとのページビュー数、記事にアクセスしたユニークユーザ数、記事に設定された被リンク数、記事のページランクを示す値、記事のページビューの増加傾向を示す値、記事のアクセスのない期間の長さを示す値、特定語句の有無を示す値、の少なくとも一部に基づいて求められた値であることが考えられる。
これらの値は記事毎のアクセス可能性に応じた値となりやすい。【００１４】
本発明に係る情報処理方法は、１又は複数の記事が含まれるブログの人気度を示す第１指標値を取得するステップと、前記ブログに含まれる複数の記事ごとに、当該記事に対するアクセス可能性を示す第２指標値を取得するステップと、ブログに含まれる記事について、前記第１指標値と前記第２指標値とに基づいて、圧縮するか否かを判定するステップと、を行う。
この情報処理方法により、情報処理装置によって適切に圧縮する記事を判定することができる。
本発明に係るプログラムは、上記各ステップに相当する手順を情報処理装置に実行させるプログラムである。本発明に係る記憶媒体は、上記プログラムを記憶したものである。これらにより上述の情報処理装置の処理を実現する。
【発明の効果】
【００１５】
本発明によれば、記事の圧縮によって記憶リソースの圧迫を抑えるとともに、なるべく圧縮や解凍の処理機会が少なくなるように、ブログ内で圧縮する記事を適切に選択することができ、サーバの処理負担の低減や、閲覧時のパフォーマンス向上を図ることができる。
【図面の簡単な説明】
【００１６】
【図１】本発明の実施の形態のブログサーバを含むネットワークの説明図である。
【図２】実施の形態で利用できるコンピュータ装置のブロック図である。
【図３】実施の形態のブログサーバの機能構成の説明図である。
【図４】実施の形態の管理データベースの説明図である。
【図５】第１の実施の形態の圧縮判定処理のフローチャートである。
【図６】第１の実施の形態の圧縮処理のフローチャートである。
【図７】実施の形態のアクセス時の処理のフローチャートである。
【図８】実施の形態の解凍後の処理例のフローチャートである。
【図９】第２の実施の形態の圧縮判定のための処理の変形例のフローチャートである。
【図１０】第３の実施の形態の圧縮解凍判定処理のフローチャートである。
【図１１】第３の実施の形態の圧縮解凍処理のフローチャートである。
【図１２】第４の実施の形態の解凍判定処理のフローチャートである。
【図１３】第４の実施の形態の解凍処理のフローチャートである。
【図１４】第５の実施の形態の解凍判定処理のフローチャートである。
【図１５】第６の実施の形態の圧縮判定処理のフローチャートである。
【発明を実施するための形態】
【００１７】
以下、実施の形態を次の順序で説明する。
＜１．システム構成＞
＜２．ブログサーバ及びデータベース＞
＜３．第１の実施の形態＞
＜４．第２の実施の形態＞
＜５．第３の実施の形態＞
＜６．第４の実施の形態＞
＜７．第５の実施の形態＞
＜８．第６の実施の形態＞
＜９．まとめ及び変形例＞
＜１０．プログラム及び記憶媒体＞
【００１８】
なお、以下の説明において、“ブログ”とは、ウェブログあるいは単にブログと呼ばれる日記形式のウェブページのことである。より具体的には、ブログサーバはユーザに対してブログを形成する環境（記憶容量やウェブページ）を提供し、ユーザは投稿等の形式で文章や画像による記事を自分のブログにアップロードする。ブログサーバは通常、当該記事を一般（又は限定した範囲）の閲覧に供する。但し非公開のものとしてもよい。
記事の内容については特に限定されない。ユーザが情報発信に用いる内容でも、個人的な日記等の内容でもよい。また「ブログ」と呼ばれていないものであっても、同等のものを含む。
【００１９】
“記事”とは、ブログを構成する要素であって、文章や画像によって構成された１つの単位（例えば投稿単位）のことを指す。内容には関わらない。なお、必ずしも１つの話題としての記事ではなく、１又は複数の話題について１つのＵＲＬで閲覧される記事群を指すものと考えても良い。
【００２０】
“ユーザ”とは、自己のブログに記事を書き込む記述者としてのユーザ（いわゆるブロガー）と、他人又は自己のブログを閲覧する閲覧者としてのユーザが想定される。これらを区別して「記述者」「閲覧者」と表記する。もちろん一人のユーザがある時点では記述者となり、ある時点では閲覧者となることが通常に想定される。
【００２１】
“圧縮”とは、いわゆるデータ圧縮のことであり、テキストデータや画像データ等の各種データを、そのデータの実質的な性質を保ったまま、データ量を減らした別のデータに変換することである。
“解凍”とは、圧縮されたデータを圧縮前の状態に戻すことである。但し、圧縮時にいわゆる非可逆圧縮が行われた場合など、データが完全に圧縮前の状態に戻らない場合も含む。本明細書では、少なくとも記事の内容の閲覧等が可能な状態とすることを“解凍”ということとする。
【００２２】
＜１．システム構成＞
図１に実施の形態のブログサーバ１を含むネットワークシステムの構成例を示す。
本実施の形態に係るネットワークシステムは、ブログサーバ１と複数のユーザ端末５がネットワーク２により相互に通信可能に接続されている。
またブログサーバ１は各種データベースにアクセス可能とされている。なお、以下「データベース」については「ＤＢ」と表記する。図ではブログサーバ１がアクセス可能なＤＢとしてブログＤＢ５１、画像ＤＢ５２、管理ＤＢ５３を例示している。
【００２３】
ネットワーク２の構成は多様な例が想定される。例えば、インターネット、イントラネット、エキストラネット、ＬＡＮ（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）やフラッシュメモリ装置などにより構成される。
通信部１０９はネットワーク２を介しての通信処理や機器間通信を行う。
入出力インタフェース１０５にはまた、必要に応じてメディアドライブ１１０が接続され、磁気ディスク、光ディスク、光磁気ディスク、或いは半導体メモリなどのリムーバブルメディア１１１が適宜装着され、リムーバブルメディア１１１に対する情報の書込や読出が行われる。
【００２８】
このようなコンピュータ装置では、通信部１０９による通信によりデータやプログラムのアップロード、ダウンロードが行われる。またリムーバブルメディア１１１を介したデータやプログラムの受け渡しが可能である。
ＣＰＵ１０１が各種のプログラムに基づいて処理動作を行うことで、ブログサーバ１やユーザ端末５としての必要な情報処理や通信が実行される。
なお、ブログサーバ１やユーザ端末５を構成する情報処理装置は、図２のようなコンピュータ装置が単一で構成されることに限らず、複数のコンピュータ装置がシステム化されて構成されてもよい。複数のコンピュータ装置は、ＬＡＮ等によりシステム化されていてもよいし、インターネット等を利用したＶＰＮ等により遠隔地に配置されたものでもよい。複数の情報処理装置には、クラウドコンピューティングサービスによって利用可能なサーバ群（クラウド）としての情報処理装置が含まれてもよい。
【００２９】
＜２．ブログサーバ及びデータベース＞
図３に１又は複数の情報処理装置で構成されるブログサーバ１としての機能構成および各種のＤＢを示す。
ブログサーバ１としての各機能は、情報処理装置においてＣＰＵ１０１でプログラムに応じて実行される処理により実現される機能である。但し以下説明する全部又は一部の各構成の処理をハードウエアにより実現してもよい。
また各機能をソフトウエアで実現する場合に、各機能がそれぞれ独立したプログラムで実現される必要はない。１つのプログラムにより複数の機能の処理が実行されてもよいし、１つの機能が複数のプログラムモジュールの連携で実現されてもよい。
また各機能は複数の情報処理装置に分散されていてもよい。さらに機能の１つが、複数の情報処理装置によって実現されてもよい。
【００３０】
ブログサーバ１は、図示するようにブログ管理部１１、第１取得部１２、第２取得部１３、判定部１４、圧縮解凍部１５としての機能を備える。
【００３１】
ブログ管理部１１は、ブログサービスを提供するサーバとして必要な処理を実行する。例えばユーザへのブログ環境の提供、記述者としてのユーザの情報の管理、作成されたブログの記憶管理、各ブログに関する情報管理、アクセス要求に応じたブログ（記事）のウェブページの配信などを行う。
またブログ管理部１１は管理ＤＢ５３の情報の更新や読み出しを逐次行う。
【００３２】
第１取得部１２は、ブログ内の記事について圧縮するか否かの判定を行う際などに、その判定に用いる情報として、ブログの人気度を示す第１指標値を取得する処理を行う。
ブログについての第１指標値とは、ブログ全体についての総ページビュー数、ブログにアクセスしたユニークユーザ数、ブログに設定された総被リンク数、ブログに記述された総コメント数、ブログのページランク、ブログ全体についてのページビューの増加傾向を示す値、ブログ全体についてのデータ量の増加傾向を示す値、ブロクに掲載された広告に対するクリック数などである。
【００３３】
第２取得部１３は、同じくブログ内の記事について圧縮するか否かの判定を行う際などに、その判定に用いる情報として、ブログに含まれる複数の記事ごとに、当該記事に対するアクセス可能性を示す第２指標値を取得する処理を行う。
第２指標値としては、記事ごとのページビュー数、記事にアクセスしたユニークユーザ数、記事に設定された被リンク数、記事のページランクを示す値、記事のページビューの増加傾向を示す値、記事のアクセスのない期間の長さを示す値、記事とともに掲載された広告に対するクリック数、特定語句の有無を示す値などである。
【００３４】
判定部１４は、ブログに含まれる記事について、第１指標値と第２指標値とに基づいて、圧縮するか否かを判定する処理を行う。
また判定部１４は、圧縮された記事について、第１指標値と第２指標値とに基づいて、解凍するか否かを判定する処理や、内容に応じて解凍するか否かを判定する処理や、ブログの人気傾向などに応じて解凍するか否かを判定する処理なども行う。
具体例は各実施の形態の処理として後述する。
【００３５】
圧縮解凍部１５は、判定部１４によって圧縮すると判定された記事を圧縮する処理を行う。
また圧縮解凍部１５は、既に圧縮された記事に対してのアクセスが発生した場合に、圧縮に対する解凍処理を行う。
さらに圧縮解凍部１５は、既に圧縮された記事について判定部１４によって解凍すると判定された記事を解凍する処理を行う。
【００３６】
図３ではブログサーバ１がアクセスするＤＢとしてブログＤＢ５１、画像ＤＢ５２、管理ＤＢ５３を示している。
ブログＤＢ５１は、各記述者についてのブログデータを保存するＤＢである。各ブログのウェブページデータが保存され、また各ブログについては、記述者の投稿に応じて記事が追加されていく。
ブログを形成するウェブページのデータは、例えば、ＨＴＭＬ（HyperText Markup Language）やＸＨＴＭＬ（Extensible HyperText Markup Language）などの構造化文書ファイルである。構造化文書ファイルには、記述者が投稿した記事のテキストデータや各種画像等の画像データの指定情報と、それらの配置や表示態様（文字色やフォントや大きさや装飾など）が記述されている。
またブログに対しては閲覧者がコメントを投稿することもできる。そのような閲覧者からのコメントデータもブログやブログ内の個々の記事に紐づけてブログＤＢ５１に保存される。
ブログサーバ１は、ユーザ端末５から或るブログについてのアクセス要求があった場合は、要求されたブログページをブログＤＢ５１から読み出してユーザ端末５に配信することになる。
【００３７】
画像ＤＢ５２は、ブログに添付された画像データ（静止画データや動画データ）を保存するＤＢである。
ブログ内の記事には、画像を添付することができるが、例えばブログＤＢ５１には記事データ及び記事データに対応した画像の指定情報（リンク情報）が記憶される。そして画像データ自体は画像ＤＢ５２に保存される。
画像が添付されたブログ記事へのアクセス要求の場合、そのウェブページデータがユーザ端末５においてブラウザにより表示されるが、その際、ユーザ端末５はウェブページ上のリンク設定により画像データをブログサーバ１に要求する。ブログサーバ１は当該要求に応じて画像データを画像ＤＢ５２から読み出し、ユーザ端末５に配信する。これによりユーザ端末５上で、画像付きのブログ記事が表示される。
なおこれは一例であり、予め画像データを含むウェブページデータをブログＤＢ５１に格納するようにしてもよい。
【００３８】
管理ＤＢ５３は、各ブログの管理のための情報を格納するＤＢである。
管理ＤＢ５３の内容の一例を図４に示す。
１つのブログについてはブログＩＤ（Identification）が設定され、ブログＩＤにより付随する情報が管理される。例えば各ブログ（ブログＩＤ）毎に、ユーザ情報、ブログ管理情報、ブログ実績情報、サイズ情報、判定情報、圧縮解凍情報、圧縮記事タグなどが、逐次更新されながら管理される。
【００３９】
ユーザ情報は、ブログを開設した記述者としてのユーザ（ブロク管理者）の情報である。例えばユーザ情報としては、ユーザＩＤ、管理者としてのログインパスワード、ユーザの住所、氏名、年齢等の属性情報、管理者としてのログイン日時、などの情報が含まれる。
【００４０】
ブログ管理情報は、ブログ自体の属性情報である。例えばブログのＵＲＬ（Uniform Resource Locator）、ブログのジャンル情報、ブログの開設日時、ブログに含まれる記事数、更新日時情報、ブログのレイアウト情報、リンク設定情報等が含まれる。
【００４１】
ブログ実績情報としては、ブログの人気の指標となる情報や、各記事のアクセス可能性の指標となる情報が記憶される。つまり上述の第１指標値や第２指標値である。
従ってブログの人気の指標となる情報（第１指標値）として、総ページビュー数、アクセスしたユニークユーザ数、総被リンク数、総コメント数、ブログのページランク、ブログ全体についてのページビューの増加傾向を示す値、ブログ全体についてのデータ量の増加傾向を示す値、広告クリック数などが逐次更新されていく。
これらの値はブログ全体の人気度に応じた値となり第１指標値として適している。
【００４２】
またブログ実績情報として、各記事のアクセス可能性の指標となる情報（第２指標値）が各記事に対応して記憶される。例えば各記事についてのページビュー数、アクセスしたユニークユーザ数、被リンク数、記事のページランクを示す値、記事のページビューの増加傾向を示す値、記事のアクセスのない期間の長さを示す値、特定語句の有無を示す値などである。
これらの値は記事毎のアクセス可能性に応じた値となり、第２指標値として適している。
【００４３】
サイズ情報は、そのブログ全体のデータサイズの情報である。また各記事のサイズ情報を記憶しても良い。サイズ情報は、ブログの更新に応じて更新される。
なお、サイズ情報としてブログＤＢ５１に記憶したデータサイズと画像ＤＢ５２に記憶した画像データのデータサイズを合わせて管理してもよいし、それぞれ別個に管理してもよい。
【００４４】
判定情報は、各記事について判定部１４が第１指標値、第２指標値に基づいて判定した、圧縮するか否かの情報である。また圧縮した記事について判定部１４が判定した、解凍するか否かの情報も含む。即ち圧縮可／不可や解凍可／不可を示す情報である。これらは例えばフラグデータとして更新される。
なお、圧縮可／不可や解凍可／不可を示すフラグは、その後の圧縮処理や解凍処理で圧縮や解凍とすべきことを示す情報となる。従ってこれらのフラグは圧縮や解凍が行われた際にはクリアされればよい。
また判定情報には、ブログの人気度の判定結果の情報を含む場合もある。
【００４５】
圧縮解凍情報は、ブログ内の各記事について、オリジナル状態／圧縮状態／圧縮から解凍した状態など、圧縮や解凍の実行状況を示す情報である。圧縮解凍情報は、これらを識別するステータス情報として構成されればよい。
また圧縮や解凍の履歴情報として、圧縮や解凍の実行日時も記憶される。
【００４６】
圧縮記事タグは、各記事について内容に応じて設定されたタグである。
例えば記事に出現するキーワード的な語句、時事的な語句、記事のジャンルなどがタグとして設定され、登録される。例えば圧縮を行う際に記事内容に応じたタグが作成されて圧縮記事タグとして登録される。
【００４７】
以上の各ＤＢ（ブログＤＢ５１、画像ＤＢ５２、管理ＤＢ５３）は、ブログサーバ１がアクセス可能とされていればどのような形態で実現されていてもよい。例えばブログサーバ１と同一システム内の記憶部に各ＤＢのすべてが形成されていてもよいし、各ＤＢの一部又は全部が別体、遠隔地等のコンピュータシステムに設けられていてもよい。もちろん各ＤＢが一つの装置（例えば一つのＨＤＤ等）内に形成されている必要はない。また各ＤＢのそれぞれが、それぞれ１つのＤＢとして構成される必要もない。例えば管理ＤＢ５３として記憶される情報が、複数のＤＢ（例えばブログに関するユーザ管理用のＤＢとブログ管理用のＤＢなど）により記憶管理されてもよい。以上の各ＤＢは、実施の形態の処理に関連する情報の記憶部を、それぞれ１つのＤＢの形態で例示したものに過ぎない。
【００４８】
＜３．第１の実施の形態＞
ブログサーバ１が実行する第１の実施の形態としての処理例を説明していく。
現在、一般ユーザにとってブログは容易に始められるが、少しの記事をアップロードした後、飽きてしまうユーザもいれば、長く続ける人もいる。また、アクセスの多い人気ブログもあれば、ほとんど閲覧者がいないブログもある。
ブログサーバ１としては、これら多様なユーザに対して分け隔て無く、ブログを維持する必要があるが、そのため記憶リソースの負担が大きくなりがちである。
そこで本実施の形態では、ブログサーバ１は、アクセス可能性の低い記事については圧縮して保存する。圧縮した記事にアクセスがあった場合には、解凍して配信する。
但し、圧縮処理・解凍処理もある程度の処理負担がかかるため、あまり頻繁に行いたくない。また、圧縮した記事を解凍して配信することは、処理負担と共に応答時間も増えることになり、ユーザにパフォーマンス低下を感じさせる可能性もあるため、なるべく圧縮した記事へのアクセスが発生しないようにしたい。
そこで本実施の形態では、アクセス可能性が小さい記事をより的確に選択して圧縮対象とする。
【００４９】
図５はブログサーバ１が実行する圧縮判定処理例を示している。
なお、図５以降、後述する図１５までのフローチャートで示す処理は、ブログサーバ１が図３に示したブログ管理部１１、第１取得部１２、第２取得部１３、判定部１４、圧縮解凍部１５としての機能により実行する処理である。
【００５０】
ブログサーバ１は図５の圧縮判定処理を、逐次、ブログＤＢ５１に保存している全部又は一部のブログに対して実行する。これは、記事毎に圧縮可否を判定する処理である。
ステップＳ１０１でブログサーバ１は、圧縮判定処理の対象とする１つのブログを特定する。例えば順番に１つのブログを選択するものとすればよい。
【００５１】
ステップＳ１０２でブログサーバ１は、処理対象としたブログについての第１指標値を取得する。例えば管理ＤＢ５３から、当該ブログ（ブログＩＤ）について記憶されているブログ実績情報に含まれる第１指標値を読み出す。
具体的には、当該ブログの、総ページビュー数、アクセスしたユニークユーザ数、総被リンク数、総コメント数、ブログのページランク、ブログ全体についてのページビューの増加傾向を示す値、ブログ全体についてのデータ量の増加傾向を示す値などの全部又は一部を読み出す。そしてこれらを当該ブログの人気度を測る材料とする。
【００５２】
そしてブログサーバ１は、ブログ内の各記事について圧縮可否を判定するためにステップＳ１１０〜Ｓ１１５の処理を行う。
まずステップＳ１１０でブログサーバ１は、ブログ内の１つの記事を選択する。
ステップＳ１１１でブログサーバ１は、選択した記事が既に圧縮済であるか否かを確認する。これは例えば管理ＤＢ５３における圧縮解凍情報を参照すればよい。
もし圧縮済であれば、圧縮可否判定は不要なためステップＳ１１５に進む。ステップＳ１１５で全ての記事について処理を終えたか否かを確認し、終えていなければステップＳ１１０に戻って次の記事を選択する。
なお、ステップＳ１１５の全記事とは、今回処理対象とする記事の全てという意味である。ブログ内の全ての記事という場合もあるし、ブログ内の一部（例えば特定の期間に投稿された記事など）でもよい。
【００５３】
ステップＳ１１０で処理対象に選択した記事が圧縮されていない状態の記事である場合、ブログサーバ１はステップＳ１１１からＳ１１２に進み、当該記事についての第２指標値を取得する。例えば管理ＤＢ５３から、当該ブログについて記憶されているブログ実績情報に含まれる、当該記事の情報を読み出す。例えば当該記事についてのページビュー数、アクセスしたユニークユーザ数、被リンク数、当該記事のページランクを示す値、当該記事のページビューの増加傾向を示す値、当該記事のアクセスのない期間の長さを示す値、当該記事とともに掲載された広告のクリック数などである。
【００５４】
そしてブログサーバ１はステップＳ１１３で、当該記事について圧縮可否判定を行う。ここではアクセス可能性が大きいか、小さいかを判定する。そしてアクセス可能性が大きければ圧縮すべきでないと判定し、アクセス可能性が小さければ圧縮してもよい記事（或いは圧縮すべき記事）と判定する。
ブログサーバ１はこの判定をステップＳ１０２で取得した第１指標値と、ステップＳ１１２で取得した第２指標値に基づいて行う。
具体的には、記事自体のアクセス可能性のみで圧縮可否を判断せず、第１指標値によりブログの人気度を判定し、それを反映させた圧縮可否判定を行う。
【００５５】
例えばまず第１指標値により、ブログ自体の人気度を判定する。例えばページビュー数などに基づいて、人気度を複数段階のいずれかに分類する。例えば「人気／不人気」の２段階でもよいし、「人気／普通／不人気」の３段階でも良い。また人気レベルとして４段階以上に分類しても良い。
このような人気度の判定結果を反映させて、記事のアクセス可能性の指標を確認し、圧縮可日を判定する。
【００５６】
例えば、第１指標値を総ページビュー数（ＰＶ）とし、
・ＰＶが０−１００００・・・不人気ブログ
・ＰＶが１０００１−１００００００・・・普通ブログ
・ＰＶが１０００００１以上・・・人気ブログ
とする。
第２指標値をアクセスのない期間の長さを示す値とする。
・不人気ブログの場合・・・アクセスのない期間が１年以上であれば圧縮
・普通ブログの場合・・・アクセスのない期間が３年以上であれば圧縮
・人気ブログの場合・・・アクセスのない期間が５年以上であれば圧縮
とする。
【００５７】
このように、まずブログの人気度を判定し、その人気度によって、アクセス可能性による圧縮可の判定基準を変更する。
これによってブログ自体の人気度を考慮したうえで、あまりアクセスされていない記事の圧縮可否を判定できることになる。
例えば単純に、「記事に対して１度もアクセスがない期間が３年以上続いていること」のように、記事に対して１度もアクセスがない期間を指標値として、指標値が一定の条件を満たす記事について圧縮することも考えられるが、この場合、必ずしもアクセス可能性が適切に判断されているとは言いがたい面がある。
例えば、全体として人気のあるブログの複数の記事のうちで、３年の間に１度もアクセスがない記事と、全体として不人気なブログの複数の記事のうちで、３年の間に１度もアクセスがない記事とでは、次にアクセスが発生する可能性は前者の方が高いと考えられる。すなわち、単に記事のみのアクセス可能性の指標のみでは、実際のアクセス可能性をより的確に判定することが難しい。換言すれば、人気ブログも不人気ブログも同様の条件で圧縮する記事を判定することは、なるべく圧縮や解凍の機会を少なくしたいという観点からは、必ずしも妥当ではない。
そこでステップＳ１１３でブログサーバ１は、ブログの人気度を反映させた状態での記事のアクセス可能性の指標から、圧縮可否判定を行うようにしている。
【００５８】
なおアクセス可能性を示す第２指標値として他の指標を用いても良い。例えば第２指標値を記事毎のユニークユーザ数ＵＮとする。そして、
・不人気ブログの場合・・・ＵＮ＜ＵＮ１であれば圧縮
・普通ブログの場合・・・ＵＮ＜ＵＮ２であれば圧縮
・人気ブログの場合・・・ＵＮ＜ＵＮ３であれば圧縮
とする。但しＵＮ１＞ＵＮ２＞ＵＮ３である。
このようにすることで、人気のないブログにおける不人気記事は、人気のあるブログにおける不人気記事より圧縮可と判定されやすくなる。
ここではユニークユーザ数を挙げたが、上述の他の指標値でも同様に用いることができる。
【００５９】
ステップＳ１１４ではブログサーバ１は、当該記事についての圧縮可否判定の結果を判定情報として記憶する。例えば当該記事についての判定情報として管理ＤＢ５３に記憶された圧縮可／不可のフラグを更新又は維持する。
【００６０】
以上で１つの記事について圧縮可否判定を終えたら、ブログサーバ１はステップＳ１１５で、現在の処理対象のブログについて今回処理対象としている記事の全てについて判定を終えたか否かを確認し、終えていなければステップＳ１１０に戻って次の記事を選択する。そしてステップＳ１１１〜Ｓ１１４を実行する。
なお、第１指標値を用いたブログの人気度の判定は、当該ブログについて最初にステップＳ１１３を実行するときのみ行い、以後はステップＳ１１５からＳ１２０に進むときまで記憶しておけばよい。或いは、第１指標値によりブログの人気度を判定する処理はステップＳ１０２の直後に１回、行っておいても良い。
【００６１】
或るブログについて今回対象の全ての記事について圧縮可否判定を終えたら、ステップＳ１２０で、続いて他のブログについても処理を実行するかを確認する。他のブログについても同様の処理を行う場合は、ステップＳ１０１に戻って、他の１つのブログを処理対象として特定し、以下同様の処理を行う。
例えば今回処理対象とする全てのブログについて処理を終えていた場合は、ステップＳ１２０から図５の圧縮判定処理を終える。
【００６２】
ブログサーバ１は、この図５のような圧縮判定処理を逐次実行する。例えば定期的に、ブログＤＢ５１に保存されている全てのブログについて実行することが考えられる。これにより、各ブログについて、各記事が、圧縮してよいものか否かが判定され、その判定情報が管理ＤＢ５３に記憶される。
なお、各ブログについて、図５のような圧縮判定処理をある時点で１回行うだけで無く、期間をおいてくり返し実行することが望ましい。時期毎に記事のアクセス状況は変動し、また所定期間以上アクセスがなかった記事も発生することが想定されるからである。
【００６３】
ブログサーバ１は以上のような圧縮判定処理を適宜行うとともに、図６に例示する圧縮処理を適宜行う。例えば全部又は一部のブログを対象として定期的に圧縮処理を行う。
図６の圧縮処理としてブログサーバ１は、まずステップＳ２０１で処理対象のブログを１つ特定する。
ステップＳ２０２でブログサーバ１は、処理対象と特定したブログについての判定情報を取得する。即ち管理ＤＢ５３において当該ブログのブログＩＤに対応して記憶されている判定情報である。具体的には例えば、図５の圧縮判定処理で記憶された、記事毎の圧縮可否のフラグ情報を確認する処理となる。
判定情報により、当該ブログにおける各記事について圧縮可とされているか否かを確認できる。
そこでステップＳ２０３でブログサーバ１は、圧縮可とされている記事を圧縮対象の記事として特定する。
【００６４】
もし圧縮可とされている記事が当該ブログに存在しなければ、ブログサーバ１はステップＳ２０４からＳ２１０に進み、当該ブログについての圧縮処理を終了する。そして続いて他のブログについても圧縮処理を実行するかを確認する。他のブログについても圧縮処理を行う場合は、ステップＳ２０１に戻って、他の１つのブログを処理対象として特定する。
【００６５】
圧縮対象として１以上の記事が存在した場合は、ブログサーバ１はステップＳ２０４からＳ２０５に進み、記事圧縮を行う。即ち、ステップＳ２０３で特定した１又は複数の記事のデータ圧縮を行う。そして圧縮データ化された記事を、当該ブログに対応づけてブログＤＢ５１や画像ＤＢ５２に記憶する。
【００６６】
このステップＳ２０５でどのような圧縮を行うかは多様に考えられる。
まず圧縮対象部分の設定、即ち記事データにおけるどの部分を圧縮するかという種別として、
・記事におけるテキストデータと画像データの両方を圧縮する
・記事におけるテキストデータの全部を圧縮する
・記事におけるテキストデータの一部を圧縮する
・記事に含まれる画像データの全部を圧縮する
・記事に含まれる画像データの一部を圧縮する
ということが想定される
【００６７】
記事のテキストデータと画像データの両方を圧縮することによれば、圧縮効果を高くすることができ、必要記憶容量の削減効果を高くすることができる。
記事におけるテキストデータの全部を圧縮することによれば、テキストデータ量や圧縮率にもよるが、圧縮効果（容量削減効果）を高くすることができる。特に記事内容としてテキストデータが中心であるブログで有効である。
テキストデータの一部を圧縮することによれば、もし圧縮後にアクセスが生じたときの配信対応を迅速化することも可能である。例えばブログの後半（閲覧時のファーストビューに現れない部分）を圧縮しておく。圧縮部分は後述のように解凍して配信することが想定されるが、ファーストビュー部分は圧縮しないことで、ユーザ端末５に対して迅速に（解凍処理を経ずに）配信できる。そしてユーザ端末５でファーストビュー表示を行っている間に後続部分の解凍を行って配信すれば、ユーザにとって応答の遅れが生じていないように感じさせることができる。
またテキストデータのみの圧縮を行うことは、画像データ圧縮を行う場合に比較して処理負担が小さく、処理時間も短いという利点も得られる。
【００６８】
記事における画像データの全部を圧縮することによれば、データ量の大きい部分であるため、圧縮効果（容量削減効果）を高くすることができる。画像データの圧縮は、画像の解像度を低下させる圧縮とすれば、容量削減効果は特に高い。複数の画像データが存在する場合、全部の画像データに限らず、一部の画像データを圧縮するものでもよい。
記事における一部の画像データを圧縮する場合、閲覧時のファーストビューに現れない画像を選んで圧縮するとよい。その場合、もし圧縮後にアクセスが生じたときには、まず解凍不要な画像データを配信すればよいため、ユーザにとって応答の遅れが生じていないように感じさせることができる。そしてユーザ端末５でファーストビュー表示を行っている間に後続の画像データを解凍して配信すればよい。
【００６９】
以上のような記事内における圧縮対象部分の設定は、固定的でもよいし、状況に応じて変更できるようにしてもよい。例えばブログＤＢ５１や画像ＤＢ５２の記憶リソース状況などに応じて自動的に選択できるようにしてもよい。
例えばブログＤＢ５１の記録可能なリソースが所定量以下になったら、テキストデータ圧縮を選択し、画像ＤＢ５２の記録可能なリソースが所定量以下になったら画像データ圧縮を選択する。ブログＤＢ５１と画像ＤＢ５２の両方の記憶可能容量が低下した状態であれば、テキストデータと画像データの両方を圧縮するなどである。
【００７０】
また圧縮対象部分の設定は、ブログ毎や記事毎に自動的に選択するようにしてもよい。
記事内容に応じて圧縮処理内容を決定する例としては、
・記事においてテキストデータが所定量以上ならテキストデータのみの圧縮を行い、所定量未満ならテキストデータと画像データの全体圧縮を行う。
・記事において画像データが存在すれば画像データのみの圧縮を行う。
などである。
さらにブログ毎に圧縮対象部分を選択する例としては、ブログの全体のテキスト／画像の比率からテキスト中心ブログか画像中心ブログかを判定し、テキスト中心ブログの場合はテキストデータの圧縮、画像中心ブログの場合は画像データの圧縮を行うということも考えられる。
逆に、アクセス時にユーザが感じる配信速度を重視する場合、テキスト中心ブログの場合は画像データの圧縮、画像中心ブログの場合はテキストデータの圧縮を行うということも考えられる。
【００７１】
なお、画像データとして動画が含まれている場合、更に動画圧縮と音声圧縮の両方、一方を選択することも考えられる。
【００７２】
以上のような圧縮対象部分の設定のほかに、圧縮方式の設定も多様に考えられる。公知の通り、画像データやテキストデータに対して多様な圧縮方式が存在し、また圧縮率も多様に選択できる。可逆圧縮、非可逆圧縮という選択も可能である。
この圧縮方式についても、或る圧縮方式を固定的に用いても良いし、状況に応じて選択するようにしてもよい。
例えばブログＤＢ５１や画像ＤＢ５２の記録可能なリソースが所定量以下になったら、より圧縮率の高い圧縮方式に切り替えるということが考えられる。
またブログ毎や記事毎に自動的に圧縮方式を選択するようにしてもよい。
例えば人気が低いブログほど圧縮率が高くなるようにしたり、記事のアクセス可能性の低さの程度によって圧縮率の異なる圧縮方式を選択するなどである。
【００７３】
ブログサーバ１は図６のステップＳ２０５で、現在処理対象のブログにおける圧縮対象の１又は複数の記事について圧縮処理を行う。これに伴って圧縮処理を行った記事についての判定情報、つまり圧縮可とされていた情報（フラグ情報）をクリアする。
続いてブログサーバ１はステップＳ２０６で管理ＤＢ５３における圧縮解凍情報を更新する。ここでは当該ブログ内の圧縮を行った記事について、圧縮状態であることを示すように例えばフラグ情報を更新する。また圧縮履歴を追加する。
【００７４】
ステップＳ２０７でブログサーバ１は、圧縮した各記事についてタグ設定を行う。ここでいうタグとは、記事内容を示すキーワードや記事のジャンル情報などを示す情報で、記事の検索、抽出に利用できるようにするものである。
圧縮処理を行うことによって、圧縮後の記事については、記事を対象とするテキスト検索がやりにくくなる。即ち圧縮記事も検索範囲に含めるようにしたい場合、検索時に、わざわざ解凍を行わなければならない。そこで、タグを設定して登録しておく。
このステップＳ２０７でブログサーバ１、圧縮前の元の記事データから、頻出語の抽出、品詞解析による名詞抽出、ジャンル情報の取得などを行い、タグとして登録する１又は複数の語句を設定する。
そしてブログサーバ１ステップＳ２０８で圧縮記事タグとして管理ＤＢ５３に登録する。即ち圧縮した記事のそれぞれに対応させて、キーワード等の１又は複数の語句を登録する。
【００７５】
なお、この圧縮記事タグの設定及び登録は、図６の例の場合、或る記事を圧縮した際に、その記事について行うようにしているが、予め全ての記事について行っておいてもよい。特に記事の検索のために、タグを用いており、前記事についてタグ登録を行っているのであれば、タグを本実施の形態の圧縮記事タグとして用いれば良いため、このステップＳ２０７，Ｓ２０８を実行する必要は無い。
但し、特に全記事についてタグ登録を行っていないシステムの場合、図６のステップＳ２０７、Ｓ２０８として圧縮記事タグ登録を行うことで、必要な記事についての必要最小限の処理となるため、ブログサーバ１の処理負担の増大防止に有効である。
【００７６】
ステップＳ２０９でブログサーバ１は、圧縮した記事について、元の圧縮前の記事データを削除する。もちろん記事の一部のみの圧縮を行った場合は、圧縮した部分のみの元のデータを削除する。
【００７７】
以上の処理により１つのブログについての圧縮処理を終えたら、ブログサーバ１はステップＳ２１０で他のブログについて処理を行うか否かを確認する。
そして今回処理対象とする全てのブログについて処理を終えていた場合は、ステップＳ２１０から図６の圧縮処理を終える。
以上の図６の圧縮処理を行うことで、図５の圧縮判定処理で圧縮可と判定された記事についての実際の圧縮処理が行われ、記憶リソースの回復が図られる。
【００７８】
なお、図５の処理で圧縮可と判定された記事が図６の処理で圧縮されるものとしているが、図５の処理で設定される判定情報（例えばフラグ）は、適宜リセットされることが好適である。例えば圧縮判定処理の開始時にリセットする。最新の判定結果を反映して圧縮処理が行われるようにするためである。
【００７９】
続いて、ブログやブログ内の記事に対するアクセス要求があった場合のブログサーバ１の処理を図７，図８で説明する。
ユーザ端末５からのアクセス要求があるとブログサーバ１はステップＳ３０１からＳ３０２に進み、まず要求された記事が、現在圧縮状態で保存されている記事（「圧縮記事」と表記する）であるか否かを判定する。
圧縮記事でなければ、ブログサーバ１はステップＳ３０２からＳ３０３に進み、通常に要求された記事を配信する。即ち該当の記事のウェブページデータをブログＤＢ５１から読み出し、ユーザ端末５に送信する。これによりユーザ端末５を使用している閲覧者は所望の記事を閲覧することができる。
【００８０】
アクセス要求された記事が圧縮記事であった場合、ブログサーバ１はステップＳ３０４に進み、解凍処理を行う。即ち該当の記事の圧縮状態のデータをブログＤＢ５１から読み出し、解凍処理を行う。そしてステップＳ３０５で解凍後のウェブページデータをユーザ端末５に送信する。これにより、圧縮されていた記事であっても、ユーザ端末５を使用している閲覧者は所望の記事を閲覧することができる。
【００８１】
なお、上述のように記事データの一部、特にウェブページデータにおけるファーストビューとして現れる領域以外のデータを圧縮するようにしていた場合、ブログサーバ１は、まず非圧縮記事部分をユーザ端末に送信しておき、その間に圧縮部分の解凍処理を行って、解凍でき次第、送信を行うという手法をとることができる。このようにすると解凍処理の時間を閲覧者に感じさせないような配信を実行でき、ブログサーバ１のサービスとしてのパフォーマンス維持が実現できる。
またファーストビュー以外の部分の圧縮に限らず、記事の一部を圧縮している場合は、記事内の非圧縮部分を先に送信するようにすることが同様の理由で望ましい。
【００８２】
圧縮記事を解凍して配信した後は、図８Ａ、図８Ｂ、図８Ｃに示すような処理例が考えられる。
まず図７のステップＳ３０５から図８ＡのステップＳ３１０に進む例では、ブログサーバ１は解凍記事、即ち圧縮状態から解凍した記事のデータ、即ち配信したウェブページデータを保存しておかずに消去する例である。
これは、当該記事への今回のアクセス要求は、あくまで例外的にアクセスが生じてしまったもので、この記事が、アクセス可能性が低いために圧縮された記事であることにかわりはないという考え方で、圧縮記事のまま保存しておくものである。
もしその後にアクセスが発生したら、その都度、解凍処理を行うことになる。アクセス要求に応じて解凍処理負担が発生するが、そもそもアクセスが少ないと考えれば、圧縮状態で保存しておくことで記憶リソース的に有利な状態を維持できる。
【００８３】
一方で、圧縮記事に対するアクセスが生じたということは、その圧縮記事（アクセス可能性が低いと判定された記事）について、アクセス可能性が高まってきた可能性があると考えることもできる。
そこで図７のステップＳ３０５から図８ＢのステップＳ３２０に進む例が考えられる。ステップＳ３２０でブログサーバ１は、解凍した記事データをブログに組み込む。そしてステップＳ３２１で圧縮記事を削除する。即ち、それまでブログに組み込んでいた圧縮記事に代えて、解凍した記事データ（解凍記事）をブログに組み込むようにする。
なお、解凍した記事データは、圧縮前の元の記事データと同一のデータである場合もあるが、不可逆圧縮を用いた場合は、元の記事データよりも低品質なデータとなる。つまり必ずしも元の記事データと同一ではない。そこで圧縮後に解凍した記事データについては「解凍記事」と表記する。
ステップＳ３２２では、ブログサーバ１は管理ＤＢ５３における圧縮解凍情報を更新する。即ち当該ブログの該当の記事について、圧縮から解凍した状態の記事データ（即ち解凍記事）であることを示すように情報を更新する。また解凍の日時等の履歴情報を追加する。
【００８４】
このように解凍した場合、圧縮記事を解凍記事に置き換えることで、その後、アクセス要求があった場合に、解凍を行わずに配信できる。
なお、もし当該解凍記事に対して、その後もアクセスが少なく、図５の圧縮判定処理でアクセス可能性が低いと判定された場合は、図６の圧縮処理で再び圧縮されることになる。従って、相変わらず不人気な記事であった場合、再び圧縮されるため、記憶リソース維持の観点で図８Ａの処理と比べて大きな不利とはならない。
また、不可逆圧縮を用いて圧縮処理を行った場合は、その後の解凍処理によって解凍した解凍記事のデータを記憶しておいたとしても、オリジナルの未圧縮の状態で記憶しておくよりもブログＤＢ５１において占有する記憶領域が小さくなるという利点がある。
【００８５】
図８Ｃは、解凍記事を圧縮記事とともに保存しておく例である。図７のステップＳ３０５から図８ＣのステップＳ３３０に進んだ場合、ブログサーバ１は、解凍した記事データをブログに対応づけて登録しておく。但し、圧縮記事はそのまま保持する。そしてステップＳ３３１でブログサーバ１は、管理ＤＢ５３における圧縮解凍情報を更新する。即ち当該ブログの該当の記事について、解凍記事が存在することを示すように情報を更新する。また解凍の日時等の履歴情報を追加する。
【００８６】
この場合、解凍記事を保存しておくことで、その後にアクセス要求があった場合に、解凍処理を行わずに配信できる。
但し、解凍記事と圧縮記事の両方を保存しておくことで、記憶リソースの負担を大きくする。そこで例えば解凍記事は、或る一定期間を経過したら削除することが考えられる。このようにすれば、アクセス要求が生じた場合、一定期間は、再度アクセスがあったときに解凍処理を経ずに配信できる状態を作ることができる。
また、このように圧縮記事と解凍記事を併存させた場合、当該記事がその後の図５の処理で圧縮対象となった場合、図６の圧縮処理では、解凍記事を削除するという処理を行えばよい。
【００８７】
＜４．第２の実施の形態＞
第２の実施の形態として、上述の図５の圧縮判定処理と同等の他の例を説明する。
これはブログサーバ１が、図５の圧縮判定処理に代えて図９Ａの人気度判定処理及び図９Ｂは圧縮記事判定処理を行う例である。
【００８８】
図９Ａは、ブログ毎に人気度判定を行う処理である。
ブログサーバ１は図９Ａの人気度判定処理を、逐次、ブログＤＢに保存している全部又は一部のブログに対して実行する。
ステップＳ１０１でブログサーバ１は、人気度判定処理の対象とする１つのブログを特定する。ステップＳ１０２でブログサーバ１は、処理対象としたブログについての第１指標値を取得する。例えば管理ＤＢ５３から、当該ブログ（ブログＩＤ）について記憶されているブログ実績情報に含まれる第１指標値を読み出す。以上のステップＳ１０１，Ｓ１０２は図５と同様である。
【００８９】
ブログサーバ１はステップＳ１０３で、当該ブログについて第１指標値を用いた人気度判定を行う。例えばページビュー数などに基づいて、人気度を複数段階のいずれかに分類する。
そしてステップＳ１０４で、当該ブログについて、人気度判定情報を管理ＤＢ５３に登録する。例えば「人気／普通／不人気」のいずれかを示す値を判定情報の１つとして登録する。
【００９０】
ステップＳ１０５でブログサーバ１は、続いて他のブログについても人気度判定を実行するかを確認する。他のブログについても同様の処理を行う場合は、ステップＳ１０１に戻って、他の１つのブログを処理対象として特定し、以下同様の処理を行う。
一方、今回処理対象とする全てのブログについて処理を終えていた場合は、ステップＳ１０５から図９Ａの人気度判定処理を終える。
【００９１】
ブログサーバ１は、この図９Ａの人気度判定処理を、逐次、実行する。例えば定期的に、ブログＤＢ５１に保存されている全てのブログについて実行する。これにより、各ブログについてのその時点の人気度判定情報が管理ＤＢ５３に記憶される。
【００９２】
またブログサーバ１は図９Ｂの圧縮記事判定処理を逐次行う。
ステップＳ１３０でブログサーバ１は、圧縮記事判定処理の対象とする１つのブログを特定する。
ステップＳ１３１でブログサーバ１は、処理対象としたブログについての人気度判定情報を管理ＤＢ５３から取得する。
そして当該ブログの各記事についての圧縮判定として、ステップＳ１１０〜Ｓ１１５の処理を実行する。これは図５のステップＳ１１０〜Ｓ１１５と同様の処理である。
このときステップＳ１１３の圧縮可否判定では、既に取得されている人気度判定情報を参照し、その人気度によって、アクセス可能性による圧縮可の判定基準を変更する。
これによってブログ自体の人気度を考慮したうえで、あまりアクセスされていない記事の圧縮可否を判定できることになる。
【００９３】
或るブログについて今回対象の全ての記事について圧縮可否判定を終えたら、ステップＳ１３２で、続いて他のブログについても処理を実行するかを確認する。他のブログについても同様の処理を行う場合は、ステップＳ１３０に戻って、他の１つのブログを処理対象として特定し、以下同様の処理を行う。
例えば今回処理対象とする全てのブログについて処理を終えていた場合は、ステップＳ１３２から図９Ｂの圧縮記事判定処理を終える。
【００９４】
以上の図９Ａ、図９Ｂの処理をブログサーバ１が逐次実行することで、逐次、圧縮すべき記事が判定される。圧縮可と判定された記事は、その後の図６の圧縮処理で圧縮されることになる。
この第２の実施の形態では、人気度判定処理と圧縮記事判定処理を、別個に行っていることで、処理のスケジュールの自由度を高めることができる。
例えば急激な人気上昇に対応するために、人気度判定処理のみを短い間隔で行いたい場合などに好適である。
【００９５】
＜５．第３の実施の形態＞
第３の実施の形態として、ブログサーバ１が、第１指標値と第２指標値とに基づいて、記事について、圧縮するか否かの判定に加えて、既に圧縮した記事を解凍するか否かも判定する例を説明する。
【００９６】
ブログサーバ１は図１０の圧縮解凍判定処理を例えば定期的、或いは所定のタイミングで実行する。この図１０の処理は第１の実施の形態における図５の圧縮判定処理に代わる処理と考えれば良い。図５と同一の処理については同一のステップ番号を付して重複説明を避ける。
【００９７】
ブログサーバ１は処理対象のブログを特定し（Ｓ１０１）、第１指標値を取得（Ｓ１０２）した後、ステップＳ１１０、Ｓ１１２、Ｓ１４０、Ｓ１４１、Ｓ１１５で各記事について判定を行う。
この場合ブログサーバ１は、ステップＳ１１０で１つの記事を選択したら、圧縮済か否かに関わらずステップＳ１１２に進んで第２指標値を取得する。そしてステップＳ１４０では、圧縮可否及び解凍可否の判定を行う。
即ちブログサーバ１は、未圧縮の記事もしくは解凍記事については、図５のステップＳ１１３と同様に、第１指標値と第２指標値を用いて圧縮可否判定を行う。
【００９８】
一方、圧縮記事についてはブログサーバ１は、第１指標値と第２指標値を用いて解凍可否判定を行う。即ち、記事自体のアクセス可能性のみで解凍可否を判断せず、第１指標値によりブログの人気度を判定し、それを反映させた解凍可否判定を行う。
例えばまず人気度を、圧縮可否判定の場合と同様に、総ページビューなどの第１指標値を用いて、「人気／普通／不人気」の３段階などに判定する。
そして第２指標値として、例えば当該記事のページビュー数Ｎを用い、
・不人気ブログの場合・・・ページビュー数ＮがＮ１以上であれば解凍
・普通ブログの場合・・・ページビュー数ＮがＮ２以上であれば解凍
・人気ブログの場合・・・ページビュー数ＮがＫ３以上であれば解凍
とする。但しＮ１＞Ｎ２＞Ｎ３である。
つまり人気ブログの圧縮記事であれば、ページビュー実績が少々高くなっていたら解凍可とするが、不人気ブログの圧縮記事であれば、ページビュー数により解凍可とする閾値を上昇させて判定を行う。人気ブログの記事ほど、一旦圧縮されても解凍可とされやすいことになる。これは人気ブログほど、アクセス可能性は上昇しやすいと考えられることによる。
【００９９】
他の例として、第２指標値として、例えば当該記事のページビューの増加傾向を示す値Ｋを用い、
・不人気ブログの場合・・・増加傾向値ＫがＫ１以上であれば解凍
・普通ブログの場合・・・増加傾向値ＫがＫ２以上であれば解凍
・人気ブログの場合・・・増加傾向値ＫがＫ３以上であれば解凍
とすることも考えられる。但しＫ１＞Ｋ２＞Ｋ３である。
つまり人気ブログの圧縮記事であれば、ページビューの少々の増加傾向が観測されたら解凍可とするが、不人気ブログの圧縮記事であれば、ページビューの大幅な増加傾向が観測されたら解凍可するというような判定を行う。この場合も、人気ブログの記事ほど、一旦圧縮されても解凍可とされやすいことになる。
【０１００】
そしてステップＳ１４１ではブログサーバ１は、当該記事についての圧縮可否判定又は解凍可否判定を判定情報として記憶する。例えば管理ＤＢ５３の判定情報として当該記事について圧縮可／不可のフラグ又は解凍可／不可のフラグを更新又は維持する。
ステップＳ１１５，Ｓ１２０は図５と同様である。
【０１０１】
ブログサーバ１はまた、図１１の圧縮解凍処理を逐次実行する。これは第１の実施の形態における図６の圧縮処理に代わるものである。図６と同一処理は同一のステップ番号を付し、詳細な説明は避ける。
【０１０２】
ブログサーバ１はステップＳ２０１で処理対象のブログを特定し、ステップＳ２０２で判定情報を取得する。
ブログサーバ１はステップＳ２０３で、圧縮可否の判定情報を参照して圧縮する記事を特定する。そしてステップＳ２０４で圧縮する記事の有無により処理を分岐する。
１又は複数の記事が圧縮対象とされた場合、ブログサーバ１はステップＳ２０５で、１又は複数の各記事データの圧縮処理を行い、図５の場合と同様にステップＳ２０７，Ｓ２０８，Ｓ２０９で、圧縮した記事についてのタグ設定、タグ登録、及び元の記事データの削除を行う。
【０１０３】
以上のステップＳ２０５〜Ｓ２０９を行った場合、もしくはステップＳ２０４で圧縮する記事が存在しないとされた場合は、ブログサーバ１はステップＳ２２０で、解凍する記事を特定する。即ちステップＳ２０２で取得した判定情報を参照して、圧縮されている記事の内で解凍すべき記事を特定する。そしてステップＳ２２１で解凍する記事の有無により処理を分岐する。解凍する記事が存在しなければステップＳ２２４に進む。
【０１０４】
１又は複数の記事が解凍対象として特定された場合、ブログサーバ１はステップＳ２２２で、当該特定された１又は複数の記事の解凍処理を行う。この場合、解凍した記事データは、それまでの圧縮記事に代えてブログに組み込むようにする。またステップＳ２２３でブログサーバ１は圧縮記事を削除する。
これにより、ブログ内の圧縮されていた記事が、アクセス可能性の上昇に応じて、解凍記事に回復されたことになる。
【０１０５】
ブログサーバ１はステップＳ２２４で管理ＤＢ５３における圧縮解凍情報を更新する。ここでは当該ブログ内の圧縮を行った記事について、圧縮状態であることを示すようにフラグ情報を更新する。また圧縮履歴を追加する。さらに当該ブログ内の解凍を行った記事について、解凍状態であることを示すようにフラグ情報を更新する。また解凍履歴を追加する。
【０１０６】
以上の処理により１つのブログについての圧縮や解凍を終えたら、ブログサーバ１はステップＳ２１０で他のブログについて処理を行うか否かを確認する。
そして今回処理対象とする全てのブログについて処理を終えていた場合は、ステップＳ２１０から図１１の圧縮解凍処理を終える。
以上の図１１の圧縮解凍処理を行うことで、図１０の圧縮解凍判定処理で圧縮可と判定された記事についての実際の圧縮処理や、解凍可と判定された記事についての実際の解凍処理が行われる。これにより記憶リソースの回復が図られるとともに、アクセス可能性が高くなった記事については解凍が行われ、アクセス時のパフォーマンスを向上させる。
【０１０７】
例えば或るブログの記事について、そのブログの記述者によって内容の変更があったり、その記事に対して閲覧者からコメントが投稿されたりした場合など、その記事自体に更新があった場合には、その記事に対するアクセス可能性は高くなる。第３の実施の形態によれば、このような記事は、圧縮を解いておくという動作が実現される。
そこで、このような動きを事前に察知して、既に圧縮したもののアクセス可能性の高まったブログ記事については、圧縮状態から解凍しておく。
このようにすれば、実際にアクセスしてきた場合に、その時点で解凍処理をせずにすぐに記事を配信することができる。
【０１０８】
＜６．第４の実施の形態＞
第４の実施の形態として、ブログサーバ１が記事内容に基づいて、既に圧縮した記事を解凍するか否かを判定する例を説明する。
例えば、あるテーマについて言及した記事について、当初にアップされた時点ではあまり話題にならなかったものの、数年後に、その記事で扱ったテーマに関する何らかの事件や事象が世の中で起きたために、その記事が掘り起こされる可能性が高まる（つまり、アクセス可能性が高まる）ことや、その記事に対する被リンク数が増加するといったことが起きうる。
そこで、このような動きを事前に察知して、既に圧縮したもののアクセス可能性の高まった記事については、圧縮状態から解凍しておくようにする。
このようにすれば、実際にアクセス要求があった場合に、その時点で解凍処理をせずにすぐに記事を配信することができる。
【０１０９】
図１２に解凍判定処理を示す。ブログサーバ１は、第１の実施の形態の各処理に加え、例えば定期的などに逐次この解凍判定処理を行う。
ステップＳ４０１でブログサーバ１は１又は複数の抽出語句を設定する。例えば時事語を抽出語句とする。例えば新聞やニュースで頻出する言葉や、芸能関係でよく使われ出した言葉、流行語などである。或いは、話題になっているジャンルや関連語などを抽出語句としてもよい。例えば、オリンピック開催期間であれば、「スポーツ」というジャンルや、各種競技の名称、選手名などを抽出語句とする。
【０１１０】
ブログサーバ１はステップＳ４０２で処理対象の１つのブログを特定する。そしてステップＳ４０３で、特定したブログに圧縮記事が存在するか否かを確認する。例えば管理ＤＢ５３の圧縮解凍情報を確認すれば良い。
もし圧縮記事が存在しなければ、解凍判定の必要はないためステップＳ４０７に進む。
圧縮記事が存在するブログであった場合は、ブログサーバ１はステップＳ４０４に進み、当該ブログの圧縮記事タグの情報を管理ＤＢ５３から取得する。圧縮記事タグとしては、少なくとも現在圧縮状態である１又は複数の圧縮記事について設定されたタグ情報を含む。図６のステップＳ２０８で登録されたタグ情報である。
【０１１１】
ステップＳ４０５でブログサーバ１は、ステップＳ４０１で設定した抽出語句と管理ＤＢ５３から取得した圧縮タグ情報を比較し、解凍する記事を判定する。
つまり抽出語句と同一又は類似の圧縮記事タグが登録されている記事を抽出し、解凍する記事と判定する。
ステップＳ４０６でブログサーバ１は、判定情報を管理ＤＢ５３に記憶する。つまり解凍すると判定した記事の情報を記憶する。
【０１１２】
以上の処理により１つのブログについての解凍判定処理を終えたら、ブログサーバ１はステップＳ４０７で他のブログについて処理を行うか否かを確認する。行う場合はステップＳ４０２に戻り、次の処理対象のブロクを特定して上記同様のステップＳ４０３以降の処理を行う。
今回処理対象とする全てのブログについて処理を終えていた場合は、ステップＳ４０７から図１２の解凍判定処理を終える。
【０１１３】
この解凍判定処理とともに、ブログサーバ１は図１３の解凍処理を逐次実行する。
ブログサーバ１はステップＳ２０１で処理対象のブログを特定し、ステップＳ２０２で判定情報を取得する。
ブログサーバ１はステップＳ２２０Ａで、取得した判定情報を参照して、圧縮されている記事の内で解凍すべき記事を特定する。そしてステップＳ２２１Ａで解凍する記事の有無により処理を分岐する。解凍する記事が存在しなければステップＳ２１０に進む。
【０１１４】
１又は複数の記事が解凍対象として特定された場合、ブログサーバ１はステップＳ２２２Ａで、当該特定された１又は複数の記事の解凍処理を行う。この場合、解凍した記事データは、それまでの圧縮記事に代えてブログに組み込むようにする。またステップＳ２２３Ａでブログサーバ１は圧縮記事を削除する。これにより、ブログ内の圧縮されていた記事が解凍記事に回復されたことになる。
ブログサーバ１はステップＳ２２４Ａで管理ＤＢ５３における圧縮解凍情報を更新する。ここでは当該ブログ内の解凍を行った記事について、解凍状態であることを示すようにフラグ情報を更新する。また解凍履歴を追加する。
【０１１５】
以上の処理により１つのブログについての解凍処理を終えたら、ブログサーバ１はステップＳ２１０で他のブログについて処理を行うか否かを確認する。処理を行う場合はステップＳ２０１に戻って、他のブログを特定し、同様の処理を実行する。
今回処理対象とする全てのブログについて処理を終えていた場合は、ステップＳ２１０から図１３の解凍処理を終える。
【０１１６】
以上の図１３の処理により、図１２の解凍判定処理で解凍可と判定された記事についての実際の解凍処理が行われる。
これにより、時事語、流行語、流行のテーマなどを含む記事が、アクセス可能性が高くなるであろうと予測して解凍が行われる。これによりその後のアクセス増加時に解凍処理を不要とできる。
【０１１７】
＜７．第５の実施の形態＞
第５の実施の形態は、ブログの人気度の変化を監視し、或るブログについて人気度の上昇傾向を検知した場合に、該ブログに含まれる圧縮済の記事を解凍する記事と判定する例である。つまり、人気が上昇したブログについては、個々の記事についての判断をせずに、そのブログに含まれる圧縮記事は解凍可とする。
【０１１８】
この場合の解凍判定処理を図１４に示す。
ブログサーバ１はステップＳ４２０で処理対象の１つのブログを特定する。そしてステップＳ４２１で、管理ＤＢ５３の圧縮解凍情報を参照し、特定したブログに圧縮記事が存在するか否かを確認する。
もし圧縮記事が存在しなければ、解凍判定の必要はないためステップＳ４２６に進む。
【０１１９】
圧縮記事が存在するブログであった場合は、ブログサーバ１はステップＳ４２２に進み、当該ブログの実績情報を管理ＤＢ５３から取得する。
例えばここでは第１指標値としての情報を取得するが、特には、期間毎の値として参照できる情報が望ましい。つまり人気の変動を判定できる情報である。
例えば当該ブログの総ページビュー数やアクセスしたユニークユーザ数、総被リンク数、総コメント数などであれば、期間毎、例えば１日毎や１週間毎の値であることが好適である。
また、ブログ全体についてのページビューの増加傾向を示す値、ブログ全体についてのデータ量の増加傾向を示す値などは、人気の変動を表す指標となるため、ステップＳ４２２で取得する情報として好適である。
【０１２０】
ステップＳ４２３でブログサーバ１は、上記の第１指標値から、当該ブログの人気の傾向を判定する。例えば「人気上昇傾向」「人気変動なし」「人気下降傾向」などを判定する。例えば総ページビュー数やユニークユーザ数の期間毎の値やページビューの増加傾向や減少傾向から判定できる。少なくとも、現在人気上昇傾向にあるか否かの判定のみでもよい。
そしてブログサーバ１は、「人気変動なし」又は「人気下降傾向」と判定した場合はステップＳ４２４からＳ４２６に進み、「人気上昇傾向」と判定した場合はステップＳ４２５に進む。
【０１２１】
ステップＳ４２５でブログサーバ１は、当該ブログに含まれる１又は複数の圧縮記事を、全て解凍可と判定し、その判定情報、つまり解凍すると判定した記事の情報を管理ＤＢ５３に記憶する。
【０１２２】
以上の処理により１つのブログについての解凍判定処理を終えたら、ブログサーバ１はステップＳ４２６で他のブログについて処理を行うか否かを確認する。処理を行う場合はステップＳ４２０に戻り、次の処理対象のブロクを特定して上記同様のステップＳ４２１以降の処理を行う。
今回処理対象とする全てのブログについて処理を終えていた場合は、ステップＳ４２６から図１４の解凍判定処理を終える。
【０１２３】
この解凍判定処理とともに、ブログサーバ１は図１３の解凍処理又は図１１の圧縮解凍処理を逐次実行することで、人気上昇傾向のブログにおける圧縮記事は解凍されることになる。
人気が上昇したブログについては、どの記事もアクセス可能性が高くなるため、圧縮記事については予め解凍しておくことで、閲覧時の解凍処理を不要とし、応答性の向上やその際の処理負担の削減を実現できる。
【０１２４】
なお、図１４のステップＳ４２５の時点で、当該ブログに含まれる圧縮記事の解凍を実行するようにしてもよい。
【０１２５】
＜８．第６の実施の形態＞
第６の実施の形態は、圧縮記事についてアクセスに応じて解凍が行われた場合、ブログサーバ１は解凍から所定期間、当該記事を圧縮する記事と判定しないようにする例である。例えば図８Ｂ又は図８Ｃで説明したようにアクセスに応じて解凍が行われた後、その解凍記事を記憶しておく場合に、図５の処理に代えて用いることができる圧縮判定処理である。
【０１２６】
図１５に第６の実施の形態としての圧縮判定処理を示す。図５と同一の処理については同一のステップ番号を付して重複説明を避ける。
【０１２７】
この圧縮判定処理でも、ステップＳ１０１でブログを特定し、ステップＳ１０２で第１指標値を取得した後、各記事についてステップＳ１１０以降の処理を行う。
ブログサーバ１はまずステップＳ１１０で圧縮判定する記事を選択したら、ステップＳ１５０で、その記事が圧縮状態から解凍された記事（解凍記事）であるか否かを確認する。例えば管理ＤＢ５３の圧縮解凍情報を参照して確認する。
解凍記事でなければステップＳ１１２以降にすすみ、図５と同様の処理を行う。
【０１２８】
一方、解凍記事であれば、ステップＳ１５１で、当該記事の解凍日時を確認し、現時点で所定期間を経過しているか否かを確認する。所定期間は例えば１ヶ月などとする。
解凍日時の確認は管理ＤＢ５３の圧縮解凍情報における履歴情報を参照して行う。なお、圧縮／解凍が複数回行われている記事の場合は、最新の解凍日時を確認する。
そして解凍から所定期間経過していれば、ステップＳ１１２に進み、第２指標値を取得してステップＳ１１３で第１指標値及び第２指標値を用いた圧縮可否の判定を行う。
解凍から所定期間経過していなければ、圧縮可否判定を行わずにステップＳ１１５に進む。
【０１２９】
従って、一旦圧縮した後に解凍した解凍記事については、解凍から所定期間経過するまでは、アクセス可能性の判定は行われず、圧縮可とは判定されないことになる。
このため解凍してから所定期間の間は、アクセス要求があった場合に、必ず解凍処理を行うことなく配信が可能となる。
【０１３０】
なおステップＳ１５０の処理は、図７のようにアクセス時に解凍された解凍記事であるか否かを判定することを前提としているが、ユーザ端末５からの閲覧のためのアクセス以外にも、例えばクローラによるアクセスもあり得る。ここでいうクローラとは、各種のウェブサイトにおけるテキストデータや画像データなどを周期的に取得して自動的にＤＢ化するプログラム（或いはそのプログラムに基づく動作を行う情報処理装置）のことである。このクローラによるアクセスは人気度や閲覧のためのアクセス可能性の変化には関係ない。
そこでクローラのアクセスに応じて解凍したような場合は、ステップＳ１５０で解凍記事と判断しないようにすることが望ましい。つまりその場合は、解凍直後であっても圧縮可否判断の対象とする。
或いはクローラによるアクセスに応じて解凍したような場合は、図８Ａのように解凍記事を保存しないようにすることも考えられる。
さらには、クローラからのアクセスの場合、圧縮記事をそもそも解凍しないようにするという手法も考えられる。
ここではクローラを例に挙げたが、一般の閲覧者たるユーザの意思と考えられるアクセス以外のアクセスは、以上のクローラの場合と同様の対応をとるとよい。
【０１３１】
＜９．まとめ及び変形例＞
以上の実施の形態によれば次のような効果が得られる。
第１〜第６の実施の形態の情報処理装置としてのブログサーバ１は、１又は複数の記事が含まれるブログの人気度を示す第１指標値を取得する第１取得部１２と、ブログに含まれる複数の記事ごとに当該記事に対するアクセス可能性を示す第２指標値を取得する第２取得部１３と、ブログに含まれる記事について前記第１指標値と前記第２指標値とに基づいて圧縮するか否かを判定する判定部１４とを備える。これらの機能により図５，図９Ａ及び図９Ｂ，図１０，図１５の処理で圧縮可否の判定を行うようにしている。
アクセス可能性が低い記事を圧縮することでサーバの記憶リソースの圧迫を回避できる。そこでこれらの判定処理では、ブログに含まれる記事の内で、アクセス可能性の小さい記事（例えば不人気記事）を圧縮するためにその可否、つまりアクセス可能性が小さい記事であるか否かを判定する。この場合に、アクセス可能性の小さい記事が、人気の高いブログ内の記事であるか、人気の低いブログ内の記事であるかも考慮して圧縮するか否かを判定する。
単にアクセス可能性が小さいということを示す指標だけでなく、ブログの人気度を示す指標も用いて圧縮するか否かを判定することで、なるべく人気の低いブログの中のアクセス可能性が低い記事を圧縮対象とし、一方でアクセス可能性が低い記事であっても人気の高いブログの記事であれば、圧縮対象となりにくいような判定が可能となる。
例えば人気の高いブログの記事の場合、その記事自体の実績からアクセス可能性が低いとされても、他の記事との関連などによりアクセスされることも想定される。つまり、人気ブログの不人気記事は、不人気ブログの不人気記事よりもアクセス可能性は高いと言える。本実施の形態の処理によれば、記事だけでなくブログの人気を考慮した判定ができ、これにより圧縮対象を適切に選択できる。
また、圧縮や、圧縮に対する解凍は、処理負荷が高いが、本実施の形態の場合、圧縮や解凍をなるべく行わないようにできる。
もし、圧縮した記事に対してアクセスがあった場合、ブログサーバはその記事を解凍して配信することが考えられるが、記憶リソースのために圧縮する記事は、真にアクセス可能性が低い記事となるため、アクセス時に解凍処理が必要となる事態を極力少なくできる。これによってブログ提供のためのブログサーバ１の処理負担を軽減できる。
また真にアクセス可能性が低い記事を選択して圧縮することで、圧縮処理の負担も軽減される。
以上から、本実施の形態によれば、記事の圧縮によって記憶リソースの圧迫を抑えるとともに、なるべく圧縮や解凍の処理機会が少なくなるように、ブログ内で圧縮する記事を適切に選択することができ、サーバの処理負担の低減や、閲覧時のパフォーマンス向上を図ることができる。
【０１３２】
第１〜第６の実施の形態のブログサーバ１は、判定部１４によって圧縮すると判定された記事を圧縮するとともに、既に圧縮された記事に対してのアクセスが発生した場合に、当該記事の解凍を行う圧縮解凍部１５を備えている。
即ち圧縮解凍部１５の機能により、図６や図１１の処理で判定部１４の判定に沿って適切に選択された記事の圧縮を行う。またアクセス可能性が小さいとして圧縮された記事であっても、アクセスが発生することは当然あり得るが、そのような場合、図７の処理で解凍を行うことで、アクセスしたユーザに対して記事を適切に提供する。
これにより記憶リソースの圧迫防止や処理負担の削減のための適切な圧縮・解凍を行うことができる。
【０１３３】
第３の実施の形態では、第１指標値と第２指標値とに基づいて、既に圧縮した記事を解凍するか否かを判定するようにしている（図１０参照）。
即ち一旦圧縮した記事についても、その後、定期的又は不定期に第１、第２指標値を取得して、アクセス可能性の変化を確認する。もし最新の状況としてアクセス可能性が高くなっていたら、解凍しておくように判定する。
一旦圧縮した記事であっても、アクセス可能性が高くなった記事を解凍しておくようにすることで、アクセスが発生したときの解凍処理を不要とし、処理負担を削減し、またユーザに快適な閲覧を提供することができる。
例えばあるブログの記事について、その記事の著者によって内容の変更があったり、その記事に対して読者からコメントが投稿されたりした場合など、その記事自体や関連内容に更新があった場合には、その記事に対するアクセス可能性は高くなる。このような記事は、圧縮を解いておくことで、アクセス時に解凍しなくてもよいようにしている。
【０１３４】
第４の実施の形態では、記事内容に基づいて、既に圧縮した記事を解凍するか否かを判定するようにしている（図１２参照）。
例えば圧縮した記事の内容として、或る設定したキーワードや時事語を含む記事、特定のテーマの記事などを抽出し、これらを解凍対象とする。
例えば、あるテーマについて言及したブログ記事について、当初にアップロードされた時点ではあまり話題にならなかったものの、数年後に、その記事で扱ったテーマに関する何らかの事件や事象が世の中で起きたために、その記事が掘り起こされる可能性が高まる（つまり、アクセス可能性が高まる）ことや、その記事に対する被リンク数が増加するといったことが起きうる。
そこで、このような動きを記事内容、具体的には時事語、設定したキーワード、記事のテーマ等により事前に察知して、既に圧縮したもののアクセス可能性の高まった記事については、圧縮状態から解凍しておく。
このようにすれば、実際にアクセスがあった際に、その時点での解凍処理を不要とし、すぐに記事を配信することができる。
【０１３５】
なお、圧縮した記事については、内容を検索することが困難にもなる。そこで、管理ＤＢ５３に圧縮記事タグとしてキーワードやテーマ等を示すタグ情報を記憶しておくようにしている。これにより、解凍判定を容易かつ適切に行うことができる。
またタグ設定及び管理ＤＢ５３へのタグ登録は、圧縮時に行っている（図６、図１１参照）。これによりタグ設定及び登録の処理の実行を必要最小限にでき、処理負担の増大を抑止し、また記憶リソースをむやみに圧迫しないようにできる。
【０１３６】
第５の実施の形態では、ブログの人気度の変化を監視し、或るブログについて人気度の上昇傾向を検知した場合に、該ブログに含まれる圧縮済の記事を解凍する記事と判定するようにしている（図１４参照）。
或るブログが何らかの人気記事によってアクセス数が顕著に上昇したような場合、そのブログに含まれる別の記事は、これまでアクセスされていなかったとしても、今後アクセスされる可能性が高まる。そこで当該ブログ内の全ての圧縮記事を解凍する記事と判定する。
このようにすれば、実際にアクセスがあった際に、その時点での解凍処理は不要となり、レスポンスよく記事を配信することができる。
【０１３７】
なお第５の実施の形態の図１４の処理の変形例として、人気上昇と判定されたブログにおける全ての圧縮記事ではなく、一部の圧縮記事を解凍する記事と判定してもよい。例えば投稿日時が現在から過去に所定期間内の記事を解凍する記事とすることで、むやみに多数の記事を解凍せず、記憶リソースの維持に好適である。例えば長期にわたって多数の記事が投稿されており、比較的古い記事の多数が圧縮されているようなブログについては、全部ではなく一部の圧縮記事を解凍対象とすることが好ましい。
或いは、圧縮記事の数が所定数以上の場合は、一部（例えば半分）のみを解凍対象とすることも考えられる。
また解凍する記事数の上限を決め、上限数以上の圧縮記事が存在する場合は、投稿日時の新しい記事から上限数の記事を解凍する記事と判定してもよい。
【０１３８】
第６の実施の形態では、圧縮された記事についてアクセスに応じて解凍が行われた場合、解凍から所定期間、当該記事を圧縮する記事と判定しないようにしている（図１５参照）。
圧縮した後にアクセスがあって解凍して配信した場合、その記事についてはアクセス可能性が高まったと考えることができる。そこで、解凍したままとし、次のアクセス時に解凍処理を不要とする。
但し、アクセスが単発的なものであって、引き続き不人気記事であることもある。そこで所定期間経過後は、第１，第２指標値に基づいた判定で、アクセス可能性が低ければ圧縮すればよい。これにより、解凍したままとしておくことが無駄なリソース消費となっている場合に対処でき、必要な記憶容量を低減させ、記憶リソースの圧迫を回避する。
【０１３９】
実施の形態の処理例は一例であり、他にも各種の変形例が想定される。
ブログの人気度について例えば３段階以上の多段階に分けた場合、最も人気が低いランクであると判定されたブログについては、全記事を圧縮可と判定するようなことも考えられる。つまり人気度のｎ段階の第１レベル（人気大）から第（ｎ−１）レベル（人気低）については第１指標値及び第２指標値を用いて記事毎の圧縮可否判定を行うが、第ｎレベル（人気最低）のブログは、個々の記事を判定することなく全記事を圧縮可とするような例である。
特に閲覧者のアクセス（閲覧やコメント書き込み）が無いだけでなく、記述者の更新も長期にわたって無いようなブログは、実質、使用されていないブログとも考えられる。そのようなブログを、上記の人気最低のブログと判定するとよい。
これによりブログサーバ１の処理効率の向上、処理負担の削減、記憶リソースの確保を促進できる。
【０１４０】
圧縮処理については段階的に複数回行うようにしても良い。
例えば図１０のように圧縮記事についても引き続きアクセス可能性の判定を行うようにする。そして圧縮済であるが、さらに所定期間、アクセスがない記事は、より高い圧縮率で圧縮するなどである。
例えば１回目の圧縮では圧縮率２０％の圧縮、２回目は圧縮率５０％の圧縮、３回目は圧縮率８０％の圧縮というようにする。
また、１回目は可逆圧縮、２回目は非可逆圧縮を行うというような例もある。
また、１回目は記事の一部圧縮、２回目は記事の全体圧縮としてもよい。
また、１回目は記事のテキストのみ圧縮、２回目は加えて画像も圧縮としてもよい。
また、１回目は記事の画像のみ圧縮、２回目は加えてテキストも圧縮としてもよい。
【０１４１】
圧縮判定処理の対象について、一部のブログを除外することも考えられる。
例えば長期にわたって高い人気と判定されるブログについては、そのブログに含まれる記事については圧縮判定の対象外としてしまうことが考えられる。これにより図５、図１０、図１５等の処理の対象とするブログの数を削減でき、処理を効率化できる。
同様に、記事全体を圧縮済のもの、特に上述のように非常に不人気（実質的に使用されていない）と判定されるブログは、解凍判定の対象外としてしまうことで、図１０、図１２、図１４等の処理の対象とするブログの数を削減でき効率化が図られる。
【０１４２】
ブログの人気度の判定については、複数の第１指標値を用いてもよい。
同様に、記事のアクセス可能性の判定については、複数の第２指標値を用いてもよい。
【０１４３】
なお、実施の形態はいわゆるブログとブログに含まれる記事を対象とし、記事の圧縮を行う処理について説明したが、このような技術は、ファイルシステムにおけるフォルダと、フォルダに含まれるファイルについても適用できる。
つまりフォルダの人気度を、頻繁に使用されるフォルダであるか否かという点でフォルダの人気度をはかり、それを反映させて、ファイルのアクセス可能性を基準にファイルの圧縮可否を判断するものである。
【０１４４】
またブログは、いわゆるクラウドストレージとして実現されるシステムであってもよい。
【０１４５】
＜１０．プログラム及び記憶媒体＞
実施の形態のプログラムは、ブログサーバ１における少なくとも第１取得部１２、第２取得部１３、判定部１４の処理を情報処理装置（ＣＰＵ等）に実行させるプログラムである。
【０１４６】
実施の形態のプログラムは、複数の記事が含まれるブログの人気度を示す第１指標値を取得する手順（Ｓ１０２）と、ブログに含まれる複数の記事ごとに、当該記事に対するアクセス可能性を示す第２指標値を取得する手順（Ｓ１１２）と、ブログに含まれる記事について第１指標値と第２指標値とに基づいて圧縮するか否かを判定する手順（Ｓ１１３又はＳ１４０）とを情報処理装置に実行させるプログラムである。
即ちこのプログラムは、情報処理装置に対して図５，図１０，図１５等で説明した処理を実行させるプログラムである。
【０１４７】
このようなプログラムにより、上述したブログサーバ１としての１又は複数の情報処理装置を実現できる。
そしてこのようなプログラムはコンピュータ装置等の機器に内蔵されている記憶媒体としてのＨＤＤや、ＣＰＵを有するマイクロコンピュータ内のＲＯＭ等に予め記憶しておくことができる。あるいはまた、半導体メモリ、メモリカード、光ディスク、光磁気ディスク、磁気ディスクなどのリムーバブル記憶媒体に、一時的あるいは永続的に格納（記憶）しておくことができる。またこのようなリムーバブル記憶媒体は、いわゆるパッケージソフトウェアとして提供することができる。
また、このようなプログラムは、リムーバブル記憶媒体からパーソナルコンピュータ等にインストールする他、ダウンロードサイトから、ＬＡＮ、インターネットなどのネットワークを介してダウンロードすることもできる。
【符号の説明】
【０１４８】
１  ブログサーバ、２  ネットワーク、５  ユーザ端末、１１  ブログ管理部、１２  第１取得部、１３  第２取得部、１４  判定部、１５  圧縮解凍部、５１  ブログＤＢ、５２  画像ＤＢ、５３  管理ＤＢ
【図１】
2018073941.tif 000003
【図２】
2018073941.tif 000004
【図３】
2018073941.tif 000005
【図４】
2018073941.tif 000006
【図５】
2018073941.tif 000007
【図６】
2018073941.tif 000008
【図７】
2018073941.tif 000009
【図８】
2018073941.tif 000010
【図９】
2018073941.tif 000011
【図１０】
2018073941.tif 000012
【図１１】
2018073941.tif 000013
【図１２】
2018073941.tif 000014
【図１３】
2018073941.tif 000015
【図１４】
2018073941.tif 000016
【図１５】
2018073941.tif 000017
【国際調査報告】
2018073941.tif 000018
2018073941.tif 000019
2018073941.tif 000020