(57)【要約】【課題】  キーワードの正確性が判別できるようにキーワードを付与することを課題とする。【解決手段】  ブログ提供サーバ４０が要求する形式要件を予めサーバＤＢ１３ｃに記憶しておき、アップロードを行う際にはアップロード先として指定されたブログ提供サーバ４０の形式要件を取得する。そして、取得された形式要件に応じて、画像データのデータ量の削減や、画像データの文字データ化や、文字データの要約を行う。これにより、ユーザーが送信先のブログ提供サーバ４０が要求する各形式要件を調査し、その条件を満足するように元データを編集しなくても済むため、知識の少ないユーザーでも容易にアップロードを行うことができる。【選択図】  図４
2007280105.tif 000002
【特許請求の範囲】
【請求項１】
外部のサーバにアップロードさせるアップロードデータを送信するアップロード要求装置において、
元データを取得する元データ取得手段と、
上記サーバがアップロード可能なデータの形式要件を取得する形式要件取得手段と、
上記元データに基づいて上記形式要件に適合する上記アップロードデータを作成する作成手段と、
上記アップロードデータを上記サーバに送信する通信手段とを具備することを特徴とするアップロード要求装置。
【請求項２】
上記元データ取得手段はスキャナを具備し、同スキャナにてスキャンした画像データを上記元データとして入力することを特徴とする請求項１に記載のアップロード要求装置。
【請求項３】
上記元データ取得手段は電子データ記録媒体から画像データまたは文字データを上記元データとして入力することを特徴とする請求項１または請求項２のいずれかに記載のアップロード要求装置。
【請求項４】
上記作成手段は、上記元データが画像データであるとき同画像データに文字像が含まれるか否かを判定し、文字像が含まれる場合にはその文字像に対応する文字コードで構成される文字データを上記アップロードデータに組み込むこと特徴とする請求項２または請求項３のいずれかに記載のアップロード要求装置。
【請求項５】
上記作成手段は、上記元データが画像データであるとき同画像データに文字像が含まれるか否かを判定し、同画像データにおいて文字像を含まれない領域についての部分的な画像データを作成するとともに、同画像データと上記文字データを組み合わせて上記アップロードデータに組み込むことを特徴とする請求項４に記載のアップロード要求装置。
【請求項６】
上記作成手段は、上記文字データに含まれる文字数が上記形式要件の制限文字数を越える場合に同文字データを要約したものを上記アップロードデータに組み込むこと特徴とする請求項３から請求項５のいずれかに記載のアップロード要求装置。
【請求項７】
上記作成手段は、上記画像データのデータ量が上記形式要件の制限データ量を越える場合に同画像データのデータ量を削減することを特徴とする請求項２から請求項６のいずれかに記載のアップロード要求装置。
【請求項８】
上記作成手段は、上記形式要件が上記アップロードデータに画像データが含まれることを許容しない場合に、
上記画像データに文字像が含まれるか否かにかかわらず同画像データを複数の文字コードによって表現した文字データを上記アップロードデータに組み込むこと特徴とする請求項２から請求項７のいずれかに記載のアップロード要求装置。
【請求項９】
上記形式要件取得手段は複数の上記サーバにおける上記形式要件を記憶したデータベースを有することを特徴とする請求項１から請求項８のいずれかに記載のアップロード要求装置。
【請求項１０】
上記通信手段は上記サーバにて上記アップロードデータが反映された閲覧データを取得するとともに、
上記閲覧データを出力する画像出力手段が備えられることを特徴とする請求項１から請求項９のいずれかに記載のアップロード要求装置。
【請求項１１】
外部のサーバにアップロードさせるアップロードデータを送信するアップロード要求方法において、
元データと上記サーバがアップロード可能なデータの形式要件を取得するとともに、
上記元データに基づいて上記形式要件に適合するように作成した上記アップロードデータを上記サーバに送信することを特徴とするアップロード要求方法。
【請求項１２】
外部のサーバにアップロードさせるアップロードデータを送信する機能をコンピュータに実行させるアップロード要求プログラムにおいて、
元データを取得する元データ取得機能と、
上記サーバがアップロード可能なデータの形式要件を取得する形式要件取得機能と、
上記元データに基づいて上記形式要件に適合する上記アップロードデータを作成する作成機能と、
上記アップロードデータを上記サーバに送信する通信機能とをコンピュータに実現させることを特徴とするアップロード要求プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、アップロード要求装置、アップロード要求方法およびアップロード要求プログラムに関する。
【背景技術】
【０００２】
ブログ(Web Log)や電子掲示板に文書や画像データを投稿する場合、ブログや電子掲示板を提供するサーバの要求に合った適式なアップロードデータを作成し、送信する必要がある。適式なアップロードデータを作成することは初心者にとっては困難であり、初心者が気軽にブログや電子掲示板に投稿を行うことが困難であった。一方、ある程度アップロードデータの形式に許容性の幅を持たせて、受信するサーバ側にて形式を整える技術が提案されている（例えば、特許文献１、参照。）。
かかる構成によれば形式を多少違反したアップロードデータでもサーバにてアップロードすることが可能となり、投稿者がアップロードデータを作成する難易度を緩和することが可能であった。
【特許文献１】特開平１０−６３６７２号公報
【発明の開示】
【発明が解決しようとする課題】
【０００３】
しかしながら、上述した技術においてもアップロードデータをメーラによってＭＩＭＥ形式に整えておく必要があり、やはりパーソナルコンピュータに不慣れなユーザーやパーソナルコンピュータを所有していないユーザーにとっては容易に投稿を行うことができないという問題があった。例えば、手書きの文書に記載された内容を投稿しようとした場合、文書の内容をキーボード等で入力するか、手書きの文書をスキャナで取り込んだ画像データをメールに添付するという複雑な作業をしなければならない。また、大量に送られるアップロードデータの形式をサーバ側で整えると、処理負担がサーバに集中するという問題もあった。
この発明は、上記課題にかんがみてなされたものであり、容易にアップロードデータを送信することが可能なアップロード要求装置、アップロード要求方法およびアップロード要求プログラムを提供することを目的とする。
【課題を解決するための手段】
【０００４】
こうした目的を達成するため、元データ取得手段がアップロードデータの元となる元データを取得する。形式要件取得手段は上記サーバがアップロード可能なデータの形式要件を取得する。すなわち、上記アップロードデータがどのようなデータ形式であれば、上記サーバにてアップロード可能となるかという条件を取得する。作成手段は、上記元データに基づいて上記形式要件に適合する上記アップロードデータを作成する。そして、通信手段が上記作成手段にて作成された上記アップロードデータを上記サーバに送信する。かかる構成によれば、上記元データに基づいて上記サーバが要求する上記形式要件に適合する上記アップロードデータを作成することができ、ユーザーが上記形式要件を調査し同形式要件に適合するように上記元データを編集しなくてもよい。従って、編集する知識のないユーザーにでも容易に投稿を行うことが可能となる。
【０００５】
上記元データ取得手段においては種々の態様で上記元データを取得することができる。その一例として、上記元データ取得手段がスキャナでスキャンした画像データを上記元データとして取得するようにすれば、ユーザーが投稿する文章を入力する必要がなくて済む。例えば、手書きの文書や印刷した文書をスキャナにて入力することができる。
【０００６】
また、上記元データ取得手段が電子データ記録媒体から上記元データを入力してもよい。この場合、画像データが上記元データとして入力される場合もあるし、文字データが上記元データとして入力される場合もある。なお、上記画像データは所定の階調を有する多数の画素で構成されたデータを意味し、上記文字データは複数の文字コードの配列によって構成されたデータを意味する。上記電子データ記録媒体はどのような媒体であってもよく、フラッシュメモリカードや光学記録媒体や磁気記録媒体など種々適用することができる。
【０００７】
画像データが上記元データとして取得された場合、その画像データにおいて文字像が含まれるかどうかを判定する。すなわち、各画素の配列によって文字の形状が表された文字像が画像データに含まれるか否かを判定する。そして、文字像が含まれる場合には、その文字像に対応する文字コードで構成される文字データを生成し、その文字データを組み込んで上記アップロードデータを作成する。これにより、手書きの文書等をスキャナで取り込むことにより、文書中の文字を入力することなく文字データ化することができる。一般的に、画像データよりも文字データの方がデータ量を少なくすることができるため、上記アップロードデータのデータ量を抑制することができる。
【０００８】
さらに、上記元データが画像データにおける文字像を含まない領域についての部分的な画像データを作成する。例えば、上記元データとしての画像データが写真部分と文字像部分を含む場合、文字像部分については文字データ化され、写真部分については部分的な画像データが新たに作成される。そして、文字データと部分的な画像データとを組み合わせて上記アップロードデータに組み込む。これにより、写真部分の情報は部分的な画像データによって上記アップロードデータに反映させることができるし、文字像部分の情報は文字データによって上記アップロードデータに反映させることができる。
【０００９】
また、上記サーバが上記文字データに含まれる文字数に上記形式要件として制限を与えている場合には、上記文字データを要約することにより文字数が制限を下回るようにするのが望ましい。要約するにあたっては、単純に文章の一部を削除してもよいし、例えば特開２００３−１０８５７１号公報や特開２００２−２９７６３５号公報のように文章ベクトルを利用して重要部分のみを抜き出すようにしてもよい。
【００１０】
一方、上記サーバが上記画像データのデータ量に上記形式要件として制限を与えている場合には、上記画像データのデータ量を削減することにより制限を下回るようにするのが望ましい。上記画像データのデータ量を削減する手法は種々考えられ、上記画像データの解像度（サイズ）を小さくしたり、各画素が有する階調数を小さくしたり、圧縮を行なったりしてもよい。また、サムネイルデータが添付される画像データにおいては、サムネイルデータを画像データに置き換えればデータ量を削減することができる。
【００１１】
また、掲示板やメーリングリストなどでは上記サーバが画像データをアップロードすることを許容しない場合もある。この場合でも、写真などの画像の情報を失うことなく上記アップロードデータを作成することが望ましい。そこで、上記画像データに文字像が含まれるか否かにかかわらず同画像データを複数の文字コードによって表現した文字データを作成し、同文字データを上記アップロードデータに組み込むようにする。すなわち、文字像が含まれない画像であっても強制的に文字コードに変換する。例えば、画像データを数画素×数画素で構成される複数のブロックに分割し、そのブロックごとに文字とのパターンマッチングを行い、マッチングした文字に対応する文字コードを各ブロックの位置に応じて配列することにより画像データに対応する文字データを作成することができる。
【００１２】
各サーバによって上記形式要件が異なるため、それぞれの上記サーバについて上記形式要件が取得できるようにするのが望ましい。そこで、上記形式要件取得手段が複数の上記サーバにおける上記形式要件を記憶したデータベースを記憶するようにすれば、各サーバについての上記形式要件を取得することができる。
【００１３】
投稿後の状態を確認するための構成として、上記通信手段が上記サーバにて上記アップロードデータが反映された閲覧データを取得し、同閲覧データを上記画像出力手段にて出力すれば上記アップロードデータの出来映えを確認することができる。なお、上記画像出力手段は液晶ディスプレイ等の表示装置であってもよいし、プリンタ等の印刷装置であってもよい。
【００１４】
むろん、以上の発明は、装置のみならず、請求項１１のようなアップロード要求方法によって実現することも可能であるし、請求項１２のように上記方法に従った処理を実行するアップロード要求プログラムによって実現することも可能である。また、本発明にかかる装置、方法、プログラムは単独で実施される場合もあるし、ある機器に組み込まれた状態で他の装置、方法、プログラムとともに実施されることもあるなど、発明の思想としてはこれに限らず、各種の態様を含むものであり、適宜、変更可能である。
【００１５】
さらに、本発明のプログラムを記録した記録媒体として提供することも可能である。このプログラムの記録媒体は、磁気記録媒体であってもよいし光磁気記録媒体であってもよいし、今後開発されるいかなる記録媒体においても全く同様に考えることができる。また、一次複製品、二次複製品などの複製段階については全く問う余地無く同等である。さらに、一部がソフトウェアであって、一部がハードウェアで実現されている場合においても発明の思想において全く異なるものではなく、一部を記録媒体上に記憶しておいて必要に応じて適宜読み込まれるような形態のものとしてあってもよい。また、必ずしも全部の機能を単独のプログラムで実現するのではなく、複数のプログラムにて実現させるようなものであってもよい。この場合、各機能を複数のコンピュータに実現させるものであればよい。
【発明を実施するための最良の形態】
【００１６】
ここでは、下記の順序に従って本発明の実施形態について説明する。
（１）マルチファンクションプリンタの構成：
（２）アップロード要求処理：
（３）まとめ：
【００１７】
（１）マルチファンクションプリンタの構成：
図１は、本発明のアップロード要求装置としてのマルチファンクションプリンタ（ＭＦＰ）の概略構成を示している。同図において、ＭＦＰ１０には、内部バス１０ａによって接続されたＣＰＵ１１とＲＡＭ１２とＨＤＤ１３とメモリカードスロット（ＭＣＳ）１４とスキャナユニット１５とプリンタユニット１６とＬＡＮインターフェイス（Ｉ／Ｆ）１７とディスプレイ１８と操作パネル１９が備えられている。なお、ＭＦＰ１０にはパーソナルコンピュータが接続されてもよい。ＨＤＤ１３には各種プログラムデータ１３ａとアップロードデータ１３ｂとサーバデータベース（ＤＢ）１３ｃと単語辞書１３ｄとが記憶されている。ＬＡＮＩ／Ｆ１７は、さらに外部のＷＡＮインターフェイス（Ｉ／Ｆ）２０と接続されており、同ＷＡＮＩ／Ｆ２０を介してＭＦＰ１０とインターネット３０上の複数のブログ提供サーバ４０，４０，４０とが双方向通信可能となっている。なお、モデムと電話回線を利用してインターネット３０に接続してもよい。
【００１８】
図２は、ＭＦＰ１０の外観を示している。同図において、概略的にＭＦＰ１０の上方部分がスキャナユニット１５によって構成されている。上面にカバー１５ａが備えられており、同カバー１５ａを開放することによりフラットベット方式の原稿台１５ｂに文書を載置し、スキャンを行うことが可能となる。原稿台１５ｂの下方には図示しないラインセンサが備えられており、同ラインセンサを走査させることにより原稿台１５ｂ上の文書を撮像した２次元画像を入力することができる。ＭＦＰ１０の前面には矩形状の液晶ディスプレイ１８が備えられており、同液晶ディスプレイ１８にて各種ＵＩ画像が表示される。概略的にＭＦＰ１０の下方部分がプリンタユニット１６によって構成されている。
【００１９】
図３は、ＣＰＵ１１にて実行されるプログラムのソフトウェア構成を示している。同図において、オペレーティングシステム（Ｏ／Ｓ）が実行されており、同Ｏ／Ｓ上においてアップロード要求プログラムＰ１とスキャナドライバＰ２とプリンタドライバＰ３が実行されている。アップロード要求プログラムＰ１は、ＵＩ部Ｐ１ａと元データ取得部Ｐ１ｂと形式要件取得部Ｐ１ｃと文字認識部Ｐ１ｄと文章要約部Ｐ１ｅと画像変換部Ｐ１ｆと通信部Ｐ１ｇとから構成されている。形式要件取得部Ｐ１ｃと文字認識部Ｐ１ｄと文章要約部Ｐ１ｅと画像変換部Ｐ１ｆは本発明のアップロードデータ作成手段に行う処理を実行する。各プログラムＰ１〜Ｐ３および各モジュールＰ１ａ〜Ｐ１ｆが実行する機能はアップロード要求処理において詳細に説明する。
【００２０】
（２）アップロード要求処理：
図４，図５は、アップロード要求処理の流れを示している。本実施形態においては、ブログにアップロードを行うものを例に挙げて説明する。ステップＳ１００においては、アップロード要求プログラムＰ１のＵＩ部Ｐ１ａが所定のＵＩ画像をディスプレイ１８に表示させ、操作パネル１９にて各種設定項目についての指定をユーザーから受け付ける。本実施形態においてユーザーから指定される設定項目は、送信先の指定と文書ソースの指定とデータモードの指定と確認画像の出力先の指定である。ユーザーは操作パネル１９の各操作ボタンを操作することにより、これらの指定項目の設定を行うことができる。
【００２１】
図６は、ステップＳ１００にてディスプレイ１８が表示するＵＩ画像の一例を示している。同図において、ブログサービス提供者の名称の一覧が表示されており、これらのうち所望のものをプルダウン方式によって選択することが可能となっている。ここで表示される複数のブログサービス提供者の名称は、ブログサービスを提供しているブログ提供サーバ４０，４０，４０の識別名称であり、サーバＤＢ１３ｃに予め登録されているものを読み出して表示している。
【００２２】
図７は、サーバＤＢ１３ｃの記述内容を示している。サーバＤＢ１３ｃでは、各ブログサービス提供者の名称とブログ提供サーバ４０，４０，４０のＵＲＬと形式要件の対応関係が格納されている。サーバＤＢ１３ｃは、ＭＦＰ１０の製造時に予めＨＤＤ１３に記憶させておく。ただし、新規のブログサービス提供者が参入する場合もあるため、ユーザーが新たに登録できる。また、インターネット３０等を介して最新の内容にサーバＤＢ１３ｃがアップデートされるようにしてもよい。あるブログサービス提供者に対してブログサービスを受けるための登録をした場合、そのブログサービス提供者についてユーザーＩＤとパスワードが対応づけて記憶させることが可能になっている。
【００２３】
図６のＵＩ画像においては、投稿内容の文書ソースを指定するための表示が設けられている。ここでは、スキャナかメモリカードのいずれかを選択することが可能となっている。さらに、メモリカードを指定する場合には、メモリカード内に格納されているデータから文書ソースとする元データを選択指定することが可能となっている。ここで選択可能な元データは、画像データであってもよいし、文字データであってもよい。本実施形態では画像データとしてビットマップ形式（拡張子：.bmp）やＪＰＥＧ形式（拡張子：.jpg）やＥＸＩＦ形式（拡張子：.exif）が指定可能とされる。なお、ＥＸＩＦ形式（ver.2.2）はＪＥＩＴＡによって定められたファイル規格であり、ＪＰＥＧ形式の画像データに対して各種のタグ情報を添付することができる。例えば、画像データのサムネイルも添付することができる。一方、文字データとしては、例えばテキスト形式（拡張子：.txt）が選択可能とされる。
【００２４】
図６のＵＩ画像においては、データモードの指定をするための表示が設けられている。ここでは、画像モードと自動モードのいずれかを設定することが可能となっている。さらに、アップロードの出来映えを確認する確認画像を出力する出力先としてプリンタまたはディスプレイのいずれかを選択することが可能となっている。操作パネル１９には、決定を指示するための決定ボタンが設けられており、同決定ボタンを操作することにより指定された内容を確定することができる。確定された指定内容はＵＩ部Ｐ１ａによって受け付けられる。
【００２５】
ステップＳ１０５においては形式要件取得部Ｐ１ｃがステップＳ１００にて指定を受け付けた送信先のブログサービス提供者に対応する形式要件をサーバＤＢ１３ｃから取得する。本実施形態では、形式要件として一度にアップロードできる文字データの制限文字数と、画像データのアップロード可否と、アップロード可能な画像データのデータ形式と、画像データが一度にアップロードできる制限データ量とが取得される。文字数によって直接的に制限文字数が規定されていてもよいし、文字数に換算できるデータ量（バイト数）によって間接的に制限文字数が規定されていてもよい。
【００２６】
ステップＳ１１０においては、Ｓ１００にて指定を受け付けた文書ソースがスキャナであるかメモリカードのどちらであるかを判定し、スキャナが指定された場合には元データ取得部Ｐ１ｂがステップＳ１２０にてスキャンを開始する。すなわち、元データ取得部Ｐ１ｂがスキャナドライバＰ２を起動させ、同スキャナドライバＰ２によるスキャナユニット１５の制御を開始する。その際に、ユーザーがスキャンしたい文書を原稿台１５ｂに載置し、載置した旨の操作を操作パネル１９にて受け付ける。載置した旨の操作が受け付けられると、スキャナユニット１５にて原稿を照明し、ラインセンサを走査させながら画像入力を開始する。ラインセンサによる入力信号は順次ＣＰＵ１１に転送され、スキャナドライバＰ２がＣＰＵ１１にて画像データを生成する。そして、生成した画像データを元データ取得部Ｐ１ｂが元データとして取得する。
【００２７】
一方、ステップＳ１００にて指定された文書ソースがメモリカードである場合には、ステップＳ１３０にて指定された元データを元データ取得部Ｐ１ｂがＭＣＳ１４を介して取得する。そして、ステップＳ１４０においては、取得した元データが文字データと画像データのいずれであるかが判定される。この判定においては、上述した各データ形式に対応する拡張子に基づいて判定を行うことができる。ステップＳ１２０にてスキャンを行った場合、または、メモリカードから取得した元データが画像データである場合には、指定されたデータモードが画像モードと自動モードのいずれであったかがステップＳ１５０にて判定される。
【００２８】
画像モードは原則的に画像データの元データを画像データのままアップロードさせるためのモードであり、自動モードは画像データの元データのうち文字データに変換できる部分を文字データに変換してアップロードさせるモードである。データモードが自動モードである場合には、ステップＳ１６０にて文字認識部Ｐ１ｄが画像データである元データから文字像の検出を行う。文字像を検出する手法としては種々のものを適用することができ、以下その一例を簡単に説明する。例えば、元データにおいて中間階調が少ない領域を文字像が存在する領域の候補とし、その領域を２値化して下地を除去する。そして、下地除去後の有効な画素のブロックを複数検出し、そのブロックごとに文字とのパターンマッチングを行う。パターンマッチングにおいて文字との相関が高いブロックが所定数存在した場合には、その領域が文字像を有する領域であると存在すると判定することができる。
【００２９】
ステップＳ１７０においては画像データの元データにおいて文字像があるかどうかが判定され、文字像がある場合には、文字認識部Ｐ１ｄがステップＳ１８０にて文字像を有する領域に対して文字認識を行う。上述した例では、ステップＳ１６０における文字像の検出において文字とのパターンマッチングが行われているため、このパターンマッチングにおいてある閾値以上の相関が得られた文字に対応する文字コードをブロックごとに取得する。そして、ステップＳ１９０では、画像データにおける各ブロックの相対位置関係に基づいて各文字コードを順に配列することにより複数の文字コードからなる文字データを生成する。その際に、文字データ化した領域については元の画像データからトリミングされる。すなわち、中間階調の画素が存在していたり、文字との相関が低かった領域については文字データ化されることなく画像データのまま分離される。
【００３０】
図８は、元データの一例を示している。同図においては、写真と手書きの文章とが混在している画像データが元データとして示されている。このような場合、手書きの文章の部分Ａについては文字像が存在するため文字データに変換され、中間階調を有する写真の部分Ｂについては画像データのまま保持されることとなる。ステップＳ２００においては、文字データ化されなかった領域の有無が判定される。すなわち、画像データとして残存している部分Ｂの有無が判定される。
【００３１】
ステップＳ２００にて画像データとして残存している部分があると判定された場合、ステップＳ１５０にてデータモードが画像データに指定されたと判定された場合、ステップＳ１７０にて文字像が存在しないと判定された場合のいずれにおいても少なくとも元データの一部が画像データとして扱われ、画像データのままアップロードされることとなる。しかしながら、アップロード先のブログ提供サーバ４０の形式要件によっては、画像データのアップロードが許容されない場合がある。そこで、ステップＳ２１０においては、形式要件取得部Ｐ１ｃがステップＳ１０５にて取得した形式要件において画像データのアップロードが許容されているかどうかを判定する。そして、許容されていない場合には、ステップＳ２２０，Ｓ２３０にて文字認識部Ｐ１ｄが画像データを強制的に文字データに変換する。
【００３２】
図９は、ステップＳ２２０，Ｓ２３０における文字データ変換を模式的に示している。同図に示すように、ステップＳ２２０においては画像データにおける中間階調の有無にかかわらず画像データを格子状に区切ることにより複数の強制ブロックを生成する。ステップＳ１８０，Ｓ１９０においては、まず文字像の有無を検出し、文字像に該当する部分についてのみパターンマッチングのブロックを設定したが、ステップＳ２２０においては文字像の有無や位置にかかわらず全領域について均一にブロックを設定する。そして、各ブロックの輝度分布と文字とのパターンマッチングを順次行い、各ブロックに対応する文字コードを特定していく。ステップＳ２３０では、各ブロックの画像データにおける相対位置に基づいて文字コードを配列することにより文字データを作成する。このとき高さ方向の配列を表現するために改行コードが挿入される。
【００３３】
図１０においては、図９に示した画像データが強制的に変換された文字データを示している。同図において、各ブロックの対応位置に各ブロックの輝度に応じた文字が配列されている。このようにすることにより、画像データをアップロードできないブログ提供サーバ４０，４０，４０に対しても画像データの情報を完全に失うことなくアップロードを行うことができる。なお、図１０の例ではアスキー文字とパターンマッチングさせたものを例示しているが、文字データに使用される文字はこれに限定されるものではない。
【００３４】
ステップＳ２１０にて画像データのアップロードが許容されると判定した場合、ステップＳ２４０にてデータ形式の判定を行う。すなわち、現在の画像データがアップロード先のブログ提供サーバ４０が受け入れ可能な画像データのデータ形式に適合しているかどうかを判定する。予め送信先のブログ提供サーバ４０の形式要件がステップＳ１０５にて取得されているため、その形式要件と画像データの拡張子を比較することにより適合性を判断することができる。そして、データ形式が適合しない場合には、ステップＳ２５０にて画像変換部Ｐ１ｆがデータ形式の変換を行う。例えば、メモリカードから取得した元データがビットマップ形式であり、送信先のブログ提供サーバ４０がＪＰＥＧ形式を要求する場合には、ステップＳ２５０ではビットマップ形式の画像データをＪＰＥＧ圧縮することによりＪＰＥＧ形式に変換する。
【００３５】
ステップＳ２６０においては、画像データのデータ量が送信先のブログ提供サーバ４０における画像データの制限データ量に適合しているかどうかを判定する。ここでも予め送信先のブログ提供サーバ４０の形式要件がステップＳ１０５にて取得されているため、その形式要件における制限データ量と画像データのサイズとを比較することができる。そして、画像データが制限データ量を超えていれば、画像変換部Ｐ１ｆがステップＳ２７０にてデータ量の削減を行う。例えば、画像のサイズを縮小することによる画素数の減少によってデータ量の削減を図ってもよいし、階調数を減少させることによりデータ量の削減を図ってもよい。ＥＸＩＦ形式の画像データのサイズを縮小する場合において、縮小倍率が高いとヘッダに添付されたサムネイルの方が良好な画質となることもある。従って、ＥＸＩＦ形式の画像データを縮小する場合には、ある縮小倍率を閾値として、本体の画像データの縮小画像を出力するか、サムネイルを出力するかを切り換えることが望ましい。以上の処理によって画像データを適式なものに変換することができる。
【００３６】
ステップＳ２８０においては、ステップＳ１３０にて取得した文字データと、ステップＳ１９０で生成した文字データと、ステップＳ２３０で生成した文字データが制限文字数を超えているかどうかを判定する。予め送信先のブログ提供サーバ４０の形式要件がステップＳ１０５にて取得されているため、その形式要件における制限文字数と各文字データの文字数とを比較することができる。なお、単一のアップロード処理においてステップＳ１９０とステップＳ２３０の双方から文字データが生成される場合があるが、この場合は双方の文字データの文字数を合算して制限文字数との比較を行う。また、画像モードを指定した場合など、ステップＳ１３０，Ｓ１９０，Ｓ２３０のいずれにおいても文字データが得られない場合もあるが、この場合には文字数が０とされ、制限文字数を超えることはない。
【００３７】
文字データが制限文字数を超えていた場合には、ステップＳ２９０にて文章要約部Ｐ１ｅが文章を要約する。ステップＳ１３０にて取得した文字データと、ステップＳ１９０で生成した文字データについては何らかの文章を構成する可能性があるため、これらについては文章要約部Ｐ１ｅが文字データを複数の単語群に分解する。そして、単語辞書１３ｄを参照して各単語の品詞と重要度を取得する。なお、単語辞書１３ｄは各単語について品詞と重要度を定義したデータベースである。品詞の配列から最低限文章が成立するために必要な単語を保持しつつ、重要度の低い単語を順に削除していく。削除するか否かを決定する重要度の閾値は、元の文字数と制限文字数との差分によって定められる。一方、ステップＳ２３０にて生成した文字データについては、奇数行あるいは偶数行のみを削除したり、奇数列あるいは偶数列の文字を削除したりして、均一に文字を間引けばよい。
【００３８】
ステップＳ３００においては、以上のようにして編集された文字データと画像データを組み合わせることによりアップロードデータ１３ｂを作成する。本実施形態ではＨＴＭＬファイルを利用したアップロードデータ１３ｂを作成するものとする。ＨＴＭＬファイルにおいては、必要なヘッダやフッタとともに文字データの内容を記述（複製）するとともに、画像データを埋め込むためのイメージタグを記述する。その際に、イメージタグに記述したファイル名と同一のファイル名を画像データに付与するとともに、イメージタグに記述したパスに画像データを保存する。そして、ＨＴＭＬファイルと画像データをひとまとめにすることによりアップロードデータ１３ｂを作成する。
【００３９】
このようにすることにより、文字データと画像データとが組み込まれたアップロードデータ１３ｂを作成することができる。むろん、ステップＳ２９０までの処理で画像データのみが得られた場合にはヘッダやフッタ以外にイメージタグのみが記述される。反対に、文字データのみが得られた場合にはイメージタグは記述されない。複数の文字データが得られた場合には、各文字データ（複製）の内容をアップロードデータ１３ｂにおいて順に記述していく。なお、アップロードデータ１３ｂが作成された段階において、操作パネル１９を利用して同アップロードデータ１３ｂの編集ができるようにしてもよい。例えば、文章を追加したり、不要な文章や画像を削除したりできるようにしてもよい。
【００４０】
以上のようにしてアップロードデータ１３ｂを作成することにより、送信先のブログ提供サーバ４０が要求する各形式要件を満足させることができる。ユーザーが送信先のブログ提供サーバ４０が要求する各形式要件を調査し、その条件を満足するように元データを編集しなくても済むため、知識の少ないユーザーでも容易にアップロードを行うことができる。サーバＤＢ１３ｃには複数の送信先についての形式要件を記憶するため、各送信先に応じて適切なアップロードデータ１３ｂを作成することができる。また、スキャナにてスキャンした文書についてもアップロードを行うことができるため、手書きの文書や印刷された文書もアップロードすることができる。従って、操作パネル１９を用いて文章の入力をする必要がなく、容易に文章をアップロードすることができる。特に、ＭＰＦ１０においては操作パネル１９の設置スペースが限られるため、ユーザーが文章を入力しやすい操作パネル１９の設置は困難である。
【００４１】
また、データモードを指定可能としたため、スキャナでスキャンした文書についてアップロードする場合に、画像データのままアップロードするのか、文字データに変換してから送信するのかを設定することができるため、ユーザーの意向に添ったアップロード結果とすることができる。例えば、写真と手書き文とが混在する文書をアップロードする際に、手書き文の書体等をそのまま維持して投稿したいと思う場合もあるし、データ量を極力節約したいと思う場合もある。このような場合も、データモードを設定可能とすることにより、ユーザーの意向に柔軟に対応することができる。さらに、送信先のブログ提供サーバ４０が画像データを受け付けない場合には、写真等の画像を強制的に文字データに変換するため、無駄に画像データを送信することが防止できるとともに、画像をブログ上にて表現することができる。
【００４２】
図５のステップＳ３１０においては、作成したアップロードデータ１３ｂに対してブログ提供サーバ４０にアップロード要求するためのコマンドを添付する。ここでは、ブログ提供サーバ４０にアップロード要求するために必要なユーザーＩＤやパスワードもステップＳ１０５にて取得した形式要件に基づいて記述される。ステップＳ３２０においては、通信部Ｐ１ｇがアップロードデータ１３ｂをＬＡＮＩ／Ｆ１７とＷＡＮＩ／Ｆ２０とインターネット３０を介して指定したブログ提供サーバ４０に送信する。ここでもステップＳ１０５にて取得した形式要件によって送信先のＵＲＬを特定することができるため、通信部Ｐ１ｇがインターネット３０上のあて先を指定することができる。以上の処理によってアップロードの要求が完了する。これにより、アップロードデータ１３ｂを受け付けたブログ提供サーバ４０においてはアップロードデータ１３ｂを既存の閲覧データに結合させる。これにより、既存のブログに今回送信したアップロードデータ１３ｂを追記することができる。なお、閲覧データはブログ提供サーバ４０において公衆に閲覧可能とされている。
【００４３】
ステップＳ３３０においては、通信部Ｐ１ｇがブラウザを起動し、同ブラウザにてアップロード後の閲覧データをダウンロードする。ステップＳ３４０においては、ステップＳ１０５においてユーザーによる確認画像の出力先の指定を受け付けているため、その指定がプリンタとディスプレイのいずれであるかを判断することができる。ディスプレイが指定されていた場合には、ステップＳ３５０にてブラウザがディスプレイ１８にて閲覧データを再生する。一方、プリンタが指定されていた場合には、ステップＳ３６０にてブラウザがプリンタドライバＰ３に閲覧データを受け渡す。プリンタドライバＰ３では印刷に必要な処理を行い、プリンタユニット１６にて印刷を行う。いずれにおいてもユーザーがアップロード後の出来映えを確認することができる。また、ユーザーがディスプレイとプリンタのいずれかを選択することができるため、例えば一般的なパーソナルコンピュータにて表示させたときの態様と近い出力状態となる方を選択することができる。むろん、ディスプレイ１８における表示と印刷を双方とも行ってもよい。
【００４４】
ステップＳ３７０においては、ＵＩ部Ｐ１ａが所定のＵＩ画像をディスプレイ１８に表示させ、ユーザーがアップロード後の状態に満足するか否かを問い合わせる。ユーザーが操作パネル１９にて満足する旨の操作をした場合にはそのまま処理を終了させ、満足しない旨の操作をした場合には直前にアップロードした内容を削除する要求を通信部Ｐ１ｇがブログ提供サーバ４０に送信する。そして、ステップＳ１００に戻り、再度、各種設定をユーザーから受け付けることとなる。これにより、満足するアップロード結果が得られるまで設定の最適化を行うことが可能となる。
【００４５】
本実施形態においては、ブログをアップロード対象としたが、本発明を掲示板やメーリングリストへのアップロードに適用することも可能である。現在のところ画像データがアップロードできる掲示板は希である。そのため、サーバＤＢ１３ｃの形式要件において画像データのアップロードを不可と登録しておけば、常に文字データのみのアップロードデータ１３ｂを作成することができ、掲示板へのアップロードも可能なる。元の文書に写真等の画像が含まれていた場合であっても、画像を強制的に文字データに変換することができるため、従来アップロードできなかった画像についても掲示板へアップロードすることが可能となる。一方、メーリングリストの場合には、メーラの機能を備えさせ、メール形式のアップロードデータ１３ｂを作成するようにすればよい。いずれにしても、初心者のユーザーが容易にサービスを提供するサーバの要求を満足するアップロードデータ１３ｂを作成することができる。
【００４６】
（３）まとめ：
ブログ提供サーバ４０が要求する形式要件を予めサーバＤＢ１３ｃに記憶しておき、アップロードを行う際にはアップロード先として指定されたブログ提供サーバ４０の形式要件を取得する。そして、取得された形式要件に応じて、画像データのデータ量の削減や、画像データの文字データ化や、文字データの要約を行う。これにより、ユーザーが送信先のブログ提供サーバ４０が要求する各形式要件を調査し、その条件を満足するように元データを編集しなくても済むため、知識の少ないユーザーでも容易にアップロードを行うことができる。
【図面の簡単な説明】
【００４７】
【図１】ＭＦＰのハードウェア構成図である。
【図２】ＭＦＰの外観斜視図である。
【図３】プログラムのソフトウェア構成図である。
【図４】アップロード要求処理の流れを示すフローチャートである。
【図５】アップロード要求処理の流れを示すフローチャートである。
【図６】ＵＩ画像を示す図である。
【図７】サーバＤＢを示す図である。
【図８】文書の一例を示す図である。
【図９】画像データを文字データに変換する様子を示す図である。
【図１０】画像データから変換した文字データを示す図である。
【符号の説明】
【００４８】
１０…ＭＦＰ，１０ａ…バス，１１…ＣＰＵ，１２…ＲＡＭ，１３…ＨＤＤ，１３ａ…プログラムデータ，１３ｂ…アップロードデータ，１３ｃ…サーバＤＢ，１３ｄ…単語辞書，１４…ＭＣＳ，１５…スキャナユニット，１６…プリンタユニット，１７…ＬＡＮＩ／Ｆ，１８…ディスプレイ，１９…操作パネル，２０…ＷＡＮＩ／Ｆ，３０…インターネット，４０…ブログ提供サーバ，Ｐ１…アップロード要求プログラム，Ｐ１ａ…ＵＩ部，Ｐ１ｂ…元データ取得部，Ｐ１ｃ…形式要件取得部，Ｐ１ｄ…文字認識部，Ｐ１ｅ…文章要約部，Ｐ１ｆ…画像変換部，Ｐ１ｇ…通信部，Ｐ２…スキャナドライバ，Ｐ３…プリンタドライバ
【図１】
2007280105.tif 000003
【図２】
2007280105.tif 000004
【図３】
2007280105.tif 000005
【図４】
2007280105.tif 000006
【図５】
2007280105.tif 000007
【図６】
2007280105.tif 000008
【図７】
2007280105.tif 000009
【図８】
2007280105.tif 000010
【図９】
2007280105.tif 000011
【図１０】
2007280105.tif 000012