JP2010102488A - 更新監視システム、ウェブサーバ、プリンタおよび更新監視方法 - Google Patents

Abstract

【課題】ＰＣ等が無い状況において、ウェブサイトの更新監視が不便であった。
【解決手段】ウェブページの更新情報を監視するための監視情報へアクセスするための監視ＵＲＩ（Uniform Resource Identifier）を前記ウェブページ毎に生成し、該監視ＵＲＩのリソースとして前記監視情報を定期的に取得し、前記監視情報に更新を検知するとこれをユーザに通知する更新監視システムにおいて、クライアントに対応した個別のウェブページの更新情報を監視するための監視情報へアクセスするための監視ＵＲＩを前記個別のウェブページ毎に独立に生成する。
【選択図】図４

Description

本発明は、更新監視システム、ウェブサーバ、プリンタおよび更新監視方法に関し、特に、ウェブページの更新情報を監視するための監視情報へアクセスするための監視ＵＲＩ（Uniform Resource Identifier）を前記ウェブページ毎に生成する更新監視システム、ウェブサーバ、プリンタおよび更新監視方法に関する。

ウェブサイトの更新状況を知る方法として、ＲＳＳ（Rich Site Summary，Really Simple Syndication，RDF Site Summary）形式やＡＴＯＭ形式（Atom Syndication Format）のＸＭＬデータを提供するウェブサイトが増えつつある。例えば、ＲＳＳ形式で記述された文書には、ウェブサイトの各ページのタイトル、アドレス、見出し、要約、更新時刻などを記述することができる。ユーザは、興味のあるサイトや記事のＲＳＳやＡＴＯＭをＲＳＳリーダー等に登録し、ＲＳＳ形式やＡＴＯＭ形式で取得したデータとその直前に取得したデータとを比較することにより、サイトを直接訪問することなく更新情報を簡単に確認することができる。

その他、ウェブサイトの更新状況のみならず、複合機が自機の通信履歴、ジョブ履歴、アクセス履歴、メモリ使用状況、課金状況をＲＳＳ形式でコンピュータに提供すること、サーバから自装置の通信履歴や各種情報を示すＲＳＳ形式のデータを受信して更新情報を印刷すること、等についての開示もある（例えば特許文献１参照）。
また、複合機のボックス関連情報、アドレス帳の内容、掲示板の内容等の変更に応じて新しい更新情報エントリを反映したＲＳＳフィードファイル作成し、フィードファイルの更新情報エントリの中に未読のエントリが存在した場合には操作パネルに表示することについての開示もある（例えば特許文献２参照）。
特開2006-54732号公報 特開2006-324918号公報

しかしながら、前述した技術はいずれもＰＣ（Personal computer）等のコンピュータの存在が前提であり、ＰＣ等が無い状況において、ウェブサイトの更新監視が不便であった。例えば、ネットワークに対応したテレビでテレビショッピングを行い、注文する場合、ＰＣが無い状況で注文状況や配送情報を把握するのが困難であった。また、同様の状況でＰＣを用いて注文状況や配送情報を把握する場合も、ユーザ自身が注文状況や配送情報を表示するウェブページを訪問して、ＲＳＳ等のフィードをＲＳＳリーダー等に登録する必要があった。
本発明は、前記課題に鑑みてなされたものであり、ウェブページにおける更新状況をクライアント側で容易に把握可能な更新監視システム、ウェブサーバ、プリンタおよび更新監視方法の提供を目的とする。

上記課題を解決するために、本発明の更新監視システムでは、ウェブページの更新情報を監視するための監視情報へアクセスするための監視ＵＲＩ（Uniform Resource Identifier）を前記ウェブページ毎に生成するウェブサーバと、前記監視ＵＲＩへアクセスして取得した前記監視情報の更新を検知するクライアントと、を備える更新監視システムであって、前記ウェブサーバは、前記クライアントに対応した個別のウェブページの更新情報を監視するための監視情報へアクセスするための監視ＵＲＩを前記個別のウェブページ毎に独立に生成する構成としてある。

前記ウェブページは、ＨＴＭＬやＸＨＴＭＬやＸＭＬ等のマークアップ言語で記述されたファイルであり、単一のファイルであっても複数ファイルで構成されるファイル群であってもよい。更新情報は、更新のあったファイル名や、各ファイルで更新された部位を指定するＵＲＩが記載されたファイルであり、例えば、ＲＳＳ（Rich Site Summary，Really Simple Syndication，RDF Site Summary）形式やＡＴＯＭ形式（Atom Syndication Format）のＸＭＬデータで該当する。更新情報に記述する更新数は、１以上で任意に指定可能である。ＵＲＩはリソース位置をユニークに特定する情報であり、例えば、ＵＲＬ（Uniform Resource Locator）やＵＲＮ（Uniform Resource Name）等である。

クライアント個別に用意されたウェブページなので、更新情報はウェブページ毎に独立に生成される。従って、監視ＵＲＩにアクセスすると、例えばテレビショッピングの注文状況や配送状況等の個人情報を漏洩させること無く更新情報を容易に監視可能になる。

本発明の選択的な一側面として、前記クライアントは印刷機能を有しており、前記更新を検知したウェブページを取得して印刷する構成としてもよい。該構成によれば、前記クライアントが印刷機能を有する場合は、注文状況が更新されて注文完了になった場合などに自動的にその内容のプリントアウト可能にする。プリントアウトは、注文完了の証明書類として利用することも可能である。すなわち、別途、注文完了証明書類を郵送したりブラウザで表示させてから印刷させたりするのではなく、更新が検知されると更新情報を自動的にプリントアウト可能な状態になるので、ウェブサーバの利用者のみならず管理者についても手間やコストが改善される。

上述した更新監視システムは、他の機器に組み込まれた状態で実施されたり他の方法とともに実施されたりする等の各種の態様を含む。また、本発明は上記更新監視システムを構成するウェブサーバやクライアント、該クライアントに印刷機能を備えさせたプリンタ、上述したシステムの構成に対応した工程を有する更新監視方法、上述したシステムの構成に対応した機能をコンピュータに実現させるプログラム、該プログラムを記録したコンピュータ読み取り可能な記録媒体、等としても実現可能である。これらウェブサーバ、クライアント、プリンタ、更新監視方法、更新監視プログラム、該プログラムを記録した媒体、の発明も、上述した作用、効果を奏する。むろん、請求項２に記載した構成も、前記ウェブサーバや前記クライアントや前記方法や前記プログラムや前記記録媒体に適用可能である。

以下、下記の順序に従って本発明の実施形態を説明する。
（１）商品注文システムの構成：
（１）商品注文システムの構成：
（２）商品管理処理：
（３）他機器への監視情報登録：
（４）ブログサーバの構成、投稿処理：
（５）まとめ：

（１）商品注文システムの構成：
図１は、本発明の実施形態に係る商品注文システムの概略構成を示す構成図である。同図において、商品注文システム１００は、視聴者に商品を紹介するテレビ１０と、商品の詳細情報ページや注文シートの印刷と商品の発注と商品の注文状況の監視とを行うプリンタ２０と、商品の詳細情報ページや注文シートのデータ提供や商品の受注並びに注文状況情報の管理を行う注文管理サーバ３０と、商品の配送情報管理並びに配送情報を提供する商品配送センター４０と、を備える。

テレビ１０はネットワーク接続に対応しており、放送局からの放送データをチューナで受信したデジタルテレビ放送の番組と、データ放送によって受信したコンテンツとを出力表示できる。具体的には、テレビ１０のディスプレイ１０ｄは、番組表示部とコンテンツ表示部とを備えており、番組表示部に表示されるデジタルテレビ放送の番組内容に関連した静止画像や文字情報等がコンテンツ表示部に表示される。データ放送においては、表示用コンテンツデータに付随した情報（例えば詳細説明ページ等）を印刷可能な場合があり、印刷用コンテンツを印刷するための印刷ボタンがコンテンツ表示部に表示される。ユーザが、リモコン等の操作入力部を操作して印刷コンテンツの印刷指示を行うと、テレビ１０は、印刷用コンテンツを印刷するための印刷ジョブ（所定の言語で記述されたスクリプト）を生成し、インターフェースを介してプリンタ２０に送信する。

テレビ１０とプリンタ２０とは、例えばＬＡＮ（Local Area Network）等を介して相互通信可能に接続されており、ユニバーサルプラグアンドプレイ（UPnP（ユー・ピィ・エヌ・ピィ・インプルメンターズ・コーポレイションの登録商標））対応のネットワーク装置である。UPnPにおいては、ネットワーク装置を任意のタイミングでネットワークに接続したり切断したりできる。ＬＡＮは、ＩＥＥＥ８０２．３等の有線ネットワークであっても、ＩＥＥＥ８０２．１１等の無線ネットワークであってもよい。また、テレビ１０とプリンタ２０とを接続する通信回線としては、赤外線通信、Ｂｌｕｅｔｏｏｔｈ等の無線通信、シリアルポートを介した通信、パラレルポートを介した通信、等、いかなる通信方式であってもよく、また今後開発されるいかなる通信態様であっても同様に利用可能である。

図２は、プリンタ２０の電気的構成を示すブロック図である。同図に示すプリンタ２０はいわゆる複合型の印刷装置であり、印刷部２０ａと読取部２０ｂとこれらを制御する制御部２０ｃとが一体化されている。制御部２０ｃは、ＣＰＵ、ＲＡＭ、ＲＯＭを備えており、ＲＯＭに記憶されたプログラムを適宜ＲＡＭに展開しつつ、ＲＡＭをワークエリアとしてＣＰＵがプログラムを実行して、プリンタ２０の動作を制御し、印刷機能とスキャナ機能とコピー機能とを実現する。プリンタ２０は、制御部２０ｃの制御に従って、接続されたコンピュータに読取部２０ｂで読取った画像データ（スキャンデータ）を出力したり、接続されたテレビ１０やコンピュータ等から入力された印刷ジョブに基づく印刷を印刷部２０ａに実行させたり、読取部２０ｂで読取った画像データを直接或いはコンピュータを介して印刷部２０ａへ送って印刷させることによりコピー機能を実現したりする。

制御部２０ｃには、プリントエンジン２０ｄと、ボタンやタッチパネル等を有する操作入力部２０ｅと、液晶パネル等を有する表示部２０ｆと、テレビ１０のインターフェースに接続されたインターフェース（Ｉ／Ｆ）２０ｇと、コンピュータのインターフェースに接続されたインターフェース（Ｉ／Ｆ）２０ｈと、インターネットへ接続されたインターフェース（Ｉ／Ｆ）２０ｉとが接続されており、印刷部２０ａへの印刷データの入力や読取部２０ｂの読取データの出力等がこれらＩ／Ｆ２０ｇ，２０ｈを介して行われる。
また、制御部２０ｃの制御下においてプリンタ２０は、印刷制御部５０ａと、スクリプト解釈部５０ｂと、通信部５０ｃと、フィード取得部５０ｄと、読取制御部５０ｅと、複写制御部５０ｆとして機能する。

印刷制御部５０ａは、印刷ジョブを管理したり、印刷データに基づいてプリントエンジン２０ｄを制御して印刷媒体に対する印刷を実行したりする。
スクリプト解釈部５０ｂは、所定の構造化言語で記述されたスクリプトを解釈して、画像や文字の配列（レイアウト）を決定して印刷データを作成する。所定の構造化言語としては、ＸＭＬ（eXtensible Markup Language）、ＸＨＴＭＬ（eXtensible HyperText Markup Language）、ＨＴＭＬ（Hyper Text Markup Language）、ページ記述言語（ＰＤＬ（Page Description Language））等、様々な言語が採用可能である。

通信部５０ｃは、Ｉ／Ｆ２０ｉを介して所定のプロトコルに基づいてインターネットに接続し、指定されたＵＲＩ（Uniform Resource Identifier）のリソースを、例えばＨＴＴＰ，ＦＴＰ等の通信プロトコルに基づいて要求する。なお、ＵＲＩにて指定できるリソースは、インターネット上のコンピュータに存在するリソースに限らず、プリンタ２０内のメモリに記憶されているリソース、プリンタ２０にＩ／Ｆ２０ｈを介して接続されたコンピュータ上に存在しているリソース、テレビ１０のメモリに記憶されているリソース、等も指定可能である。

フィード取得部５０ｄは、ＲＳＳ（Rich Site Summary，Really Simple Syndication，RDF Site Summary）形式やＡＴＯＭ形式（Atom Syndication Format）等に従って記述されたフィードと呼ばれるメタデータのＵＲＬを登録可能である。このフィードには、Ｗｅｂサイト内の新着情報、個々の記事のタイトル、Ｗｅｂサイトのリンク先（ＵＲＬ）、リンク先の要約、フィードの更新日時等が記述されている。フィード取得部５０ｄは、定期的、もしくは取得指示が行われ時に、登録されているＵＲＬのフィードを取得し、取得したフィードをその直前に取得したフィードと比較して、その更新情報をユーザに通知する。

図３は、注文管理サーバ３０の電気的構成を示すブロック図である。同図において、注文管理サーバ３０は、制御部３０ａと通信部３０ｂとハードディスクドライブ（ＨＤＤ）３０ｃと操作入力部３０ｄと表示部３０ｅとを備える。制御部３０ａは、ＣＰＵ、ＲＡＭ、ＲＯＭを備え、ＲＯＭに記憶されたプログラムを適宜ＲＡＭに展開しつつ、ＲＡＭをワークエリアとしてＣＰＵがプログラムを実行して、注文管理サーバ３０を制御する。

通信部３０ｂは、Ｉ／Ｆ３０ｆを介してインターネットに接続されており、所定のプロトコル（例えばＴＣＰ／ＩＰ，ＨＴＴＰ，ＦＴＰ等の通信プロトコル）に基づいた要求に対する応答として、指定されたＵＲＩのリソースを要求元へ送信する。例えば、プリンタ２０から商品詳細ページのＵＲＬのリソースが要求されると、該ＵＲＬに対応する商品詳細ページのデータをＨＤＤ３０ｃから取得してプリンタ２０へ送信する。
また、通信部３０ｂは、Ｉ／Ｆ３０ｇを介して商品配送センター４０と相互通信可能に接続されており、所定のプロトコル（例えばＴＣＰ／ＩＰ，ＨＴＴＰ，ＦＴＰ等の通信プロトコル）に基づいて、商品配送センター４０とデータの送受信が可能である。

制御部３０ａの制御下において、注文管理サーバ３０は、個別ウェブページ生成部６０ａと、監視情報生成部６０ｂと、個別ウェブページ更新部６０ｃと、監視情報更新部６０ｄして機能する。ここで言う監視情報とは、個別ウェブページに含まれる情報を項目分けして見出しを付け、各見出しに各情報へのリンクを付加したものであり、例えば、ＲＳＳ形式やＡＴＯＭ形式に従って記述されたフィードと呼ばれるメタデータが該当する。個別ウェブページと該個別ウェブページの監視情報とは互いに関連付けられて、ＨＤＤ３０ｃに格納される。個別ウェブページや監視情報はＵＲＩで指定して注文管理サーバ３０の外部から取得可能である。

また、監視情報には、各ウェブページの要約が含まれてもよい。要約とは、各ウェブページの簡略な説明であり、既存の文章の要約を作成する公知の要約作成プログラムを利用して自動生成したり、人が手動で作成したりできる。また、監視情報には、各ウェブページのタイトル、各ウェブページのＵＲＩを示す情報が含まれる。

また、注文管理サーバ３０のＨＤＤ３０ｃには、商品注文システム１００においてテレビ１０から注文可能な商品の、商品詳細や注文シートの画像データが格納されており、後述のショッピングチャンネルにおけるコンテンツサーバとしての役割も備える。これらの画像データも、ＵＲＩで指定して注文管理サーバ３０の外部から取得可能である。

（２）商品管理処理：
以上のように構成された商品注文システム１００における注文管理処理について説明する。本実施形態の商品注文システムは、いわゆるデジタルテレビ放送におけるショッピングチャンネルを利用して商品注文するものであり、概略、ショッピングチャンネルの視聴者がプリンタ２０を介して注文管理サーバ３０に商品の注文を行い、商品の注文後、注文した商品の受注から配送完了までの注文状況をプリンタ２０を利用して監視するものである。また、商品注文状況の監視情報を、プリンタ２０以外の機器へ送信して自動登録し、他の機器から商品の注文状況を監視することも可能である。

図４は商品注文システム１００において、一の注文にかかる処理の流れを時系列で示したタイムチャート、図５はプリンタ２０で実行される印刷処理のフローチャート、図６はサーバで実行される注文状況管理処理のフローチャート、図７はプリンタ２０にて実行される読取処理のフローチャートである。図５の印刷処理は、視聴者が、ショッピングチャンネルの視聴中に気に入った商品を見つけて、操作入力を行って商品の詳細情報の印刷を選択すると開始される。すなわち、ＵＲＩを含む印刷命令がプリンタ２０へ入力されたときに開始される。図７の処理は、ユーザが読取部１０ｂに読取対象をセットし、操作入力部２０ｅで読取を指示したり、接続されたコンピュータから読取を指示したりすると開始される。

なお、本実施形態においては、テレビ１０からプリンタ２０へ入力される印刷命令を契機として処理を開始する例について説明してあるが、プリンタ２０の操作入力部２０ｅを操作して、直接、所望のインターネット上のＵＲＩを指定して印刷処理を開始することも可能である。プリンタ２０で直接ＵＲＩを指定する場合は、プリンタ２０にテレビ１０のテレビ放送やコンテンツを表示する機能と同等の機能を備えさせてもよい。

《プリンタ》
図５の印刷処理が開始されると、ステップＳ１００において、プリンタ２０の制御部２０ｃは、入力された印刷命令がＵＲＩを指定した印刷命令であるか否かを判断する。判断の結果、ＵＲＩを指定した印刷命令であればステップＳ１０２に進み、ＵＲＩを指定しない印刷命令であればステップＳ１０６に進む。ステップＳ１０６に進むと、スクリプト解釈部５０ｂが入力された印刷ジョブのスクリプトを解釈し、その解釈結果に基づいて印刷制御部５０ａがレイアウト処理、色変換処理、ハーフトーン処理、インターレース処理等の印刷データ生成処理を実行し、生成した印刷データに基づいてプリントエンジン２０ｄを制御して印刷用紙に印刷を実行する。

ステップＳ１０２に進むと、通信部５０ｃが、注文管理サーバ３０にＵＲＩのリソースを要求し、印刷命令で指定されたＵＲＩからリソースを取得する。ＵＲＩで指定可能なリソースは、テレビ１０のメモリアドレスやインターネット上のＵＲＬ等、プリンタ２０でアクセス可能であれば様々なものが可能であるが、本実施形態においては、商品ページと注文シートのリソース位置を示すＵＲＩとして注文管理サーバ３０上のＵＲＩが指定された場合について説明する。

《サーバ》
このとき、注文管理サーバ３０では図６に示す注文状況管理処理が繰り返し実行されており、プリンタ２０から入力されたリソースの要求を通信部５０ｃが受付けて、ステップＳ２００が条件成立となり、ステップＳ２０２に進む。

ステップＳ２０２においては、個別ウェブページ生成部６０ａが、各要求にユニークな認証情報を生成し、監視情報生成部６０ｂが各要求に対応して以降の処理において発生する注文の進行状況を監視するための監視情報を生成する。ここで言う監視情報とは、例えば、ＲＳＳ形式やＡＴＯＭ形式で記載されたメタデータが該当し、インターネット上でＵＲＩを用いて指定して取得可能な情報である。以下、この監視情報のＵＲＩを監視ＵＲＩと呼ぶことにする。

制御部３０ａは、要求されたＵＲＩの指し示す注文シートのデータを取得し、注文先のＵＲＩと作成した認証情報と監視情報とを注文シートに含めた個別注文シートを作成し、通信部３０ｂを制御してこの個別注文シートと商品詳細ページのデータをプリンタ２０に送信する。注文シートに含められる注文先のＵＲＩや認証情報や監視情報は、「 http://xxxx.xxxx.xxxx/xxx.rdf 」のように文字情報として記載されていてもよいが、例えば、ＱＲコードやバーコード等のように電子計算機での読取りを前提とした図形情報に符号化として記載すると、スキャナ等で読取って情報を取得するまでの読取速度向上や記載可能な情報量の向上が見込める。

このように作成された認証情報は、送信した注文シートを利用してユーザがショッピングを行ったときに、注文・在庫・配送・課金等の情報を注文毎に識別管理するための注文管理コードとして利用される。すなわち、注文管理サーバ３０では、同一の認証情報を有する情報は同一の注文に属する情報として扱われ、各認証情報に対応する監視情報には同一の認証情報を有する情報の一覧が記載される。なお、監視情報はステップＳ２０２で作成されずともよく、実際に注文シートよる注文が行われてから作成して、プリンタ２０に通知されても構わない。

《プリンタ》
ステップＳ１０４においては、制御部２０ｃが通信部５０ｃを介して個別注文シートと商品詳細ページのデータを受信し、ＲＡＭに保存する。
ステップＳ１０６においては、制御部２０ｃは印刷部２０ａを制御して、ＲＡＭに保存された個別注文シートと商品詳細ページとを印刷する。
ユーザは、印刷された商品詳細ページを見て商品の購入を検討し、購入を決めると注文シートに注文する商品の種類・数量等を記入する。そしてユーザは、注文シートをプリンタ２０の読取部２０ｂにセットし、操作入力部２０ｅを操作して注文シートのスキャンを実行させる。

《プリンタ》
操作入力部２０ｅで注文シートのスキャンが指示されると、ステップＳ３００において、制御部２０ｃは読取部２０ｂを制御してセットされた読取対象をスキャンし、スキャンデータを取得する。

ステップＳ３０２において、制御部２０ｃはスキャンデータが注文シートであるか否かを判断する。注文シートのスキャンであるか否かの判断は、ユーザが操作入力部で注文シートのスキャンである旨を指定したか否かに基づいて行う。注文シートのスキャンである旨の指定が行われていればステップｓ３０４に進み、注文シートのスキャンである旨の指定が行われていない場合はステップＳ３０８に進む。無論、注文シートに予めバーコードやＱＲコードで注文シートである旨を記載しておき、ステップＳ３０２において、スキャンデータにこれらの記載を検出すると自動的に注文シートのスキャンであると判断してもよい。

ステップＳ３０４においては、スキャンデータを注文管理サーバ３０に送信する。より具体的には、スキャンデータのＯＣＲ処理やＱＲコード検出処理を実行し、スキャンデータ内の認証情報や注文先のＵＲＩに該当する情報を抽出し、取得した注文先のＵＲＩに認証情報を付したスキャンデータを送信する。この送信においては、注文管理サーバ３０上のプログラムを呼び出して処理結果を受取るリモートプロシージャコール（XML-RPC、JAX-RPC等）を利用して、監視情報のリクエストを行うと処理が効率的に行える（例えばXML-RPCを利用するのであれば、図８に示すような構文が使用可能である。）。

図８のXML-RPCには、監視ＵＲＩを自動的に返信させるための関数名と、認証情報とスキャンデータのメタ情報やスキャンデータ名をパラメータとして含んでいる。図８のXML-RPCを受信した注文管理サーバ３０は、送信されたスキャンデータをプリンタ２０の認証情報が付された情報として保存するとともに、監視情報生成部６０ｂが自動的に実行され、XML-RPCに記載された認証情報を有する情報を一覧化する監視情報を作成し、監視ＵＲＩを生成してプリンタ２０に送信する。

なお、注文管理サーバ３０からプリンタ２０へ送信される監視ＵＲＩは、完全ＵＲＩである必要は無く、相対ＵＲＩであってもよい。例えばスキーム（リソースを取得するための名前のつけ方）やリソースを提供するホストマシンの名前が別途通知済みであれば、ウェブページ間でユニークな部分（例えば、パス（ホストマシン上でのリソース自身の名前）等）のみを監視情報とし、クライアント側で完全ＵＲＩに補完してもよい。具体的には、図８のXML-RPCに対する応答として、図９のように、監視情報がＲＳＳ２．０形式であることを示す情報（feed=rss2）と、個別ウェブページに含まれる各情報のＩＤ（p=123）と、認証情報（orderid=12345678）とを送信し、プリンタ２０側でスキームとホストマシン名と補完して「http://xxxx.com/?feed=rss2&p=123&orderid=12345678」という完全ＵＲＩを生成する等である。

図８のXML-RPCを受信した注文管理サーバ３０は、認証情報と投稿記事のＩＤとをキーとして監視情報を生成する。ここで注文管理サーバ３０で作成される監視情報は、例えば、図１０のようなＲＳＳ形式のｘｍｌである。すなわち、認証番号と、オペレータの保存した注文情報にアクセスするためのＵＲＩと、注文情報の説明と、更新日時と、が記載されている。更新日時を確認することにより、監視情報が更新されたか否かを判断可能であり、注文管理サーバ３０にＵＲＩを指定した要求を行うことにより、注文完了ページを取得して印刷可能になる。

ステップＳ３０６においては、注文管理サーバ３０から送信された監視ＵＲＩを受信し、受信した監視ＵＲＩをフィード取得部５０ｄに登録する。

なお、注文管理サーバ３０に投稿されたスキャンデータはオペレータがスキャンデータに記載された情報を受付ける受注処理を待つ状態となる。オペレータはスキャンデータを視認して、注文個数や色やサイズ等の注文情報を注文管理サーバ３０の操作入力部から入力し、入力した情報をスキャンデータに付された認証情報と関連付けて注文管理サーバ３０に保存（投稿）する。この保存された情報は、同一の識別番号を付された情報の中で、注文受付完了を示す情報となる。具体的には、ＲＳＳ形式のＸＭＬ文書に、図１１に例示するように、タグで挟まれた位置に注文受付ページの情報が登録される。図１１に示すｘｍｌには、保存された情報のタイトル（注文受付完了）と、保存された情報固有の情報（p=124&ordered=12345678&print=true）と、スキームやホストマシン名を示す情報（http://xxxx.com/?p=124）と、更新日時（Fri, 29 Aug 2008 04:38:59 +0000）と、情報の説明（注文受付確認）と、が含まれている。なお、図１１に示すｘｍｌのように、ＵＲＩを指定して保存された情報を取得すると自動的に印刷処理が実行される（print=trueが末尾に付加されている）ｘｍｌとしてもよい。

《サーバ》
オペレータが注文受付完了を示す情報を注文管理サーバ３０に保存すると、図６の注文状況管理処理ではステップＳ２０８の注文状況情報の更新を検知したか否かの判断が条件成立となり、ステップＳ２１０が実行される。
ステップＳ２１０において、注文管理サーバ３０の制御部３０ａは、更新された注文状況情報についての情報を含む監視情報を作成して、作成した監視情報をＨＤＤ３０ｃに格納する。

受注完了すると注文管理サーバ３０から商品配送センター４０へ配送依頼が行われる。この配送依頼とともに認証情報も、商品配送センター４０へ通知される。商品配送センター４０は、配送状況（商品準備完了、センターから発送、最寄りの店舗への到着、配送完了等）が変化すると、その変化後の配送状況情報に認証情報を付して、注文管理サーバ３０に送信する。すると、個別ウェブページ更新部６０ｃが送信された配送状況情報をＨＤＤ３０ｃに保存し、監視情報更新部６０ｄが監視情報を、例えば図１２に示すｘｍｌのように更新してＨＤＤ３０ｃに格納する。

《プリンタ》
図１３は、プリンタ２０で実行される更新監視処理のフローチャートである。同図の処理はプリンタ２０の電源が投入されている間は繰り返し実行されている。
ステップＳ４００においては、監視先が登録されているか否かを判断する。監視先が登録されている場合はステップＳ４０２に進み、監視ＵＲＩにアクセスして監視情報を取得する。監視ＵＲＩが登録されていない場合は、処理を終了する。

ステップＳ４０３においては、ステップＳ４０２で取得した監視情報が更新されたか否かを判断する。監視情報が更新されたか否かは、取得したＲＳＳの情報を解析し、欄に記載の更新時間を利用して判断できる。また、取得した監視情報の情報ＩＤや内容と、その前回に同一のＵＲＩから取得した監視情報とを比較し、更新の有無を判断してもよい。判断の結果、監視情報が更新されていればステップＳ４０４に進み、監視情報に変更が無ければ更新監視処理を終了する。
ステップＳ４０４においては、制御部２０ｃが表示部２０ｆを制御して、注文状況に更新がある旨を表示する。

ステップＳ４０５においては、監視情報に登録された注文状況のうち、更新された情報を印刷するか否かの操作入力を待機する。表示パネルを見て更新があることを知ったユーザが印刷指示を行うと、印刷する旨の操作入力を受付けてステップＳ４０６に進む。ステップＳ４０６においては、通信部５０ｃを制御して更新された情報のＵＲＩのリソースを取得し、注文受付完了ページを印刷する。一方、印刷しない旨の操作入力を受付けると更新監視処理を終了する。無論、ユーザの印刷指示を待たずに、更新を検知すると自動的に更新された情報のＵＲＩからリソースを取得して自動的に印刷しても構わない。

（３）他機器への監視情報登録：
前述した実施形態では、注文完了後の監視情報の監視はプリンタ２０で行っていたが、プリンタ２０で監視情報の更新を待機するだけではなく、携帯電話やテレビ等の外部機器にも監視情報のＵＲＩを登録して、外部機器の更新を確認してもよい。外部機器で注文状況を監視できるとユーザの利便性が向上する。

図１４は、監視情報を外部機器へ登録するシステムの概略構成を示す構成図である。同図において、プリンタ２０は商品注文システムと同じものを使用するので、同一の符号を付して示し、説明を省略する。また、同図において、テレビ１１０や携帯電話１２０等の外部機器は、プリンタ２０と通信可能になっている。通信形態は、有線無線を問わず、様々なものが利用可能である。外部機器は、プリンタ２０のフィード取得部と類似のフィードリーダを備えており、登録されたフィードのＵＲＩにアクセスして監視情報を取得し、取得した監視情報を前回取得した監視情報と比較して更新の有無を判断する。そして、更新を検出すると、検出した更新をディスプレイに表示してユーザに通知する機能を有する。

外部機器にフィードを登録する手法として、本実施形態では、プリンタ２０で印刷したＱＲコードを利用する方法を例示する。すなわち、前記印刷処理においてプリンタ２０で印刷される注文受付完了ページが自動的に印刷されるようにｘｍｌを作成し、注文受付完了ページに予め監視情報のＵＲＩを示す情報をＱＲコードで記載しておく。この印刷結果をプリンタ２０でスキャンして、ＱＲコードから監視情報のＵＲＩを復元する。プリンタ２０には、テレビ１１０や携帯電話１２０のアドレスを監視情報の送信先として予め登録しておくことが可能であり、ＱＲコードから復元したＵＲＩを所定のフォーマットでテレビ１１０や携帯電話１２０に送信する。無論、監視情報の記載の仕方はＱＲコードに限るものではなく、バーコードで記載してもよいし、文字記載していても構わない。

外部機器は所定のフォーマットで受信した監視情報のＵＲＩを、自動的にフィードリーダの監視対象に登録する機能を有しており、プリンタ２０から送信されたＵＲＩをフィードリーダに登録する。よって外部機器で監視情報の更新を検知可能となり、ユーザの利便性が向上する。

（４）ブログサーバの構成、投稿処理：
ところで、本発明はブログの更新状況監視にも利用できる。図１５は、本発明の一実施形態に係るブログシステムの概略構成を示す構成図である。同図において、ブログシステム２００は、プリンタ２０と、ブログサーバ１３０とを備える。ブログシステム２００は、注文管理サーバ３０がブログサーバ１３０として機能する点を除けば、前述した商品注文システム１００からテレビ１０の構成を除いた構成と同一なので各構成の詳細な説明は省略し、図１５並びに以降の説明において、商品注文システム１００と同じ符号を付して説明することにする。

図１６はブログシステム２００における投稿処理の流れを時系列で概略的に示したタイムチャート、図１７はブログシステム２００のプリンタ２０において実行される投稿処理のフローチャートである。

操作入力部２０ｅでスキャンが指示されると図１７の処理が開始され、ステップＳ５００において、制御部２０ｃは読取部２０ｂを制御してセットされた写真をスキャンし、スキャンデータを取得する。

ステップＳ５０２においては、制御部２０ｃはスキャンデータが投稿写真であるか否かを判断する。投稿写真のスキャンであるか否かの判断は、ユーザが操作入力部で投稿写真のスキャンである旨を指定したか否かに基づいて行う。投稿写真のスキャンである旨の指定が行われていればステップＳ５０２に進み、投稿写真のスキャンである旨の指定が行われていない場合はステップＳ５１６に進んでスキャンデータをプリンタ２０や不図示のコンピュータに保存して投稿処理を終了する。

ステップＳ５０２においては、ブログサーバ１３０に投稿したい旨の要求を行って投稿ＩＤと監視ＵＲＩとを取得する。このとき、投稿したい旨の要求を受信したブログサーバ１３０は、要求に応じた個別ブログページを作成し、該個別ブログページの投稿ＩＤと、該個別ブログページへのコメント投稿状況を監視する監視情報のＵＲＩとを生成して、プリンタ２０に送信する。

ステップＳ５０４において、投稿ＩＤと監視情報のＵＲＩとを受信したプリンタ２０の制御部２０ｃは、ステップＳ５００で取得したスキャンデータを投稿ＩＤの示す個別ブログページへ投稿する。
ステップＳ５０６において、プリンタ２０の制御部２０ｃは、監視情報のＵＲＩをフィード取得部５０ｄに登録する。

ステップＳ５０８において、フィード取得部５０ｄは、商品注文システムと同様に、所定時間置きに監視ＵＲＩにアクセスして監視情報を取得し、監視情報の更新の有無を判断する。監視情報に更新を検知するとステップＳ５１０に進み、更新を検知しない場合は処理を終了する。
ステップＳ５１０において、フィード取得部５０ｄは、表示部２０ｆに更新がある旨の表示を行う。

ステップＳ５１２において、フィード取得部５０ｄは、更新されたコメントの印刷の可否をユーザに問合せ、必要であれば印刷する。すなわち、監視情報に登録された注文状況のうち、更新された情報を印刷するか否かの操作入力を待機する。表示パネルを見て更新があることを知ったユーザが印刷指示を行うと、印刷する旨の操作入力を受付けてステップＳ５１４に進む。一方、印刷しない旨の操作入力を受付けると更新監視処理を終了する。

ステップＳ５１４においては、フィード取得部５０ｄは、通信部５０ｃを制御して更新された情報のＵＲＩのリソースを取得し、注文受付完了ページを印刷する。無論、ユーザの印刷指示を待たずに、更新を検知すると自動的に更新された情報のＵＲＩからリソースを取得して自動的に印刷しても構わない。

以上説明したブログシステムにおいては、コンピュータの無い状況においても、プリンタ２０を用いてブログの更新を監視し、更新された内容を印刷して確認することができる。また、前記他機器への登録は、本ブログシステムにおいても利用可能であり、携帯端末やテレビ等でブログの更新を確認可能となる。

（５）まとめ：
以上説明したように、本発明の実施形態によれば、ウェブページの更新情報を監視するための監視情報へアクセスするための監視ＵＲＩ（Uniform Resource Identifier）を前記ウェブページ毎に生成し、該監視ＵＲＩのリソースとして前記監視情報を定期的に取得し、前記監視情報に更新を検知するとこれをユーザに通知する更新監視システムにおいて、クライアントに対応した個別のウェブページの更新情報を監視するための監視情報へアクセスするための監視ＵＲＩを前記個別のウェブページ毎に独立に生成することにより、ＰＣ等が無い状況において、ウェブサイトの更新監視が容易になる。

なお、本発明は上述した実施形態や変形例に限られず、上述した実施形態および変形例の中で開示した各構成を相互に置換したり組み合わせを変更したりした構成、公知技術並びに上述した実施形態および変形例の中で開示した各構成を相互に置換したり組み合わせを変更したりした構成、等も含まれる。

商品注文システムの概略構成を示す構成図である。 プリンタの電気的構成を示すブロック図である。 注文管理サーバの電気的構成を示すブロック図である。 一の注文にかかる処理の流れを時系列で示したタイムチャートである。 印刷処理のフローチャートである。 注文状況管理処理のフローチャートである。 読取処理のフローチャートである。 XML-RPCを利用した監視情報要求の一例である。 図８のXML-RPCに対する応答の一例である。 注文管理サーバで生成される監視情報の一例である。 更新された監視情報の一例である。 更新された監視情報の一例である。 更新監視処理のフローチャートである。 監視情報を外部機器へ登録するシステムの概略構成を示す構成図である。 ブログシステムの概略構成を示す構成図である。 ブログシステムの投稿処理の流れを時系列で示したタイムチャートである。 投稿処理のフローチャートである。

符号の説明

１０…テレビ、２０…プリンタ、２０ａ…印刷部、２０ｂ…読取部、２０ｃ…制御部、２０ｄ…プリントエンジン、２０ｅ…操作入力部、２０ｆ…表示部、２０ｇ…Ｉ／Ｆ、２０ｈ…Ｉ／Ｆ、２０ｉ…Ｉ／Ｆ、３０…注文管理サーバ、３０ａ…制御部、３０ｂ…通信部、３０ｃ…ハードディスクドライブ、３０ｄ…操作入力部、３０ｅ…表示部、３０ｆ…Ｉ／Ｆ、３０ｇ…Ｉ／Ｆ、４０…商品配送センター、１００…商品注文システム、１１０…テレビ、１２０…携帯電話、１３０…ブログサーバ、２００…ブログシステム

Claims (5)

1. ウェブページの更新情報を監視するための監視情報へアクセスするための監視ＵＲＩ（Uniform Resource Identifier）を前記ウェブページ毎に生成するウェブサーバと、
   前記監視ＵＲＩへアクセスして取得した前記監視情報の更新を検知するクライアントと、
   を備える更新監視システムであって、
   前記ウェブサーバは、前記クライアントに対応した個別のウェブページの更新情報を監視するための監視情報へアクセスするための監視ＵＲＩを前記個別のウェブページ毎に独立に生成することを特徴とする更新監視システム。
2. 前記クライアントは印刷機能を有しており、前記更新を検知したウェブページを取得して印刷する請求項１の更新監視システム。
3. ウェブページの更新情報を監視するための監視情報へアクセスするための監視ＵＲＩ（Uniform Resource Identifier）を前記ウェブページ毎に生成するウェブサーバであって、
   前記クライアントに対応した個別のウェブページの更新情報を監視するための監視情報へアクセスするための監視ＵＲＩを前記個別のウェブページ毎に独立に生成することを特徴とするウェブサーバ。
4. ウェブページの更新情報を監視するための監視情報へアクセスするための監視ＵＲＩ（Uniform Resource Identifier）を前記ウェブページ毎に生成するウェブサーバと通信可能に接続されたプリンタであって、
   前記監視ＵＲＩは、前記プリンタに対応した個別のウェブページの更新情報を監視するための監視情報へアクセスするために前記個別のウェブページ毎に独立に生成されており、
   前記監視ＵＲＩを指定して前記ウェブサーバから前記監視情報を取得し、前記監視情報に基づいて更新を検知したウェブページを取得して印刷することを特徴とするプリンタ。
5. ウェブページの更新情報を監視するための監視情報へアクセスするための監視ＵＲＩ（Uniform Resource Identifier）を前記ウェブページ毎に生成し、該監視ＵＲＩのリソースとして前記監視情報を定期的に取得し、前記監視情報に更新を検知するとこれをユーザに通知する更新監視方法であって、
   クライアントに対応した個別のウェブページの更新情報を監視するための監視情報へアクセスするための監視ＵＲＩを前記個別のウェブページ毎に独立に生成することを特徴とする更新監視方法。

Images