JP4810339B2 - ネットワーク通信装置、ネットワーク通信装置の制御方法、ネットワーク通信装置の制御プログラムおよび記録媒体 - Google Patents

ネットワーク通信装置、ネットワーク通信装置の制御方法、ネットワーク通信装置の制御プログラムおよび記録媒体 Download PDF

Info

Publication number
JP4810339B2
JP4810339B2 JP2006192199A JP2006192199A JP4810339B2 JP 4810339 B2 JP4810339 B2 JP 4810339B2 JP 2006192199 A JP2006192199 A JP 2006192199A JP 2006192199 A JP2006192199 A JP 2006192199A JP 4810339 B2 JP4810339 B2 JP 4810339B2
Authority
JP
Japan
Prior art keywords
rss
data
request
image data
network communication
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP2006192199A
Other languages
English (en)
Other versions
JP2008021118A (ja
Inventor
聖彦 篠宮
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Ricoh Co Ltd
Original Assignee
Ricoh Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Ricoh Co Ltd filed Critical Ricoh Co Ltd
Priority to JP2006192199A priority Critical patent/JP4810339B2/ja
Publication of JP2008021118A publication Critical patent/JP2008021118A/ja
Application granted granted Critical
Publication of JP4810339B2 publication Critical patent/JP4810339B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Landscapes

  • Telephonic Communication Services (AREA)
  • Information Transfer Between Computers (AREA)
  • Facsimiles In General (AREA)
  • Facsimile Transmission Control (AREA)

Description

本発明は、ネットワーク通信装置が持つ情報をセマンティックＸＭＬにて他の機器に情報提供することの可能なネットワーク通信装置、ネットワーク通信装置の制御方法、ネットワーク通信装置の制御プログラムおよび記録媒体に関する。
従来より、各種の機器、特にプリンタ、ファクシミリ装置、複写機等の事務機器は、ＨＴＴＰプロトコルによりデータの送受信を行うＨＴＴＰ通信機能や、ＰＳＴＮに接続されファクシミリ伝送によるデータの送受信を行うファクス通信機能など、ネットワーク通信機能を備えるようになっている。また、機器内部にＷｅｂアクセス機構を備え、Ｗｅｂ技術を用いた、強化拡張された通信機能を備えているものがある。
このようなネットワーク通信装置の従来技術として、特許文献１〜３に開示された発明が公知である。特許文献１には、ＷＷＷサーバプログラムを搭載することにより、外部装置のＷＷＷブラウザによって操作することができるファクシミリ装置に関する技術が開示されている。
また特許文献２には、画像処理装置にＷｅｂサーバ機能を持たせ、画像データに関する情報のリストをＷｅｂページとして生成させることで、装置の状態をユーザに通知するためのソフトウェアの設計、操作などの労力を軽減する技術が開示されている。
さらに特許文献３には、ＬＡＮなどのネットワークに接続可能な各種のネットワーク装置自体又はその他の外部装置が保有する情報を相互利用することが可能な技術が開示されている。
特開２０００−０９２２６２号公報 特開２００２−００７０９５号公報 特開２００５−２０９０５６号公報
従来のネットワーク通信装置で機器の情報を取得する場合には、ブラウザ経由でユーザーが操作することによって行っていたが、ファイルの場所を知るためにはブラウザを立ち上げて見ないといけないという問題があった。そのため、人を介した操作でしかダウンロードが実現できないため自動化処理等には向いていなかった。また、クライントが多様化してきたときに、レスポンスするデータのフォーマットを通信装置側で自由に切り替えることができなかった。
また上述した従来技術では、ブラウザから通信装置の設定をしたり情報を取得する方法はあったが、セマンティックＸＭＬ（ＲＳＳ）にてファイル蓄積受信文書のダウンロードを行うための情報を出力する方法はなかった。また、機器（ＭＦＰ）のファクス蓄積受信文書の引き取り機能はあったが、これはWebImageMonitorなどを利用してブラウザからのユーザ操作によりファイルの引き取り操作を行う手順であった。さらに、機器がＲＳＳ情報を出力する発明もあるが、ダウンロード機能について詳述されている発明はなかった。
このような課題に鑑み、本発明は、クライアント端末からの要求に基づいて、ＨＴＭＬデータとＸＭＬデータ（ＲＳＳデータ）とを切り替えて返信するネットワーク通信装置、
ネットワーク通信装置の制御方法、ネットワーク通信装置の制御プログラムおよび記録媒体を提供することを目的としている。
上記の目的を達成するため、請求項１に記載の発明は、公衆回線網に接続されて画像データの送受信を行うＦＡＸ通信手段と、ネットワークに接続されてクライアント端末とのデータの送受信を行うネットワーク通信手段と、を備えたネットワーク通信装置であって、前記クライアント端末から受信したリクエストを解析する解析手段と、前記解析手段の解析結果に基づいて、前記クライアント端末から受信したリクエストがＨＴＭＬクライアントアプリケーションからのリクエストかＲＳＳクライアントアプリケーションからのリクエストかを振り分ける振り分け手段と、前記ＨＴＭＬクライアントアプリケーションからのリクエストに基づいて前記画像データに関するＨＴＭＬデータを生成するＨＴＭＬデータ生成手段と、前記ＲＳＳクライアントアプリケーションからのリクエストに基づいて前記画像データに関するＲＳＳデータを生成するＲＳＳデータ生成手段と、前記ＨＴＭＬデータまたは前記ＲＳＳデータを前記クライアント端末に返信する返信手段と、前記ＦＡＸ通信手段で受信した画像データを他装置に転送する手段と、を備え、前記ＲＳＳデータ生成手段は、前記画像データを他装置に転送した場合に、該画像データの転送先情報を前記ＲＳＳデータの添付ファイル情報に含めた前記ＲＳＳデータを、前記画像データの転送先のプロトコルごとに生成することを特徴とする。
請求項２に記載の発明は、公衆回線網に接続されて画像データの送受信を行うＦＡＸ通信手段と、ネットワークに接続されてクライアント端末とのデータの送受信を行うネットワーク通信手段と、を備えたネットワーク通信装置であって、前記クライアント端末から受信したリクエストを解析する解析手段と、前記解析手段の解析結果に基づいて、前記クライアント端末から受信したリクエストがＨＴＭＬクライアントアプリケーションからのリクエストかＲＳＳクライアントアプリケーションからのリクエストかを振り分ける振り分け手段と、前記ＨＴＭＬクライアントアプリケーションからのリクエストに基づいて前記画像データに関するＨＴＭＬデータを生成するＨＴＭＬデータ生成手段と、前記ＲＳＳクライアントアプリケーションからのリクエストに基づいて前記画像データに関するＲＳＳデータを生成するＲＳＳデータ生成手段と、前記ＨＴＭＬデータまたは前記ＲＳＳデータを前記クライアント端末に返信する返信手段と、前記ＦＡＸ通信手段で受信した画像データを他装置に転送する手段と、を備え、前記ＲＳＳデータ生成手段は、前記画像データを他装置に転送した場合に、該画像データの転送先情報を前記ＲＳＳデータの添付ファイル情報に含めた前記ＲＳＳデータを、前記ＲＳＳクライアントアプリケーションからのリクエストに含まれるＲＥＳＴインタフェースで指定される前記画像データの転送先のプロトコルについて生成することを特徴とする。
請求項３に記載の発明は、請求項１または２記載のネットワーク通信装置において、前記ＲＳＳデータ生成手段は、該ネットワーク通信装置の機能ごとに前記ＲＳＳデータを生成することを特徴とする。
請求項４に記載の発明は、請求項１から３のいずれか１項記載のネットワーク通信装置において、前記ＲＳＳデータ生成手段は、前記画像データの転送先情報を前記ＲＳＳデータのリンク情報に含めた前記ＲＳＳデータを生成することを特徴とする。
請求項５に記載の発明は、請求項１から４のいずれか１項記載のネットワーク通信装置において、前記ＲＳＳデータ生成手段は、前記画像データを閲覧可能なアプリケーションのアドレスを前記ＲＳＳデータのリンク情報または本文情報に含めた前記ＲＳＳデータを生成することを特徴とする。
請求項６に記載の発明は、公衆回線網に接続されて画像データの送受信を行うＦＡＸ通信工程と、ネットワークに接続されてクライアント端末とのデータの送受信を行うネットワーク通信工程と、を備えたネットワーク通信装置の制御方法であって、前記クライアント端末から受信したリクエストを解析する解析工程と、前記解析工程の解析結果に基づいて、前記クライアント端末から受信したリクエストがＨＴＭＬクライアントアプリケーションからのリクエストかＲＳＳクライアントアプリケーションからのリクエストかを振り分ける振り分け工程と、前記ＨＴＭＬクライアントアプリケーションからのリクエストに基づいて前記画像データに関するＨＴＭＬデータを生成するＨＴＭＬデータ生成工程と、前記ＲＳＳクライアントアプリケーションからのリクエストに基づいて前記画像データに関するＲＳＳデータを生成するＲＳＳデータ生成工程と、前記ＨＴＭＬデータまたは前記ＲＳＳデータを前記クライアント端末に返信する返信行程と、前記ＦＡＸ通信工程で受信した画像データを他装置に転送する転送工程と、を備え、前記ＲＳＳデータ生成工程は、前記画像データを他装置に転送した場合に、該画像データの転送先情報を前記ＲＳＳデータの添付ファイル情報に含めた前記ＲＳＳデータを、前記画像データの転送先のプロトコルごとに生成することを特徴とする。
請求項７に記載の発明は、公衆回線網に接続されて画像データの送受信を行うＦＡＸ通信工程と、ネットワークに接続されてクライアント端末とのデータの送受信を行うネットワーク通信工程と、を備えたネットワーク通信装置の制御方法であって、前記クライアント端末から受信したリクエストを解析する解析工程と、前記解析工程の解析結果に基づいて、前記クライアント端末から受信したリクエストがＨＴＭＬクライアントアプリケーションからのリクエストかＲＳＳクライアントアプリケーションからのリクエストかを振り分ける振り分け工程と、前記ＨＴＭＬクライアントアプリケーションからのリクエストに基づいて前記画像データに関するＨＴＭＬデータを生成するＨＴＭＬデータ生成工程と、前記ＲＳＳクライアントアプリケーションからのリクエストに基づいて前記画像データに関するＲＳＳデータを生成するＲＳＳデータ生成工程と、前記ＨＴＭＬデータまたは前記ＲＳＳデータを前記クライアント端末に返信する返信行程と、前記ＦＡＸ通信工程で受信した画像データを他装置に転送する転送工程と、を備え、前記ＲＳＳデータ生成工程は、前記画像データを他装置に転送した場合に、該画像データの転送先情報を前記ＲＳＳデータの添付ファイル情報に含めた前記ＲＳＳデータを、前記ＲＳＳクライアントアプリケーションからのリクエストに含まれるＲＥＳＴインタフェースで指定される前記画像データの転送先のプロトコルについて生成することを特徴とする。
請求項８に記載の発明は、請求項６または７記載のネットワーク通信装置の制御方法において、前記ＲＳＳデータ生成工程は、該ネットワーク通信装置の機能ごとに前記ＲＳＳデータを生成することを特徴とする。
請求項９に記載の発明は、請求項６から８のいずれか１項記載のネットワーク通信装置の制御方法において、前記ＲＳＳデータ生成工程は、前記画像データの転送先情報を前記ＲＳＳデータのリンク情報に含めた前記ＲＳＳデータを生成することを特徴とする。
請求項１０に記載の発明は、請求項６から９のいずれか１項記載のネットワーク通信装置の制御方法において、前記ＲＳＳデータ生成工程は、前記画像データを閲覧可能なアプリケーションのアドレスを前記ＲＳＳデータのリンク情報または本文情報に含めた前記ＲＳＳデータを生成することを特徴とする。
請求項１１に記載の発明は、請求項６から１０のいずれか１項記載のネットワーク通信装置の制御方法における各工程の処理をネットワーク通信装置に実行させるネットワーク通信装置の制御プログラムであることを特徴とする。
請求項１２に記載の発明は、請求項１１項記載のネットワーク通信装置の制御プログラムを記録したコンピュータ読み取り可能な記録媒体であることを特徴とする。
このように本発明のネットワーク通信装置、ネットワーク通信装置の制御方法、ネットワーク通信装置の制御プログラムおよび記録媒体によれば、ＲＳＳ形式でも従来のＨＴＭＬ形式でも情報を返信することができる。
以下に、本実施形態のネットワーク通信装置、ネットワーク通信装置の制御方法、ネットワーク通信装置の制御プログラムおよび記録媒体について図面を参照しながら詳細に説明する。なお本実施形態は以下に述べるものに限定されず、その趣旨を逸脱しない範囲において種々変更が可能である。
本実施形態では、標準ＸＭＬフォーマットであるＲＳＳ（RDF Site Summary／Rich Site Summary）形式であっても、従来のＨＴＭＬ形式であっても機器の情報を出力することができ、様々なクライアントツールに対応可能とすることを目的としている。
本実施形態においては、ローカルエリアネットワーク（ＬＡＮ）上でのデータのやりとりの機能と、公衆回線を介して行われるファクシミリ伝送手順によるファクシミリデータのやりとりの機能を備えると共に、ＬＡＮを介して受信した電子メールに含まれる画情報を公衆網の通信装置へ送信するネットワーク通信装置であり、図１に本実施形態にかかる
ネットワークシステムを示している。
図１に示すように、本実施形態のネットワーク通信装置を用いた通信システムは、複数のワークステーション装置ＷＳ１〜ＷＳｎと、ルータ装置ＲＴと、メールサーバ装置ＳＭと、ネットワーク通信装置ＦＸとが、ローカルエリアネットワーク（ＬＡＮ）を介して相互に接続可能な状態となっている。またＬＡＮは、ルータ装置ＲＴを介してインターネット等のネットワークへと接続され、図示しない他のＬＡＮ等に接続されているホスト装置との間で種々のデータのやり取りが可能である。
メールサーバ装置ＳＭは、ローカルエリアネットワーク（ＬＡＮ）に接続されているワークステーション装置ＷＳ１〜ＷＳｎを利用するユーザおよびネットワーク通信装置ＦＸに対して電子メールの収集、配信サービスを提供する。
また、ワークステーション装置ＷＳ１〜ＷＳｎには、ローカルエリアネットワーク（ＬＡＮ）を介して種々のデータのやりとりを行うアプリケーションソフトウェア（電子メールアクセスなど）やネットワーク通信装置ＦＸより受信した電子メールに含まれる画情報を処理するアプリケーションソフトウェア（ビューワーなど）など種々のプログラムが導入されていて、特定のユーザにより使用されるものである。なお特定のユーザとは、１人または複数人であってもよい。
また、ネットワーク通信装置ＦＸは、ローカルエリアネットワーク（ＬＡＮ）における電子メールの送受信機能と公衆電話交換網（ＰＳＴＮ）に接続し、この公衆網を伝送路として用いてグループ３（Ｇ３）ファクシミリ伝送手順による画情報伝送を行う伝送機能を備えている。
本実施形態において、ローカルエリアネットワーク（ＬＡＮ）に接続されている端末相互間でのデータのやりとりは、ＴＣＰ／ＩＰというトランスポートレイヤまでの伝送プロトコルと、それ以上の上位レイヤの通信プロトコルとの組み合わせが適用されて行われる。例えば、電子メールの送信では、上位レイヤの通信プロトコルとして、ＳＭＴＰ（Simple Mail Transport Protocol）という通信プロトコルが適用される。
本実施形態では、電子メールはメールサーバ装置ＳＭに一旦蓄積された後に配信される。例えば、ネットワーク通信装置ＦＸからワークステーション装置ＷＳ１のユーザへの電子メールは、メールサーバ装置ＳＭに一旦蓄積される。
一方、ワークステーション装置ＷＳ１〜ＷＳｎ及びネットワーク通信装置ＦＸは、適当な周期でメールサーバ装置ＳＭに対して、自端末のユーザ宛の電子メール受信の問い合わせを行い、ユーザ宛の電子メールがメールサーバ装置ＳＭに蓄積されているときは、メールサーバ装置ＳＭによりその電子メールを受信して、自端末ユーザにその旨を通知する。
この場合、ワークステーション装置ＷＳ１は、メールサーバ装置ＳＭに対して、自端末のユーザ宛の電子メール受信の問い合わせを行った場合に、自端末のユーザ宛の電子メールがメールサーバ装置ＳＭに蓄積されていることが通知されるので、その電子メールを受信してその旨をユーザに通知する。通知を受け取ったユーザは、その電子メールの内容を読み出して内容を確認する。
なおこの際の通信プロトコルとしては、ＰＯＰ（Post Office Protocol）などを適用することができる。
また、本実施形態では、ワークステーション装置ＷＳ１〜ＷＳｎからネットワーク通信装置ＦＸに対し、公衆網に接続された通信装置へ画情報の中継送信依頼を行うことができ
、その中継依頼画情報の送信には電子メールが適用される。なお、この場合のローカルエリアネットワーク（ＬＡＮ）は、インターネットに接続されているので、インターネットに接続されている他のワークステーション装置等のユーザも、このネットワーク通信装置ＦＸに対して画情報の中継送信依頼を行うことができる。
この電子メールは、ＭＩＭＥ（Multipurpose Internet Mail Extension）形式のものである。画情報は、Ｂａｓｅ６４符号化形式で符号化した後の情報がセットされる。
ここで、ＨＴＴＰとは、“Hyper Text Transfer Protocol”の略で、いわゆるＷＷＷ（World-Wide Web）を実現するためのプロトコルである。通常、ＴＣＰ上（ポート番号：８０）でやりとりされる。ＧＥＴやＰＯＳＴなどのコマンドにより、ブラウザがサーバに対して処理を指定し、そのレスポンスとして、ＨＴＭＬ（Hyper Text Markup Language）ファイルや画像ファイルなどがサーバから送られてくる。ＨＴＴＰには、プロトコルとしてのバージョンがあり、多くのブラウザは、まだ、１．０（ＲＦＣ１９４５）までにしか対応していない。なお最新のバージョンは、１．１（ＲＦＣ２６１６）である。１．１では、コマンドやレスポンス自体やフォーマットなどに、多くの拡張がなされている。ワークステーション装置にインストールされているブラウザソフトより閲覧することができる。
また、ＸＭＬ（eXtensible Markup Language）とは、Ｗ３Ｃ（ＷＷＷ技術の標準化団体）の勧告(Recommendation)で、ＳＧＭＬ（ＩＳＯ／ＩＥＣ ８８７９：１９８６）を簡略化してインターネット対応したものであり、ＨＴＭＬと違って任意のタグが使用可能である。またデータと処理（レイアウト（デザイン））の分離して記述できる点に特徴がある。
次に図２は、ネットワーク通信装置ＦＸの構成例を示す図である。
図２に示すように、ネットワーク通信装置ＦＸは、システム制御部１と、システムメモリ２と、パラメータメモリ３と、時計回路４と、スキャナ５と、プロッタ６と、操作表示部７と、符号化／復号化部８と、画像蓄積部９と、Ｇ３ＦＡＸモデム１０と、網制御部１１と、ＬＡＮ Ｉ／Ｆ１２とＬＡＮ伝送制御部１３とを備えている。
この図２において、システム制御部１は、このネットワーク通信装置ＦＸの各部の制御処理、およびファクシミリ伝送制御手順などの各種制御処理を行う。システムメモリ２は、システム制御部１が実行する制御処理プログラムおよび処理プログラムを実行するときに必要な各種データなどを記憶するとともに、システム制御部１のワークエリアを構成する。パラメータメモリ３は、本実施形態のネットワーク通信装置ＦＸに固有な各種の情報を記憶する。
また時計回路４は、現在時刻情報を出力する。スキャナ５は、所定の解像度で原稿画像を読み取る。プロッタ６は、所定の解像度で画像を記録出力する。操作表示部７は、本実施形態のネットワーク通信装置ＦＸを操作するためのもので、各種の操作キー、および各種の表示器からなる。符号化／復号化部８は、画信号を符号化圧縮するとともに、符号化圧縮された状態の画情報を多数記憶する。画像蓄積部９は、符号化圧縮された状態の画情報を多数記録する。グループ３ファクシミリモデム（Ｇ３ＦＡＸモデム）１０は、グループ３ファクシミリのモデム機能を実現する。網制御部１１は、本実施形態のネットワーク通信装置ＦＸを電話回線網（ＰＳＴＮ）に接続するためのものであり、自動発着信機能を備えている。
ローカルエリアネットワークインターフェース回路（ＬＡＮ Ｉ／Ｆ）１２は、本実施形態のネットワーク通信装置ＦＸをローカルエリアネットワーク（ＬＡＮ）に接続するためのものであり、ローカルエリアネットワーク（ＬＡＮ）伝送制御部１３は、ローカルエ
リアネットワーク（ＬＡＮ）を介して他のデータ端末装置との間で種々のデータをやりとりするための各種所定のプロトコルの通信制御処理（電子メール送受信処理など）を実行する。
これらのシステム制御部１、システムメモリ２、パラメータメモリ３、時計回路４、スキャナ５、プロッタ６、操作表示部７、符号化／復号化部８、画像蓄積部９、Ｇ３ＦＡＸモデム１０、網制御部１１、ＬＡＮ伝送制御部１３は、それぞれ内部バス１４に接続されており、これらの各要素間でのデータやりとりは主として内部バス１４を介して行われている。また、網制御部１１とＧ３ＦＡＸ１０との間のデータのやりとりは直接行われている。
ＦＡＸ蓄積受信文書などの文書情報は、ＲＳＳ（RDF Site Summary）フォーマット（ＸＭＬファイル）の形式で提供することができる。ＲＳＳデータの一例を図１３に示す。
ここで参考までに、ＲＳＳについてＵＮＩＸ（登録商標） ＵＳＥＲ ２００４年３月号より引用して説明する。
ＲＳＳはサイトの概要を記述し、配布するためのＸＭＬフォーマットである。ＸＭＬとは上述したように、文書の構造を簡単にマークアップしたテキストファイルのことである。ＸＭＬは人が直接読むものではなく、プログラムがそれを解釈することで、いろいろな形で応用されるデータ、すなわちメタデータである。また、ＲＳＳのフォーマットに従って記述された文書を、ＲＳＳ文書あるいはＲＳＳフィードなどという。ＲＳＳは、様々な企業や団体により仕様が標準化されている。
異なるサイトの新着情報やそのデータの書式が統一されていれば、プログラム作成者などのユーザは統一されたその決まりに従ってデータを解釈するだけでよい。このような場合に、ＸＭＬで記述することが一般的になっている。このような流れから、ＲＳＳ文書もＸＭＬ文書で記述されることが多い。ＲＳＳ文書を利用する代表的なアプリケーションとしては、複数のサイトのＲＳＳ文書を読み込んで新着情報を横断的に表示するＲＳＳリーダが挙げられる。これは、ＨＴＭＬやＣＳＳを解釈してＷｅｂサイトをレンダリングするＷｅｂブラウザのようなものである。
また、ＲＳＳについては、http://e-words.jp/w/RSS.htmlにも詳述されている。
このＲＳＳにはいくつかのバージョンが混在し、またその名称自体も数種類存在する。主なものを例示すると、RDF Site Summary、Rich Site Summary「1.0系列」、Real Simple Syndication「0.9-2.0系列」、などが挙げられる。また、ＲＳＳのサイト情報の要約と公開については、http://kanzaki.com/docs/sw/rss.htmlに詳述されている。
ＲＳＳのＵＲＬの指定方法は、例えば以下のように行う。なおここでは、リソースに適用するメソッドとして、“ｇｅｔ”の場合を用いて説明する。
http://hostname/web/guest/ja/webdocbox/faxDocListPage.cgi?xml=rss2.0
（１）通信プロトコル
次の２つのいずれかを指定する。ただし、機器の設定状態によっては指定されたプロトコルで通信できない場合もある。詳細はAcacia機能仕様書に記載されている。
・http：ＨＴＴＰ（Hypertext Transfer Protocol）のこと。
・http：ＨＴＴＰＳ（Hypertext Transfer Protocol Security）のこと。ＳＳＬによる経路の暗号化を行う。
（２）ユーザプロファイル
次の２つのいずれかを指定する。詳細は以下に記載されている。
・guest：ゲストモードのこと。個人認証を行わない設定の場合に使用する。
・entry：認証モードのこと。個人認証する設定の場合、または管理者としてログインする場合に使用する。
（３）言語
表示に用いる言語のこと。選択できる言語のみ指定可能であり、通常装置本体の操作部にて選択可能な言語に依存する。
（４）機能
各機能のパスのこと。例えば、蓄積文書はwebdocbox、通信履歴はwebfaxなどが挙げられる。
（５）ＲＳＳバージョン
ＲＳＳのバージョンを次のいずれかから指定する。なお、各機能でサポートしているバージョンについては以下に記載されている。
・rss1.0：RSS1.0
・rss0.91：RSS0.91
・rss2.0：RSS2.0
・atom：Atom
また、図２のＬＡＮ伝送制御部１３において、ＲＳＳ／ＨＴＭＬの切り替えに係る部分について、図２１を用いて説明する。
ＬＡＮ伝送制御部１３は、要求解析部１３１と、振り分け部１３２と、ＸＭＬ生成部１３３と、ＨＴＭＬ生成部１３４とを備えている。
要求解析部１３１は、クライアントからリクエストを解析する。振り分け部（ディスパッチャ）１３２は、解析後のリクエストを振り分ける。ＸＭＬ（ＲＳＳ）生成部１３３およびＨＴＭＬ生成部１３４は、実際のレスポンスデータをそれぞれ生成する。
クライアントから指定されたＵＲＬは要求解析部１３１で判断され、振り分け部（ディスパッチャ）１３２にてそれぞれ振り分けられる。そのリクエストがＲＳＳの場合にはＸＭＬ（ＲＳＳ）生成部１３３に振り分けられ、またリクエストがＨＴＭＬの場合にはＨＴＭＬ生成部に振り分けられる。
このように本実施形態によれば、標準ＸＭＬフォーマットであるＲＳＳ形式でも従来のＨＴＭＬ形式でも機器の情報を出力できるので、様々なクライアントツールに対応することができる。
また、本実施形態では、機器のそれぞれの機能ごとにＲＳＳフィード用のＵＲＬを生成することも可能である。図２２は、アプリケーション種別によるＲＳＳフィードのＵＲＬを模式的に示す図である。この図２２に示すように、例えばファイル名で分けることで、内容を絞った情報を出力することができる。
これによって、図２０にて説明する、転送先のプロトコル種別により取得可能な情報を選択するフローチャートと同様の処理にて、機能単位でのＵＲＬ生成を実施することができる。
図２０は、ＵＲＬを用いたリクエスト種別によるＲＳＳ情報レスポンスを示すフローチャートである。
まずクライアントからのリクエストを受け付けると、ＵＲＬの解析を行う（ステップＳ１０１）。そしてこのＵＲＬを見てどの機能のリクエストかを判断する。そして解析の結果、当該ＵＲＬがサポート対象のＵＲＬかを判定する（ステップＳ１０２）。ここでＵＲＬが未サポートの場合には（ステップＳ１０２／Ｎｏ）、エラーメッセージである「404 Not Found」のメッセージをクライアントへ返送する（ステップＳ１１０）。
ＵＲＬがサポート対象の場合には（ステップＳ１０２／Ｙｅｓ）、さらに当該ＵＲＬが全データ取得用のＵＲＬかを判断する（ステップＳ１０３）。全データ取得用のＵＲＬと判断された場合には（ステップＳ１０３／Ｙｅｓ）、全データを抽出した後（ステップＳ１１１）、レスポンス用のＸＭＬデータを生成するステップＳ１０８へと移行する。
一方、ＵＲＬが全データ取得用ではない場合には（ステップＳ１０３／Ｎｏ）、取得するプロトコルの種別を判別する（ステップＳ１０４）。なおここでのサポートＵＲＬにおけるプロトコルとしては、ＦＴＰ，ＳＭＢ，ＨＴＴＰの３種類がサポートされていると設定して説明する。
上記のステップＳ１０４にて判別されたプロトコルに応じて、各データが抽出される。すなわち、プロトコルがＦＴＰ（File Transfer Protocol）の場合にはＦＴＰデータが抽出され（ステップＳ１０５）、またＳＭＢ（Server Message Block）の場合にはＳＢＭデータが抽出され（ステップＳ１０６）、さらにＨＴＴＰの場合にはＨＴＴＰデータが抽出される（ステップＳ１０７）。
このようにして各プロトコル種別に応じたデータを抽出した後、レスポンス用のＸＭＬデータを生成して（ステップＳ１０８）、このレスポンスデータをクライアントへと送信する（ステップＳ１０９）。
なおサポートしているＵＲＬについては、例えば前述した図２２の例に沿って決められている。例えば、ファクス受信文書の情報のみならば、ＵＲＬがfaxDocListPag.rssなどとなる。また、全ての情報を返信するためのＵＲＬも用意することも可能である。
従来では、あらかじめ決められた内容を返答するだけだったので、細かいレスポンスデータの内容を指定することができなかった。しかし本実施形態によれば、機能単位で機器の情報を出力できるので、様々なクライアントツールに対応できるようになる。
ＲＳＳフォーマットのサンプルを図１３に示す。また、ここで使用している各要素の説明を図１４に示す。図１４は、ＲＳＳフィードの仕様を模式的に示す図である。
本実施形態では、ｌｉｎｋ要素ではなくｅｎｃｌｏｓｕｒｅ要素を用いてその機能を実現する。
図３は、ネットワーク通信装置（サーバ）とクライアントソフトウェア（ＲＳＳアグリゲータ）とのやりとりを示す図である。
図３に示すように、クライアント側はＨＴＴＰのＧＥＴ（またはＰＯＳＴ）にて情報取得のリクエストを要求する。これを受けてサーバ側では、レスポンスとしてＲＳＳファイル（ＸＭＬデータ）を返信する。このとき、クライアントソフトウェア上では、このＸＭＬデータが図５に示すように表示される。
ｌｉｎｋ要素に記述されたＵＲＬは、クライアント側でクリックすることなどにより表示される。この表示例として、例えば図６に示すようにＨＴＭＬページが表示される。この動作は、図３中のリンクのクリックに相当する。最初にリンク先情報を取得して、その後にリンクをクリックすることによって、新たなＨＴＴＰリクエストを発生させて情報を取得する。
また図４は、ｌｉｎｋ要素ではなくｅｎｃｌｏｓｕｒｅ要素を用いた場合のクライアントとサーバとのやり取りを示すシーケンス図である。
ｅｎｃｌｏｓｕｒｅ要素にはファイルのＵＲＬが記載されるので、クライアントソフト（ＲＳＳアグリゲータなど）が自動的にＵＲＬを解釈してリクエストを送信する。また、
そのＵＲＬがプロトコルと異なり実際にファイルを引き取るような場合には、そのプロトコルを利用してダウンロードを行う。
図１５にｅｎｃｌｏｓｕｒｅ要素とｉｔｅｍ要素中のｌｉｎｋ要素の使い方を示す。図１５は、リンク情報／ファイル添付情報の使い分けを示す図である。
このように本実施形態では、ファクス受信文書をダウンロードするための情報を標準ＸＭＬフォーマットであるＲＳＳ形式にマッピングしているので、人が介在しなくてもクライアントツールが自動的にファイルの保存場所を知ることができ、自動的にダウンロードすることができる。
図７は、ダウンロード情報のＲＳＳフィード（ｅｎｃｌｏｓｕｒｅ要素）を設定する動作を示すフローチャートである。
メモリ転送を行った場合には、通信履歴情報にメモリ転送先のあて先を記憶する。なおこのあて先の記憶場所としては、図２中のパラメータメモリ３が挙げられる。
まず、クライアントよりファクス蓄積受信文書の取得のリクエストがあるか、すなわちＲＳＳリクエストがあるかを確認する（ステップＳ２０１）。ＲＳＳリクエストがあった場合には（ステップＳ２０１／Ｙｅｓ）、フィード情報の生成処理を行う。また、リクエストがない場合には（ステップＳ２０１／Ｎｏ）、リクエストが確認できるまで待機する。
次に、クライアント側にＨＤＤなどのストレージがあるかを確認する（ステップＳ２０２）。ここでＨＤＤがない場合には（ステップＳ２０２／Ｎｏ）、パラメータメモリ３から通信履歴情報を取得し、当該履歴情報中よりメモリ転送がされていたかを確認する（ステップＳ２０３）。この際、履歴情報中のプロパティ情報からメモリ転送先のあて先（プロトコルやアドレスを取得する（ステップＳ２０４）。
次に、そのメモリ転送先がフォルダあて先か否かを確認する（ステップＳ２０５）。転送先がフォルダあて先の場合には（ステップＳ２０５／Ｙｅｓ）、ファイルダウンロード用のＵＲＬを生成する（ステップＳ２０６）。例えば、ＦＴＰの場合は、ftp://hostname/web/fax20060120.tifのようになる。生成したＵＲＬ情報は、ＲＳＳフォーマットのサンプル図である図１３中のｅｎｃｌｏｓｕｒｅ要素にセットされる（ステップＳ２０７）。
また、ｉｔｅｍのｌｉｎｋ要素については、機器のファクス蓄積文書のＷｅｂＰａｇｅをブラウザから閲覧するためのＵＲＬを生成して（ステップＳ２０８）、生成したＵＲＬをｌｉｎｋ要素にセットする（ステップＳ２０９）。また、その他必要なＲＳＳフィードのデータをセットしてレスポンス用のＸＭＬデータを作成し（ステップＳ２１０）、クライアントに送信する（ステップＳ２１１）。
なお、前述のステップＳ２０２にてＨＤＤがある場合や（ステップＳ２０２／Ｎｏ）、前述のステップＳ２０３にてメモリ転送を行っていない場合（ステップＳ２０３／Ｎｏ）、また前述のステップＳ２０５にてメモリ転送のあて先がフォルダではない場合（ステップＳ２０５／Ｎｏ）は、ｅｎｃｌｏｓｕｒｅ要素には何もセットしないで、ｌｉｎｋ要素に対しても通常の処理を行う。
ただし、フォルダあて先に例えばパスワードが付与されているなどアクセス制限がある場合には、ｅｎｃｌｏｓｕｒｅ要素には何もセットしないことも可能である。また、その際には、ｅｎｃｌｏｓｕｒｅ要素に何もセットしないことを示すガイダンス用ＷｅｂＰａｇｅのＵＲＬをｌｉｎｋ要素に入れることも可能である。
従来のネットワーク通信装置では、ＨＤＤ等の内部ストレージがない場合には、受信したファクス受信文書を保持しておくことができなかった。そのため、ブラウザ経由でも受信文書をダウンロードできないという問題があった。しかし、本実施形態によれば、受信したファクス画像をメモリ転送機能を使って、他のＰＣ等に転送することにより、その転送先のアドレス（ＵＲＬ）を標準ＸＭＬフォーマットであるＲＳＳ形式の添付ファイル情報にファクス蓄積受信文書情報を出力しているので、ＨＤＤなどのストレージのない機器でもクライアントツールが自動的にファイルをダウンロードできる。
図８は、ダウンロード情報のＲＳＳフィード（ｌｉｎｋ要素）を設定する動作を示すフローチャートである。
メモリ転送を行った場合には、通信履歴情報にメモリ転送先のあて先を記憶する。なおこのあて先の記憶場所としては、図２中のパラメータメモリ３が挙げられる。
まず、クライアントよりファクス蓄積受信文書の取得のリクエストがあるか、すなわちＲＳＳリクエストがあるかを確認する（ステップＳ３０１）。ＲＳＳリクエストがあった場合には（ステップＳ３０１／Ｙｅｓ）、フィード情報の生成処理を行う。また、リクエストがない場合には（ステップＳ３０１／Ｎｏ）、リクエストが確認できるまで待機する。
次に、クライアント側にＨＤＤなどのストレージがあるかを確認する（ステップＳ３０２）。ここでＨＤＤがない場合には（ステップＳ３０２／Ｎｏ）、パラメータメモリ３から通信履歴情報を取得し、当該履歴情報中よりメモリ転送がされていたかを確認する（ステップＳ３０３）。この際、履歴情報中のプロパティ情報からメモリ転送先のあて先（プロトコルやアドレスを取得する（ステップＳ３０４）。
次に、そのメモリ転送先がフォルダあて先か否かを確認する（ステップＳ３０５）。転送先がフォルダあて先の場合には（ステップＳ３０５／Ｙｅｓ）、ファイルダウンロード用のＵＲＬを生成する（ステップＳ３０６）。例えば、ＦＴＰの場合は、ftp://hostname/web/fax20060120.tifのようになる。生成したＵＲＬ情報は、ＲＳＳフォーマットのサンプル図である図１３中のｌｉｎｋ要素にセットされる（ステップＳ３０７）。また、その他必要なＲＳＳフィードのデータをセットしてレスポンス用のＸＭＬデータを作成し（ステップＳ３０８）、クライアントに送信する（ステップＳ３０９）。
なお、前述のステップＳ３０２にてＨＤＤがある場合や（ステップＳ３０２／Ｎｏ）、前述のステップＳ３０３にてメモリ転送を行っていない場合（ステップＳ３０３／Ｎｏ）、また前述のステップＳ３０５にてメモリ転送のあて先がフォルダではない場合（ステップＳ３０５／Ｎｏ）は、機器のファクス蓄積文書のＷｅｂＰａｇｅをブラウザから閲覧するためのＵＲＬを生成して（ステップＳ３１０）、ｌｉｎｋ要素に対しても通常の処理を行う。
ただし、フォルダあて先に例えばパスワードが付与されているなどアクセス制限がある場合には、ｌｉｎｋ要素には何もセットしないことも可能である。また、その際には、ｌｉｎｋ要素に何もセットしないことを示すガイダンス用ＷｅｂＰａｇｅのＵＲＬをｉｔｅｍ要素に入れることも可能である。
従来、メモリ転送した宛先にアクセスできない場合（例えば、相手先に届くまでに時間がかかる、アクセス権がないなど）は、自動ダウンロードができずにエラーとなる可能性があるという問題があった。また、添付ファイル情報を使って自動ダウンロードさせるには、専用のクライアントが必要になるという問題があった。しかし本実施形態によれば、受信したファクス画像をメモリ転送機能を使って、他のＰＣ等に転送した際の転送先のア
ドレス（ＵＲＬ）を標準XMLフォーマットであるＲＳＳ形式の添付ファイル情報ではなくて、リンク情報にだけ入れるので、ユーザ操作で引き取りをすることができ、また汎用的なＲＳＳリーダでもダウンロードすることができるので、ダウンロード用としての専用クライアントが必要なくなる。
図９は、ダウンロード情報のＲＳＳフィード（ａｎｃｌｏｓｕｒｅ／ｌｉｎｋ要素）を設定する動作を示すフローチャートである。
メモリ転送を行った場合には、通信履歴情報にメモリ転送先のあて先を記憶する。なおこのあて先の記憶場所としては、パラメータメモリ３が挙げられる。
まず、クライアントよりファクス蓄積受信文書の取得のリクエストがあるか、すなわちＲＳＳリクエストがあるかを確認する（ステップＳ４０１）。ＲＳＳリクエストがあった場合には（ステップＳ４０１／Ｙｅｓ）、フィード情報の生成処理を行う。また、リクエストがない場合には（ステップＳ４０１／Ｎｏ）、リクエストが確認できるまで待機する。
次に、クライアント側にＨＤＤなどのストレージがあるかを確認する（ステップＳ４０２）。ここでＨＤＤがない場合には（ステップＳ４０２／Ｎｏ）、パラメータメモリ３から通信履歴情報を取得し、当該履歴情報中よりメモリ転送がされていたかを確認する（ステップＳ４０３）。この際、履歴情報中のプロパティ情報からメモリ転送先のあて先（プロトコルやアドレスを取得する（ステップＳ４０４）。
次に、そのメモリ転送先がフォルダあて先か否かを確認する（ステップＳ４０５）。転送先がフォルダあて先の場合には（ステップＳ４０５／Ｙｅｓ）、ファイルダウンロード用のＵＲＬを生成する（ステップＳ４０６）。例えば、ＦＴＰの場合は、ftp://hostname/web/fax20060120.tifのようになる。生成したＵＲＬ情報は、ＲＳＳフォーマットのサンプル図である図１３中のｅｎｃｌｏｓｕｒｅ要素にセットされ（ステップＳ４０７）、さらにｉｔｅｍのｌｉｎｋ要素にもセットされる（ステップＳ４０８）。このときセットされる値は、ｅｎｃｌｏｓｕｒｅ要素とｌｉｎｋ要素とが同じ値にセットされる。さらに、その他必要なＲＳＳフィードのデータをセットしてレスポンス用のＸＭＬデータを作成し（ステップＳ４０９）、クライアントに送信する（ステップＳ４１０）。
なお、前述のステップＳ４０２にてＨＤＤがある場合や（ステップＳ４０２／Ｎｏ）、前述のステップＳ４０３にてメモリ転送を行っていない場合（ステップＳ４０３／Ｎｏ）、また前述のステップＳ４０５にてメモリ転送のあて先がフォルダではない場合（ステップＳ４０５／Ｎｏ）は、ｅｎｃｌｏｓｕｒｅ要素には何もセットしない。また、ｌｉｎｋ要素に対しては、機器のファクス蓄積文書のＷｅｂＰａｇｅをブラウザから閲覧するためのＵＲＬを生成して（ステップＳ４１１）、生成したＵＲＬをｌｉｎｋ要素にセットする（ステップＳ４１２）。
ただし、フォルダあて先に例えばパスワードが付与されているなどアクセス制限がある場合には、ｅｎｃｌｏｓｕｒｅ要素には何もセットしないことも可能である。また、その際には、ｅｎｃｌｏｓｕｒｅ要素に何もセットしないことを示すガイダンス用ＷｅｂＰａｇｅのＵＲＬをｌｉｎｋ要素に入れることも可能である。
このように、従来ではダウンロードされるかどうかが、クライアントツールの仕様に左右される可能性があるという問題があったが、本実施形態によれば、受信したファクス画像をメモリ転送機能を使って、他のＰＣ等に転送した際の転送先のアドレス（ＵＲＬ）を標準ＸＭＬフォーマットであるＲＳＳ形式の添付ファイル情報とリンク情報の両方に入れるので、ダウンロードする方法を複数、提供することができる。
また本実施形態では、図１１に示すように、メモリ転送を行ったプロトコル別にＲＳＳフィード用のＵＲＬを生成することも可能である。
図１１は、プロトコル種別によるＲＳＳフィードのＵＲＬを模式的に示す図である。この図１１に示すように、例えばファイル名で分けることで、内容を絞った情報を出力することができる。
これにより、前述の図２０にて説明した、転送先のプロトコル種別により取得可能な情報を選択するフローチャートと同様の処理にて、機能単位でのＵＲＬ生成を実施することができる。図２０のフローチャートに示すように、クライアントからのリクエストが合った場合に、ＵＲＬを参照してどの種別のリクエストかを決定する。このときサポートしているＵＲＬは、図１１に示す例に沿って決められている。例えば、ＦＴＰ情報のみならば、ＵＲＬがfaxDocListPag.rssなどとなる。また、全ての情報を返信するためのＵＲＬも用意する。
従来では、メモリ転送した宛先が様々なプロトコルの場合には、クライアント側がダウンロードする際にまとめて行うことができずに、その都度、通信プロトコルを切り替えないといけないという問題があった。しかし本実施形態によれば、受信したファクス画像をメモリ転送機能を使って、他のＰＣ等に転送した際の転送先のアドレス（ＵＲＬ）を、プロトコル別に標準ＸＭＬフォーマットであるＲＳＳ形式にまとめてフィードを生成するため、種別ごとの情報が簡単に入手でき、クライアント側の不可を減らすことができる。
また図１２は、リクエスト種別によるＲＳＳフィードのＵＲＬを模式的に示す図である。この図１２に示すように、例えばＧＥＴのパラメータ（ＲＥＳＴ（Representational State Transfer） Ｉ／Ｆ）で指定することで、内容を絞った情報を出力することができる。
図１０は、ＲＥＳＴ Ｉ／Ｆを用いたリクエスト種別によるＲＳＳ情報レスポンスを示すフローチャートである。
まずクライアントからのリクエストを受け付けると、ＵＲＬの解析を行う（ステップＳ４０１）。このＵＲＬを見て、ＧＥＴの引数があるかを確認する（ステップＳ４０２）。ＵＲＬ中にＧＥＴ引数がある場合には（ステップＳ４０２／Ｙｅｓ）、当該ＧＥＴ引数を見てパラメータの解析を行い、どの種別のリクエストかを判断する（ステップＳ４０３）。
このようにしてＧＥＴのパラメータを解析した後、当該ＵＲＬがサポート対象のプロトコルかを判定する（ステップＳ４０４）。ここでＵＲＬ（パラメータ）が未サポートの場合には（ステップＳ４０４／Ｎｏ）、空データを作成して（ステップＳ４１１）クライアントへ返送する。なお引数を省略した場合にはすべての値を返す。
ＵＲＬがサポート対象の場合には（ステップＳ４０２／Ｙｅｓ）、取得するプロトコルの種別を判別する（ステップＳ４０５）。なおここでのサポートＵＲＬにおけるプロトコルとしては、ＦＴＰ，ＳＭＢ，ＨＴＴＰの３種類がサポートされていると設定して説明する。そして、このステップＳ４０５にて判別されたプロトコルに応じて、各データが抽出される。すなわち、プロトコルがＦＴＰ（File Transfer Protocol）の場合にはＦＴＰデータが抽出され（ステップＳ４０６）、またＳＭＢ（Server Message Block）の場合にはＳＢＭデータが抽出され（ステップＳ４０７）、さらにＨＴＴＰの場合にはＨＴＴＰデータが抽出される（ステップＳ４０８）。
このようにして各プロトコル種別に応じたデータを抽出した後、レスポンス用のＸＭＬデータを生成して（ステップＳ４０９）、このレスポンスデータをクライアントへと送信する（ステップＳ４１０）。
なおサポートしているＵＲＬについては、例えば前述した図１２の例に沿って決められている。例えば、ＦＴＰ情報のみならば、ＵＲＬがfaxDocListPag.rssなどとなる。また、全ての情報を返信するためのＵＲＬも用意する。
従来では、メモリ転送した宛先が様々なプロトコルの場合には、種別ごとにＲＳＳのＵＲＬが分かれてしまい管理が大変であるという問題があった。しかし本実施形態によれば、受信したファクス画像をメモリ転送機能を使って、他のＰＣ等に転送した際の転送先のアドレス（ＵＲＬ）を、プロトコル別に標準ＸＭＬフォーマットで取得したい場合に、ＲＥＳＴ Ｉ／Ｆを用いて絞り込みやフィルタリングすることにより、ＲＳＳフィードのＵＲＬを１つで済ませることができる。
また図１８は、ダウンロード情報のＲＳＳフィードへの設定を、操作部（ＳＷ）に係る情報によって判定する場合を示すフローチャートである。
ファクス受信時などにメモリ転送をした場合は、通信履歴情報に転送先のあて先を記憶する。記憶場所としては、パラメータメモリ３が挙げられる。また操作部にて設定したＳＷ情報も、このパラメータメモリ３に保存される。リンク情報（ｌｉｎｋ要素）と添付ファイル情報（ｅｎｃｌｏｓｕｒｅ要素）とのうちどちらを載せるかを選択するＳＷの設定は、機器の操作パネルやＷｅｂブラウザなどから設定することができる。
まず、クライアントからＲＳＳリクエストがあると、ファクス通信履歴情報をパラメータメモリ３から取得したときに、メモリ転送先にフォルダアドレスがあるかを確認する（ステップＳ６０１）。これは、履歴情報の取得時にメモリ転送がされていた場合に、履歴情報のプロパティ情報からメモリの転送先のあて先（プロトコルやアドレス）を取得することで達成できる。
ここで、あて先がファイル転送先である場合、すなわち転送先にフォルダアドレスが存在する場合には（ステップＳ６０１／Ｙｅｓ）、ファイルダウンロード用のＵＲＬを生成する（ステップＳ６０２）。生成されるＵＲＬは、例えばＦＴＰの場合、ftp://hostname/web/fax20060120.tifのようになる。
次に、パラメータメモリ３から操作部であるＳＷ情報を取得する（ステップＳ６０３）。そして取得したＳＷの値がｌｉｎｋ要素に出力するよう設定されているか否かを確認する（ステップＳ６０４）。ＳＷの値がｌｉｎｋ要素に設定するようになっていれば（ステップＳ６０４／Ｙｅｓ）、ｉｔｅｍのｌｉｎｋ要素にファイルダウンロード用のＵＲＬをセットする（ステップＳ６０５）。このとき、ｅｎｃｌｏｓｕｒｅ要素には何もセットしない。
一方、ＳＷの値をｌｉｎｋ要素に出力しない場合、すなわちＳＷの値がｅｎｃｌｏｓｕｒｅ要素に設定するようになっていれば（ステップＳ６０４／Ｎｏ）、ｅｎｃｌｏｓｕｒｅ要素にファイルダウンロード用のＵＲＬをセットする（ステップＳ６０６）。そして、ｌｉｎｋ要素に対して機器のファクス蓄積受信文書のＷｅｂＰａｇｅをブラウザから閲覧するためのＵＲＬの生成（ステップＳ６０７）、および生成したＵＲＬのセットを行う（ステップＳ６０８）。このセットは、例えば図１３に示すようなｅｎｃｌｏｓｕｒｅ要素、またはｉｔｅｍのｌｉｎｋ要素にその値がセットされる。
そして、その他の必要なＲＳＳフィードのデータをセットし、レスポンス用のＸＭＬデータを生成して（ステップＳ６０９）、このレスポンスデータをクライアントへと送信する（ステップＳ６１０）。
なお、メモリ転送あて先がフォルダ転送ではない場合、すなわちメモリ転送先にフォルダアドレスがない場合には（ステップＳ６０１／Ｎｏ）、ｅｎｃｌｏｓｕｒｅ要素には何もセットしないで、ｌｉｎｋ要素に対して機器のファクス蓄積受信文書のＷｅｂＰａｇｅをブラウザから閲覧するためのＵＲＬを生成するステップＳ６０７へと移行する。
ただし、フォルダあて先に例えばパスワードが付与されているなどアクセス制限がある場合には、ｅｎｃｌｏｓｕｒｅ要素には何もセットしないことも可能である。また、その際には、ｅｎｃｌｏｓｕｒｅ要素に何もセットしないことを示すガイダンス用ＷｅｂＰａｇｅのＵＲＬをｌｉｎｋ要素に入れることも可能である。
従来では、メモリ転送を行った場合には、転送先あて先をＲＳＳフォーマットのリンク情報と添付ファイル情報の両方に含めて返信するが、どちらに出力するのか選択することができないという問題があった。しかし本実施形態によれば、受信したファクス画像をメモリ転送機能を使って、他のＰＣ等に転送した際の転送先のアドレス（ＵＲＬ）を標準ＸＭＬフォーマットのＲＳＳ形式で配信する場合に添付ファイル情報とリンク情報のどちらに情報を入れるのか選択できるので、クライアントの仕様に合わせてユーザの自由選択度が増し、利便性が向上する。
また本実施形態では、標準ＸＭＬフォーマットであるＲＳＳ形式でファクス蓄積受信文書情報を出力すると同時に、当該情報を閲覧するためのビューワーソフトの情報を含めることができる。
図１９は、ダウンロードファイルを閲覧するためのビューワーソフトの所在を通知する動作を示すフローチャートである。すなわち、履歴情報のプロパティ情報から、メモリ転送先のあて先に対して送信したファイルのファイルタイプを取得する。ビューワーソフトをサポートしているファイルタイプの場合は、図１７に示す表に対応したビューワーソフトの所在を示すＵＲＬを生成することになる。この図１７に示すようなテーブルデータは、パラメータメモリ３に保存されている。なおこの設定は、操作部（ＳＷ）など機器のパネルやＷｅｂブラウザから設定可能である。
まず、ダウンロードしたファイルの属性情報を取得する（ステップＳ７０１）。次に、取得した属性情報から、このファイルがビューワーソフトをサポートしているファイルタイプ（種別）かを確認する（ステップＳ７０２）。サポートしているファイルタイプの場合には（ステップＳ７０２／Ｙｅｓ）、そのファイルタイプを判別する（ステップＳ７０３）。
ここで、判別されたファイルタイプに応じて、対応するビューワーソフトの所在を示すＵＲＬの生成が行われる。すなわち、ファイルの種別がＰＤＦの場合にはＰＤＦ用のビューワーソフトのダウンロード用ＵＲＬが生成され（ステップＳ７０４）、またＴＩＦＦの場合にはＴＩＦＦ用のビューワーソフトのダウンロード用ＵＲＬが生成され（ステップＳ７０５）、さらにＪＰＥＧの場合にはＪＰＥＧ用のビューワーソフトのダウンロード用ＵＲＬが生成される（ステップＳ７０６）。
このようにして生成されたビューワーソフトの所在を示すＵＲＬは、図１６に示すようなｌｉｎｋ要素またはｅｎｃｌｏｓｕｒｅ要素に設定する（ステップＳ７０７）。最後にレスポンスデータを送信する（ステップＳ７０８）。なお、サポートしていないファイル
タイプの場合には（ステップＳ７０２／Ｎｏ）、何も値をセットしない。
従来では、ファクス受信文書をダウンロードする場合には、ブラウザ経由でユーザが操作することによって行っていたが、ファイルを開くためのビューワーソフトは、自分で探してインストールをしないといけないという問題があった。そのため、未知のファイル形式の場合には、ファイルをダウンロードしても開いて中身を見ることができなかった。しかし本実施形態によれば、標準ＸＭＬフォーマットであるＲＳＳ形式でファクス蓄積受信文書情報を出力すると同時に閲覧するためのビューワーソフトの情報を含めるので、ユーザがダウンロードしたファイルが開けるようになる。
本実施形態のネットワーク通信装置、ネットワーク通信装置の制御方法、ネットワーク通信装置の制御プログラムおよび記録媒体は、インターネット通信装置にも応用が可能である。
本実施形態のネットワーク通信装置を用いた通信システムの一例を示す図である。 本実施形態のネットワーク通信装置ＦＸの構成を示すブロック図である。 ｌｉｎｋ要素を用いた場合のネットワーク通信装置とクライアントソフトウェアとのやりとりを示す図である。 ｅｎｃｌｏｓｕｒｅ要素を用いた場合のネットワーク通信装置とクライアントソフトウェアとのやりとりを示す図である。 ＸＭＬデータのＲＳＳアグリゲータでの表示例を示す図である。 ＨＴＭＬデータのＲＳＳアグリゲータでの表示例を示す図である。 ダウンロード情報のＲＳＳフィード（ｅｎｃｌｏｓｕｒｅ要素）を設定する動作を示すフローチャートである。 ダウンロード情報のＲＳＳフィード（ｌｉｎｋ要素）を設定する動作を示すフローチャートである。 ダウンロード情報のＲＳＳフィード（ａｎｃｌｏｓｕｒｅ／ｌｉｎｋ要素）を設定する動作を示すフローチャートである。 ＲＥＳＴ Ｉ／Ｆを用いたリクエスト種別によるＲＳＳ情報レスポンスを示すフローチャートである。 プロトコル種別によるＲＳＳフィードのＵＲＬを模式的に示す図である。 リクエスト種別によるＲＳＳフィードのＵＲＬ（ＲＥＳＴ Ｉ／Ｆ）を模式的に示す図である。 ＲＳＳフォーマットのサンプル図である。 ＲＳＳフィードの仕様を示す図である。 リンク情報とファイル添付情報との使い方を示す図である。 ビューワー情報の指定方法を示すサンプル図である。 ファイル種別に対応したビューワーの一例を示す図である。 ダウンロード情報のＲＳＳフィードへの設定を、操作部（ＳＷ）に係る情報によって判定する場合を示すフローチャートである。 ダウンロードファイルを閲覧するためのビューワーソフトの所在を通知する動作を示すフローチャートである。 ダウンロード情報のＲＳＳフィードへの設定を、リクエスト種別によって判定する場合を示すフローチャートである。 ＲＳＳ／ＨＴＭＬの切り替えに係る構成を模式的に示すブロック図である。 アプリケーション種別によるＲＳＳフィードのＵＲＬを模式的に示す図である。
符号の説明
１ システム制御部
２ システムメモリ
３ パラメータメモリ
４ 時計回路
５ スキャナ
６ プロッタ
７ 操作表示部
８ 符号化／復号化部
９ 画像蓄積部
１０ Ｇ３ＦＡＸモデム
１１ 網制御部
１２ ＬＡＮ Ｉ／Ｆ
１３ ＬＡＮ伝送制御部
１４ バス

Claims (12)

  1. 公衆回線網に接続されて画像データの送受信を行うＦＡＸ通信手段と、ネットワークに接続されてクライアント端末とのデータの送受信を行うネットワーク通信手段と、を備えたネットワーク通信装置であって、
    前記クライアント端末から受信したリクエストを解析する解析手段と、
    前記解析手段の解析結果に基づいて、前記クライアント端末から受信したリクエストがＨＴＭＬクライアントアプリケーションからのリクエストかＲＳＳクライアントアプリケーションからのリクエストかを振り分ける振り分け手段と、
    前記ＨＴＭＬクライアントアプリケーションからのリクエストに基づいて前記画像データに関するＨＴＭＬデータを生成するＨＴＭＬデータ生成手段と、
    前記ＲＳＳクライアントアプリケーションからのリクエストに基づいて前記画像データに関するＲＳＳデータを生成するＲＳＳデータ生成手段と、
    前記ＨＴＭＬデータまたは前記ＲＳＳデータを前記クライアント端末に返信する返信手段と、
    前記ＦＡＸ通信手段で受信した画像データを他装置に転送する手段と、を備え、
    前記ＲＳＳデータ生成手段は、前記画像データを他装置に転送した場合に、該画像データの転送先情報を前記ＲＳＳデータの添付ファイル情報に含めた前記ＲＳＳデータを、前記画像データの転送先のプロトコルごとに生成することを特徴とするネットワーク通信装置。
  2. 公衆回線網に接続されて画像データの送受信を行うＦＡＸ通信手段と、ネットワークに接続されてクライアント端末とのデータの送受信を行うネットワーク通信手段と、を備えたネットワーク通信装置であって、
    前記クライアント端末から受信したリクエストを解析する解析手段と、
    前記解析手段の解析結果に基づいて、前記クライアント端末から受信したリクエストがＨＴＭＬクライアントアプリケーションからのリクエストかＲＳＳクライアントアプリケーションからのリクエストかを振り分ける振り分け手段と、
    前記ＨＴＭＬクライアントアプリケーションからのリクエストに基づいて前記画像データに関するＨＴＭＬデータを生成するＨＴＭＬデータ生成手段と、
    前記ＲＳＳクライアントアプリケーションからのリクエストに基づいて前記画像データに関するＲＳＳデータを生成するＲＳＳデータ生成手段と、
    前記ＨＴＭＬデータまたは前記ＲＳＳデータを前記クライアント端末に返信する返信手段と、
    前記ＦＡＸ通信手段で受信した画像データを他装置に転送する手段と、を備え、
    前記ＲＳＳデータ生成手段は、前記画像データを他装置に転送した場合に、該画像データの転送先情報を前記ＲＳＳデータの添付ファイル情報に含めた前記ＲＳＳデータを、前記ＲＳＳクライアントアプリケーションからのリクエストに含まれるＲＥＳＴインタフェースで指定される前記画像データの転送先のプロトコルについて生成することを特徴とするネットワーク通信装置。
  3. 前記ＲＳＳデータ生成手段は、該ネットワーク通信装置の機能ごとに前記ＲＳＳデータを生成することを特徴とする請求項１または２記載のネットワーク通信装置。
  4. 前記ＲＳＳデータ生成手段は、前記画像データの転送先情報を前記ＲＳＳデータのリンク情報に含めた前記ＲＳＳデータを生成することを特徴とする請求項１から３のいずれか１項記載のネットワーク通信装置。
  5. 前記ＲＳＳデータ生成手段は、前記画像データを閲覧可能なアプリケーションのアドレスを前記ＲＳＳデータのリンク情報または本文情報に含めた前記ＲＳＳデータを生成することを特徴とする請求項１から４のいずれか１項記載のネットワーク通信装置。
  6. 公衆回線網に接続されて画像データの送受信を行うＦＡＸ通信工程と、ネットワークに接続されてクライアント端末とのデータの送受信を行うネットワーク通信工程と、を備えたネットワーク通信装置の制御方法であって、
    前記クライアント端末から受信したリクエストを解析する解析工程と、
    前記解析工程の解析結果に基づいて、前記クライアント端末から受信したリクエストがＨＴＭＬクライアントアプリケーションからのリクエストかＲＳＳクライアントアプリケーションからのリクエストかを振り分ける振り分け工程と、
    前記ＨＴＭＬクライアントアプリケーションからのリクエストに基づいて前記画像データに関するＨＴＭＬデータを生成するＨＴＭＬデータ生成工程と、
    前記ＲＳＳクライアントアプリケーションからのリクエストに基づいて前記画像データに関するＲＳＳデータを生成するＲＳＳデータ生成工程と、
    前記ＨＴＭＬデータまたは前記ＲＳＳデータを前記クライアント端末に返信する返信行程と、
    前記ＦＡＸ通信工程で受信した画像データを他装置に転送する転送工程と、を備え、
    前記ＲＳＳデータ生成工程は、前記画像データを他装置に転送した場合に、該画像データの転送先情報を前記ＲＳＳデータの添付ファイル情報に含めた前記ＲＳＳデータを、前記画像データの転送先のプロトコルごとに生成することを特徴とするネットワーク通信装置の制御方法。
  7. 公衆回線網に接続されて画像データの送受信を行うＦＡＸ通信工程と、ネットワークに接続されてクライアント端末とのデータの送受信を行うネットワーク通信工程と、を備えたネットワーク通信装置の制御方法であって、
    前記クライアント端末から受信したリクエストを解析する解析工程と、
    前記解析工程の解析結果に基づいて、前記クライアント端末から受信したリクエストがＨＴＭＬクライアントアプリケーションからのリクエストかＲＳＳクライアントアプリケーションからのリクエストかを振り分ける振り分け工程と、
    前記ＨＴＭＬクライアントアプリケーションからのリクエストに基づいて前記画像データに関するＨＴＭＬデータを生成するＨＴＭＬデータ生成工程と、
    前記ＲＳＳクライアントアプリケーションからのリクエストに基づいて前記画像データに関するＲＳＳデータを生成するＲＳＳデータ生成工程と、
    前記ＨＴＭＬデータまたは前記ＲＳＳデータを前記クライアント端末に返信する返信行程と、
    前記ＦＡＸ通信工程で受信した画像データを他装置に転送する転送工程と、を備え、
    前記ＲＳＳデータ生成工程は、前記画像データを他装置に転送した場合に、該画像データの転送先情報を前記ＲＳＳデータの添付ファイル情報に含めた前記ＲＳＳデータを、前記ＲＳＳクライアントアプリケーションからのリクエストに含まれるＲＥＳＴインタフェースで指定される前記画像データの転送先のプロトコルについて生成することを特徴とするネットワーク通信装置の制御方法。
  8. 前記ＲＳＳデータ生成工程は、該ネットワーク通信装置の機能ごとに前記ＲＳＳデータを生成することを特徴とする請求項６または７記載のネットワーク通信装置の制御方法。
  9. 前記ＲＳＳデータ生成工程は、前記画像データの転送先情報を前記ＲＳＳデータのリンク情報に含めた前記ＲＳＳデータを生成することを特徴とする請求項６から８のいずれか１項記載のネットワーク通信装置の制御方法。
  10. 前記ＲＳＳデータ生成工程は、前記画像データを閲覧可能なアプリケーションのアドレスを前記ＲＳＳデータのリンク情報または本文情報に含めた前記ＲＳＳデータを生成することを特徴とする請求項６から９のいずれか１項記載のネットワーク通信装置の制御方法。
  11. 請求項６から１０のいずれか１項記載のネットワーク通信装置の制御方法における各工程の処理をネットワーク通信装置に実行させるネットワーク通信装置の制御プログラム。
  12. 請求項１１項記載のネットワーク通信装置の制御プログラムを記録したコンピュータ読み取り可能な記録媒体。
JP2006192199A 2006-07-12 2006-07-12 ネットワーク通信装置、ネットワーク通信装置の制御方法、ネットワーク通信装置の制御プログラムおよび記録媒体 Expired - Fee Related JP4810339B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2006192199A JP4810339B2 (ja) 2006-07-12 2006-07-12 ネットワーク通信装置、ネットワーク通信装置の制御方法、ネットワーク通信装置の制御プログラムおよび記録媒体

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2006192199A JP4810339B2 (ja) 2006-07-12 2006-07-12 ネットワーク通信装置、ネットワーク通信装置の制御方法、ネットワーク通信装置の制御プログラムおよび記録媒体

Publications (2)

Publication Number Publication Date
JP2008021118A JP2008021118A (ja) 2008-01-31
JP4810339B2 true JP4810339B2 (ja) 2011-11-09

Family

ID=39077002

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2006192199A Expired - Fee Related JP4810339B2 (ja) 2006-07-12 2006-07-12 ネットワーク通信装置、ネットワーク通信装置の制御方法、ネットワーク通信装置の制御プログラムおよび記録媒体

Country Status (1)

Country Link
JP (1) JP4810339B2 (ja)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2010028401A1 (en) * 2008-09-05 2010-03-11 Yammer, Inc. System and method for collaborative short messaging and discussion
JP6282081B2 (ja) 2013-11-01 2018-02-21 キヤノン株式会社 画像処理装置、画像処理装置の制御方法及びプログラム
US11017037B2 (en) * 2017-07-03 2021-05-25 Google Llc Obtaining responsive information from multiple corpora
KR101944188B1 (ko) * 2017-07-11 2019-02-07 동서대학교 산학협력단 시각장애인용 음성서비스 제공 시스템
JP7167247B2 (ja) * 2019-08-05 2022-11-08 キヤノン株式会社 画像処理装置、画像処理装置の制御方法及びプログラム

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2004112445A (ja) * 2002-09-19 2004-04-08 Murata Mach Ltd ファクシミリサーバおよびファクシミリシステム
JP2006035849A (ja) * 2004-06-25 2006-02-09 Ricoh Co Ltd ネットワーク装置
JP4177305B2 (ja) * 2004-08-06 2008-11-05 株式会社リコー ネットワーク通信装置
JP2006163901A (ja) * 2004-12-08 2006-06-22 Ricoh Co Ltd ネットワーク機器、プログラムおよび記録媒体

Also Published As

Publication number Publication date
JP2008021118A (ja) 2008-01-31

Similar Documents

Publication Publication Date Title
JP3368804B2 (ja) ハイパーテキスト送信方法及びハイパーテキスト送信サーバ装置
US7490139B2 (en) Embedded business apparatus including web server function
US20020002451A1 (en) Translating system and translating apparatus
JP4810339B2 (ja) ネットワーク通信装置、ネットワーク通信装置の制御方法、ネットワーク通信装置の制御プログラムおよび記録媒体
US7822864B2 (en) Communication apparatus, program product for adding communication mechanism to communication apparatus for providing improved usability and communication efficiency, and recording medium storing program product
CN102685356B (zh) 图像读取设备和图像读取方法
US7991828B2 (en) Network communication apparatus generating XML responses based on HTTP requests
JP4666849B2 (ja) 印刷ジョブ管理方法および装置
JP5257142B2 (ja) 画像形成装置、画像形成システム、情報処理方法、及び、コンピュータプログラム
JP2008217750A (ja) ネットワーク装置、画像形成装置、データ検索方法、データ検索プログラム及びコンピュータ読み取り可能な記録媒体
US20040003121A1 (en) Document server and recording medium recording document processing program
JP2005322222A (ja) 通信機能付加方法、プログラム、記録媒体及び通信装置
JP2009130493A (ja) ネットワーク対応画像処理装置
JP2006285840A (ja) 文書管理システム
JP4177305B2 (ja) ネットワーク通信装置
JP4359569B2 (ja) ネットワーク通信装置
US20070136784A1 (en) Communication terminal apparatus
JP4362778B2 (ja) プロキシサーバ装置
JP2004072131A (ja) ネットワークファクシミリ装置
JP2006135890A (ja) データ処理システム、データ処理システムの制御方法、情報処理装置、画像処理装置、プログラムおよび記憶媒体
JP4545621B2 (ja) ネットワーク通信装置
JP2010182272A (ja) 画像処理装置、その制御方法及びコンピュータプログラム
JP2007251845A (ja) ネットワーク通信装置
JP4188768B2 (ja) ネットワーク通信装置、プログラムおよび記録媒体
JP5988670B2 (ja) データ処理装置、データ処理方法、及びプログラム

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20090413

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20110329

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20110525

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20110816

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20110822

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20140826

Year of fee payment: 3

R150 Certificate of patent or registration of utility model

Free format text: JAPANESE INTERMEDIATE CODE: R150

LAPS Cancellation because of no payment of annual fees