JP2006119943A

JP2006119943A - 既読管理方法

Info

Publication number: JP2006119943A
Application number: JP2004307588A
Authority: JP
Inventors: Katsuro Kikuchi; 克朗菊地
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 2004-10-22
Filing date: 2004-10-22
Publication date: 2006-05-11
Also published as: US20060095422A1

Abstract

【課題】自宅、職場、移動時などユビキタス環境においてWeb上に散在する情報に効率よくアクセスできる方法が存在しない。
【解決手段】クライアント100とコンテンツを提供するWebサーバ(111, 112, 113)の間に中継サーバ103を配置する。本中継サーバにて、クライアント100で動作するブラウザのリクエストをトラップして訪問履歴を記録する(107)。訪問記録を元にコンテンツ中のリンクの表示方法を変更し、既読管理サービスをクライアント100に提供する(109)。更にコンテンツに対して、ユーザが任意の属性を設定可能とし、属性に応じて既読済みリンクの表示方法を変更することを可能とする。
【選択図】図１

Description

本発明は、Webコンテンツの既読管理方法に関する。

Web(World Wide Web)上には有用、無用に関わらずな多種多様で膨大な情報が公開されており、Webは情報取得の場とした重要な役割をもちつつある。しかし、Webはまったく整理されていない情報が氾濫しているため必要な情報にアクセスするのが困難となっている。これに対して、YahooやGoogleといったWebの検索サービスを利用して、必要な情報に効率良くアクセスすることが可能である。また、有用な情報に目印を付けておければ、有用な情報に直ぐにたどり着ける。これはブラウザのブックマーク機能を利用することで実現可能である。

また、以前に見たことがあるかどうかを事前に確認できれば、無駄なアクセスを避けることができる。たとえば、Yahoo! MailなどWebメールシステムではメールコンテンツに対する既読管理機能があるので、ユーザは一度見たコンテンツすなわちメールを何度も確認する必要がなくなる。
Webブラウザに目を向けると単純ではあるがWebアクセス履歴管理機能がある。Webブラウザは訪問したURLを履歴として保存することにより、コンテンツ表示時に訪問済みのリンク(URL)を未訪問のリンクと区別できるよう表示する。

特開2001-297048号公報

特開2003-337737号公報

前述したようにWeb上の膨大な情報から有用な情報を探し出す手段として、Web検索サービスは有用である。しかし、検索キーワードの選択にはちょっとしたコツが必要であり、また、あまりにも膨大なWebの情報量が災いし検索結果に不要な情報(URL)が多く埋もれ、効率的な情報収集が難しいのが現実である。一方、ブラウザのブックマーク機能に目を向けると、自宅や職場、モバイル環境など複数のクライアントでのブックマークの共有の問題などブックマークのメンテナンスにはかなりの手間が必要となる。
Webメールなどのアプリケーションが提供する既読管理機能はユーザに対してもちろん適切に機能するが、アプリケーション自身が管理するコンテンツ以外についてはもちろん既読管理していないので、Web全体に対するコンテンツアクセス改善には寄与しない。

ブラウザのWebアクセス履歴機能は、Webブラウザは訪問履歴をローカルに保存しているため、自宅と職場など複数のクライアントを利用する場合には意味を成さない。
また、本履歴管理機能はコンテンツの有用性や属性に関係なく、単に訪問済みを識別できるよう表示するのみなので、本機能を既読管理に利用して効率向上を図ることは難しいといえる。また、Windows（特許商標） 2000 Serverのターミナルサービス機能などを利用して単一のデスクトップ環境すなわち常に同じWebブラウザを利用することも可能だが、社内外利用時のネットワーク運用の問題や、そもそもWebブラウザは単なる訪問履歴管理しか実現していないという点で、効率向上にはあまり寄与しないと言える。

中継サーバで既読情報を一括管理することにより、ユビキタス環境において既読管理サービスを提供し、それによりユーザのWebアクセス効率の向上を図ることが可能。

発明の第１の実施形態について説明する。図１にシステムの全体構成を示す。既読管理を行う中継サーバ103はクライアント100とWebサーバ111〜113の中間に位置する。既読管理を行うためにユーザは、クライアント100となるWebブラウザのプロキシサーバ設定を中継サーバ103に設定する。これにより、クライアント100のWebアクセスが全て中継サーバ103を経由することとなり、ユーザは既読管理サービスを受けることができる。

中継サーバ103はクライアント100のユーザ認証を行うクライアント認証部104、ユーザ管理データベース105、プロキシサーバとしてクライアント100に代わってWebサーバにアクセスしコンテンツを取得するWebアクセス部106、クライアント100のWebアクセス履歴を保存する訪問履歴管理部107、訪問履歴データベース108および訪問済みリンクの表示方法を変更するコンテンツ変換部109、変換ルールデータベース110からなる。

次いで、図２〜図４を用いてデータベースのテーブル構成について説明する。ユーザ管理データベース105はクライアント100を認証するための情報として、ユーザID200とパスワード201を持つ。訪問履歴データベース108はユーザ毎に訪問したURLを格納する。本データベース中のユーザID(300)は前記ユーザ管理データベース105のユーザID(200)と対応するフィールドである。変換ルールデータベース110はユーザ毎に既読済みURLの表示方法が格納されている。本実施例ではCSS(Cascading Style Sheets)で表示方法を指定しているが、DynamicHTML技術を利用し、ツールチップを出力する方法なども可能である。

次に図５を用いて処理の流れについて説明する。クライアント100がWebサーバ1(111)へのコンテンツ要求としてhttp://server1/content.htmlを要求する(500)。クライアント100のプロキシサーバとして中継サーバ103が設定されているので、この要求は中継サーバ103に送られる。ブラウザ起動後の初回アクセス時の場合、中継サーバ103のWebアクセス部106はプロキシ認証の要求をクライアント100に返却する(501)。プロキシ認証の要求を受け取ったクライアント100はプロキシ認証に必要なユーザID、パスワードをユーザから入力してもらう。ユーザID、パスワードの入力を受け取ったクライアント100は、再度中継サーバ103にコンテンツの要求をおこなう(502)。要求を受け取った中継サーバのクライアント認証部104はHTTPヘッダからプロキシ認証情報を取り出し、ユーザ認証を行う(503)。ユーザ認証方法としては、前記ユーザ管理データベース105を用いてユーザIDとパスワードのマッチングを行う。次いで、中継サーバ103のWebアクセス部106は、Webサーバ1からクライアントが要求したコンテンツを取得する(504,505)。次いで、訪問履歴管理部107は訪問履歴データベース105を参照し、既読済みＵＲＬでなければ訪問履歴データベース105に訪問履歴としてURLを記録する(506)。参照の結果、既読済みＵＲＬであった場合には、コンテンツ変換部109にてWebサーバ１から取得したコンテンツに既読情報を埋め込むためのコンテンツ変換をおこなう(507)。

このコンテンツ変換手順の詳細を図６を用いて説明する。まず始めに変換ルールデータベース110から既読済みリンクの表示方法を取得する(600)。次いで、コンテンツ中の相対形式URLを絶対形式URLに変換するためのベースURLとして、取得したコンテンツのURLの親ディレクトリを設定する(601)。ただし、コンテンツ中にBASEタグがあった場合には、前記ベースURLをBASEタグのhref属性で指定されているURLに変更する(603)。次いで、コンテンツのBODYタグ内の全てのAタグについてリンクの表示方法変換処理を行う(604、605)。始めにAタグのhref属性からURLを抽出する。URLが相対パス形式の場合には前記ベースURLを元に絶対パス形式URLに変換する(606)。次いで、抽出したURLが訪問履歴データベース105に含まれているか確認する(607)。含まれている場合、前記ステップ600で取得したCSS情報をAタグのstyle属性に追加する。本CSS情報と一致するプロパティが既に含まれている場合には上書きする(608)。これらの処理により、コンテンツ中のURLの中で訪問履歴データベース105に存在するURL、すなわち既読済みURLの表示方法が変換ルールデータベース110で指定されている表示方法に変換される。

中継サーバ103は、本変換処理を行った後、コンテンツをクライアント100に返却する。コンテンツを受け取ったクライアント100のブラウザは既読済みURLの表示方法(CSS)に従ってコンテンツを整形処理し、ユーザに提示する。これにより、ユーザは既読済みコンテンツか否かの確認が可能となる。以降、ユーザが本コンテンツ中に含まれるリンクをクリックした場合、前記ステップ502からステップ508の処理が行われ、既読情報が反映されたコンテンツがユーザに提示されることとなる。

図７に示すようにユーザがクライアント100とは異なる環境であるクライアント700を利用する場合についても、中継サーバ103は前記図５のステップ500〜502のユーザ認証処理によりクライアント700とクライアント100が同一のユーザと判定することが出来る。これにより、自宅、職場や出張先など様々な環境について、ユーザに透過的な既読管理サービスを提供することが出来る。

前記第１の実施例ではWebブラウザのプロキシ設定を中継サーバに設定することで既読管理サービスの提供を実現した。一方、携帯電話のブラウザなどの場合、一般的にプロキシの設定を変更することは不可能である。プロキシの機能を持たないWebブラウザに対する既読管理サービスの実施の形態を図８〜図１３を用いて説明する。システムの全体構成については図１や図７と同等である。図８に処理シーケンス図を示す。本実施の形態の場合、ブラウザは始めに中継サーバ103に明示的にアクセスしてログイン操作を行う(800〜803)。中継サーバ103にアクセスすると図９のようにログイン用画面がクライアント100に返却される(800、801)。本実施例ではForm認証によるログイン画面を返却している。ユーザは前記実施例のプロキシ認証で入力したユーザIDとパスワードを同様に入力し中継サーバ103の認証を受ける(803)。本実施例ではForm認証により認証を行っているが、Basic認証でも同様に実現できる。中継サーバ103でユーザ認証をパスすると、図１０に示す既読管理サービスのポータル画面1000が表示される(804)。ポータル画面1000は、ユーザが直接URLを入力するアドレス入力エリア1001と、ユーザが良く利用するURLを予め登録しておけるブックマーク集1003の2つの部分からなる。

それぞれのコンテンツ断片のHTMLを図１１に示す。ブックマーク集のリンクは、図１１の該当するHTML(1101)に示すとおり、中継サーバ103のURL＋クエリの形式となる。クエリは実際のコンテンツのURLをクエリとして埋め込むために適切にエンコードした値となる。本実施例ではエンコード方法としてURLエンコードを利用している。ユーザがアドレス入力エリア1001にURLを入力し、GOボタン1002を押すと本URLがクエリとして中継サーバ103に通知され、また、ブックマーク集1003のURLをクリックしても同様にコンテンツのURLが中継サーバ103に通知されることとなる(805)。中継サーバ103は、クライアントの要求からコンテンツのURLを抽出する(806)。次いで、実際にサーバにアクセスしてコンテンツを取得する(807、808)。次いで、URLを訪問履歴データベース105に記録する(809)。次いで、コンテンツ変換(810)を行い、クライアント100にコンテンツを返却する(811)。コンテンツ変換の方法を図12に示す。まず始めに変換ルールデータベース110から既読済みリンクの表示方法を取得する(600)。

次いで、コンテンツ中の相対形式URLを絶対形式URLに変換するためのベースURLとして、取得したコンテンツのURLの親ディレクトリを設定する(601)。ただし、コンテンツ中にBASEタグがあった場合には、前記ベースURLをBASEタグのhref属性で指定されているURLに変更する(603)。次いで、コンテンツのBODYタグ内の全てのAタグについてリンクの表示方法変換処理とURL変換処理を行う(604、605)。始めにAタグのhref属性からURLを抽出する。URLが相対パス形式の場合には前記ベースURLを元に絶対パス形式URLに変換する(606)。次いで、抽出したURLが訪問履歴データベース105に含まれているか確認する(607)。含まれている場合、前記ステップ600で取得したCSS情報をAタグのstyle属性に追加する。本CSS情報と一致するプロパティが既に含まれている場合には上書きする(608)。次いで、本Aタグをユーザがクリックした際に中継サーバ103を経由させるために、hrefで指定されていたURLを、中継サーバのURL＋クエリの形に変換しhref属性を書き換える(1200)。URLは図１３のようにURLエンコードする。これらの処理により、コンテンツ中のURLの中で訪問履歴データベース105に存在するURL、すなわち既読済みURLの表示方法が変換ルールデータベース110で指定されている表示方法に変換される。また、ユーザがコンテンツ中のリンクをクリックした場合、中継サーバ103を経由して、リンク先のコンテンツを取得することとなる。

次に発明の第３の実施形態について説明する。第３の実施形態では、図１４に示すように中継サーバ103にコンテンツ更新検知部1400とコンテンツ更新データベース1401が新たに追加し、コンテンツの更新状態も加味した既読情報をユーザに提示する。図１５にコンテンツの更新時刻を格納するためのコンテンツ更新データベース1401の構成を示す。本データベースはコンテンツのURL(1500)とコンテンツの更新時刻を格納するフィールド(1501)からなる。本データベースはコンテンツ更新検知部1400により定期的に図１６に示すコンテンツ更新時刻確認処理が呼び出され、コンテンツの更新時刻を更新する。コンテンツ更新時刻確認処理は、コンテンツ更新データベース1401の全てのURLについて(1600)、Webサーバにアクセスしてコンテンツ更新時刻を取得し(1601)、最終更新時刻フィールド(1501)を更新する。また、訪問履歴データベース108は、図１７の1700に示すように、ユーザがコンテンツのアクセスした時刻も保存するように拡張する。

加えて、変換ルールデータベース110は図１８の1800に示すように更新時刻を条件に付加して表示方法を格納できるように拡張する。本例では１日以内に更新されている場合にはAタグのラベルの書式を太字かつ赤色、未更新の場合には単に太字、それ以外の場合には太字かつ朱色に表示方法を変えるよう指示している。図１９、２０を用いて処理の流れについて説明する。図１９の処理シーケンス1900〜1905までは前記図５の処理シーケンス500〜505までと同様である。処理シーケンス1905でWebサーバ１からコンテンツを取得後、訪問履歴を記録するが、前述したようにアクセス時刻も合わせて保存する(1906)。次いで、訪問履歴データベース105を参照して、Webサーバ１から取得したコンテンツに既読情報を埋め込むためのコンテンツ変換処理を行う(1907)。

本コンテンツ変換手順を図２０を用いて説明する。まず始めに変換ルールデータベース110から既読済みリンクの表示方法を取得する(2000)。ユーザIDがu0000001のユーザの場合、図１８の1801に示す3種類の表示方法が取得される。次いで、コンテンツ中の相対形式URLを絶対形式URLに変換するためのベースURLとして、取得したコンテンツのURLの親ディレクトリを設定する(601)。ただし、コンテンツ中にBASEタグがあった場合には、前記ベースURLをBASEタグのhref属性で指定されているURLに変更する(603)。次いで、コンテンツのBODYタグ内の全てのAタグについてリンクの表示方法変換処理を行う(604、605)。始めにAタグのhref属性からURLを抽出する。URLが相対パス形式の場合には前記ベースURLを元に絶対パス形式URLに変換する(606)。次いで、抽出したURLが訪問履歴データベース105に含まれているか確認する(607)。含まれている場合、コンテンツ更新データベース1401から本URLの最終更新時刻を取得する(2001)。次いで、前記ステップ2000で取得したCSS情報の中から前記ステップ2001で取得したコンテンツ最終更新時刻に適合するスタイル情報を選択し、Aタグのstyle属性に追加する。本CSS情報と一致するプロパティが既に含まれている場合には上書きする(2002)。これらの処理により、コンテンツ中のURLの中で訪問履歴データベース105に存在するURL、すなわち既読済みURLについて、コンテンツ更新時刻を加味した形でユーザに既読情報として提示することができる。上記第３の実施例では中継サーバ103がクライアント100のプロキシサーバとして動作する例で説明したが、上記第２の実施例のようにURLを書き換えて中継する形態でも実現できる。

次に発明の第４の実施形態について説明する。第４の実施形態ではユーザがURLに対して重要度などの属性を追加し、コンテンツ中にそのURLが存在する場合、属性値ごとに設定された表示方法でリンクの表示方法を変換し、ユーザに提示することを可能とする。
図２１に示す属性表示名定義データベース2100と図２３に示す属性マッピングデータベース2300を新たに設ける。属性種別表示名データベース2100は、コンテンツに割り当てられる属性種別IDに対して実際にクライアントで表示される属性表示名のマッピングを定義するテーブルである。本実施例では属性種別IDとして"attr0"、"attr1"、"attr2"、"attr3"の4つを定義している。これはユーザがコンテンツに対して4種類の属性を設定することが可能ということを意味する。本実施例では属性種別IDを４つ定義しているが、もちろん任意の数の属性種別IDを利用することも可能である。属性マッピングデータベース2300は、URLと属性種別IDを対応を格納するためのテーブルである。マッピングの方法として、絶対形式URLに対して属性種別IDを一対一に割り当てる方法と、アスタリスク記号を利用して部分URLに対して属性種別IDを割り当てる方法を提供する。後者の方法では、アスタリスクとURLの断片を組み合わせてURL断片に対する前方一致、後方一致によりURLと属性種別IDのマッピングを定義することができる。属性表示名の設定インターフェイス例を図２２に示す。ユーザは、表示名を設定したい属性種別IDを選択し(2202)、属性表示名を入力後(2201)、"適用"(2203)または"完了"(2204)ボタンを押すことで、属性IDに表示名を設定することが出来る。通常、ユーザは本表示名を用いてコンテンツ(URL)に対して属性の設定等を行う。

次にコンテンツに対する属性設定のインターフェイス例を図２４に示す。本インターフェイス画面の作成は、中継サーバ103がコンテンツをクライアント100に返却する際(図５の処理ステップ508、図８の処理ステップ811、図１９の処理ステップ1908)に、図２５に示すコンテンツに対する属性種別設定用のHTML断片を追加することで実現する。図２４中の属性種別一覧2402に表示される属性名は上記属性表示名設定インターフェイスでユーザが設定した属性表示名となる。ユーザは現在表示しているコンテンツに対して属性種別を設定したい場合、属性種別一覧2502から属性種別を選択し、"属性の設定"ボタン(2403)を押すことで属性種別を設定することが出来る。"属性の設定"ボタン(2403)が押されると、図２５のHTML断片に従い属性種別IDと設定対象のURLが中継サーバ103に通知される。本例ではコンテンツとは別の子ウインドウを開いてサーバに設定を要求するようにしている。設定要求を受け取った中継サーバ103は、属性マッピングデータベース2300のユーザID(300)に対応するURL属性マッピング(2301)を更新する。次いで、子ウインドウに対して設定完了のメッセージを返却する。

図２６に部分URLに対して属性種別を設定するためのインターフェイス例を示す。部分URL入力エリア2601にアスタリスク記号を用いて部分URLを入力し、設定したい属性種別を選択後(2602)、”適用”(2603)もしくは”完了”(2604)ボタンを押すことにより、中継サーバ103に属性設定の要求を行う。上記個別コンテンツへの設定と同様に、中継サーバ103は、属性マッピングデータベース2300のユーザID(300)に対応するURL属性マッピング(2301)を更新する。

本実施例では変換ルールデータベース110のテーブル構造も図４に示した実施例１の構成から拡張されている。すなわち図２７に示すように、ユーザＩＤ300に対して設定される既読時表示方法の欄1800は、属性種別ごとに細分され、設定された属性に対応して表示スタイルを格納できるようなテーブル構造となる。また、この属性種別に対する表示スタイルを設定するためのインターフェイス画面の例を図２８示す。表示スタイルを設定したい属性種別を属性種別一覧から選択して欄2802に記入し、欄2801に表示スタイルをCSSとして入力し、適用ボタン2803もしくは完了ボタン2804を押すと、この対応付けが設定される。

次に第５の実施例として、URLの別名表記対応について説明する。URLは図２９に示すように字面が異なる場合でも、結果として同一のコンテンツとなる場合がある。たとえば、スラッシュで終わるURLの場合、終端のスラッシュを省いた形のURLと同一のコンテンツを指す(2900)。また、スラッシュで終わるURLは、実際にはその仮想ディレクトリのインデックスなるWebサーバ中のインデックスファイルと同一のコンテンツを指す。インデックスファイルはWebサーバの種別や設定により、index.html、index.htm、index.jsp、index.asp、index.php、default.htmなどがある(2901)。さらに、DNSについても考えると、ローカルホスト名、FQDN名、IPアドレスとそれぞれ字面は異なっていても、DNSにより同一のサーバに対してマッピングされていれば、それぞれのURL表記は異なるにも関わらず同一のコンテンツとなる。加えて、DNSラウンドロビンを利用している場合は、ローカルホスト名やFQDN名に複数のIPアドレスが対応している場合もあり、これについても、同一のコンテンツを指すこととなる。(2902)。

そこで第５の実施例では、既読判定時に行うURLマッチング処理について、図３０に示すURLの正規化処理により別名の可能性のあるホスト名とインデックスファイル名の候補リストを取得し、既読判定時に本候補リストを用いることでURLマッチング処理を行う。以下、本正規化処理について説明する。

正規化処理は、ホスト名の部分とインデックスファイルの2つの部分の処理からなる。インデックスファイル名は、正規化対象URLのインデックスファイル名が空文字の場合、後述するインデックスファイル候補一覧を正規化結果とする(3002)。一方、何らかのファイル名だった場合、実際にWebサーバにHTTPリクエストを送る。サーバの応答が終端にスラッシュが付加されたURLへのリダイレクト要求だった場合には、処理ステップ3002と同様にインデックスファイル候補一覧を正規化結果とする。リダイレクト要求がない場合には、そのファイルそのものがインデックスファイルなので、正規化対象のインデックスファイル名をそのまま正規化結果とする。

ホスト名に対する処理としては、DNSを利用してIPアドレス一覧を取得し、正規化結果とする。具体的には、正規化対象のホスト名がIPアドレスだった場合には、DNSを用いてIPアドレスからホスト名を取得し、再度、ホスト名でIPアドレス一覧を取得し、正規化結果とする(3007)。一方、ホスト名だった場合には、DNSを用いてホスト名からサーバのIPアドレス一覧を取得し、正規化結果とする(3008)。
上記正規化処理から得られた、URLについての同一視できる可能性のあるインデックスファイル名のリストとWebサーバのIPアドレスリストを用いてURLのマッチング処理を行い、既読判定する。

次に図３１を用いてインデックスファイル候補一覧の定義方法について説明する。本インターフェイスにより、ユーザがインデックスファイルとして同一視したいファイル名を選択することができる(3102)。ここでユーザが選択したインデックスファイル名称一覧が上記正規化処理で利用される。また、スラッシュ有無チェックボックス(3101)とDNS解決チェックボックス(3103)では、それぞれ、正規化処理の処理ステップ3004、処理ステップ3006の実行を行うか否かを指示できる。また、システム管理者は上記設定のデフォルト値を設定できる。
上記により別名表記を持つURLの既読管理を実現できる。

次に第６の実施例として他ユーザの既読情報を確認する機能について説明する。本機能を用いることにより、他のユーザがコンテンツを参照したか否かを確認することができる。図３２に確認用のインターフェイス画面例を示す。図のように確認したいユーザのID(3201)と、URL(3202)を入力し、確認ボタン(3203)を押すと、指定されたユーザがURLを参照したか否かを確認することができる。
本実施例では、上記インターフェイス画面により指定されたユーザＩＤとＵＲＬとを用いて訪問履歴データベース108を検索し、検索結果を返す手段が、図１の訪問履歴管理部107に設けられる。

さらに訪問履歴データベース108に図１７に示す構成、つまりＵＲＬのアクセス情報としてアクセス時刻をも記録するものを採用すれば、指定したユーザがコンテンツを参照した時刻も知ることができ。
以上の検索、つまり他のユーザにとってコンテンツが既読か否かの検索に、図２９、図３０で説明したＵＲＬの別名表記対応を採用することも可能である。

また、本インターフェイス例ではユーザを一人選択しているが複数のユーザを同時に選択できるよう実現することも可能である。また、確認したいユーザIDの一覧についてはLDAPと連携して部下一覧のみ確認できるようにすることも可能である。
本実施例によれば他ユーザがコンテンツを参照したか否かを確認することができる。これにより重要な情報を読んだか否かを確認することが出来る。

中継サーバで既読情報を一括管理することにより、ユビキタス環境において既読管理サービスを提供し、それによりユーザのWebアクセス効率の向上を図ることが可能となる。

Web既読管理システムの最も基本的な１実施例における全体構成図である。 Web既読管理システムの最も基本的な１実施例におけるユーザ管理データベースのテーブル構成図である。 Web既読管理システムの最も基本的な１実施例における訪問履歴データベースのテーブル構成図である。 Web既読管理システムの最も基本的な１実施例における変換ルールデータベースのテーブル構成図である。 Web既読管理システムの最も基本的な１実施例におけるクライアント、中継サーバおよびWebサーバの間の処理シーケンス図である。 Web既読管理システムの最も基本的な１実施例におけるコンテンツの変換処理フロー図である。複数クライアントが存在する場合の全体構成図である。中継サーバがURL書換えを行う１実施例におけるクライアント、中継サーバおよびWebサーバ間の処理シーケンス図である。中継サーバがURL書換えを行う１実施例における中継サーバのログイン画面である。中継サーバがURL書換えを行う１実施例における既読管理サービスのポータル画面である。中継サーバがURL書換えを行う１実施例における既読管理サービスのポータル画面のHTML断片である。中継サーバがURL書換えを行う１実施例におけるコンテンツの変換処理フロー図である。中継サーバがURL書換えを行う１実施例におけるURL書換えの書換え例である。コンテンツ更新検知機能を含む１実施例における全体構成図である。コンテンツ更新検知機能を含む１実施例におけるコンテンツ更新データベースのテーブル構成図である。コンテンツ更新検知機能を含む１実施例におけるコンテンツ更新時刻確認処理フロー図である。コンテンツ更新検知機能を含む１実施例における訪問履歴データベースのテーブル構成図である。コンテンツ更新検知機能を含む１実施例における変換ルールデータベースのテーブル構成図である。コンテンツ更新検知機能を含む１実施例におけるクライアント、中継サーバおよびWebサーバ間の処理シーケンス図である。コンテンツ更新検知機能を含む１実施例におけるコンテンツの変換処理フロー図である。コンテンツ属性設定機能を含む１実施例における属性識別IDに設定する属性表示名を定義するデータベースのテーブル構成図である。コンテンツ属性設定機能を含む１実施例における属性表示名の設定インターフェイス例である。コンテンツ属性設定機能を含む１実施例におけるURLと属性種別IDの対応を格納するデータベースのテーブル構成図である。コンテンツ属性設定機能を含む１実施例におけるコンテンツ（URL）に対する属性を設定するインターフェイス例である。コンテンツ属性設定機能を含む１実施例におけるコンテンツ（URL）に対する属性を設定するインターフェイス例のHTML断片である。コンテンツ属性設定機能を含む１実施例における部分URLに対する属性を設定するインターフェイス例である。コンテンツ属性設定機能を含む１実施例における変換ルールデータベースのテーブル構成図である。コンテンツ属性設定機能を含む１実施例における表示スタイルを設定するインターフェイス例である。 URLの別名表記対応機能を含む１実施例における別名表記URLの一例である。 URLの別名表記対応機能を含む１実施例におけるURLの正規化処理例である。 URLの別名表記対応機能を含む１実施例における別名表記解消処理の設定インターフェイス例である。他ユーザの既読状態確認機能を含む１実施例における既読状態確認用のインターフェイス例である。

符号の説明

１００：クライアント、１０３：中継サーバ、１０５：ユーザ管理データベース、１０８：訪問履歴データベース、１１０：変換ルールデータベース、１１１、１１２、１１３：Webサーバ。

Claims

クライアントのWebブラウザに代わってWebサーバからコンテンツの取得を行う中継サーバによってクライアントに既読管理サービスを提供するWeb既読管理方法であって、 (1)前記中継サーバがクライアントのログイン要求を受け付けるステップ、
(2)クライアント認証機能によってクライアントの認証を行い、該クライアントとのセッションを張るステップ、
(3)前記クライアントのWebブラウザからコンテンツ取得の要求を受け付けるステップ、
(4)要求を受け付けた要求にしたがっては要求先のWebサーバからコンテンツを取得するステップ、
(5)前記ステップ(4)でアクセスしたURLを、前記クライアントの訪問履歴として訪問履歴データベースに記録するステップ、
(6)前記ステップ(4)で取得したコンテンツに含まれるリンクについて、前記訪問履歴データベースを参照して前記クライアントが訪問済みか否かの既読判定を行い、訪問済みのリンクの場合には、既読リンクの表示方法を格納する変換ルールデータベースを参照してリンクの表示方法を変更するステップ、及び
(7)変更したコンテンツを前記クライアントに返却するステップ、
を有することを特徴とするWeb既読管理方法。
前記前記訪問履歴データベースを参照して、クライアントが訪問したリンクについてコンテンツが更新されているかを巡回して確認するステップを更に有し、前記ステップ(6)のリンクの表示方法変更はコンテンツの更新時期に応じて指定された表示方法に変更することを特徴とする請求項１記載のWeb既読管理方法。
前記ステップ(7)でコンテンツをクライアントに返却する際に、該コンテンツのURLに対応して該コンテンツのユーザ定義の属性をユーザに設定させる属性設定インターフェイスを該コンテンツに追加して返却し、前記変換ルールデータベースには、クライアント毎に、ユーザが設定したコンテンツの属性に対応して前記ユーザが選択したリンクの表示方法を格納し、前記ステップ(6)では、前記取得したコンテンツに含まれるリンクについて属性が設定されていた場合は、前記変換ルールデータベースを参照して該属性に対応する表示方法を選択し、選択した表示方法に従いコンテンツを変換することを特徴とする請求項１記載のWeb既読管理方法。
前記属性設定インターフェースは、クライアントに返却するコンテンツのＵＲＬの一部をなす部分ＵＲＬと、該部分ＵＲＬに対応する属性とをユーザに設定させるインターフェースを更に含むことを特徴とする請求項３記載のWeb既読管理方法。
前記属性設定インターフェースは、ＵＲＬの別名表記をコンテンツの既読判定時に同一視させるか否かをユーザに定義させるインターフェイスをさらに具備し、前記ステップ(6)では、取得したコンテンツに含まれるリンクについて前記別名表記を含めたURLマッチング処理を行い、該コンテンツが既読済みか否かを判定することを特徴とする請求項１記載のWeb既読管理方法。
クライアントのWebブラウザに代わってWebサーバからコンテンツを取得して前記クライアントに中継する中継サーバ上にて実現するWeb既読管理システムであって、
ユーザＩＤとパスワードとを管理するユーザ管理データベース、
前記クライアントからのログイン要求を受けた場合に前記ユーザ管理データベースを用いて要求元のクライアントのユーザ認証を行うクライアント認証部、
前記クライアントのWebページ訪問履歴として少なくともアクセスしたＵＲＬの一覧を格納する訪問履歴データベース、
前記クライアントからのコンテンツ取得要求により前記Webサーバからコンテンツを取得するWebアクセス部、
コンテンツのリンクが既読でリンクであった場合のコンテンツ表示方法を少なくとも前記ユーザＩＤに対応して格納する変換ルールデータベース、及び
前記Webアクセス部が取得したコンテンツのＵＲＬを前記訪問履歴データベースに記録する訪問履歴管理部、及び、
該ＵＲＬが既に前記訪問履歴データベースに存在していた場合に該ＵＲＬのコンテンツ表示方法を前記変換ルールデータベースに格納された表示方法に変換するコンテンツ変換部
を有することを特徴とするWeb既読管理システム。
前記訪問履歴管理部は、ユーザＩＤとそのユーザが既読か否かを確認したいＵＲＬの指定を受け、前記訪問履歴データベースの前記ユーザＩＤに対応した既読ＵＲＬの一覧に前記指定したＵＲＬが含まれるか否かを検索する検索手段を有する請求項６のWeb既読管理システム。