JP2012113533A - 画像取込システム及びこのシステムのサーバとクライアント、並びに画像取込プログラム - Google Patents

Abstract

【課題】ネットワークの負荷軽減と、画像処理端末のリソースの節約を図る。
【解決手段】記憶媒体５，６から画像ファイルを取り込むためのクライアント２と、このクライアント２に画像取込プログラムをダウンロードするサーバ１とを備えた画像取込システムにおいて、クライアント２は、記憶媒体から画像ファイルを取り込む機能と、取り込んだ画像ファイルの用途選択を受付ける機能と、選択を受付けた用途に応じた画像のサイズを画像取込プログラムから検出する機能と、取り込んだ画像ファイルの画像データを、検出したサイズの画像データに変更する機能と、画像データのサイズが変更された画像ファイルをサーバ１にアップロードする機能とを備える。サーバ１は、クライアント２からアップロードされる画像ファイルを、画像データベース７で蓄積する。
【選択図】 図１

Description

本発明の実施形態は、記憶媒体から画像ファイルを取り込むためのクライアントとこのクライアントによって取り込まれた画像ファイルを蓄積するサーバとを備えた画像取込システム、及びこのシステムのクライアントとサーバ、並びに前記クライアントに画像ファイルの取込処理を実現させるための画像取込プログラムに関する。

例えば飲食店に導入される電子メニュー端末は、種々の料理メニュー品目の画像を一覧にしたメニュー画面をディスプレイに表示する。この種の電子メニュー端末は、メニュー画面を作成するためのアプリケーションプログラムを実装している。ネットワークで接続されたサーバから各メニュー品目の画像を受信すると、電子メニュー端末は、前記プログラムに従いメニュー画面を作成する。

各メニュー品目の画像は、例えばデジタルカメラで撮影する。サーバは、デジタルカメラで撮影された画像を取り込むためのパーソナルコンピュータ、いわゆるパソコンを、クライアントとしてネットワークで接続している。パソコンによって取り込まれた撮影画像のデータは、画像ファイルの形式でサーバにアップロードされる。

ところで、昨今のデジタルカメラは、高性能化に伴い、撮影画像の画素数が増えている。その一方で、例えばメニュー画面は、料理メニュー品目の画像を一覧にして表示するため、画素数の少ない低画質の画像で十分である。そこで従来は、電子メニュー端末がメニュー画面作成用のアプリケーションプログラムに従いサーバから受信した画像データを縮小する。そして電子メニュー端末は、縮小された画像データを用いてメニュー画面を作成し、ディスプレイに表示させていた。

特開２００２−２２９９０１号公報

従来のシステムは、クライアントによって取り込まれたデータサイズの大きい画像ファイルを、そのままサーバにネットワークを介してアップロードする。サーバは、クライアントからアップロードされた画像ファイルを、そのままネットワークを介して画像処理端末、例えば電子メニュー端末に配信する。画像処理端末は、サーバから配信された画像ファイルのデータを用途に応じたサイズに縮小して画面を作成し、ディスプレイに表示する。

したがって、従来のシステムにおいては、クライアントとサーバとの間で、データサイズの大きい画像ファイルが送受信される。このため、ネットワークの負荷が大きい。また、画像処理端末側で画像データのサイズ変更が行われる。このため、画像処理端末のリソースが大きく消費される。

このような課題を解決するために、一実施形態によれば、外部から画像ファイルを取り込む取込手段を備えたクライアントが、さらに、取込手段により取り込んだ画像ファイルの用途選択を受付ける用途受付手段と、この用途受付手段により選択を受付けた用途に応じた画像のサイズを、サーバからダウンロードされた画像取込プログラムから検出する画像サイズ検出手段と、取込手段により取り込んだ画像ファイルの画像データを、画像サイズ検出手段により検出したサイズの画像データに変更するサイズ変更手段と、このサイズ変更手段により画像データのサイズが変更された画像ファイルをサーバにアップロードする送信手段とを備える。

第１，第２の実施形態のシステム構成図。 第１，第２の実施形態において、電子メニュー端末のディスプレイに表示される画面の遷移例を示す図。 第１，第２の実施形態において、クライアントの要部構成を示すブロック図。 同クライアントのソフトウェア構成図。 第１，第２の実施形態において、サーバの要部構成を示すブロック図。 同サーバがクライアントにダウンロードする画像取込プログラムを示す模式図。 第１，第２の実施形態において、サーバのＣＰＵが実行する画像取込支援処理の要部を示す流れ図。 第１の実施形態において、画像取込プログラムによって制御される画像ファイル取込処理の要部手順を示す流れ図。 第２の実施形態において、画像取込プログラムによって制御される画像ファイル取込処理の要部手順を示す流れ図。

以下、電子メニュー端末で表示する画像を取り込む画像取込システムの実施形態を、図面を用いて説明する。

（第１の実施形態）
図１は、本実施形態のシステム構成図である。本システムは、サーバ１と、クライアント２とを、インターネット等のネットワーク４で接続する。ネットワーク４には、画像処理端末の一態様として複数の電子メニュー端末３が接続される。

クライアント２は、フラッシュメモリ５またはＵＳＢ（Universal Serial Bus）メモリ６等の記憶媒体から、画像データを、ジェイペグ（ＪＰＥＧ）、ティフ（ＴＩＦ）、ビットマップ（ＢＭＰ）等のファイル形式で取り込む。クライアント２は、記憶媒体から取り込んだ画像ファイルを、ネットワーク４を介してサーバにアップロードする。

サーバ１は、クライアント２からアップロードされる画像ファイルを、画像蓄積手段としての画像データベース７に蓄える。サーバ１は、画像データベース７に蓄積した画像ファイルを、ネットワーク４を介して各電子メニュー端末３に配信する。

なお、本実施形態では、サーバ１とクライアント２とを接続するネットワークと、サーバ１と各電子メニュー端末３とを接続するネットワーク４を、同一のネットワーク４として説明するが、別々のネットワークであってもよい。

各電子メニュー端末３は、前記サーバ１から配信される画像ファイルの画像データを用いて種々の画面を作成するためのアプリケーションプログラムを実装する。このプログラムは、予め各電子メニュー端末３にインストールされていてもよいし、サーバ１からネットワーク４を介してダウンロードしてもよい。

図２は、電子メニュー端末３のディスプレイに表示される画面の遷移例である。同図において、上からカテゴリ選択画面１１、メニュー選択画面１２及び注文確認画面１３を示す。なお、各画面１１，１２，１３のレイアウトは、あくまでも一例であり、図２に示すものに限定されるものではない。また、電子メニュー端末３のディスプレイに表示される画面は、これらの画面１１〜１３に限定されるものでもない。

カテゴリ選択画面１１は、料理メニュー品目を分類するカテゴリの一覧をボタン形式で表示する。カテゴリ別のボタン１１-ｉ（ｉ＝１，２，３，…，６）には、そのカテゴリに属する代表的な料理メニュー品目の画像が表示される。入力デバイスの操作入力によりいずれか１つのカテゴリボタン１１-iが選択されると、電子メニュー端末３は、ディスプレイの画面をメニュー選択画面１２に切り替える。入力デバイスは、例えばキーボード、マウス、タッチパネル等である。

メニュー選択画面１２は、カテゴリ選択画面１１で選択されたカデゴリに属する料理メニュー品目の一覧を、ボタン形式で表示する。メニュー品目別のボタン１２-j（ｊ＝１，２，３，…，１６）には、そのメニュー品目の画像が表示される。前記入力デバイスの操作入力によりいずれか１つのメニューボタン１２-jが選択されると、電子メニュー端末３は、ディスプレイの画面を注文確認画面１３に切り替える。

注文確認画面１３は、メニュー選択画面１２で選択された料理メニュー品目の詳細画像１３Ａを表示する。また、注文確認画面１３は、注文ボタン１３Ｂと取消ボタン１３Ｃとを表示する。前記入力デバイスの操作入力により注文ボタン１３Ｂが選択されると、詳細画像１３Ａが表示された料理メニュー品目の注文が確定する。これに対し、取消ボタン１３Ｃが選択された場合には、当該料理メニュー品目の注文が取消される。注文ボタン１３Ｂまたは取消ボタン１３Ｃが選択されると、電子メニュー端末３は、ディスプレイの画面をカテゴリ選択画面１１に戻す。

ここで、各画面１１，１２，１３にそれぞれ表示される画像のデータサイズは、メニュー選択画面１２の各メニューボタン１２-jに表示される料理メニュー品目の画像が最も小さく、注文確認画面１３に表示される詳細画像１３Ａが最も大きい。例えば、メニュー選択画面１２の画像は１６０×１２０画素であり、カテゴリ選択画面１１の画像は４００×３００画素であり、注文確認画面１３の詳細画像１３Ａは８００×６００画素である。

図３は、クライアント２の要部構成を示すブロック図である。クライアント２は、ＣＰＵ（Central Processing Unit）３１、ＲＯＭ（Read Only Memory）３２、ＲＡＭ（Random Access Memory）３３、ＨＤＤ（Hard Disk Drive）３４、通信インターフェース３５、キーボードコントローラ３６、表示コントローラ３７、マウスインターフェース３８、メモリカードインターフェース３９及びＵＳＢインターフェース４０を搭載している。ＣＰＵ３１と、他の各部３２〜４０とは、アドレスバス，データバス等のバスライン４１で接続している。

ＣＰＵ３１は、オペレーティングシステム、ミドルウェアおよびアプリケーションプログラムに基づいて、クライアント２としての動作を実現するべく各部３２〜４０を制御する。

ＲＯＭ３２は、上記のオペレーティングシステムを記憶する。ＲＯＭ３２は、上記のミドルウェアやアプリケーションプログラムを記憶する場合もある。またＲＯＭ３２は、ＣＰＵ３１が各種の処理を行う上で参照するデータを記憶する場合もある。

ＲＡＭ３３は、ＣＰＵ３１が各部３２〜４０を制御する上で参照するデータを記憶する。さらにＲＡＭ３３は、ＣＰＵ３１が各部３２〜４０を制御する上で一時的に使用するデータを記憶するための領域、いわゆるワークエリアとして利用される。またＲＡＭ３３は、上記のミドルウェアやアプリケーションプログラムを記憶する場合もある。

ＨＤＤ３４は、ＣＰＵ３１が各部３２〜４０を制御する上で使用するデータや、ＣＰＵ３１の制御によって生成されたデータを保存する。またＨＤＤ３４は、上記のミドルウェアやアプリケーションプログラムを記憶する場合もある。

通信インターフェース３５は、ネットワーク４を介して接続されるサーバ１との間で行うデータ送受信の通信手順を司る。キーボードコントローラ３６は、入力デバイスであるキーボード４２を制御する。表示コントローラ３７は、表示デバイスであるディスプレイ４３の画像表示を制御する。マウスインターフェース３８は、入力デバイスであるマウスを電気的に接続可能である。

メモリカードインターフェース３９は、前記フラッシュメモリ５に記憶されるデータの読取り、及びフラッシュメモリ５へのデータの書込みを行う。ＵＳＢインターフェース４０は、前記ＵＳＢメモリ６に記憶されるデータの読取り、及びＵＳＢメモリ６へのデータの書込みを行う。

図４は、上記クライアント２のソフトウェア構成図である。クライアント２は、オペレーティングシステム（ＯＳ）５１と、ウェブ（Ｗｅｂ）ブラウザ５２を含む複数のアプリケーションプログラム（ＡＰＬ）と、アプリケーションフレームワーク５３を含む複数のミドルウェアとで、ソフトウェアを構成する。

ウェブブラウザ５２は、インターネット上のウェブページを閲覧するためのソフトウェアである。アプリケーションフレームワーク５３は、上記ウェブブラウザ５２のプラグイン形式で提供され、ウェブブラウザ５２上で画像の再生や動的な処理を実現する。このようなアプリケーションフレームワークには、例えばSilverlight（シルバーライト：登録商標）がある。

図５は、サーバ１の要部構成を示すブロック図である。サーバ１は、ＣＰＵ６１、ＲＯＭ６２、ＲＡＭ６３、通信インターフェース６４及び補助記憶装置６５を搭載している。ＣＰＵ６１と、他の各部６２〜６５とは、アドレスバス，データバス等のバスライン６６で接続している。

ＣＰＵ６１は、オペレーティングシステム、ミドルウェアおよびアプリケーションプログラムに基づいて、サーバ１としての動作を実現するべく各部６２〜６５を制御する。

ＲＯＭ６２は、上記のオペレーティングシステムを記憶する。ＲＯＭ６２は、上記のミドルウェアやアプリケーションプログラムを記憶する場合もある。またＲＯＭ６２は、ＣＰＵ６１が各種の処理を行う上で参照するデータを記憶する場合もある。

ＲＡＭ６３は、ＣＰＵ６１が各部６２〜６５を制御する上で参照するデータを記憶する。さらにＲＡＭ６３は、ＣＰＵ６１が各部６２〜６５を制御する上で一時的に使用するデータを記憶するための領域、いわゆるワークエリアとして利用される。またＲＡＭ６３は、上記のミドルウェアやアプリケーションプログラムを記憶する場合もある。

通信インターフェース６４は、ネットワーク４を介して接続されるクライアント２及び各電子メニュー端末３との間で行うデータ送受信の通信手順を司る。

補助記憶装置６５は、前記画像データベース７を含む種々のデータベースを保存するデータベース領域６５Ａと、画像取込プログラムＰ１を含む種々のアプリケーションプログラムを保存するプログラムファイル領域６５Ｂとを有する。ＨＤＤやＳＳＤ（solid state drive）等が、補助記憶装置６５として用いられる。

画像取込プログラムＰ１は、クライアント２において実行される画像ファイルの取込処理を制御するものである。このプログラムＰ１は、図６に示すように、カテゴリ画面用画像サイズとメニュー画面用画像サイズと注文確認画面用画像サイズの各データを組み込んでいる。カテゴリ画面用画像サイズは、カテゴリ選択画面１１で使用する画像ファイルのデータサイズ（例えば４００×３００画素）である。メニュー画面用画像サイズは、メニュー選択画面１２で使用する画像ファイルのデータサイズ（例えば１６０×１２０画素）である。注文確認画面用画像サイズは、注文確認画面１３で使用する画像ファイルのデータサイズ（８００×６００画素）である。

かかる構成のサーバ１は、ＳｓｓＳ［Software as a Service］によってウェブベースのアプリケーションプログラム（この場合は、画像取込プログラムＰ１）をクライアント２に提供することで、クライアント２において実行される画像ファイルの取込処理を支援する。

図７は、サーバ１のＣＰＵ６１が実行する画像取込支援処理の要部を示す流れ図である。ＣＰＵ６１は、クライアント２からの要求コマンドの有無を判断する（ＳＴ１）。要求コマンドが無い場合（ＳＴ１のＮＯ）、ＣＰＵ６１は、要求コマンドがあるまで待機する。

ネットワーク４を介してクライアント２からの要求コマンドを受信すると（ＳＴ１のＹＥＳ）、ＣＰＵ６１は、そのコマンドが画像取込要求のコマンドなのか否かを判断する（ＳＴ２）。画像取込要求以外のコマンドである場合（ＳＴ２のＮＯ）、ＣＰＵ６１は、要求内容に応じた処理を実行する。

ネットワーク４を介してクライアント２から画像取込要求のコマンドを受信すると（ＳＴ２のＹＥＳ）、ＣＰＵ６１は、前記画像取込プログラムＰ１をプログラムファイル領域６５Ｂから読み出す。そしてＣＰＵ６１は、このプログラムＰ１を、ネットワーク４を介してクライアント２にダウンロードする（ＳＴ３）。

ＣＰＵ６１は、データベース領域６５Ａの画像データベース７をオープンする（ＳＴ４）。そしてＣＰＵ６１は、画像ファイルを受信したか否かを判断する（ＳＴ５）。画像ファイルを受信していない場合（ＳＴ５のＮＯ）、ＣＰＵ６１は、終了コマンドを受信したか否かを判断する（ＳＴ６）。終了コマンドを受信していない場合（ＳＴ６のＮＯ）、ＣＰＵ６１は、画像ファイルまたは終了指示の受信を待機する。

ネットワーク４を介してクライアント２から画像ファイルを受信すると（ＳＴ５のＮＯ）、ＣＰＵ６１は、この受信した画像ファイルを画像データベース７に保存する（ＳＴ７）。

ネットワーク４を介してクライアント２から終了コマンドを受信すると（ＳＴ６のＹＥＳ）、ＣＰＵ６１は、前記画像データベース７をクローズする（ＳＴ８）。以上で、ＣＰＵ６１は、今回の画像取込支援処理を終了する。

図８は、画像取込プログラムＰ１によって制御される画像ファイル取込処理の要部手順を示す流れ図である。クライアント２のユーザが、例えばキーボード４２を操作して、画像ファイルの取込開始を宣言すると、クライアント２のＣＰＵ３１は、ネットワーク４を介してサーバ１に画像取込要求のコマンドを送信する。このコマンドに応じて、サーバ１からクライアント２に画像取込プログラムＰ１がダウンロードされるので、ＣＰＵ３１は、画像取込プログラムＰ１を起動する。

画像取込プログラムＰ１が起動すると、ＣＰＵ３１は、図８の処理を開始する。先ず、ＣＰＵ３１は、記憶媒体から画像ファイルを取り込む（ＳＴ１１：取込手段）。例えば、メモリカードインターフェース３９にフラッシュメモリ５が接続されている場合には、ＣＰＵ３１は、このフラッシュメモリ５から画像ファイルを取り込む。ＵＳＢインターフェース３９にＵＳＢメモリ６が接続されている場合には、ＣＰＵ３１は、このＵＳＢメモリ６から画像ファイルを取り込む。

ＣＰＵ３１は、画像ファイルの取り込みを完了したか否かを判断する（ＳＴ１２）。取り込みを完了していない場合（ＳＴ１２のＮＯ）、ＣＰＵ３１は、取り込みが完了するのを待機する。

画像ファイルの取り込みが完了すると（ＳＴ１２のＹＥＳ）、ＣＰＵ３１は、ディスプレイ４３に用途選択画面を表示させる（ＳＴ１３：用途受付手段）。用途選択画面には、記憶媒体から取り込んだ画像ファイルの用途がカテゴリ画面用なのかメニュー画面用なのか注文確認画面用なのかをユーザに選択させるための情報が表示される。

ＣＰＵ３１は、用途が選択されたか否かを判断する（ＳＴ１４）。用途が選択されていない場合（ＳＴ１４のＮＯ）、ＣＰＵ３１は、業務終了が宣言されたか否かを判断する（ＳＴ１５）。業務終了が宣言されていない場合（ＳＴ１５のＮＯ）、ＣＰＵ３１は、用途が選択されるか業務終了が宣言されるのを待機する。

例えばキーボード４２の操作入力により、カテゴリ画面用、メニュー画面用及び注文確認画面用のうち、いずれか１つの用途が選択されると（ＳＴ１４のＹＥＳ）、ＣＰＵ３１は、画像取込プログラムＰ１からその選択された用途の画像サイズ情報（Ａ×Ｂ画素）を検出し、ＲＡＭ３３のワークエリアに記憶する（ＳＴ１６：画像サイズ検出手段）。

次に、ＣＰＵ３１は、ディスプレイ４３に画像選択画面を表示させる（ＳＴ１７）。画像選択画面には、ステップＳＴ１１の処理で記憶媒体から取り込んだ全ての画像ファイルの画像がサムネイル形式で表示される。

ＣＰＵ３１は、画像が選択されたか否かを判断する（ＳＴ１８）。画像が選択されていない場合（ＳＴ１８のＮＯ）、ＣＰＵ３１は、用途変更が宣言されたか否かを判断する（ＳＴ１９）。用途変更が宣言されていない場合（ＳＴ１９のＮＯ）、ＣＰＵ３１は、画像が選択されるか用途変更が宣言されるのを待機する。

例えばキーボード４２の操作入力により、いずれか１つのサムネイル画像が選択されると（ＳＴ１８のＹＥＳ）、ＣＰＵ３１は、その選択画像データを記憶する画像ファイルをＲＡＭ３３のワークエリアに複写する（ＳＴ２０：複写手段）。そしてＣＰＵ３１は、複写した画像ファイルの画像データを、ステップＳＴ１６の処理で記憶した画像サイズのデータに変更する（ＳＴ２１：サイズ変更手段）。

次いで、ＣＰＵ３１は、画像データのサイズを変更した画像ファイルのファイル名を、ステップＳＴ１４の処理で選択された用途に応じた固有の名称に変更する（ＳＴ２２：ファイル名変更手段）。例えば、選択用途がカテゴリ画面用の場合には“caregory-n”、メニュー画面用の場合には“menu-n”、注文確認画面用の場合には“order-n”（ｎは１から順次繰り上がる連続番号）とする。

しかる後、ＣＰＵ３１は、ファイル名を変更した画像ファイルを、ネットワーク４を介してサーバ１へ送信する（ＳＴ２３：送信手段）。そして送信後、ＣＰＵ３１は、画像選択画面から次の画像が選択されたか否かを判断する（ＳＴ１７）。次の画像が選択された場合（ＳＴ１７のＹＥＳ）、ＣＰＵ３１は、前述したステップＳＴ２０〜ＳＴ２３の処理を再度実行する。

画像が選択されず（ＳＴ１８のＮＯ）、用途変更が宣言された場合には（ＳＴ１９のＹＥＳ）、ＣＰＵ３１は、ディスプレイ４３の画面を用途選択画面に戻す（ＳＴ１３）。そしてＣＰＵ３１は、用途が選択されるか（ＳＴ１４）、業務終了が宣言されるのを待機する（ＳＴ１５）。

ここで、例えばキーボード４２の操作入力により、業務終了が宣言された場合（ＳＴ１５のＹＥＳ）、ＣＰＵ３１は、ネットワーク４を介してサーバ１に終了コマンドを送信する（ＳＴ２４）。以上で、画像取込プログラムＰ１が終了する。

今、フラッシュメモリ５またはＵＳＢメモリ６の記憶媒体に記憶された画像ファイルの画像データが、１６００×１２００画素の高解像度のデジタルカメラで撮影された料理メニュー品目のデータであると仮定する。また、図６に示すように、メニュー選択画面１２の画像は１６０×１２０画素であり、カテゴリ選択画面１１の画像は４００×３００画素であり、注文確認画面１３の詳細画像１３Ａは８００×６００画素であると仮定する。

この場合において、クライアント２のユーザが、画像ファイルの取込開始を宣言すると、記憶媒体の画像ファイルがクライアント２に取り込まれる。また、クライアント２のディスプレイに用途選択画面が表示される。

ユーザが、用途として“カテゴリ画面用”を選択すると、ディスプレイが画像選択画面に切り換わる。そこでユーザは、カテゴリ選択画面１１に用いる料理メニュー品目の画像を選択する。そうすると、クライアント２では、選択画像の画像ファイルが複写される。そして、この複写された画像ファイルの画像データが、１６００×１２００画素の画像から４００×３００画素の画像に縮小される。また、複写された画像ファイルのファイル名が“caregory-１”に変更される。そして、このファイル名“caregory-１”の画像ファイルがサーバ１にアップロードされて、画像データベース７に保存される。

次に、ユーザが、カテゴリ選択画面１１に用いる他の料理メニュー品目の画像を選択すると、クライアント２では、上記と同様な処理が実行される。その結果、４００×３００画素に縮小された画像データを記憶するファイル名“caregory-２”の画像ファイルがサーバ１にアップロードされて、画像データベース７に保存される。

以後、ユーザが料理メニュー品目を選択する毎に、クライアント２では同様な処理が実行される。こうして、カテゴリ選択画面１１に用いる画像の選択を終了すると、ユーザは、用途の変更を宣言する。そうすると、ディスプレイ４３の画面が用途選択画面に戻るので、ユーザは、次に、用途として例えば“メニュー画面用”を選択する。そうすると、ディスプレイが画像選択画面に切り換わるので、ユーザは、メニュー選択画面１２に用いる料理メニュー品目の画像を選択する。そうすると、クライアント２では、選択画像の画像ファイルが複写される。そして、この複写された画像ファイルの画像データが、１６００×１２００画素の画像から１６０×１２０画素の画像に縮小される。また、複写された画像ファイルのファイル名が“menu-１”に変更される。そして、このファイル名“menu -１”の画像ファイルがサーバ１にアップロードされて、画像データベース７に保存される。

次に、ユーザが、メニュー選択画面１２に用いる他の料理メニュー品目の画像を選択すると、クライアント２では、上記と同様な処理が実行される。その結果、１６０×１２０画素に縮小された画像データを記憶するファイル名“menu -２”の画像ファイルがサーバ１にアップロードされて、画像データベース７に保存される。

以後、ユーザが料理メニュー品目を選択する毎に、クライアント２では同様な処理が実行される。こうして、メニュー選択画面１２に用いる画像の選択を終了すると、ユーザは、再び用途の変更を宣言する。そうすると、ディスプレイ４３の画面が用途選択画面に戻るので、ユーザは、次に、用途として例えば“注文確認画面用”を選択する。そうすると、ディスプレイが画像選択画面に切り換わるので、ユーザは、注文確認画面１３に用いる料理メニュー品目の画像を選択する。そうすると、クライアント２では、選択画像の画像ファイルが複写される。そして、この複写された画像ファイルの画像データが、１６００×１２００画素の画像から８００×６００画素の画像に縮小される。また、複写された画像ファイルのファイル名が“order-１”に変更される。そして、このファイル名“order-１”の画像ファイルがサーバ１にアップロードされて、画像データベース７に保存される。

次に、ユーザが、注文確認画面１３に用いる他の料理メニュー品目の画像を選択すると、クライアント２では、上記と同様な処理が実行される。その結果、８００×６００画素に縮小された画像データを記憶するファイル名“order-２”の画像ファイルがサーバ１にアップロードされて、画像データベース７に保存される。

以後、ユーザが料理メニュー品目を選択する毎に、クライアント２では同様な処理が実行される。こうして、注文確認画面１３に用いる画像の選択を終了すると、ユーザは、業務終了を宣言する。

かくして、サーバ１の画像データベース７には、４００×３００画素の料理メニュー品目画像を記憶したファイル名“caregory-n”の画像ファイルと、１６０×１２０画素の料理メニュー品目画像を記憶したファイル名“menu-n”の画像ファイルと、８００×６００画素の料理メニュー品目画像を記憶したファイル名“order-n”の画像ファイルとが蓄積される。

これらの画像ファイルは、ネットワーク４を介して各電子メニュー端末３に配信される。電子メニュー端末３においては、ファイル名“caregory-n”の画像ファイルに記憶された料理メニュー品目の画像データに基づいて、カテゴリ選択画面１１が作成される。また、ファイル名“menu-n”の画像ファイル画像ファイルに記憶された料理メニュー品目の画像データに基づいて、メニュー選択画面１２が作成される。さらに、ファイル名“order-n”の画像ファイルに記憶された料理メニュー品目の画像データに基づいて、注文確認画面１３が作成される。

このように、クライアント２は、記憶媒体５，６から取り込んだ高解像度の画像データを、任意に選択された用途に応じた低解像度の画像データに縮小してからサーバ１にアップロードしている。また、サーバ１は、クライアント２から受信した低解像度の画像データを画像データベース７に蓄積し、必要に応じて各電子メニュー端末３に配信している。したがって、クライアント２とサーバ１との間、及び、サーバ１と各電子メニュー端末３との間のネットワーク４の負荷を軽減できる。また、各電子メニュー端末３は、サーバ１から受信した画像データのサイズを変更する必要が無いので、リソースを大きく消費することはない。

（第２の実施形態）
第２の実施形態は、画像取込プログラムＰ１によって制御される画像ファイル取込処理の手順の一部が異なる。第２の実施形態における画像ファイル取込処理の要部手順を、図９の流れ図で示す。

図９に示すように、画像取込プログラムＰ１が起動すると、ＣＰＵ３１は、記憶媒体から画像ファイルを取り込む（ＳＴ３１：取込手段）。画像ファイルの取り込みが完了すると（ＳＴ３２のＹＥＳ）、ＣＰＵ３１は、画像選択画面を表示させる（ＳＴ３３）。そしてＣＰＵ３１は、画像が選択されたか否かを判断する（ＳＴ３４）。画像が選択されていない場合（ＳＴ３４のＮＯ）、ＣＰＵ３１は、業務終了が宣言されたか否かを判断する（ＳＴ３５）。業務終了が宣言されていない場合（ＳＴ３５のＮＯ）、ＣＰＵ３１は、画像が選択されるか業務終了が宣言されるのを待機する。

例えばキーボード４２の操作入力により、いずれか１つのサムネイル画像が選択されると（ＳＴ３４のＹＥＳ）、ＣＰＵ３１は、その選択画像データを記憶する画像ファイルをＲＡＭ３３のワークエリアに複写する（ＳＴ３６：複写手段）。

次に、ＣＰＵ３１は、ディスプレイ４３に用途選択画面を表示させる（ＳＴ３７：用途受付手段）。そしてＣＰＵ３１は、用途が選択されたか否かを判断する（ＳＴ３８）。用途が選択されていない場合（ＳＴ３８のＮＯ）、ＣＰＵ３１は、用途が選択されるのを待機する。

例えばキーボード４２の操作入力により、いずれか１つの用途が選択されると（ＳＴ３８のＹＥＳ）、ＣＰＵ３１は、画像取込プログラムＰ１からその選択された用途の画像サイズ情報（Ａ×Ｂ画素）を検出し、ＲＡＭ３３のワークエリアに記憶する（ＳＴ３９：画像サイズ検出手段）。

次に、ＣＰＵ３１は、ステップＳＴ３６の処理で複写した画像ファイルの画像データを、ステップＳＴ３９の処理で記憶した画像サイズのデータに変更する（ＳＴ４０：サイズ変更手段）。そしてＣＰＵ３１は、画像データのサイズを変更した画像ファイルのファイル名を、ステップＳＴ３８の処理で選択された用途に応じた固有の名称に変更する（ＳＴ４１：ファイル名変更手段）。しかる後、ＣＰＵ３１は、ファイル名を変更した画像ファイルを、ネットワーク４を介してサーバ１へ送信する（ＳＴ４２：送信手段）。

画像ファイルを送信後、ＣＰＵ３１は、ディスプレイ４３の画面を画像選択画面に戻す。そしてＣＰＵ３１は、画像が選択されるか（ＳＴ３４）、業務終了が宣言されるのを待機する（ＳＴ３５）。

画像が選択された場合、ＣＰＵ３１は、前述したステップＳＴ３６〜ＳＴ４２の各処理を再度実行する。これに対し、業務終了が宣言された場合には（ＳＴ３５のＹＥＳ）、ＣＰＵ３１は、ネットワーク４を介してサーバに終了コマンドを送信する（ＳＴ４３）。以上で、画像取込プログラムＰ１が終了する。

第１の実施形態では、クライアント２のユーザは、用途選択画面から用途を選択した後、画像選択画面からその用途に用いる画像を選択する。このため、画像選択画面に数多くの料理メニュー品目のサムネイル画像が表示されていた場合には、選択すべき画像を探し出すのに時間がかかる。

これに対して、第２の実施形態では、ユーザは、画像選択画面から所望のサムネイル画像を選択した後、その画像の用途を選択すればよい。したがって、例えば画像選択画面から画像を順番に選択すればよいので、選択すべき画像を探し出す面倒が無い。

なお、この第２の実施形態においても、ネットワーク４の負荷を軽減できること、及び各電子メニュー端末３のリソースを大きく消費することが無いことは明らかである。

以下、その他の実施形態について、簡単に説明する。

前記実施形態では、サーバ１がクライアント２に画像取込プログラムＰ１を毎回ダウンロードするものとして説明をした。しかし本発明は、これに限定されるものではない。例えば、図７のステップＳＴ３の処理の前に、サーバ１のＣＰＵ６１が、クライアント２に前回ダウンロードした画像取込プログラムと、現時点でプログラムファイル領域６５Ｂに記憶されている画像取込プログラムとのバージョンを比較し、バージョンアップされているときだけダウンロードしてもよい。

また、同様の機能を記録媒体に記憶させたものをクライアント２にインストールしてもよい。記録媒体としては、ディスクＲＯＭやメモリカード等プログラムを記憶でき、かつ装置が読み取り可能な記録媒体であれば、その形態は何れの形態であっても良い。またこのように予めインストールやダウンロードにより得る機能は装置内部のＯＳ（オペレーティング・システム）等と協働してその機能を実現させるものであってもよい。

前記実施形態では、クライアント２が、フラッシュメモリ５またはＵＳＢ等の記憶媒体から画像データを取り込む場合を示した。しかし本発明は、記憶媒体から画像データを取り込むものに限定されるものではない。クライアント２が、外部から画像データを取り込むものであればよい。

前記実施形態では、クライアント２が、データサイズを変更した画像ファイルを１ファイルずつサーバ１にアップロードした。しかし本発明は、これに限定されるものではない。例えば、図８のステップＳＴ２３、あるいは図９のステップＳＴ４２の処理を省略する。そして、ステップＳＴ１５またはステップＳＴ３５の処理で業務終了が宣言されると、ＣＰＵ３１は、ワークメモリに複写された画像ファイルをサーバ１にアップロードする。その後、ＣＰＵ３１は、ネットワーク４を介してサーバ１に終了コマンドを送信する。こうすることにより、クライアント２が、データサイズを変更した画像ファイルをまとめてサーバ１にアップロードできる。

前記実施形態では、電子メニュー端末３を画像処理端末の一態様として説明をした。しかし画像処理端末は、電子メニュー端末３に限定されるものではない。例えば、厨房端末、ＰＯＳ端末、オーダエントリー用のハンディ端末等であってもよい。

この他、本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。

１…サーバ、２…クライアント、３…電子メニュー端末、４…ネットワーク、５…フラッシュメモリ、６…ＵＳＢメモリ、７…画像データベース。

Claims (7)

1. 外部から画像ファイルを取り込む取込手段と、
   この取込手段により取り込んだ前記画像ファイルの用途選択を受付ける用途受付手段と、
   この用途受付手段により選択を受付けた用途に応じた画像のサイズを、サーバからダウンロードされた画像取込プログラムから検出する画像サイズ検出手段と、
   前記取込手段により取り込んだ前記画像ファイルの画像データを、前記画像サイズ検出手段により検出したサイズの画像データに変更するサイズ変更手段と、
   このサイズ変更手段により画像データのサイズが変更された画像ファイルを前記サーバにアップロードする送信手段と、
   を具備したことを特徴とするクライアント。
2. クライアントと、ネットワークを介して前記クライアントに画像ファイル取込処理を実現させる画像取込プログラムをダウンロードするサーバと、を備えた画像取込システムであって、
   前記画像取込プログラムがダウンロードされた前記クライアントは、
   外部から前記画像ファイルを取り込む取込手段と、
   この取込手段により取り込んだ前記画像ファイルの用途選択を受付ける用途受付手段と、
   この用途受付手段により選択を受付けた用途に応じた画像のサイズを前記画像取込プログラムから検出する画像サイズ検出手段と、
   前記取込手段により取り込んだ前記画像ファイルの画像データを、前記画像サイズ検出手段により検出したサイズの画像データに変更するサイズ変更手段と、
   このサイズ変更手段により画像データのサイズが変更された画像ファイルを、前記ネットワークを介して前記サーバにアップロードする送信手段と、を具備し、
   前記画像取込プログラムを前記クライアントにダウンロードした前記サーバは、
   前記クライアントからアップロードされる画像ファイルを蓄積する画像蓄積手段、を具備したことを特徴とする画像取込システム。
3. 前記クライアントは、
   前記取込手段により取り込んだ前記画像ファイルを複写する複写手段と、
   この複写手段により複写された前記画像ファイルのファイル名を前記用途受付手段により選択を受付けた用途に応じた名称に変更するファイル名変更手段と、をさらに具備し、
   前記サイズ変更手段は、前記複写手段により複写された前記画像ファイルの画像データを、前記画像サイズ検出手段により検出したサイズの画像データに変更することを特徴とする請求項２記載の画像取込システム。
4. 前記サーバが前記クライアントにダウンロードする画像取込プログラムは、前記クライアントに実装されたウェブブラウザのプラグインとして提供されるアプリケーションフレームワークを使用して、前記クライアントに画像ファイルの取り込みを実現させるものであることを特徴とする請求項２または３記載の画像取込システム。
5. クライアントに、外部から前記画像ファイルを取り込む機能と、前記外部から取り込んだ前記画像ファイルの用途選択を受付ける機能と、選択を受付けた用途に応じた画像のサイズを画像取込プログラムから検出する機能と、前記外部から取り込んだ前記画像ファイルの画像データを、前記画像取込プログラムから検出したサイズの画像データに変更する機能と、画像データのサイズが変更された画像ファイルを、ネットワークを介してサーバにアップロードする機能と、を実現させるための画像取込プログラムを、前記ネットワークを介してダウンロードするダウンロード手段と、
   前記クライアントからアップロードされる画像ファイルを蓄積する画像蓄積手段と、
   を具備したことを特徴とする画像取込サーバ。
6. クライアントに、外部から前記画像ファイルを取り込む機能と、前記外部から取り込んだ前記画像ファイルの用途選択を受付ける機能と、選択を受付けた用途に応じた画像のサイズを画像取込プログラムから検出する機能と、前記外部から取り込んだ前記画像ファイルを複写する機能と、複写された前記画像ファイルのファイル名を前記選択を受付けた用途に応じた名称に変更する機能と、複写された前記画像ファイルの画像データを、前記画像取込プログラムから検出したサイズの画像データに変更する機能と、画像データのサイズが変更された画像ファイルを、ネットワークを介してサーバにアップロードする機能と、を実現させるための画像取込プログラムを、前記ネットワークを介してダウンロードするダウンロード手段と、
   前記クライアントからアップロードされる画像ファイルを蓄積する画像蓄積手段と、
   を具備したことを特徴とする画像取込サーバ。
7. クライアントに、
   外部から前記画像ファイルを取り込む機能と、
   前記外部から取り込んだ前記画像ファイルの用途選択を受付ける機能と、
   選択を受付けた用途に応じた画像のサイズを画像取込プログラムから検出する機能と、
   前記外部から取り込んだ前記画像ファイルの画像データを、前記画像取込プログラムから検出したサイズの画像データに変更する機能と、
   画像データのサイズが変更された画像ファイルを、ネットワークを介してサーバにアップロードする機能と、を実現させるための画像取込プログラム。

Images