JP4532885B2

JP4532885B2 - サーバコンピュータ及び、サーバコンピュータによりページデータを通信端末へネットワークを介して提供する方法

Info

Publication number: JP4532885B2
Application number: JP2003401629A
Authority: JP
Inventors: 仁砂田
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 2003-12-01
Filing date: 2003-12-01
Publication date: 2010-08-25
Anticipated expiration: 2023-12-01
Also published as: JP2005165530A

Description

本発明は、ユーザ端末、特に携帯電話のような表示部の小さな情報通信端末からサービスなどの注文をオンラインで受け付けるための情報処理装置および情報処理方法に関するものである。

従来、インターネットなどのネットワークを介して、ユーザの情報通信端末から画像をハガキに印刷するサービスなど、各種サービスの注文を受け付けるサイトが知られている。このようなサイトから注文を行う場合、ユーザがそのサイトにアクセスすると、サーバから端末に対して、端末上で表示される画面が記述されたデータが送信される。端末ではそのデータをブラウザにより解釈して表示する。そしてその画面には、注文のための種々の情報をユーザが入力する欄と、入力済みの情報をサーバに送信するきっかけを端末にユーザが与えるための欄等が設けられている。ユーザはそれらの欄に必要な事項を入力してサーバに送信する。
特開2003-281029号公報

しかしながら、ユーザの情報通信端末が携帯電話などのように、一度に表示できる画面量や色数の制限、スクリプトの未搭載、クッキー機能がないなど表示能力に制限のあるものであった場合、何度も同じ情報を入力しなければならなかったり、小さい画面なのでスクロールしながらの入力作業をしなければならなかったり、文字入力が簡便でなかったりするなど、ユーザの操作の負担が過大になるという問題があった。もちろん、携帯電話でなくとも、表示部のサイズが小さな、たとえばＰＤＡと呼ばれる小型情報端末や、据置き型のブラウザフォン等についても同様である。

また、携帯端末に搭載されているブラウザソフトはPersonal Computer（ＰＣ）に搭載されているブラウザソフトに比べて、利用可能なタグや属性などが少ないため、表現能力が貧弱で、エラーなどのイベント発生時にユーザに通知するための表現方法には制限が大きかった。また、色やフォントの太字、イタリックなど文字種を変更し注意を喚起させるように表現されても、携帯端末のディスプレイの表示サイズが小さいためユーザが見辛かったり、見落とされたりしてしまうという問題があった。

また、スクリプトを搭載していないために、サービスを注文するたびにサーバに接続する必要があり、回線料金（回線交換代、パケット代など）も発生し、ユーザに過大なコストを負担させてしまうという問題があった。

また、一度に表示される画面情報量を少なくする方法も考えられるが、住所や名前など複数の項目を入力させるような場合に、複数の画面に分割してしまうと、既に入力された項目の情報を確認できないため、既に入力した項目の情報を変更したい場合にユーザにとって操作しづらく、不都合であるという問題があった。

本発明は、上記従来技術の課題を解決するために成されたもので、その目的とするところは、ユーザが一度入力したデータの再利用を可能にするとともに、その変更も容易にすることである。また、入力に失敗したデータの再入力を促す際に、ユーザの負荷を軽減させ使い勝手の良いインタフェースを提供することにある。

上記目的を達成するために本発明は以下のような構成を有する。

ページデータを通信端末へネットワークを介して提供するサーバコンピュータであって、
複数の項目の入力フィールドを所定の順で配置し、スクロールして画面に表示するためのページデータを前記通信端末へ送信する送信手段と、
前記入力フィールドに入力されたデータを前記通信端末から受信する受信手段と、
前記受信されたデータに基づき、前記項目の入力フィールドに再入力が必要か否かを判定する判定手段と、
前記判定の結果、再入力が必要と判定された複数の項目の入力フィールドを含む第１のフィールド群を、再入力が不要と判定された複数の項目の入力フィールドを含む第２のフィールド群よりも前に配置し、前記第１のフィールド群では前記再入力が必要と判定された複数の項目の入力フィールドを前記所定の順にしたがって配置し、前記第２のフィールド群では前記入力が不要と判定された複数の項目の入力フィールドを所定の順にしたがって配置し、スクロールして画面に表示されるように前記複数の項目の入力フィールドを並べ替えて前記ページデータを変更する変更手段とを備え、
前記送信手段は、さらに前記変更されたページデータを前記通信端末へ送信する。

本発明によれば、画面表示データ量に制限のある機器における情報入力処理において、入力の誤りなどが発生した場合の操作性の向上を図ることができる。また、色など、端末の持つ表現能力の制約にかかわらず、再入力の必要な項目について利用者の注意を喚起することができ、相違で端末ごとにばらつきに影響されることがない。さらに、データ量を増やすことなく、操作性の向上や端末に対する非依存性の獲得を実現できる。

以下に、図面を参照して、本発明の好適な実施形態を例示的に詳しく説明する。ここでは、本発明を実施する一実施形態の情報処理システムとして、インターネットを介して画像データの共有及び提供を行う情報提供システムを例に説明する。

（情報提供システムの概要）
図１は、本実施形態に係る情報提供システムの構成例を示す図である。本実施形態の情報提供システムは、ユーザからの画像及び個人情報などを管理するサービスを提供するフォトサイト１０５と、フォトサイト１０５が管理する画像をプリント処理するプリントサイト１０９と、印刷物の対価としてユーザからお金を直接受ける店舗１２１と、入金処理を行う決済サイト１２０と、サービスの提供を受けるユーザのパーソナルコンピュータ（ＰＣ）１０２（以下、ユーザＰＣと略す）と、携帯端末１１３とを含む。また、ユーザＰＣ１０２には、イメージ情報である光学像を電気信号に変換し、所定の画像処理をした後、デジタル情報として記録・再生するデジタルカメラ１０１が接続されている。なお、デジタルカメラに限らず、スキャナなどの画像入力装置をユーザＰＣ１０２に接続しても良い。また、データ転送用インタフェース１１６は、デジタルカメラ１０１からユーザＰＣ１０２の記憶領域へ画像データを転送するためのインタフェースである。データ転送用インタフェース１１６としては、ユニバーサルシリアルバス（ＵＳＢ）やＩＥＥＥ１３９４に代表される有線インタフェースや、ＩｒＤＡやＢｌｕｅｔｏｏｔｈに代表される無線系インタフェースを用いることができる。

フォトサイト１０５は、インターネット１０４上のサーバ内あるいはサーバと接続された記憶領域に、ユーザのデジタルカメラ１０１で撮影された画像データを保管し、保管された画像データをユーザが閲覧できるようなサービスや、保管された画像データのプリント注文を受け付けるサービスや、保管された画像データをユーザの指定した招待ユーザが閲覧できるようなサービスを提供する。尚、本実施形態に係るフォトサイト１０５は、独自にはプリントサービスは行わず、様々なプリントサービスを提供できるプリントサイト１０９と提携している。

又、本実施形態に係るフォトサイト１０５は、独自には決済サービスは行わず、代金を回収する決済サイト１２０と提携している。本実施形態に係るフォトサイト１０５は、印刷物の代金の入金情報を待って、そのプリントサイト１０９に対して画像データの印刷を依頼する。又、プリントサイト１０９は、インターネット１０４を利用して転送された年賀状やワープロ文書、画像などの電子ドキュメントを印刷装置を用いてプリントアウトし、印刷物１１２を商品としてユーザに提供する。

ユーザＰＣ１０２上では、インターネット１０４での情報転送可能な標準プロトコルを有するＷｅｂブラウザが動作可能である。このＷｅｂブラウザによって、ｈｔｔｐプロトコル等の標準プロトコルを用いてフォトサイト１０５にアクセスし、ＨＴＭＬ、ＸＭＬ等の記述言語で作成されたＷｅｂ情報を表示させることができる。そのＷｅｂ情報は、フォトサイト１０５が管理する画像や音声等のマルチメディア情報にリンクされている。この動作により、ユーザＰＣ１０２のユーザは、インターネット１０４を利用してフォトサイト１０５が提供するサービスを受けることができる。

（フォトサイトを構成するサーバのハードウエア構成例）
図２は、本実施形態のフォトサイト１０５を構成するサーバのハードウエア構成例を示す図である。尚、図２は、制御部を中心に示しており、入出力装置などは省略してある。また、フォトサイト１０５は、各種機能を実行する複数のサーバ装置がローカルエリアネットワーク（ＬＡＮ）に接続されて構成されている。なお、インターネットを介して実際に端末等と通信するのはフォトサイト１０５のサーバコンピュータであるが、そのサーバコンピュータのことをフォトサイト１０５と呼ぶことがある。

中央処理装置（ＣＰＵ）２１０は、プログラムを実行してサーバ装置全体を制御するための制御装置である。ＲＯＭ２２０には、変更を必要としないプログラムやパラメータが格納されている。ＲＡＭ２３０はプログラムやデータを一時記憶する記憶領域である。外部記憶装置２４０は、固定されたハードディスクやメモリカード、あるいは着脱可能で携帯可能なフロッピー（登録商標）ディスク（ＦＤ）やコンパクトディスク（ＣＤ）等の光ディスク、磁気や光カード、ＩＣカード、メモリカードなど、不揮発性のファイル装置である。外部記憶装置２４０はデータ記憶領域とプログラム記憶領域からなる。尚、ＲＯＭ２２０やＲＡＭ２３０、特に外部記憶装置２４０は複数の装置に分散されて構成されていてもよく、また、サーバ装置の外部に存在し、サーバ装置と通信可能に接続される構成であってもよい。

（画像の保管サービス）
ユーザは、ユーザが保有する画像をフォトサイトにアップロードしてその保管等を依頼できる。その際、ユーザＰＣ１０２からフォトサイト１０５にアクセスし、その意思を示す情報をフォトサイト１０５のサーバに送信すると、フォトサイト１０５のサーバから、ユーザインターフェースとなる画面情報がユーザＰＣ１０２に送信され、Ｗｅｂブラウザにより表示される。Ｗｅｂブラウザに表示される情報に従って、ユーザＰＣ１０２の情報記憶領域に格納されている画像データから転送したい画像データが選択され、画像アップロードの要求アクションに連動してインターネット１０４を介してフォトサイト１０５が管理する画像ＤＢ１１７に転送される。あるいは、Ｗｅｂブラウザに表示される情報ではなく、ユーザＰＣ１０２にインストールされた画像アップロード専用ソフトウェアに従って転送されるようにしてもよい。いずれの方法も、インターネット１０４上で利用可能なプロトコル、例えばｈｔｔｐやｆｔｐなどに基づいて実行される。

フォトサイト１０５はユーザＰＣ１０２からアップロードされた画像データを画像ＤＢ１１７に保管する。尚、フォトサイト１０５は、ユーザＰＣ１０２からアップロードされた画像データを、複数をひとつの単位としてまとめたアルバムとして管理することもできる。また、フォトサイト１０５には、画像データを管理するだけでなく、画像データの属性情報や各種データを一元管理している。例えば、各種データとしては、フォトサイト１０５にアクセスしてくるユーザの認証に使用するためのユーザの属性情報や、保管された画像データの印刷を依頼するプリントサイト１０９の属性情報などである。また、画像データをアップロードする端末として、ＰＣを例に挙げて説明したが、これに限定されるものではなく、携帯端末１１３、例えば携帯電話、或は、デジタルカメラ、デジタルビデオ、スキャナ、複写機等の画像入力装置からアップロードしてもよい。

（画像の閲覧サービス）
ユーザがフォトサイト１０５の画像を閲覧する場合には、ユーザは、ユーザＰＣ１０２上で動作しているＷｅｂブラウザを用いてフォトサイト１０５にアクセスし、フォトサイト１０５に保管されている画像データの閲覧要求を行う。次に、フォトサイト１０５は、ユーザ認証などを実行した後、ユーザＰＣ１０２のＷｅｂブラウザ上に画像を表示させるためのＷｅｂページ情報をインターネット１０４へ送出する。ユーザＰＣ１０２のＷｅｂブラウザはフォトサイト１０５から送出されたＷｅｂページ情報を解析し、画像を表示する。また、ユーザが指定する招待ユーザに対し、フォトサイト１０５の画像ＤＢ１１７に保管された画像またはアルバムを閲覧できるようにするには、ユーザはユーザＰＣ１０２のＷｅｂブラウザに表示された、フォトサイト１０５から提供された入力画面に招待ユーザの電子メールアドレスを入力してフォトサイト１０５に通知する。

フォトサイト１０５は招待ユーザに閲覧させる画像またはアルバムにアクセスするためのユニバーサルリソースロケータ（ＵＲＬ）を生成する。そして、生成されたＵＲＬを電子メールのメッセージ中に記載して招待ユーザに送信する。フォトサイト１０５からの電子メールを受け取った招待ユーザは、ユーザＰＣ１０２‘のＷｅｂブラウザに電子メールに記載されたＵＲＬを入力することで、フォトサイト１０５にアクセスして画像又はアルバムを表示させることができる。尚、上記では、ユーザおよび招待ユーザはＰＣを用いて画像を閲覧する例について説明したが、ＰＣの場合と同様にして携帯電話１１３を用いることができることは明らかである。

（画像のプリント注文受付サービス）
ユーザは、ユーザＰＣ１０２や携帯端末１１３を操作し、フォトサイト１０５により発行されたＵＲＬをＷｅｂブラウザに入力することにより、フォトサイト１０５の画像ＤＢ１１７に保管されたアルバムの画像データを閲覧できる。図１０はアルバム閲覧時に携帯端末１１３のディスプレイに表示されるログイン画面である。ユーザは携帯端末１１３を操作してパスワード入力領域１００１に適切なパスワードを入力し、「ＯＫ」ボタン１００２を押下することで、アルバム内の画像を閲覧することができる。尚、フォトサイト１０５は携帯端末１１３から新規のアクセスを受けると、当該アクセスを一意に識別するためのセッションＩＤを発行し、ＭＢセッション情報テーブル６００（図６）に新規レコードを作成して、セッションＩＤ６０１、最終アクセス日時６０２、アクセス日時６０３にそれぞれ値を格納する。また、セッションＩＤは携帯端末１１３に通知され、以後、携帯端末１１３はＵＲＬのパラメータ部にこのセッションＩＤを含むＵＲＬを用いてフォトサイト１０５にアクセスする。このように、セッションＩＤを利用して携帯端末１１３とフォトサイト１０５とが通信することにより、フォトサイト１０５は携帯端末１１３からの連続したアクセスであることを認識でき、また、携帯端末１１３からのアクセスを管理することができる。そして、ユーザは閲覧したアルバムの画像のプリント注文をフォトサイト１０５に行うことができる。

図３は、フォトサイト１０５のサーバが実行するプリント注文受付処理を説明するためのフローチャートである。ユーザが閲覧中のアルバムに対してプリント注文を行う場合、図１１の画像閲覧画面１１００内の「プリント注文」リンク１１０９を押下する。「プリント注文」リンク１１０９が押下されると、入力されている枚数とともに、「プリント注文」が押下されたことを示す情報をフォトサイト１０５に送信する。

フォトサイト１０５は、端末から情報を受信し、その内容を調べて「プリント注文」リンク９０９が押下されたことを検知する（ステップＳ３０１）。図３の手順は端末からの情報の受信から開始される。なお、図３のステップＳ３０１ではプリント枚数を受信するまで処理がループしているが、これは表記上の便宜であって、他の処理ができないことを意味するわけではない。

フォトサイト１０５は、携帯端末１１３でプリント注文リンク１１０９が押下されたことを検知すると、携帯端末１１３のディスプレイに一括プリント注文画面１２００（図１２）を表示するための画面データを送出する（ステップＳ３０２）。そして、携帯端末１１３のＷｅｂブラウザはフォトサイト１０５からの画面データを解析し、ディスプレイに一括プリント注文画面１２００を表示する。ユーザは一括プリント注文画面１２００にしたがって、閲覧していたアルバムに含まれる全画像データに対するプリントサイズとプリント枚数を指定する。また、フォトサイト１０５は、本プリント注文に対して新たな注文番号を発行してデータベース１１８内の注文情報テーブル７００（図７）に新規レコードを作成する（ステップＳ３０３）。尚、発行した注文番号は、後述するプリント注文関連の画面内に埋め込まれる各種ＵＲＬパラメータ部分に常に付加される。

図７は、本実施の形態におけるフォトサイト１０５で管理する注文情報テーブルを示した図である。注文情報テーブル７００は、アルバムのプリント注文があると１オーダにつき１レコード作成され、データベース１１８に登録され管理される。プリント注文ごとに発行される注文番号７０１をキーとして、注文者ＩＤ７０２、配送先氏名７０３、配送先郵便番号（１、２）７０４、７０５、配送先都道府県コード７０６、配送先住所（１、２）７０７、７０８、配送先電話番号（１、２、３）７０９、７１０、７１１、注文日時７１３が保管される。

ユーザが携帯端末１１３を操作し、一括プリント注文画面１２００のプルダウンメニュー１２０２を押下することで、各種プリントサイズがリスト状に表示され、その中から所望のプリントサイズが選択される。各種プリントサイズには、例えば、ＤＰ判フチなし、ＤＰ判フチあり、Ｌ判フチなし、Ｌ判フチあり、２Ｌ判フチなし、２Ｌ判フチあり、などがある。続いて、ユーザは携帯端末１１３を操作し、一括プリント注文画面１２００の枚数入力領域１２０３に所望のプリント枚数を入力する。プリントサイズの選択およびプリント枚数の入力が完了すると、ユーザは携帯端末１１３を操作し、「すすむ」ボタン１２０４を押下する。

フォトサイト１０５は携帯端末１１３で「すすむ」ボタン１２０４が押下されたか、「こちらへ」ボタン１２０５が押下されたか、「注文取消し」リンク１２０６が押下されたかを検知する（ステップＳ３０４）。フォトサイト１０５は、「注文取消し」リンク１２０６が押下されたことを検知すると、プリント注文処理をキャンセルする。また、携帯端末１１３のディスプレイは画像閲覧画面１１００の表示へ戻る。この際、画像閲覧画面１１００に表示する画像は、プリント注文処理へ入る直前に表示していた画像である。

フォトサイト１０５は、携帯端末１１３で「こちらへ」ボタン１２０４が押下されたことを検知すると、アルバム内のいくつかの画像のみ選択的にプリント注文する、あるいはアルバム内の画像毎に異なるプリント枚数を指定することのできる個別プリント注文画面１３００（図１３）を携帯端末１１３のディスプレイに表示させるための画面データを送出する（ステップＳ３０５）。

個別プリント注文画面１３００では、ユーザが閲覧しているアルバム内の画像の画像名１３０２がリスト状に表示されていて、プリント注文したい画像の枚数入力領域１３０３に所望の枚数を入力することで、画像毎にプリント枚数を指定することができる。枚数入力領域１３０３に入力された枚数は、「設定更新」ボタン１３０４が押下されると、携帯端末１１３のＷｅｂブラウザからフォトサイト１０５へ送出される。

本実施形態では、プリントサイズの指定は一括プリント注文画面１２００で行われ、個別プリント注文画面１３００では指定しないようにしているが、これは特に限定されるものではない。又、本実施形態では、個別プリント注文画面１３００の一画面中に表示する画像名は最大５つまでとしており、アルバム内にこれより多くの数の画像がある場合、複数ページに跨って画像名のリストを表示しているが、一画面中に表示する画像名の数も特に限定されるものではない。又、ページ番号１３０５は、複数ページに跨って画像名のリストを表示する場合の現在表示中のページを表している。又、「前へ」リンク１３０６、「次へ」リンク１３０７を押下することで、ページ間の移動が行われる。更に、ページ番号指定領域１３０８に移動先のページ番号を入力して表示ボタン１３０９を押下することで、指定したページ番号のページへ移動することができる。尚、個別プリント注文画面１３００の一画面中に表示する画像名が５つ以下の場合、「設定更新」ボタン１３０４、「前へ」リンク１３０６、「次へ」リンク１３０７、ページ番号指定領域１３０８、「表示」ボタン１３０９は無い。又、画面上に表示している画像名自体もリンクになっており、ユーザが携帯端末１１３を操作してこのリンクを押下することで、携帯端末１１３のディスプレイの表示は画像確認画面１４００（図１４）へ遷移する。又、個別プリント注文画面１３００で「戻る」リンク１３１２が押下されると、携帯端末１１３のディスプレイの表示は一括プリント注文画面１２００へ遷移する。

図１４の画像確認画面１４００は、ユーザがプリントを所望する画像を実際に見て確認するための画面である。この画面には、画像ＤＢ１１７に格納された画像や画像名、画像ページ番号、画像サイズ、プリント回数が表示される。「戻る」リンク１４０１を押下すると個別プリント注文画面１３００へ遷移する。一括プリント注文画面１２００または個別プリント注文画面１３００で「すすむ」ボタン１２０４または１３１０が押下されると、フォトサイト１０５は、注文画像データテーブル１２００に注文された画像数分のレコードを作成し、選択されたプリントサイズと入力されたプリント枚数を格納する（ステップＳ３０６）。また、個別プリント注文画面１３００で「設定更新」ボタン１３０４が押下されると、フォトサイト１０５は携帯端末１１３から入力されたプリント枚数を受け付けることができ、プリント枚数を格納する。

図９は、本実施の形態におけるフォトサイト１０５で管理する注文画像データテーブルを示した図である。注文画像データテーブル９００は、アルバムの画像に対するプリント注文があると、注文される画像に対応する画像数分だけのレコードが作成され、データベース１１８に登録され管理される。注文画像データテーブル９００には、注文番号９０１をキーとしてプリントサイト１０９の受付番号９０２、印刷オーダ単位で管理する画像番号９０３、プリント注文用にコピーしたサムネイル画像、オリジナル画像、及びプレビュー表示用画像のファイルパス９０４、９０５、９０６、プリント枚数９０７、プリントサイズ９０８、プリントタイプ９０９、画像ＩＤ９１０を管理する。プリントサイズ９０８には"１"はＬ判、"２"は２Ｌ判、"３"は官製はがきサイズ、"４"は私製はがきサイズ、"５"はＡ４サイズを意味するという値が格納される。又、プリントタイプ９０９では、"０"は縁無しプリント、"１"は縁有りプリントを意味するという値が格納される。なお、同一の注文では注文番号９０１と注文番号５０１は同一の番号が格納さる。画像ＩＤ９１０は、画像ＤＢ１１７に格納されたアルバムの画像を一意に識別するための画像ＩＤが保持される。フォトサイト１０５は、携帯端末１１３のディスプレイに注文者情報入力画面１５００（図１５）を表示するための画面データを送出する（ステップＳ３０７）。

フォトサイト１０５は、携帯端末１１３からのアクセスに用いられたＵＲＬのパラメータ部に含まれるセッションＩＤをキーにしてＭＢセッション情報テーブル６００（図６参照）から対応するセッションＩＤ４０１を有するレコードを探し出す。そして、該当するレコードがあり、注文番号６０６に値が格納されていれば、その注文番号６０６をキーにして注文情報データテーブル９００から対応する注文番号７０１を有するレコードを探し出す。そして、該当するレコードがあり、その注文者ＩＤ７０２に値が格納されていれば、その注文者ＩＤ７０２をキーにして注文者データテーブル８００から対応する注文者ＩＤ８０１を有するレコードを探し出す。そして、該当するレコードの情報を注文者情報入力画面１５００上に表示する。

このようにして、セッションＩＤを元に注文者情報を取得することができるので、同一のユーザが同一セッションＩＤのアクセスでプリント注文を複数回連続して行うような場合、直前に入力した注文者の情報が予め注文者情報入力画面１５００上に表示することができるので、ユーザに何度も同じ情報の入力させるという手間を省くことができる。尚、新規のアクセスで初めてのプリント注文であれば、未だＭＢセッション情報テーブル６００の注文番号６０６に値が格納されていないので、再利用できる情報が無いため、注文者情報入力画面１５００には空欄が表示される。

図８は、本実施の形態におけるフォトサイト１０５で管理する注文者データテーブルを示した図である。注文者データテーブル８００は、アルバムのプリント注文があると１オーダにつき１レコード作成され、データベース１１８に登録され管理される。注文者データテーブル８００では注文者ＩＤ８０１をキーとして、ユーザＩＤ８０２、通知先メールアドレス８０３、氏名（姓）８０４、氏名（名）８０５、ふりがな（姓）８０６、ふりがな（名）８０７、郵便番号（１、２）８０８、８０９、都道府県コード８１０、住所（１、２）８１１、８１２、電話番号（１、２、３）８１３、８１４、８１５を管理する。なお、同一の注文においては、注文社データテーブルの注文者ＩＤ８０１と注文情報データテーブルの注文者ＩＤ７０２（図７）には同じＩＤが格納される。

ユーザは、携帯端末１１３のディスプレイに表示された注文者情報入力画面１５００の指示に従って姓名１５０２および１５０３、姓名のフリガナ１５０４および１５０５、郵便番号１５０６、住所１５０７〜１５０９、電話番号１５１０、メールアドレス１５１１、配送方法１５１２、配送先１５１３を入力し、「すすむ」ボタン１５１４を押下する。ここで、フォトサイト１０５は「すすむ」ボタン１５１４が押下されたかどうか検知する（ステップＳ３０８）。尚、ユーザは過去に入力された情報が予め表示されている項目については、特に入力する必要はないが、修正や変更があれば、再度、入力することもできる。「すすむ」ボタン１５１４が押下されていれば、フォトサイト１０５は、入力された情報に不備がないかどうかをチェックする（ステップＳ３０９）。

そして、入力された情報に不備がなかった場合、フォトサイト１０５は、注文者情報テーブル８００に新たなレコードを生成し、入力されたデータを格納する（ステップＳ３１０）。この時、生成した新規レコード内の注文者ＩＤフィールド８０１には、新たに割り振った注文者ＩＤが格納されている。更に、新たに割り振った注文者ＩＤを、ステップＳ３０１にて作成済みの注文情報データテーブル７００のレコード内の注文者ＩＤフィールド７０２に格納する。また、現在のセッションに対応するセッション情報テーブル６００内の注文番号フィールド６０６に、現在処理中の注文に対応する注文番号を格納する。尚、この注文番号は注文者情報入力画面１２００が呼び出された際のＵＲＬパラメータに含まれているもので、前述のステップＳ３０３にて発行した注文番号である。これにより、ＭＢセッション情報テーブル６００内のセッション情報から、対応する注文情報データテーブル７００内の注文情報や、注文者データテーブル８００内の注文者情報を辿ることが可能となる。もしも、注文番号フィールド６０６に既に注文番号が格納されていた場合には、新規に発行した注文番号で上書きする（ステップＳ３１０）。

フォトサイト１０５は、ユーザの操作によって「すすむ」ボタン１５１４が押下されたことを受けると、配送先１５１３として「注文者と同じ」が選択されたか、「配送先を指定」が選択されたかをチェックする。「配送先を指定」が選択されていれば、フォトサイト１０５は携帯端末１１３のディスプレイに表示される画面を図１６の配送先入力画面１６００へ遷移するためのＷｅｂページデータを出力する。配送先入力画面１６００では、注文者情報入力画面１５００と同様にして、セッションＩＤをキーにして注文情報データテーブル７００から対応する注文情報レコードを探し出し、該当するレコードの配送先情報７０３〜７１１に情報が格納されている場合には、それらが表示される。このことにより、同一セッション内でプリント注文を複数回行うような場合、直前に入力した配送先情報が予め表示されるため、ユーザは再度、配送先の入力を行うという手間を省くことができる。尚、配送先入力画面１６００においても注文者情報入力画面１５００と同様に入力されたデータに不備があるかどうかチェックが行なわれ、そのチェック結果に応じた処理も同様に実行される。そして、配送先入力画面１６００で入力されたデータを注文情報データテーブル７００に格納する。一方、「注文者と同じ」が選択されていれば、注文者データテーブル８００の該当するレコードの値を注文情報データテーブル７００に格納する（ステップＳ３１１）。なお、「すすむ」ボタン１５１４ではなく、「戻る」リンク１５１６が押下されると、携帯端末１１３のディスプレイに表示されている画面は注文者情報入力画面１５００から、その直前に表示していた一括プリント注文画面１２００か個別プリント注文画面１３００のどちらかへ遷移する。

そして、フォトサイト１０５は携帯端末１１３のディスプレイに表示される画面を図１８の見積もり表示画面１８００に遷移するためのＷｅｂページデータを出力する（ステップＳ３１２）。ここで、フォトサイト１０５は見積もり表示画面１８００に表示するために商品価格や送料、各種手数料を合計し、利用金額を算出して、表示させる。

見積もり表示画面１８００で「戻る」リンク１８０４が押下されると、携帯端末１１３のディスプレイの表示は、直前に表示されていた注文者情報入力画面１５００か配送先入力画面１６００かのどちらかへ遷移する。また、「注文取消し」リンク１８０３が押下されると、フォトサイト１０５はプリント注文処理をキャンセルし、携帯端末１１３のディスプレイの表示を画像閲覧画面１１００へ戻す。この画像閲覧画面１１００で表示する画像は、プリント注文処理へ入る直前に表示していた画像である。

見積もり表示画面１８００で「注文する」ボタン１８０２が押下されると、フォトサイト１０５はユーザに選択された画像が画像ＤＢ１１７内にあるか否かをチェックする（Ｓ３１３）。画像が無い場合、携帯端末１１３のディスプレイにエラー画面を表示させた後、再度、一括プリント注文画面１２００を表示させてユーザに画像選択を促す。

画像があれば、図１９の注文確認画面１９００を携帯端末１１３のディスプレイに表示させ、プリント注文要求を受け付けた旨をユーザに通知する。そして、フォトサイト１０５はプリントオーダーファイル作成処理を行う（ステップＳ３１４）。ここで、プリントオーダーファイルは、印刷する画像データ、プリント枚数、プリントサイズ、注文者情報、配送先情報、利用金額などの情報を１つのファイルにまとめたものである。

続いて、フォトサイト１０５は、決済サイト１２０に利用金額を通知する（ステップＳ３１５）。決済サイト１２０は、通知された利用金額を受け付ける処理を行った後に、その確認番号をフォトサイト１０５に通知する。これにより、フォトサイト１０５はプリント注文の決済が完了したことを確認することができる。尚、決済サイト１２０が通知された利用金額を受け付ける処理とは、具体的には、クレジット会社からユーザの与信を受ける処理や、ユーザによって銀行振込やコンビニエンスストアでの支払いが完了したという通知を各金融機関から受ける処理などがある。

そして、フォトサイト１０５はプリント注文の決済が完了したことを確認すると、プリント要求とともに、ステップＳ３１４で作成したオーダーファイルをプリントサイト１０９に転送する（ステップＳ３１６）。プリント要求を受けたプリントサイト１０９は、プリンタで画像データを印刷し、印刷物１１２を得る。そして、プリントサイト１０９のオペレータはオーダーファイルで指定された配送先に印刷物１１２を配送する。

なお、注文確認画面１９００の終了ボタン１９０２が押下されると、ユーザはプリント注文処理を完了して、携帯端末１１３のディスプレイに表示される画面を画像閲覧画面１１００へ戻すことができる。この画像閲覧画面１１００で表示される画像は、プリント注文処理へ入る直前に表示していた画像である。

（再入力手順）
一方、ステップＳ３０９にて入力された情報に不備があったと判定された場合に、フォトサイト１０５で実行される処理について説明する。尚、未入力の項目があった場合や指定外文字種が入力されている場合等に入力された情報に不備があるとチェックされる。具体的に、ステップＳ３０９では、未入力の項目がないか、入力されたデータの半角全角が適切であるか、入力されたデータのデータ量がオーバーしていないか、県名が正しく入力されているかなどをチェックする。尚、項目ごとに必須か否かを設定することができ、必須で無い項目であれば、データが入力されていなくても不備であるとはチェックされない。また、半角全角のどちらが適切であるか、データ量の上限または下限等の入力値条件は項目ごとに設定されている。

フォトサイト１０５は不備が無かった項目のデータを注文者情報テーブル８００に格納する（Ｓ３１７）。以降、携帯端末１１３のディスプレイに注文情報の再入力を促す再入力要求画面２０００（図２０）を表示するための画面データを出力するための処理を実行する。フォトサイト１０５は、不備の無かった項目のデータは、既に受け付けられたデータとして再入力要求画面２０００に表示させるが、不備があった項目については、再度入力を要求するために未入力の空欄状態で表示される。これは１つの画面で、再入力が要求される項目の入力と、不備の無かったデータの修正も入力できるようにするためである。

また、携帯端末１１３のような、ディスプレイが小さいために表示能力が低く、また、ポインティングデバイスやキーボードを持たないために入力能力も低いデバイスでは、入力間違いは頻繁に行なわれると想定される。そこで、本発明では、特に、制限された表示能力の中で効率的にユーザに再入力を促す仕組みを提供することを目的としている。

ここで、フォトサイト１０５が作成するＷｅｂページデータの内容について説明する。フォトサイト１０５は、携帯端末１１３のディスプレイに各種画面を表示させるために、携帯端末１１３のブラウザが解析可能なＨＴＭＬのフォーム機能を用いてＷｅｂページデータを作成し、携帯端末１１３に提供する。

注文者情報入力画面１５００のＷｅｂページデータ（たとえばＣｏｍｐａｃｔＨＴＭＬで記述されたデータ）の一例を図２２に示す。図２２ははＨＴＭＬで記述されたデータの例であるので、まず簡単に図２２で用いられているエレメントについて説明する。図２２は、後述のとおり、端末にブラウザによって注文者情報を入力させるための画面を表示させる部分のみを示しており、この前後にそのほかのエレメントが記述される場合もある。フォームタグ＜ＦＯＲＭ＞＜／ＦＯＲＭ＞により記述されるフォームエレメントは、ブラウザにより入力欄を表示させるための要素である。フォームエレメント内には、個々の入力項目を記述するためのインプットエレメントが含まれ、インプットタグ（＜ＩＮＰＵＴ＞）で記述される。インプットエレメントにはタイプ属性（「ｔｙｐｅ＝」により記述）、値属性（「ｖａｌｕｅ＝」で記述）、名前属性（「ｎａｍｅ＝」で記述）などが含まれる。タイプ属性は入力されるデータ型を記述するための属性で、ｔｅｘｔであれば、テキストボックスがブラウザにより表示されて文字列の入力を許し、ｒａｄｉｏｂｕｔｔｏｎであれば、択一的に選択可能なラジオボタンが表示されてその選択が許され、ｓｕｂｍｉｔであれば、そのフォームエレメントで入力されたデータの転送指示をするための転送ボタンが表示され、その押下が許される。転送ボタンが押されれば、入力されたデータがサーバに送信される。値属性としては、タイプ属性がラジオボタンであれば、選択されたラジオボタンに対応する値が指定され、サブミットであれば、転送ボタンの名称が指定される。名前属性は、入力されたデータが参照される名前を示す。また「ｃｈｅｃｋｅｄ」の指定は、入力欄表示時に既にチェックされている欄の指定を示す。なお、フォームエレメントにおいて入力されるデータには、データの項目としては独立していても、入力欄としては一体化して扱う方が好都合なものがある。たとえば、ユーザ氏名は、姓と名とが独立したデータとして入力されるが、入力画面においては、一体としてひとつの入力欄を構成した方が都合がよい。そこで、これらをひとまとめにして入力ブロックと呼ぶことにする。すなわち、ひとつの入力ブロックには１乃至複数のインプットエレメントが含まれる。図２２の参照符号２２０１〜２２０８は、入力ブロックを示している。入力ブロックは、後述する入力欄の編集単位となる。もちろん、ひとつの入力エレメントをひとつの入力ブロックとして扱うこともできる。

図２２のＷｅｂページデータは、ユーザが携帯端末１１３を操作し、図１５の注文者情報入力画面１５００で示されるように、全ての項目が表示され、上部の項目から順にスクロールしながらデータを入力していき、下部の「すすむ」ボタンを押下できるようなレイアウトになるよう構成されている。具体的には、図２２に示されるようなフォームエレメント「＜ＦＯＲＭ＞ … 入力ブロック１ … 入力ブロック群 … 入力ブロックＸ … ＜ＩＮＰＵＴｔｙｐｅ＝ｓｕｂｍｉｔｖａｌｕｅ＝“すすむ” ｎａｍｅ＝ｐｒｉｎｔ＞＜／ＦＯＲＭ＞」で、端末に注文者情報入力画面を表示するためのデータは構成される。このように入力すべき項目が上部から順に表示され、「すすむ」ボタンが最下部に表示されるようなＷｅｂページデータをフォトサイト１０５は出力する。

一方、再入力要求画面２０００のＷｅｂページデータを出力する際には、フォトサイト１０５は判定処理Ｓ３１８で、再入力必須項目の数をチェックする。判定処理Ｓ１８０１での判定の結果、所定数以上の項目において不備があった場合には、フォトサイト１０５は、もう一度注文者情報入力画面１３００を表示するためのＷｅｂページデータを出力する（処理Ｓ３１９）。所定数としては、例えば、必須項目全ての数を設定するようにしてもよい。また、携帯端末１１３の表示能力に応じた数、例えば、スクロールせずに一度にディスプレイに表示される項目の数を設定するようにしてもよい。また、ここで表示させる注文者情報入力画面１５００では、最上部などユーザにとって分かりやすい任意の位置に再入力が必要である旨のメッセージを表示させるようにしてもよい。

一方、判定処理Ｓ３１８での判定の結果、不備があった項目の数が所定数未満であった場合には、フォトサイト１０５は注文者情報入力画面１３００のＷｅｂページデータ２１００のレイアウトを一部変更して、再入力要求画面２０００のＷｅｂページデータを出力するための処理を行う（Ｓ３２０）。フォトサイト１０５は、データ処理Ｓ３２０では注文者情報入力画面１５００の項目の表示順序を変更した再入力要求画面２０００（図２０）のＷｅｂページデータ（図２３）を出力する処理を行う。具体的な例として、判定処理Ｓ３１７で、「姓・名のフリガナ」、「メールアドレス」に入力されたデータに不備があったと判定されたとすると、フォトサイト１０５は、図２３に示すように、「姓・名のフリガナ」の入力ブロック２３０１、「メールアドレス」の入力ブロック２３０２を、フォームエレメントの先頭部分に移動した構成に変更したＷｅｂページデータを出力し、携帯端末１１３のディスプレイに「姓・名のフリガナ」、「メールアドレス」の入力フィールド（ＩＮＰＵＴ属性）を入力エラーのメッセージとともに上部に表示されるようにする。そして、ボタンに表示される名称も“再入力”（ｖａｌｕｅ＝“再入力”）と変更し、ユーザに対して注意喚起を促す。続けて、不備がなかった項目を順に表示するよう、Ｗｅｂページデータの構成を変更し、注文者情報テーブル６００のレコードの値をｖａｌｕｅ値として挿入した入力フィールド（ＩＮＰＵＴ属性値入り）を順に出力する。

図４に図３のステップＳ３２０におけるウエブページデータの編集処理手順の一例を、図５にその処理のために利用されるデータの一例を示す。図５のページデータ５１０は、編集前の原型となるテンプレートデータであり、図２２のＨＴＭＬデータに相当する。このデータは予め定義され、サーバのハードディスク等の保持されている。このテンプレートは、本実施形態ではウエブページデータのうち、フォームエレメントの部分に限られており、サーバがクライアントにウエブページデータを送信する際に、本来フォームエレメントが挿入されるべき位置に挿入されて送信される。

図５において、ウエブページデータ５１０は、入力ブロック定義データ５２０によって入力ブロック０〜入力ブロックＮに分割されている。入力ブロック定義データ５２０は、テンプレートデータの編集に用いられるデータであり、各入力ブロックの先頭ライン欄５２２と末尾ライン欄５２３とを含む。先頭ライン欄５２２および末尾ライン欄５２３は、テンプレートデータと共に定義されており、各ブロックの先頭を末尾とを定義している。ただし、入力ブロックの区切り目は１箇所でもよいので、先頭または末尾のいずれか一方のみの指定でも良い。入力フラグ欄５２１は、その入力ブロックのデータが全て入力されているか否かを示すデータであり、図３のステップＳ３０９において、入力データがすべて揃った入力ブロックについては「済」に相当する値が、揃っていないブロックについては「未」に相当する値が記録される。なお、ステップＳ３０９では、たとえば、各入力欄について、何らかのデータが単に入力されたか否かではなく、その形式をもあわせて判定するのが望ましい。たとえば、電話番号であれば、０から始まる一定桁数の数字であること、電子メールアドレスであれば「＠」が含まれ、それ以下がドメイン名の体裁をとること、フリガナであれば、カタカナのみであること、などがチェックされ、条件に合致しない項目は、「未」入力と判定されて、図５の入力ブロック定義欄の入力フラグに値「未」が記録されるようにしてもよい。

ステップＳ４０１では、入力ブロック定義データ５２０の先頭の項目を初期の着目入力項目とする。そして、テンプレートデータの先頭を初期の挿入位置とする。ステップＳ４０２では、編集処理が終了したか、すなわち入力ブロック定義データの末尾まで処理を終了したか判定する。終了していなければ、着目入力項目は入力フラグの値をテストし、「未」に相当する値であれば、着目入力項目に対応する入力ブロックを、現在の挿入位置に移動する。たとえば、着目入力項目が２番目の項目であり、現在の挿入位置がウエブページデータ５１０の先頭であれば、２番目の入力項目に対応する入力ブロックを、ウエブページデータ５１０の先頭に移動する。そして、ステップＳ４０５で、現在の挿入位置を、移動された入力ブロックの直後に変更する。ステップＳ４０６では、着目入力項目を次の項目に移動する。ステップＳ４０３において再入力が不要な項目であると判定された場合には、ステップＳ４０６に分岐して次の項目について同様の処理を繰り返す。

ステップＳ４０２で編集処理が終了したものと判定されたなら、ステップＳ４０７において、「すすむ」ボタンの入力ブロックを現在の挿入位置へと移動する。「すすむ」ボタンの入力ブロックは、テンプレートにおいては末尾の入力ブロックであるが、もちろんテンプレートの構成次第でどの位置にあってもよい。その場合には、「すすむ」ボタンの入力ブロックの位置を知るためのマークを入力ブロック定義データに含めても良い。そして、ボタンの名称を「すすむ」から「再入力」に書き換える。最後に、編集されたウエブページデータを、さらに必要に応じてページ全体に組み込むなどして、クライアント端末に送信する（Ｓ４０８）。

この図４の編集手順により、再入力が必要な入力ブロックはページの先頭部分に移動され、再入力ボタンも再入力対象の入力ブロックに続けて配置される。もちろん、この例では注文者情報入力画面のウエブページデータを例にしたが、そのほかの入力画面についても全く同様にして、再入力対象の入力ブロックをページの先頭に移動させることができる。また、編集手順も、編集された結果として、再入力のための入力ブロックがページデータの先頭部分にあればよいので、様々なバリエーションを取り得るはずである。

このように、Ｗｅｂページデータの構成を変更し、図２０に示したように再入力が必要な項目が優先的に空欄で表示されるようにすることにより、ユーザが再入力の必要な項目を直ちに知ることができ、再入力するよう誘導することができる。また、再入力の必要な項目が複数ある場合にそれぞれがまとまりなく表示されていると、ユーザの見落としにより、再入力がなされない項目がある可能性が高くなるが、本実施形態のように再入力の必要な項目をまとめて、かつ、最上部に表示するようにしたことにより、ユーザに確実に再入力を行わせることができるようになる。

ユーザによって再入力の必要な項目にデータが入力され、「再入力」ボタンが選択されると、フォトサイト１０５は再度、データを受け取り、再び判定処理Ｓ３０９を行う。データに不備があった場合は、再びステップＳ３１７以降の処理を順に実行する。判定処理Ｓ３０９にて入力されたデータのすべてに不備がないと判定されると、フォトサイト１０５は、携帯端末１１３のディスプレイに表示される画面を配送先設定画面１６００（図１６）または注文確認画面１９００（図１９）に遷移させるためのＷｅｂページデータを出力し、ステップＳ３１０以降の処理を順に実行する。

尚、図２０において黒線枠２００１は標準的な携帯電話１１３のディスプレイに一度に表示できる画面の範囲を示している。一方、本実施形態のようにＷｅｂページデータを変更せず、通常の構成のまま出力した場合に表示される画面を図２１に示す。図２０と図２１を比較すると、図２０で示される画面の方が再入力の操作時にスクロールしなければならない距離が短くなるので、ユーザにとって、操作がし易くなることが分かる。また、「再送信」ボタンの下部に不備がなかった項目も既に入力されたデータとともに表示されるので、後から変更や修正が必要になった場合に再入力することが可能になっている。また、プリント注文時に携帯端末１１３のディスプレイに表示される各画面はその工程に応じてインジケータとして◆マークが表示されている。本実施形態では、例えば、一括プリント注文画面１２００、個別プリント注文画面１３００は最初の工程であるので、一番左端の◆マークが表示されている。そして、注文者情報入力画面１５００はその次の工程であるので、左から２番目の◆マークが表示されている。そして、再入力要求画面２０００は注文者情報入力画面１５００から遷移して表示された画面ではあるが、プリント注文における工程が進んだ訳ではないので、◆マークは左から２番目のままで表示され、工程が先に進んでおらず、再入力であることを示している。また、再入力の項目が離れている場合、および再入力項目を色などの装飾で再入力の注意喚起場合、一画面上で分かりにくい状態にあることと、スクロール量が大きいことを図２１に示す。

尚、本実施形態ではデジタルカメラを使ったイメージネットワークサービスを例に説明したが、画像及びその情報配信を行うサービスに適応できることは言うまでもない。更に、先にも記載の如く、本発明は画像閲覧システムに限定されることなく、通信回線を介してサーバなどの外部装置に接続される携帯電話サービスにおいて広く適用できる技術であり、本発明はこれらの範囲を含むものである。また、本実施形態の各図で示した携帯端末のディスプレイに表示される各種画面は一例である。携帯端末１１３の機種毎に画面サイズが異なるので、文字の回りこみ具合の違いや、表示可能な文字数の違いにより、ここに示したデザインとは異なるものであってもよい。また、本実施形態では、端末を携帯電話としたが、もちろん通常のパーソナルコンピュータであってもよい。パーソナルコンピュータ等の大画面の装置であっても、ウエブページのたとえば末尾の入力をし直すのは、その位置の確認からして困難であり、本発明の適用が非常に操作性の向上に役立つものと考えられる。

本発明の目的は、前述した実施形態の機能を実現するソフトウェアのプログラムコードを記録した記憶媒体（または記録媒体）を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ（またはCPUやMPU）が記憶媒体に格納されたプログラムコードを読み出し実行することによっても達成される。この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコードを記憶した記憶媒体は本発明を構成することになる。又、コンピュータが読み出したプログラムコードを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼働しているオペレーティングシステム（OS）などが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれる。

更に、記憶媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張カードやコンピュータに接続された機能拡張ユニットに備わるメモリに書込まれた後、そのプログラムコードの指示に基づき、その機能拡張カードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれる。本発明を上記記憶媒体に適用する場合、その記憶媒体には、先に説明したフローチャートに対応するプログラムコードを含むプログラムコードが格納されることになる。

本実施形態のプリント注文システム全体のブロック図である。本実施形態のフォトサイトを構成するサーバ装置のハードウエアのブロック図である。本実施形態のフォトサイトで実行されるプリント注文受付処理のフローチャート図である。本実施形態のフォトサイトで実行される再入力要求時の編集処理のフローチャート図である。本実施形態の編集対象となるデータを示す模式図である。本実施形態のフォトサイトで管理するＭＢセッションテーブルに格納されるデータ項目の一例を示す図である。本実施形態のフォトサイトで管理する注文情報データテーブルに格納される項目の一例を示す図である。本実施形態のフォトサイトが管理する注文者データテーブルに格納される項目の一例を示す図である。本実施形態のフォトサイトが管理する注文画像データテーブルに格納されるデータ項目の一例を示す図である。本実施形態の携帯端末のディスプレイに表示されるログイン画面の一例を示す図である。本実施形態の携帯端末のディスプレイに表示される画像閲覧画面の一例を示す図である。本実施形態の携帯端末のディスプレイに表示される一括プリント注文画面の一例を示す図である。本実施形態の携帯端末のディスプレイに表示される個別プリント注文画面の一例を示す図である。本実施形態の携帯端末のディスプレイに表示される画像確認画面の一例を示す図である。本実施形態の携帯端末のディスプレイに表示される注文者情報入力画面の一例を示す図である。本実施形態の携帯端末のディスプレイに表示される配送先入力画面の一例を示す図である。本実施形態の携帯端末のディスプレイに表示される配送先の再入力要求画面の一例を示す図である。本実施形態の携帯端末のディスプレイに表示される見積もり表示画面の一例を示す図である。本実施形態の携帯端末のディスプレイに表示される注文確認画面の一例を示す図である。本実施形態の携帯端末のディスプレイに表示される再入力要求画面の一例を示す図である。従来の携帯端末のディスプレイに表示される再入力が必要な注文者情報入力画面の一例を示す図である。本実施形態の注文者情報入力画面を携帯端末のディスプレイに表示させるためのＷｅｂページ情報のスクリプトの一例を示す図である。本実施形態の本実施形態の注文者情報の再入力要求画面を携帯端末のディスプレイに表示させるためのＷｅｂページ情報のスクリプトの一例を示す図である。

Claims

ページデータを通信端末へネットワークを介して提供するサーバコンピュータであって、
複数の項目の入力フィールドを所定の順で配置し、スクロールして画面に表示するためのページデータを前記通信端末へ送信する送信手段と、
前記入力フィールドに入力されたデータを前記通信端末から受信する受信手段と、
前記受信されたデータに基づき、前記項目の入力フィールドに再入力が必要か否かを判定する判定手段と、
前記判定の結果、再入力が必要と判定された複数の項目の入力フィールドを含む第１のフィールド群を、再入力が不要と判定された複数の項目の入力フィールドを含む第２のフィールド群よりも前に配置し、前記第１のフィールド群では前記再入力が必要と判定された複数の項目の入力フィールドを前記所定の順にしたがって配置し、前記第２のフィールド群では前記入力が不要と判定された複数の項目の入力フィールドを所定の順にしたがって配置し、スクロールして画面に表示されるように前記複数の項目の入力フィールドを並べ替えて前記ページデータを変更する変更手段とを備え、
前記送信手段は、さらに前記変更されたページデータを前記通信端末へ送信することを特徴とするサーバコンピュータ。
前記変更手段は、前記再入力が必要と判定された項目の入力フィールドが空欄で表示されるように前記ページデータを変更することを特徴とする請求項１に記載のサーバコンピュータ。
前記判定の結果、再入力が必要と判定された項目の数を検知する検知手段をさらに備え、
前記検知された数が所定値より大きいとき、前記変更手段は前記複数の項目の入力フィールドの並べ替えを実行せず、所定のメッセージを画面の最上部に配置して前記ページデータを更新することを特徴とする請求項１または２に記載のサーバコンピュータ。
サーバコンピュータによりページデータを通信端末へネットワークを介して提供する方法であって、
前記サーバコンピュータの送信手段が、複数の項目の入力フィールドを所定の順で配置し、スクロールして画面に表示するためのページデータを前記通信端末へ送信する送信工程と、
前記サーバコンピュータの受信手段が、前記入力フィールドに入力されたデータを前記通信端末から受信する受信工程と、
前記サーバコンピュータの判定手段が、前記受信されたデータに基づき、前記項目の入力フィールドに再入力が必要か否かを判定する判定工程と、
前記サーバコンピュータの変更手段が、前記判定の結果、再入力が必要と判定された複数の項目の入力フィールドを含む第１のフィールド群を、再入力が不要と判定された複数の項目の入力フィールドを含む第２のフィールド群よりも前に配置し、前記第１のフィールド群では前記再入力が必要と判定された複数の項目の入力フィールドを前記所定の順にしたがって配置し、前記第２のフィールド群では前記入力が不要と判定された複数の項目の入力フィールドを所定の順にしたがって配置し、スクロールして画面に表示されるように前記複数の項目の入力フィールドを並べ替えて前記ページデータを変更する変更工程とを有し、
前記送信工程では、さらに前記変更されたページデータを前記通信端末へ送信することを特徴とする方法。
サーバコンピュータによりページデータを通信端末へネットワークを介して提供するためのプログラムであって、
複数の項目の入力フィールドを所定の順で配置し、スクロールして画面に表示するためのページデータを前記通信端末へ送信する送信手段と、
前記入力フィールドに入力されたデータを前記通信端末から受信する受信手段と、前記受信されたデータに基づき、前記項目の入力フィールドに再入力が必要か否かを判定する判定手段と、
前記判定の結果、再入力が必要と判定された複数の項目の入力フィールドを含む第１のフィールド群を、再入力が不要と判定された複数の項目の入力フィールドを含む第２のフィールド群よりも前に配置し、前記第１のフィールド群では前記再入力が必要と判定された複数の項目の入力フィールドを前記所定の順にしたがって配置し、前記第２のフィールド群では前記入力が不要と判定された複数の項目の入力フィールドを所定の順にしたがって配置し、スクロールして画面に表示されるように前記複数の項目の入力フィールドを並べ替えて前記ページデータを変更する変更手段としてサーバコンピュータを機能させるためのプログラムであって、
前記送信手段は、さらに前記変更されたページデータを前記通信端末へ送信することを特徴とするプログラム。