JP5550083B2 - 情報処理装置、情報処理システム、情報処理方法及びプログラム - Google Patents

Description

本発明は、取引金額入力ウィンドウを用いた決済手段提供システム及び方法に係り、さらに詳しくは、同好会などが運営するウェブサイトまたはＮＡＶＥＲ（大韓民国のＮＨＮ社が運営する検索サイト）などが運営するカフェ内の商品販売掲示板に決済手段を提供し、前記決済手段を用いた個人と個人との間の取引環境において発生する取引商品最終金額の変動性を考慮して、購買者が購買金額を入力して決済ウィンドウを完成した後、当該決済金額を入金することにより決済が完了する決済手段提供システム及び方法に関する。

最近のインターネットの発達には目を見張るものがあり、これに伴い、インターネットを用いた商品取引が盛んになされている。インターネットを用いた商品取引は、ユーザーが直接的に商店を訪問することなく、会社や自宅のパソコンを介してインターネットで商品を選択し、注文、決済及び配送まで処理することが可能であり、ショッピング時間が省かれ、手軽に種々の商品を比較することができるなど数多くのメリットがある。このようなインターネットを用いた商品取引にあって、消費者が特に重要視している事項の一つは、代金決済に関することである。

インターネットを用いた商品取引代金を支払う安全な方法の一つは、エスクロー制度を用いることである。その代表例として、韓国のオークションサイトがあるが、このようなエスクロー決済システムを小規模電子商取引サイトが自ら構築して運営するためには多大なコストがかかり、しかも、管理面でもかなりの難点がある。

このような難点を克服するために、エスクロー決済方法を同好会が運営する小規模サイトに対して専門的に提供する会社が新設されている。その代表例が、「www.unicro.co.kr」とうサイトである。当該業体は、サービスを受けたいサイトと提携を結んだ後、エスクロー決済手段を提供している。例えば、「www.unicro.co.kr」というサイトは、「www.pentaxclub.co.kr」というカメラ同好会サイトと提携を結んだ後、「www.pentaxclub.co.kr」サイトの同好会会員がカメラまたはその附属品を売りたいときにエスクロー決済手段を提供している。

しかしながら、「www.unicro.co.kr」というサイトが提供するエスクロー決済方法またはシステムを、当該サイトと協約が締結されていない同好会サイトなどにおいて用いることはできないという不都合がある。例えば、「www.unicro.co.kr」と「www.pentaxclub.co.kr」とが事前協約を締結し、商品情報を提供するシステムと決済システムとの統合作業を行う事前作業がなされていなければ、ｐｅｎｔａｘｃｌｕｂの会員がｕｎｉｃｒｏの決済手段を用いることができないという制約がある。すなわち、ＮＡＶＥＲにおいてカメラカフェサイトを運営する運営者が「www.unicro.co.kr」の提供する決済システムを用いたい場合には、先ず、ＮＡＶＥＲと「www.unicro.co.kr」との間に交渉が先行してなされている必要があるという問題がある。

一方で、個人と個人との間で取引される中古商品の取引について述べると、中古商品は、その特性から、価格の妥協が頻繁になされる。例えば、販売者Ａがヘルスサイクル（ヘルスバイク）を50,000ウォンで売るために商品販売掲示板に掲載したとする。購買者は、商品のイメージをみて、または、販売者Ａと通話した結果、当該ヘルスサイクルを用いるためにはヘルスサイクルのサドルを新品に交換する必要があるということを知り、購買者は、サドルの購入費用の10,000ウォンの５０％に相当する金額である5,000ウォンを割り引いて購入することを希望している。販売者Ａは、できる限り早期に処分することを希望していたため、新たな購買者を探すよりは、5,000ウォンの割引を要求する当該購買者に販売すると約束している。

ところが、従来のエスクロー取引決済提供システム及び方法は、販売者が商品を登録するときに取引金額を確定した上でエスクロー決済ウィンドウを提供するが、上記のように価格の妥協が必要になる場合には使い難かった。

上記と類似の過程を通じて価格が変動され、変動された価格に合わせて購買者が最終的な取引、すなわち、決済を行うために、販売者は、最初に登録した販売価格を変動された価格として再登録する煩雑な決済金額の修正作業を経ることを余儀なくされるという問題点があった。

また、販売者と購買者との間において携帯電話などを用いた価格の妥協がなされた後、最終的な取引金額が確定されたとしても、販売者が直ちにインターネットに接続できない状況であれば、修正作業を直ちに実行に移すことができなくなる。このため、購買者は、このような修正作業が完了することを待ち続けなければならず、結果として、商品取引の進行が遅れてしまうという不都合がある。

また、従来のエスクロー決済システムは、決済しか担当しないにも拘わらず、エスクロー決済を提供するシステムに販売しようとする商品情報を別途にアップロードしなければならないという問題がある。販売者にとっては、本人が会員として加入して商品の販売を仲介しているサイトだけではなく、エスクロー決済を代行する決済システムにも商品情報をアップロードするといった二重作業をしているのが現状である。このような実情により、従来のエスクロー決済システムが提供する方式は、販売者にとっては、安全に決済し得るということは分かっているとはいえ、使い勝手が悪いという理由で汎用されていないのが現状である。

本発明は、上記の問題点を解消するためになされたものであり、サイトとサイトとの間の事前協約がない状態でも決済し易い決済方法及びシステムを提供することを目的としている。

本発明の他の目的は、販売者と購買者との間で価格の妥協がなされた後、販売者が確定された販売金額を用いて自ら決済ウィンドウを修正し易く、これにより決済がなされる決済方法及びシステムを提供することを目的としている。

本発明のさらに他の目的は、販売者が販売する商品名を手軽に決済ウィンドウに提供することのできる決済方法及びシステムを提供することを目的としている。

本発明のさらに他の目的は、販売者が決済システムには販売しようとする商品情報を別途にアップロードする必要がなく、販売者識別子を区切りキーとして運営される決済方法及びシステムを提供することを目的としている。

本発明の上記目的は、インターネットに接続されたウェブ環境を用いて販売者システムと購買者システムとの間において商品取引を行うに当たって、前記販売者システムと購買者システムとの間において決済手段を提供する取引決済提供システムであって、会員加入を完了した販売者の会員識別子がメタ情報として含まれる入金ウィンドウを生成して前記販売者システムに提供し、前記販売者システムが前記入金ウィンドウをウェブ環境に保存し、前記入金ウィンドウに取引金額を含む詳細取引情報データがさらに入力されて前記ウェブ環境に表示された状態で前記購買者が表示された前記入金ウィンドウを押した場合に、前記ウェブ環境から詳細取引情報データ及び販売者の会員識別子が送信された後、購買者システムに、前記詳細取引情報データが表示される金額確定ウィンドウを提供することを特徴とする取引決済提供システムによって達成可能である。

本発明の上記他の目的は、インターネットに接続されたウェブ環境を用いて販売者システムと購買者システムとの間において商品取引を行うに当たって、前記販売者システムと購買者システムとの間において決済手段を提供する取引決済提供方法であって、販売者を会員として加入させる第１のステップと、販売者の会員識別子がメタ情報として含まれる入金ウィンドウを生成して前記購買者システムのクリップボードに提供する第２のステップ及び販売者である会員が前記固有の入金ウィンドウをコピーして前記ウェブ環境に保存した後、取引金額を含む詳細取引情報データをさらに入力した後に前記ウェブ環境に表示させ、前記購買者が表示された前記入金ウィンドウを押す場合、前記購買者システムに前記詳細取引情報データを含む金額確定ウィンドウを提供する第３のステップを含むことを特徴とする取引決済の提供方法によって達成可能である。

本発明に係る取引金額入力ウィンドウを用いた取引決済提供システム及び方法によれば、販売者による修正入力を容易にして、販売者と購買者との間の取引の妥協が頻繁に発生して価格が変動される状況に容易に適用することができる。

また、本発明においては、商品別の取引明細を提供することを回避し、商品を販売する会員ごとに固有に生成される入金ウィンドウを用いることにより、決済方式を提供するサイトと、このようなサービスの提供を受けるサイトとの間の商品データベース（ＤＢ）統合または取引ＤＢ統合などの事前調整を無くすことができるので、決済方式をあらゆるウェブ環境に適用することができる。

さらに、本発明に係る取引決済提供システム及び方法によれば、決済ウィンドウに販売者が販売しようとする商品名などを手軽に登録することができ、販売者に与えられる１つの決済ウィンドウを用いて多数の商品を容易に取引することができる。

本発明に係る取引決済提供システム及び周辺システムの構成図である。 本発明に係る取引決済提供システムと周辺システムとの間の業務の流れを示すフローチャートである。 金額確定ウィンドウの一例を示す図である。 販売者がウェブ環境「www.naver.com/blog/FAIRLADY_Z」に３種類の商品を登録した例のウェブ環境を示す図である。 図４の商品を購入する購買者「Cassis_Orange」が金額確定ウィンドウを入力した例を示す図である。 図４の商品を購入する購買者「save_the_future」が金額確定ウィンドウを入力した例を示す図である。 販売者「FAIRLADY_Z」が取引決済提供システムにログインし、販売の進み具合を照会したときに表示される画面の一例を示す図である。 本発明に係る取引決済提供システムと周辺システムとの間の業務の流れを示すフローチャートである。 会員加入画面の一例を示す図である。 会員に提供される入金ウィンドウの一例を示す図である。 パラン（paran）を介して電子メールを送るとき、電子メールの本文に入金ウィンドウをコピーして購買者に送る例を示す図である。 ウェブ環境に表示された入金ウィンドウのｈｔｍｌエディター上に表示されるｈｔｍｌ言語形式の例示図であって、（ａ）は、詳細取引情報データが入力される前の入金ウィンドウのｈｔｍｌ言語であり、（ｂ）は、四角領域内に表示されるように、販売者によって追加される詳細取引情報データの入力形式を表示した例であり、（ｃ）は、販売者によって追加された詳細取引情報データが入力された後の入金ウィンドウのｈｔｍｌ言語である。 購買者が決済提供システムの会員である場合の金額確定ウィンドウの詳細な実施形態を示す図である。 購買者が非会員である場合の金額確定ウィンドウの詳細な実施形態を示す図である。 販売しようとする多数の商品を一つのイメージ上に表現し、当該イメージ上の商品をクリックする場合に金額確定ウィンドウ２０−１、２０−２、…、２０−６が表示される一例を示すものである。 図１５の場合の処理の流れを示したフローチャートである。 本発明の入金ウィンドウを書籍のプレビュー機能に適用した一例を示すものである。

以下、添付図面に基づき、本発明の特長点及び好適な実施形態について詳述する。

図１は、本発明に係る取引決済提供システム及び周辺システムの構成図である。決済提供システムは、インターネット網を介してＰＧ（Payment Gateway）社、ウェブ環境、販売者システム及び購買者システムと接続され、専用線を介して金融機関システムと接続される。

取引決済提供システムは、インターネット網に接続されたウェブ環境を用いて販売者と購買者との間において商品取引を行うに当たって、前記販売者と購買者との間において決済手段を提供する取引決済提供システムであって、会員ごとに固有の入金ウィンドウを生成して提供し、入金ウィンドウを前記ウェブ環境にコピーできるようにし、販売者である会員が前記固有の入金ウィンドウをコピーしてウェブ環境に表示させた後、ウェブ環境が提供するＨＴＭＬ（Hyper Text Markup Language）エディターなどを用いて固有の入金ウィンドウに販売価格と商品名を含む詳細取引情報データをさらに入力し、購買者が表示された入金ウィンドウを押した場合に、詳細取引情報データが送信されてこれが解析された後、購買者に販売価格と商品名情報とが含まれる金額確定ウィンドウを提供する。システムは、通常、サーバーコンピュータと呼ばれる入出力装置付き装置から構成される。

取引決済提供システムは、加入された会員に関する情報を保存する会員ＤＢと、販売者が予め指定した取引承認コードを保存するメモリーと、会員別の販売商品を登録したウェブ環境のＵＲＬ情報を保存する商品情報ＤＢと、購買者が会員である場合に当該会員別の購買情報を保存する会員購買ＤＢと、購買者が非会員である場合に当該非会員別の購買情報を保存する非会員購買ＤＢと、を備える。

金融機関システムは、取引決済提供システムに仮想口座を提供し、取引決済提供システムの要請に応じて、取引決済提供システム会員の入金明細を専用線を介して知らせるか、あるいは、周期的に若しくは入金明細が発生する度に取引決済提供システム会員の入金明細を提供する。

ＰＧ社は、ウェブ環境において購買者が購買代金を入金するとき、取引決済提供システムに代えてクレジットカード決済、無通帳入金、サイバーマネー決済、及び携帯電話決済などの種々の決済手段を提供するシステムを運営する会社であり、代表的なＰＧ社としては、韓国サイバーマネー社、イニシス社などがある。

ウェブ環境とは、販売者システム及び購買者システムにインターネット上の活動空間を提供するサイト運営装置であり、販売者システム及び購買者システムに同好会サイト、個人ホームページ、フォーラム、ミニホームページ、ブログ、掲示板などのインターネット上の活動空間を提供する装置を意味する。ウェブ環境は、販売者が売ろうとする商品を広報可能なインターネット上の空間を提供するシステムであれば、その種類を問わない。

販売者システムは、商品を販売する個人が運営するコンピュータ装置であって、生成された入金ウィンドウをコピーした後にウェブ環境に登録する装置であり、通常、パソコン装置を意味し、購買者システムは、ウェブ環境が提供するインターネット空間においてウェブサーフィングをしていて購買しようとする商品が見つかった場合に表示された入金ウィンドウを介して決済を行う購買者のパソコン装置を意味する。

図２は、本発明に係る取引決済提供システムと周辺システムとの間の業務の流れを示すフローチャートである。

販売者システムは、取引決済提供システムに会員加入をする（ＳＴ１）。会員加入の際に、会員ＩＤ、パスワード、住所、送金される口座番号及び取引を承認するための取引承認コードなどが入力され、当該内容は会員ＤＢに保存される。

このとき、口座番号と取引承認コードは、会員加入時に要請することなく、別途の段階において要請してもよく、会員ＤＢではない別途のＤＢに保存されてもよいことは言うまでもない。

取引決済提供システムは、会員ごとに固有の入金ウィンドウを生成する（ＳＴ２）。入金ウィンドウは、ウェブ環境に表示されるときには、見かけ上、単なるボタンのように見え、当該ボタンには、メタ情報として、販売者である会員を識別する会員識別子（例えば、会員ＩＤ）が関連付けて保存される。ここで、「会員ごとに固有の入金ウィンドウ」とは、通常の電子商取引システムにおける、販売中の商品をキーとした固有の入金ウィンドウと対比される用語であり、同じ会員であれば、販売する商品の種類及び数量によらずに固有に一つが与えられる。

より具体的には、従来のオークションサイト（www.auction.co.kr）において商品を販売中の販売者は、当該商品の販売数量、入金明細を知るためには、販売中の商品を選択する必要がある。すなわち、ｕｓｅｒ１という販売者が自転車５台とゴルフクラブ３本を販売中である場合に、自転車を販売するためのウェブページと、ゴルフクラブを販売するためのウェブページとを別々に生成し、各商品の販売ウェブページには決済ボタンが存在する。各決済ボタンは当該商品に従属されて生成されて管理される。ｕｓｅｒ１が自転車販売に対する入金明細を把握するためには、販売中の商品のうち自転車を選択する必要があり、ゴルフクラブに対する入金明細を把握するためには、販売中の商品のうちゴルフクラブを選択する必要がある。すなわち、従来のオークションサイトシステムは、会員に固有の入金ウィンドウが提供されるのではなく、商品ごとに固有の入金ウィンドウが提供されるものと理解されるべきである。すなわち、販売中の商品をキーとして入金状況などが提供されるのである。

これに対し、本発明においては、上記の同じ状況下で、ｕｓｅｒ１という販売者が自転車５台とゴルフクラブ３本を販売中である場合、自転車を販売するためのウェブページと、ゴルフクラブを販売するためのウェブページを生成する。このとき、全ての商品を１つのウェブページを用いて販売してもよく、商品ごとにウェブページを別々に生成して販売してもよい。１ページのウェブページを用いる場合には、当然のことながら、入金ウィンドウが１ページしか生成されないため、商品ごとに各々のウェブページを生成する場合について説明する。各商品の販売ウェブページには、本発明に従い生成された入金ウィンドウをコピーして当該ウェブページに表示させればよいが、このとき、ウェブページに表示される入金ウィンドウは、一見して２つ存在するかのように見えるが、実質的に同じボタンをコピーしておいたものに過ぎない。これは、本発明が提供される入金ウィンドウは会員ごとに固有の入金ウィンドウであるためである。

販売者は、ウェブ環境に販売しようとする商品を登録し、入金ウィンドウをコピーして当該ウェブ環境に表示させる（ＳＴ３）。入金ウィンドウのコピーは、取引決済提供システムから販売者のクリップボードにコピーした後、当該ウェブ環境に貼り付けることにより行われる。このとき、ユーザーの貼り付け動作がある場合に、入金ウィンドウのボタンに対応するウェブ環境のＵＲＬをコピーして取引決済提供システムに送信し、これを受け取った取引決済提供システムはこれを会員ごとの販売ＤＢに保存する。

販売者は、当該ウェブ環境が提供するＨＴＭＬ（Hyper Text Markup Language）エディターなどを用いて固有の入金ウィンドウに販売価格と商品名を含む詳細取引情報データをさらに入力する（ＳＴ４）。

購買者システムは、ウェブ環境をサーフィング中に購買したい商品を見つけた場合（ＳＴ５）、当該ウェブ環境が提供する文字、チャットまたはウェブ環境に記載の販売者の電話番号などを用いて販売者に購買を要請する（ＳＴ６）。販売者システムは、当該商品を販売しようとする場合、文字、チャットまたは通話を用いて取引承認コードを送信し（ＳＴ７）、購買者システムは、当該取引承認コードを入力する（ＳＴ８）。取引承認コードの入力は、通常、販売者が当該ウェブ環境に表示させておいた入金ウィンドウをクリックすると、取引承認コードを入力するためのウィンドウを提供し、購買者システムが、表示されたウィンドウを介して販売者から送られてきた取引承認コードを入力することで行われる。

入力された取引承認コードは、取引決済提供システムに送信され、取引決済提供システムは、購買者システムから送信された取引承認コードと販売者が事前に登録した取引承認コードとを比較して、これらが一致しているか否かを確認する。上述したように、販売者が事前に登録した取引承認コードは、会員ＤＢまたは別途のＤＢに保存され、このようなＤＢは、取引決済提供システムのメモリーに永続的に保存される。

取引承認コードが一致している場合、取引決済提供システムは、詳細取引情報データを解析し（ＳＴ１０）、解析された詳細取引情報を用いて購買者システムに詳細取引情報付き金額確定ウィンドウを提供する（ＳＴ１１）。図３は、金額確定ウィンドウの一例を示すものである。購買者システムは、取引決済提供システムの会員であるか否かをチェックする。会員である場合、決済提供システムに保存されていた配送地及び会員識別子（例えば、会員ＩＤ）を読み込んで金額確定ウィンドウに表示する。非会員である場合には、金額確定ウィンドウに示されているあらゆる情報を自ら入力せねばならない。

購買者は、取引に必要な取引数量、配送地情報、配送費決済主体、購買商品名及び取引メモをはじめとする残りの情報を入力する（ＳＴ１２）。このとき、本発明においては、商品ごとに入金有無を判断可能なシステムとして構築されていないため、どのような商品を購入するかを示す購買商品名を入力し、さらに取引メモに関する情報を入力するようになっている。本願の発明者による先の出願である大韓民国特許出願１０−２００８−１１６８６７号に開示されている発明においても、会員ごとに固有の入金ウィンドウの場合、販売者ごとに固有の入金ウィンドウが１つしか与えられない。ところが、当該先の出願は、販売者が多数の商品を販売する場合、金額が変更し難く、購買者に提示される金額確定ウィンドウに、購買しようとする商品名を提示することができないため、購買者に購買金額と購買しようとする商品名を記載させなければならないという不都合があった。本発明においては、本願発明者による先の出願の大韓民国特許出願１０−２００８−１１６８６７号において発生する前記２通りの問題点を、詳細取引情報データを用いて解消することが可能になった。

このため、本発明においては、購買者が入金する場合、詳細取引情報データに含まれている「商品名」を用いて、どのような商品に対する決済がなされたかを販売者が容易に判断することが可能になった。どのような商品が販売されたかを手軽に把握するための他の方法として、販売者が商品を登録する際に当該ウェブ環境におけるＵＲＬを保存し、購買者が商品を購買しようとするときに当該ウェブ環境のＵＲＬを読み込んで商品販売登録時に保存されたＵＲＬと比較して両者を関連付けて表示する方法が挙げられるが、この方法も正確には商品別にどれくらいの数量が売られ、売上高がいくらであるかなどに関するデータを知らせるには難点がある。

例示の金額確定ウィンドウには購買者の電話番号も入力されるようになっている。ここで、購買者が取引決済提供システムの会員である場合には、当該システムから読み込んで提供してもよいが、非会員である場合には、自ら入力するようにする。購買者の電話番号の他にも、電子メールアドレスなどを入力するようにしてもよく、電話番号または電子メールアドレスなどの購買者ごとに固有の情報は、今後、非会員購買情報を提供するキー値として使用可能である。

図３に例示された金額確定ウィンドウにおいては、取引承認コードを入力するようになっているが、取引承認コードは、図２に例示されているように、金額確定ウィンドウに先駆けて入力してもよく、図３に示すように、金額確定ウィンドウと一緒に入力してもよい。図３に示すように、金額確定ウィンドウに入力する場合にも、販売者が事前に登録した取引承認コードと比較・確認する作業が取引承認前に行われる必要がある。金額確定ウィンドウも、当該商品を登録した取引決済提供システムの会員識別子をメタ情報として有している必要がある。

購買者システムが金額確定ウィンドウ入力を完了すると（ＳＴ１２）、取引決済提供システムは、金額確定ウィンドウの入力内容を保存する（ＳＴ１３）。このような保存は、ＤＢまたはテーブル形式などにより行われるが、例えば、金額確定ウィンドウの入力内容が商品情報ＤＢに保存されることを想定している。通常の電子商取引システムにおいては、販売者が販売しようとする商品を登録する時点で商品情報ＤＢまたは販売ＤＢが生成される。ここで、商品情報ＤＢまたは販売ＤＢは、販売者が販売しようとする商品に関する情報を保存するＤＢを意味する。しかしながら、本発明に係る取引決済提供システムは、販売者が入金ウィンドウをウェブ環境に貼り付けて表示させるだけでは特別な取引が行われるわけではないため、このステップまではあえて販売しようとする商品を保管する必要がない。よって、購買者が入金ウィンドウをクリックするステップまたは購買者が入金を完了するステップにおいて、商品情報ＤＢまたは販売ＤＢを生成しても構わない。商品情報ＤＢには、決済金額、数量、ウェブ環境のＵＲＬ、購買商品、配送地、購買者の電話番号、取引メモに関する情報が保存される。一方で、取引決済提供システムは、購買者にも購買を行った商品に関する情報を提供する必要があるが、このために、会員である場合、会員購買ＤＢを用いて内容を提供し、非会員である場合、非会員購買ＤＢを用いて購買内容を提供する（ＳＴ１４）。会員購買ＤＢには、「会員ＩＤ、決済金額、数量、取引ウェブ環境のＵＲＬ、配送地、購買者の電話番号、購買商品名、取引メモ」が保存され、非会員購買ＤＢには、「決済金額、数量、取引ウェブ環境のＵＲＬ、配送地、購買者の電話番号、購買商品名、取引メモ」が保存される。購買者が取引決済提供システムにログインして購買の進み具合を把握する必要がある場合、会員である場合には、会員ＩＤを用いてログインし、非会員である場合、非会員を識別可能な購買者の電話番号、または電子メールアドレスなどを用いてログインする。

取引決済提供システムは、購買者が選択した入金方式によって決済モジュールを提供して決済を誘導する（ＳＴ１５、ＳＴ１６、ＳＴ１７）。入金方式による決済モジュールを提供する方法は、オークションサイトなどにおいて汎用されている方式であるため、その詳細な説明は省く。簡略に説明すると、無通帳入金である場合には、取引決済提供システムが当該販売者の仮想口座番号を購買者に通知することにより処理可能であり、クレジットカード及び携帯電話による決済の場合、ＰＧ社に決済金額を通知し、ＰＧ社に決済を代行せしめる。

次いで、決済内容を購買者及び販売者に通知し、販売者に配送を要請するステップ、購買者が取引を承認するステップなどは従来のオークションサイト、Ｇマーケットサイトが運営する方式とほとんど同様であるため、その詳細な説明を省く。

本発明においては、上述したように、商品販売または購買に対する入金ウィンドウが商品ごとに提供されるのではなく、販売者ごとに提供されることを特徴とする。このため、同じ販売者が多数の商品を販売する場合、商品ＤＢが取引決済提供システムに設けられていないため、どのような商品がどれくらい売れ、在庫がどれくらい残っているかなどに関する詳しい情報は知ることができない。これは、本発明において対象とする取引が主として個人同士の少数商品を販売することにフォーカスされているため、購買商品名と取引メモにより販売者と購買者との間で取引される明細を確認するようになっているためである。

実際に発生可能な取引を想定して、図４、図５及び図６を用いて説明する。図４に示すように、販売者がウェブ環境「www.Naver.com/blog/FAIRLADY_Z」に３種類の商品を販売するために登録したとする。従来の商品取引サイトにおいては、販売しようとする商品ごとに別個の商品登録ページを生成する必要がある。これは、結局、商品ごとに取引が行われ、データベースの運営及び決済処理なども商品ごとに行われるのである。しかしながら、本発明においては、会員ごとに固有の入金ウィンドウを用いることにより、同じ入金ウィンドウにより３種類の商品を取引することが可能になる。図４には、各商品を取引するための入金ウィンドウ４−１、４−２、４−３が各商品ごとに隣に開示されている。

このとき、表示されている３つの入金ウィンドウ４−１、４−２、４−３には、販売者の会員識別子が関連付けられてメタ情報として保存されている。なお、図２の手続きにおいて、ＳＴ３ステップまで行った場合、すなわち、当該ウェブ環境に入金ウィンドウをコピーしたステップまで行った場合には、いずれも同じ入金ウィンドウとしてウェブ環境に保存される。図４に示す３つの入金ウィンドウ４−１、４−２、４−３は、図２のＳＴ４ステップを行うことにより、異なる詳細取引情報データが入力されるため、異なるメタ情報が保存される。

例えば、ＳＴ３ステップまでのみ行われた入金ウィンドウ４−１、４−２、４−３をｈｔｍｌ言語で表示すると、いずれも「ｈｔｔｐ：／／ｗｗｗ．ｅｕｍｍｏｎｅｙ．ｃｏｍ／ｍｃ／ｉｎｄｅｘ．ｊｓｐ？ｍｃ＿ｉｄ＝会員識別ＩＤ」と表示され得る。ここで、「ｗｗｗ．ｅｕｍｍｏｎｅｙ．ｃｏｍ」は、取引決済提供システムのドメインアドレスとなり、会員識別ＩＤは、販売者識別子に相当する。この後、ＳＴ４ステップにおいて、各入金ウィンドウに詳細取引情報データが入力されると、各々の入金ウィンドウに相当するｈｔｍｌ言語は、価格と商品名が詳しく特定される入金ウィンドウに変更されて保存される。例えば、入金ウィンドウ４−１は、「ｈｔｔｐ：／／ｗｗｗ．ｅｕｍｍｏｎｅｙ．ｃｏｍ／ｍｃ／ｉｎｄｅｘ．ｊｓｐ？ｍｃ＿ｉｄ＝会員識別ＩＤ／300,000／ヘルスサイクル」のｈｔｍｌ言語で保存され、入金ウィンドウ４−２は、「ｈｔｔｐ：／／ｗｗｗ．ｅｕｍｍｏｎｅｙ．ｃｏｍ／ｍｃ／ｉｎｄｅｘ．ｊｓｐ？ｍｃ＿ｉｄ＝会員識別ＩＤ／20,000／キックボード」のｈｔｍｌ言語で保存され、入金ウィンドウ４−３は、「ｈｔｔｐ：／／ｗｗｗ．ｅｕｍｍｏｎｅｙ．ｃｏｍ／ｍｃ／ｉｎｄｅｘ．ｊｓｐ？ｍｃ＿ｉｄ＝会員識別ＩＤ／100,000／セイコー００７時計」のｈｔｍｌ言語で保存される。

図５は、購買者「Cassis_Orange」がヘルスサイクルを購入するために金額確定ウィンドウに入力した例であり、図６は、購買者「save_the_future」がセイコー時計を購入するために金額確定ウィンドウに入力した例である。もちろんこれは、図４に示す入金ウィンドウ４−１、４−３を購買者「Cassis_Orange」及び「save_the_future」が各々クリックした結果であり、本発明が提示する入金ウィンドウは複数の購買者同士において繰り返し用いることができる。

図５に示すように、購買者「Cassis_Orange」が入金ウィンドウ４−１をクリックすると、取引決済提供システムは、当該入金ウィンドウに保存されたｊｓｐ文を実行しつつ、区切子「／」の後ろにさらに入力されている詳細取引情報データを解析した後、これを金額確定ウィンドウに表示する。取引決済提供システムは、「Cassis_Orange」が取引決済提供システムの会員である場合、当該システムに保存されたアドレス（配送地）、購買者の電話番号を読み込んで金額確定ウィンドウに表示する。表示された内容に変更がある場合、購買者「Cassis_Orange」が修正してもよいことは言うまでもない。取引ページは、購買者「Cassis_Orange」が入力することなく、金額確定ウィンドウが生成されるとき、入金ウィンドウが提供されたウェブページのＵＲＬに関する情報が入手され、これが表示する。次いで、購買者「Cassis_Orange」は、数量、配送費決済主体、入金方式、取引メモを入力する。もし、取引メモ欄に購買しようとする商品名を記入する場合には、購買商品欄は重複する情報であるため省略しても構わない。

図６に示すように、購買者「save_the_future」は、取引決済提供システムの会員ではないため、取引ページを除く残りの情報を自ら入力する。図５及び図６に示すように、購買者が入力した情報は、取引決済提供システムにＤＢまたはテーブル形式などの方式により保存される。

図７は、販売者「FAIRLADY_Z」が取引決済提供システムにログインして販売の進み具合を照会したときに表示される画面の一例である。図７の画面に示すように、本発明においては、当該商品が販売されたか否かをシステムが自動的に判断する方式ではなく、販売者が入金ウィンドウにさらに入力した詳細取引情報データまたは購買者が入力した取引メモを当該販売者に表示することにより、どのような商品が取引されたかを目視する方式であることが分かる。

以下、詳しい実施形態について説明する。

図８は、本発明に係る取引決済提供システムと周辺システムとの間の業務の流れを示すフローチャートである。販売者システムは、取引決済提供システムに会員加入する（ｓ１）。図９は、会員加入画面を示す一例であり、会員加入時に実名確認、会員ＩＤ、パスワード、電子メールを入力し、当該内容は会員ＤＢに保存される。決済口座は、決済システムから実際にお金を引き出すタイミングで入力するようになっている。

取引決済提供システムは、会員加入を完了した会員に会員ごとに固有の入金ウィンドウを生成した後に提供する（ｓ２）。入金ウィンドウは、ウェブ環境に表示されるときには、見かけ上、単なるボタンのように見え、当該ボタンには、メタ情報として販売者である会員を識別する会員識別子（例えば、会員ＩＤ）が関連付けられて保存される。ここで、会員ごとに固有の入金ウィンドウとは、通常の電子商取引システムにおける、販売中の商品をキーとした固有の入金ウィンドウと対比される用語であり、同じ会員であれば、販売する商品の種類及び数量によらずに固有に一つが与えられる。

図１０は、会員に提供される入金ウィンドウの一例を示す図である。本発明においては、入金ウィンドウを３種類の形式で提供する。第一に、イメージ掲示板において使用可能なイメージ形式１０１であり、第二に、ＨＴＭＬ形式１０３であり、第三に、ＵＲＬ形式１０５である。

イメージ掲示板形式１０１で入金ウィンドウをウェブ環境に提供するために、クリップボードにコピーを行うソースコードの一例をJavaScript（登録商標）「ｆｕｎｃｔｉｏｎｃｏｐｙ＿ａｌｌ（）」により実現した例を以下に示す。
ｆｕｎｃｔｉｏｎｃｏｐｙ＿ａｌｌ（）
｛
ｖａｒｔｅｘｔ=ｄｏｃｕｍｅｎｔ．ｉｔｅｍ．ｄｏｃｕｍｅｎｔ．ｂｏｄｙ．ｃｒｅａｔｅＴｅｘｔＲａｎｇｅ（）；
ｔｅｘｔ．ｓｅｌｅｃｔ（）；
ｔｅｘｔ．ｅｘｅｃＣｏｍｍａｎｄ（"Ｃｏｐｙ"）；
｝

最初の「var text」文章は、コピーするイメージの領域を指定し、第二の「ｔｅｘｔ．ｓｅｌｅｃｔ（）」文章は、当該領域を選択するコマンドであり、最後の文章は、これを販売者システムのクリップボードにコピーするコマンドである。

ＨＴＭＬ形式１０３で提供されるソースコードとしては、以下のものが挙げられる。
Ｆｕｎｃｔｉｏｎ ｃｏｐｙ＿ｈｔｍｌ（）｛
Ｖａｒ ｅｌｅ=ｄｏｃｕｍｅｎｔ．ｉｔｅｍ．ｄｏｃｕｍｅｎｔ．ｂｏｄｙ；
Ｖａｒ ｍａｉｎｔｅｘｔ＝ｅｌｅ．ｉｎｎｅｒＨＴＭＬ；
Ｗｉｎｄｏｗ．ｃｌｉｐｂｏａｒｄＤａｔａ．ｓｅｔＤａｔａ（"Ｔｅｘｔ"、ｍａｉｎｔｅｘｔ）；
｝

オブジェクトを「ｄｏｃｕｍｅｎｔ．ｉｔｅｍ．ｄｏｃｕｍｅｎｔ．ｂｏｄｙ」に保存した後、これを「ｍａｉｎｔｅｘｔ」に変数として保存し、販売者システムのクリップボードに当該内容をコピーする。

ＵＲＬ形式１０５で提供されるソースコードは、以下により実現される。
Ｆｕｎｃｔｉｏｎ ｃｏｐｙ＿ｌｉｎｋ（）｛
Ｖａｒ ｍａｉｎｔｅｘｔ＝"ｈｔｔｐ：／／ｗｗｗ．ｅｕｍｍｏｎｅｙ．ｃｏｍ／ｍｃ／ｉｎｄｅｘ．ｊｓｐ？ｍｃ＿ｉｄ＝会員識別ＩＤ"；
Ｗｉｎｄｏｗ．ｃｌｉｐｂｏａｒｄＤａｔａ．ｓｅｔＤａｔａ（"Ｔｅｘｔ"、ｍａｉｎｔｅｘｔ）；
｝

前記３種類の形式の入金ウィンドウには、「ｈｔｔｐ；／／ｗｗｗ．ｅｕｍｍｏｎｅｙ．ｃｏｍ／ｍｃ／ｉｎｄｅｘ．ｊｓｐ？ｍｃ＿ｉｄ＝会員識別ＩＤ」がメタ情報として記録される。そのうち、「ｈｔｔｐ；／／ｗｗｗ．ｅｕｍｍｏｎｅｙ．ｃｏｍ／ｍｃ／ｉｎｄｅｘ．ｊｓｐ」は、購買者がウェブ環境にコピーされた入金ウィンドウをクリックしたときに実行されるｊｓｐ言語であり、販売者の会員識別コードまたは会員ＩＤが変数として保存されるものである。すなわち、本発明に従い提供される入金ウィンドウには、販売者の会員識別子と、購買者に決済金額を入力するフィールドが含まれているウィンドウを生成するメタ情報が含まれる。

販売者は、ウェブ環境に販売しようとする商品を登録し、入金ウィンドウをコピーして当該ウェブ環境に表示させる（ｓ３）。入金ウィンドウのコピーは、取引決済提供システムから販売者のクリップボードにコピーした後、当該ウェブ環境に貼り付けることにより行われる。図１１は、パランを介して電子メールを送る場合に、電子メールの本文に入金ウィンドウ１１１をコピーして購買者に送る例を示す図である。図１１においては、ウェブ環境として電子メール本文を設定しているが、これに加えて、ウェブ環境としては、インターネット掲示板、ブログ、同好会サイト、個人ホームページ、フォーラム、ミニホームページなどのインターネット上の活動空間が挙げられる。

当該入金ウィンドウは、販売しようとする商品価格及び商品名に関する情報が全く反映されていない状態であるため、ウェブ環境が提供するｈｔｍｌなどの文書エディターを用いて入金ウィンドウに詳細取引情報データを入力する。図１２は、ウェブ環境に表示された入金ウィンドウを消費者がクリックするときに実行されるコマンドをｈｔｍｌエディター上に表示したものである。同図（ａ）は、販売者が詳細取引情報データを入力する前の入金ウィンドウのｈｔｍｌ言語であり、同図（ｂ）は、矩形領域内に表示されているように、販売者によって追加される詳細取引情報データの入力形式を表示した例であり、同図（ｃ）は、販売者によって詳細データが追加された詳細取引情報データが入力された後の入金ウィンドウのｈｔｍｌ言語である。

「ｗｗｗ．ｅｕｍｍｏｎｅｙ．ｃｏｍ／ｍｃ／ｉｎｄｅｘ．ｊｓｐ？」は、ウェブ環境に表示された入金ウィンドウを購買者システムがクリックするときに実行されるｊｓｐコマンドを示すものであり、「／」は、フィールド区切子であり、フィールド区切子の間に入力される「ｄａｔａ １」、「ｄａｔａ ２」及び「ｄａｔａ ｎ」は、購買者がウェブ環境に表示された入金ウィンドウを押した場合に、取引決済提供システムにおいて生成して提供する金額確定ウィンドウに表示しようとする販売商品に関する情報である。このような詳細取引情報データの入力形式は、取引決済提供システムと販売者との間において事前に約束された形式で入力される必要がある。より具体的には、取引決済提供システムが詳細取引情報データを入力する規則を定め、これを販売者に熟知させる。取引決済提供システムは、詳細取引情報データが入力された後、これを解析し、解析された情報を金額確定ウィンドウに提供する。詳細取引情報データが入力されない場合には、当該データを入力可能な入力フィールドを有する金額確定ウィンドウを購買者に提供する。例えば、図１２の実施形態において、入金ウィンドウをクリックしたときに実行される実行文に対するｈｔｍｌ言語を「ｈｔｔｐ：／／ｗｗｗ．ｅｕｍｍｏｎｅｙ．ｃｏｍ／ｍｃ／ｉｎｄｅｘ．ｊｓｐ？ｍｃ＿ｉｄ＝会員識別ＩＤ／／キックボード」に変更する場合、購買者システムに提供される金額確定ウィンドウには、商品金額を入力可能なフィールドが提供される。図１２の実施形態においては、フィールド区切子として「／」を用い、最初のデータフィールドである「ｄａｔａ １」は価格を表示し、第二のデータフィールドである「ｄａｔａ ２」は商品名を表示する実施形態である。データフィールドの数と属性は、取引決済提供システムが適宜決めるものであるため、特に制限されず、価格と商品名に加えて、多数のデータを表現することが可能であるということはいうまでもない。

購買者システムは、ウェブ環境をサーフィング中に（ｓ５）、購買したい商品を見つけた場合、当該ウェブ環境が提供する文字、チャットまたはウェブ環境に記載の販売者の電話番号などを用いて販売者に購買を要請する（ｓ６）。販売者と当該購買者との間において交渉が円滑に行われて購買者がウェブ環境に表示された入金ウィンドウをクリックすると、取引決済提供システムは、詳細取引情報データを解析し、これを用いて購買者システムに金額確定ウィンドウを提供する（ｓ７、ｓ８、ｓ９）。

金額確定ウィンドウを提供するソースコードの一例を示す。
＜Ａ
ｏｎｆｏｃｕｓ＝ｂｌｕｒ（）
ｈｒｅｆ＝"ｈｔｔｐ：／／ｗｗｗ．ｅｕｍｍｏｎｅｙ．ｃｏｍ／ｍｃ／ｉｎｄｅｘ．ｊｓｐ？ｍｃ＿ｉｄ＝ｉｆ会員識別ＩＤ／20000／キックボードｔａｒｇｅｔ＝＿ｂｌａｎｋ＞
＜／Ａ＞

金額確定ウィンドウ提供ソースコードにおいて、第１行目はグラフィックを考慮してカーソルのフォーカスを無くすことを命じるコマンドであり、第二のｈｒｅｆ文章は、「ｈｔｔｐ：／／ｗｗｗ．ｅｕｍｍｏｎｅｙ．ｃｏｍ／ｍｃ」ディレクトリーの下に保存されている「ｉｎｄｅｘ．ｊｓｐ」というｊｓｐ言語を実行し、当該ｊｓｐ言語を実行するときに会員識別ＩＤ、「ｄａｔａ １（20000）」と「ｄａｔａ ２（キックボード）」を変数（パラメータ）として用いるものである。より正確には、ｈｒｅｆ文章を介してリンクされて実行される実行文が置かれるアドレス「ｈｔｔｐ：／／ｗｗｗ．ｅｕｍｍｏｎｅｙ．ｃｏｍ／ｍｃ／ｉｎｄｅｘ．ｊｓｐ」と、当該実行文を実行するときに用いられる変数を販売者の識別番号、商品価格及び商品名を指定して送る。

取引決済提供システムは、「ｉｎｄｅｘ．ｊｓｐ」文を実行し、販売者の識別番号を用いて販売者を識別し、詳細取引情報データとして入力される商品価格及び商品名を解析し、解析された情報に基づいて、図１３または図１４に示す金額確定ウィンドウ１２０を購買者システムに提供する。

図１３は、購買者が決済提供システムの会員である場合の金額確定ウィンドウの詳細な実施形態を示す図であり、図１４は、購買者が非会員である場合の金額確定ウィンドウの詳細な実施形態を示す図である。図１３と図１４との相違点は、非会員用サービス利用約款を提示する点と、購買者情報入力フィールド１２５が異なる点であることが分かる。

金額確定ウィンドウ１２０は、上位メニュー１２１と、商品情報及び購買者情報を入力するフィールドを提供したり表示したりする手段として、通常購買者システムのディスプレイにポップアップ形式で提供される。上位メニュー１２１には、入金ウィンドウを生成するための「利用タグ」メニューと、当該会員が販売中の商品または購買中の商品を表示するための進行中の取引を表示するための「進行中の取引」メニューと、購買者が入金した金額を引き出すための「出金管理」メニューと、取引が終了された商品取引を表示するための「終了した取引」メニューと、が含まれる。商品情報欄には、入金ウィンドウのデータフィールド（ｄａｔａ １）に当該する「商品金額」と、データフィールド（ｄａｔａ ２）に当該する「商品名」が表示され、購買者が販売者に伝えたい要求事項などを記載するための取引メモ欄１２３が提供される。商品金額の隣には、金額変更ボタン１２４がさらに提供されるが、当該金額変更ボタン１２４を押すと、取引金額を変更することができる。例えば、図１３の実施形態において、キックボード１台の取引金額（商品金額）が50,000ウォンであるが、もし、購買者が２台を購買しようとする場合、購買者は、金額変更ボタン１２４を押して100,000ウォンを選択する。すなわち、金額変更ボタン１２４は、金額確定ウィンドウに提供される商品価格を倍数の金額に増額するためのボタンである。図１３の実施形態の場合、金額変更ボタン１２４を押すと、100,000ウォン、150,000ウォン、…といったように50,000ウォンの倍数だけ価格が変わる。

図２のフローチャートに基づいて説明すると、購買者がＳＴ１２ステップにおいて金額確定ウィンドウを入力すると、確定された金額を基準として、その後のステップが行われる。購買者情報欄には、購買者の名前が表示され、連絡先を記載するようになっている。

図１４は、購買者が取引決済提供システムの非会員である場合に提供される金額確定ウィンドウ１２０の一例である。購買者が取引決済提供システムの会員である場合には、会員識別子（ＩＤ）を用いて購買者を識別することができるが、購買者が取引決済提供システムの非会員である場合には、電話番号または電子メールなどにより非会員を識別することができる。非会員である場合、取引明細を確認するために取引決済提供システムにアクセスするとき、電話番号または電子メールを用いてログインすることができる。なお、非会員である場合、パスワード入力欄とパスワード確認欄を提供することにより、他人に当該情報が表示されるのを防ぐことができる。図１３及び図１４は、単なる例示画面に過ぎず、種々に変更可能であることはいうまでもない。

金額確定ウィンドウ１２０にも、購買者システムには見えないメタ情報として「販売者識別ＩＤ」が関連付けられて保存されている。購買者が必要な情報を全て入力すると（ｓ１０）、金額確定ウィンドウに保存されたメタ情報として保存された「販売者識別ＩＤ」を用いて「商品情報ＤＢ」に保存する（ｓ１１）。次いで、決済提供システムにおいては、「取引金額」及び「取引メモ」というデータを一つの識別子として認識して新たな「販売商品コード」を発行し、当該「販売商品コード」を用いて当該商品に対する決済、配送などの一連の過程を追跡管理することとなる。金額確定ウィンドウ１２０に購買者が入力する「購買者情報」は、当該「販売商品コード」を用いて「商品購買情報ＤＢ」に保存することとなる。今後の決済に対する過程（ｓ１２、ｓ１３、ｓ１４）は、通常のインターネット上の取引決済システムとほとんど同じ方式により行われる。

一方で、既に決済金額を入金完了した購買者が図１１に示す入金ウィンドウ１１１ボタンをさらにクリックした場合、決済後の進行具合（例えば、配送状態など）を確認できるように、図１３及び図１４の金額確定ウィンドウ１２０には、取引確認ボタン１２７をさらに提供している。取引確認ボタン１２７をクリックすると、会員である場合には、会員識別子（会員ＩＤなど）を入力し、非会員である場合、決済時に入力した識別子（電子メールアドレスまたは住民番号など）を入力するように誘導した後、当該購買商品の決済後の進行具合が分かるようになっている。

本発明は種々に変形可能である。例えば、複数の商品が含まれている一つのイメージをウェブ環境に表示し、各々の商品が表示される領域を限定する。ユーザーが限定された領域をマウスでクリックする場合、図１２に示すウェブ環境に表示された入金ウィンドウを消費者がクリックする場合に実行されるコマンドを実行するように変形してもよいことはいうまでもない。図１５は、販売しようとする多数の商品を一つのイメージ上に表現し、当該イメージ上の商品をクリックする場合に金額確定ウィンドウ２０−１、２０−２、…、２０−６が表示される一例を示すものである。図１５においては、図１３及び図１４に示す金額確定ウィンドウを単純化して２０−１、２０−２、…、２０−６の金額確定ウィンドウとして再図示したものである。

この場合、イメージが表示されるウェブ環境のｈｔｍｌでは、図１６に示す流れを実現する必要がある。すなわち、眼鏡（サングラス）領域として限定された領域１をユーザーがクリックする場合、当該眼鏡を購入するための金額確定ウィンドウ２０−１がポップアップウィンドウとして表示され、上着領域として限定された領域２をユーザーがクリックする場合、当該上着を購入するための金額確定ウィンドウ２０−２がポップアップウィンドウとして表示され、自動車領域として限定された領域３をユーザーがクリックする場合、当該自動車を購入するための金額確定ウィンドウ２０−３がポップアップウィンドウとして表示され、ジーンズ領域として限定された領域４をユーザーがクリックする場合、当該ジーンズを購入するための金額確定ウィンドウ２０−４がポップアップウィンドウとして表示され、カバン領域として限定された領域５をユーザーがクリックする場合、当該カバンを購入するための金額確定ウィンドウ２０−５がポップアップウィンドウとして表示され、履物領域として限定された領域６をユーザーがクリックする場合、当該履物を購入するための金額確定ウィンドウ２０−６がポップアップウィンドウとして表示される。図１５及び図１６に示す変形の実施形態に適用する場合、決済手段提供システムからコピーされて提供される入金ウィンドウは、テキスト形式でコピーされ、当該ウェブ環境を訪問した者には表示されずに実行されるコマンドとして保存される必要がある。このため、図１５に示す変形例は、ｈｔｍｌ言語に若干の知識があるユーザーのみが使用可能である。

図１５に示す変形の実施形態は、インターネット網に接続されたウェブ環境を用いて販売者システムと購買者システムとの間において商品取引を行う際に、前記販売者システムと購買者システムとの間において決済手段を提供する取引決済の提供方法であって、販売者を会員として加入させる第１のステップと、前記販売者の会員識別子がメタ情報として含まれるテキスト形式の入金ウィンドウを生成して前記購買者システムのクリップボードに提供する第２のステップと、販売者である会員が前記ウェブ環境に多数の商品が含まれる少なくとも一つのイメージを提供し、前記販売者は多数の商品領域を限定するように前記イメージをいくつかの領域に分割し、前記販売者が分割された領域をクリックした場合、実行される前記入金ウィンドウを保存した後に取引金額を含む詳細取引情報データをさらに入力し、前記購買者が分割された領域をクリックした場合、前記購買者システムに前記詳細取引情報データを含む金額確定ウィンドウを提供する第６のステップを含むことを特徴とする取引決済の提供方法として説明可能である。

本発明は種々の分野に適用可能である。例えば、電子書籍のプレビューにも適用可能である。amazon.comなどにおいては、当該サイトを訪問した者に、書籍の一部について、プレビューサービスを提供している。プレビューサービスとは、書籍を購入する前に購買予定者に当該書籍の一部のページを無料で閲覧可能に提供するものである。ところが、このようなプレビューサービスは、amazon.comサイトを訪問したユーザーにしか提供されていない。このようなプレビューサービスを、当該サイトを訪問した者にしか提供しない理由としてはいろいろが挙げられるが、最も重要な理由は、決済処理が円滑に行われないためである。

図１７は、本発明の入金ウィンドウを書籍のプレビュー機能に適用した一例を示すものである。図１７の（ａ）に示すように、ユーザーが自分のブログなどのウェブ環境にエリス物語という書籍を読んで感動したという読書評を提示し、当該書籍のプレビューアイコン１３０を貼り付ける。プレビューアイコン１３０は、ユーザーが当該アイコンをクリックすると、当該書籍の一部のページをプレビューし、規定されたページ数を超えて読むことを要請する場合、決済手段を提供するアイコンである。

ウェブ環境を訪問した第３のユーザーが当該プレビューアイコン１３０をクリックすると、図１７の（ｂ）及び図１７の（ｃ）に示すように、所定のページがプレビューできるようにプレビューサービスを提供する。第３のユーザーが規定されたページ（図１７においては、１０ページ）を読み終わってから次のページを読みたい場合、図１７の（ｄ）に示すように、本発明に係る入金ウィンドウ１１０を提示する。もちろん、図１７の（ｄ）に示す入金ウィンドウには、ウェブ環境の所有者が貼り付けした後、当該入金ウィンドウのｈｔｍｌ言語を「ｈｔｔｐ：／／ｗｗｗ．ｅｕｍｍｏｎｅｙ．ｃｏｍ／ｍｃ／ｉｎｄｅｘ．ｊｓｐ？ｍｃ＿ｉｄ＝会員識別ＩＤ／１、８００／エリス物語」に修正する必要がある。

以上、本発明の特定の実施形態が説明及び図示されたが、本発明の技術的思想を逸脱しない範囲内において当業者によって種々に変形されて実施される可能性があるということはいうまでもない。このように変形された実施形態は本発明の思想及び範囲から個別的に理解されてはならず、本発明における特許請求の範囲に属すると理解さるべきである。例えば、本発明においてデータベースという名称を使用しているが、システムによっては、データベースではないテーブル形式などとして適用可能であるということはいうまでもない。

Claims (14)

1. インターネットに接続されたウェブサイトを用いて販売者コンピュータと購買者コンピュータとの間で商品取引を行うに当たって、前記販売者コンピュータと購買者コンピュータとの間に決済手段を提供する取引決済提供サーバであって、
   会員識別子がメタ情報として含まれる、販売者に詳細取引情報データを入力させるための第１のユーザインタフェースを生成して前記販売者コンピュータに送信する第１の送信手段と、
   前記販売者コンピュータが前記第１のユーザインタフェースに対応するソースコードをウェブサイトに保存し、前記第１のユーザインタフェースを介して販売金額を含む詳細取引情報データがさらに入力され、前記ウェブサイトに表示された前記第１のユーザインタフェースが前記購買者コンピュータによりクリックされた場合に、詳細取引情報データ及び販売者の会員識別子を含み購買者コンピュータに前記詳細取引情報データを表示させ購買者に購買金額を入力させるための第２のユーザインタフェースを送信する第２の送信手段とを具備し、
   前記第１の送信手段は、前記販売者コンピュータが、販売者の多数の商品の画像を含む１つのイメージから、前記多数の商品に対応する多数の領域を分割して生成し、前記分割された領域が販売者コンピュータにおいてクリックされた場合に前記領域毎の前記第１のユーザインタフェースを送信し、
   前記第２の送信手段は、前記第１のユーザインタフェースを介して販売金額を含む詳細取引情報データが前記販売者コンピュータによりさらに入力され、前記分割された領域が購買者コンピュータにおいてクリックされた場合に、前記購買者コンピュータに前記領域毎の前記第２のユーザインタフェースを送信する
   ことを特徴とする取引決済提供サーバ。
2. 前記購買者コンピュータに送信される前記第２のユーザインタフェースにおいて購買金額を変更可能な金額変更ボタンをさらに提供することを特徴とする請求項１に記載の取引決済提供サーバ。
3. 取引決済提供サーバは、前記第１のユーザインタフェースに対応するソースコードを前記販売者コンピュータのクリップボードにコピーして提供することを特徴とする請求項１に記載の取引決済提供サーバ。
4. 前記詳細取引情報データは、フィールド区切子と、前記区切子の間に入力されるデータと、からなることを特徴とする請求項１に記載の取引決済提供サーバ。
5. 前記第１のユーザインタフェースがイメージ形式で送信される場合、前記イメージのある領域が選択され、これに対応するソースコードが販売者コンピュータのクリップボードにコピーされた後、貼り付けにより前記第１のユーザインタフェースがウェブサイトに表示されることを特徴とする請求項２に記載の取引決済提供サーバ。
6. 前記第１のユーザインタフェースは、会員加入をした販売者が販売する商品の種類によらずに販売者当たりに１つしか発行されないことを特徴とする請求項１に記載の取引決済提供サーバ。
7. 購買金額を自ら入力するフィールドを含む前記第２のユーザインタフェースには、ｈｒｅｆコマンドがメタ情報として含まれることを特徴とする請求項１に記載の取引決済提供サーバ。
8. 購買金額を自ら入力するフィールドを含む前記第２のユーザインタフェースには、リンクされて実行される実行文が置かれるアドレスと、当該実行文を実行するときに用いられる変数としての販売者識別番号とがメタ情報として保存されることを特徴とする請求項１に記載の取引決済提供サーバ。
9. インターネットに接続されたウェブサイトを用いて販売者コンピュータと購買者コンピュータとの間で商品取引を行うに当たって、取引決済提供サーバにより、前記販売者コンピュータと購買者コンピュータとの間に決済手段を提供する取引決済提供方法であって、
   前記取引決済提供サーバの送信手段が、会員ごとに固有の会員識別子を含む、販売者に詳細取引情報データを入力させるための第１のユーザインタフェースを生成して送信する第１のステップと、
   前記販売者コンピュータの制御手段により、前記第１のユーザインタフェースに対応するソースコードがコピーされて前記第１のユーザインタフェースがウェブサイトに表示される第２のステップと、
   前記販売者コンピュータの制御手段により、販売者の多数の商品の画像を含む１つのイメージから、前記多数の商品に対応する多数の領域が分割されて生成される第３のステップと、
   前記分割された領域が販売者コンピュータにおいてクリックされた場合に表示される前記第１のユーザインタフェースを介して販売金額を含む詳細取引情報データが前記販売者コンピュータの入力手段によりさらに入力される第４のステップと、
   前記分割された領域が購買者コンピュータにおいてクリックされた場合に、前記取引決済提供サーバの送信手段が、前記購買者コンピュータに、前記詳細取引情報データ及び販売者の会員識別子を含み購買者コンピュータに前記詳細取引情報データを表示させ購買者に前記領域毎の商品の購買金額を入力させるための第２のユーザインタフェースを送信する第５のステップと
   を含むことを特徴とする取引決済の提供方法。
10. 前記第１のステップにおいて前記販売者コンピュータに送信される前記第１のユーザインタフェースは、少なくともイメージ形式、ＨＴＭＬ形式及びＵＲＬ形式のうちいずれかであることを特徴とする請求項９に記載の取引決済の提供方法。
11. 前記第２のステップにおいて送信される第１のユーザインタフェースは、販売者が販売する商品の種類によらずに販売者当たりに１つしか発行されないことを特徴とする請求項９に記載の取引決済の提供方法。
12. 前記第５のステップにおいて送信される前記第２のユーザインタフェースには、ｈｒｅｆコマンドがメタ情報として含まれることを特徴とする請求項９に記載の取引決済の提供方法。
13. 前記第５のステップにおいて提供される前記第２のユーザインタフェースには、リンクされて実行される実行文が置かれるアドレスと、当該実行文を実行するときに用いられる変数としての販売者識別番号とがメタ情報として含まれることを特徴とする請求項９に記載の取引決済の提供方法。
14. 購買者コンピュータの入力手段から前記第２のユーザインタフェースへの入力が実行される第６のステップと、
    前記取引決済提供サーバの記憶手段が、前記第６のステップ後に販売者が販売しようとする商品または販売済みの商品に関する情報を保存する第７のステップと、
    をさらに含むことを特徴とする請求項９に記載の取引決済の提供方法。