JP2004086803A - 仮想試着のための情報処理方法及び装置 - Google Patents

Abstract

【課題】オンライン・ショッピングにおいても複数人による現実のショッピングに近い状況を実現する。
【解決手段】仮想試着場面の画像の閲覧を可能とする第１のユーザの登録要求を受信した場合、当該第１のユーザに関する情報を記憶装置に登録するステップと、仮想試着場面の画像の閲覧が可能であると登録された第１のユーザの端末から仮想試着場面の画像の閲覧要求を受信した場合、記憶装置に登録された第１のユーザに関する情報と仮想試着場面に登場する所定の者に関する情報との少なくともいずれかに基づき仮想試着場面の画像を生成し、第１のユーザの端末に送信するステップとを含む。これにより、例えば仮想試着を行おうとするユーザは、自己又は他のユーザ若しくは自己及び他のユーザが登場する仮想試着場面の画像を同時又は非同期に閲覧できる第１のユーザを設定登録することができる。すなわち、仮想試着場面の複数人による共有が可能となる。
【選択図】　図２７

Description

【０００１】
【発明が属する技術分野】
本発明は、コンピュータによる仮想的な空間内において商品である衣服の着脱を行う仮想試着のための情報処理技術及び関連する決済のための情報処理技術に関する。
【０００２】
【従来の技術】
例えば特開２００１−０２２８３１号公報には以下のような技術が開示されている。すなわち、ユーザーの様々な取引先における取引履歴を基に、ユーザーが選択した商品に対して組合せがよく、かつユーザーの嗜好性にあった商品の情報を提供するために、情報の提供者が、予め商品同士を関連付けする情報を登録しなくても、ユーザーが選択した商品に対し組合せのよい商品を判定し、さらにユーザーの嗜好性にあった商品を判定するのに際し、ユーザーの多面的な嗜好性として、平均的嗜好性、目的別嗜好性、最近の嗜好性を加味し、ユーザーに適したコーディネート例として商品情報を提供する。
【０００３】
また、例えば特開平１１−０８６１４２号公報には以下のような技術が開示されている。すなわち、モデル画像を表示器に表示し、複数の商品群から指定された一つの商品群の画像情報と衣類に関する商品の画像情報をその商品データと共に記憶するデータベースから転送して表示端末の表示器に表示し、指定された商品群に含まれる複数の商品から指定された商品の商品画像をモデル画像に試着させて試着モデル画像として表示器に表示する。続く処理として、試着モデル画像が試着する商品の登録を確定し、表示端末での締め操作に応じ登録が確定した商品の商品データを本体に送信して商品登録処理を行う。
【０００４】
また、例えば特開平１１−００１８１３号公報には以下のような技術が開示されている。すなわち、ファッションの専門的な知識が無くとも、あるいはファッションの専門的な知識をもった人のアドバイスがなくとも、顧客が好みの衣服の細部の形状や適用する素材を容易に選択可能とするコーディネート支援装置等である。
【０００５】
また、例えば特開平１１−２６５２４３号公報には以下のような技術が開示されている。すなわち、販売者側では、仮想試着に用いる商品の各部位の測定値及び購入者の身体の各部位の測定値が登録されたデータベースと、購入者が、購入者側の端末を操作し販売者側に設けられた仮想店舗内で、ある試着を伴う商品を購入する際、その商品の各部位のサイズの測定値及びその商品に対応する購入者の身体の各部位のサイズの測定値をデータベースから取得し、その取得した測定値を比較して、その商品の購入者に対するフィット具合を判定し、その判定結果を仮想試着結果として、購入者側の端末に提示する仮想試着システムアプリケーションとを備えたものである。
【０００６】
また、例えば特開平１１−２０３３４７号公報には以下のような技術が開示されている。すなわち、　試着用として選択された衣服（試着服）に対応する衣服型紙情報と、標準人体モデルの体型に関する標準人体情報とがメモリからそれぞれ読出されるとともに、キーボードやマウスを介して入力された体型情報、生地情報、および縫製情報がＲＡＭから読出され、衣服画像生成部が試着人の体型に適合した衣服を示す衣服画像を作成する。こうして作成された衣服画像と、試着人の人物画像とが試着画像生成部に与えられ、人物画像と衣服画像とがクロマキー合成されて合成画像（試着画像）が作成される。
【０００７】
また、例えば日本特許２８６０６９０号には以下のような技術が開示されている。すなわち、キー商品を特定するキー商品特定ステップと、前記特定したキー商品に基づいて、前記キー商品に組み合わされる商品であって、前記商品に合うコーディネート商品を特定するコーディネート商品特定ステップと、前記特定されたコーディネート商品を出力するコーディネート商品出力ステップとを有することを特徴とする商品案内方法を提供する。
【０００８】
また、例えば特開２００１−１６００９５号公報には以下のような技術が開示されている。すなわち、インターネットに接続された電子モールシステムは、店舗・商品データベース、およびユーザデータベースを備える。店舗・商品データベースには、各店舗で販売される各商品の三次元モデルデータが登録されている。また、ユーザデータベースには、各ユーザの人物像規定データが登録されており、この人物像規定データに基づいて人物像を生成する。外部コンピュータで商品が選択されると、その商品を人物像に試着させた試着像の画像データが外部コンピュータに送信される。
【０００９】
また、例えば特開２００１−２１６４２９号公報には以下のような技術が開示されている。すなわち、消費者は仲介者のホームページに接続し、登録した仮想試着モデルに、サーバーに登録されている商品を選択し仮想試着する。仮想試着では、カラーコーディネーター及びスタイリストのデーターを基に作成した診断ソフトでアドバイスを得る事が出来、仮想試着を行えば、メーカー名・購入品名・価格等が一覧表示され、消費者は発注情報を入力し、仲介者は各販売業者に契約に必要な消費者のデーターをインターネットで送信し、販売業者は消費者に商品を発送する。
【００１０】
また、例えば特開２００１−３１９１０８号公報には以下のような技術が開示されている。すなわち、会員をスターとして扱いＴＶドラマ的なアングルにして、ショッピングを楽しませ各国々のグラフイックス人物を取り入れ、ドラマ的スリル要素を入れる。会員の社会情勢、会話の勉強も盛り込む。交換器、接続回路の確保、友達同志のキーワードによる画面上、双方向のおしゃべりおよび家族同志のショツピング、ブライダルのウエデイングドレス、装飾品、タキシード、お色直し、式場での雰囲気、実写ソフト化、何度でも確かめ気に入ったら本契約する。好きな物を好きなだけ試着したり、装飾品、その他を身に着けたりしゴージヤスな雰囲気を味わったり行きたい外国、行きたい店の疑似体験を画面上で出来る。
【００１１】
また、例えば特開２００１−３３０８０６号公報には以下のような技術が開示されている。すなわち、個人が所有のパーソナルコンピュータのウエブブラウザを用いて眼鏡店が開設するホームページにインターネットを経由してアクセスし、ホームページで提供された眼鏡フレームを選択して、選択された眼鏡フレームを顔画像と合成してモニター画面上に表示させる。
【００１２】
また、例えば特開２００１−３４４４７４号公報には以下のような技術が開示されている。すなわち、商品、特に服飾用品のように、顧客の体型によって同一商品であっても価値に差がでる商品に関して、三次元オブジェクトに当該服飾用品を試着させ、様々な視点から見ることができるようにしたため、従来のオンラインショッピングでは、不可能であった、顧客個々の価値感を考慮した上での購入が可能となり、返品等を軽減することができる。また、服飾用品を重ね着させることができるため、トータルコディネイトの状態も確認することができる。さらに、顧客オブジェクトを顧客の体型に合せて変形することができる。
【００１３】
また、例えば特開２００１−３４４４８２号公報には以下のような技術が開示されている。すなわち、顧客側の画像及び希望商品を登録・蓄積する手段、商品を提供する側の商品画像及び商品情報を登録・蓄積する手段、顧客側の希望に対応した商品を登録・蓄積された商品画像及び商品情報から検索する手段、検索された商品画像及び商品情報と顧客側の画像とを合成する手段、及び得られた合成画像を顧客側に提供する手段とを有する合成写真を用いた試着システムである。
【００１４】
また、例えば特開２００２−２４６４０号公報には以下のような技術が開示されている。すなわち、ファッション誌等に示された洋服等を記憶するデータベースとユーザに関連する情報を記憶するデータベースとウェブサーバで体験ウェブサイトが構築される。体験ウェブサイトはファッション誌等と予め関連付けられている。ユーザは体験ウェブサイトにアクセスするコンピュータを有する。ユーザの人体に洋服等を付加して体験合成画像を作成するバーチャル体験実行部は、ユーザのコンピュータ側または体験ウェブサイト側に設けられる。ファッション誌等に表示された洋服等に関して体験希望意思に基づきインターネットを介してアクセスしたユーザに対してバーチャル試着ページを提示し、ここで試着体験を仮想的に行うことができる。
【００１５】
また、例えば特開２００２−３２６４０号公報には以下のような技術が開示されている。すなわち、インターネット上に専門店の仮想店舗、仮想マーケットを設ける。顧客の趣向、データを登録し、かつ店舗側よりアンケート形式で顧客の好み、容姿等のデータを収集して個人別のファイルを作る。これらのデータを総合して人工現実感を創って顧客が着衣して歩いたり、走ったりする姿を多方面から見る事を可能にする。顧客の端末機器から個人認証を確定して仮想店舗に入って行き、メニューから選定して仮想試着し、迅速に好みの衣服を選び、発注することが出来る。又、ファッションショーに出演したモデルの服装、装飾品を自分、家族又は知人に仮想試着して容姿を客観的に観察して、楽しんだり、注文したりすることが出来る。
【００１６】
また、例えば特開２００２−３２５８９号公報には以下のような技術が開示されている。すなわち、本システムの利用者は、身長、胸囲、胴まわり、袖丈等のデータをインターネットで入力し、体型の詳細なデータであるインターネットオーダーサイズを得る。オーダーの購入希望者は、注文内容と、インターネットオーダーサイズを入力するだけで注文でき、オーダー同様の仕上がりとなる。季節ものの新作やニューファッションの作品、それに販売用に展示された衣類でも、必要に応じて一部手直しができることから、オーダー同等の製品を手に入れることができる。さらに、必要があれば、仮想空間を利用して模擬試着もできるインターネットオーダーによる衣類の販売等システムを提供する。
【００１７】
また、例えば特開２００２−５８０４５号公報には以下のような技術が開示されている。すなわち、店舗などに設置した複数台の多眼ステレオカメラ（例えば９個のビデオカメラを３×３マトリックス配置したもの）で人の身体や物品などの対象物を撮影し、出力された動画像データをネットワークを通じてモデリングサーバへ送る。モデリングサーバは、その動画像データから対象物の３次元モデルを作成する。この３次元モデルは、撮影時の対象物の動きに基づいて、動くことができるように作られている。ユーザシステムは、その３次元モデルを受け取り、これを衣服のバーチャル試着や体験型ゲームなどのアプリケーションのバーチャル３次元空間に取り込み、動かす。
【００１８】
また現在、顧客がオンライン・ショッピングにおいて仮想試着を行い購入を決めることができるインターネット・サイトが既に存在する。中には自分の体系や顔までを真似て画面に登場させ仮想試着をして似合うかどうかを判断し、購入できるものも存在する。
【００１９】
【発明が解決しようとする課題】
しかしながら、上で述べた従来技術では、本人もしくは第３者が個別に試着をした画面を見て購入を検討するものであり、一般的に行われているショッピングとはかけ離れたものになっている。すなわち、複数の人が商品を試着した様子をお互いに見せあったり、ペア・ルック等、複数人によるコーディネイトを検討したり、他の人が試着した商品が気に入った場合、その商品を購入したりすることなどが、上で述べた従来技術では実現できない。
【００２０】
従って本発明の目的は、オンライン・ショッピングにおいても複数人による現実のショッピングに近い状況を実現するための新規な情報処理技術を提供することである。
【００２１】
また本発明の他の目的は、試着された商品の多様な代金支払態様を可能にするための情報処理技術を提供することである。
【００２２】
【課題を解決するための手段】
本発明の第１の態様に係る、所定の者の仮想試着場面の画像を複数人で閲覧するための情報処理方法は、仮想試着場面の画像の閲覧を可能とする第１のユーザの登録要求を受信した場合、当該第１のユーザに関する情報を記憶装置に登録するステップと、仮想試着場面の画像の閲覧が可能であると登録された第１のユーザの端末から仮想試着場面の画像の閲覧要求を受信した場合、記憶装置に登録された第１のユーザに関する情報と仮想試着場面に登場する所定の者に関する情報との少なくともいずれかに基づき仮想試着場面の画像を生成し、第１のユーザの端末に送信するステップとを含む。これにより、例えば仮想試着を行おうとするユーザは、自己又は他のユーザ若しくは自己及び他のユーザが登場する仮想試着場面の画像を同時又は非同期に閲覧できる第１のユーザを設定登録することができる。
【００２３】
また、本発明の第１の態様において、第２のユーザの仮想試着を可能とする設定要求を受信した場合、第２のユーザに対応して仮想試着が可能であることを表す情報を記憶装置に登録するステップと、第２のユーザの端末から第２のユーザの仮想試着に関する設定情報を受信した場合、第２のユーザの仮想試着に関する設定情報を記憶装置に登録するステップとをさらに含むような構成であってもよい。これにより、例えば仮想試着を行おうとするユーザは、例えば一緒に仮想試着場面に登場する他のユーザを登録することができる。また、仮想試着場面に登場するユーザは、例えば下半身を隠す等、仮想試着場面に登場する際の条件を設定することが可能となる。
【００２４】
また、本発明の第１の態様において、上で述べた所定の者に関する情報が、第２のユーザの仮想試着に関する設定情報を含むような構成であってもよい。これにより、仮想試着場面に登場する各ユーザによって設定された条件が、閲覧が許可されている各ユーザのための仮想試着場面の画像に反映されるようになる。
【００２５】
また、本発明の第１の態様において、上で述べた第２のユーザの仮想試着に関する設定情報は、第１のユーザによる、第２のユーザの画像に対する仮想試着操作に関する設定情報を含むような構成であってもよい。これにより、仮想試着場面に登場する各ユーザは、自己の画像に対しての他のユーザによる仮想試着操作（例えば衣服の着脱等）についての設定を行うことが可能となる。例えば「上半身は他のユーザの仮想試着操作を許可しない」等の設定が可能となる。
【００２６】
また、本発明の第１の態様において、仮想試着操作に関する設定情報に則った仮想試着操作指示を第１のユーザの端末から受信した場合、少なくとも仮想試着操作指示に基づき仮想試着場面の画像を生成し、第１のユーザの端末に送信するステップをさらに含むような構成であってもよい。これにより、仮想試着操作についての設定が、仮想試着場面での各ユーザの操作に対応する画像生成処理に反映される。
【００２７】
本発明の第２の態様に係る、所定の者の仮想試着に用いられた商品の決済についての情報処理方法は、所定の者に商品を仮想試着させる要求をユーザの端末から受信した場合には、少なくとも所定の者に関する情報と商品に関する情報とを試着情報記憶部に格納するステップと、商品又は所定の者を指定する決済要求をユーザの端末から受信した場合、指定された商品若しくは所定の者が仮想試着した商品又は商品群に対応して支払者たるユーザの情報を決済情報記憶部に格納するステップとを含む。これにより、仮想試着者別・商品別に決済を行うことが可能となる。すなわち、自己又は他のユーザが仮想試着している商品をまとめて決済したり、各商品について個別に決済したりすることが可能となる。
【００２８】
また、本発明の第２の態様において、支払者たるユーザの支払金額の情報をユーザの端末から受信した場合、支払金額の情報を少なくともユーザに対応付けて決済情報記憶部に格納するステップをさらに含むような構成であってもよい。これにより、どのユーザがどの決済についていくら支払うのかということを登録できるようになり、複数のユーザによる決済すなわち共同購入が可能となる。
【００２９】
また、本発明の第２の態様において、支払分担の指示情報を支払者たるユーザの端末から受信した場合には、支払分担の指示情報に基づき計算された支払金額を少なくともユーザに対応付けて決済情報記憶部に格納するステップをさらに含むような構成であってもよい。これにより、共同購入が効率的に行える。例えば４人のユーザによる割前勘定では、商品注文金額の４分の１の金額が、少なくとも割前勘定を選択したユーザの支払金額として登録される。
【００３０】
また、本発明の第２の態様において、指定された商品若しくは所定の者が仮想試着した商品又は商品群の注文金額に支払者たる複数のユーザの支払金額の累計が達するまで又は決済要求を受信してから所定の期間、指定された商品若しくは所定の者が仮想試着した商品又は商品群についての決済要求を受け付け、指定された商品若しくは所定の者が仮想試着した商品又は商品群の注文金額に支払者たる複数のユーザの支払金額の累計が達した場合、指定された商品若しくは当該所定の者が仮想試着した商品又は商品群の発注処理を行うステップをさらに含むような構成であってもよい。これにより、共同購入時において、ある一定の期間は注文金額に達するまで複数のユーザが分担して支払登録を行うことができる。また、共同購入時における金額不足の状態での発注等を防止することが可能となる。
【００３１】
本発明の第３の態様に係る情報処理方法は、所定の者の仮想試着場面の画像をサーバに対して要求するステップと、要求元ユーザに関する情報と仮想試着場面に登場する所定の者に関する情報との少なくともいずれかに基づき生成された仮想試着場面の画像をサーバから受信して表示装置に表示するステップとを含む。これにより、ユーザは自己又は他のユーザ若しくは自己及び他のユーザが登場する仮想試着場面の画像を同時又は非同期に閲覧することが可能となる。
【００３２】
本発明の第４の態様に係る決済処理方法は、少なくとも仮想試着を行った所定の者に関する情報と当該所定の者に対応付けられた仮想試着商品の情報とをサーバから受信して表示装置に表示するステップと、仮想試着商品又は所定の者を指定する決済要求をサーバに送信するステップとを含む。例えば決済を行おうとするユーザは、自己又は他のユーザが仮想試着している商品をまとめて決済したり、各商品について個別に決済したりするための要求を出すことが可能となる。
【００３３】
本発明の第５の態様に係る、商品の決済についての情報処理方法は、所定の者に商品を対応付けるための要求をユーザの端末から受信した場合には、少なくとも当該所定の者に関する情報と前記商品に関する情報とを商品情報記憶部に格納するステップと、商品又は所定の者を指定する決済要求をユーザの端末から受信した場合、指定された商品若しくは前記所定の者に対応付けられた商品又は商品群に対応して支払者たる当該ユーザの情報を決済情報記憶部に格納するステップとを含む。これにより、ユーザからの要求に応じて商品別又は試着者別に決済することが可能となる。
【００３４】
本発明に係る情報処理方法をコンピュータに実行させるためのプログラムを作成することも可能であって、当該プログラムは、例えばフレキシブル・ディスク、ＣＤ−ＲＯＭ、光磁気ディスク、半導体メモリ、ハードディスク等の記憶媒体又は記憶装置に格納される。また、ネットワークを介して頒布される場合もある。なお、処理途中のデータについては、コンピュータのメモリに一時保管される。
【００３５】
【発明の実施の形態】
本発明の一実施の形態に係るシステム構成図を図１に示す。例えばパーソナル・コンピュータであるユーザ端末Ａ（３）及びユーザ端末Ｂ（７）は、図示しないがウェブ（Ｗｅｂ）ブラウザ機能及びメーラ機能を備えており、無線又は有線によりインターネットに接続してホームページを閲覧すること及びメールの送受信を行うことが可能となっている。
【００３６】
例えばインターネットであるネットワーク１には、１又は複数のユーザ端末Ａ（３）やユーザ端末Ｂ（７）の他、仮想試着処理等を行う１又は複数のＡＳＰ（Ａｐｐｌｉｃａｔｉｏｎ　Ｓｅｒｖｉｃｅ　Ｐｒｏｖｉｄｅｒ）サーバ５、並びに例えば服飾品のオンライン販売店（販売サイト）のサーバである１又は複数の販売サイトＡサーバ９及び販売サイトＢサーバ１１が接続されている。
【００３７】
ＡＳＰサーバ５には、仮想試着に関連するデータが格納されている試着管理データベース（ＤＢ）５１及び仮想試着を行うユーザの情報が格納されているユーザ管理ＤＢ５３が接続されている。また、各販売サイトでは取扱商品の情報が格納されている商品ＤＢが管理されており、販売サイトＡサーバ９には商品ＤＢ９１が接続され、販売サイトＢサーバ１１には商品ＤＢ１１１が接続されている。
【００３８】
なお、オンライン・ショッピング及び仮想試着サービスに参加するユーザ数や販売サイトの数は限定されず、それに伴いユーザ端末及び販売サイト・サーバの数も限定されない。また、ＡＳＰが複数あってそれぞれが仮想試着サービスを提供するような構成であってもよい。
【００３９】
また、ネットワーク１を経由する通信には、図示していないがドメイン・ネーム・サーバ（ＤＮＳ）、メール・サーバ、ファイア・ウォール等の、インターネット接続やメール送受信に必要な機器及び機能を使用するものとする。
【００４０】
各ＤＢにおけるテーブル構成及び格納されるデータの一例を図２乃至図８に示す。
【００４１】
商品ＤＢ９１や商品ＤＢ１１１等、販売サイトが管理する商品ＤＢには、例えば図２に示すような商品管理テーブルが含まれる。図２に示す商品管理テーブルの例には、商品コードの列２００、商品型式の列２０２、商品情報の列２０４、色の列２０６、サイズの列２０８、生地・素材の列２１０、画像データの列２１２及び単価の列２１４が含まれている。
【００４２】
本テーブルでは商品コードの列２００の値及び商品型式の列２０２の値によってレコードが特定される。商品コードの列２００の値や商品型式の列２０２の値は各販売サイトやメーカが独自に設定したものでもよいが、商品コードの列２００の値及び商品型式の列２０２の値が決まることによって、商品の種類、色、形、サイズ及び生地・素材が特定できる必要がある。また、各販売サイトやメーカの商品別在庫数を本テーブルに登録するような構成であってもよい。なお、画像データの列２１２に登録されるファイルのデータ形式については、仮想試着が行われる際に表示される画面構成によって、２次元データであっても３次元データであってもよい。
【００４３】
次に、ユーザ管理ＤＢ５３におけるテーブル構成及び格納されるデータの一例を図３に示す。図３に示すユーザ管理テーブルの例には、ユーザＩＤの列３００、氏名の列３０２、生年月日の列３０４、郵便番号の列３０６、住所の列３０８、電話番号の列３１０、身長の列３１２、胸囲の列３１４、ウエストの列３１６、ヒップの列３１８及び本人画像の列３２０が含まれている。
【００４４】
本テーブルには仮想試着サービスに参加する各ユーザの属性情報が格納されている。レコードは主キーであるユーザＩＤの列３００の値によって特定される。各列は、仮想試着場面の画像（仮想試着画面とも呼ぶ）の表示処理や商品注文における支払登録処理などで使用する属性で構成されている。また、身長の列３１２の値、胸囲の列３１４の値、ウエストの列３１６の値及びヒップの列３１８の値に基づき、仮想試着する商品のサイズを自動的に設定するような構成であってもよい。なお、本人画像の列３２０に登録されるファイルのデータ形式については、仮想試着が行われる際に表示される画面構成によって、２次元データであっても３次元データであってもよい。但し、商品を仮想試着する体の部位が特定できるような情報が含まれているものとする。例えば、Ｔシャツを上半身に仮想試着する操作がなされた場合には、Ｔシャツの情報と、仮想試着するユーザの画像の上半身を表す情報との対応付けがなされ、ユーザが上半身にＴシャツを着ているように見える画像を生成するような構成となる。
【００４５】
次に、試着管理ＤＢ５１におけるテーブル構成及び格納されるデータの一例を図４乃至図８に示す。試着管理ＤＢ５１には、例えば図４に示すバスケット管理テーブル、図５に示す利用者エントリ・テーブル、図６に示す試着エントリ・テーブル、図７に示す購入管理テーブル及び図８に示す注文テーブルが含まれている。本実施の形態では、仮想試着場面において仮想試着された商品は、仮想試着場面毎に用意された仮想の試着用バスケットに入るものと仮定し、仮想試着された商品及び対応するユーザの情報の管理を、試着用バスケットに関する情報を管理することによって実現するような構成となっている。
【００４６】
図４にバスケット管理テーブルの一例を示す。図４に示すバスケット管理テーブルの例には、バスケットＩＤの列４００、名称の列４０２、生成者ＩＤの列４０４、生成日の列４０６、有効期限の列４０８、画面ＵＲＬ（Ｕｎｉｆｏｒｍ　ＲｅｓｏｕｒｃｅＬｏｃａｔｏｒ）（ディレクトリ）の列４１０、個人／グループの列４１２及び利用者エントリ数の列４１４が含まれている。
【００４７】
本テーブルには各バスケットすなわち各仮想試着場面の情報が格納されている。ユーザによって仮想試着場面を新規に設定する操作がなされた場合、本テーブルにレコードが追加される。バスケットＩＤの列４００には、ＡＳＰサーバ５によって生成されたユニークなＩＤが登録され、レコードはバスケットＩＤの列４００の値によって特定される。名称の列４０２には、バスケットの名称が登録される。個人用バスケットの場合は生成者の氏名が登録され、グループ用バスケットの場合はグループ名が登録される。生成者ＩＤの列４０４には、バスケットを生成する操作を行ったユーザのユーザＩＤが登録され、このユーザは当該バスケットの管理者となる。生成日の列４０６には、バスケットが生成された日付が登録され、有効期限の列４０８には、バスケットの有効期限となる日付が登録される。この日付になった場合には、当該レコードを削除して仮想のバスケットを消滅させるような構成となっている。図４の例ではバスケットが１年間有効となるようなデータが登録されているが、バスケットの有効期間はもっと長くても短くてもよい。また、バスケット毎に有効期間を変えるような構成でもよい。画面ＵＲＬ（ディレクトリ）の列４１０にはＷｅｂブラウザで仮想試着画面を閲覧するための情報が登録される。なお、ここに登録される情報はＵＲＬの一部（同一グループに共通のディレクトリ）であり、実際にユーザが利用するＵＲＬは、このディレクトリ情報を用いてユーザ毎に個別に生成される。個人／グループの列４１２には、当該バスケットを１人（個人）で使用するのか又は複数人（グループ）で使用するのかを表す値が登録される。利用者エントリ数の列４１４には、当該バスケットを利用する人数が登録される。始めはバスケット生成者１人が登録され、バスケットを利用するユーザが登録されると１人づつ増えるような構成となっている。なお、仮想試着画面を表示する際の人物（ユーザ画像）の位置や大きさ等は、この数値に基づいて決定される。
【００４８】
図５に利用者エントリ・テーブルの一例を示す。図５に示す利用者エントリ・テーブルの例には、バスケットＩＤの列５００、ユーザＩＤの列５０２、利用者名の列５０４、Ｅ−ｍａｉｌアドレスの列５０６、エントリ生成日の列５０８、共有条件の列５１０及び試着エントリ数の列５１２が含まれている。本テーブルには、どのユーザがどのバスケットを利用しているのかという情報が格納される。ユーザがバスケットの利用者として登録された場合、本テーブルにレコードが追加される。なお、１人のユーザが複数のバスケットを利用している場合もある一方で、１つのバスケットは上で述べたバスケット管理テーブル（図４）の利用者エントリ数の列４１２の値で示される数だけユーザに関連付けられている。そのため、レコードはバスケットＩＤの列５００の値及びユーザＩＤの列５０２の値によって特定される。個人用バスケットについては、利用者と１対１の関係であるため本テーブルの例では登録していないが、グループ用バスケットと同様に登録するような構成であってもよい。
【００４９】
利用者名の列５０４にはユーザの氏名が登録され、仮想試着画面表示の際に使用されるが、正規化してユーザ管理テーブル（図３）から導出するような構成であってもよい。Ｅ−ｍａｉｌアドレスの列５０６にはユーザの電子メール・アドレスが登録され、エントリ生成日の列５０６には、ユーザがバスケットの利用者として登録された日付すなわち当該レコードの生成日が登録される。なお、本テーブルのレコード追加に伴い、バスケット管理テーブル（図４）の対応するバスケット（レコード）の利用者エントリ数の列４１２の値が増えるような構成となっている。共有条件の列５０８には、詳しくは後述するが、自己の画像を他のユーザに見せる範囲や他のユーザによる試着操作について等、各ユーザがバスケットを利用する上での条件を示す値が登録される。試着エントリ数の列５１０には、各ユーザが仮想試着中の商品の数が登録される。
【００５０】
図６に試着エントリ・テーブルの一例を示す。図６に示す試着エントリ・テーブルの例には、バスケットＩＤの列６００、アイテム番号（ＮＯ．）の列６０２、ユーザＩＤの列６０４、試着部位の列６０６、商品情報の列６０８、販売サイト・コードの列６１０、商品コードの列６１２、商品型式の列６１４、画像データの列６１６及び購入ステータスの列６１８が含まれている。本テーブルには、どのバスケットを利用しているどのユーザがどのような商品を仮想試着しているのかという情報が格納される。レコードはユーザが仮想試着を行った時に生成され、バスケットＩＤの列６００の値及びアイテム番号（ＮＯ．）の列６０２の値によって特定される。アイテム番号（ＮＯ．）の列６０２には、バスケット内でユニークになるようにＡＳＰサーバ５によって生成された番号が登録される。
【００５１】
ユーザＩＤの列６０４には、商品を仮想試着しているユーザのＩＤが登録され、試着部位の列６０６には、ユーザの体のどの部位に仮想試着がなされているかを表す情報が登録される。商品情報の列６０８には商品名が登録され、仮想試着画面の表示の際に使用されるが、正規化して商品管理テーブル（図２）から導出するような構成であってもよい。販売サイト・コードの列６１０、商品コードの列６１２及び商品型式の列６１４には、商品を特定するためのコードが登録される。画像データの列６１６には仮想試着画面に表示される商品の画像が登録されるが、商品情報の列６０８同様、正規化してもよい。購入ステータスの列６１８には、仮想試着がなされている当該商品が既に購入済みであるかどうかを表す値が登録される。すなわち、バスケットの中の商品を購入したからといって、商品をバスケットから出さないような構成となっている。実際のショッピングに例えると、商品の見本をレジに持っていって購入するような形態であり、見本が繰返し使用できるのと同様に、仮想試着商品は何回でも購入可能である。
【００５２】
図７に購入管理テーブルの一例を示す。図７に示す購入管理テーブルの例には、バスケットＩＤの列７００、アイテム番号（ＮＯ．）の列７０２、商品単価の列７０４、数の列７０６、合計金額の列７０８、支払登録済金額累計の列７１０、支払入力者ユーザＩＤの列７１２、入力金額の列７１４、支払方法の列７１６、入力日の列７１８、配送先郵便番号の列７２０、配送先住所の列７２２、受取人氏名の列７２４及び金額ステータスの列７２６が含まれている。本テーブルには、仮想試着がなされた商品の購入（すなわち代金支払登録）に関する情報が格納される。ユーザが自己又は他のユーザが仮想試着している商品の代金支払登録を行った場合、本テーブルにレコードが追加される。代金支払は、ある商品について１人のユーザが１回だけ行うものとは限らず、各々支払金額を決定した複数のユーザによってなされる場合もある。そのため、本テーブルには代金支払登録の履歴データが登録され、レコードを特定するための主キーは存在しない。なお、最新のデータだけが参照できればよい場合には、レコードを上書きするようにし、バスケットＩＤの列７００及びアイテム番号（ＮＯ．）の列７０２を主キーとするような構成であってもよい。
【００５３】
商品単価の列７０４には、ユーザが代金支払登録を行った商品の単価が登録される。数の列７０６には商品の数が登録され、合計金額の列７０８には、商品単価の列７０４の値に数の列７０６の値を掛けた値が登録される。すなわちこの値が、商品の注文金額となる。支払登録済金額累計の列７１０には、当該商品について１又は複数のユーザが代金支払登録を行った金額の累計が登録される。例えば、ある商品の購入について、まず第１のユーザが１千円の代金支払登録を行った場合、本テーブルにはレコードが１件追加され、当該レコードの支払登録済金額累計の列７１０には、”１，０００”の値が登録される。次に第２のユーザが同じ商品の購入について２千円の代金支払登録を行った場合、本テーブルにはレコードがさらに１件追加され、当該レコードの支払登録済金額累計の列７１０には、”３，０００”の値が登録されるような構成となっている。
【００５４】
支払入力者ユーザＩＤの列７１２には、代金支払登録を行ったユーザのＩＤが登録され、入力金額の列７１４には、当該代金支払登録によってユーザが支払うべき金額が登録される。支払方法の列７１６には、クレジット・カードや銀行振込みなどの代金支払方法が登録され、入力日の列７１８には、代金支払登録を行った日付が登録される。複数のユーザによる代金支払に対して代金支払登録を受け付ける期間を設定する場合には、最初の代金支払登録についてのレコードの、入力日の列７１８の値に基づき代金支払登録の期限を設定する。
【００５５】
配送先郵便番号の列７２０、配送先住所の列７２２及び受取人氏名の列７２４には、商品の配送先となる郵便番号、住所及び受取人の氏名が登録される。これらの値は、例えば複数のユーザによる代金支払が行われる場合には、最初の代金支払登録の際に登録される。これにより、他のユーザは誰のために代金支払登録が開始されたのかを知ることができ、追加で代金支払登録を行うかどうかを判断することができる。金額ステータスの列７２６には、支払登録済金額累計の列７１０の値が合計金額の列７０８の値に達しているかどうかを表す値が登録される。本テーブルの例では、支払登録済金額累計の列７１０の値が合計金額の列７０８の値に達した場合には”注文可”と登録され、未だ達していない場合には”金額不足”と登録される。本実施の形態では、金額ステータスの列７２６の値が”注文可”である商品について発注処理を行うような構成となっている。なお、発注処理が行われた場合には、対応するレコードを削除するか無効にするような処理を行う。
【００５６】
図８に注文テーブルの一例を示す。図８に示す注文テーブルの例には、注文番号の列８００、注文日の列８０２、販売サイト・コードの列８０４、商品コードの列８０６、商品型式の列８０８、数の列８１０、代引金額の列８１２、配送先郵便番号の列８１４、配送先住所の列８１６及び受取人氏名の列８１８が含まれている。本テーブルには、注文がなされた商品及び商品の配送先に関する情報が格納される。メーカや販売サイトに対して商品の発注が行われた場合、本テーブルにレコードが追加され、主キーである注文番号の列８００の値によってレコードが特定される。
【００５７】
注文日の列８０２には発注が行われた日付が登録される。販売サイト・コードの列８０４、商品コードの列８０６及び商品型式の列８０８には、発注がなされた商品（配送すべき商品）を特定する値（コード）が登録される。数の列８１０には配送すべき商品の数が登録される。代引金額の列８１２には、代金の支払方法が代引きである場合に、配送時に受け取るべき金額が登録される。配送先郵便番号の列８１４、配送先住所の列８１６及び受取人氏名の列８１８には、商品の配送先となる郵便番号、住所及び受取人の氏名が登録される。なお、例えば贈り物の購入など、受取人が商品購入処理を行っていない場合においても、支払方法が”代引”に登録されていると、受取人が代金を請求されることになる。そのため、代金支払登録を受け付ける際、代金支払登録を行うユーザと商品の受取人とが別の人物である場合には、代金支払方法として”代引”を選択できないようにする構成であってもよい。
【００５８】
次に、図９及び図１０を用いて図１に示したシステムの画面遷移を説明する。なお、図中に点線で囲んである画面（画面名称）については、ＡＳＰサーバ５以外のサーバが管理する画面を表している。また、影付きの実線で囲んである画面については、ブラウザ上のメイン画面として表示される画面を表し、通常の実線で囲んである画面については、サブ画面としてポップアップ表示される画面を表している。なお、各画面の構成や処理の詳細については後述するため、ここでは全体的な画面の遷移について説明する。また、各画面のためのデータ（例えばＨＴＭＬ（Ｈｙｐｅｒ　Ｔｅｘｔ　Ｍａｒｋｕｐ　Ｌａｎｇｕａｇｅ）ファイル及び同時表示される画像ファイル等）はＡＳＰサーバ５等のサーバによって生成され、例えばユーザ端末Ａ（３）又はユーザ端末Ｂ（７）に送信され、ユーザ端末Ａ（３）又はユーザ端末Ｂ（７）のブラウザ機能により画面表示されるものとする。
【００５９】
まず、販売サイトの商品選択画面（Ｐ９００：図１２）において商品の選択及び仮想試着（以下、試着）操作を受け付ける。例えば販売サイトＡサーバ９又は販売サイトＢサーバ１１は、ユーザ端末から操作入力データを受信した場合、ＡＳＰサーバ５に処理を移行する。ＡＳＰサーバ５は、ユーザを特定するため、ログイン画面（Ｐ９０２）を表示させる。ログイン処理が終了した場合、試着画面を選択させる画面（Ｐ９０４：図１４）を表示させる。この画面は、ユーザが個人用の試着画面で試着操作を行うか、複数人（共有グループ）用の試着画面で試着操作を行うかを選択させるような構成となっている。
【００６０】
ユーザが個人用の試着画面を選択した場合には、端子Ａを介して図１０の画面遷移に移行する。ユーザが共有グループ用の試着画面を選択した場合には、共有グループ一覧画面（Ｐ９０６：図１６）を表示させる。共有グループ一覧画面（Ｐ９０６）からは、共有グループ新規作成・編集画面（Ｐ９０８：図２２）に移行し、さらに共有グループ・メンバ追加画面（Ｐ９１０：図２４）や共有条件設定画面（Ｐ９１２：図２６）に移行することができる。共有グループ一覧画面（Ｐ９０６）で一覧表示された共有グループのうち、いずれかの共有グループをユーザが選択した場合、試着対象（部位）選択画面（Ｐ９１４：図１８）を表示させる。この画面では、選択された商品を、グループ内のどのユーザのどの部位（例えば上半身等）に試着させるのかをユーザに選択させる。試着対象（部位）が選択入力された場合、共有用の試着画面（Ｐ９１６：図１８）を表示させる。ここでは、試着するユーザの部位に選択された商品のデータが対応付けられ、画面上でも試着が完了している画像が表示されるような構成となっている。なお、試着した商品の試着状態をユーザが調整するようにしてもよい。
【００６１】
共有用の試着画面（Ｐ９１６）には、「他商品選択」ボタン、「試着リスト」ボタン、「画面共有」ボタン、「購入」ボタン及び「終了」ボタンが含まれている。「他商品選択」ボタンが押された場合には、販売サイトのサーバへ処理を移行し、商品選択用の画面（Ｐ９１８）を表示させる。この販売サイト商品選択画面は、Ｐ９００の画面と同じでもよいし、別の販売サイトの画面であってもよい。ユーザが商品の選択及び試着操作を行うと、再び試着対象（部位）選択画面（Ｐ９１４）を表示させ、選択した商品を、どのユーザのどの部位に試着させるのかをユーザに選択させる。
【００６２】
また、共有用の試着画面（Ｐ９１６）において「試着リスト」ボタンが押された場合には、試着リスト画面（Ｐ９２０：図３０）を表示させる。この画面では、どのユーザがどの部位にどんな商品を試着しているのかの一覧（リスト）が含まれる。リストの行（ユーザの部位及び商品）が選択されて「試着商品のコピー」ボタンが押された場合、試着商品コピー画面（Ｐ９２２：図３５）に移行する。試着商品コピー画面（Ｐ９２２）にはユーザの一覧が含まれ、同じ商品を試着させるユーザの選択入力が行われた場合、再び試着リスト画面（Ｐ９２０）を表示させる。ここでは、選択されたユーザに対しての試着処理（商品のコピー）を反映したリストが表示される。
【００６３】
また、共有用の試着画面（Ｐ９１６）において「画面共有」ボタンが押された場合には、共有グループ一覧画面（Ｐ９０６）に戻り、共有グループの選択や新規作成・編集等の操作を受け付ける。
【００６４】
また、共有用の試着画面（Ｐ９１６）において「終了」ボタンが押された場合には、試着状況の保存を行い、処理を終了する。なお、保存を行うかどうかを選択させる画面を表示させ、ユーザの入力に応じて、対応する処理を行うような構成であってもよい。
【００６５】
また、共有用の試着画面（Ｐ９１６）において「購入」ボタンが押された場合には、会計用試着リスト画面（Ｐ９２４：図３９）を表示させる。この画面には、試着状況及び試着している商品の金額がリストとして含まれ、また「試着者別に会計」ボタン及び商品毎の「会計」ボタン（リンク）が含まれる。
【００６６】
「試着者別に会計」ボタンが押された場合には、会計試着者選択画面（Ｐ９２６：図５１）を表示させる。この画面で、ユーザが会計しようと思うユーザ（試着者）を選択させる。試着者の選択入力が行われた場合、試着者別会計画面（Ｐ９２８：図５３）を表示させる。この画面には、選択された試着者の試着商品の情報が含まれ、ユーザは数量等を入力できるようになっている。また、試着者別会計画面（Ｐ９２８）には「支払登録」ボタンが含まれ、ユーザによる「支払登録」ボタンの押下が行われた場合、試着者別支払登録画面（Ｐ９３０：図５５）を表示させる。この画面では、支払方法や商品の配送先等の入力を受け付け、「注文」ボタンが押された場合には、支払登録を受け付けたことを示す、試着者別会計（支払登録）確認画面（Ｐ９３２：図５６）を表示させる。
【００６７】
会計用試着リスト画面（Ｐ９２４）において商品毎の「会計」ボタン（リンク）が押された場合には、選択された商品の商品別会計画面（Ｐ９３４）を表示させる。この画面には、選択された商品の価格等の情報が含まれ、ユーザは数量等を入力できるようになっている。また、商品別会計画面（Ｐ９３４：図４２）には「支払登録」ボタンが含まれ、ユーザによる「支払登録」ボタンの押下が行われた場合、商品別支払登録画面（Ｐ９３６：図４４）を表示させる。この画面では、支払方法や商品の配送先等の入力を受け付け、「注文」ボタンが押された場合には、支払登録を受け付けたことを示す、商品別会計（支払登録）確認画面（Ｐ９３８：図４５）を表示させる。
【００６８】
次に、図１０を用いて、端子Ａを介して移行した後の画面遷移について説明する。試着画面を選択させる画面（Ｐ９０４）（図９）において、ユーザが個人用の試着画面を選択した場合には、試着部位選択画面（Ｐ１０００：図５８）を表示させる。選択した商品をどの部位に試着させるかの選択入力が行われた場合には、個人用の試着画面（Ｐ１００２：図５９）を表示させる。ここでは、試着する部位と選択された商品のデータとが対応付けられ、画面上でも試着が完了している画像が表示されるような構成となっている。なお、試着した商品の試着状態をユーザが調整するようにしてもよい。
【００６９】
個人用の試着画面（Ｐ１００２）には、「他商品選択」ボタン、「試着リスト」ボタン、「画面共有」ボタン、「購入」ボタン及び「終了」ボタンが含まれている。「他商品選択」ボタンが押された場合には、販売サイトのサーバへ処理を移行し、商品選択用の画面（Ｐ１０２２）を表示させる。この販売サイト商品選択画面は、Ｐ９００（図９）の画面と同じでもよいし、別の販売サイトの画面であってもよい。ユーザにより商品の選択及び試着操作の入力が行われると、再び試着部位選択画面（Ｐ１０２４）を表示させ、選択した商品をどの部位に試着させるのかをユーザに選択させる。
【００７０】
試着部位選択画面（Ｐ１０２４）において試着部位の選択入力が行われた場合又は個人用の試着画面（Ｐ１００２）において「試着リスト」ボタンが押された場合には、試着リスト画面（Ｐ１０２６：図６１）を表示させる。この画面では、どの部位にどんな商品を試着しているのかについての一覧が含まれる。
【００７１】
また、個人用の試着画面（Ｐ１００２）において「画面共有」ボタンが押された場合には、共有グループ一覧画面（Ｐ１００４）を表示させる。共有グループ一覧画面（Ｐ１００４）からは、共有グループ新規作成・編集画面（Ｐ１００６）に移行し、さらに共有グループ・メンバ追加画面（Ｐ１００８）や共有条件設定画面（Ｐ１０１０）に移行することができる。共有グループ一覧画面（Ｐ１００４）で一覧表示された共有グループのうち、いずれかの共有グループをユーザが選択した場合、共有用の試着画面（Ｐ１０１２）を表示させる。この画面はＰ９１６（図９）の共有用の試着画面と同様の構成であり、「他商品選択」ボタンが押されると、販売サイトの商品選択画面（Ｐ１０１８）へ移行する。ユーザにより商品の選択及び試着操作の入力が行われると、試着対象（部位）選択画面（Ｐ１０２０）を表示させ、選択した商品をどのユーザのどの部位に試着させるのかを、ユーザに選択させる。
【００７２】
また、共有用の試着画面（Ｐ１０１２）において「試着リスト」ボタンが押された場合には、試着リスト画面（Ｐ１０１４）を表示させる。この画面では、どのユーザがどの部位にどんな商品を試着しているのかについての一覧（リスト）が含まれる。リストの行（ユーザの部位及び商品）が選択されて「試着商品のコピー」ボタンが押された場合、試着商品コピー画面（Ｐ１０１６）に移行する。試着商品コピー画面（Ｐ１０１６）にはユーザの一覧が含まれ、同じ商品を試着させるユーザを選択する操作を受け付けた場合、再び試着リスト画面（Ｐ９２０）を表示させる。ここでは、選択されたユーザに対しての試着処理（商品のコピー）を反映したリストが表示される。
【００７３】
また、個人用の試着画面（Ｐ１００２）又は共有用の試着画面（Ｐ１０１２）において「終了」ボタンが押された場合には、試着状況の保存を行い、処理を終了する。なお、上述同様、保存を行うかどうかを選択させる画面を表示させ、ユーザの指示に応じて処理を行うような構成であってもよい。
【００７４】
また、個人用の試着画面（Ｐ１００２）又は共有用の試着画面（Ｐ１０１２）において「購入」ボタンが押された場合には、端子Ｂを介して会計用試着リスト画面（Ｐ９２４）（図９）に移行する。
【００７５】
次に、図１１乃至図６２を用いて図１に示したシステムの動作を説明する。
【００７６】
ユーザはオンライン・ショッピングにおいて、例えばユーザ端末Ａ（３）（又はユーザ端末Ｂ（７））を操作して、購入候補となる商品の選択を行う。商品選択の操作を受け付けたユーザ端末Ａ（３）は、選択商品ページ・データの要求を例えば販売サイトＡサーバ（９）（又は販売サイトＢサーバ（１１））に対して送信する（ステップＳ１）。販売サイトＡサーバ（９）はユーザ端末Ａ（３）から選択商品ページ・データの要求を受信し（ステップＳ３）、例えば商品番号及び商品型式を記憶装置に格納する。販売サイトＡサーバ（９）は商品番号及び商品型式を用いて商品ＤＢ９１を検索し、その結果に基づき選択商品ページ・データを生成してユーザ端末Ａ（３）に対して送信する（ステップＳ５）。ユーザ端末Ａ（３）は販売サイトＡサーバ（９）から選択商品ページ・データを受信し、表示装置に表示する（ステップＳ７）。
【００７７】
図１２に選択商品ページの一例を示す。図１２に示す選択商品ページの例には、商品画像１２０、商品データ１２２、「ショッピング・カートに入れる」ボタン１２４、「試着する」ボタン１２６及び「買い物を続ける」ボタン１２８が含まれている。商品画像１２０は、選択された商品の画像であり、商品ＤＢ（図２）の画像データの列２１２に登録されているファイルを表示したものである。なお、画像データは２次元データであっても３次元データであってもよい。
【００７８】
商品データ１２２には、商品種別、色、サイズ及び単価として、商品ＤＢ（図２）の商品情報の列２０４の値、色の列２０６の値、サイズの列２０６の値及び単価の列２１４の値が含まれている。なお、生地・素材の列２１０の値や、他のデータが含まれるような構成でもよい。
【００７９】
「ショッピング・カートに入れる」ボタン１２４がユーザにより押された場合、当該ホームページを管理するサーバ（例えば販売サイトＡサーバ（９））のオンライン購入用データ記憶部に当該商品のデータが格納される。すなわち、仮想ショッピング・カートに商品が投入された状態となる。「買い物を続ける」ボタン１２８がユーザにより押された場合、商品を選択する前のオンライン・ショッピング用のページ（図示しない）に戻る。「試着する」ボタン１２６がユーザにより押された場合、図１１のステップＳ９以降の処理が行われる。
【００８０】
ユーザ端末Ａ（３）は、ユーザによる試着指示を受け付け（ステップＳ９）、試着ページ・データの要求を販売サイトＡサーバ（９）に対して送信する（ステップＳ１１）。販売サイトＡサーバ（９）は、試着ページ・データの要求をユーザ端末Ａ（３）から受信し（ステップＳ１３）、例えば商品番号及び商品型式を記憶装置に格納する。販売サイトＡサーバ（９）は試着ページ・データ要求をＡＳＰサーバ５に対して送信する（ステップＳ１５）。ＡＳＰサーバ５は試着ページ・データ要求を販売サイトＡサーバ（９）から受信し、例えば販売サイト・コード、商品番号及び商品型式を記憶装置に格納する（ステップＳ１７）。
【００８１】
ＡＳＰサーバ５はユーザを識別するために、図示しないログイン・ページ等によりユーザのログイン処理を実施する（ステップＳ２１）。なお、ＡＳＰサーバ５と販売サイトＡサーバ（９）とを連携させ、販売サイトＡサーバ（９）が事前にユーザのログインを受け付けておき、試着指示に応じてログイン・データ（例えばユーザＩＤ等）をＡＳＰサーバ５に送信するような構成であってもよい。ログイン処理が完了したら、ＡＳＰサーバ５はログイン・データを記憶装置に格納する（ステップＳ２３）。処理は端子Ｃを介して図１３の処理に移行する。
【００８２】
次にＡＳＰサーバ５は商品データの要求を販売サイトＡサーバ（９）に対して送信する（ステップＳ２５）。販売サイトＡサーバ（９）は商品データの要求をＡＳＰサーバ５から受信し（ステップＳ２７）、例えば商品コード及び商品型式を記憶装置に格納する。販売サイトＡサーバ（９）は商品番号及び商品型式を用いて商品ＤＢ９１を検索し、その結果抽出された商品データをＡＳＰサーバ５に対して送信する（ステップＳ２９）。ＡＳＰサーバ５は商品データを販売サイトＡサーバ（９）から受信し、記憶装置に格納する（ステップＳ３１）。なお、ステップＳ１９におけるログイン判定の前にＡＳＰサーバ５が販売サイトＡサーバ（９）から商品データを受信するような構成であってもよい。
【００８３】
ＡＳＰサーバ５は予め記憶装置に格納してある又はステップＳ２３において記憶装置に格納したユーザＩＤを用いて試着管理ＤＢ５１のバスケット管理テーブル（図４）の検索処理を行う（ステップＳ３３）。検索内容としては、当該ログイン・ユーザのＩＤで、生成者ＩＤに含まれているレコードを抽出するものである。すなわち、当該ログイン・ユーザが過去に生成した試着場面（バスケット）のデータを抽出する。既存の試着場面のデータが存在するかどうか判定し（ステップＳ３５）、存在しないと判定された場合は、処理は端子Ｄを介して図５７の処理へ移行する。存在すると判定された場合は、ＡＳＰサーバ５は共有・個人選択ページ・データを生成し、ユーザ端末Ａ（３）に対して送信する（ステップＳ３７）。ユーザ端末Ａ（３）は共有・個人選択ページ・データをＡＳＰサーバ５から受信し、表示装置に表示する（ステップＳ３９）。
【００８４】
図１４に共有・個人選択ページの一例を示す。図１４に示す共有・個人選択ページの例には、「個人」ボタン１４０及び「共有グループ」ボタン１４２が含まれている。「個人」ボタン１４０は、個人用試着場面へ移行するためのボタンであり、「共有グループ」ボタン１４２は、複数人による試着を行う共有グループ用試着場面へ移行するためのボタンである。なお、本実施の形態では、まず個人用試着場面を生成してから共有グループ用試着場面を生成するような構成となっているため、個人用試着場面だけが登録されていて、共有グループ用試着場面が登録されていない場合がある。そのような場合には、「共有グループ」ボタン１４２の色を薄く表示（グレー・アウト）し、押されても何も処理しないようにする。なお、「共有グループ」ボタン１４２を表示しないような構成であってもよい。
【００８５】
図１３の処理フローに戻り、ユーザ端末Ａ（３）はユーザからの選択入力（個人か共有グループか）を受け付ける（ステップＳ４１）。ユーザ端末Ａ（３）はユーザから受け付けた選択入力データをＡＳＰサーバ５に対して送信する（ステップＳ４３）。ＡＳＰサーバ５は選択入力データをユーザ端末Ａ（３）から受信し、記憶装置に格納する（ステップＳ４５）。処理は端子Ｅを介して図１５の処理に移行する。
【００８６】
ＡＳＰサーバ５は、受信した選択入力データが共有グループの選択であったかどうか判定する（ステップＳ４７）。すなわち、共有・個人選択ページ（図１４）において「共有グループ」ボタン１４２が押されたかどうか判断する。共有グループの選択ではなかったと判定された場合、処理は端子Ｆを介して図５７の処理へ移行する。共有グループの選択であったと判定された場合、ＡＳＰサーバ５はステップＳ３３において抽出されたデータを用いて共有グループ一覧ページ・データを生成し、ユーザ端末Ａ（３）に対して送信する（ステップＳ４９）。ユーザ端末Ａ（３）は共有グループ一覧ページ・データをＡＳＰサーバ５から受信し、表示装置に表示する（ステップＳ５１）。
【００８７】
図１６に共有グループ一覧ページの一例を示す。図１６に示す共有グループ一覧ページの例には、共有グループ・リスト１６０、「共有開始」ボタン１６２、「新規作成」ボタン１６４、「削除」ボタン１６６及び「編集」ボタン１６８が含まれている。共有グループ・リスト１６０には、ログイン・ユーザが管理者となっている共有グループの名称が含まれ、ラジオボタンにより選択できるようになっている。共有グループ・リスト１６０から１つの共有グループが選択され且つ「共有開始」ボタン１６２が押された場合、その共有グループでの共有試着処理を開始する指示がユーザにより選択入力されたこととなる。
【００８８】
また、「新規作成」ボタン１６４が押された場合、新しい共有グループを生成する指示がユーザにより選択入力されたこととなる。また、共有グループ・リスト１６０から１つの共有グループが選択され、且つ「削除」ボタン１６６が押された場合、その共有グループの登録を抹消する指示がユーザにより選択入力されたこととなり、同様に「編集」ボタン１６８が押された場合、その共有グループの情報を変更する指示がユーザにより選択入力されたこととなる。
【００８９】
図１５の処理フローに戻り、ユーザ端末Ａ（３）は、共有グループ一覧ページ（図１６）におけるユーザによる選択入力を受け付け（ステップＳ５３）、受け付けた選択データをＡＳＰサーバ５に対して送信する（ステップＳ５５）。ＡＳＰサーバ５は選択データをユーザ端末Ａ（３）から受信して記憶装置に格納する（ステップＳ５７）。ＡＳＰサーバ５は受信した選択データに基づき、ユーザの指示について以下の判定を行う。まず、共有開始かどうか、すなわち共有グループ一覧ページ（図１６）において共有グループ・リスト１６０から１つの共有グループが選択され且つ「共有開始」ボタン１６２が押されたかどうか判定する（ステップＳ５９）。共有開始であると判定された場合、処理は端子Ｇを介して図１７の処理に移行する。
【００９０】
共有開始ではないと判定された場合、新規作成かどうか、すなわち共有グループ一覧ページ（図１６）において「新規作成」ボタン１６４が押されたかどうか判定する（ステップＳ６１）。新規作成であると判定された場合、処理は端子Ｈを介して図２１の処理に移行する。
【００９１】
新規作成ではないと判定された場合、削除かどうか、すなわち共有グループ一覧ページ（図１６）において共有グループ・リスト１６０から１つの共有グループが選択され且つ「削除」ボタン１６４が押されたかどうか判定する（ステップＳ６３）。削除ではないと判定された場合は選択された共有グループの編集の場合であり、処理は端子Ｈを介して図２１の処理に移行する。
【００９２】
削除であると判定された場合、共有グループ・データから、選択された共有グループを削除する。すなわち試着管理ＤＢ５１から対応するレコードを削除する。なお、バスケット管理テーブル（図４）、利用者エントリ・テーブル（図５）、試着エントリ・テーブル（図６）及び購入管理テーブル（図７）は、親子関係等の関連が設定されている場合があり、レコード削除の際には不整合が発生しないように対応するレコードも削除する必要がある。
【００９３】
本実施の形態では、各テーブルにおいて、削除すべき共有グループのバスケットＩＤと同じバスケットＩＤを含むレコードを全て削除すればよい。また、削除の場合には、図示しないが再確認のページを表示させ、ユーザの再確認を促すような構成であってもよい。削除処理終了後は、処理は端子Ｊを介してステップＳ４９に戻る。すなわち、削除処理の結果を反映させて共有グループ一覧ページ・データの生成及び送信を行う。
【００９４】
図１７を用いて、ステップＳ５９において共有開始であると判定された場合の処理（端子Ｇの後の処理）について説明する。ＡＳＰサーバ５は、試着者選択ページ・データを生成し、ユーザ端末Ａ（３）に対して送信する（ステップＳ６７）。ユーザ端末Ａ（３）は試着者選択ページ・データをＡＳＰサーバ５から受信し、表示装置に表示する（ステップＳ６９）。
【００９５】
図１８に試着者選択ページの一例を示す。図１８に示す試着者選択ページの例には、試着リスト（共有グループ）名称１８０、商品情報１８２、試着リスト１８４、「試着」ボタン１８６及び「キャンセル」ボタン１８８が含まれている。試着リスト（共有グループ）名称１８０には、ステップＳ５３においてユーザにより選択された共有グループの名称が示されている。商品情報１８２には、メーカ又は販売店名や商品種別等、試着しようとしている商品の情報が含まれている。
【００９６】
試着リスト１８４には、試着者名、部位、店舗、商品及びオプションが含まれ、誰（どのユーザ）のどの部位（上半身等）にどこ（店舗）の何（黄色いＭサイズのＴシャツ等）が試着されているのかが分かるような一覧情報が示されている。また、各行をラジオボタンにより選択できるようになっている。行が選択され且つ「試着」ボタン１８６が押された場合には、試着指示がユーザにより選択入力されたこととなる。「キャンセル」ボタン１８８が押された場合には、共有グループ一覧ページ（図１６）の表示に戻ってもよいし、誰にも試着させずに次に進むような構成であってもよい。また、Ｔシャツを下半身には試着できないようにする設定がなされている場合もある。
【００９７】
図１７の処理フローに戻り、ユーザ端末Ａ（３）はユーザによる試着者（部位）選択入力を受け付け（ステップＳ７１）、ユーザ端末Ａ（３）は選択試着者（部位）のデータをＡＳＰサーバ５に対して送信する（ステップＳ７３）。ＡＳＰサーバ５は、選択試着者（部位）のデータをユーザ端末Ａ（３）から受信し、一旦記憶装置に格納する（ステップＳ７５）。
【００９８】
さらにＡＳＰサーバ５は、受信したデータを用いて試着管理ＤＢ５１の試着エントリ・テーブル（図６）を更新する（ステップＳ７７）。この時、購入管理テーブル（図７）との整合性をとる必要がある場合（例えば試着をやめた商品は購入しないようにする場合）は、試着エントリ・テーブルで更新（上書消去）されたレコードに対応する（すなわちバスケットＩＤの値及びアイテム番号（ＮＯ．）の値が同じ）購入管理テーブルのレコードが存在すればそれを削除する。
【００９９】
また、試着していない部位に試着がなされた場合には、試着エントリ・テーブルにレコードを追加し、利用者エントリ・テーブル（図５）の対応する（すなわちバスケットＩＤ及びユーザＩＤで特定される）レコードの試着エントリ数の列５１０の値を１つ増やす。
【０１００】
ＤＢ更新処理の終了後、ＡＳＰサーバ５は共有試着ページ・データを生成し、ユーザ端末Ａ（３）に対して送信する（ステップＳ７９）。ユーザ端末Ａ（３）は共有試着ページ・データをＡＳＰサーバ５から受信し、表示装置に表示する（ステップＳ８１）。
【０１０１】
図１９に共有試着ページの一例を示す。図１９に示す共有試着ページの例には、ＵＲＬ１９００、ページ見出し１９０２、「他商品選択」ボタン１９０４、「試着リスト」ボタン１９０６、「画面共有」ボタン１９０８、「購入」ボタン１９１０、「終了」ボタン１９１２、仮想試着画像１９１４及び購入候補リスト１９１６が含まれている。
【０１０２】
ＵＲＬ１９００には、本ページのアドレスが示されている。共有開始時は、共有グループの生成者（管理者）がこのアドレスを他のユーザに通知し、他のユーザがこのアドレスを用いてページを閲覧することにより共有を行う。
【０１０３】
なお、本実施の形態ではユーザ毎に画像表示や試着操作等の設定を行うため、このＵＲＬ１９００で示されるアドレスはユーザ毎に異なる。例えば図１９に示す例では、「／￣０ｘ０００１／ｇｒｏｕｐ−４ｎｉｎ／」の部分で示されるディレクトリまでは本グループに属するユーザに共通であり、「０ｘ０００１．ｈｔｍｌ」の部分（ページ・ファイル）が各ユーザＩＤ毎に生成されるような構成になっている。そのため、共有グループの管理者は共通のディレクトリを他の共有ユーザに通知し、他の共有ユーザは通知された共通のディレクトリと自己のユーザＩＤとを含んだＵＲＬによって共有試着ページを閲覧する。
【０１０４】
なお、共有ユーザを追加する際に、追加されたユーザ用のＵＲＬを生成して自動的に通知メールの送信を行うような場合もある。
【０１０５】
共有試着ページのＵＲＬを通知された管理者以外のユーザは、自己の操作する端末（例えばユーザ端末Ｂ（７））のブラウザ機能を使用して共有試着ページにアクセスする。すなわち、ユーザ端末Ｂ（７）は共有試着ページ・データの要求をＡＳＰサーバ５に対して送信する。
【０１０６】
ＡＳＰサーバ５は共有試着ページ・データの要求をユーザ端末Ｂ（７）から受信し、ログイン処理を行った後、ステップＳ７９の処理に移行する。そしてステップＳ８１においてユーザ端末Ｂ（７）の表示装置に共有試着ページを表示させることにより、管理者以外のユーザも共有試着ページを閲覧することができる。
【０１０７】
ページ見出し１９０２には共有グループ名及びグループ生成者の氏名が示されており、ユーザは自分がどの共有試着ページを閲覧しているのかが分かるようになっている。「他商品選択」ボタン１９０４が押された場合には、試着していない商品を選択するために、販売サイト（例えば販売サイトＡサーバ（９））が管理するホームページへ移行する指示がユーザにより選択入力されたこととなる。なお、提携販売サイトの一覧が表示されるようにしてもよいし、ユーザにより予め登録された一の販売サイトに直接遷移してもよい。
【０１０８】
「試着リスト」ボタン１９０６が押された場合には、商品の着脱操作等を行うために、試着リスト・ページへの移行指示がユーザにより選択入力されたこととなる。「画面共有」ボタン１９０８が押された場合には、他の共有試着場面に移行するために、一旦共有グループ一覧ページ（図１６）へ移行する指示がユーザにより選択入力されたこととなる。
【０１０９】
なお、複数のユーザが同時に同じ共有グループの共有試着ページを閲覧している時に、個人の判断で勝手に他の共有試着ページに移行するのが好ましくない場合もある。この場合、共有試着ページにおいて「画面共有」ボタン１９０８が押されると、共有グループ一覧ページ（図１６）には移行せずに、当該共有グループの編集ページ（後述する図２２）に移行するような構成であってもよい。
【０１１０】
また、管理者以外の共有メンバにより「画面共有」ボタン１９０８が押された場合には、当該メンバについての共有設定ページ（後述する図２６）へ移行する指示がユーザにより選択入力されたこととなる。管理者以外の共有メンバが閲覧するページでは、「画面共有」ボタン１９０８に表示されるボタン名を「共有設定」と変えて表示するような構成であってもよい。
【０１１１】
「購入」ボタン１９１０が押された場合には、試着している商品の会計を行うページへ移行する指示がユーザにより選択入力されたこととなる。また、「終了」ボタン１９１２が押された場合には、試着又は閲覧を終了する指示がユーザにより選択入力されたこととなる。
【０１１２】
仮想試着画像１９１４には、本実施の形態では同じ共有グループのメンバであるユーザの画像及び試着している商品の画像が含まれている。図１９に示す例では４人のユーザの画像及び試着している商品が全て閲覧可能となっているが、各ユーザによる共有設定によっては、例えばあるユーザの上半身等の一部が見えないような場合もある。
【０１１３】
購入候補リスト１９１６には、各ユーザが試着している商品の情報が含まれており、仮想試着画像１９１４とあわせて、誰が何を試着していて見た目はどのようになるのかが分かるような構成となっている。
【０１１４】
なお、本実施の形態では、ユーザは商品の着脱操作を試着リスト・ページにおいて行うような構成となっているが、仮想試着画像１９１４の商品画像に対するマウスのドラッグ・アンド・ドロップによって着脱操作が行われるような構成であってもよい。この場合、各商品画像及びユーザ画像のレイヤ及び位置情報を例えばＪＡＶＡ（Ｓｕｎ　Ｍｉｃｒｏｓｙｓｔｅｍｓ社の商標）等により管理する必要がある。
【０１１５】
図１７の処理フローに戻り、ユーザ端末Ａ（３）は共有試着ページにおけるユーザによる操作入力を受け付ける（ステップＳ８３）。ユーザ端末Ａ（３）は受け付けた選択操作データをＡＳＰサーバ５に対して送信する（ステップＳ８５）。ＡＳＰサーバ５は、共有試着ページにおけるユーザの選択操作データをユーザ端末Ａ（３）から受信し、一旦記憶装置に格納する（ステップＳ８７）。処理は端子Ｋを介して図２０の処理に移行する。
【０１１６】
ＡＳＰサーバ５は、ステップＳ８７で受信した選択操作データに基づき、ユーザの指示について以下の判定を行う。まず、他商品選択かどうか、すなわち共有試着ページ（図１９）において、販売サイト（例えば販売サイトＡサーバ（９））が管理する商品選択ホームページへ移行するために「他商品選択」ボタン１９０４が押されたかどうか判定する（ステップＳ８９）。他商品選択であると判定された場合、処理は端子Ｌを介して図３７の処理に移行する。
【０１１７】
他商品選択の指示ではないと判定された場合、試着リストの表示指示かどうか、すなわち共有試着ページ（図１９）において「試着リスト」ボタン１９０６が押されたかどうか判定する（ステップＳ９１）。試着リストの表示指示であると判定された場合、処理は端子Ｍを介して図２９の処理に移行する。
【０１１８】
試着リストの表示指示ではないと判定された場合、画面共有かどうか、すなわち共有試着ページ（図１９）において他の共有試着ページへ移行するために「画面共有」ボタン１９０８が押されたかどうか判定する（ステップＳ９３）。画面共有であると判定された場合、処理は端子Ｊを介してステップＳ４９（図１５）の処理に戻る。
【０１１９】
なお、管理者以外の共有メンバにより「画面共有」ボタン１９０８が押されたと判定された場合には、当該メンバについての共有設定ページ（後述する図２６）へ移行する処理を行う。
【０１２０】
画面共有ではないと判定された場合、商品購入かどうか、すなわち共有試着ページ（図１９）において会計処理を行うために「購入」ボタン１９１０が押されたかどうか判定する（ステップＳ９５）。商品購入であると判定された場合、処理は端子Ｐを介して図３８の処理に移行する。
【０１２１】
商品購入ではないと判定された場合はすなわち終了の場合（「終了」ボタン１９１２が押された場合）であり、ＡＳＰサーバ５は試着状況の保存処理として試着管理ＤＢ５１の更新を行う（ステップＳ９７）。この保存処理はグループ生成者が終了ボタンを押した場合のみ実施されるという構成であってもよい。なお、保存しないで終了したいこともある場合には、試着管理ＤＢ５１の更新を行う前に、ユーザに保存処理の実行可否の確認をとるような構成であってもよい。
【０１２２】
ＡＳＰサーバ５は図示しない終了確認ページ・データを生成し、ユーザ端末Ａ（３）に対して送信する（ステップＳ９９）。ユーザ端末Ａ（３）は終了確認ページ・データをＡＳＰサーバ５から受信し、表示装置に表示する（ステップＳ１０１）。なお、終了確認ページに「キャンセル」ボタンを設置し、「キャンセル」ボタンが押された場合には共有試着ページ（図１９）に戻るような構成であってもよい。終了確認ページ・データの送信後、ＡＳＰサーバ５は当該ユーザのログオフ処理を行う（ステップＳ１０３）。
【０１２３】
次に、図２１を用いて、ステップＳ６１（図１５）において新規作成であると判定された場合又はステップＳ６３（図１５）において削除ではない（編集である）と判定された場合の処理（端子Ｈの後の処理）について説明する。ＡＳＰサーバ５は、共有グループ新規作成・編集ページのデータを生成し、ユーザ端末Ａ（３）に対して送信する（ステップＳ１０５）。ユーザ端末Ａ（３）は共有グループ新規作成・編集ページのデータをＡＳＰサーバ５から受信し、表示装置に表示する（ステップＳ１０７）。
【０１２４】
図２２に共有グループ新規作成・編集ページの一例を示す。図２２に示す共有グループ新規作成・編集ページの例には、グループ名入力欄２２０、ＵＲＬディレクトリ入力欄２２２、メンバ・リスト２２４、「ＯＫ」ボタン２２６、「メンバ追加」ボタン２２７、「削除」ボタン２２８及び「共有条件」ボタン２２９が含まれている。
【０１２５】
本ページは、当該グループ用仮想バスケットの生成及び設定変更の際に使用され、本ページにおけるユーザの操作に伴い、試着管理ＤＢ５１のバスケット管理テーブル（図４）及び利用者エントリ・テーブル（図５）の対応するレコードの追加・更新処理が行われる。
【０１２６】
グループ名入力欄２２０には、バスケット管理テーブル（図４）の名称の列４０２の値が編集可能な状態で示されている。共有グループの新規作成の場合には空欄になっており、新しい共有グループの名称が入力される。ＵＲＬディレクトリ入力欄２２２も同様に、バスケット管理テーブル（図４）の画面ＵＲＬの列４１０の値が編集可能な状態で示されている。共有グループの新規作成の場合には空欄になっており、メンバが使用する新しいＵＲＬディレクトリが入力される。
【０１２７】
メンバ・リスト２２４には当該共有グループ・メンバ（バスケットの利用メンバ）の一覧及びラジオボタンが示されている。これらのメンバは、バスケットＩＤで抽出された利用者エントリ・テーブル（図５）のレコードの利用者名の列５０４の値で構成されている。
【０１２８】
なお、本実施の形態では、共有グループの新規作成の場合には管理者（生成者）ユーザだけがメンバ・リスト２２４に示されるような構成となっている。「ＯＫ」ボタン２２６が押された場合には、ページに示されている内容をそのまま保存又は新規登録する指示がユーザにより選択入力されたこととなる。「メンバ追加」ボタン２２７が押された場合には、当該共有グループに新たにメンバを追加登録する指示がユーザにより選択入力されたこととなる。「削除」ボタン２２８が押された場合には、ラジオボタンで選択されたメンバを当該共有グループから登録抹消する指示がユーザにより選択入力されたこととなる。
【０１２９】
「メンバ追加」ボタン２２７及び「削除」ボタン２２８については管理者のみが押すことができるようになっている。また、「共有条件」ボタン２２９が押された場合には、共有条件を設定又は変更する指示がユーザにより選択入力されたこととなる。なお、この共有条件については、ユーザ本人が自らについての設定しかできない構成となっている。また、ラジオボタンでのメンバ選択は、削除の場合にのみ処理に反映される。
【０１３０】
図２１の処理フローに戻り、ユーザ端末Ａ（３）はユーザによる共有グループについての入力データを受け付ける（ステップＳ１０９）。ユーザ端末Ａ（３）は受け付けたユーザの入力データをＡＳＰサーバ５に対して送信する（ステップＳ１１１）。ＡＳＰサーバ５は共有グループについての入力データをユーザ端末Ａ（３）から受信し、一旦記憶装置に格納する（ステップＳ１１３）。
【０１３１】
ＡＳＰサーバ５は、ステップＳ１１３で受信した共有グループについての入力データに基づき、ユーザの指示について以下の判定を行う。まず、ＯＫの指示かどうか、すなわち共有グループ新規作成・編集ページ（図２２）において、ページに示されている内容をそのまま保存又は新規登録するために「ＯＫ」ボタン２２６が押されたかどうか判定する（ステップＳ１１５）。ＯＫであると判定された場合、試着管理ＤＢ５１に当該共有グループのデータを格納する（ステップＳ１１７）。具体的には、共有グループの新規作成であった場合にはバスケット管理テーブル（図４）及び利用者エントリ・テーブル（図５）にレコードを追加する。
【０１３２】
共有グループの編集であった場合には、バスケット管理テーブル（図４）及び利用者エントリ・テーブル（図５）の対応するレコードを更新する。処理は端子Ｊを介してステップＳ４９（図１５）に戻り、ＡＳＰサーバ５は新たに共有グループ一覧ページ（図１６）のデータを生成してユーザ端末Ａ（３）に対して送信する。
【０１３３】
また、ステップＳ１１５においてＯＫではないと判定された場合、メンバ追加の指示かどうか、すなわち、共有グループ新規作成・編集ページ（図２２）において、新たにメンバを追加するために「メンバ追加」ボタン２２７が押されたかどうか判定する（ステップＳ１１９）。メンバ追加であると判定された場合、処理は端子Ｑを介して図２３の処理に移行する。
【０１３４】
メンバ追加ではないと判定された場合、削除の指示かどうか、すなわち、共有グループ新規作成・編集ページ（図２２）において、メンバを登録抹消するために「削除」ボタン２２８が押されたかどうか判定する（ステップＳ１２１）。削除であると判定された場合、共有グループのデータから、ラジオボタンで選択されたメンバのデータを削除する（ステップＳ１２３）。具体的には、利用者エントリ・テーブル（図５）の対応するレコードを削除し、バスケット管理テーブル（図４）の対応するレコードの利用者エントリ数の列４１４の値を１つ減らす。
【０１３５】
処理は端子Ｈを介してステップＳ１０５に戻り、ＡＳＰサーバ５は新たに共有グループ新規作成・編集ページ（図２２）のデータを生成してユーザ端末Ａ（３）に対して送信する。また、ステップＳ１２１において削除ではないと判定された場合には、すなわち共有条件の設定であり、処理は端子Ｒを介して図２５の処理に移行する。
【０１３６】
次に、図２３を用いて、ステップＳ１１９においてメンバ追加であると判定された場合の処理（端子Ｑの後の処理）について説明する。ＡＳＰサーバ５は、メンバ追加ページのデータを生成し、ユーザ端末Ａ（３）に対して送信する（ステップＳ１２５）。ユーザ端末Ａ（３）はメンバ追加ページのデータをＡＳＰサーバ５から受信し、表示装置に表示する（ステップＳ１２７）。
【０１３７】
図２４にメンバ追加ページの一例を示す。図２４に示すメンバ追加ページの例には、ユーザＩＤ入力欄２４０、氏名入力欄２４２、Ｅ−ｍａｉｌアドレス入力欄２４４、「登録」ボタン２４６及び「キャンセル」ボタン２４８が含まれている。
【０１３８】
ユーザＩＤ入力欄２４０には、新規に追加されるユーザのユーザＩＤが入力される。すなわち、本実施の形態においては、ユーザ管理ＤＢ５３に登録済みでユーザＩＤを持っているユーザだけが、共有グループの追加メンバとして登録可能となっている。同様に、氏名入力欄２４２にはユーザの氏名が入力され、Ｅ−ｍａｉｌアドレス入力欄２４４にはユーザの電子メール・アドレスが入力される。
【０１３９】
「登録」ボタン２４６が押された場合には、入力したデータに基づき新規メンバを登録する指示がユーザにより選択入力されたこととなる。「キャンセル」ボタン２４８が押された場合には、新規メンバの登録処理をやめる指示がユーザにより選択入力されたこととなる。
【０１４０】
図２３の処理フローに戻り、ユーザ端末Ａ（３）はユーザによる追加メンバについてのデータ入力を受け付ける（ステップＳ１２９）。ユーザ端末Ａ（３）は追加メンバについてのデータをＡＳＰサーバ５に対して送信する（ステップＳ１３１）。ＡＳＰサーバ５は追加メンバについてのデータをユーザ端末Ａ（３）から受信し、一旦記憶装置に格納する（ステップＳ１３３）。
【０１４１】
ここでメンバ追加ページ（図２４）におけるユーザの指示が登録であったかどうか判定する（ステップＳ１３５）。登録ではなかったと判定された場合、すなわちキャンセルの指示であった場合には、端子Ｈを介してステップＳ１０５（図２１）の処理に戻る。登録の指示であったと判定された場合、共有グループのデータに登録されたメンバのデータを追加する（ステップＳ１３７）。具体的には、試着管理ＤＢ５１の利用者エントリ・テーブル（図５）にレコードを追加し、バスケット管理テーブル（図４）の対応するレコードの利用者エントリ数の列４１４の値を１つ増やす。
【０１４２】
処理は端子Ｈを介してステップＳ１０５（図２１）に戻り、ＡＳＰサーバ５は新たに共有グループ新規作成・編集ページ（図２２）のデータを生成してユーザ端末Ａ（３）に対して送信する。
【０１４３】
次に、図２５を用いて、ステップＳ１２１（図２１）において削除ではないと判定された場合（すなわち共有条件の設定であると判定された場合）の処理（端子Ｒの後の処理）について説明する。ＡＳＰサーバ５は、共有設定ページのデータを生成し、ユーザ端末Ａ（３）に対して送信する（ステップＳ１３９）。ユーザ端末Ａ（３）は共有設定ページのデータをＡＳＰサーバ５から受信し、表示装置に表示する（ステップＳ１４１）。
【０１４４】
図２６に共有設定ページの一例を示す。図２６に示す共有設定ページの例には、ユーザ情報２６０、試着画面公開範囲の設定部２６２、試着リスト公開範囲の設定部２６４、他人による自己試着服の利用（コピー）可能範囲の設定部２６５、他人による自己画像への試着可能範囲の設定部２６６、共有画面での試着可能メンバの設定部２６７、「登録」ボタン２６８及び「キャンセル」ボタン２６９が含まれている。
【０１４５】
ユーザ情報２６０には、共有設定を行うユーザのユーザＩＤ、氏名及びＥ−ｍａｉｌアドレスが示されている。このユーザ情報は、設定を行おうとしているユーザ本人の情報であり、試着管理ＤＢ５１の利用者エントリ・テーブル（図５）の対応するレコードのユーザＩＤの列５０２の値、利用者名の列５０４の値及びＥ−ｍａｉｌアドレスの列５０６の値によって構成されている。
【０１４６】
また、試着画面公開範囲の設定部２６２から共有画面での試着可能メンバの設定部２６７までにおいては、ユーザが試着条件を設定するようになっており、設定結果が登録されると試着管理ＤＢ５１の利用者エントリ・テーブル（図５）において対応するレコードの共有条件の列５１０の値が更新される。この共有条件の列５１０の値は５桁の数値になっており、各桁の値が試着条件の１乃至５、すなわち試着画面公開範囲の設定部２６２から共有画面での試着可能メンバの設定部２６７までの各設定値に対応している。具体的には以下の通りとなっている。
【０１４７】
試着画面公開範囲の設定部２６２では、「全身」、「上半身」及び「下半身」の体の部位が示され、ラジオボタンで選択できるようになっている。共有グループのメンバであるユーザは、共有試着ページにおいて自己の画像を他のメンバに見せる範囲を設定する。なお、共有グループのメンバが自己の画像を他のメンバに全く見せないような設定は適切ではないため、ここでは「なし」という選択項目は存在しない。設定値は「全身」が選択された場合は”１”、「上半身」が選択された場合は”２”、「下半身」が選択された場合は”３”となり、利用者エントリ・テーブル（図５）における共有条件の列５１０の値の５桁の数値のうち、１番左の桁に登録される。
【０１４８】
試着リスト公開範囲の設定部２６４では、「全身」、「上半身」及び「下半身」の体の部位と「なし」とが示され、ラジオボタンで選択できるようになっている。共有グループのメンバであるユーザは、共有試着ページにおいて自己の試着リストのうち、他のメンバに見せる範囲を設定する。設定値は「全身」が選択された場合は”１”、「上半身」が選択された場合は”２”、「下半身」が選択された場合は”３”、「なし」が選択された場合は”０”となり、利用者エントリ・テーブル（図５）における共有条件の列５１０の値の５桁の数値のうち、左から２番目の桁に登録される。
【０１４９】
他人による自己試着服の利用（コピー）可能範囲の設定部２６５では、「全身」、「上半身」及び「下半身」の体の部位と「なし」とが示され、ラジオボタンで選択できるようになっている。共有グループのメンバであるユーザは、共有試着ページにおいて自己の試着服（商品）のうち、他のメンバに利用（コピー）可能とする範囲を設定する。設定値は「全身」が選択された場合は”１”、「上半身」が選択された場合は”２”、「下半身」が選択された場合は”３”、「なし」が選択された場合は”０”となり、利用者エントリ・テーブル（図５）における共有条件の列５１０の値の５桁の数値のうち、左から３番目の桁に登録される。
【０１５０】
なお、試着リストに公開されない部位に試着している商品については、他のメンバは見ることができず、当然利用もできないため、上で述べた試着リスト公開範囲の設定部２６４において設定された範囲内でのみ設定可能となる。例えば、試着リスト公開範囲の設定部２６４において「上半身」が選択された場合、他人による自己試着服の利用（コピー）可能範囲の設定部２６５では、「上半身」及び「なし」のいずれか１つが設定可能となる。
【０１５１】
他人による自己画像への試着可能範囲の設定部２６６では、「全身」、「上半身」及び「下半身」の体の部位と「なし」とが示され、ラジオボタンで選択できるようになっている。共有グループのメンバであるユーザは、共有試着ページにおいて自己画像の部位のうち、他のメンバによる試着操作を可能とする範囲を設定する。設定値は「全身」が選択された場合は”１”、「上半身」が選択された場合は”２”、「下半身」が選択された場合は”３”、「なし」が選択された場合は”０”となり、利用者エントリ・テーブル（図５）における共有条件の列５１０の値の５桁の数値のうち、左から４番目の桁に登録される。
【０１５２】
なお、画像又は試着リストのいずれかのみを見て他のメンバの試着操作を行うことは適切ではないため、上で述べた試着画面公開範囲の設定部２６２及び試着リスト公開範囲の設定部２６４において設定された範囲のうち共通の範囲についてのみ、この設定を可能とするような構成であってもよい。この場合、例えば、試着画面公開範囲の設定部２６２において「上半身」が選択され且つ試着リスト公開範囲の設定部２６４において「下半身」が選択されると、他人による自己画像への試着可能範囲の設定部２６６には「なし」のみが設定可能となる。
【０１５３】
共有画面での試着可能メンバの設定部２６７には、管理者以外の共有メンバ及び各メンバに対応するチェック・ボックスが示されている。本設定項目については管理者のみが設定可能であり、管理者は共有試着ページにおいて他のメンバに試着を可能にするかどうかを設定する。チェック・ボックスにチェックが入っている状態であれば、当該メンバは共有試着ページにおける試着が可能となる。設定値は、チェックが入っている場合は”１”、チェックが入っていない場合は”０”となり、利用者エントリ・テーブル（図５）内の設定対象のメンバに対応するレコードについての共有条件の列５１０の値の５桁の数値のうち、１番右の桁に登録される。
【０１５４】
なお、管理者自身については試着可能と設定されており、設定値は”１”であり、管理者に対応するレコードについての共有条件の列５１０の値の５桁の数値のうち、１番右の桁に登録される。なお、管理者についても管理者自ら試着するかしないかを設定できるようにしてもよい。
【０１５５】
また、管理者が新規に共有グループ（共有試着場面）を生成した場合及び管理者によって他のメンバが登録された場合における管理者及び他のメンバの設定値の初期値は全て”１”となっている。すなわち、利用者エントリ・テーブル（図５）の共有条件の列５１０の値は”１１１１１”である。
【０１５６】
「登録」ボタン２６８が押された場合には、入力したデータに基づき共有設定を登録する指示がユーザにより選択入力されたこととなる。「キャンセル」ボタン２６９が押された場合には、共有設定をやめる指示がユーザにより選択入力されたこととなる。
【０１５７】
図２５の処理フローに戻り、ユーザ端末Ａ（３）はユーザによる共有設定データの入力を受け付ける（ステップＳ１４３）。ユーザ端末Ａ（３）は、ユーザの指示に応じて入力された共有設定データをＡＳＰサーバ５に対して送信する（ステップＳ１４５）。ＡＳＰサーバ５は共有設定データをユーザ端末Ａ（３）から受信し、一旦記憶装置に格納する（ステップＳ１４７）。
【０１５８】
ここで共有設定ページ（図２６）におけるユーザの指示が登録であったかどうか判定する（ステップＳ１４９）。登録ではなかったと判定された場合、すなわちキャンセルの指示であった場合には、端子Ｈを介してステップＳ１０５の処理（図２１）に戻る。登録の指示であったと判定された場合、共有グループのデータに設定された条件を追加する（ステップＳ１５１）。具体的には、試着管理ＤＢ５１の利用者エントリ・テーブル（図５）の対応するレコードの共有条件の列５１０の値を更新する。
【０１５９】
処理は端子Ｈを介してステップＳ１０５（図２１）に戻り、ＡＳＰサーバ５は共有グループ新規作成・編集ページ（図２２）のデータを生成してユーザ端末Ａ（３）に対して送信する。なお、管理者以外の共有メンバにより共有設定ページ（図２６）における操作（共有設定データの入力等）が行われた場合には、処理はステップＳ７９（図１７）に戻り、ＡＳＰサーバ５は共有試着ページ（図１９）のデータを生成してユーザ端末Ａ（３）に対して送信する。
【０１６０】
図２７及び図２８に、共有設定後の共有試着ページの一例を示す。図２７に示す第１の共有設定後の共有試着ページの例には、ＵＲＬ２７００、ページ見出し２７０２、「他商品選択」ボタン２７０４、「試着リスト」ボタン２７０６、「画面共有」ボタン２７０８、「購入」ボタン２７１０、「終了」ボタン２７１２、仮想試着画像２７１４及び購入候補リスト２７１６が含まれている。
【０１６１】
上で説明した図１９に示す共有試着ページとの違いは、仮想試着画像２７１４及び購入候補リスト２７１６にある。まず仮想試着画像２７１４において、１番左のユーザの下半身が隠されているような画像が示されている。これは、共有設定ページ（図２６）において、試着画面公開範囲の設定部２６２における設定が当該ユーザにより「上半身」とされた結果であり、当該設定は画像としてこのように反映されている。また、購入候補リスト２７１６において、第１のユーザの下半身の試着商品が「非表示設定」と示されている。
【０１６２】
なお、本実施の形態では、仮想試着画像２７１４に示されているユーザ画像を左側から第１のユーザ、第２のユーザと順に定義しており、購入候補リスト２７１６にもその順番でユーザ毎にデータが示されている。そして、仮想試着画像２７１４において１番左のユーザの下半身の試着商品が、購入候補リスト２７１６において「非表示設定」と示されている。これは、共有設定ページ（図２６）において、試着リスト公開範囲２６４の設定が当該ユーザにより「上半身」とされた結果であり、閲覧されるデータとして上記設定はこのように反映されている。
【０１６３】
また、試着リスト２７０６が押された場合においても、同様に当該部位に対応する商品データは示されない。この場合、利用者エントリ・テーブル（図５）の対応するレコードの共有条件の列５１０の値は、左から１桁目及び２桁目がどちらも”２”に設定されている。なお、第１のユーザのユーザ端末では図１９のような画面が表示される。
【０１６４】
図２８に示す第２の共有設定後の共有試着ページの例には、ＵＲＬ２８００、ページ見出し２８０２、「他商品選択」ボタン２８０４、「試着リスト」ボタン２８０６、「画面共有」ボタン２８０８、「購入」ボタン２８１０、「終了」ボタン２８１２、仮想試着画像２８１４及び購入候補リスト２８１６が含まれている。
【０１６５】
図２７の例と同様、上で説明した図１９に示す共有試着ページとの違いは、仮想試着画像２８１４及び購入候補リスト２８１６にある。まず仮想試着画像２８１４において、左から２番目（第２）のユーザの上半身が隠されているような画像が示されている。これは、共有設定ページ（図２６）において、試着画面公開範囲の設定部２６２における設定が当該ユーザにより「下半身」とされた結果であり、当該設定は画像としてこのように反映されている。
【０１６６】
また、購入候補リスト２８１６において、第１のユーザの下半身の試着商品が「非表示設定」と示されており、第２のユーザの上半身の試着商品のデータは示されている。これは、共有設定ページ（図２６）において、第１のユーザの試着リスト公開範囲の設定部２６４における設定が「上半身」とされ、第２のユーザの試着リスト公開範囲の設定部２６４における設定が「全身」とされた結果であり、当該設定は閲覧されるデータとしてこのように反映されている。この場合、利用者エントリ・テーブル（図５）の対応するレコードの共有条件の列５１０の値は、第１のユーザについては左から１桁目が”１”に設定され、２桁目が”２”に設定されている。また、第２のユーザについては左から１桁目が”３”に設定され、２桁目が”１”に設定されている。このようにして、他の共有メンバに公開する情報を設定した場合には、当該設定が共有試着ページに反映されるようになる。
【０１６７】
次に、図２９を用いて、ステップＳ９１（図２０）において試着リストであると判定された場合の処理（端子Ｍの後の処理）について説明する。ＡＳＰサーバ５は、試着リスト・ページのデータを生成し、ユーザ端末Ａ（３）に対して送信する（ステップＳ１５３）。ユーザ端末Ａ（３）は試着リスト・ページのデータをＡＳＰサーバ５から受信し、表示装置に表示する（ステップＳ１５５）。
【０１６８】
図３０に、試着リスト・ページの一例を示す。図３０に示す試着リスト・ページの例には、試着リスト（共有グループ）名称３００、試着リスト３０２、「試着をやめる」ボタン３０４、「試着商品のコピー」ボタン３０６及び「試着画面へ」ボタン３０８が含まれている。試着リスト（共有グループ）名称３００には、ユーザが現在閲覧している共有試着ページ（共有グループ）の名称が示されている。試着リスト３０２には、試着者名、部位、店舗、商品及びオプションが含まれ、誰（どのユーザ）のどの部位（上半身等）にどこ（店舗）の何（黄色いＭサイズのＴシャツ等）が試着されているのかが分かるような一覧情報が示されている。また、各行をラジオボタンにより選択できるようになっている。
【０１６９】
行が選択され且つ「試着をやめる」ボタン３０４が押された場合には、選択された商品の試着をやめるという指示がユーザにより選択入力されたこととなる。また、行が選択され且つ「試着商品のコピー」ボタン３０６が押された場合には、選択された商品をコピーして別のメンバにも試着させるという指示がユーザにより選択入力されたこととなる。「試着画面へ」ボタン３０８が押された場合には、共有試着ページに戻る指示がユーザにより選択入力されたこととなる。
【０１７０】
図２９の処理フローに戻り、ユーザ端末Ａ（３）はユーザによる操作選択入力を受け付ける（ステップＳ１５７）。ユーザ端末Ａ（３）は操作選択入力データをＡＳＰサーバ５に対して送信する（ステップＳ１５９）。ＡＳＰサーバ５は操作選択入力データをユーザ端末Ａ（３）から受信し、一旦記憶装置に格納する（ステップＳ１６１）。
【０１７１】
ここで試着リスト・ページ（図３０）におけるユーザの指示が「試着をやめる」であったかどうか判定する（ステップＳ１６３）。「試着をやめる」ではなかったと判定された場合には、共有状態であるかどうか判定する（ステップＳ１６５）。これは本処理フローが個人用試着リスト・ページが使用された場合においても共通に使用されるフローであり、個人用試着リスト・ページと共有グループ用試着リスト・ページとでは、ページに含まれるボタンが違うために行う判定処理である。すなわちステップ１６５において、共有状態ではない（すなわち個人用試着リスト・ページからの指示データを受信した）と判定された場合には、端子Ｆを介して図５７の処理に移行する。
【０１７２】
共有状態である（すなわち共有試着リスト・ページからの指示データを受信した）と判定された場合には、試着リスト・ページ（図３０）におけるユーザの指示が試着商品のコピーであったかどうかを判定する（ステップＳ１６７）。試着商品のコピーであったと判定された場合には、端子Ｓを介して図３４の処理に移行する。
【０１７３】
また、試着商品のコピーではなかったと判定された場合、すなわち「試着画面へ」ボタン３０８が押され、共有試着ページに戻る指示であった場合には、端子Ｔを介してステップＳ７９（図１７）に戻り、ＡＳＰサーバ５は共有試着ページ・データを生成してユーザ端末Ａ（３）に対して送信する。
【０１７４】
また、ステップＳ１６３において、「試着をやめる」と判定された場合には、試着データから、選択された商品を削除する（ステップＳ１６９）。具体的には、試着管理ＤＢの試着エントリ・テーブル（図６）の対応するレコードを削除し、利用者エントリ・テーブル（図５）において対応するレコードの試着エントリ数の列５１２の値を１つ減らす。
【０１７５】
処理は端子Ｍを介してステップＳ１５３に戻り、ＡＳＰサーバ５は新たに試着リスト・ページのデータを生成し、ユーザ端末Ａ（３）に対して送信する。
【０１７６】
処理結果を反映させた試着リスト・ページの例を以下図３１乃至図３３に示す。
【０１７７】
図３１に、ステップＳ１６９における処理後の試着リスト・ページの一例を示す。図３１に示す試着リスト・ページの例には、図３０に示した試着リスト・ページの例と同様に、試着リスト（共有グループ）名称３１０、試着リスト３１２、「試着をやめる」ボタン３１４、「試着商品のコピー」ボタン３１６及び「試着画面へ」ボタン３１８が含まれている。
【０１７８】
図３０に示した試着リスト・ページとの違いは、試着リスト３１２のうち、１番上の行に「試着なし」と示されている点である。例えば、図３０に示した試着リスト・ページにおいて、試着リスト３０２の１番上の行が選択され且つ「試着をやめる」ボタン３０４が押された場合に、図３１に示すようにＡＳＰサーバ５による処理結果が試着リストに反映されるような構成となっている。
【０１７９】
図３２に、共有設定（図２６）後の試着リスト・ページの一例を示す。図３２に示す試着リスト・ページの例には、図３０に示した試着リスト・ページの例と同様に、試着リスト（共有グループ）名称３２０、試着リスト３２２、「試着をやめる」ボタン３２４、「試着商品のコピー」ボタン３２６及び「試着画面へ」ボタン３２８が含まれている。
【０１８０】
図３０に示した試着リスト・ページとの違いは、試着リスト３２２のうち、第１のユーザ（井上明美）の下半身及び足についての行が存在しない点である。例えば、図２６に示した共有設定ページにおいて、試着リスト公開範囲の設定部２６４において「上半身」と設定された場合に、図３２に示すように当該設定に基づく処理結果が試着リストに反映されるような構成となっている。
【０１８１】
図３３に、試着者（部位）選択（図１８）後の試着リスト・ページの一例を示す。図３３に示す試着リスト・ページの例には、試着リスト（共有グループ）名称３３０、試着リスト３３２、「試着をやめる」ボタン３３４、「試着商品のコピー」ボタン３３６及び「試着画面へ」ボタン３３８が含まれている。なお、本実施の形態では試着者選択ページ（図１８）からは共有試着ページ（図１９）に移行し、試着リスト・ページには直接移行しないような構成となっている。
【０１８２】
本試着リスト・ページの例は、図１８に示した試着者選択ページにおいて第３のユーザ（辻元喜代美）の上半身の行が選択され且つ「試着」ボタン１８６が押されて一旦共有試着ページに移行し、ユーザにより「試着リスト」ボタンが押された場合における試着リスト・ページの例である。
【０１８３】
ここで、図１８に示した試着者選択ページの試着リスト１８４と図３３に示す試着リストページの試着リスト３３０との違いは、第３のユーザ（辻元喜代美）の上半身の行の商品情報である。図３３の試着リスト３３０には、図１８の商品情報１８２と同じ内容が示されている。すなわち、第３のユーザ（辻元喜代美）に対して選択された商品の試着操作が行われたことがわかる。このように、試着操作の結果が試着リストに反映されるような構成となっている。
【０１８４】
次に、図３４を用いて、ステップＳ１６７（図２９）において試着商品のコピーであると判定された場合の処理（端子Ｓの後の処理）について説明する。ＡＳＰサーバ５は、試着商品コピー処理ページのデータを生成し、ユーザ端末Ａ（３）に対して送信する（ステップＳ１７１）。ユーザ端末Ａ（３）は試着商品コピー処理ページのデータを受信し、表示装置に表示する（ステップＳ１７３）。
【０１８５】
図３５に、試着商品コピー処理ページの一例を示す。図３５に示す試着商品コピー処理ページの例には、コピー元情報３５０、コピー先メンバ・リスト３５２、「コピー実行」ボタン３５４及び「キャンセル」ボタン３５６が含まれている。
【０１８６】
コピー元情報３５０には、試着者名及び試着商品の情報が示されており、この商品を他のメンバにも試着させるような構成となっている。ここでは、図３０に示した試着リスト・ページ（第１のユーザ（井上明美）の上半身の行が選択されている）において、「試着商品のコピー」ボタン３０６が押された場合の試着商品コピー処理ページの例を示している。
【０１８７】
コピー先メンバ・リスト３５２では、コピー元情報３５０に示されているメンバ以外の共有メンバ及び各メンバに対応するチェック・ボックスが示されている。なお、コピー先メンバ・リスト３５２には、共有設定ページ（図２６）における設定が反映されるため、同じ共有グループのメンバであっても、コピー先メンバ・リスト３５２に示されないユーザが存在する場合もある。
【０１８８】
例えば、コピー元の商品がＴシャツであった場合、共有設定ページ（図２６）において、他人による自己画像への試着可能範囲の設定部２６６が「下半身」又は「なし」と設定されたユーザについては、Ｔシャツ等の上半身に試着する商品を試着させることができないため、コピー先メンバ・リスト３５２に当該ユーザの名前は示されない。
【０１８９】
また例えば、コピー元の商品がＴシャツであった場合、共有設定ページ（図２６）において、試着画面公開範囲の設定部２６２及び試着リスト公開範囲の設定部２６４が「下半身」又は「なし」と設定されたユーザについては、Ｔシャツ等の上半身に試着する商品を試着させても確認することができないため、コピー先メンバ・リスト３５２に当該ユーザの名前は示されない。その他、共有設定との矛盾が発生しない形態で、コピー先メンバ・リスト３５２が示されるような構成となっている。
【０１９０】
商品を試着させたいメンバに対応するチェック・ボックスにユーザによってチェックが入れられ且つ「コピー実行」ボタン３５４が押されることより、コピー元情報３５０に示されている試着商品をチェック対象のメンバに試着させるという指示がユーザにより選択入力されたこととなる。
【０１９１】
なお、チェック対象として複数のメンバを同時に選択することが可能であり、選択されたメンバは同じ商品を試着することになる。また、試着させる体の部位については、コピー元となる商品が試着されていた部位と同じ部位に試着させるような構成となっている。また、「キャンセル」ボタン３５６が押されると、何もせずに試着リスト・ページに戻るという指示がユーザにより選択入力されたこととなる。
【０１９２】
図３４の処理フローに戻り、ユーザ端末Ａ（３）はユーザによる操作選択入力を受け付ける（ステップＳ１７５）。ユーザ端末Ａ（３）は操作選択入力データをＡＳＰサーバ５に対して送信する（ステップＳ１７７）。ＡＳＰサーバ５は操作選択入力データをユーザ端末Ａ（３）から受信し、一旦記憶装置に格納する（ステップＳ１７９）。
【０１９３】
ここで試着商品コピー処理ページ（図３５）におけるユーザの指示がコピー実行であったかどうか判定する（ステップＳ１８１）。コピー実行ではなかったと判定された場合には、キャンセルであるため、処理は端子Ｍを介してステップＳ１５３（図２９）に戻り、ＡＳＰサーバ５は試着リスト・ページのデータを生成してユーザ端末Ａ（３）に対して送信する。コピー実行であったと判定された場合には、商品データをコピーして選択されたメンバに試着登録する（ステップＳ１８３）。具体的には、試着管理ＤＢ５１の試着エントリ・テーブル（図６）の対応するレコードを更新する。
【０１９４】
なお、試着していない部位に対して試着が行われた場合には、試着エントリ・テーブル（図６）にレコードを追加し、利用者エントリ・テーブルにおいて対応するレコードの試着エントリ数の列５１２の値を１つ増やす。処理は端子Ｍを介してステップＳ１５３（図２９）に戻り、ＡＳＰサーバ５は新たに試着リスト・ページのデータを生成してユーザ端末Ａ（３）に対して送信する。なお、他のユーザのユーザ端末では、共有試着ページ・データに設定されているタイマに従って、自動的に最新の共有試着ページ・データを定期的に取得するようにＷｅｂブラウザが動作する。従って、試着商品のコピー処理が実行されれば、そのコピー後の試着態様が共有試着ページで表示されるようになる。
【０１９５】
図３６に、試着商品コピー処理後の試着リスト・ページの一例を示す。図３６に示す試着リスト・ページの例には、図３０に示した試着リスト・ページの例と同様に、試着リスト（共有グループ）名称３６０、試着リスト３６２、「試着をやめる」ボタン３６４、「試着商品のコピー」ボタン３６６及び「試着画面へ」ボタン３６８が含まれている。図３０に示した試着リスト・ページとは、試着リスト３６２のうち、第３のユーザ（辻元喜代美）の上半身についての商品の情報が異なっている。
【０１９６】
ここでは、図３５に示した試着商品コピー処理ページ（コピー先メンバ・リスト３５２の２番目（試着リストでは第３）のユーザ（辻元喜代美）にチェックが入っている）において、「コピー実行」ボタン３５４が押された場合の試着リスト・ページの例を示している。そのため、図３６に示した試着リスト・ページの例では、第１のユーザの上半身（井上明美）についての商品の情報と第３のユーザ（辻元喜代美）の上半身についての商品の情報とが同じ情報になっている。すなわち、試着商品のコピー処理がなされたことがわかる。このように、試着商品コピー処理の結果が試着リストに反映されるような構成となっている。
【０１９７】
次に、図３７を用いて、ステップＳ８９（図２０）において他商品選択であると判定された場合の処理（端子Ｌの後の処理）について説明する。ＡＳＰサーバ５は、販売サイトのホームページである販売ページのデータ要求を販売サイト・サーバ（例えば販売サイトＢサーバ（１１））に対して送信する（ステップＳ１８５）。販売サイトＢサーバ（１１）は販売ページのデータ要求をＡＳＰサーバ５から受信し、一旦記憶装置に格納する（ステップＳ１８７）。販売サイトＢサーバ（１１）は販売ページのデータを生成し、ユーザ端末Ａ（３）に対して送信する（ステップＳ１８９）。
【０１９８】
ユーザ端末Ａ（３）は販売ページのデータを受信し、表示装置に表示する（ステップＳ１９１）。ユーザ端末Ａ（３）はユーザによる商品選択操作を受け付ける（ステップＳ１９３）。商品選択の操作を受け付けたユーザ端末Ａ（３）は、選択商品ページ・データの要求を販売サイトＢサーバ（１１）に対して送信する（ステップＳ１９５）。
【０１９９】
販売サイトＢサーバ（１１）はユーザ端末Ａ（３）から選択商品ページ・データの要求を受信し（ステップＳ１９７）、例えば商品番号及び商品型式を記憶装置に格納する。販売サイトＢサーバ（１１）は商品番号及び商品型式を用いて商品ＤＢ１１１を検索し、その結果に基づき選択商品ページ・データを生成してユーザ端末Ａ（３）に対して送信する（ステップＳ１９９）。ユーザ端末Ａ（３）は販売サイトＢサーバ（１１）から選択商品ページ・データを受信し、表示装置に表示する（ステップＳ２０１）。なお、選択商品ページは図１２に示したような構成となっている。
【０２００】
ユーザ端末Ａ（３）は、選択商品ページにおいてユーザによる試着指示を受け付け（ステップＳ２０３）、試着ページ・データの要求を販売サイトＢサーバ（１１）に対して送信する（ステップＳ２０５）。販売サイトＢサーバ（１１）は、試着ページ・データの要求をユーザ端末Ａ（３）から受信し（ステップＳ２０７）、例えば商品番号及び商品型式を記憶装置に格納する。
【０２０１】
販売サイトＢサーバ（１１）は試着ページ・データ要求をＡＳＰサーバ５に対して送信する（ステップＳ２０９）。ＡＳＰサーバ５は試着ページ・データ要求を販売サイトＢサーバ（１１）から受信し、例えば販売サイト・コード、商品番号及び商品型式を記憶装置に格納する（ステップＳ２１１）。
【０２０２】
なお、このステップＳ１８５からの処理において、ユーザ端末Ａ（３）のＷｅｂブラウザのクッキー情報保存機能等により、ユーザのＡＳＰサーバ５に対するログイン状態は保たれているものとする。また、バスケットＩＤも保存されており、ステップＳ１８５の処理を行う前にユーザが使用していたページが共有試着ページであったのか個人用試着ページであったのかも判定できるような構成となっている。
【０２０３】
ＡＳＰサーバ５はユーザが使用していたページが共有試着ページであったかどうか（すなわち共有状態であったかどうか）を判定する（ステップＳ２１３）。共有状態であったと判定された場合は、端子Ｇを介してステップＳ６７（図１７）の処理に戻る。共有状態ではなかったと判定された場合は、端子Ｆを介して図５７の処理に移行する。
【０２０４】
次に、図３８を用いて、ステップＳ９５（図２０）において購入であると判定された場合の処理（端子Ｐの後の処理）について説明する。ＡＳＰサーバ５は、試着管理ＤＢ５１の試着エントリ・テーブル（図６）及び購入管理テーブル（図７）をバスケットＩＤを用いて検索し、レコードを抽出する（ステップＳ２１５）。ＡＳＰサーバ５は抽出されたレコードのデータに基づき会計用試着リスト・ページのデータを生成し、ユーザ端末Ａ（３）に対して送信する（ステップＳ２１７）。ユーザ端末Ａ（３）は会計用試着リスト・ページのデータをＡＳＰサーバ５から受信し、表示装置に表示する（ステップＳ２１９）。
【０２０５】
図３９及び図４０に、会計用試着リスト・ページの例を示す。図３９に示す第１の会計用試着リスト・ページの例には、ページ見出し３９０、会計用試着リスト３９２、商品別会計リンク３９４、「試着者別に会計」ボタン３９６及び「試着を続ける」ボタン３９８が含まれている。
【０２０６】
ページ見出し３９０には、現在の（本会計用リストを表示している）日付及び共有グループの名称が示されている。会計用試着リスト３９２には、共有試着ページにおいて試着を行っているユーザ名（試着者名）、試着がなされている商品の情報及び支払いに関する情報が示されている。
【０２０７】
なお、会計用試着リスト３９２では、図３２に示した試着リスト・ページの例と同様に、共有設定ページ（図２６）における設定が反映されている。また、リストのデータは、例えば商品ＤＢ９１（図２）、試着管理ＤＢ５１の試着エントリ・テーブル（図６）及び購入管理テーブル（図７）の対応するレコードのデータを用いて構成されている。なお、不足金額の列には、単価から支払登録済金額累計を引いた金額が示される。
【０２０８】
また、支払登録受付期限の列には、最初の支払登録があった日から例えば３日後までが期限日として設定され、現在の日付からその期限日まであと何日かという日数が示される。共同購入の際に支払登録を受け付ける期間（締め切り情報）として、例えば「あと２日」等と表示される。
【０２０９】
商品別会計リンク３９４には、会計用試着リスト３９２の各行に対応して商品毎の会計を行うためのリンクが示されている。商品別会計リンク３９４が押されると、対応する行に示されている試着商品を購入するという指示がユーザにより選択入力されたこととなる。
【０２１０】
「試着者別に会計」ボタン３９６が押されると、試着者を選択して試着者別に会計するという指示がユーザにより選択入力されたこととなる。また、「試着を続ける」ボタン３９８が押されると、共有試着ページに戻るという指示がユーザにより選択入力されたこととなる。なお、図４０に示す第２の会計用試着リスト・ページの例においても、同様の構成となっている。
【０２１１】
図３８の処理フローに戻り、ユーザ端末Ａ（３）はユーザによる操作選択入力を受け付ける（ステップＳ２２１）。ユーザ端末Ａ（３）は操作選択入力データをＡＳＰサーバ５に対して送信する（ステップＳ２２３）。ＡＳＰサーバ５は操作選択入力データをユーザ端末Ａ（３）から受信し、一旦記憶装置に格納する（ステップＳ２２５）。
【０２１２】
ここで会計用試着リスト・ページにおけるユーザの指示が「試着者別に会計」であったかどうか判定する（ステップＳ２２７）。「試着者別に会計」であったと判定された場合には、端子Ｕを介して図５０の処理に移行する。「試着者別に会計」ではなかったと判定された場合には、会計用試着リスト・ページにおけるユーザの指示が「試着を続ける」であったかどうか判定する（ステップＳ２２９）。「試着を続ける」であったと判定された場合には、端子Ｔを介してステップ７９（図１７）に戻る。「試着を続ける」でなかったと判定された場合には、端子Ｖを介して図４１の処理に移行する。
【０２１３】
次に、図４１を用いて、ステップＳ２２９において「試着を続ける」でなかったと判定された場合（会計用試着リスト・ページ（例えば図４０）において商品別会計リンク４００４が押された場合）の処理について説明する。ＡＳＰサーバ５は、選択された商品についての商品別会計ページのデータを生成し、ユーザ端末Ａ（３）に対して送信する（ステップＳ２３１）。ユーザ端末Ａ（３）は商品別会計ページのデータをＡＳＰサーバ５から受信し、表示装置に表示する（ステップＳ２３３）。
【０２１４】
図４２に、第１の商品別会計ページの一例を示す。図４２に示す第１の商品別会計ページの例には、お届先４２００、支払登録履歴４２０２、会計リスト４２０４、今回支払金額入力欄４２０６、「支払登録」ボタン４２０８、「試着を続ける」ボタン４２１０、「試着リストに戻る」ボタン４２１２、割前勘定人数入力欄４２１４、「割前勘定支払登録」ボタン４２１６及び割前勘定用メッセージ４２１８が含まれている。
【０２１５】
ここでは、図４０に示した第２の会計用試着リスト・ページの例において、会計用試着リスト４００２の６行目（辻元喜代美が試着しているＨａｍｅｓのシャツ）の行に対応する会計リンク・ボタン４００４が押された場合の、商品別会計ページの例を示している。
【０２１６】
お届先４２００には、当該商品について最初の支払登録の際に設定される、商品の届先の住所及び宛名が示される。図４２の例では未だ未設定であると示されている。支払登録履歴４２０２には、当該商品についての支払登録の履歴がリスト形式で示される。また、支払登録の回数も示される。図４２の例では未だ支払登録の履歴がない状態が示されている。
【０２１７】
会計リスト４２０４には、会計しようとしている商品の情報及び支払金額に関する情報が示されている。なお、数量の入力欄が設けられており、同じ商品を複数購入することができる。また、ＪＡＶＡスクリプト等により、数量の入力欄に入力された数値に応じて、小計、不足金額及び割前勘定用メッセージ４２１８の金額が計算されて表示されるような構成となっている。
【０２１８】
また、今回支払金額入力欄４２０６には、今回支払おうとする金額がユーザにより入力される。「支払登録」ボタン４２０８が押されると、当該商品に対して今回支払金額入力欄４２０６に入力された金額分について支払登録を行うという指示がユーザにより選択入力されたこととなる。なお、今回支払金額入力欄４２０６に入力された金額が所定の金額未満であった場合には、支払登録を受け付けないような構成であってもよい。また不足金額がマイナスとなるような入力も支払登録できないような構成でもよい。
【０２１９】
また、「試着を続ける」ボタン４２１０が押されると、共有試着ページに戻るという指示がユーザにより選択入力されたこととなり、「試着リストに戻る」ボタン４２１２が押されると、会計用試着リスト・ページに戻るという指示がユーザにより選択入力されたこととなる。
【０２２０】
割前勘定人数入力欄４２１４には、当該商品の合計金額を均等割で共同購入する場合の人数（割前勘定への参加人数）がユーザにより入力される。「割前勘定支払登録」ボタン４２１６が押された場合には、当該会計を割前勘定人数入力欄４２１４に入力された数で分担した場合の１人分の金額について、支払登録を行うという指示がユーザにより選択入力されたこととなる。割前勘定用メッセージ４２１８には、現在ユーザが閲覧している共有試着ページの共有メンバの人数及びその人数で当該会計を分担した場合の金額情報が示されている。
【０２２１】
図４１の処理フローに戻り、ユーザ端末Ａ（３）はユーザによる会計入力を受け付け（ステップＳ２３５）、ユーザ端末Ａ（３）は入力された会計データをＡＳＰサーバ５に対して送信する（ステップＳ２３７）。ＡＳＰサーバ５は入力された会計データをユーザ端末Ａ（３）から受信し、一旦記憶装置に格納する（ステップＳ２３９）。
【０２２２】
ここで商品別会計ページにおけるユーザの指示が「試着を続ける」であったかどうか判定する（ステップＳ２４１）。「試着を続ける」であったと判定された場合には、端子Ｔを介してステップ７９（図１７）に戻る。「試着を続ける」でなかったと判定された場合には、商品別会計ページにおけるユーザの指示が「試着リストに戻る」であったかどうか判定する（ステップＳ２４３）。「試着リストに戻る」であったと判定された場合には、端子Ｐを介してステップＳ２１５（図３８）に戻る。「試着リストに戻る」でなかったと判定された場合には、端子Ｗを介して図４３の処理に移行する。
【０２２３】
図４３を用いて、ステップＳ２４３において「試着リストに戻る」でなかったと判定された場合（すなわち商品別会計ページ（図４２）において「支払登録」ボタン４２０８又は「割前勘定支払登録」ボタン４２１６が押された場合）の処理について説明する。ＡＳＰサーバ５は、商品別支払登録ページのデータを生成し、ユーザ端末Ａ（３）に対して送信する（ステップＳ２４５）。ユーザ端末Ａ（３）は商品別支払登録ページのデータをＡＳＰサーバ５から受信し、表示装置に表示する（ステップＳ２４７）。
【０２２４】
図４４に、第１の商品別支払登録ページの一例を示す。図４４に示す第１の商品別支払登録ページの例には、支払内容４４００、支払方法設定入力部４４０２、届先住所設定入力部４４０４、「支払登録」ボタン４４０６、「キャンセル」ボタン４４０８及びメッセージ４４１０が含まれている。
【０２２５】
ここでは、図４２に示した第１の商品別会計ページの例において、当該商品を仮想試着しているユーザ（辻元喜代美）によって、今回支払金額入力欄４２０６に例えば”２０００”と入力され且つ「支払登録」ボタン４２０８が押された場合の、商品別支払登録ページの例を示している。すなわち、商品購入に必要な５，４００円のうち、２，０００円を自分で支払う登録をし、残りの３，４００円を他の共有ユーザに支払ってもらおうとする場合の例である。
【０２２６】
支払内容４４００には、支払登録しようとしている商品の情報及び支払金額に関する情報が示されている。商品別会計ページにおいて入力されたデータが反映され、今回お支払金額の列に”２，０００”、支払登録済金額累計の列に”２，０００”、不足金額の列に”３，４００”が示されている。
【０２２７】
また、例えば図４２に示した第１の商品別会計ページの例において、割前勘定人数入力欄４２１４に例えば”３”が入力され且つ「割前勘定支払登録」ボタン４２１６が押された場合には、今回の支払金額が自動的に計算され、今回お支払金額の列に”１，８００”、支払登録済金額累計の列に”１，８００”、不足金額の列に”３，６００”が示される。
【０２２８】
支払方法設定入力部４４０２には、カードや銀行振込み等の支払方法及びカード番号や有効期限等、支払いに必要な情報が入力される。
【０２２９】
届先住所設定入力部４４０４には、商品の配送先の情報が入力される。ラジオボタンで「住所と同じ」か「その他」かを選択させ、「その他」の場合には配送先となる宛先の郵便番号、住所、氏名及び電話番号が入力される。ここで「住所と同じ」とは、現在ログインしているユーザ（例えば辻元喜代美）がユーザ管理ＤＢ（図３）に登録してある情報を使用することを意味する。すなわち、ユーザが自己宛てに配送する指示を出す場合に選択される。例えば贈り物等であれば、「その他」が選択され、配送に必要な情報が入力される。
【０２３０】
なお、共同購入の場合など、同じ会計について支払登録が複数発生する場合には、届先住所が一旦登録されると当該会計についての商品別会計ページには届先住所設定入力部４４０４は含まれず、登録された届先の表示が含まれるような構成となっている。すなわち、追加で支払登録するユーザは、誰宛に配送されるかを把握した上で支払登録することができる。
【０２３１】
また、「支払登録」ボタン４４０６が押されると、入力した内容で支払登録するという指示がユーザにより選択入力されたこととなり、「キャンセル」ボタン４４０８が押されると、支払登録をやめて商品別会計ページに戻るという指示がユーザにより選択入力されたこととなる。なお、メッセージ４４１０には、不足金額の有無によって注文可能かどうかを表すメッセージが示されている。
【０２３２】
図４３の処理フローに戻り、ユーザ端末Ａ（３）はユーザによる支払条件等の入力を受け付け（ステップＳ２４９）、ユーザ端末Ａ（３）は支払条件等の入力データをＡＳＰサーバ５に対して送信する（ステップＳ２５１）。ＡＳＰサーバ５は支払条件等の入力データをユーザ端末Ａ（３）から受信し、一旦記憶装置に格納する（ステップＳ２５３）。
【０２３３】
ここで商品別支払登録ページにおけるユーザの指示が「キャンセル」であったかどうか判定する（ステップＳ２５５）。「キャンセル」であったと判定された場合には、端子Ｖを介してステップＳ２３１（図４１）に戻る。「キャンセル」でなかったと判定された場合、すなわち、商品別支払登録ページにおいて入力された内容で支払登録処理を行うという指示がユーザにより選択入力された場合には、ＡＳＰサーバ５は商品別支払登録データを試着管理ＤＢ５１に格納する。具体的には、購入管理テーブル（図７）にレコードを追加又は対応するレコードを更新する。またその際に、金額ステータス７２６の列の値が”注文可”になった会計データについては、注文テーブル（図８）にレコードを追加する場合もある。
【０２３４】
ＡＳＰサーバ５は、商品別支払登録が完了したことを示す確認ページのデータを生成し、ユーザ端末Ａ（３）に対して送信する（ステップＳ２５９）。ユーザ端末Ａ（３）は、商品別支払登録が完了したことを示す確認ページのデータをＡＳＰサーバ５から受信し、表示装置に表示する（ステップＳ２６１）。
【０２３５】
図４５に、第１の商品別支払登録確認ページの一例を示す。図４５に示す第１の商品別支払登録確認ページの例には、確認メッセージ４５００、商品情報４５０２、届先４５０４、支払情報４５０６及び支払登録受け付け期間情報４５０８が含まれている。
【０２３６】
ここでは、図４４に示した商品別支払登録ページの例において、さらに必要な情報（カード番号等）が入力され且つ「支払登録」ボタン４４０６が押された場合の、商品別支払登録確認ページの例を示している。確認メッセージ４５００には、支払登録が完了したこと及び支払金額に関するメッセージが示されている。商品情報４５０２には、支払登録の対象商品の情報が示されている。
【０２３７】
また、届先４５０４には、第１の商品別支払登録ページ（図４４）の届先住所設定入力部４４０４において設定登録された届先の情報が示されている。本例では、支払登録を行ったユーザ（辻元喜代美）の住所に関する情報をユーザ管理ＤＢ５３から抽出した結果が示されている。支払情報４５０６には、第１の商品別支払登録ページ（図４４）で支払登録を行ったユーザ名、支払金額、支払方法、合計金額及び不足金額が示される。ここで、支払登録を行ったユーザが複数存在する場合には、履歴情報として支払登録を行ったユーザ名、支払金額及び支払方法がリスト表示され、対応する合計金額及び不足金額が示される。なお、不足金額がない（合計支払金額が購入価格に達した）場合には、不足金額は表示されない。
【０２３８】
支払登録受付期間情報４５０８には、その他のユーザの支払登録を受け付ける期間が示されている。なお、不足金額がない（合計支払金額が購入価格に達した）場合には、支払登録の受け付けを終了して注文処理に移行するため、支払登録受付期間情報４５０８は本ページには含まれないような構成となっている。
【０２３９】
以上の例に従って商品別の支払登録が行われた後の会計用試着リストの一例を図４６に示す。図４６に示す第３の会計用試着リスト・ページの例には、ページ見出し４６００、会計用試着リスト４６０２、商品別会計リンク４６０４、「試着者別に会計」ボタン４６０６及び「試着を続ける」ボタン４６０８が含まれている。図４０に示した第２の会計用試着リスト・ページとは、会計用試着リスト４６０２の６行目（辻元喜代美が試着しているＨａｍｅｓのシャツ）の情報のうち、支払登録済金額累計、不足金額及び支払登録受付期限が異なっている。すなわち、上で述べた商品別支払登録処理を行った結果がこのように反映される。
【０２４０】
ここで、例えば他のユーザ（例えば扇智影）によって、会計用試着リスト４６０２の６行目（辻元喜代美が試着しているＨａｍｅｓのシャツ）に対してさらに商品別支払登録が行われた場合のページの例を図４７乃至図４９に示す。なお、処理フローは上で述べたステップＳ２３１からの処理と同様である。
【０２４１】
図４７に、第２の商品別会計ページの一例を示す。図４７に示す第２の商品別会計ページの例には、お届先４７００、支払登録履歴４７０２、会計リスト４７０４、「試着を続ける」ボタン４７０６、「試着リストに戻る」ボタン４７０８、今回支払金額入力欄４７１０及び「支払登録」ボタン４７１２が含まれている。
【０２４２】
お届先４７００には、当該商品について最初の支払登録の際に設定された、商品の届先の住所及び宛名が示されている。支払登録履歴４７０２には、当該商品についての支払登録の履歴がリスト形式で示されている。また、支払登録の回数も示されている。図４７の例では１件の支払登録の履歴が示されている。
【０２４３】
会計リスト４７０４には、会計しようとしている商品の情報及び支払金額に関する情報が示されている。なお、図４２に示した第１の商品別会計ページの例とは違い、数量の入力欄が設けられておらず、数量の変更はできないような構成になっている。また、今回支払金額入力欄４７１０及び各ボタンについては、図４２に示した第１の商品別会計ページの例と同様の処理が行われる。
【０２４４】
なお、最初に支払登録を行ったユーザが割前勘定支払登録を行った場合には、今回支払金額入力欄４７１０及び「支払登録」ボタン４７１２に代えて、「割前勘定支払登録」ボタンを本ページに含めるような構成であってもよい。
【０２４５】
図４８に、第２の商品別支払登録ページの一例を示す。図４８に示す第２の商品別支払登録ページの例には、届先４８００、支払内容４８０２、支払方法設定入力部４８０４、「注文」ボタン４８０６、「キャンセル」ボタン４８０８及びメッセージ４８１０が含まれている。
【０２４６】
ここでは、図４７に示した第２の商品別会計ページの例において、ユーザ（例えば扇智影）によって、今回支払金額入力欄４７１０に例えば”３４００”と入力され且つ「支払登録」ボタン４７１２が押された場合の、商品別支払登録ページの例を示している。すなわち、商品購入に必要な５，４００円のうち、２，０００円が既に支払登録済みであったので、残りの３，４００円を支払おうとする場合の例である。
【０２４７】
届先４８００には、最初の支払登録の際に設定された、商品の届先の情報が示されている。支払内容４８０２には、支払登録しようとしている商品の情報及び支払金額に関する情報が示されている。商品別会計ページにおいて受け付けたデータが反映され、今回お支払金額の列に”３，４００”、支払登録済金額累計の列に”５，４００”、不足金額の列に”０”が示されている。支払方法設定入力部４８０４では、カードや銀行振込み等の支払方法及びカード番号や有効期限等、支払いに必要な情報の入力が行われる。
【０２４８】
また、本ページの例では、支払登録済金額累計が購入に必要な金額に達した場合、図４４に示した第１の商品別支払登録ページにおける「支払登録」ボタン４４０６に代えて、「注文」ボタン４８０６が含まれるような構成となっている。「注文」ボタン４８０６が押されると、入力した内容で支払登録するという指示がユーザにより選択入力されたこととなり、「キャンセル」ボタン４８０８が押されると、支払登録をやめて商品別会計ページに戻るという指示がユーザにより選択入力されたこととなる。なお、メッセージ４８１０には、不足金額の有無によって注文可能かどうかを表すメッセージが示されている。
【０２４９】
図４９に、第２の商品別支払登録確認ページの一例を示す。図４９に示す第２の商品別支払登録確認ページの例には、確認メッセージ４９００、商品情報４９０２、届先４９０４及び支払情報４９０６が含まれている。
【０２５０】
ここでは、図４８に示した商品別支払登録ページの例において、支払方法が設定され且つ「注文」ボタン４８０６が押された場合の、商品別支払登録確認ページの例を示している。確認メッセージ４９００には、注文が完了したことを表すメッセージが示されている。商品情報４９０２には、支払登録（注文）の対象商品の情報が示されている。
【０２５１】
また、届先４５０４には、第１の商品別支払登録ページ（図４４）の届先住所設定入力部４４０４において設定登録された届先の情報が示されている。支払情報４９０６には、当該商品の購入についての支払登録の履歴情報として、支払登録を行ったユーザ名、支払金額及び支払方法がリスト表示され、対応する合計金額及び不足金額が示される。
【０２５２】
なお、本ページの例では不足金額がない場合（すなわち合計支払金額が購入価格に達した場合）であるので、不足金額は表示されていない。また、本ページの例では支払登録の受け付けを終了して注文処理に移行するため、図４５に示した商品別支払登録確認ページの例とは異なり、支払登録受付期間情報は含まれていない。
【０２５３】
なお、支払方法を銀行振込みや現金書留等に設定したユーザについては、事前に全ユーザに対して振込先や送金先を通知しておいてもよいし、注文後にメール等で通知するような構成であってもよい。
【０２５４】
次に、図５０を用いて、ステップＳ２２７において試着者別に会計であったと判定された場合の処理（端子Ｕの後の処理）について説明する。ＡＳＰサーバ５は、会計試着者選択ページのデータを生成し、ユーザ端末Ａ（３）に対して送信する（ステップＳ２６３）。ユーザ端末Ａ（３）は会計試着者選択ページのデータをＡＳＰサーバ５から受信し、表示装置に表示する（ステップＳ２６５）。
【０２５５】
図５１に、会計試着者選択ページの一例を示す。図５１に示す会計試着者選択ページの例には、会計試着者選択リスト５１００、「試着を続ける」ボタン５１０２、「試着リストに戻る」ボタン５１０４及び「会計」ボタン５１０６が含まれている。
【０２５６】
ここでは、図３９に示した第１の会計用試着リスト・ページの例において、「試着者別に会計」ボタン３９６が押された場合の、会計試着者選択ページの例を示している。会計試着者選択リスト５１００には、共有試着メンバの氏名及び当該メンバが試着している商品の情報が一覧で示されている。また、ラジオボタンによりメンバが選択されるようになっている。なお、共有グループのメンバであっても、１つの商品も試着がなされていない場合は、会計試着者選択リスト５１００に表示されないような構成となっている。
【０２５７】
また、「試着を続ける」ボタン５１０２が押されると、共有試着ページに戻るという指示がユーザにより選択入力されたこととなり、「試着リストに戻る」ボタン５１０４が押されると、会計用試着リスト・ページに戻るという指示がユーザにより選択入力されたこととなる。
【０２５８】
図５０の処理フローに戻り、ユーザ端末Ａ（３）はユーザによる会計試着者等の選択入力を受け付け（ステップＳ２６７）、ユーザ端末Ａ（３）は選択された試着者等のデータをＡＳＰサーバ５に対して送信する（ステップＳ２６９）。ＡＳＰサーバ５は選択された試着者等のデータをユーザ端末Ａ（３）から受信し、一旦記憶装置に格納する（ステップＳ２７１）。
【０２５９】
ここで会計試着者選択ページにおけるユーザの指示が「試着を続ける」であったかどうか判定する（ステップＳ２７３）。「試着を続ける」であったと判定された場合には、端子Ｔを介してステップ７９（図１７）に戻る。「試着を続ける」でなかったと判定された場合には、会計試着者選択ページにおけるユーザの指示が「試着リストに戻る」であったかどうか判定する（ステップＳ２７５）。「試着リストに戻る」であったと判定された場合には、端子Ｐを介してステップＳ２１５（図３８）に戻る。「試着リストに戻る」でなかったと判定された場合には、端子Ｘを介して図５２の処理に移行する。
【０２６０】
図５２を用いて、ステップＳ２７５において「試着リストに戻る」でなかったと判定された場合の処理について説明する。ＡＳＰサーバ５は、選択されたメンバが試着している商品についての試着者別会計ページのデータを生成し、ユーザ端末Ａ（３）に対して送信する（ステップＳ２７７）。ユーザ端末Ａ（３）は試着者別会計ページのデータをＡＳＰサーバ５から受信し、表示装置に表示する（ステップＳ２７９）。
【０２６１】
図５３に、試着者別会計ページの一例を示す。図５３に示す試着者別会計ページの例には、お届先５３００、支払登録履歴５３０２、会計リスト５３０４、合計金額５３０６、支払登録済金額累計５３０８、不足金額５３１０、今回支払金額入力欄５３１２、「支払登録」ボタン５３１４、「試着を続ける」ボタン５３１６、「試着リストに戻る」ボタン５３１８、割前勘定人数入力欄５３２０、「割前勘定支払登録」５３２２ボタン及び割前勘定用５３２４メッセージが含まれている。
【０２６２】
ここでは、図５１に示した会計試着者選択ページの例において、会計試着者選択リスト５１００のうち、第１の試着者ユーザ（井上明美）の行に対応するラジオボタンが選択され且つ「会計ボタン」５１０６が押された場合の、試着者別会計ページの例を示している。
【０２６３】
お届先５３００には、当該会計について最初の支払登録の際に設定される、商品の届先の住所及び宛名が示される。図５３の例では未だ未設定であると示されている。支払登録履歴５３０２には、当該会計についての支払登録の履歴がリスト形式で示される。また、支払登録の回数も示される。図５３の例では未だ支払登録の履歴がない状態が示されている。
【０２６４】
会計リスト５３０４には、会計しようとしている商品の情報及び支払金額に関する情報がリスト形式で示されている。なお、数量の入力欄が設けられており、同じ商品を複数購入することや、”０”を入力することにより、特定の商品を購入しないという意思表示を行うことができる。また、会計の対象となるユーザが複数の商品を試着している場合（例えばＴシャツ及びスカート等）、図４２及び図４７に示した商品別会計ページとは、この会計リスト５３０４に示される商品の数（行数）が異なる。そのため、複数行のリストに対応する構成として、合計５３０６、支払登録済金額累計５３０８及び不足金額５３１０が、会計リスト５３０４の下段に示されている。
【０２６５】
なお、図４２に示した商品別会計ページと同様に、ＪＡＶＡスクリプト等により、数量の入力欄に入力された数値に応じて小計、合計５３０６、不足金額５３１０及び割前勘定用メッセージ５３２４の金額が計算されて表示されるような構成となっている。
【０２６６】
また、今回支払金額入力欄５３１２には、今回支払おうとする金額がユーザにより入力される。「支払登録」ボタン５３１４が押されると、当該商品に対して今回支払金額入力欄５３１２に入力された金額分について支払登録を行うという指示がユーザにより選択入力されたこととなる。なお、今回支払金額入力欄５３１２に入力された金額が所定の金額未満であった場合には、支払登録を受け付けないような構成であってもよい。また不足金額がマイナスとなるような入力も支払登録できないような構成でもよい。
【０２６７】
また、「試着を続ける」ボタン５３１６が押されると、共有試着ページに戻るという指示がユーザにより選択入力されたこととなり、「試着リストに戻る」ボタン５３１８が押されると、会計用試着リスト・ページに戻るという指示がユーザにより選択入力されたこととなる。
【０２６８】
割前勘定人数入力欄５３２０には、当該商品の合計金額を均等割で共同購入する場合の人数（割前勘定への参加人数）がユーザにより入力される。「割前勘定支払登録」ボタン５３２２が押された場合には、当該会計を割前勘定人数入力欄５３２０に入力された数で分担した場合の１人分の金額について、支払登録を行うという指示がユーザにより選択入力されたこととなる。割前勘定用メッセージ５３２４には、現在ユーザが閲覧している共有試着ページの共有メンバの人数及びその人数で当該会計を分担した場合の金額情報が示されている。
【０２６９】
図５２の処理フローに戻り、ユーザ端末Ａ（３）はユーザによる数量等の会計入力を受け付け（ステップＳ２８１）、ユーザ端末Ａ（３）は入力された会計データをＡＳＰサーバ５に対して送信する（ステップＳ２８３）。ＡＳＰサーバ５は入力された会計データをユーザ端末Ａ（３）から受信し、一旦記憶装置に格納する（ステップＳ２８５）。
【０２７０】
ここで試着者別会計ページにおけるユーザの指示が「試着を続ける」であったかどうか判定する（ステップＳ２８７）。「試着を続ける」であったと判定された場合には、端子Ｔを介してステップ７９（図１７）に戻る。「試着を続ける」でなかったと判定された場合には、試着者別会計ページにおけるユーザの指示が「試着リストに戻る」であったかどうか判定する（ステップＳ２８９）。「試着リストに戻る」であったと判定された場合には、端子Ｐを介してステップＳ２１５（図３８）に戻る。「試着リストに戻る」でなかったと判定された場合には、端子Ｙを介して図５４の処理に移行する。
【０２７１】
図５４を用いて、ステップＳ２８９（図５２）において「試着リストに戻る」でなかったと判定された場合（試着者別会計ページ（図５３）において「支払登録」ボタン５３１４又は「割前勘定支払登録」ボタン５３２２が押された場合）の処理について説明する。ＡＳＰサーバ５は、試着者別支払登録ページのデータを生成し、ユーザ端末Ａ（３）に対して送信する（ステップＳ２９１）。ユーザ端末Ａ（３）は試着者別支払登録ページのデータをＡＳＰサーバ５から受信し、表示装置に表示する（ステップＳ２９３）。
【０２７２】
図５５に、試着者別支払登録ページの一例を示す。図５５に示す試着者別支払登録ページの例には、支払内容５５００、合計５５０２、今回支払金額５５０４、支払登録済金額累計５５０６、不足金額５５０８、支払方法設定入力部５５１０、届先住所設定入力部５５１２、「注文」ボタン５５１４、「キャンセル」ボタン５５１６及びメッセージ５５１８が含まれている。
【０２７３】
ここでは、図５３に示した試着者別会計ページの例において、ユーザによって、今回支払金額入力欄５３１２に例えば”１７９００”と入力され且つ「支払登録」ボタン５３１４が押された場合の、試着者別支払登録ページの例を示している。すなわち、商品購入に必要な１７，９００円を全額支払う登録をする場合の例である。
【０２７４】
支払内容５５００には、支払登録しようとしている商品の情報及び支払金額に関する情報が示されている。なお、図５３に示した試着者別会計ページと同様に、合計５５０２、今回支払金額５５０４、支払登録済金額累計５５０６及び不足金額５５０８が、支払内容５５００の下段に示されている。また、試着者別会計ページにおいて入力されたデータが反映され、今回支払金額５５０４に”１７，９００”、支払登録済金額累計の列に”１７，９００”、不足金額の列に”０”が示されている。
【０２７５】
また、試着者別会計ページにおいて「割前勘定支払登録」ボタン５３２２が押された場合や、支払方法設定入力部５５１０及び届先住所設定入力部５５１２における処理については、図４４に示した商品別支払登録ページと同様の構成となっている。
【０２７６】
「注文」ボタン５５１４が押されると、入力した内容で支払登録するという指示がユーザにより選択入力されたこととなり、「キャンセル」ボタン４８０８が押されると、支払登録をやめて試着者別会計ページに戻るという指示がユーザにより選択入力されたこととなる。なお、メッセージ５５１８には、不足金額の有無によって注文可能かどうかを表すメッセージが示されている。不足金額がある場合には、上で述べた商品別の支払登録と同様に、本ページには「注文」ボタン５５１４の代わりに「支払登録」ボタンが含まれ、メッセージ５５１８の内容も変わる。
【０２７７】
また、同じ（試着者別の）会計について追加で支払登録が行われる際には、図４８に示した商品別支払登録ページの例と同様に、届先住所設定入力部５５１２の代わりに登録済の届先が示されるようなページ構成となる。
【０２７８】
図５４の処理フローに戻り、ユーザ端末Ａ（３）はユーザによる支払条件等の入力を受け付け（ステップＳ２９５）、ユーザ端末Ａ（３）は支払条件等の入力データをＡＳＰサーバ５に対して送信する（ステップＳ２９７）。ＡＳＰサーバ５は支払条件等の入力データをユーザ端末Ａ（３）から受信し、一旦記憶装置に格納する（ステップＳ２９９）。
【０２７９】
ここで試着者別支払登録ページにおけるユーザの指示が「キャンセル」であったかどうか判定する（ステップＳ３０１）。「キャンセル」であったと判定された場合には、端子Ｘを介してステップＳ２７７（図５２）に戻る。「キャンセル」でなかったと判定された場合、すなわち、試着者別支払登録ページにおいて入力された内容で支払登録処理を行うという指示がユーザにより選択入力された場合には、ＡＳＰサーバ５は試着者別支払登録データを試着管理ＤＢ５１に格納する（ステップＳ３０３）。具体的には、購入管理テーブル（図７）にレコードを追加又は対応するレコードを更新する。またその際に、金額ステータス７２６の列の値が”注文可”になった会計データについては、注文テーブル（図８）にレコードを追加する場合もある。
【０２８０】
ＡＳＰサーバ５は、試着者別支払登録が完了したことを示す確認ページのデータを生成し、ユーザ端末Ａ（３）に対して送信する（ステップＳ３０５）。ユーザ端末Ａ（３）は、試着者別支払登録が完了したことを示す確認ページのデータをＡＳＰサーバ５から受信し、表示装置に表示する（ステップＳ３０７）。
【０２８１】
図５６に、試着者別支払登録確認ページの一例を示す。図５６に示す試着者別支払登録確認ページの例には、確認メッセージ５６００、商品情報５６０２、届先５６０４及び支払情報５６０６が含まれている。
【０２８２】
ここでは、図５５に示した試着者別支払登録ページの例において、さらに必要な情報（カード番号等）が入力され且つ「注文」ボタン５５１４が押された場合の、試着者別支払登録確認ページの例を示している。確認メッセージ５６００には、注文が完了したことを表すメッセージが示されている。商品情報５６０２には、支払登録（注文）の対象商品の情報が示されている。なお、商品別の会計と異なり、１又は複数行からなるリスト形式で表示され、リスト下部に合計金額が示されている。
【０２８３】
また、届先５６０４には、試着者別支払登録ページ（図５５）の届先住所設定入力部５５１２において設定登録された届先の情報が示されている。本例では、支払登録を行ったユーザ（井上明美）の住所に関する情報をユーザ管理ＤＢ５３から抽出した結果が示されている。支払情報５６０６には、試着者別支払登録ページ（図５５）で支払登録を行ったユーザ名、支払金額、支払方法、合計金額及び不足金額が示される。ここで、支払登録を行ったユーザが複数存在する場合には、履歴情報として支払登録を行ったユーザ名、支払金額及び支払方法がリスト表示され、対応する合計金額及び不足金額が示される。
【０２８４】
なお、商品別の会計と同様に、不足金額がない（合計支払金額が購入価格に達した）場合には、不足金額は表示されず、不足金額がある場合には、支払登録受け付け期間情報としてその他のユーザの支払登録を受け付ける期間が示されるような構成となっている。
【０２８５】
以上のようにして共有試着ページにおける仮想試着及び会計に関する処理が行われる。
【０２８６】
次に、図５７を用いて、ステップＳ３５（図１３）において既存の試着データがなかったと判定された場合の処理（端子Ｄの後の処理）及び、ステップＳ４７（図１５）において共有ではないと判定された場合又はステップＳ１６５（図２９）において共有状態ではないと判定された場合（後に説明する個人用試着リスト・ページにおいて「試着画面へ」ボタンが押された場合）又はステップＳ２１３（図３７）において共有状態ではないと判定された場合（端子Ｆの後の処理）について説明する。
【０２８７】
端子Ｄの後に、ＡＳＰサーバ５は新規個人データのＤＢ格納処理を行う（ステップＳ３０９）。具体的には、試着管理ＤＢ５１のバスケット管理テーブル（図４）に新規レコードを追加する。なお、個人／グループの列４１２の値は”個人”と登録され、画面ＵＲＬ（ディレクトリ）の列４１０の値については、図示しないページを用いて名称の列４０２の値とともにユーザに入力させるような構成であってもよいし、自動生成されるような構成であってもよい。
【０２８８】
ＡＳＰサーバ５は試着部位選択ページ・データを生成し、ユーザ端末Ａ（３）に対して送信する（ステップＳ３１１）。ユーザ端末Ａ（３）は試着部位選択ページ・データをＡＳＰサーバ５から受信し、表示装置に表示する（ステップＳ３１３）。
【０２８９】
図５８に試着部位選択ページの一例を示す。図５８に示す試着部位選択ページの例には、試着リスト（個人）名称５８００、商品情報５８０２、試着リスト５８０４、「試着」ボタン５８０６及び「キャンセル」ボタン５８０８が含まれている。試着リスト（個人）名称５８００には、ユーザの氏名が示され、誰に試着するのか特定できるようになっている。商品情報５８０２には、メーカ又は販売店名や商品種別等、試着しようとしている商品の情報が含まれている。
【０２９０】
試着リスト５８０４には、部位、店舗、商品及びオプションが含まれ、ユーザのどの部位（上半身等）にどこ（店舗）の何（赤の７号サイズのスカート等）が試着されているのかが分かるような一覧情報が示されている。また、各行をラジオボタンにより選択できるようになっている。行が選択され且つ「試着」ボタン５８０６が押された場合には、試着指示がユーザにより選択入力されたこととなる。「キャンセル」ボタン５８０８が押された場合には、本ページの前にユーザが閲覧していたページに戻ってもよいし、試着させずに次に進むような構成であってもよい。
【０２９１】
また、Ｔシャツを下半身には試着できないようにする設定がなされている場合もある。なお、図５８に示した例では、下半身及び足に試着がなされているが、ステップＳ３０９を経由した新規の試着処理の場合には、試着リスト５８０４の全ての行に”試着なし”が示される。
【０２９２】
図５７の処理フローに戻り、ユーザ端末Ａ（３）はユーザによる試着部位選択入力を受け付け（ステップＳ３１５）、ユーザ端末Ａ（３）は試着部位選択データをＡＳＰサーバ５に対して送信する（ステップＳ３１７）。ＡＳＰサーバ５は、試着部位選択データをユーザ端末Ａ（３）から受信し、一旦記憶装置に格納する（ステップＳ３１９）。さらにＡＳＰサーバ５は、受信したデータを用いて試着管理ＤＢ５１の試着エントリ・テーブル（図６）にレコードを追加又は試着エントリ・テーブル（図６）を更新する（ステップＳ３２１）。
【０２９３】
この時、購入管理テーブル（図７）との整合性をとる必要がある（例えば試着をやめた商品は購入しないようにする）場合は、試着エントリ・テーブルで更新（上書消去）されたレコードに対応する（すなわちバスケットＩＤの値及びアイテム番号（ＮＯ．）の値が同じ）購入管理テーブルのレコードが存在すれば削除する。なお、利用者エントリ・テーブルについては、個人用のレコードは存在しないような構成となっているが、共有グループ用と同様に生成するような構成であってもよい。
【０２９４】
ＤＢ更新処理の終了後、ＡＳＰサーバ５は個人用試着ページ・データを生成し、ユーザ端末Ａ（３）に対して送信する（ステップＳ３２３）。ユーザ端末Ａ（３）は個人用試着ページ・データをＡＳＰサーバ５から受信し、表示装置に表示する（ステップＳ３２５）。
【０２９５】
図５９に個人用試着ページの一例を示す。図５９に示す個人用試着ページの例には、ＵＲＬ５９００、ページ見出し５９０２、「他商品選択」ボタン５９０４、「試着リスト」ボタン５９０６、「画面共有」ボタン５９０８、「購入」ボタン５９１０、「終了」ボタン５９１２、仮想試着画像５９１４及び購入候補リスト５９１６が含まれている。ＵＲＬ５９００には、本ページのアドレスが示されている。試着ページを生成させたユーザは、このアドレスを用いて試着ページを閲覧し、その後に試着商品の選択（着脱）を行うことができるようになる。ページ見出し５９０２にはユーザの氏名が示されており、ユーザは自己の試着ページを閲覧していることを確認できるようになっている。
【０２９６】
「他商品選択」ボタン５９０４が押された場合には、試着していない商品を選択するために、販売サイト（例えば販売サイトＡサーバ（９））が管理するホームページへ移行する指示がユーザにより選択入力されたこととなる。なお、提携販売サイトの一覧が表示されるようにしてもよいし、ユーザにより予め登録された一の販売サイトに直接遷移してもよい。
【０２９７】
「試着リスト」ボタン５９０６が押された場合には、商品の着脱操作等を行うために、試着リスト・ページへの移行指示がユーザにより選択入力されたこととなる。「画面共有」ボタン５９０８が押された場合には、共有試着場面に移行するために、一旦共有グループ一覧ページ（図１６）へ移行する指示がユーザにより選択入力されたこととなる。なお、自己が管理する共有グループを持たないユーザの場合には、共有グループ新規作成ページ（図２２）へ移行するような構成であってもよい。
【０２９８】
「購入」ボタン５９１０が押された場合には、試着している商品の会計を行うページへ移行する指示がユーザにより選択入力されたこととなる。また、「終了」ボタン５９１２が押された場合には、試着又は閲覧を終了する指示がユーザにより選択入力されたこととなる。
【０２９９】
仮想試着画像５９１４には、ユーザの画像及び試着している商品の画像が含まれている。購入候補リスト５９１６には、ユーザが試着している商品の情報が含まれており、仮想試着画像５９１４とあわせて、何を試着していて見た目はどのようになるのかが分かるような構成となっている。なお、本実施の形態では、ユーザは商品の着脱操作を試着リスト・ページにおいて行うような構成となっているが、仮想試着画像５９１４の商品画像に対するマウスのドラッグ・アンド・ドロップによって着脱操作が行われるような構成であってもよい。この場合、各商品画像及びユーザ画像のレイヤ及び位置情報を例えばＪＡＶＡ等により管理する必要がある。
【０３００】
図５７の処理フローに戻り、ユーザ端末Ａ（３）は個人用試着ページにおけるユーザによる操作（選択）入力を受け付け（ステップＳ３２７）、ユーザ端末Ａ（３）は受け付けた選択操作データをＡＳＰサーバ５に対して送信する（ステップＳ３２９）。ＡＳＰサーバ５は、個人用試着ページにおけるユーザの選択操作データをユーザ端末Ａ（３）から受信し、一旦記憶装置に格納する（ステップＳ３３１）。処理は端子Ｚを介して図６０の処理に移行する。
【０３０１】
また、端子Ｆの後に、ＡＳＰサーバ５は、ユーザ端末Ａ（３）からの要求が商品の試着であるかどうか判定する（ステップＳ３３３）。すなわち、選択した商品を試着させてから試着ページを表示させる（ステップＳ４７（図１５）経由又はステップＳ２１３（図３７）経由）のか、試着ページの表示（ステップＳ１６５（図２９）経由）のみでよいのかを判定する。商品試着であると判定された場合には、ステップＳ３１１の処理に移行する。商品試着ではないと判定された場合には、ステップＳ３２３の処理に移行する。
【０３０２】
端子Ｚの後に、ＡＳＰサーバ５は、ステップＳ３３１で受信した選択操作データに基づき、ユーザの指示について以下の判定を行う。まず、他商品選択かどうか、すなわち個人用試着ページ（図５９）において、販売サイト（例えば販売サイトＡサーバ（９））が管理する商品選択ホームページへ移行するために「他商品選択」ボタン５９０４が押されたかどうか判定する（ステップＳ３３５）。他商品選択であると判定された場合、処理は端子Ｌを介して図３７の処理（共有試着における処理と共通）に移行する。
【０３０３】
他商品選択ではないと判定された場合、試着リストの表示指示かどうか、すなわち個人用試着ページ（図５９）において「試着リスト」ボタン５９０６が押されたかどうか判定する（ステップＳ３３７）。試着リストの表示指示であると判定された場合、処理は端子Ｍを介して図２９の処理（共有試着における処理と共通）に移行する。
【０３０４】
図６１に、個人試着リスト・ページの一例を示す。図６１に示す個人試着リスト・ページの例には、試着リスト名称６１００、試着リスト６１０２、「試着をやめる」ボタン６１０４及び「試着画面へ」ボタン６１０６が含まれている。試着リスト名称６１００には、ユーザが現在閲覧している個人用試着ページの名称（ユーザの氏名）が示されている。試着リスト６１０２には、部位、店舗、商品及びオプションが含まれ、当該ユーザがどの部位（上半身等）にどこ（店舗）の何（緑の９号サイズのシャツ等）が試着されているのかが分かるような一覧情報が示されている。また、ラジオボタンにより各行を選択できるようになっている。行が選択され且つ「試着をやめる」ボタン６１０４が押された場合には、選択された商品の試着をやめるという指示がユーザにより選択入力されたこととなる。また、「試着画面へ」ボタン６１０６が押された場合には、個人用試着ページに戻る指示がユーザにより選択入力されたこととなる。
【０３０５】
図６２に、上で述べた「試着をやめる」ボタン６１０４が押された場合における処理後の個人試着リスト・ページの一例を示す。図６２に示す個人試着リスト・ページの例には、図６１に示した個人試着リスト・ページの例と同様に、試着リスト名称６２００、試着リスト６２０２、「試着をやめる」ボタン６２０４及び「試着画面へ」ボタン６２０６が含まれている。図６１に示した個人試着リスト・ページとの違いは、試着リスト６２０２のうち、１番上の行に「試着なし」と示されている点である。例えば、図６１に示した個人試着リスト・ページにおいて、試着リスト６１０２の１番上の行が選択され且つ「試着をやめる」ボタン６１０４が押された場合に、図６２に示すようにＡＳＰサーバ５による処理結果が試着リストに反映されるような構成となっている。
【０３０６】
図６０のステップＳ３３７において、試着リストの表示指示ではないと判定された場合、画面共有かどうか、すなわち個人用試着ページ（図５９）において共有試着ページへ移行するために「画面共有」ボタン５９０８が押されたかどうか判定する（ステップＳ３３９）。画面共有であると判定された場合、処理は端子Ｊを介してステップＳ４９（図１５）の処理（共有試着における処理と共通）に移行する。
【０３０７】
画面共有ではないと判定された場合、商品購入かどうか、すなわち個人用試着ページ（図５９）において会計処理を行うために「購入」ボタン５９１０が押されたかどうか判定する（ステップＳ３４１）。商品購入であると判定された場合、処理は端子Ｐを介して図３８の処理（共有試着における処理と共通）に移行する。
【０３０８】
商品購入ではないと判定された場合はすなわち終了が指示された場合（「終了」ボタン５９１２が押された場合）であり、ＡＳＰサーバ５は試着状況の保存処理として試着管理ＤＢ５１の更新を行う（ステップＳ３４３）。なお、保存しないで終了したいこともある場合には、試着管理ＤＢ５１の更新を行う前に、ユーザに保存処理の実行可否の確認をとるような構成であってもよい。
【０３０９】
ＡＳＰサーバ５は図示しない終了確認ページ・データを生成し、ユーザ端末Ａ（３）に対して送信する（ステップＳ３４５）。ユーザ端末Ａ（３）は終了確認ページ・データをＡＳＰサーバ５から受信し、表示装置に表示する（ステップＳ３４７）。なお、終了確認ページに「キャンセル」ボタンを設置し、「キャンセル」ボタンが押された場合には個人試着ページ（図５９）に戻るような構成であってもよい。終了確認ページ・データの送信後、ＡＳＰサーバ５は当該ユーザのログオフ処理を行う（ステップＳ３４９）。
【０３１０】
このようにすると、複数人による仮想試着場面の共有が実現でき、複数の人が商品を試着した様子をお互いに見せあったり、ペア・ルック等、複数人によるコーディネイトを検討したり、他の人が試着した商品が気に入った場合、その商品を購入したりすること等が可能となる。すなわち、オンライン・ショッピングにおいても複数人による現実のショッピングに近い状況を実現することができる。また、共有設定を行うことにより、他の人に見せたくない部分を隠す等、様々な形態でのオンライン・ショッピングが可能となる。また、試着した商品の購入の際には、商品毎や試着者毎の会計、割前勘定などの多彩な代金支払態様がオンライン・ショッピングにおいても可能となる。
【０３１１】
以上本発明の一実施の形態を説明したが、本発明はこれに限定されるものではない。例えば、図１に示したシステム構成は一例であって他の構成であっても上記の実施パターンを実現することができればよい。例えばＤＢ構成についても一例であって同様のデータを格納するためであれば、別の構成を採用するようにしてもよいし、必要に応じて項目を追加又は削除するようにしてもよい。例えば体の部位や共有設定項目も一例であり、必要に応じて追加や変更等がなされる場合もある。また、各ページの構成についても一例であって、例えば共有試着ページに同時に表示されるユーザの画像は何人分であってもよい。解像度や大きさの点から同時に表示される人数（画像数）を制限したい場合には、複数ページにわたって表示されるような構成であってもよい。また、各サーバは１台による構成に限らず、複数台による構成であってもよい。例えばＡＳＰサーバ５や販売サイト・サーバが複数台で構成されていてもよい。
【０３１２】
（付記１）
所定の者の仮想試着場面の画像を複数人で閲覧するための情報処理方法であって、
仮想試着場面の画像の閲覧を可能とする第１のユーザの登録要求を受信した場合、当該第１のユーザに関する情報を記憶装置に登録するステップと、
前記仮想試着場面の画像の閲覧が可能であると登録された第１のユーザの端末から前記仮想試着場面の画像の閲覧要求を受信した場合、前記記憶装置に登録された当該第１のユーザに関する情報と前記仮想試着場面に登場する前記所定の者に関する情報との少なくともいずれかに基づき仮想試着場面の画像を生成し、当該第１のユーザの端末に送信するステップと、
を含む情報処理方法。
【０３１３】
（付記２）
第２のユーザの仮想試着を可能とする設定要求を受信した場合、前記第２のユーザに対応して仮想試着が可能であることを表す情報を記憶装置に登録するステップと、
前記第２のユーザの端末から当該第２のユーザの仮想試着に関する設定情報を受信した場合、当該第２のユーザの仮想試着に関する設定情報を記憶装置に登録するステップと、
をさらに含む付記１記載の情報処理方法。
【０３１４】
（付記３）
前記所定の者に関する情報が、前記第２のユーザの仮想試着に関する設定情報を含むことを特徴とする付記２記載の情報処理方法。
【０３１５】
（付記４）
前記第２のユーザの仮想試着に関する設定情報が、前記第１のユーザに対する前記第２のユーザの画像の開示部位に関する情報を少なくとも含むことを特徴とする付記３記載の情報処理方法。
【０３１６】
（付記５）
前記第２のユーザの仮想試着に関する設定情報は、前記第１のユーザによる、当該第２のユーザの画像に対する仮想試着操作に関する設定情報を含むことを特徴とする付記２乃至４のいずれか１つに記載の情報処理方法。
【０３１７】
（付記６）
前記仮想試着操作に関する設定情報に則った仮想試着操作指示を前記第１のユーザの端末から受信した場合、少なくとも当該仮想試着操作指示に基づき仮想試着場面の画像を生成し、当該第１のユーザの端末に送信するステップをさらに含む付記５記載の情報処理方法。
【０３１８】
（付記７）
所定の者の仮想試着に用いられた商品の決済についての情報処理方法であって、
所定の者に商品を仮想試着させる要求をユーザの端末から受信した場合には、少なくとも当該所定の者に関する情報と前記商品に関する情報とを試着情報記憶部に格納するステップと、
商品又は前記所定の者を指定する決済要求をユーザの端末から受信した場合、指定された商品若しくは前記所定の者が仮想試着した商品又は商品群に対応して支払者たる当該ユーザの情報を決済情報記憶部に格納するステップと、
を含む情報処理方法。
【０３１９】
（付記８）
支払者たるユーザの支払金額の情報を当該ユーザの端末から受信した場合、当該支払金額の情報を少なくとも前記ユーザに対応付けて決済情報記憶部に格納するステップをさらに含む付記７記載の情報処理方法。
【０３２０】
（付記９）
支払分担の指示情報を支払者たるユーザの端末から受信した場合には、当該支払分担の指示情報に基づき計算された支払金額を少なくとも前記ユーザに対応付けて決済情報記憶部に格納するステップをさらに含む付記７又は８記載の情報処理方法。
【０３２１】
（付記１０）
前記指定された商品若しくは前記所定の者が仮想試着した商品又は商品群の注文金額に前記支払者たる複数のユーザの支払金額の累計が達するまで又は前記決済要求を受信してから所定の期間、当該指定された商品若しくは当該所定の者が仮想試着した商品又は商品群についての決済要求を受け付け、
前記指定された商品若しくは前記所定の者が仮想試着した商品又は商品群の注文金額に前記支払者たる複数のユーザの支払金額の累計が達した場合、当該指定された商品若しくは当該所定の者が仮想試着した商品又は商品群の発注処理を行うステップをさらに含む付記８記載の情報処理方法。
【０３２２】
（付記１１）
所定の者の仮想試着場面の画像をサーバに対して要求するステップと、
要求元ユーザに関する情報と前記仮想試着場面に登場する前記所定の者に関する情報との少なくともいずれかに基づき生成された仮想試着場面の画像を前記サーバから受信して表示装置に表示するステップと、
を含む情報処理方法。
【０３２３】
（付記１２）
少なくとも仮想試着を行った所定の者に関する情報と当該所定の者に対応付けられた仮想試着商品の情報とを前記サーバから受信して表示装置に表示するステップと、
前記仮想試着商品又は前記所定の者を指定する決済要求を前記サーバに送信するステップと、
を含む決済処理方法。
【０３２４】
（付記１３）
所定の者に商品を対応付けるための要求をユーザの端末から受信した場合には、少なくとも当該所定の者に関する情報と前記商品に関する情報とを商品情報記憶部に格納するステップと、
商品又は前記所定の者を指定する決済要求をユーザの端末から受信した場合、指定された商品若しくは前記所定の者に対応付けられた商品又は商品群に対応して支払者たる当該ユーザの情報を決済情報記憶部に格納するステップと、
を含む商品の決済についての情報処理方法。
【０３２５】
（付記１４）
付記１乃至１０又は１３のいずれか１つに記載の情報処理方法をコンピュータに実行させるためのプログラム。
【０３２６】
（付記１５）
所定の者の仮想試着場面の画像を複数人で閲覧するための情報処理装置であって、
仮想試着場面の画像の閲覧を可能とするユーザの登録要求を受信した場合、当該ユーザに関する情報を記憶装置に登録する手段と、
前記仮想試着場面の画像の閲覧が可能であると登録された第１のユーザの端末から前記仮想試着場面の画像の閲覧要求を受信した場合、前記記憶装置に登録された当該第１のユーザに関する情報と前記仮想試着場面に登場する前記所定の者に関する情報との少なくともいずれかに基づき仮想試着場面の画像を生成し、当該第１のユーザの端末に送信する手段と、
を有する情報処理装置。
【０３２７】
（付記１６）
所定の者の仮想試着に用いられた商品の決済処理装置であって、
所定の者に商品を仮想試着させる要求をユーザの端末から受信した場合には、少なくとも当該所定の者に関する情報と前記商品に関する情報とを試着情報記憶部に格納する手段と、
商品又は前記所定の者のいずれかを指定する決済要求をユーザの端末から受信した場合、指定された商品若しくは前記所定の者が仮想試着した商品又は商品群に対応して支払者たる当該ユーザの情報を決済情報記憶部に格納する手段と、
を有する決済処理装置。
【０３２８】
【発明の効果】
以上述べたように、本発明によれば、オンライン・ショッピングにおいても複数人による現実のショッピングに近い状況を実現するための新規な情報処理技術を提供することができた。
【０３２９】
また、試着された商品の多様な代金支払態様を可能にするための情報処理技術を提供することもできた。
【図面の簡単な説明】
【図１】本発明の一実施の形態におけるシステム概要図である。
【図２】商品ＤＢのテーブルの構成及び格納されるデータの一例を示す図である。
【図３】ユーザ管理ＤＢのテーブルの構成及び格納されるデータの一例を示す図である。
【図４】バスケット管理テーブルの構成及び格納されるデータの一例を示す図である。
【図５】利用者エントリ・テーブルの構成及び格納されるデータの一例を示す図である。
【図６】試着エントリ・テーブルの構成及び格納されるデータの一例を示す図である。
【図７】購入管理テーブルの構成及び格納されるデータの一例を示す図である。
【図８】注文テーブルの構成及び格納されるデータの一例を示す図である。
【図９】本発明の一実施の形態における画面遷移（その１）を示す図である。
【図１０】本発明の一実施の形態における画面遷移（その２）を示す図である。
【図１１】本発明の一実施の形態における処理フロー（その１）を示す図である。
【図１２】選択商品表示ページの一例を示す図である。
【図１３】本発明の一実施の形態における処理フロー（その２）を示す図である。
【図１４】試着画面選択ページの一例を示す図である。。
【図１５】本発明の一実施の形態における処理フロー（その３）を示す図である。
【図１６】共有グループ一覧ページの一例を示す図である。
【図１７】本発明の一実施の形態における処理フロー（その４）を示す図である。
【図１８】試着者選択ページの一例を示す図である。
【図１９】共有試着ページの一例（その１）を示す図である。
【図２０】本発明の一実施の形態における処理フロー（その５）を示す図である。
【図２１】本発明の一実施の形態における処理フロー（その６）を示す図である。
【図２２】共有グループ新規作成・編集ページの一例を示す図である。
【図２３】本発明の一実施の形態における処理フロー（その７）を示す図である。
【図２４】メンバ追加ページの一例を示す図である。
【図２５】本発明の一実施の形態における処理フロー（その８）を示す図である。
【図２６】共有設定ページの一例を示す図である。
【図２７】共有試着ページの一例（その２）を示す図である。
【図２８】共有試着ページの一例（その３）を示す図である。
【図２９】本発明の一実施の形態における処理フロー（その９）を示す図である。
【図３０】試着リスト・ページの一例（その１）を示す図である。
【図３１】試着リスト・ページの一例（その２）を示す図である。
【図３２】試着リスト・ページの一例（その３）を示す図である。
【図３３】試着リスト・ページの一例（その４）を示す図である。
【図３４】本発明の一実施の形態における処理フロー（その１０）を示す図である。
【図３５】試着商品コピー処理ページの一例を示す図である。
【図３６】試着リスト・ページの一例（その５）を示す図である。
【図３７】本発明の一実施の形態における処理フロー（その１１）を示す図である。
【図３８】本発明の一実施の形態における処理フロー（その１２）を示す図である。
【図３９】会計用試着リスト・ページの一例（その１）を示す図である。
【図４０】会計用試着リスト・ページの一例（その２）を示す図である。
【図４１】本発明の一実施の形態における処理フロー（その１３）を示す図である。
【図４２】商品別会計ページの一例（その１）を示す図である。
【図４３】本発明の一実施の形態における処理フロー（その１４）を示す図である。
【図４４】商品別支払登録ページの一例（その１）を示す図である。
【図４５】商品別支払登録確認ページの一例（その１）を示す図である。
【図４６】会計用試着リスト・ページの一例（その３）を示す図である。
【図４７】商品別会計ページの一例（その２）を示す図である。
【図４８】商品別支払登録ページの一例（その２）を示す図である。
【図４９】商品別支払登録確認ページの一例（その２）を示す図である。
【図５０】本発明の一実施の形態における処理フロー（その１５）を示す図である。
【図５１】会計試着者選択ページの一例を示す図である。
【図５２】本発明の一実施の形態における処理フロー（その１６）を示す図である。
【図５３】試着者別会計ページの一例を示す図である。
【図５４】本発明の一実施の形態における処理フロー（その１７）を示す図である。
【図５５】試着者別支払登録ページの一例を示す図である。
【図５６】試着者別支払登録確認ページの一例を示す図である。
【図５７】本発明の一実施の形態における処理フロー（その１８）を示す図である。
【図５８】試着部位選択ページの一例を示す図である。
【図５９】個人用試着ページの一例を示す図である。
【図６０】本発明の一実施の形態における処理フロー（その１９）を示す図である。
【図６１】個人試着リスト・ページの一例（その１）を示す図である。
【図６２】個人試着リスト・ページの一例（その２）を示す図である。
【符号の説明】
１　ネットワーク　　３　ユーザ端末Ａ
５　ＡＳＰサーバ　　７　ユーザ端末Ｂ
９　販売サイトＡサーバ　　１１　販売サイトＢサーバ
５１　試着管理ＤＢ　　５３　ユーザ管理ＤＢ
９１　商品ＤＢ（販売サイトＡ）
１１１　商品ＤＢ（販売サイトＢ）

Claims (5)

1. 所定の者の仮想試着場面の画像を複数人で閲覧するための情報処理方法であって、
   仮想試着場面の画像の閲覧を可能とする第１のユーザの登録要求を受信した場合、当該第１のユーザに関する情報を記憶装置に登録するステップと、
   前記仮想試着場面の画像の閲覧が可能であると登録された第１のユーザの端末から前記仮想試着場面の画像の閲覧要求を受信した場合、前記記憶装置に登録された当該第１のユーザに関する情報と前記仮想試着場面に登場する前記所定の者に関する情報との少なくともいずれかに基づき仮想試着場面の画像を生成し、当該第１のユーザの端末に送信するステップと、
   を含む情報処理方法。
2. 第２のユーザの仮想試着を可能とする設定要求を受信した場合、前記第２のユーザに対応して仮想試着が可能であることを表す情報を記憶装置に登録するステップと、
   前記第２のユーザの端末から当該第２のユーザの仮想試着に関する設定情報を受信した場合、当該第２のユーザの仮想試着に関する設定情報を記憶装置に登録するステップと、
   をさらに含む請求項１記載の情報処理方法。
3. 前記所定の者に関する情報が、前記第２のユーザの仮想試着に関する設定情報を含むことを特徴とする請求項２記載の情報処理方法。
4. 所定の者の仮想試着に用いられた商品の決済についての情報処理方法であって、
   所定の者に商品を仮想試着させる要求をユーザの端末から受信した場合には、少なくとも当該所定の者に関する情報と前記商品に関する情報とを試着情報記憶部に格納するステップと、
   商品又は前記所定の者を指定する決済要求をユーザの端末から受信した場合、指定された商品若しくは前記所定の者が仮想試着した商品又は商品群に対応して支払者たる当該ユーザの情報を決済情報記憶部に格納するステップと、
   を含む情報処理方法。
5. 支払者たるユーザの支払金額の情報を当該ユーザの端末から受信した場合、当該支払金額の情報を少なくとも前記ユーザに対応付けて決済情報記憶部に格納するステップをさらに含む請求項４記載の情報処理方法。

Images