JP4697899B2 - プリントシステム及び方法、並びにコンピュータプログラム - Google Patents

Description

本発明は各種イベントで撮影した写真をプリントする技術に関するものである。

従来、学校等でのイベント写真の注文は、銀塩カメラで撮影した場合もデジタルカメラで撮影した場合も、見本としてサービスサイズの写真を１枚ずつプリントし、大きめの模造紙に貼り付けて教室等に掲示し、各関係者はそのプリントを見て個人別又は全員用の注文用紙に名前と所望とする写真別のプリント依頼数を記入していた。

又、最近ではデジタルカメラやスキャナが広く普及し、撮影した画像をサーバーにアップロードして、フォトアルバムサイトとして特定のグループや不特定の人の閲覧に供することも行われている。例えば特許文献１では、アナログフィルムをスキャナで読み込んでデジタル画像に変換し、そのデジタル画像を検索可能な形で記憶するデジタル画像データベースとクライアント端末とを通信回線を介して接続する画像データ管理システムが開示されている。
特開２００２−９９５４３号公報

しかし、プリント依頼書を記入する場合、手作業でプリントした写真を綺麗にならべて糊付けし、注文番号を記入していくのは相当の手間がかかり、イベント役員や幹事役の負担が大きかった。さらに注文枚数の集計にも相当の手間が掛かっていた。

他方、特許文献１のような技術の場合、画面で見た写真と実際のプリントの色が異なる場合があり、苦情に繋がる場合があった。又、デジタルフォトサービスサイトで写真を確認するには、サムネール画像を見て気に入りそうなものがあれば拡大画像を表示する必要があり、多くの写真から好みの写真を選ぶのは相当忍耐強い作業が必要であった。さらにデジタルフォトサービスサイトで写真を注文した場合、写真のプリント→袋詰め→郵送の作業が必要となり、フォトサービス側の担当者の作業負担が大きいと共に、依頼者にとっては、注文してから写真の入手までのタイムラグが大きいという問題があった。仮に注文に基づいて自己のパソコンに画像データを送信してもらうとしても自分のプリンタで印刷すれば、色味の問題はなお残ってしまう。

本願発明は上記問題点を解決するためになされたものであり、実際にプリントされる写真と同様のサイズで複数の写真が一覧印刷された大判印刷用紙を印刷することで、注文して手にした写真と見本との色味の違いの発生を抑制すると共に、模造紙等に実際の写真を貼り付ける作業負担をなくす仕組みを提供しようとするものである。

本願発明は、注文画像データとインデックスプリントをプリント装置でプリントするプリントシステムであって、カメラで撮像した複数の画像データを受け付け、前記複数の画像データの各画像データと前記各画像データの名前を順序付けてリネームして記憶する画像記憶手段と、前記記憶された前記各画像データと前記順序付けられた名前とを対応付けて配置し、前記注文画像データのプリントサイズと同様のサイズになるように、前記各画像データと前記順序付けられた名前を一覧にした印刷データを生成し、前記生成した印刷データおよび特定のイベントを判定可能なイベント特定情報をアカウントとして使用したメールアドレスを含む注文受け付けのためのインデックスプリントを所定の大判プリント紙に印刷する第１の印刷制御手段と、前記メールアドレス宛てに送信された前記大判プリント紙に印刷された前記順序付けられた名前を撮影した大判プリント紙撮影画像を含む注文を受け付ける受付手段と、前記受付手段が受け付けた前記大判プリント紙撮影画像に含まれる前記順序付けられた名前を文字認識により注文画像データ情報として特定する特定手段と、前記注文画像データ情報に基づいて、前記記憶された前記複数の画像データの中から前記注文画像データを特定し、前記特定した注文画像データを、前記送信されたメールアドレスに含まれるイベント特定情報と関連付けた注文情報として、注文データベースに蓄積する第２の特定手段と、前記注文データベースから前記蓄積した注文情報を読み取り、前記読み取った注文情報の前記第２の特定手段が特定した前記注文画像データを、前記プリントサイズで印刷する第２の印刷制御手段と、を備えることを特徴とする。

本発明によれば、実際にプリントされる写真と同様のサイズで複数の写真が一覧印刷された大判印刷用紙を印刷することで、注文して手にした写真と見本との色味の違いの発生を抑制することができる。
また、実際にプリントされる写真と同様のサイズで複数の写真が一覧印刷された大判印刷用紙を印刷することで、写真の被写体の状態を確認して、印刷の注文を行うことができる。
また、模造紙等に実際の写真を貼り付ける作業負担をなくすことができる。

以下、添付図面に従って本発明にかかる実施形態を詳細に説明する。

［第１の実施形態］
＜概要の説明＞
学校からの依頼を受けたカメラマンは、その学校の運動会等の各種イベントの写真を撮影する。カメラマンは、ＤＰＥ店に設置されたシステムを利用し、撮影した画像を電子化して取り込みを行わせる。なお、カメラが銀塩カメラの場合には、フィルムスキャナで読取ることで電子化して取り込みが行えるし、デジタルカメラの場合にはメモリカードリーダ等を介して電子データとして取り込みを行えば良い。そして、注文を受け付けるため、大判（Ａ０版やＢ０版）に、撮像した画像を通常のＬ版サイズで複数印刷した結果を、見本として学校に仮納品し、注文を受けつけ、その注文にしたがってプリントを行い、ＤＰＥ店にて手渡すものである。

なお、ＤＰＥ店に設置されたシステムに画像を登録する方法は、上記以外にもメールにて登録可能とした。メールでの登録する際には、撮像画像を上記の様なフィルムスキャナ、もしくは、カードリーダにて読取り、ＤＰＥ店の公に用意されたメールアドレス宛てに添付した上で送信することで実現する。ＤＰＥ店では、ＤＰＥ店の公のメールアドレス（後述するイベント特定情報で示されたアドレスとは異なり、固定メールアドレス）宛て受信したメールに画像が添付されている場合には、その添付画像をシステムに登録し、先に説明したように大判印刷を行うことになる。

＜システム構成と処理の説明＞
図１は実施形態におけるシステム構成図である。図示において、１００はインターネット、２００はＤＰＥ店に設置されたシステムを示し、３０１乃至３０３は、注文する際の端末として機能する装置であって、図示の如く、インターネットに接続し得る装置であればその機種は問わない。

システム２００において、２０１はメールサーバ、画像処理サーバとして機能する装置であって、ハードウェア的には、一般のパーソナルコンピュータ（ＰＣ）で代表される汎用の情報処理装置で良い。２５０は写真をプリントするプリント装置である。実施形態では１つの装置にメールサーバ、画像処理サーバを搭載する例を示しているが、これらは別装置であっても良いし、ＤＰＥ店に設置されていなくても構わない。また、実施形態における画像処理サーバは、撮影した画像を蓄積保存する機能、及び、Ｗｅｂサーバとしても機能するものとして説明する。

ＰＣ２０１は図２に示すような構成である。図示において、２１は装置全体の制御を司るＣＰＵであり、２２はＣＰＵのワークエリア、ＯＳ、各種アプリケーションをロードし実行するためのＲＡＭである。２３はＢＩＯＳやブートプログラムを記憶しているＲＯＭである。２４はインターネットに接続するためのＬＡＮアダプタであり、２５はビデオメモリを内蔵し、ＣＰＵ２１の制御下でビデオメモリへの書き込み、及び、外部の表示装置にビデオ信号を出力するビデオアダプタである。２６、２７はキーボード、マウス（登録商標）等のポインティングデバイス、２８はＯＳ、サーバアプリケーション、更には実施形態で説明する各種データベースを記憶するハードディスクである。２９はＣＤＲＯＭドライブである。なお、これら各構成要素はシステムバス２０を介して接続されることになる。

図３は図１における端末３０２等の構成を示している。ハードウェア構成そののものは図２と実質的に同じであるのでその詳述は省略するが、図３のクライアントでは、インターネットに接続でき、ホームページの閲覧、メールの送受信を行うためのＯＳ、ブラウザ、メーラのプログラムが実行可能であれば良い。

上記構成において、先に説明したように、学校等の団体からの依頼を受けて撮影した画像は、ＤＰＥ店に設置されたＰＣ２０１に接続されたフィルムスキャナやカードリーダを介して電子化画像データとして取り込み蓄積する。もしくは、固定のメールアドレス宛てに送信されたメールを受信し、それに添付された画像データをハードディスク２８中の画像ＤＢに蓄積登録する。

いずれの場合であっても、一連の画像を特定するイベント情報（以下、イベント特定情報という）を生成し、それに関連付けて、個々の画像データを連番（００１、００２…の３桁の番号）付けてＰＣ２０１内のハードディスク内の画像データベース（画像ＤＢ）に登録すると共に、そのイベント特定情報に関連づけた注文ＤＢも構築する。また、このとき、注文を受け付けるため、大判（Ａ０版やＢ０版）に、撮像した画像を通常のＬ版サイズで複数印刷した結果を、見本として学校に仮納品することで、関係者が注文できる状況を構築する。更に、画像ＤＢに登録した各画像（高解像度）の低解像度のサムネイル画像も生成し、Ｗｅｂサーバ上にイベント特定情報名のディレクトリ内に格納し、注文受け付けのホームページも作成する。

なお、詳細は後述するが、学校に仮納品する大判プリント結果の各画像には、それぞれの画像を特定する番号もプリントされており、尚且つ、所定形式の注文用紙も仮納品する。

図１３はこの大判印刷した例を示している。図示に示す如く、イベント名が印刷されると共に、各画像が通常のＬ版もしくはそれに近いサイズで印刷することになるので、注文する際に閲覧した画像と注文した結果納品される写真の画像との間の色味の差が発生することは無くなり、尚且つ、これまで模造紙等に実際の写真を貼り付けた場合には剥がされる等の問題があったが、実施形態ではこのような大判の記録紙に直接印刷するので、かかる問題が発生する可能性を小さなものとすることが可能になる。

また、図１３に示す如く、写真の注文サイトのＵＲＬ、メールアドレスも印刷する。なお、図示における文字列“ＡＱ１４３２８７”が、実施形態におけるイベント特定情報であり、関係者以外の者が推察し得ないような無意味な文字で構成されることが望ましい（英数字をランダムに並べた）。

さて、実施形態における写真の注文方法は以下の４通りとした。

方法１：昨今の携帯電話にはデジタルカメラが内蔵されているものが少なくないので、図１３の大判印刷した中の所望とする画像の近傍に印刷されている番号（勿論、それ以外にもバーコードがあればそれでも構わない）を撮影し、その撮像して得た画像を、添付ファイルとして掲示されたメールアドレス宛てに送信する。メールアドレスにはイベント特定情報が利用されているので、ＤＰＥ店側としては、どのイベントに対する注文であるのか判別できることになり、尚且つ、撮影された画像番号も判明するので、どの画像を注文したのかが判別可能となっている。

なお、撮像画像が添付されてきたメールは、その撮像画像中の画像を特定する情報を文字認識を行い、イベント特定情報に関連付けて注文ＤＢ（後述）に蓄積する。その際、注文者名としては電話番号を用いるものとするが、メール本文に氏名等が存在すれば、それを用いても良い。

方法２：この方法は、大判印刷結果を依頼元に納品した際に、一緒に納品した注文用紙を利用するものである。注文用紙は例えば図１４に示すように、イベント特定情報が予め印刷され、氏名、電話番号、そして、注文したい画像の番号（ファイル名でもある）及び枚数を記入する欄が設けられている。ＤＰＥ店は記入済みの注文書を貰い受け、順次ＯＣＲ処理を実行し、注文ＤＢに蓄積する。このとき、注文用紙の所定位置にはイベント特定情報も文字認識することで、どのイベントに対する注文かが判別可能となる。そして、画像を特定する情報、枚数、氏名をそのイベントに関連付けて注文ＤＢに登録する。なお、手書き注文用紙の形態は図１４に限らない。例えば、個々のサムネイル画像も併せて印刷するようにしても構わない。

方法３：大判印刷結果を依頼元に納品した際、その大判印刷物には図１３に示すように、ＷｅｂページのＵＲＬを記述してあるので、注文者が有するパーソナルコンピュータや携帯電話でＷｅｂページをアクセスし、注文する画像及び枚数と、氏名を入力する。入力結果は、そのイベントに関連づけられた注文ＤＢに登録される。図１１はパーソナルコンピュータ等の装置でのアクセスした際に表示される画面の例を示し、図１２は携帯電話の表示画面に表示される画面を示している。いずれの場合であっても、プリントしたい画像のチェックボックスをチェックし、「注文」ボタンを指定することで、その注文結果を注文ＤＢに登録することになる。なお、一度に表示される画像枚数には限りがあるので、図示の如く、ページ送りボタン（例えば図１１では「前のページ」、「次のページ」、図１２では単なる矢印）を指示することで、所望とする画像を探し出すことが可能となっている。

方法４：昨今の携帯電話にはデジタルカメラが内蔵されているものが少なくないので、図１３の大判印刷した中の所望とする画像の近傍に印刷されている番号（勿論、それ以外にもバーコードがあればそれでも構わない）又は所望の画像の少なくとも一部（傾いていても良い）を撮影し、その撮像して得た画像を、予め所定のサイトからダウンロードしてインストールしたアプリケーション（例えばiアプリ）を起動して画像処理サーバ２０１（又は不図示の注文受付サイト）宛てに送信する。画像処理サーバ２０１（又は不図示の注文受付サイト）では受信した撮像画像を所定のフォルダに蓄積する。

次に、蓄積された撮像画像は、その撮像画像中の画像を特定する情報について文字認識を行い、又撮影画像が画像だけの場合は予め記憶されている実際の写真画像との画像一致検索を行ない、イベント特定情報及び撮影番号を特定した上で注文ＤＢ（後述）に蓄積する。その際、注文者名としては電話番号を用いる。

以上、注文方法を説明したが、ＰＣ２０１のハードディスク２８に生成される注文ＤＢ、及び画像ＤＢは例えば図１５に示す構造となっている。

先ず、ＤＰＥ店では、複数の学校からの撮影画像のプリント依頼を受けることが考えられるので、注文ＤＢには個々のイベント特定情報、注文者、注文した画像番号及び枚数のフィールド、及び、個々の注文にユニークな注文番号のフィールドで構成される。注文は画像番号及び枚数を１組として受け付け、要求される画像の数は不特定である。そこで、セミコロンをデリミタとして登録するようにした。なお、イベント特定情報と依頼元（実施形態では学校名；代表者名等の情報）との関係を示すＤＢは別途設けられているものとし、ここでの詳述は省略する。

＜処理の説明＞
先ず、ＤＰＥ店のシステムに画像を登録する処理手順を説明する。画像登録は先に説明したように、ＤＰＥ点に設置さえた画像取り込み装置（カメラが銀塩カメラの場合にはフィルムスキャナ、デジタルカメラの場合にはカードリーダ）を利用しても良いが、この場合には説明するまでもないであろうから、メールによる受信により登録する例を図４のフローチャートに従って説明する。なお、ＤＰＥ点に設置されたシステム、特にＰＣ２０１は、要求元に対して画像処理サーバとして機能することになるので、以下ではＰＣ２０１を画像処理サーバとして説明することとする。勿論、画像処理サーバはＰＣ２０１とは別装置で構成しても良いし、インターネット上に設けてもよいことを付言しておく。

さて、プリントを要求するクライアント（例えば図３の端末）は、何らの手段（フィルムスキャナ、カードリーダ等）で撮影した像を電子的な画像データに変換した上で、ステップＳ４０１にて、画像の登録を依頼するメールを、画像処理サーバの一般に公開されているメールアドレスに向けて送信する。以下、単に「画像」と言う場合は、画像処理サーバ２０１の画像ＤＢに登録された写真画像を意味する。

画像処理サーバはステップＳ４２１にてそのメールを受信し、ステップＳ４２２で過去に同じ要求があったか否かの検索を行う。そして、ステップＳ４２３にて同じ要求を既に受信済みであると判断した場合には、ステップＳ４２４にて依頼された画像は既に存在する旨のエラー通知メールを送信する。従って、クライアントはこのエラー通知メールを受信した場合には（ステップＳ４０２）、それを確認することが可能となる。

一方、新規の画像登録依頼であると判断した場合には、ステップＳ４２５に進み、今回登録要求された画像登録に対しユニークなイベント特定情報を生成する。そして、ステップＳ４２６において、添付された各画像の名前を“００１”で始まる名前にリネームし、イベント特定情報に関連付けてハードディスク２８内の画像ＤＢに記憶保存する。全ての画像の記憶が完了すると、ステップＳ４２７に進んで、各画像の確認用のサムネイル画像（画像の内容が確認できる程度の低解像度画像）を生成し、ステップＳ４２８において、Ｗｅｂサーバ４０２に、イベント特定情報のディレクトリを作成し、そこに生成したサムネイル画像、並びに、注文用ホームページをアップロードする。また、ステップＳ４２９では、イベント特定情報を構成する文字列を使ったメールアドレス（アカウント）をメールサーバ４０１に登録する。次いで、ステップＳ４３０にて、画像登録要求したクライアントに対し、作成したホームページのＵＲＬ、並びに、注文用に確保したメールアドレスをメールにて通知する。そして、ステップＳ４３１では、登録した画像を大判印刷するべく、印刷画像データを作成し、ステップＳ４４１にて大判印刷可能なプリンタ２５０に出力し、図１３に示す大判印刷を行う。なお、大判印刷可能なプリンタを所有していないＤＰＥ店の場合、その大判印刷要求をその装置を有するＤＰＥ店に要求するようにしても構わない。

いずれにしても、この大判印刷結果は、写真プリントを要求した依頼人に渡されることになるし、その際には図１４に示す手書き注文用紙も併せて納品することになる。この結果、電子メールでの注文、手書き注文用紙での注文が行える環境が整うことになる。

なお、この大判にプリントされた画像の一部に「見本」や「ＳＡＭＰＬＥ］等の透かし文字を加えてもよい。このようにすることで、大判にプリントされた画像を携帯電話のカメラやデジタルカメラで撮影（コピー）する行為を相当程度抑制することができる。この透かしを各画像の所定の位置（一定位置）に印刷すれば、後述する画像一致検索（ステップＳ１９３３）が容易になるという効果も奏する。

ＤＰＥ店のＰＣ２０１（画像処理サーバ）は、ステップＳ４２９で作成したアカウント向けの電子メールがあるかどうかのチェックを定期的に行うことになる。そこで、その処理手順を図５のフローチャートに従って説明する。同図はＤＰＥ点のＰＣ２０１、すなわち、画像処理サーバと、注文を行うクライアントとの処理手順を関連付けて示したものである。

先ず、写真を注文しようとするクライアントでは、ステップＳ５０１において、注文する画像番号及び枚数を記述したメール、もしくは撮影した画像を添付ファイルとして送信する。画像処理サーバは、ステップＳ５２１にて、このメールを受信し、ステップＳ５２２にて、過去に同じクライアントから同じ注文メールがあったかを判定するため注文ＤＢの注文者の欄を検索する。重複する注文があったと判断した場合には、ステップＳ５２３からステップＳ５２４に進み、その旨のメールを要求元に送信することで、クライアントはそれを受信することが可能となる（ステップＳ５０２）。

一方、新規な注文であると判断した場合には、ステップＳ５２５に進み、その注文依頼に対してユニークな注文番号を生成する。そして、ステップＳ５２６では、メールに添付画像が存在するか否かを判断する。添付画像が存在すると判断した場合には、大判印刷結果を画像番号（バーコードでも良い）を撮影したものとして判断して良いので、ステップＳ５２７に進んでＯＣＲもしくはバーコードイメージをデコードする。そして、ステップＳ５２８でメール本文を解析し、ステップＳ５２９で、注文者、ＯＣＲ（もしくはバーコードをデコード）した結果で特定する画像、メール本文で記述された画像＆枚数、更には注文番号を注文ＤＢに追加登録する。

図６は、注文しようとする者がＷｅｂサーバ（ＰＣ２０１）のホームページを閲覧して注文する際の処理の流れを示している。以下、同図に従って説明する。

先ず、クライアントが所定の認証情報を通知することでＷｅｂサーバのイベント特定情報で特定されたホームページをアクセスする（ステップＳ６０１）、サーバは認証情報を受信し（ステップＳ６２１）、認証チェックを行う（ステップＳ６２２）。この認証情報は、大判印刷結果を依頼元に納品した際に通知するものである。認証に失敗した場合には、ステップＳ６２３からステップＳ６２４に進み、アクセス不可を示す警告メッセージを送信し、クライアントはこのメッセージを受信してアクセスが拒否されたことを表示することになる。

一方、アクセスが認証されると、処理はステップＳ６２５に進み、閲覧用の画像を生成し、その生成された画像とその番号、注文者名の入力欄を有する表示画像を作成し、ステップＳ６２６でクライアントに送信する。

クライアントはこれを受信し画面に表示し（ステップＳ６０３）、所望とする画像及び枚数を指定すると共に注文者の名前等を入力し、サーバに注文情報として送信する（ステップＳ６０４）。

サーバは、この注文情報を受信し（ステップＳ６２７）、その注文に対するユニークな注文番号を発生し（ステップＳ６２８）、注文ＤＢに登録する（ステップＳ６２９）。そして、注文情報中に返信用のメールアドレスが記述されているか否かを判断し（ステップＳ６３０）、もしそれがあれば注文を受け付けた旨のメール（注文番号も含む）をそのメールアドレスに向けて送信する（ステップＳ６３１）。

以上、メール、Ｗｅｂを介しての注文受注処理を説明したが、先に説明したように、実施形態での注文は、上記以外にも手書き注文用紙での注文も受け付けるが、これは手書き注文用紙を文字認識しては、注文ＤＢに登録するものであるので、説明するまでもないであろう。

次に、実施形態における注文ＤＢに蓄積された注文情報に従って写真をプリントする処理を図７のフローチャートに従って説明する。

先ず、ステップＳ７２０にて注文情報を読取り、ステップＳ７２１でその注文の印刷時期を判定する。そして、印刷時期に未だなっていないと判断した場合には、ステップＳ８２３にて所定時間待ち、ステップＳ７２０に戻る。

上記印刷時期を設定したのは、或るイベントに対する印刷をまとめて処理するためである。

印刷時期になったと判断した場合には、ステップＳ７２４で、注文ＤＢを検索して、キャンセルになったものがあるか否かを判定を判定する。このキャンセル通知の有無は、キャンセル要求メールを蓄積するＤＢ（不図示）を用意し、メール本文にイベント特定番号と注文番号、及び、キャンセルする所定の文字列があるか否かで判断するものとした。

キャンセル通知を受けた注文については、ステップＳ７２５からステップＳ７２９に進み、キャンセルされた旨のメールを依頼元に通知し、ステップＳ７３０で注文ＤＢから該当するレコード（１行）を削除し、本処理を終える。一方、キャンセル通知が無かったと判断した場合には、ステップＳ７２５からステップＳ７２６に進み、注目している注文データ中に記述された画像番号に対応する画像データを画像ＤＢより順次読み込み、プリント装置２５０に、その画像データとプリント枚数を送信する。これを受けて、プリント装置２５０は写真印刷処理を行い（ステップＳ７４１）、印刷が完了するとその旨を本装置（ＰＣ２０１）に送信する。この印刷処理完了の通知を受けると、依頼元がメールで注文してきている場合にはステップＳ７２８で印刷完了を知らせるメールを送信する。そして注文ＤＢ中の該当する注文データに、印刷済みフラグを立てて（ステップＳ７３０）、本処理を終える。

以上説明したように本実施形態によれば、注文を受け付けのための見本を、Ａ０版やＢ０版等の大判用紙に、通常のＬ版もしくはそれに近いサイズの画像を複数印刷することになるので、これまでのように写真を模造紙に貼り付ける作業が不要となると共に剥がされることも無くなる。また、注文する際には、実際にプリントされた結果を確かめた上で行えるようになるので、期待した通りの写真を注文することが可能となる。更に、本実施形態によれば、上記の如く、学校が依頼元の場合であっても、その関係者が注文を集計する作業が必要であったが、本実施形態のようなシステムにすることにより、かかる作業から解放されることになる。

＜第２の実施形態＞
上記実施形態では、注文した者が実際に写真を手にするためには、固定のプリントサービスを行うＤＰＥ店まで足を運ぶ必要がある。しかしながら、依頼元である学校の近くにあるＤＰＥ店で写真を手に入れることが望ましい。そこで、本第２の実施形態では、依頼元の近くに存在するＤＰＥ店を決定し、その上で第１の実施形態と同様な作用効果を奏する例を説明する。

＜システム構成＞
図１６は本第２の実施形態におけるシステム全体構成図である。図示において、５００はデジタルフォトサービス（ＤＰＳ）サーバであって、４０１乃至４０４はＤＰＥ店である。各ＤＰＥ店には、インターネットと接続すると共に注文された画像のプリント制御を行うサーバ（ハードウェアとしてＰＣで実現できる）、及び、実際にプリント処理を行うプリント装置が設置されることになる。図示では、ＤＰＥ店４０１についてのみ、その構成を示したが、他のＤＰＥ店も同様である。他の構成要素は、図１と同様なので、その説明は省略する。また、ＤＰＳサーバ５００は、図２と実質的に同じ構成をしているものとし、その詳述は省略する。

上記構成における本第２の実施形態の処理概要を説明すると、次の通りである。

先ず、依頼人もしくはその代理人は、依頼人名称（学校名等）及び住所と記述した本文メールと、撮影した画像は電子データとして添付して、ＤＰＳサーバ５００に送信する。ＤＰＳサーバ５００は、第１の実施形態と同様、１つのイベントについてユニークなイベント特定情報を生成し、画像ファイルを管理すると共に、注文受け付けのためのホームページを作成する。また、画像登録の際に、依頼元から通知される住所情報に従い、その依頼元の最寄りのＤＰＥ店を決定し、その決定したＤＰＥ店のサーバ４５０にその画像データとイベント特定情報、依頼元情報を送信し、保存させる。また、ＤＰＳサーバ５００は、第１の実施形態と同様、各クライアント３０１乃至３０３からの写真の注文を受けつけるためのメールアドレスを確保すると共に、注文ＤＢも確保する。

一方、ＤＰＳサーバ５００から前述した情報を受信したＤＰＥ店のサーバ４５０は、第１の実施形態と同様大判プリントし、依頼元にその印刷結果を仮納品を行う。

この後、ＤＰＳサーバ５００には、インターネットを介しての注文メールを受け付け、それを注文ＤＢに登録することになるが、その注文情報を、先に決定したＤＰＥ店に送信し、画像の印刷を行わせる。なお、ＤＰＳサーバ５００には、住所ＤＢと、本システムに参加・加入しているＤＰＥ店の住所ＤＢが設けられていることになる。住所ＤＢには、住所を示す文字列と、その座標位置（経度、緯度情報）とが関連づけられているものである。また、ＤＰＥ店ＤＢの構造としては、例えば図１７に示す構造を有し、本システムに加入している加入者番号、ＤＰＥ点のメールアドレス、そして、実際の住所である。

先に説明したように、依頼人（実施形態では学校）の住所をキーにして住所ＤＢを検索することでその座標位置が判明する。また、ＤＰＥ店ＤＢも住所ＤＢを参照することで、個々のＤＰＥ点の座標が判明する。したがって、これら二者間の距離が最も短いものを検索することで、依頼元に最も近いＤＰＥ点を検索することが可能となる。

以上のようにすることで、画像を依頼する者は、その所在地の近くに存在するＤＰＥ店にて写真を手に入れることができるようになり、先に示した問題点を解決できるようになる。

＜処理の説明＞
以下、上記処理を実現する第２の実施形態の具体的な処理を説明する。

図８は第２の実施形態におけるＤＰＳサーバ５００への画像登録処理手順を示している。図８と図１との違いは、図８の処理がＤＰＳサーバ５００で実行する点、依頼元から送信されてきた画像を実際に印刷するＤＰＥ店を依頼元の住所に近いＤＰＥ店を決定する工程（ステップＳ８３０）が設けられる点、更に、その決定したＤＰＥ店のプリントサーバ４５０に、登録した画像データ並びにイベント特定情報を送信する工程（ステップＳ８８３）が設けられている点にある。また、各ＤＰＥ店ではＤＰＳサーバ５００から画像を受信した際（発信元のメールアドレスから判別可能である）には、プリントサーバ４５０のハードディスクにそのイベント特定情報のディレクトリを作成して、その中に保存する処理（ステップＳ８４１乃至８４３）を行う。なお、ＤＰＥ店のプリントサーバ４５０は、この情報を受信した際には、第１の実施形態と同様、大判プリントを行い、依頼元にそれを納品することになる。このとき、手書き注文用紙も併せて仮納品することになる。

次に、クライアント（写真を注文する者が使用する端末）からメールによる注文を受けつける処理を図９に従って説明する。この処理は、ちょうど第１の実施形態における図５に対応するものであることが理解できよう。

図９と図５との違いは、メールによるクライアントからの注文の受け付けを行うのはＤＰＳサーバ５００となっている点と、図９におけるＳ９２９以降の処理が、図５のＳ５２９以降と置き換わった点である。従って、図９のＳ９２９よりも前の処理については、図５と重複するので簡単に説明することとする。

クライアントから大判印刷結果の所望とする画像（画像番号やバーコード画像）が添付されてきた、あるいは、メール本文中に画像番号と枚数を組（複数組あっても勿論構わない）を受信すると、ＤＰＳサーバの注文ＤＢにその注文情報を格納し（ステップＳ９３０）、図８で決定したＤＰＥ店のプリントサーバ４５０に向けてその注文情報を送信する（ステップＳ９３１）。

ＤＰＥ店のプリントサーバ４５０は、この注文情報を受信すると（ステップＳ９５１）、その情報を自身の注文ＤＢに登録する。

次に、クライアントがＤＰＳサーバ５００のホームページにアクセスして、注文を行う場合の処理は図１０のようになる。同図は、図６に対応するものであるが、同図と図６との違いは、Ｗｅｂページによるクライアントからの注文の受け付けを行うのはＤＰＳサーバ５００となっている点と、注文を受け付けた際にその注文情報を、図８で決定したＤＰＥ店のプリントサーバ４５０に向けて送信する点（ステップＳ１０３３）、及び、その注文情報を受信したプリントサーバ４５０が自身の注文ＤＢに登録する点である。それ以外については、図６と同様であるので説明は省略する。

さて、ＤＰＥ店のプリントサーバ４５０であるが、図８乃至図１０の処理によって、自身のハードディスクには先に説明した第１の実施形態と同様のデータが構築されることになる。したがって、実際のプリント処理は第１の実施形態で説明した図７と実質的に同じとなるので、その説明についても省略する。

以上の結果、本第２の実施形態によれば、撮影した画像を印刷する依頼人は、本サービスを運営しているＤＰＳにその画像を登録するという作業を行うだけで、最寄りのＤＰＥ店で大判印刷した結果を受けとることができ、一連の写真の申し込み作業から解放されることになり、尚且つ、最寄りのＤＰＥ店にて注文した写真を手にすることが可能となる。また、本第２の実施形態に従えば、本システムに参加しているＤＰＥ店であれば、不特定の依頼人からの写真の注文を受けることができるようになる。

＜第３の実施形態＞
第２の実施形態では、依頼元の最寄りのＤＰＥ店が写真を印刷するものであったが、注文する者の近くにあるとは限らない。

そこで、注文する人の近場にあるＤＰＥ店にて写真を手に入れる例を第３の実施形態として以下に説明する。

基本的なシステム構成は、図１６と同じである。異なる点は、写真を注文する際に、その注文者の住所をメール本文に記述する点にある。ＤＰＳサーバ５００は注文をメールで受信した際、そのメール中に記述された住所に従って、本システムに加入しているＤＰＥ店ＤＢを参照して注文者の住所に距離の短いＤＰＥ店のプリントサーバに撮像した画像と注文情報を送信するものである。

具体的には、図８のステップＳ８３３の送信処理を無くする（注文者がないいので、この段階ではＤＰＥ店も未定のため）。そして、図９のステップＳ９２８でメール本文中の住所から最寄りのＤＰＥ店を検索する処理も行うようにし、尚且つ、ステップＳ９３１にて、その検索結果得られたＤＰＥ店に向けて注文情報並びに注文された画像データを送信する処理を行えばよい。これは図１０でも同様である。

なお、図９、図１０のいずれにおいても、注文者には、いずれのＤＰＥ店でプリントされるのかを知らせるメールを送信することが望ましい。

以上の結果、本第３の実施形態によれば、第２の実施形態の作用効果に加えて、注文者が居住する場所に近いＤＰＥ店にて写真を手に入れることが可能となる。

また、本第３の実施形態の場合には、撮影した画像をＤＰＳに登録すると、その際に作成された注文用のＵＲＬの通知を受けるので、そのＵＲＬを遠方の親戚や知人にメールで知らせることで、それを受けとった者は地元のＤＰＥ店にてその写真を手にすることも可能となる。

＜第４の実施形態＞
次に図１８のフローチャートを用いて、既述の方法１によって各写真注文者が写真を注文するための注文者登録処理について説明する。図１８においてステップＳ１８０１乃至ステップＳ１８０４は携帯端末３０１で実行され、ステップＳ１８２１乃至ステップＳ１８２８は画像処理サーバのＣＰＵ２１の制御の下で実行される。

まず、ステップＳ１８０１では、携帯端末３０１が画像サーバのユーザ登録用ＵＲＬに接続要求を送信する。ステップＳ１８２１では、接続要求を受信し、ステップＳ１８２２では、この接続要求に含まれる端末固有情報（発信者電話番号又は携帯端末のＭＡＣアドレス又は機器のシリアル番号等端末を特定できる一意の情報）の種別を判定してから、顧客ＤＢを検索する。

ステップＳ１８２３では、接続要求を送信した携帯端末３０１で特定される顧客が既に顧客DBに登録済みかを判定する。登録済みの場合、処理はステップＳ１８２４に進み画像処理サーバは「既に登録済です」等のエラーメッセージを送信し、ステップＳ１８０２では携帯端末３０１の画面にこのエラーメッセージが表示される。なお、エラーメッセージは携帯端末３０１側で音声で再生するようにしても良い。

登録済みでない場合、処理はステップＳ１８２５に進み、画像処理サーバの顧客ＤＢに新規顧客として一意の顧客番号が採番される。

ステップＳ１８２６では、画像処理サーバ２０１から携帯端末３０１に登録用画面が送信される。具体的には例えば携帯端末用のＨＴＭＬ情報が送信される。ステップＳ１８０３では、携帯端末３０１の表示部に登録用の画面が表示される。

ステップＳ１８０３では、登録用の画面経由で携帯端末３０１に入力された登録情報が画像処理サーバに送信され、ステップＳ１８２７では、画像処理サーバが登録情報を受信してＲＡＭ２２に記憶する。

処理はステップＳ１８２８に進み、採番されたユーザ番号と受信した登録情報に基づいて顧客情報がハードディスク２８の顧客ＤＢに登録される。顧客情報は、ユーザ番号の他、端末固有情報区分、端末固有情報、電話番号、登録年月日が含まれる。

これらの処理の結果、撮像画像による注文や、Ｗｅｂサイト経由の注文、電子メールでの注文、手書き注文用紙での注文が行える環境が整うことになる。

次に既述の方法４による受注処理の詳細を図１９のフローチャートに基づいて説明する。図１９においてステップＳ１９０１とステップＳ１９０２は携帯端末３０１で実行され、ステップＳ１９２１乃至ステップＳ１９３６は画像処理サーバのＣＰＵ２１の制御の下で実行される。携帯端末３０１は典型的にはデジタルカメラを備えた携帯電話であるが通信機能を備えたデジタルカメラ付ＰＤＡや通信機能を備えたデジタルカメラ等でも良い。

写真の注文者は、大判用紙に印刷されたバーコードや英数字や印刷された画像の一部を携帯端末３０１で撮影する。その後予め画像処理サーバ又はその他のサーバからダウンロードしたアプリケーション（例えばiアプリ）を起動する。

ステップＳ１９０１では、携帯端末３０１が大版印刷に記載された受注用ＵＲＬに撮像画像を送信する。受注用ＵＲＬはイベント特定情報と関連付けられて割り当てられいる一意のＵＲＬである。送信する場合ＦＴＰで送信しても良いし、ＨＴＴＰ等のその他のプロトコルでも良い。画像処理サーバはステップＳ１９２１で撮像画像を受信し、ハードディスク２８に発信者の電話番号別（又は端末固有番号別）の所定の一時フォルダを作成して撮像画像を記憶する。

次にステップＳ１９２２では所定の一時フォルダに記憶された画像の送信者の端末固有番号で顧客ＤＢを検索する。ステップＳ１９２３では、該当する端末固有番号が既に登録済みかが判定される。登録済みでない場合はステップＳ１９２４に進み、登録依頼画面が携帯端末に送信され、ステップＳ１９０２で登録依頼画面が携帯端末の表示部に表示されユーザ登録処理に遷移する。登録済みの場合はステップＳ１９２５に進む。

ステップＳ１９２５では、一意の注文番号が採番され、ステップＳ１９２６で採番された注文番号を含む名称の個別フォルダが生成される。ステップＳ１９２７で受信した撮像画像が一時フォルダから前ステップで生成された注文番号を含む個別フォルダに移動される。

ステップＳ１９２８では、個別フォルダの撮像画像がＲＡＭ２２のワークエリアに１画像づつ読み込まれる。ステップＳ１９２９で読み込んだ画像が、写真画像の少なくとも一部かバーコードかが判定される。この場合撮像画像に少なくとも二値画像のバーコード又は英数字が含まれている場合はバーコードと判定され、バーコード又は英数字を含まず写真画像だけの場合は写真画像と判定される。バーコード又は英数字と判定した場合はステップＳ１９３０に進み、写真画像と判定した場合は、ステップＳ１９３３に進む。

ステップＳ１９３０では、撮像画像の傾き補正処理後、ＯＣＲ処理（光学的文字認識処理）が実行され、バーコードの場合は、認識されたバーコードが英数字に変換される。なお、イベント特定情報や写真番号を示す英数字やバーコードに加えて、チェックサム用の英数字やバーコードを付加してもよい。このように構成することで、ＯＣＲ認識で複数の認識候補が出た場合にもより正確な認識が可能になる。認識された英数字はＲＡＭ２２のワークエリアに記憶される。なお受付用ＵＲＬはイベント毎に一意なので、処理を高速化するためにイベント特定情報部分の文字認識を省略することもできる。

ステップＳ１９３１では、チェックサム部分を除いた認識された英数字（イベント特定情報と注文番号）をキーにして画像ＤＢが検索される。ステップＳ１９３２では、画像ＤＢ中に認識された英数字で特定される画像が存在するかが判定され、画像が存在する場合は、ステップＳ１９３５に進み、画像が存在しない場合は、ステップＳ１９３６に進む。

なお撮像画像に重複があった場合（例えば同じ写真を特定するバーコードが複数回撮影された場合）は撮影回数分のプリントが注文されたものとみなすこととしても良く、又は重複を省いて１枚ずつの注文とみなしても良い。

ステップＳ１９３３では、撮像画像の傾きが補正された後、撮像画像ＤＢの当該イベント特定情報に合致する画像について画像一致検索が実行され、ステップＳ１９３４では、撮像画像と一致又は部分一致する画像が存在するかが判定され、画像が存在する場合は、ステップＳ１９３５に進み、画像が存在しない場合は、ステップＳ１９３６に進む。この判定では「見本」等のすかしがある場合は、すかしの位置によって、大版に印刷された写真画像のどの部分が撮像されたかを判定するので検索が早くなる。

なお、注文用ＵＲＬをイベント毎に作成せず、固定されたＵＲＬにすることも考えられる。この場合、多数の撮像画像と画像ＤＢ中の画像の一致検索処理が重くなるが、注文したユーザの顧客ＤＢ中の自宅住所と、写真の画像の登録依頼者の住所が近い順に画像を照合し、さらにイベント毎の写真の受注年月日を制限することで撮像画像にイベント特定情報が含まれていない場合であっても合理的な時間内に検索を行うことができる。このように構成することで、各顧客はイベント毎の固有のＵＲＬを入力しなくても簡単に写真の注文を行うことが出来る。

説明を実施形態に戻す。ステップＳ１９３５では、イベント番号と注文番号がＲＡＭ２２に予め確保された注文用配列に記憶される。

ステップＳ１９３６では、今回読み込んだ画像が固有フォルダ中の最後の画像かが判定される。最後の画像でない場合は、ステップＳ１９２８に戻り、最後の画像の場合は、注文用配列のイベント番号及び注文番号と、端末固有番号又は電話番号がハードディスク２８の注文ＤＢに登録されて処理を終わる。

以上の第４の実施形態によれば、例えばカメラ付携帯電話で１度ユーザ登録をしてiアプリ等のアプリケーションをダウンロードした後であれば、大判用紙に印刷されたバーコードや英数字、又は画像の一部を撮影することで簡単に所望の写真を注文することが可能になり、教師やＰＴＡ役員又は写真店のスタッフは面倒な注文集計作業から開放される。

以上第１乃至第４の実施形態を説明したが、上記実施形態で説明したサーバ装置は基本的にパーソナルコンピュータ等の汎用装置で実現できるものであるから、本発明はコンピュータプログラムをもその範疇とすることは明らかである。また、通常、コンピュータプログラムは、ＣＤＲＯＭ等のコンピュータ可読記憶媒体をコンピュータにセットし、システムにコピー又はインストールすることで実行可能となるわけであるから、当然、本発明はかかるコンピュータ可読記憶媒体をもその範疇とすることは明らかである。

第１の実施形態におけるシステム構成図である。 第１の実施形態におけるサーバ装置のブロック構成図である。 第１の実施形態におけるクライアント装置のブロック構成図である。 第１の実施形態における画像登録処理手順を示すフローチャートである。 第１の実施形態における電子メールによる写真注文処理手順を示すフローチャートである。 第１の実施形態におけるＷｅｂページ上での写真注文処理手順を示すフローチャートである。 実施形態における写真印刷処理を示すフローチャートである。 第２の実施形態における画像登録処理手順を示すフローチャートである。 第２の実施形態における電子メールによる写真注文処理手順を示すフローチャートである。 第２の実施形態におけるＷｅｂページ上での写真注文処理手順を示すフローチャートである。 第１、第２の実施形態におけるＰＣ用の写真注文画面の一例を示す図である。 第１、第２の実施形態における携帯電話用の写真注文画面の一例を示す図である。 実施形態における大判プリントの例を示す図である。 実施形態における手書き注文用紙のフォーマットの一例を示す図である。 実施形態における注文ＤＢ、画像ＤＢの構造と関係を示す図である。 第２の実施形態におけるシステム構成図である。 第２の実施形態におけるＤＰＥ店ＤＢの構造を示す図である。 第４の実施形態におけるＷｅｂページ上での写真注文処理手順を示すフローチャートである。 第４の実施形態におけるＷｅｂページ上での写真注文処理手順を示すフローチャートである。

Claims (4)

1. 注文画像データとインデックスプリントをプリント装置でプリントするプリントシステムであって、
   カメラで撮像した複数の画像データを受け付け、前記複数の画像データの各画像データと前記各画像データの名前を順序付けてリネームして記憶する画像記憶手段と、
   前記記憶された前記各画像データと前記順序付けられた名前とを対応付けて配置し、前記注文画像データのプリントサイズと同様のサイズになるように、前記各画像データと前記順序付けられた名前を一覧にした印刷データを生成し、前記生成した印刷データおよび特定のイベントを判定可能なイベント特定情報をアカウントとして使用したメールアドレスを含む注文受け付けのためのインデックスプリントを所定の大判プリント紙に印刷する第１の印刷制御手段と、
   前記メールアドレス宛てに送信された前記大判プリント紙に印刷された前記順序付けられた名前を撮影した大判プリント紙撮影画像を含む注文を受け付ける受付手段と、
   前記受付手段が受け付けた前記大判プリント紙撮影画像に含まれる前記順序付けられた名前を文字認識により注文画像データ情報として特定する特定手段と、
   前記注文画像データ情報に基づいて、前記記憶された前記複数の画像データの中から前記注文画像データを特定し、前記特定した注文画像データを、前記送信されたメールアドレスに含まれるイベント特定情報と関連付けた注文情報として、注文データベースに蓄積する第２の特定手段と、
   前記注文データベースから前記蓄積した注文情報を読み取り、前記読み取った注文情報の前記第２の特定手段が特定した前記注文画像データを、前記プリントサイズで印刷する第２の印刷制御手段と、
   を備えることを特徴とするプリントシステム。
2. 前記所定の大判プリント紙はＡ０またはＢ０サイズの用紙である事を特徴とする請求項１に記載のプリントシステム。
3. 注文画像データとインデックスプリントをプリント装置でプリントするプリントシステムの制御方法であって、
   画像記憶手段が、カメラで撮像した複数の画像データを受け付け、前記複数の画像データの各画像データと前記各画像データの名前を順序付けてリネームして記憶する画像記憶工程と、
   第１の印刷制御手段が、前記記憶された前記各画像データと前記順序付けられた名前とを対応付けて配置し、前記注文画像データのプリントサイズと同様のサイズになるように、前記各画像データと前記順序付けられた名前を一覧にした印刷データを生成し、前記生成した印刷データおよび特定のイベントを判定可能なイベント特定情報をアカウントとして使用したメールアドレスを含む注文受け付けのためのインデックスプリントを所定の大判プリント紙に印刷する第１の印刷制御工程と、
   受付手段が、前記メールアドレス宛てに送信された前記大判プリント紙に印刷された前記順序付けられた名前を撮影した大判プリント紙撮影画像を含む注文を受け付ける受付工程と、
   特定手段が、前記受付工程で受け付けた前記大判プリント紙撮影画像に含まれる前記順序付けられた名前を文字認識により注文画像データ情報として特定する特定工程と、
   第２の特定手段が、前記注文画像データ情報に基づいて、前記記憶された前記複数の画像データの中から前記注文画像データを特定し、前記特定した注文画像データを、前記送信されたメールアドレスに含まれるイベント特定情報と関連付けた注文情報として、注文データベースに蓄積する第２の特定工程と、
   第２の印刷制御手段が、前記注文データベースから前記蓄積した注文情報を読み取り、前記読み取った注文情報の前記第２の特定工程が特定した前記注文画像データを前記プリントサイズで印刷する第２の印刷制御工程と、
   を含むことを特徴とする制御方法。
4. 注文画像データとインデックスプリントをプリント装置でプリントするプリントシステムで読み取り実行可能なプログラムあって、
   カメラで撮像した複数の画像データを受け付け、前記複数の画像データの各画像データと前記各画像データの名前を順序付けてリネームして記憶する画像記憶手段と、
   前記記憶された前記各画像データと前記順序付けられた名前とを対応付けて配置し、前記注文画像データのプリントサイズと同様のサイズになるように、前記各画像データと前記順序付けられた名前を一覧にした印刷データを生成し、前記生成した印刷データおよび特定のイベントを判定可能なイベント特定情報をアカウントとして使用したメールアドレスを含む注文受け付けのためのインデックスプリントを所定の大判プリント紙に印刷する第１の印刷制御手段と、
   前記メールアドレス宛てに送信された前記大判プリント紙に印刷された前記順序付けられた名前を撮影した大判プリント紙撮影画像を含む注文を受け付ける受付手段と、
   前記受付手段が受け付けた前記大判プリント紙撮影画像に含まれる前記順序付けられた名前を文字認識により注文画像データ情報として特定する特定手段と、
   前記注文画像データ情報に基づいて、前記記憶された前記複数の画像データの中から前記注文画像データを特定し、前記特定した注文画像データを、前記送信されたメールアドレスに含まれるイベント特定情報と関連付けた注文情報として、注文データベースに蓄積する第２の特定手段と、
   前記注文データベースから前記蓄積した注文情報を読み取り、前記読み取った注文情報の前記第２の特定手段が特定した前記注文画像データを前記プリントサイズで印刷する第２の印刷制御手段と、
   して機能させることを特徴とするプログラム。

Images