(57)【要約】【課題】クライアント端末からの要求に基づいて、ＨＴＭＬデータとＸＭＬデータ（ＲＳＳデータ）とを切り替えて返信するネットワーク通信装置、ネットワーク通信装置の制御方法、ネットワーク通信装置の制御プログラムおよび記録媒体を提供する。【解決手段】外部からのリクエストを受け付けると、当該リクエストを解析する。そしてリクエストがＲＳＳの場合とＨＴＭＬの場合とでそれぞれ振り分けられる。リクエストがＲＳＳの場合にはＸＭＬレスポンスデータが生成され、ＨＴＭＬの場合には従来通りＨＴＭＬレスポンスデータが生成される。【選択図】図１
2008021118.tif 000002
【特許請求の範囲】
【請求項１】
公衆回線網に接続され所定のファクシミリ伝送手順にてデータの送受信を行うＦＡＸ通信手段と、ネットワークに接続され所定のプロトコルにてデータの送受信を行うネットワーク通信手段とを備え、少なくとも１以上のクライアント端末と前記データの送受信を行うネットワーク通信装置であって、
前記ＦＡＸ通信手段にて受信した前記データ、および、受信した当該データの一覧の一覧情報を蓄積して記憶するデータ蓄積手段と、
外部からのリクエストを解析する解析手段と、
前記解析手段の解析結果に基づいて、クライアントアプリケーションからのリクエストかＲＳＳクライアントからのリクエストかを振り分ける振り分け手段と、
前記クライアントアプリケーションからのリクエストに基づいてＨＴＭＬデータを生成するＨＴＭＬデータ生成手段と、
前記ＲＳＳクライアントからのリクエストに基づいてＸＭＬデータを生成するＸＭＬデータ生成手段と、
前記クライアント端末からの要求に基づいてデータを返信する場合に、前記ＨＴＭＬデータと前記ＸＭＬデータとを切り替える切り替え手段と、
前記切り替え手段にて切り替えられた前記ＨＴＭＬデータと前記ＸＭＬデータとを返信する返信手段とを有することを特徴とするネットワーク通信装置。
【請求項２】
前記クライアント端末からの要求に基づいて、当該クライアント端末の機能ごとにＲＳＳデータを生成するＲＳＳデータ生成手段を有し、
生成された前記ＲＳＳデータを前記返信手段にて返信することを特徴とする請求項１記載のネットワーク通信装置。
【請求項３】
前記クライアントアプリケーションから前記一覧情報のリクエストを受け付けると、ＸＭＬ文書にて返信するＸＭＬ文書返信手段と、
前記蓄積手段にて蓄積した前記データおよび前記一覧情報の蓄積先のアドレスを前記ＸＭＬデータフォーマットであるＲＳＳフォーマットに付加する蓄積先データ生成手段とを有することを特徴とする請求項１記載のネットワーク通信装置。
【請求項４】
前記データをメモリ転送するメモリ転送手段を有し、
前記蓄積先データ生成手段は、メモリ転送を行った場合に前記データの転送先情報を前記ＲＳＳフォーマットの添付ファイル情報に付加して、前記返信手段にて返信することを特徴とする請求項１または３記載のネットワーク通信装置。
【請求項５】
前記データをメモリ転送するメモリ転送手段を有し、
前記蓄積先データ生成手段は、メモリ転送を行った場合に、前記データの転送先情報を前記ＲＳＳフォーマットのリンク情報に付加して、前記返信手段にて返信することを特徴とする請求項２または３記載のネットワーク通信装置。
【請求項６】
前記メモリ転送手段にてメモリ転送を行った場合、前記蓄積先データ生成手段は、前記データの転送先情報を前記ＲＳＳフォーマットの前記添付ファイル情報および前記リンク情報に付加して、前記返信手段にて返信することを特徴とする請求項４または５記載のネットワーク通信装置。
【請求項７】
前記メモリ転送手段にてメモリ転送を行った場合、前記データの転送先情報を前記ＲＳＳフォーマットの前記添付ファイル情報と前記リンク情報とのうちいずれに付加するかを選択する選択手段を有することを特徴とする請求項４から６のいずれか１項記載のネットワーク通信装置。
【請求項８】
前記メモリ転送手段にてメモリ転送を行った場合、前記蓄積先データ生成手段は、転送先のプロトコルごとに前記ＲＳＳフォーマットを生成して、前記返信手段にて返信することを特徴とする請求項３から７のいずれか１項記載のネットワーク通信装置。
【請求項９】
前記メモリ転送手段にてメモリ転送を行った場合、前記蓄積先データ生成手段は、ＲＥＳＴインタフェースにて指定した転送先のプロトコルのみ前記ＲＳＳフォーマットを生成し、前記返信手段にて返信することを特徴とする請求項３から７のいずれか１項記載のネットワーク通信装置。
【請求項１０】
前記データの要求に基づき当該データを返信する場合、前記蓄積先データ生成手段は、当該データを閲覧可能なアプリケーションソフトのアドレスをＲＳＳフォーマットのリンク情報または本文情報に付加し、前記返信手段にて返信することを特徴とする請求項１から９のいずれか１項記載のネットワーク通信装置。
【請求項１１】
公衆回線網に接続され所定のファクシミリ伝送手順にてデータの送受信を行うＦＡＸ通信工程と、ネットワークに接続され所定のプロトコルにてデータの送受信を行うネットワーク通信工程とを備え、少なくとも１以上のクライアント端末と前記データの送受信を行うネットワーク通信装置の制御方法であって、
前記ＦＡＸ通信工程にて受信した前記データ、および、受信した当該データの一覧の一覧情報を蓄積して記憶するデータ蓄積工程と、
外部からのリクエストを解析する解析工程と、
前記解析工程の解析結果に基づいて、クライアントアプリケーションからのリクエストかＲＳＳクライアントからのリクエストかを振り分ける振り分け工程と、
前記クライアントアプリケーションからのリクエストに基づいてＨＴＭＬデータを生成するＨＴＭＬデータ生成工程と、
前記ＲＳＳクライアントからのリクエストに基づいてＸＭＬデータを生成するＸＭＬデータ生成工程と、
前記ＨＴＭＬデータと前記ＸＭＬデータとを切り替える切り替え工程とを有し、
前記クライアント端末からの要求に基づいて前記ＨＴＭＬデータと前記ＸＭＬデータとを切り替えて返信することを特徴とするネットワーク通信装置の制御方法。
【請求項１２】
前記クライアント端末からの要求に基づいて、当該クライアント端末の機能ごとにＲＳＳデータを生成して返信することを特徴とする請求項１１記載のネットワーク通信装置の制御方法。
【請求項１３】
前記クライアントアプリケーションから前記一覧情報のリクエストを受け付けると、ＸＭＬ文書にて返信するＸＭＬ文書返信工程と、
前記蓄積手段にて蓄積した前記データおよび前記一覧情報の蓄積先のアドレスを前記ＸＭＬデータフォーマットであるＲＳＳフォーマットに付加する蓄積先データ生成工程とを有することを特徴とする請求項１１記載のネットワーク通信装置の制御方法。
【請求項１４】
前記データをメモリ転送するメモリ転送工程を有し、
メモリ転送を行った場合に、前記データの転送先情報を前記ＲＳＳフォーマットの添付ファイル情報に付加して返信することを特徴とする請求項１１または１３記載のネットワーク通信装置の制御方法。
【請求項１５】
メモリ転送を行った場合に、前記データの転送先情報を前記ＲＳＳフォーマットのリンク情報に付加して返信することを特徴とする請求項１２または１３記載のネットワーク通信装置の制御方法。
【請求項１６】
前記メモリ転送工程にてメモリ転送を行った場合、前記データの転送先情報を前記ＲＳＳフォーマットの前記添付ファイル情報および前記リンク情報に付加して返信することを特徴とする請求項１４または１５記載のネットワーク通信装置の制御方法。
【請求項１７】
前記メモリ転送工程にてメモリ転送を行った場合、前記データの転送先情報を前記ＲＳＳフォーマットの前記添付ファイル情報と前記リンク情報とのうちいずれに付加するかを選択する選択工程を有することを特徴とする請求項１４から１６のいずれか１項記載のネットワーク通信装置の制御方法。
【請求項１８】
前記メモリ転送工程にてメモリ転送を行った場合、転送先のプロトコルごとに前記ＲＳＳフォーマットを生成して返信することを特徴とする請求項１３から１７のいずれか１項記載のネットワーク通信装置の制御方法。
【請求項１９】
前記メモリ転送工程にてメモリ転送を行った場合、ＲＥＳＴインタフェースにて指定した転送先のプロトコルのみ前記ＲＳＳフォーマットを生成して返信することを特徴とする請求項１３から１７のいずれか１項記載のネットワーク通信装置の制御方法。
【請求項２０】
前記データの要求に基づき当該データを返信する場合、当該データを閲覧可能なアプリケーションソフトのアドレスをＲＳＳフォーマットのリンク情報または本文情報に付加して返信することを特徴とする請求項１１から１９のいずれか１項記載のネットワーク通信装置の制御方法。
【請求項２１】
公衆回線網に接続され所定のファクシミリ伝送手順にてデータの送受信を行うＦＡＸ通信処理と、ネットワークに接続され所定のプロトコルにてデータの送受信を行うネットワーク通信処理とを備え、少なくとも１以上のクライアント端末と前記データの送受信を行うネットワーク通信装置の制御プログラムであって、
前記ＦＡＸ通信工程にて受信した前記データ、および、受信した当該データの一覧の一覧情報を蓄積して記憶するデータ蓄積処理と、
外部からのリクエストを解析する解析処理と、
前記解析処理の解析結果に基づいて、クライアントアプリケーションからのリクエストかＲＳＳクライアントからのリクエストかを振り分ける振り分け処理と、
前記クライアントアプリケーションからのリクエストに基づいてＨＴＭＬデータを生成するＨＴＭＬデータ生成処理と、
前記ＲＳＳクライアントからのリクエストに基づいてＸＭＬデータを生成するＸＭＬデータ生成処理と、
前記ＨＴＭＬデータと前記ＸＭＬデータとを切り替える切り替え処理とを実行させ、
前記クライアント端末からの要求に基づいて前記ＨＴＭＬデータと前記ＸＭＬデータとを切り替えて返信するようコンピュータに実行させることを特徴とするネットワーク通信装置の制御プログラム。
【請求項２２】
前記クライアント端末からの要求に基づいて、当該クライアント端末の機能ごとにＲＳＳデータを生成して返信するようコンピュータに実行させることを特徴とする請求項２１記載のネットワーク通信装置の制御プログラム。
【請求項２３】
前記クライアントアプリケーションから前記一覧情報のリクエストを受け付けると、ＸＭＬ文書にて返信するＸＭＬ文書返信処理と、
前記蓄積手段にて蓄積した前記データおよび前記一覧情報の蓄積先のアドレスを前記ＸＭＬデータフォーマットであるＲＳＳフォーマットに付加する蓄積先データ生成処理とをコンピュータに実行させることを特徴とする請求項２１記載のネットワーク通信装置の制
御プログラム。
【請求項２４】
前記データをメモリ転送するメモリ転送処理を実行させ、
メモリ転送を行った場合に、前記データの転送先情報を前記ＲＳＳフォーマットの添付ファイル情報に付加して返信するようコンピュータに実行させることを特徴とする請求項２１または２３記載のネットワーク通信装置の制御プログラム。
【請求項２５】
メモリ転送を行った場合に、前記データの転送先情報を前記ＲＳＳフォーマットのリンク情報に付加して返信するようコンピュータに実行させることを特徴とする請求項２２または２３記載のネットワーク通信装置の制御プログラム。
【請求項２６】
前記メモリ転送処理にてメモリ転送を行った場合、前記データの転送先情報を前記ＲＳＳフォーマットの前記添付ファイル情報および前記リンク情報に付加して返信するようコンピュータに実行させることを特徴とする請求項２４または２５記載のネットワーク通信装置の制御プログラム。
【請求項２７】
前記メモリ転送処理にてメモリ転送を行った場合、前記データの転送先情報を前記ＲＳＳフォーマットの前記添付ファイル情報と前記リンク情報とのうちいずれに付加するかを選択する選択処理をコンピュータに実行させることを特徴とする請求項２４から２６のいずれか１項記載のネットワーク通信装置の制御プログラム。
【請求項２８】
前記メモリ転送処理にてメモリ転送を行った場合、転送先のプロトコルごとに前記ＲＳＳフォーマットを生成して返信するようコンピュータに実行させることを特徴とする請求項２３から２７のいずれか１項記載のネットワーク通信装置の制御プログラム。
【請求項２９】
前記メモリ転送処理にてメモリ転送を行った場合、ＲＥＳＴインタフェースにて指定した転送先のプロトコルのみ前記ＲＳＳフォーマットを生成して返信するようコンピュータに実行させることを特徴とする請求項２３から２７のいずれか１項記載のネットワーク通信装置の制御プログラム。
【請求項３０】
前記データの要求に基づき当該データを返信する場合、当該データを閲覧可能なアプリケーションソフトのアドレスをＲＳＳフォーマットのリンク情報または本文情報に付加して返信することを特徴とする請求項２１から２９のいずれか１項記載のネットワーク通信装置の制御プログラム。
【請求項３１】
請求項２１から３０のいずれか１項記載のネットワーク通信装置の制御プログラムを記録したコンピュータ読み取り可能な記録媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワーク通信装置が持つ情報をセマンティックＸＭＬにて他の機器に情報提供することの可能なネットワーク通信装置、ネットワーク通信装置の制御方法、ネットワーク通信装置の制御プログラムおよび記録媒体に関する。
【背景技術】
【０００２】
従来より、各種の機器、特にプリンタ、ファクシミリ装置、複写機等の事務機器は、ＨＴＴＰプロトコルによりデータの送受信を行うＨＴＴＰ通信機能や、ＰＳＴＮに接続されファクシミリ伝送によるデータの送受信を行うファクス通信機能など、ネットワーク通信機能を備えるようになっている。また、機器内部にＷｅｂアクセス機構を備え、Ｗｅｂ技術を用いた、強化拡張された通信機能を備えているものがある。
【０００３】
このようなネットワーク通信装置の従来技術として、特許文献１〜３に開示された発明が公知である。特許文献１には、ＷＷＷサーバプログラムを搭載することにより、外部装置のＷＷＷブラウザによって操作することができるファクシミリ装置に関する技術が開示されている。
【０００４】
また特許文献２には、画像処理装置にＷｅｂサーバ機能を持たせ、画像データに関する情報のリストをＷｅｂページとして生成させることで、装置の状態をユーザに通知するためのソフトウェアの設計、操作などの労力を軽減する技術が開示されている。
【０００５】
さらに特許文献３には、ＬＡＮなどのネットワークに接続可能な各種のネットワーク装置自体又はその他の外部装置が保有する情報を相互利用することが可能な技術が開示されている。
【特許文献１】特開２０００−０９２２６２号公報
【特許文献２】特開２００２−００７０９５号公報
【特許文献３】特開２００５−２０９０５６号公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】
従来のネットワーク通信装置で機器の情報を取得する場合には、ブラウザ経由でユーザーが操作することによって行っていたが、ファイルの場所を知るためにはブラウザを立ち上げて見ないといけないという問題があった。そのため、人を介した操作でしかダウンロードが実現できないため自動化処理等には向いていなかった。また、クライントが多様化してきたときに、レスポンスするデータのフォーマットを通信装置側で自由に切り替えることができなかった。
【０００７】
また上述した従来技術では、ブラウザから通信装置の設定をしたり情報を取得する方法はあったが、セマンティックＸＭＬ（ＲＳＳ）にてファイル蓄積受信文書のダウンロードを行うための情報を出力する方法はなかった。また、機器（ＭＦＰ）のファクス蓄積受信文書の引き取り機能はあったが、これは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のようになる。
【０１２０】
次に、パラメータメモリ３から操作部であるＳＷ情報を取得する（ステップＳ６０３）。そして取得したＳＷの値がｌｉｎｋ要素に出力するよう設定されているか否かを確認する（ステップＳ６０４）。ＳＷの値がｌｉｎｋ要素に設定するようになっていれば（ステップＳ６０４／Ｙｅｓ）、ｉｔｅｍのｌｉｎｋ要素にファイルダウンロード用のＵＲＬをセットする（ステップＳ６０５）。このとき、ｅｎｃｌｏｓｕｒｅ要素には何もセットしない。
【０１２１】
一方、ＳＷの値をｌｉｎｋ要素に出力しない場合、すなわちＳＷの値がｅｎｃｌｏｓｕｒｅ要素に設定するようになっていれば（ステップＳ６０４／Ｎｏ）、ｅｎｃｌｏｓｕｒｅ要素にファイルダウンロード用のＵＲＬをセットする（ステップＳ６０６）。そして、ｌｉｎｋ要素に対して機器のファクス蓄積受信文書のＷｅｂＰａｇｅをブラウザから閲覧するためのＵＲＬの生成（ステップＳ６０７）、および生成したＵＲＬのセットを行う（ステップＳ６０８）。このセットは、例えば図１３に示すようなｅｎｃｌｏｓｕｒｅ要素、またはｉｔｅｍのｌｉｎｋ要素にその値がセットされる。
【０１２２】
そして、その他の必要なＲＳＳフィードのデータをセットし、レスポンス用のＸＭＬデータを生成して（ステップＳ６０９）、このレスポンスデータをクライアントへと送信する（ステップＳ６１０）。
【０１２３】
なお、メモリ転送あて先がフォルダ転送ではない場合、すなわちメモリ転送先にフォルダアドレスがない場合には（ステップＳ６０１／Ｎｏ）、ｅｎｃｌｏｓｕｒｅ要素には何もセットしないで、ｌｉｎｋ要素に対して機器のファクス蓄積受信文書のＷｅｂＰａｇｅをブラウザから閲覧するためのＵＲＬを生成するステップＳ６０７へと移行する。
【０１２４】
ただし、フォルダあて先に例えばパスワードが付与されているなどアクセス制限がある場合には、ｅｎｃｌｏｓｕｒｅ要素には何もセットしないことも可能である。また、その際には、ｅｎｃｌｏｓｕｒｅ要素に何もセットしないことを示すガイダンス用ＷｅｂＰａｇｅのＵＲＬをｌｉｎｋ要素に入れることも可能である。
【０１２５】
従来では、メモリ転送を行った場合には、転送先あて先をＲＳＳフォーマットのリンク情報と添付ファイル情報の両方に含めて返信するが、どちらに出力するのか選択することができないという問題があった。しかし本実施形態によれば、受信したファクス画像をメモリ転送機能を使って、他のＰＣ等に転送した際の転送先のアドレス（ＵＲＬ）を標準ＸＭＬフォーマットのＲＳＳ形式で配信する場合に添付ファイル情報とリンク情報のどちらに情報を入れるのか選択できるので、クライアントの仕様に合わせてユーザの自由選択度が増し、利便性が向上する。
【０１２６】
また本実施形態では、標準ＸＭＬフォーマットであるＲＳＳ形式でファクス蓄積受信文書情報を出力すると同時に、当該情報を閲覧するためのビューワーソフトの情報を含めることができる。
【０１２７】
図１９は、ダウンロードファイルを閲覧するためのビューワーソフトの所在を通知する動作を示すフローチャートである。すなわち、履歴情報のプロパティ情報から、メモリ転送先のあて先に対して送信したファイルのファイルタイプを取得する。ビューワーソフトをサポートしているファイルタイプの場合は、図１７に示す表に対応したビューワーソフトの所在を示すＵＲＬを生成することになる。この図１７に示すようなテーブルデータは、パラメータメモリ３に保存されている。なおこの設定は、操作部（ＳＷ）など機器のパネルやＷｅｂブラウザから設定可能である。
【０１２８】
まず、ダウンロードしたファイルの属性情報を取得する（ステップＳ７０１）。次に、取得した属性情報から、このファイルがビューワーソフトをサポートしているファイルタイプ（種別）かを確認する（ステップＳ７０２）。サポートしているファイルタイプの場合には（ステップＳ７０２／Ｙｅｓ）、そのファイルタイプを判別する（ステップＳ７０３）。
【０１２９】
ここで、判別されたファイルタイプに応じて、対応するビューワーソフトの所在を示すＵＲＬの生成が行われる。すなわち、ファイルの種別がＰＤＦの場合にはＰＤＦ用のビューワーソフトのダウンロード用ＵＲＬが生成され（ステップＳ７０４）、またＴＩＦＦの場合にはＴＩＦＦ用のビューワーソフトのダウンロード用ＵＲＬが生成され（ステップＳ７０５）、さらにＪＰＥＧの場合にはＪＰＥＧ用のビューワーソフトのダウンロード用ＵＲＬが生成される（ステップＳ７０６）。
【０１３０】
このようにして生成されたビューワーソフトの所在を示すＵＲＬは、図１６に示すようなｌｉｎｋ要素またはｅｎｃｌｏｓｕｒｅ要素に設定する（ステップＳ７０７）。最後にレスポンスデータを送信する（ステップＳ７０８）。なお、サポートしていないファイル
タイプの場合には（ステップＳ７０２／Ｎｏ）、何も値をセットしない。
【０１３１】
従来では、ファクス受信文書をダウンロードする場合には、ブラウザ経由でユーザが操作することによって行っていたが、ファイルを開くためのビューワーソフトは、自分で探してインストールをしないといけないという問題があった。そのため、未知のファイル形式の場合には、ファイルをダウンロードしても開いて中身を見ることができなかった。しかし本実施形態によれば、標準ＸＭＬフォーマットであるＲＳＳ形式でファクス蓄積受信文書情報を出力すると同時に閲覧するためのビューワーソフトの情報を含めるので、ユーザがダウンロードしたファイルが開けるようになる。
【産業上の利用可能性】
【０１３２】
本実施形態のネットワーク通信装置、ネットワーク通信装置の制御方法、ネットワーク通信装置の制御プログラムおよび記録媒体は、インターネット通信装置にも応用が可能である。
【図面の簡単な説明】
【０１３３】
【図１】本実施形態のネットワーク通信装置を用いた通信システムの一例を示す図である。
【図２】本実施形態のネットワーク通信装置ＦＸの構成を示すブロック図である。
【図３】ｌｉｎｋ要素を用いた場合のネットワーク通信装置とクライアントソフトウェアとのやりとりを示す図である。
【図４】ｅｎｃｌｏｓｕｒｅ要素を用いた場合のネットワーク通信装置とクライアントソフトウェアとのやりとりを示す図である。
【図５】ＸＭＬデータのＲＳＳアグリゲータでの表示例を示す図である。
【図６】ＨＴＭＬデータのＲＳＳアグリゲータでの表示例を示す図である。
【図７】ダウンロード情報のＲＳＳフィード（ｅｎｃｌｏｓｕｒｅ要素）を設定する動作を示すフローチャートである。
【図８】ダウンロード情報のＲＳＳフィード（ｌｉｎｋ要素）を設定する動作を示すフローチャートである。
【図９】ダウンロード情報のＲＳＳフィード（ａｎｃｌｏｓｕｒｅ／ｌｉｎｋ要素）を設定する動作を示すフローチャートである。
【図１０】ＲＥＳＴ  Ｉ／Ｆを用いたリクエスト種別によるＲＳＳ情報レスポンスを示すフローチャートである。
【図１１】プロトコル種別によるＲＳＳフィードのＵＲＬを模式的に示す図である。
【図１２】リクエスト種別によるＲＳＳフィードのＵＲＬ（ＲＥＳＴ  Ｉ／Ｆ）を模式的に示す図である。
【図１３】ＲＳＳフォーマットのサンプル図である。
【図１４】ＲＳＳフィードの仕様を示す図である。
【図１５】リンク情報とファイル添付情報との使い方を示す図である。
【図１６】ビューワー情報の指定方法を示すサンプル図である。
【図１７】ファイル種別に対応したビューワーの一例を示す図である。
【図１８】ダウンロード情報のＲＳＳフィードへの設定を、操作部（ＳＷ）に係る情報によって判定する場合を示すフローチャートである。
【図１９】ダウンロードファイルを閲覧するためのビューワーソフトの所在を通知する動作を示すフローチャートである。
【図２０】ダウンロード情報のＲＳＳフィードへの設定を、リクエスト種別によって判定する場合を示すフローチャートである。
【図２１】ＲＳＳ／ＨＴＭＬの切り替えに係る構成を模式的に示すブロック図である。
【図２２】アプリケーション種別によるＲＳＳフィードのＵＲＬを模式的に示す図である。
【符号の説明】
【０１３４】
１    システム制御部
２    システムメモリ
３    パラメータメモリ
４    時計回路
５    スキャナ
６    プロッタ
７    操作表示部
８    符号化／復号化部
９    画像蓄積部
１０    Ｇ３ＦＡＸモデム
１１    網制御部
１２    ＬＡＮ  Ｉ／Ｆ
１３    ＬＡＮ伝送制御部
１４    バス
【図１】
2008021118.tif 000003
【図２】
2008021118.tif 000004
【図３】
2008021118.tif 000005
【図４】
2008021118.tif 000006
【図５】
2008021118.tif 000007
【図６】
2008021118.tif 000008
【図７】
2008021118.tif 000009
【図８】
2008021118.tif 000010
【図９】
2008021118.tif 000011
【図１０】
2008021118.tif 000012
【図１１】
2008021118.tif 000013
【図１２】
2008021118.tif 000014
【図１３】
2008021118.tif 000015
【図１４】
2008021118.tif 000016
【図１５】
2008021118.tif 000017
【図１６】
2008021118.tif 000018
【図１７】
2008021118.tif 000019
【図１８】
2008021118.tif 000020
【図１９】
2008021118.tif 000021
【図２０】
2008021118.tif 000022
【図２１】
2008021118.tif 000023
【図２２】
2008021118.tif 000024