JP2004348269A - 情報処理装置、情報処理方法、プログラムおよび記憶媒体 - Google Patents
情報処理装置、情報処理方法、プログラムおよび記憶媒体 Download PDFInfo
- Publication number
- JP2004348269A JP2004348269A JP2003142407A JP2003142407A JP2004348269A JP 2004348269 A JP2004348269 A JP 2004348269A JP 2003142407 A JP2003142407 A JP 2003142407A JP 2003142407 A JP2003142407 A JP 2003142407A JP 2004348269 A JP2004348269 A JP 2004348269A
- Authority
- JP
- Japan
- Prior art keywords
- order
- information
- settlement
- payment
- orderer
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
- 238000000034 method Methods 0.000 title claims description 96
- 230000010365 information processing Effects 0.000 title claims description 19
- 238000012545 processing Methods 0.000 claims description 73
- 230000008569 process Effects 0.000 claims description 39
- 238000003672 processing method Methods 0.000 claims description 7
- 230000000717 retained effect Effects 0.000 abstract 1
- 238000012790 confirmation Methods 0.000 description 36
- 238000007726 management method Methods 0.000 description 27
- 238000010586 diagram Methods 0.000 description 17
- 230000006870 function Effects 0.000 description 12
- 230000007774 longterm Effects 0.000 description 8
- 230000009286 beneficial effect Effects 0.000 description 7
- 230000004044 response Effects 0.000 description 7
- 230000005540 biological transmission Effects 0.000 description 3
- 230000008859 change Effects 0.000 description 3
- 238000004891 communication Methods 0.000 description 3
- 230000006399 behavior Effects 0.000 description 2
- 238000011161 development Methods 0.000 description 2
- 230000005764 inhibitory process Effects 0.000 description 2
- 125000002066 L-histidyl group Chemical group [H]N1C([H])=NC(C([H])([H])[C@](C(=O)[*])([H])N([H])[H])=C1[H] 0.000 description 1
- 230000015556 catabolic process Effects 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 238000007429 general method Methods 0.000 description 1
- 230000007246 mechanism Effects 0.000 description 1
- 238000012544 monitoring process Methods 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 230000007704 transition Effects 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q30/00—Commerce
- G06Q30/06—Buying, selling or leasing transactions
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q30/00—Commerce
- G06Q30/06—Buying, selling or leasing transactions
- G06Q30/0601—Electronic shopping [e-shopping]
- G06Q30/0633—Lists, e.g. purchase orders, compilation or processing
- G06Q30/0635—Processing of requisition or of purchase orders
Landscapes
- Business, Economics & Management (AREA)
- Accounting & Taxation (AREA)
- Finance (AREA)
- Development Economics (AREA)
- Economics (AREA)
- Marketing (AREA)
- Strategic Management (AREA)
- Physics & Mathematics (AREA)
- General Business, Economics & Management (AREA)
- General Physics & Mathematics (AREA)
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
Abstract
【課題】顧客を相手とするオンライン販売システムにおいて、同一顧客からの重複注文をチェックする。
【解決手段】申し込み受付手段Ｓ２１０は、顧客の注文者端末Ｓ２００から商品等の注文を受け付けると、重複判断手段Ｓ２６０により、その顧客が、重複注文を認めていない商品等に関して、あるいは、重複注文するとその顧客が不利益を被るであろう商品等に関して、重複した注文を申し込んでいないか判定する。判定は、注文時に入力された商品コード等に基づいて、情報保持手段Ｓ２７０に保持されたテーブルを参照して行われる。たとえば、注文された商品コードの商品について、重複受注が禁止された商品である旨が商品情報として登録されていれば、受注できない旨を顧客に通知する。
【選択図】図１
【解決手段】申し込み受付手段Ｓ２１０は、顧客の注文者端末Ｓ２００から商品等の注文を受け付けると、重複判断手段Ｓ２６０により、その顧客が、重複注文を認めていない商品等に関して、あるいは、重複注文するとその顧客が不利益を被るであろう商品等に関して、重複した注文を申し込んでいないか判定する。判定は、注文時に入力された商品コード等に基づいて、情報保持手段Ｓ２７０に保持されたテーブルを参照して行われる。たとえば、注文された商品コードの商品について、重複受注が禁止された商品である旨が商品情報として登録されていれば、受注できない旨を顧客に通知する。
【選択図】図１
Description
【０００１】
【発明の属する技術分野】
本発明は情報処理装置、情報処理方法、及びそれをコンピュータで実施するためのプログラム及びそのプログラムをコンピュータ可読に記録した記憶媒体に関し、特に、ネットワークを通して顧客からの注文を重複なく受け付けることができるものである。
【０００２】
【従来の技術】
近年、通信インフラの整備及び情報通信技術の発展により、インターネットを利用し、ＷＥＢページを閲覧した人が商品やサービスを注文することが可能となっている。このようなインターネットを通した商取引の決済手段としてはクレジットカード決済、コンビニエンスストア決済、電子マネーなどがあり、一つの販売サイトにおいて複数の決済手段がサポートされていることも多い（例えば、非特許文献１参照。）。
【０００３】
これら決済手段を提供する決済業者の中には、決済を受け付けるＷＥＢページを提供しているものもある。決済を受け付けるＷＥＢページを使用することにより、商品やサービスを注文するユーザは決済業者に直接決済情報を通知でき、商品やサービスの販売者にクレジットカード番号など決済情報を知られないで済む。
【０００４】
従来は商品やサービスの販売者が決済情報を受付け、それを決済業者に通知する方法が一般的であった。しかし購入者にとっては決済情報が第三者に漏洩しづらく、販売者にとっては漏洩の責任を問われる可能性が少ないので、最近は決済業者が提供するＷＥＢページを使用するケースが増えている。
【０００５】
決済業者が提供するＷＥＢページを使用して決済を行う場合は、通常以下のような過程を踏む。まず、販売する商品やサービスの説明を行うＷＥＢページを表示し、次に注文者の氏名などを入力するＷＥＢページを表示する。注文者がここで決済を行う旨のボタンなどを押下すると、決済業者の提供するＷＥＢページに遷移し、その際に販売者から決済業者に決済に必要な商品やサービスの金額などの情報などが引き渡される。注文者は決済業者の提供するＷＥＢページにおいて、クレジットカード番号など決済に必要な情報を入力すると、決済業者から販売者に対し、決済が正常に完了したかどうかが通知され、販売者によってこの決済の結果と注文の内容などを含むＷＥＢページが表示される。
【０００６】
一方、決済業者の提供するＷＥＢページを使用しない場合は、以下のような過程が一般的である。まず、販売する商品やサービスの説明を行うＷＥＢページを表示し、次に注文者の氏名と共にクレジットカード番号など決済に必要な情報を入力するＷＥＢページを表示する。注文者がここで決済を行う旨のボタンなどを押下すると、販売者から決済業者に対し金額やクレジットカード番号などの情報などが引き渡される。これに対し、決済業者は販売者に、決済が正常に完了したかどうかが通知し、販売者によってこの決済の結果と注文の内容などを含むＷＥＢページが表示される（例えば、非特許文献２参照）。
【０００７】
【非特許文献１】
インターネットホームページ「ｈｔｔｐ：／／ｗｗｗ．ｄｉｇｉｐｒｉ．ｃｏ．ｊｐ／ｄ／ｐａｙｍｅｎｔ．ｈｔｍｌ」、デジプリ株式会社、出願日（２００３年５月２０日）付け
【非特許文献２】
インターネットホームページ「ｈｔｔｐ：／／ｗｗｗ．ａｔ−ｌｉｎｋ．ａｄ．ｊｐ／ｔｏｐｉｃｓ／ｔ７４．ｈｔｍｌ」、三井住友ＶＩＳＡ、出願日（２００３年５月２０日）付け
【０００８】
【発明が解決しようとする課題】
このようにインターネットを利用した商取引ではネットワークを通した情報のやり取りの中で、商品の特定・注文者の特定・決済方法の特定・申し込みなどが行われるので、途中で作業が終わったり、注文者は一回申し込んだつもりが複数回申し込まれていたりといった問題が生じやすい。決済業者の提供するＷＥＢページを使用すると、他のサイトとの情報のやりとりが発生するため、さらにこのような問題が生じやすい。
【０００９】
このような問題は、有体物の販売の時も問題にはなるが、一定期間特定サービスの提供に対して課金するような場合、同一注文者に同一内容の申し込みを禁止する場合もありうるので、より大きな問題となり得る。
【００１０】
また前述したように一つの販売サイトにおいて、複数の決済システムをサポートすることが多いので、同一ユーザが同一商品を申し込む際に異なる決済システムを使用し決済することも考えられる。このため同一注文者に同一内容の申し込みを禁止する場合は、複数の決済システムに渡ることを考慮する必要がある。
【００１１】
本発明は上記従来例に鑑みてなされたもので、オンライン販売において重複注文の有無を判定し、重複注文ができない旨、あるいは重複する注文が既にされている旨を注文者に通知し、重複注文を抑制した時に発生する返金など運用上の問題を解決しサイト運用者の効率を高めることを可能とする情報処理装置等を提供することを目的とする。
【００１２】
【課題を解決するための手段】
上記目的を達成するために本発明は以下の構成を有する。
（１）情報処理装置であって、顧客からの注文を受け付ける注文受付手段と、
前記顧客が前記注文以外に同一種の注文を行っていないかを判断する重複注文判断手段と、
前記重複注文判断手段の判断結果を顧客に通知するよう制御する注文受付通知手段と、
前記注文を受付できると判定された注文についての情報を保持する情報保持手段とを有する。
（２）さらに好ましくは、外部決済システムへの情報を提供する決済情報提供手段と、
前記外部決済システムからの情報を受け付ける決済情報受付手段とをさらに備え、
前記注文受付可否表示手段はさらに、前記決済情報受付手段により受け取った情報に基づいて、前記注文の受け付けの可否を顧客に通知するよう制御し、前記情報保持手段はさらに前記外部決済情報も保持する。
（３）さらに好ましくは、前記決済情報提供手段及び決済情報受付手段は、前記注文受付手段により受け付けられた決済方法に応じた決済システムに対して情報の提供及び情報の受付を行う。
（４）さらに好ましくは、前記外部決済システムからの情報を前記決済情報受付手段が受け付けることを失敗した場合に、当該注文に対する決済後の処理を再開する注文処理再開手段をさらに有し、
前記注文処理再開手段により処理の再開が行われる際に、前記重複注文判断手段によって注文のチェックを判断し、判断結果を管理者に通知するための管理者用注文受付可否通知手段をさらに有する。
（５）さらに好ましくは、前記注文処理再開手段により処理の再開が行われた際に、前記重複注文判断手段によって注文できないと判断された場合に、前記外部決済システムに対して当該注文の決済のキャンセル処理を要求するキャンセル情報提供手段をさらに有する。
（６）さらに好ましくは、前記注文処理再開手段により処理の再開が行われた際に、前記重複注文判断手段によって注文できないと判断された場合に、管理者に対して前記外部決済システムに対してキャンセル処理を要求するよう通知するキャンセル情報通知手段をさらに有する。
（７）さらに好ましくは、前記重複注文判断手段の判断結果に基づいて前記注文の受け付けの可否を表示する管理者用注文受付可否表示手段をさらに有する。
【００１３】
【発明の実施の形態】
以下に、図面を参照して、本発明の好適な実施形態を例示的に詳しく説明する。尚、本実施形態に記載されている構成要素の相対配置、表示画面等は、特に特定的な記載がない限りは、本発明の範囲をそれらのみに限定する趣旨のものではない。ネットワークを使用するサービスにおいての共通の課題を解決する発明であり、これらも本発明に含まれる。
【００１４】
＜本実施形態の情報処理システムの構成＞
本実施例の目的は、決済システムとの連携で、ネットワークを通じて顧客からの商品・サービスの申し込みを受ける際に、その商品・サービスが同一人からの複数回の申し込みを特定条件下で禁止すべき場合に、同一商品・サービスの申し込みを拒絶し、重複注文禁止時に発生する返金など運用上の問題を解決する情報処理システムを提供することである。本発明の一実施形態として、商品・サービスを販売する場合について説明する。
【００１５】
図１は、本実施形態におけるサービスを構成するシステム全体Ｓ２００（以下では販売システムと呼ぶ）の構成、および販売システムＳ２００の運用を受けもつ管理者用の管理者端末Ｓ５００、販売システムＳ２００の顧客である注文者が利用する注文者端末Ｓ１００、注文者が販売システムＳ２００との決済に利用する決済システムの運営会社Ｓ４００の関連と情報のやり取りについて表したものである。
【００１６】
なお、図１においては各処理部の情報や要求・応答等のメッセージの交換の全てを表しているのではない。情報保持手段Ｓ２７０からの読み出しについてはそれを記述すると煩雑になるので省略し、また、そこに格納されたデータベースの更新についても全てを記載せず主たるものに限り記載されている。
【００１７】
図１では、決済システム運営会社を決済システムＳ４１０、決済システム管理者Ｓ４２０、決済システム管理用ツールＳ４３０の３つで構成されるとしているが、決済システム管理用ツールＳ４３０は必須ではない。決済システム管理用ツールＳ４３０は、決済システムＳ４１０において行われた決済の状態を一定期間たとえば１日について、後述するオーダ番号などにしたがって表示する。表示される情報はたとえば決済完了したオーダ番号のみを保存するようにしてもよいし、決済完了したオーダ番号及び中断されたオーダ番号を保存するようにしてもよい。いずれにしても、販売システムＳ２００において成立していない販売契約であるにもかかわらず、それに対応する決済が行われていないか否かを判定するために参照される情報が決済システム管理用ツールＳ４３０により表示される。この情報は、決済システムＳ４１０により提供される。
【００１８】
また図１では便宜的に決済システム運営会社Ｓ４００について一つしか表記していないが、決済システム運営会社Ｓ４００は複数あっても構わない。以下では、決済システム運営会社Ｓ４００が二つある条件の下で書かれている。つまり図１の決済システム運営会社Ｓ４００は二つのうちの一つを示している。なお現実の会社が二つ以上の決済システムを運営している場合でも、決済システム運営会社Ｓ４００が二つ以上あるのと同視すればよい。つまり決済システム運営会社Ｓ４００は、現実の単一の会社をさすのではなく、単一の決済システムＳ４１０とその運営者である決済システム管理者Ｓ４２０、決済システムの管理用ツールである決済システム管理用ツールＳ４３０を包含する概念である。
【００１９】
さらに図１では決済システム運営会社Ｓ４００が販売システムＳ２００の外にあるように記述しているが、販売システムとＳ２００と決済システムＳ４１０および決済システム管理用ツールＳ４３０が同じサイトに存在することを排除する意図ではない。決済システムＳ４１０や決済システム管理用ツールＳ４３０が使用するデータが情報保持手段Ｓ２７０上に存在することも可能である。
【００２０】
なお本実施例では、クレジットカード決済などのように決済予約という概念がなく現金等の払い込みを要せずして決済が完了する決済方式においては、決済のキャンセルが何らかの方法で可能であることを前提としている。つまり決済システムＳ４１０、決済システム管理用ツールＳ４３０、決済システム管理者Ｓ４２０のいずれかによってキャンセルが可能である。
【００２１】
また、図１において注文者端末Ｓ１００とは、注文者が利用するコンピュータ等の端末装置である。注文者のコンピュータは、販売システムＳ２００及び決済システムＳ４００と通信可能である。具体的には、注文者端末Ｓ１００はたとえばＴＣＰ／ＩＰプロトコルスタックおよびＨＴＴＰクライアントプログラム（ウェブブラウザ）実装し、そのウェブブラウザを注文者との間のユーザインターフェースとして利用する。また注文者端末Ｓ１００のウェブブラウザは、販売システムＳ１００と決済システムＳ４１０との間の情報の中継を行う場合もある。
【００２２】
また、管理者用端末Ｓ５００も注文者用端末Ｓ１００と同様に管理者が利用するコンピュータ等の端末装置である。ただし、管理者用端末Ｓ５００には、販売システムＳ２００の一部（管理用手段Ｓ３００、注文再開手段Ｓ３１０、管理者用注文受付可否表示手段Ｓ３２０、キャンセル情報提供手段Ｓ３３０、キャンセル情報通知手段Ｓ３４０）を含む構成を有していても良い。この場合には、管理者端末Ｓ５００も販売システムＳ２００の一部を構成することになる。さらに管理者端末Ｓ５００は独立したコンピュータにより実現されなくとも良く、販売システムＳ２００に属するサーバコンピュータにより実現することもできる。しかしながら、本実施形態では、管理者は管理者端末Ｓ５００を介して販売システムＳ２００にアクセスするものとして説明する。
【００２３】
図１の矢印は注文者Ｓ１００、販売システムＳ２００、決済システム運営会社Ｓ４００、管理者Ｓ５００間の情報のやり取りを示す。
【００２４】
図１に示すように、販売システムＳ２００は、申し込み受付手段Ｓ２１０、注文受付可否表示手段Ｓ２２０、注文処理手段Ｓ２３０、決済情報受付手段Ｓ２４０、決済情報提供手段Ｓ２５０、重複注文判断手段Ｓ２６０、情報保持手段Ｓ２７０、管理用手段Ｓ３００、注文再開手段Ｓ３１０、管理者用注文受付可否表示手段Ｓ３２０、キャンセル情報提供手段Ｓ３３０、キャンセル情報通知手段Ｓ３４０からなる。
【００２５】
販売システムＳ２００内の各手段は、メモリ上に存在するプログラムであって、販売システムＳ２００が存在するサーバシステム上に存在する。本実施形態はインターネットを介しての例であり、サーバシステムは、イーサネット（登録商標）等のネットワークでつながれたコンピュータにより実現される。販売システムＳ２００内の各手段は、互いに異なるコンピュータに存在する場合にはその間における情報のやり取りをこのネットワークを介して行い、また、同一のコンピュータに存在する場合には、コンピュータ上のメモリやディスク等を介したプロセス間通信などとして行う。販売システムＳ２００内の各手段は、概念としてＨＴＴＰサーバやそれより低位のネットワークプロトコル用サーバを含み得るが、サーバシステムが備えるＨＴＴＰサーバやそれより低位のネットワークプロトコル用サーバを利用しても良い。また情報保持手段Ｓ２７０は後述するデータベースを保持し、要求に応じてデータの検索や更新等を行う。データベースとしては本実施形態ではリレーショナルデータベースを使用しているが、リレーショナルデータベースでなければならないわけではない。情報保持手段Ｓ２７０は、データを磁気ディスク等のランダムアクセス可能な大容量記憶媒体上に保管する。ディスクは、情報保持手段Ｓ２７０が存在するサーバ上のディスクでも、ネットワーク上に存在する別のサーバのディスクでも構わない。なお販売システムＳ２００内の各手段は、物理的に異なるサーバ上に存在しても良いし、同一のサーバ上に存在しても良い。
【００２６】
注文処理手段Ｓ２３０は注文者Ｓ１００が申し込んだ商品・サービスによって挙動を異にする。注文者Ｓ１００が申し込んだ商品が販売システムＳ２００を運営する業者が直接扱うものであったら、注文処理手段Ｓ２３０は、担当者へのメールが送付されるものや担当者が使用するツールへの表示などを行う。また第三者の扱う商品だったら第三者へのＦＡＸやメールを送付し、または第三者が商品を作成するのに必要なデータの送信を行う。注文者Ｓ１００が申し込んだサービスが、販売システムＳ２００が存在するサイト上で扱われているものなら、注文処理Ｓ２３０は、注文者Ｓ１００に当該サービスを使用可能にする処理を行う。本実施形態は、特定の商品・サービスを目的とするものではないので、注文処理手段Ｓ２３０についての制約はない。
【００２７】
＜本実施形態の注文者からの利用＞
次に本実施形態を注文者から利用した際の振る舞いについて説明する。図２から図７は、注文者が利用する注文者端末Ｓ１００のディスプレイに表示される申し込み画面Ｕ０１００、申込者情報入力画面Ｕ０２００、配送先情報入力画面Ｕ０３００、クレジット情報入力画面Ｕ０４００、注文結果表示画面（１）Ｕ０５００、注文結果表示画面（２）Ｕ０６００を示している。注文者は、販売システムＳ２００と決済システムＳ４１０により提供されて注文者端末Ｓ１００のディスプレイに表示される画面Ｕ０１００、Ｕ０２００、Ｕ０３００、Ｕ０４００、Ｕ０５００、Ｕ０６００を介して、販売者システムＳ２００および決済システムＳ４１０から情報を獲得し、あるいは情報を入力して、商品・サービスを購入する。
【００２８】
さらに、図１中の矢印は情報の流れ（要求や応答等の命令、およびそれらに付随するデータ等の送信や受信）を表しているが、以下の説明においては、情報の流れを生じさせるきっかけとなる操作や処理を、それらにより引き起こされる情報の流れに付された参照番号によって示している。例えば「申し込みボタンＵ０１１０を押下する（図１：ステップｃ０１）。」との記載は、操作者が注文者端末Ｓ１００の画面に表示されたソフトウエアボタンを押すという操作を行うことで、注文者端末Ｓ１００から販売システムＳ２００のサーバコンピュータに対して渡される所定の情報等の流れが、図１のステップｃ０１において発生することを示す。
【００２９】
なお、この説明は操作者を含めてシステム全体としてどのように動作するかの説明を行うもので、販売システムにおけるサーバコンピュータの動作、特に利用するデータの構造や内容、処理手順や各プログラムモジュール（図１の手段）の間で交換される情報の内容等については、図１７（図１７Ａ及び図１７Ｂの総称）以降の流れ図を参照して詳しく説明する。
【００３０】
図２は商品・サービス申し込み作業の開始の申し込み画面Ｕ０１００である。申し込みメッセージＵ０１０１は便宜的に一行で表示しているが、商品・サービスの説明などどのような表記があっても構わない。また申し込みボタンＵ０１１０は商品・サービスの申し込みを行うためのボタンであるが、この画面上に二個以上存在しても構わない。
【００３１】
まず注文者は注文者端末Ｓ１００を操作し、たとえば販売システムＳ２００が提供するＨＴＴＰサーバにアクセスして商品等の注文を受け付ける画面を表示させ、その画面上に表示された商品等および数量等を選択して発注する旨の指示をする。それに応じて図２の画面が注文者端末Ｓ１００に表示される。
【００３２】
図２の申し込みボタンＵ０１１０を押下する（図１：ステップｃ０１）と、当該注文と重複する既に有効な注文が行われているかが調べられ（図１：ステップｃ０２）、既に有効な注文が存在する時は図７に示される注文結果表示画面Ｕ０６００が注文者端末Ｓ１００の画面上に表示される（図１：ステップｉ０１）。既に有効な注文が存在するかどうかの判断は、同一注文者が同一物の購入を禁じられている場合や、同一注文者は同一サービスを二つ以上契約することが無駄な場合などを基準に判断されるのが基本となる。このように同一の商品・サービスを購入することができない、もしくは許されない時は、注文結果表示画面Ｕ０６００には確認ボタンＵ０６１１は表示されない。この重複注文の判定は、具体的には情報保持手段Ｓ２７０のデータベースに格納された注文情報テーブル等に基づいて判定される。詳しいデータ構造や処理の手順は後述する。
【００３３】
同一の商品・サービスを購入することが不利益であることが考えられる場合、または確認をとることが注文者にとって有益な場合は、確認ボタンＵ０６１１の表示された注文結果表示画面Ｕ０６００が注文者端末Ｓ１００に表示される。同一商品・サービスを購入することが禁止されていないし注文者が不利益をこうむる可能性もない商品について注文された場合には、ステップｃ０２の重複注文のチェック自体が行われない。
【００３４】
注文者が注文結果表示画面Ｕ０６００の確認ボタンＵ０６１１を押下（図１：ステップｉ０２）した時、または同一商品・サービスを購入することが禁止されていないし注文者が不利益をこうむる可能性もない商品について申し込み画面Ｕ０１００の申し込みボタンＵ０１１０を押下（図１：ステップｃ０１）した時、図３に示す画面Ｕ０２００または図４に示す画面Ｕ０３００が表示される（図１：ステップｃ０３）。配送先が必要とならない場合は注文者情報入力画面Ｕ０２００が表示され、配送先が必要とされる場合は配送先情報入力画面Ｕ０３００が表示される。注文者が自分の情報を入力欄Ｕ０２０１〜Ｕ０２１０、または入力欄Ｕ０３０１〜Ｕ０３１０および入力欄Ｕ０３２０〜Ｕ０３２９に記入する。さらに決済方法としてラジオボタンＵ０２１１またはＵ０２１２、ラジオボタンＵ０３３０またはＵ０３３１を選択する。本実施形態では決済方法として２つの選択肢を表示しているが、決済方法は２つに限定されるわけではない。キャンセルボタンＵ０２２０またはＵ０３４０を押下すると、申し込み画面Ｕ０１００が表示され、商品・サービス申し込み作業が中断される。
【００３５】
ＯＫボタンＵ０２２１またはＵ０３４１を押下する（図１：ステップｃ０４）と、販売者システムＳ２００において、再度当該注文者により既に有効な注文が行われているかを調べ（図１：ステップｃ０５）、既に有効な注文が存在する時は図７に示される注文結果の表示画面Ｕ０６００が表示される（図１：ステップｉ０１）。既に有効な注文が存在するかどうかは、同一注文者が同一物の購入を禁じられている場合や同一注文者は同一サービスを二つ以上契約することが無駄な場合などに判断されるのが基本となる。このように同一の商品・サービスを購入することができない、もしくは許されない時は、注文結果表示画面Ｕ０６００に確認ボタンＵ０６１１は表示されない。
【００３６】
同一の商品・サービスを購入することが不利益であることが考えられる場合、または確認をとることが注文者にとって有益な場合は、確認ボタンＵ０６１１の表示された注文結果表示画面Ｕ０６００が注文者端末Ｓ１００に表示される。同一商品・サービスを重ねて購入することが禁止されていないし注文者が不利益をこうむる可能性もない商品については、ステップｃ０５の重複注文のチェック自体が行われない。また、同一の商品・サービスを購入することが不利益であることが考えられる場合やまたは確認をとることが注文者にとって有益な場合であっても、ステップｃ０２の段階で一度確認ボタンＵ０６１１を押下した場合にもステップｃ０５の重複注文のチェック自体が行われない。
【００３７】
注文結果表示画面Ｕ０６００の確認ボタンＵ０６１１を押下した（図１：ステップｉ０２）時、または、同一商品・サービスを購入することが禁止されていないし注文者が不利益をこうむる可能性もない商品かそのような商品でも注文者による了承を受けた場合（この画面操作に先行する重複注文の確認の際にＵ０６１１を押下していた場合）で注文者情報入力画面Ｕ０２００のＯＫボタンＵ０２２１または配送先情報入力画面Ｕ０３００のＯＫボタンＵ０３４１を押下（図１：ステップｃ０４）した時には、ラジオボタンＵ０２１１またはＵ０２１２、ラジオボタンＵ０３３０またはＵ０３３１で選択された決済システム、本例では決済システムＳ４１０に決済に必要な情報が渡され（図１：ステップｃ０８）、図５に示すカード会社のクレジット情報入力画面Ｕ０４００が注文者端末Ｓ１００に表示される（図１：ステップｃ０９）。注文者情報入力画面Ｕ０２００または配送先情報入力画面Ｕ０３００のラジオボタンは、その販売システムＳ２００から利用可能な決済システムすべてについて表示される。あるいは利用者毎に利用可能な決済システムが表示されるものであっても良い。
【００３８】
クレジット情報入力画面Ｕ０４００は決済システムＳ４１０がクレジットカードの決済を目的とするものの場合であり、画面Ｕ０４００は決済システム運営会社Ｓ４００（この場合はクレジットカード会社）の決済システム（具体的にはそのサーバコンピュータ）が注文者端末Ｓ１００に対して提供するものである。入力欄Ｕ０４０１〜Ｕ０４０３に注文者の所有するクレジットカードの番号と有効期限とを入力する。クレジットカード決済のように注文者が個人を特定する情報や注文者の支払能力を示す情報（この場合はクレジットカード番号）を入力する必要がないなら画面Ｕ０４００は必要ない。例えば、注文者が直接コンビニエンスストアで入金するコンビニエンスストア決済では画面Ｕ０４００は必要ない。画面Ｕ０４００にあたる画面での入力が必要ない場合は、ＯＫボタンＵ０２２１またはＵ０３４１を押下する（図１：ステップｃ０４）と、図６の注文結果表示画面Ｕ０５００または図７の注文結果表示画面Ｕ０６００が表示される（図１：ステップｃ１５、ｉ０４）。また個人を特定する情報や注文者の支払能力を示す情報の入力が必要な場合は、その決済システムＳ４１０が必要とする情報の入力がクレジット情報入力画面Ｕ０４００と同じように求められる。本実施形態は、特定の決済システムを対象としたものではないので、画面Ｕ０４００に関しての制約はない。
【００３９】
クレジット情報入力画面Ｕ０４００に相当する画面が存在しない場合で、注文者情報入力画面におけるＯＫボタンＵ０２２１または配送先情報入力画面におけるＯＫボタンＵ０３４１を押下（図１：ステップｃ０４）するか、またはクレジット情報入力画面Ｕ０４００に相当する画面においてＯＫボタンＵ０４１０を押下（図１：ステップｃ１０）すると、販売システムＳ２００は、再度当該注文者について既に有効な注文が行われているかを調べる（図１：ステップｃ１２）。既に有効な注文が存在する時は、図７に示される注文結果表示画面Ｕ０６００が注文者端末Ｓ１００に表示される（図１：ステップｉ０４）。既に有効な注文が存在するかどうかは、同一注文者が同一物の購入を禁じられている場合や同一注文者は同一サービスを二つ以上契約することが無駄な場合などに判断されるのが基本となる。このように同一の商品・サービスを購入することができない時、もしくは許されない時は、注文結果表示画面Ｕ０６００に確認ボタンＵ０６１１は表示されない。
【００４０】
同一の商品・サービスを購入することが不利益であることが考えられる場合、または確認をとることが注文者にとって有益な場合は、確認ボタンＵ０６１１の表示された注文結果表示画面Ｕ０６００が注文者端末Ｓ１００に表示される。一方、同一商品・サービスを購入することが禁止されていないし注文者が不利益をこうむる可能性もない商品についてはステップｃ０１２の重複注文のチェック自体が行われない。また、同一の商品・サービスを購入することが不利益であることが考えられる場合かまたは確認をとることが注文者１００にとって有益な場合であっても、ステップｃ０２またはｃ０５の段階で一度確認ボタンＵ０６１１を押下した場合にもステップｃ０１２の重複注文のチェック自体が行われない。
【００４１】
注文結果表示画面Ｕ０６００の確認ボタンＵ０６１１を押下（図１：ステップｉ０５）したとき、または同一商品・サービスを購入することが禁止されていないし注文者が不利益をこうむる可能性もない商品かそのような商品でも注文者による了承を受けた場合でかつ決済システムＳ４１０が独自の画面を持たない場合で画面Ｕ０２００のＯＫボタンＵ０２２１または画面Ｕ０３００のＯＫボタンＵ０３４１を押下（図１：ステップｃ０４）した時、または同一商品・サービスを購入することが禁止されていないし注文者が不利益をこうむる可能性もない商品かそのような商品でも注文者による了承を受けた場合でかつ決済システムＳ４１０が独自の画面を持つ場合でクレジット情報入力画面Ｕ０４００のＯＫボタンＵ０４１０を押下（図１：ステップｃ１０）した時、図６の注文結果表示画面Ｕ０５００が表示される（図１：ステップｃ１５）。注文結果表示画面Ｕ０５００では、決済システムＳ４１０からもたらされる（図１：ステップｃ１１）決済が成立したか否かの情報をもとに、メッセージＵ０５０１において注文が正常に受け付けられたかどうかが表示される。オーダ番号Ｕ０５０２には、受け付けられた、または受け付けられなかった注文の情報が書かれている。例としてオーダ番号を表示しているがより詳しい情報を表示しても構わない。ＯＫボタンＵ０５１０を押下すると、申し込み画面Ｕ０１００が表示され、再度別の商品サービスの注文をすることが可能となる。
【００４２】
以上のようにして、注文者は所望の商品等を注文できると共に、重複して注文しても利益がないであろう商品の重複注文について注意を喚起されるため、重複した購入を防止できる。また、同一人に対する重複的な販売を制限している商品等に関して、その制限にしたがって販売を行うことができる。
【００４３】
＜本実施形態の管理者からの利用＞
次に本実施形態を管理者端末Ｓ５００から利用した際の振る舞いについて説明する。図８から図１０は管理者端末Ｓ５００に表示されるオーダ一覧画面Ｕ０７００、オーダ詳細画面Ｕ０８００、再開結果画面Ｕ０９００を示している。管理者は、管理者端末Ｓ５００に表示されるオーダ一覧画面Ｕ０７００、オーダ詳細画面Ｕ０８００、再開結果画面Ｕ０９００を使用して注文の処理状況を調べ、注文再開の処理ができる。
【００４４】
注文再開の処理とは、決済システムＳ４１０側の情報による決済は正常に完了しているのにも関わらず、情報保持手段Ｓ２７０が保持する注文情報テーブル（図１１に示す。）に含まれる当該注文の状態が完了していないことを示している時、管理者端末Ｓ５００によって行われる処理である。注文者からの注文過程において、決済情報提供手段Ｓ２５０によって決済システムＳ４１０に決済に必要な情報が渡されて（図１のステップｃ０８）、決済システム運営会社での処理に移ってから何らかの障害が起こる場合もありえる。そのような障害によって決済システムＳ４１０から決済が成立したか否かの情報（ステップｃ１１）が販売システムＳ２００にもたらされなかった時は、販売システムＳ２００からは、注文者が端末Ｓ１００上でクレジット情報入力画面Ｕ０４００を自ら閉じた時との区別がつかない。
【００４５】
しかしながら、これら２つの場合は以下の点において相違している。注文者が端末Ｓ１００上でクレジット情報入力画面Ｕ０４００を自ら閉じた場合には、販売システムＳ２００において当該注文は中止されており販売契約は成立していない。そのために、決済システムＳ４１０において当該注文の決済が成立していなくとも、両システムの保持する情報の一貫性は保持される。これに対して決済システムＳ４１０の障害等により決済システムＳ４１０から決済が成立したか否かの情報（ステップｃ１１）が販売システムＳ２００にもたらされなかった時には、販売システムＳ２００においては販売契約がその注文過程において中断しているために成立していないにも関わらず、決済システムＳ４１０においては当該注文についての決済は完了している場合がある。この場合には両システムの保持する情報の一貫性が失われている。
【００４６】
そこで、このような時、管理者は、通常直接あるいは管理者端末Ｓ５００を介するなどして決済システム管理用ツールＳ４３０などを使用して、決済が正常に完了している旨を知ることができるので、そのような注文に関して情報保持手段Ｓ２７０が保持する状態が完了していない時は、注文の処理を中断している状態から再開させる必要がある。注文再開の処理とはそのための機能である。決済が正常に完了しているか否かの監視はたとえば管理者が定期的に行うことで実施される。
【００４７】
図８は管理用手段Ｓ３００が管理者端末Ｓ５００に対し表示するオーダ一覧画面Ｕ０７００を示している。オーダ一覧画面Ｕ０７００が表示される前の仕組みについては、ボタンを押すと情報保持手段Ｓ２７０に保持されたデータベースを検索し、有効な注文の一覧を示す（図１：ステップａ０１）のでも良いし、特定のＵＲＬにおいて常にオーダ一覧画面Ｕ０７００が表示し、一定時間ごとに情報保持手段Ｓ２７０に保持されたデータベースを検索し、有効な注文の一覧を示す（図１：ステップａ０１）のでも良い。
【００４８】
オーダ一覧画面Ｕ０７００にはオーダ番号Ｕ０７０１が列挙され、前のページボタンＵ０７１０、次のページボタンＵ０７１１を押下することで表示されるオーダ番号が変化する。前のページボタンＵ０７１０は最初のページにおいては表示されず、次のページボタンＵ０７１１は最後のページにおいては表示されない。
【００４９】
オーダ番号Ｕ０７０１はリンクとなっていて、押下する（図１：ステップａ０２）ことにより、図９に示されるオーダ詳細画面Ｕ０８００が管理者用端末Ｓ５００に表示される（図１：ステップａ０３）。商品名表示Ｕ０８０１、申込者表示Ｕ０８０３、配送者表示Ｕ０８０４、決済方法Ｕ０８０５、作成日時Ｕ０８０６が表示されるが、これ以上の詳しい情報が表示されても構わない。ステータス表示として、本実施形態では図１のステップのどこが終了したかをステータス表示Ｕ０８０２に表示しているが、管理者にわかりやすい「決済サイトへの遷移後」といった表現を使用しても構わない。戻るボタンＵ０８１１を押下すると、オーダ一覧画面Ｕ０７００へ遷移する。
【００５０】
オーダ処理再開ボタンＵ０８１０は前述した注文再開の処理をする際に押下する。オーダ処理再開ボタンＵ０８１０を押下すると、再開結果画面Ｕ０９００へ遷移する。結果メッセージＵ０９０１に再開した結果について表示される。図１０の画面表示から確認ボタンＵ０９１１の表示を除いたものが、重複注文判断手段Ｓ２６０で重複が確認され（図１：ステップａ０６）、再開できなかった時の例になる。同一商品・サービスを購入することが禁止されていないし注文者が不利益をこうむる可能性もない商品については、ステップａ０６による重複チェックは行われない。
【００５１】
管理者は、管理者端末Ｓ５００に表示される作業指示メッセージＵ０９０２に表示される作業指示に従い、決済システム運営会社Ｓ４００の決済システム管理用ツールＳ４３０を使用するか、決済システム管理者に連絡するか、または直接注文者に連絡することで、該当注文の注文者に返金を行う。後述するように自動的に返金処理が行われる場合は、作業指示メッセージＵ０９０２には何も表示されない。またオーダ処理を正常に再開できた場合は結果メッセージＵ０９０１に「再開に成功しました。」と表示され、作業指示メッセージＵ０９０２には何も表示されない。
【００５２】
同一の商品・サービスを購入することが不利益であることが考えられる場合、または確認をとることが注文者にとって有益な場合は、作業指示メッセージＵ０９０２に注文者への確認を即す旨表示され、確認ボタンＵ０９１１が表示される（図１：ステップａ１０）。管理者は注文者に対して確認した上で確認ボタンＵ０９１１を押下する（図１：ステップａ１１）。確認ボタンＵ０９１１を押下すると、確認Ｕ０９１１が表示されない再開結果表示画面Ｕ０９００が表示される。このとき結果メッセージＵ０９０１には「再開に成功しました。」と書かれ、作業指示メッセージＵ０９０２には何も表示されない。
【００５３】
ＯＫボタンＵ０９１０を押下するとオーダ一覧画面Ｕ０７００が管理者端末Ｓ５００に表示され、管理者は他の注文に対する処理を行うことができる。
【００５４】
以上の操作手順により、管理者は中断した注文処理を再開あるいは中止して決済をキャンセルすることが可能であり、販売システム及び決済システムの間の一貫性を維持することができる。そしてその処理手順において、注文者からの注文処理と同様に、重複して注文しても利益がないであろう商品の重複注文について注意を喚起されるため、重複した購入を防止できる。また、同一人に対する重複的な販売を制限している商品等に関して、その制限にしたがって販売を行うことができる。
【００５５】
本実施例においては決済システム管理用ツールＳ４３０などを利用して決済が正常に完了しているかを調べ、必要に応じて管理者が管理者端末Ｓ５００を使用して注文再開の処理を行うこととしている。しかしオーダ番号を通知すると決済状況を返す機能を決済システムＳ４１０がもつ時は、以下のような方法によって注文再開の処理の自動化の割合をさらに上げることも可能である。情報保持手段Ｓ２７０中の注文情報から決済システムＳ４１０へのデータ送信後注文処理が中断されている注文を一日に数回探し、決済システムＳ４１０での処理が正常に終了しているかを決済システムＳ４１０に問い合わせる。そして決済システムＳ４１０において正常に処理されていたら、自動的に注文の再開を行い（管理者が管理者端末Ｓ５００から当該注文の再開を行ったのと同等の処理を行い）、ステップａ１０、ａ１１相当の注文者または管理者による判断が必要なら、管理者へのメールを送付する。管理者は注文者への確認を行い、本実施例で説明した手作業による注文の再開を行う。
【００５６】
＜本実施形態におけるデータ処理方法：情報保持手段＞
注文者および管理者によるオペレーションについて述べたので、これらのオペレーションがどのような仕組みで動くのかについて述べる。まずは情報保持手段に存在するテーブル構造について述べる。本実施形態で述べる情報保持手段はリレーショナルデータベースであることを仮定しており、これから示す各テーブルもリレーショナルデータベースでのテーブルであるが、本発明が情報保持手段としてリレーショナルデータベースでなければならないわけではない。
【００５７】
図１１は注文の情報を格納する注文情報テーブルＴ０１００を示している。オーダ番号Ｔ０１０１を主キーとし、商品コードＴ０１０２からサービスＴ０１１１まで個々の注文に関する情報が格納される。注文情報テーブルＴ０１００は、後述する図１７の処理手順の中で作成される。
【００５８】
ステータスＴ０１０４には、前述したように図１のどのステップが終了したかを格納するものとする。例えば、注文者端末Ｓ１００がＯＫボタンＵ０３４１を押下し、決済情報が決済システムＳ４１０に送られた後では、ステータスＴ０１０４には決済情報が決済システムＳ４１０に送られたことを示すコード、たとえば「ｃ０８」が格納される。もちろん、ステータスはこの方法で管理しなければならないというわけではなく、ステータスＴ０１０４に格納される値も、ステータスを適切に示す値であれば特に制約はない。
【００５９】
なおこのように各ステップが終了した時にステータスを更新することとしているので情報保持手段Ｓ２７０へのアクセスは図１より頻繁にあるはずである。これはステータスの更新については各ステップに含まれるものとし、省略したものである。また情報保持手段Ｓ２７０からの読み出しについても記述すると煩雑になるので、それも省略している。
【００６０】
さらに商品コードＴ０１０２には注文者が購入した商品・サービスを特定する商品コードを格納する。注文者が申し込もうとしている商品・サービスが、同一注文者による重複の購入を禁じている場合は商品種別Ｔ０１０３には「１」が格納され、同一の商品・サービスを購入することが不利益であることが考えられる場合、または確認をとることが注文者にとって有益な場合は商品種別Ｔ０１０３には「２」が格納され、どちらにも該当しないものには「３」が格納される。値１〜３は、注文情報レコード作成時に後述する商品情報テーブルＴ０６００の商品種別Ｔ０６０２から初期値としてコピーされる。注文者が申し込もうとしている商品・サービスが確認をとることが注文者にとって有益な場合（つまり商品種別Ｔ０１０２の初期値が「２」であった場合）で、注文者端末Ｓ１００に表示された注文結果表示画面Ｕ０６００において確認ボタンＵ０６１１が押下され、注文者の確認が取れた場合は、商品種別Ｔ０１０３には「４」が格納される。
【００６１】
決済方法Ｔ０１０６には、この注文が行われた時使用された決済システムＳ４１０を示すコードが格納される。そして使用された決済システムがコンビニエンスストア決済のように瞬間に決済が終了するわけではなく、入金が行われるまでの期限があるときにはこの期限が決済有効期限Ｔ０１０７に格納される。さらにこの注文の決済の状態を示すために決済結果Ｔ０１０８が使用され、コンビニエンスストア決済のように一旦決済予約が済んだ状態（払い込み前）の時は「１」が、決済予約の後払い込みがされた時やクレジットカード決済など決済予約が必要でなく決済が正常に終了した場合は「２」が、決済予約が済んだまま払込が行われなく決済有効期限を過ぎた場合は「３」が、決済処理が注文者端末Ｓ１００には終了しなかったと通知されこれから手動でキャンセルする必要がある時は「４」が、キャンセルが行われた時は「５」が、クレジットカード番号間違いなどで決済が失敗した時は「６」が格納される。なお入金による「１」から「２」への変更や決済有効期限の経過による「１」から「３」への変更は通常決済システムＳ４１０からの通知により決済情報受付手段Ｓ２４０により行われるが、後者については販売システムＳ２００自身が決済有効期限Ｔ０１０７を調べることにより更新することも可能である。
【００６２】
またユーザＩＤＴ０１０９にはユーザＩＤを格納しているが、これは注文者が事前登録をする場合に、注文者ごとに割り当てられるものである。本実施形態としては、事前登録は可能だが、登録していない人も、商品やサービスを購入することができるとする。ただし本実施形態で説明している各ステップでは（つまり申し込み画面Ｕ０１００が表示される前に）すでにログイン認証などが済んでおり、申し込み画面Ｕ０１００以降の注文のプロセスでは明示的に登録されている旨を示さなくても、事前登録している注文者が申し込み画面Ｕ０１００のＯＫボタンＵ０１１０を押下したら、申し込み受付手段Ｓ２１０には注文者のユーザＩＤが通知されるものとする。なお登録されていない場合は、ユーザＩＤＴ０１０９についてはｎｕｌｌ値が格納される。
【００６３】
この他、作成日時Ｔ０１０５にはこの注文が行われた日時が、数量Ｔ０１１０にはこの注文で申し込まれた商品・サービスの数量が、価格Ｔ０１１１にはこの注文の金額の総合計が格納される。
【００６４】
図１２は注文者が事前登録した場合に使用されるユーザ情報テーブルＴ０２００を示している。ユーザＩＤを主キーＴ０２０１に、登録した人の情報がＴ０２０２からＴ０２１１に格納される。注文情報テーブルＴ０１００のユーザＩＤＴ０１０９に格納されるのは、ユーザ情報テーブルのユーザＩＤＴ０２０１である。
【００６５】
姓Ｔ０２０２には注文者の氏名の姓の部分、名Ｔ０２０３には注文者の氏名の名の部分が、郵便番号上Ｔ０２０４には郵便番号の上３桁、郵便番号下Ｔ０２０５には郵便番号の下４桁が格納される。また都道府県コードＴ０２０６は都道府県コード、住所Ｔ０２０７は都道府県名を除いた住所、市外局番Ｔ０２０８は電話番号の市外局番、市内局番Ｔ０２０９は電話番号の市内局番、電話番号Ｔ０２１０は市外局番と市内局番を除いた電話番号、メールアドレスＴ０２１１は注文者のメールアドレスを示す。これらカラムと同じ名称を持つカラムの意味は後述する注文者情報テーブルＴ０３００、配送先情報テーブルＴ０４００についても同じである。
【００６６】
図１３は注文者の情報を格納する注文者テーブルＴ０３００を示している。オーダ番号を主キーＴ０３０１に、注文者に関する情報をＴ０３０２からＴ０３１１に格納する。注文者が事前登録している場合はこのテーブルのデータ格納する必要は必ずしもないが、本実施形態では事前登録している場合も格納するものとする。
【００６７】
図１４は注文者が購入した商品・サービスが配送を要するものである時、配送先に関する情報を格納する配送先情報テーブルＴ０４００を示している。オーダ番号を主キーＴ０４０１に、配送先に関する情報をＴ０４０２からＴ０４１１に格納する。
【００６８】
図１５は注文者が購入したものがサービスである場合に、そのサービスの契約内容を格納するための契約内容テーブルＴ０５００を示している。オーダ番号を主キーＴ０５０１に、契約内容についてＴ０５０２からＴ０５０５に格納する。
【００６９】
開始日時Ｔ０５０２にはサービスを開始する日時、終了日時Ｔ０５０３にはサービスを終了する日時を、有効／無効Ｔ０５０４にはサービスの提供が有効か無効かを格納する。またサービスの販売においては、注文者に一定期間購入を禁止する必要がある場合も考えられるので、申し込みの解禁を行う日時を指定できるようにする必要がある。この日時を格納するのが申し込み再開日時Ｔ０５０５である。
【００７０】
図１６は商品の内容を格納するための商品情報テーブルＴ０６００を示している。商品コードを主キーＴ０６０１に、商品の内容についてＴ０６０２からＴ０６０８に格納する。
【００７１】
商品・サービスが、同一注文者による重複の購入を禁じている場合は商品種別Ｔ０６０２には「１」が格納され、同一の商品・サービスを購入することが不利益であることが考えられる場合、または確認をとることが注文者１００にとって有益な場合は商品種別Ｔ０６０２には「２」が格納され、どちらにも該当しないものには「３」が格納される。商品種別Ｔ０６０２は、注文情報テーブルＴ０１００のステータスＴ０１０４の初期値として格納されることになるが、値「４」は注文者の承認が取られたときにのみ格納されるものなので、商品種別Ｔ０６０２に格納されることはない。
【００７２】
配送可否Ｔ０６０３は、注文者によって配送先の特定が必要かどうかを示すもので、注文者が購入した商品・サービスによって特定される。配送先の指定が必要な場合は、「１」が、配送先の指定が不要な場合は「２」が配送可否Ｔ０６０３に格納される。
【００７３】
サービスＴ０６０４は、この商品がサービス契約か否かを示すもので、この商品がサービス契約である場合「０」が、サービス契約でない場合は「１」が格納される。期間Ｔ０６０５はこの商品がサービス契約である場合に契約の有効期間を示すものである。またサービスの販売においては、一定期間購入を禁止する必要がある場合も考えられるので、申し込みの解禁を行うまでの期間を指定できるようにする必要がある。この期間を格納するのが申し込み再開期間Ｔ０６０６である。
【００７４】
価格Ｔ０６０７にはこの商品の単価が格納され、税区分Ｔ０６０８にはこの商品の価格が内税なのか外税なのかが格納される。価格Ｔ０６０７、税区分Ｔ０６０８に格納された情報と、注文者が申し込み画面Ｕ０１００が表示されるまでの注文過程において指定した商品等の数量から、価格Ｔ０１１１に格納されるべき価格が計算される。
【００７５】
注文情報テーブルＴ０１００、ユーザ情報テーブルＴ０２００、注文者情報テーブルＴ０３００、配送先情報テーブルＴ０４００、契約内容テーブルＴ０５００、商品情報テーブルＴ０６００は、本実施形態で最低限必要とされるテーブルであり、これ以外にもテーブルが存在することが考えられる。例えば、管理者を管理するテーブル、注文者が注文した商品・サービスの内訳を管理するテーブルなどが考えられる。これらのテーブルについては必須とはいえないので説明を省略する。また後述する決済システムＳ４１０に関する種別を管理するテーブルなども考えられるが、本実施形態では決済情報提供手段、決済情報受付手段などにハードコーディングされているものとする。
【００７６】
＜本実施形態におけるデータ処理方法：注文者による注文＞
次に注文者端末Ｓ１００によって注文が行われた際に販売システムＳ２００がどのような仕組みで動くのかについて、図１、図１７（図１７Ａ及び図１７Ｂの総称）、図１８（図１８Ａ及び図１８Ｂの総称）を使用して説明する。なおフローチャートの破線は販売システムＳ２００内の別の手段や注文者端末Ｓ１００における動作が入る場合である。
【００７７】
この手順により注文の内容に応じて注文情報テーブルＴ０１００、注文者情報テーブルＴ０３００に新たなレコードが作成され、また必要に応じて配送先情報テーブルＴ０４００、契約内容テーブルＴ０５００にも新たなレコードが作成される。しかし、新たなレコードの追加は後述する段階で行われ、途中の段階においては必要な情報は申し込み受付手段Ｓ２１０のプログラムが実行されるコンピュータのメモリなどに確保された作業領域に、必要な情報が一時的に格納されて参照や更新の対象となる。一時的に保存される情報としては、商品コード、商品種別、ユーザＩＤ、配送可否のほか、処理途中に入力される注文者に関する情報や、配送先に関する情報、検索により得られた商品テーブルＴ０６００やユーザ情報テーブルＴ０２００のレコードが含まれる。これら一時メモリに保持される情報は、以下の説明では「一時メモリに保存した」という語を付して特定する。なお文脈から明らかな場合にはそれを省略する場合もある。またステータスＴ０１０４の更新についてはレコードの新規作成後の図１の各ステップにおいて行われものとし、以後言及しないこととする。
【００７８】
なお、これらの一時的に保存される情報を、注文情報テーブルＴ０１００、注文者情報テーブルＴ０３００、配送先情報テーブルＴ０４００、契約内容テーブルＴ０５００の形式で、メモリ等に保存すれば、テーブルの更新時において充填すべきフィールド、たとえば作成日時などに適切な値を書き込めば、そのままテーブルへ追加することができる。
【００７９】
まず申し込み画面Ｕ０１００には、注文者が選択した商品の商品コードが埋め込まれており、注文者端末Ｓ１００に表示された画面Ｕ０１００のボタンＵ０１１０が押下されると、画面Ｕ０１００から申し込み受付手段Ｓ２１０に対し注文者が購入する商品・サービスの商品コードが渡される。また注文者が事前登録済みの場合はユーザＩＤも申し込み画面Ｕ０１００から申し込み受付手段Ｓ２１０に対し通知される（図１：ステップｃ０１、図１７：ステップＦ０１０１）。ユーザＩＤは、申し込み画面Ｕ０１００の前の段階で注文者が入力しても良いし、所定の記憶場所に記憶されている情報を添付するようにしても良い。申し込み受付手段Ｓ２１０は商品コードに対応する商品種別、配送可否を、情報保持手段Ｓ２７０中の商品情報テーブルＴ０６００から検索し、一時メモリに商品コードやユーザＩＤ（入力されている場合）と対応付けて保存する（図１７：ステップＦ０１０２）。検索された商品種別が「１」または「２」でかつユーザＩＤが通知されている時は（図１７：ステップＦ０１２０）、重複注文判断手段Ｓ２６０に商品コードと商品種別、ユーザＩＤが通知される（図１：ステップｃ０２、図１７：ステップＦ０１２１）。
【００８０】
商品コードと商品種別、ユーザＩＤの通知を受けた重複注文判断手段Ｓ２６０は、後述する方法で重複をチェックし、重複が存在すると判断した場合は申し込み受付手段Ｓ２１０に重複が存在する旨を通知する。重複が存在する旨の通知を受けた（図１７：ステップＦ０１２２、Ｆ０１２３）申し込み受付手段Ｓ２１０は、注文者端末Ｓ１００に注文結果表示画面Ｕ０６００を表示させる（図１：ステップｉ０１、図１７：ステップＦ０１２５、Ｆ０１２４、Ｆ０１２６）。一時メモリに保存した商品種別が「１」である時（図１７：ステップＦ０１２５）は確認ボタンＵ０６１１は表示されず（図１７：ステップＦ０１２４）、「２」である時（図１７：ステップＦ０１２５）は確認ボタンＵ０６１１は表示される（図１７：ステップＦ０１２６）。
【００８１】
注文者が端末Ｓ１００上の画面Ｕ０６００において確認ボタンＵ０６１１を押下した（図１：ステップｉ０２、図１７：ステップＦ０１２７）場合、申し込み受付手段Ｓ２１０は、一時メモリに保存した商品種別を「４」に更新し（図１７：ステップＦ０１２８）、一時メモリに保存した配送可否を判定して（図１７：ステップＦ０１４０）、その値が「１」の時は配送先情報入力画面Ｕ０３００を表示し（図１：ステップｃ０３、図１７：ステップＦ０１４３）、配送可否が「２」の時（図１７：ステップＦ０１４０）は注文者情報入力画面Ｕ０２００を表示する（図１：ステップｃ０３、図１７：ステップＦ０１４１）。
【００８２】
また申し込み受付手段Ｓ２１０が、重複注文判別手段Ｓ２６０から重複が存在しない旨の通知を受けた場合（図１７：ステップＦ０１２２、Ｆ０１２３）は、一時メモリに保存した配送可否を判定して（図１７：ステップＦ０１４０）、その値が「１」の時は配送先情報入力画面Ｕ０３００が表示され（図１：ステップｃ０３、図１７：ステップＦ０１４３）、配送可否が「２」の時（図１７：ステップＦ０１４０）は注文者情報入力画面Ｕ０２００が表示される（図１：ステップｃ０３、図１７：ステップＦ０１４１）。
【００８３】
一方、ステップＦ０１０３においてユーザＩＤが通知されていないと判定された場合には、一時メモリに保存された商品種別を判定し（図１７：ステップＦ０１１０）、その値が「１」の場合は注文結果表示画面Ｕ０６００が表示される（図１：ステップｉ０１、図１７：ステップＦ０１１１）。この時、結果メッセージＵ０６０１には「この商品・サービスは事前登録されていないと購入できません。」と表示され、ボタンＵ０６０２、Ｕ０６１１は表示されない。ユーザＩＤの通知を受けていて、一時メモリに保存された商品種別が「１」「２」以外の時（図１７：ステップＦ０１２０−Ｎｏ）、またはユーザＩＤの通知を受けていなくて一時メモリに保存された商品種別が「１」以外の時（図１７：ステップＦ０１１０−Ｎｏ）は、配送可否が判定されて（図１７：ステップＦ０１４０）、その値が「１」の時は配送先情報入力画面Ｕ０３００が表示され（図１：ステップｃ０３、図１７：ステップＦ０１４３）、配送可否が「２」の時（図１７：ステップＦ０１４０）は注文者情報入力画面Ｕ０２００が表示される（図１：ステップｃ０３、図１７：ステップＦ０１４１）。
【００８４】
注文者端末Ｓ１００に表示された注文者情報入力画面Ｕ０２００または配送先情報入力画面Ｕ０３００において、ＯＫボタンＵ０２２１、Ｕ０３４１を押下した（図１：ステップｃ０４、図１７：ステップＦ０１４２、Ｆ０１４５）場合、一時メモリに保存された商品種別が「１」または「２」の時（図１７：ステップＦ０１６０）は、申し込み受付手段Ｓ２１０は、重複注文判断手段Ｓ２６０に、一時メモリに保存された商品コードと商品種別、存在するならユーザＩＤを通知する（図１：ステップｃ０５、図１７：ステップＦ０１６１）。
【００８５】
商品コードと商品種別、ユーザＩＤの通知を受けた重複注文判断手段Ｓ２６０は、後述する方法で重複をチェックし、重複が存在すると判断した場合は申し込み受付手段Ｓ２１０に重複が存在する旨を通知する。重複が存在する旨の通知を受けた（図１７：ステップＦ０１６２、Ｆ０１６３）申し込み受付手段Ｓ２１０は、注文者端末Ｓ１００に画面Ｕ０６００を表示させる（図１：ステップｉ０１、図１７：ステップＦ０１６３、Ｆ０１６４、Ｆ０１６５、Ｆ０１６６）。一時メモリに保存された商品種別が「１」である時（図１７：ステップＦ０１６４−「１」）は、ボタンＵ０６１１は表示されず（図１７：ステップＦ０１６５）、「２」である時（図１７：ステップＦ０１６４−「２」）はボタンＵ０６１１は表示される（図１７：ステップＦ０１６６）。
【００８６】
注文者端末Ｓ１００に表示された注文結果表示画面Ｕ０６００において確認ボタンＵ０６１１が押下された（図１：ステップｉ０２、図１７：ステップＦ０１６７）場合、申し込み受付手段Ｓ２１０は、一時メモリに保存された商品種別を「４」に更新する（図１７：ステップＦ０１６８）。一時メモリに保存された商品種別が「１」でも「２」でもなかった場合（図１７：ステップＦ０１６０）、もしくは重複注文判断手段Ｓ２６０から重複が存在しない旨の通知を受けた場合（図１７：ステップＦ０１６２、Ｆ０１６３）、もしくは画面Ｕ０６００に対して確認ボタンＵ０６１１が押されて一時メモリに保存された商品種別を「４」に更新した場合（図１７：ステップＦ０１６８）は、申し込み受付手段Ｓ２１０は、当該注文の情報を情報保持手段Ｓ２７０中に存在するテーブルＴ０１００、Ｔ０３００、Ｔ０４００に新規に追加する（図１：ステップｃ０６、図１７：ステップＦ０１６９）。
【００８７】
追加されるレコードは、一時メモリに保存してある商品コード、商品種別、ユーザＩＤ、配送可否の各情報に基づいて作成される。また、オーダ番号はこの段階で新たに割り当てられる。オーダ番号をシーケンシャルに割り当てるためには、情報保持手段Ｓ２７０を実装するのに使用したＤＢＭＳに順序列があればそれを使用しても良いし、オーダ番号が割り当てられる毎に値が増加されるレジスタ等を用意しそこから割り当ててもよい。たとえば、注文情報テーブルＴ０１００のレコードを作成するためには、オーダ番号を新たに割り当て、入力あるいは検索されて一時保存された商品コード、商品種別、決済方法、ユーザＩＤ、数量、価格から追加すべき新たなレコードを作成し、テーブルにそれを追加すればよい。そのほかのテーブルＴ０３００、Ｔ０４００についても同様である。
【００８８】
そして申し込み受付手段Ｓ２１０は、決済情報提供手段Ｓ２５０に対しオーダ番号と注文者情報入力画面Ｕ０２００または配送先情報入力画面Ｕ０３００で選択された決済方法を通知する（図１：ステップｃ０７、図１７：ステップＦ０１７０）。決済情報提供手段Ｓ２５０は、情報保持手段Ｓ２７０上の注文情報テーブルＴ０１００から通知されたオーダ番号を使用して当該注文の価格を取得する。また決済システム４１０の特性に応じて、他に必要な情報を情報保持手段Ｓ２７０上から取得する。そして決済システムＳ４１０に情報を通知する（図１：ステップｃ０８）。
【００８９】
決済情報提供手段Ｓ２５０からオーダ番号や価格等の情報を受信した決済システムＳ４１０は、注文者端末Ｓ１００に画面Ｕ０４００を表示する（図１：ステップｃ０９）。注文者がカード番号Ｕ０４０１、有効期限Ｕ０４０２、Ｕ０４０３を入力し、ＯＫボタンＵ０４１０を押下した時（図１：ステップｃ１０）、決済システムＳ４１０は決済情報受付手段Ｓ２４０にオーダ番号などオーダを特定する情報と対応する決済の結果について通知する（図１：ステップｃ１１）。
【００９０】
決済システムＳ４１０が画面Ｕ０４００と異なる画面で注文者に対して入力を求める場合の情報の流れは、ステップｃ０８からｃ１１と何ら変わらない。ただ決済情報提供手段Ｓ２５０と決済情報受付手段Ｓ２４０は決済システムＳ４１０に対応した機能を要する。また決済システムＳ４１０が画面を注文者端末Ｓ１００に表示しない時は、ステップｃ０９とｃ１０は存在せず、注文者端末Ｓ１００と決済システムＳ４１０との間の情報の交換はないが、それ以外の情報の流れは変わらない。
【００９１】
図１８は、決済システムＳ４１０からの決済結果について通知を受けた販売システムＳ２００による処理手順である。
【００９２】
オーダ番号など注文を特定する情報と対応する決済結果（コンビニエンス決済などのようにまず決済予約が行われその後現金等の払い込みがなされ決済が終了する決済方法については決済有効期限も含まれる）について通知を受けた（図１８：ステップＦ０２０１）決済情報受付手段Ｓ２４０は、もし決済結果が失敗であるならば（図１８：ステップＦ０２１０−Ｎｏ）、情報保持手段Ｓ２７０上に保持された注文情報テーブルＴ０１００において当該注文に対するレコードの決済結果Ｔ０１０８を「６」に更新し（図１：ステップｃ１３、図１８：ステップＦ０２０２）、その決済結果を注文受付可否表示手段Ｓ２２０に通知して注文結果表示画面Ｕ０５００の表示を指示する（図１：ステップｃ１４、図１８：ステップＦ０２０３）。指示を受けた注文受付可否表示手段Ｓ２２０は、Ｕ０５０１に「決済に失敗しました。」と表示された画面Ｕ０５００を注文者端末Ｓ１００に表示する（図１：ステップｃ１５）。
【００９３】
次に決済結果が成功だった場合には（図１８：ステップＦ０２１０−Ｙｅｓ）、当該注文の商品種別、商品コードを注文情報テーブルＴ０１００より取得し、当該商品コードに対応するサービス、期間、申し込み再開期間について商品情報テーブルＴ０６００より取得する（図１８：ステップＦ０２１１）。そして重複注文判断手段Ｓ２６０にオーダ番号を通知する（図１：ステップｃ１２、図１８：ステップＦ０２１２）。オーダ番号の通知を受けた重複注文判断手段Ｓ２６０は、後述する方法で重複をチェックし、重複が存在すると判断した場合は決済情報受付手段Ｓ２４０に重複が存在する旨を通知する。重複が存在する旨の通知を受けた（図１８：ステップＦ０２１３、Ｆ０２１４）決済情報受付手段Ｓ２４０は、商品種別が「２」の場合（図１８：ステップＦ０２２０−「２」）は、注文結果表示画面Ｕ０６００を表示するよう注文受付可否表示手段Ｓ２２０に対し指示する（図１：ステップｉ０３、図１８：ステップＦ０２４０）。
【００９４】
注文受付可否表示手段Ｓ２２０が注文者端末Ｓ１００に注文結果表示画面Ｕ０６００を表示し（図１：ステップｉ０４）、画面Ｕ０６００の確認ボタンＵ０６１１を注文者が押下した時（図１：ステップｉ０５）は、注文受付可否表示手段Ｓ２２０は決済情報受付手段Ｓ２４０に対しその旨を通知し（図１：ステップｉ０６、図１８：ステップＦ０２４１）、情報保持手段Ｓ２７０の注文情報テーブルＴ０１００の当該注文に対するレコードの決済結果Ｔ０１０８を「１」または「２」に更新する（図１：ステップｃ１３、図１８：ステップＦ０２５０、Ｆ０２５１、Ｆ０２５２）。「１」に更新される（図１８：ステップＦ０２５１）のは、決済システムＳ４１０の決済方式がコンビニエンスストア決済などのようにまず決済予約が行われその後現金等の払い込みがなされ決済が終了する決済方法（以下では長期型決済方式と呼ぶ）の場合（図１８：ステップＦ０２５０−「長期型決済方式」）であり、この時同時に決済有効期限Ｔ０１０７も決済システムから通知された決済有効期限で更新する（図１８：ステップＦ０２５１）。「２」に更新される（図１８：ステップＦ０２５２）のは、決済システムＳ４１０の決済方式がクレジットカード決済などのように決済予約という概念がなく現金等の払い込みを要せずして決済が完了する決済方式（以下では瞬間型決済方式と呼ぶ）の場合（図１８：ステップＦ０２５０−「瞬間型決済方法」）である。
【００９５】
商品情報テーブルＴ０６００から取得したサービスＴ０６０４が「０」である時（図１８：ステップＦ０２５３−Ｙｅｓ）は、さらに情報保持手段Ｓ２７０の契約内容テーブルＴ０５００に対しレコードを追加する（図１：ステップｃ１３、図１８：ステップＦ０２５４）。開始日時Ｔ０５０２には現在の時刻を、終了日時Ｔ０５０３には現在の時刻と商品情報テーブルＴ０６００から取得した期間Ｔ０６０５から計算される値を、申し込み再開日時Ｔ０５０５には現在の時刻と商品情報テーブルＴ０６００から取得した申し込み再開期間Ｔ０６０６から計算される値を、有効／無効Ｔ０５０４には「有効」を格納する。この後、決済情報受付手段Ｓ２４０は注文受付可否表示手段Ｓ２２０に対して注文結果表示画面Ｕ０５００の表示を指示する（図１：ステップｃ１４、図１８：ステップＦ０２５５）。注文結果表示画面Ｕ０５００の表示の指示を受けた注文受付可否表示手段Ｓ２２０は、画面Ｕ０５００を利用者端末Ｓ１００に表示する（図１：ステップｃ１５）。そして決済情報受付手段Ｓ２４０は注文処理手段Ｓ２３０に注文処理を指示する（図１：ステップｃ１６、図１８：ステップＦ０２５６）。
【００９６】
ステップＦ０２２０において、商品種別が「１」の時は、決済情報受付手段Ｓ２４０は、キャンセル情報提供手段Ｓ３３０またはキャンセル情報通知手段Ｓ３４０に決済システムＳ４１０へのキャンセル処理を行うように指示し（図１：ステップｃ１６、ｃ１７、図１８：ステップＦ０２２５、Ｆ０２２７、Ｆ０２３０）、情報保持手段Ｓ２７０上の注文情報テーブルＴ０１００の当該注文に対するレコードのＴ０１０８を「４」または「５」に更新する（図１：ステップｃ１３、図１８：ステップＦ０２２４、Ｆ０２２６、Ｆ０２２９）。「４」に更新される（図１８：ステップＦ０２２６）のは決済システムＳ４１０が自動的なキャンセルの処理は不可能であるが決済システム管理用ツールＳ４３０においてキャンセル処理が可能である場合（図１８：ステップＦ０２２１、Ｆ０２２２）であり、「５」に更新される（図１８：ステップＦ０２２４、Ｆ０２２９）のは決済システムＳ４１０が自動的なキャンセル処理が可能な場合（図１８：ステップＦ０２２１）もしくは自動的なキャンセルの処理は不可能で決済システム管理用ツールＳ４３０においてもキャンセル処理ができないが決済システム管理者にメールなどで通知すればキャンセル処理が可能である場合（図１８：ステップＦ０２２１、Ｆ０２２２、Ｆ０２２３）である。このような各場合分けについては、たとえば決済システムから通知されたり、あるいは予め販売システムに情報が与えられている。この後、注文受付可否表示手段Ｓ２２０に注文結果表示画面Ｕ０６００の表示を指示する（図１：ステップｉ０３、図１８：ステップＦ０２２８）。このとき確認ボタンＵ０６１１は表示されない。
【００９７】
なお決済情報受付手段Ｓ２４０が決済システムＳ４１０へのキャンセル処理を指示した際に行うのは、以下の処理である。決済システムＳ４１０が自動的なキャンセル処理が可能である場合（図１８：ステップＦ０２２１−Ｙｅｓ）は、当該注文のキャンセル処理を決済システムＳ４１０に対し行うようキャンセル情報提供手段Ｓ３３０に指示する（図１：ステップｃ１６、図１８：ステップＦ０２３０）。キャンセル情報提供手段Ｓ３３０は決済システムＳ４１０に対応した方法でキャンセルの処理を行う（図１：ステップａ１３）。
【００９８】
また自動的なキャンセルの処理は不可能であるが決済システム管理用ツールＳ４３０においてキャンセル処理が可能であれば（図１８：ステップＦ０２２１→Ｆ０２２２−Ｙｅｓ）、管理者端末Ｓ５００によって決済システム管理用ツールＳ４３０でキャンセルする（図１：ステップａ１８）ために、キャンセル情報通知手段Ｓ３４０によって管理者端末Ｓ５００へメールなどで連絡する（図１：ステップａ１６）よう、キャンセル情報通知手段に指示する（図１：ステップｃ１７、図１８：ステップＦ０２２７）。
【００９９】
自動的なキャンセルの処理は不可能で決済システム管理用ツールＳ４３０においてもキャンセル処理ができないが決済システム管理者Ｓ４２０にメールなどで通知すればキャンセル処理が可能である場合（図１８：ステップＦ０２２１→Ｆ０２２２→Ｆ０２２３−Ｙｅｓ）は、キャンセル情報通知手段Ｓ３４０が決済システム管理者Ｓ４２０に対しメールなどでキャンセルする旨を通知するよう（図１：ステップａ１５）、決済情報受付手段Ｓ２４０はキャンセル情報通知手段Ｓ３４０に対し指示する（図１：ステップｃ１７、図１８：ステップＦ０２２５）。
【０１００】
ステップＦ０２１３において、決済情報受付手段Ｓ２４０が重複注文判断手段Ｓ２６０から重複は存在しない旨の通知を受けた（図１８：ステップＦ０２１３）と判定された場合、または当該商品の商品種別が「１」でも「２」でもない時は（図１８：ステップＦ２０２０）、情報保持手段Ｓ２７０上の注文情報テーブルＴ０１００の当該注文に対するレコードの決済結果Ｔ０１０８を「１」または「２」に更新する（図１：ステップｃ１３、図１８：ステップＦ０２５１、Ｆ０２５２）。「１」に更新される（図１８：ステップＦ０２５１）のは、決済システムＳ４１０の決済方式が長期型決済方式の場合（図１８：ステップＦ０２５０−「長期型決済方式」）であり、この時同時にＴ０１０７にも決済システムから通知された決済有効期限で更新する（図１８：ステップＦ０２５１）。「２」に更新される（図１８：ステップＦ０２５２）のは決済システムＳ４１０の決済方式が瞬間型決済方式の場合（図１８：ステップＦ０２５０−「瞬間型決済方式」）である。商品情報テーブルＴ０６００から取得した当該商品のサービスＴ０６０４が「０」である時（図１８：ステップＦ０２５３−Ｙｅｓ）は、さらに情報保持手段Ｓ２７０の契約内容テーブルＴ０５００に対してレコードを追加する（図１：ステップｃ１３、図１８：ステップＦ０２５４）。開始日時Ｔ０５０２には現在の時刻を、終了日時Ｔ０５０３には現在の時刻と商品情報テーブルＴ０６００から取得した期間Ｔ０６０５から計算される値を、申し込み再開日時Ｔ０５０５には現在の時刻と商品情報テーブルＴ０６００から取得した申し込み再開期間Ｔ０６０６から計算される値を、有効／無効Ｔ０５０４には「有効」を格納する。この後、注文受付可否表示手段Ｓ２２０に、注文結果表示画面Ｕ０５００の表示を指示する（図１：ステップｃ１４、図１８：ステップＦ０２５５）。画面Ｕ０５００の表示の指示を受けた注文受付可否表示手段Ｓ２２０は、画面Ｕ０５００を表示する（図１：ステップｃ１５）。そして決済情報受付手段Ｓ２４０は注文処理手段Ｓ２３０に注文処理を指示する（図１：ステップｃ１６、図１８：ステップＦ０２５６）。
【０１０１】
＜本実施形態におけるデータ処理方法：管理者による注文再開＞
さらに管理者端末Ｓ５００によって注文再開の処理が行われた際にどのような仕組みで動くのかについて、図１を用いて説明する。
【０１０２】
管理用手段Ｓ３００は情報保持手段Ｓ２７０よりオーダに関する情報、たとえば注文情報テーブルに含まれるオーダ番号等を取得し、管理者端末Ｓ５００に対しオーダ一覧画面Ｕ０７００を表示する（図１：ステップａ０１）。管理者端末Ｓ５００において管理者がオーダ番号Ｕ０７０１を押下する（図１：ステップａ０２）と、管理用手段Ｓ５００はオーダ番号Ｕ０７０１の押下により通知されたオーダ番号を用いて、選択されたオーダ番号に対応する注文情報レコードを情報保持手段２７０中の注文情報テーブルＴ０１００、注文者情報テーブルＴ０３００、配送先情報テーブルＴ０４００より取得し、オーダ詳細画面Ｕ０８００を管理者端末Ｓ５００に対し表示する（図１：ステップａ０３）。ステータスがｃ０８で、決済方法に書かれた決済システムが瞬間型決済方法であって、作成日時が十分に古い場合はステップｃ１１において問題が生じた可能性が高い可能性があるので、決済システム管理用ツールＳ４３０で当該注文の決済が正常に終了しているかを調べる（図１：ステップａ１８）か、決済システム管理者Ｓ４２０に対し照会（図１：ステップａ１７）をし、決済システムＳ４１０での処理が正常に終了している旨が確認された場合は、管理者端末Ｓ５００はＵ０８１０を押下してオーダ再開処理を再開する必要がある。
【０１０３】
管理者端末Ｓ５００が再開ボタンＵ０８１０を押下する（図１：ステップａ０４）と、管理用手段Ｓ３００は注文再開手段Ｓ３１０に対し注文再開処理を指示する（図１：ステップａ０５）。注文再開処理の指示を受けた注文再開手段Ｓ３１０は、重複注文判断手段Ｓ２６０にオーダ番号を通知する（図１：ステップａ０６）。オーダ番号の通知を受けた重複注文判断手段Ｓ２６０は、後述する方法で重複をチェックし、重複が存在すると判断した場合は注文再開手段Ｓ３１０に重複が存在する旨を通知する。重複が存在する旨の通知を受けた注文再開手段Ｓ３１０は、情報保持手段Ｓ２７０中の注文情報テーブルＴ０１００から当該注文の商品種別を取得する。
【０１０４】
当該注文の商品種別が「１」の場合は再開結果表示画面Ｕ０９００を管理者端末Ｓ５００に表示する（図１：ステップａ１０）よう管理者用注文受付可否表示手段Ｓ３２０に対し指示する（図１：ステップａ０７）。この時再開確認ボタンＵ０９１１は表示されず、決済システムＳ４１０が自動的なキャンセルの処理は不可能であるが決済システム管理用ツールＳ４３０においてキャンセル処理が可能である場合は図１０のようにメッセージＵ０９０２にはキャンセル処理を管理者端末Ｓ５００に即す文言が表示される。この時管理者端末Ｓ５００に対しメールなどを送付する（図１：ステップａ１４、ａ１６）ことも可能である。またこの時、情報保持手段Ｓ２７０内の注文情報テーブルＴ０１００中の当該注文に対する決済結果Ｔ０１０８は「４」に更新される（図１：ステップａ０８）。
【０１０５】
また決済システムＳ４１０が自動的なキャンセル処理が可能な場合もしくは自動的なキャンセルの処理は不可能で決済システム管理用ツールＳ４３０においてもキャンセル処理ができないが決済システム管理者にメールなどで通知すればキャンセル処理が可能である場合、メッセージＵ０９０２には何も表示されない。そして決済システムＳ４１０が自動的なキャンセル処理が可能な場合は、管理者用注文受付可否表示手段Ｓ３２０は、キャンセル情報提供手段Ｓ３３０に対し決済サイトＳ４１０へのキャンセル処理を行うように指示をする（図１：ステップａ１２）。そしてこの時、情報保持手段Ｓ２７０内の注文情報テーブルＴ０１００中の当該注文に対する決済結果Ｔ０１０８は「５」に更新される（図１：ステップａ０８）。
【０１０６】
キャンセル処理の指示を受けたキャンセル情報提供手段Ｓ３３０は、決済システムＳ４１０に対しキャンセル処理の指示をする（図１：ステップａ１３）。
自動的なキャンセルの処理は不可能で決済システム管理用ツールＳ４３０においてもキャンセル処理ができないが決済システム管理者にメールなどで通知すればキャンセル処理が可能である場合は、管理者用注文受付可否表示手段Ｓ３２０はキャンセル情報通知手段Ｓ３４０に対し決済システム管理者Ｓ４２０（実際にはその者が利用するコンピュータ等）へメールなどでキャンセルする旨が通知するよう指示をする（図１：ステップａ１４）。この時、情報保持手段Ｓ２７０内の注文情報テーブルＴ０１００中の当該注文に対する決済結果は「５」に更新される（図１：ステップａ０８）。指示を受けたキャンセル情報通知手段Ｓ３４０は決済システム管理者Ｓ４２０へメールなどでキャンセルする旨を通知する（図１：ステップａ１５）。
【０１０７】
当該注文の商品種別が「２」の場合は再開結果表示画面Ｕ０９００を表示する（図１：ステップａ１０）よう管理者用注文受付可否表示手段Ｓ３２０に対し指示する（図１：ステップａ０７）。この時再開ボタンＵ０９１１は表示され、メッセージＵ０９０２には「ユーザへの確認を行ってください」と表示される。ユーザへの確認の結果、再開する場合、管理者は端末Ｓ５００に表示された再開ボタンＵ０９１１を押下する（図１：ステップａ１１）。それに応じて、管理者用注文受付可否表示手段Ｓ３２０は情報保持手段Ｓ２７０中の注文情報テーブルＴ０１００の当該注文の商品種別Ｔ０１０３を「４」に、決済結果Ｔ０１０８を「２」に更新する（図１：ステップａ０８）。そして商品情報テーブルＴ０６００から取得したサービスＴ０６０４が「０」である時は、さらに情報保持手段Ｓ２７０に保持された契約内容テーブルＴ０５００に対してレコードを追加する（図１：ステップａ０８）。新たに追加されるレコードの開始日時Ｔ０５０２には現在の時刻を、終了日時Ｔ０５０３には現在の時刻と商品情報テーブルＴ０６００から取得した期間から計算される値を、申し込み再開日時Ｔ０５０５には現在の時刻と商品情報テーブルＴ０６００から取得した申し込み再開期間から計算される値を、有効／無効Ｔ０５０４には「有効」を格納する。その後注文処理手段Ｓ２３０に注文処理を指示する（図１：ステップａ０９）。そして画面Ｕ０９００を管理者端末Ｓ５００に対し表示する（図１：ステップａ１０）。メッセージＵ０９０１には「再開に成功しました。」と表示され、操作指示メッセージＵ０９０２および再開ボタンＵ０９１１は表示されない。
【０１０８】
当該注文にかかる商品種別が「１」「２」以外の場合、再開結果表示画面Ｕ０９００を表示する（図１：ステップａ１０）よう管理者用注文受付可否表示手段Ｓ３２０に対し指示する（図１：ステップａ０７）。この時再開ボタンＵ０９１１は表示されず、メッセージＵ０９０１には「再開に成功しました。」と表示され、操作指示メッセージＵ０９０２には何も表示されない。この時、情報保持手段Ｓ２７０内の注文情報テーブルＴ０１００中の当該注文に対する決済結果Ｔ０１０８は「２」に更新される（図１：ステップａ０８）。そして商品情報テーブルＴ０６００から取得したサービスＴ０６０４が「０」である時は、さらに情報保持手段Ｓ２７０の契約内容テーブルＴ０５００に対してレコードを追加する（図１：ステップａ０８）。追加されるレコードの開始日時Ｔ０５０２には現在の時刻を、終了日時Ｔ０５０３には現在の時刻と商品情報テーブルＴ０６００から取得した期間Ｔ０６０５から計算される値を、申し込み再開日時Ｔ０５０５には現在の時刻と商品情報テーブルＴ０６００から取得した申し込み再開期間Ｔ０６０６から計算される値を、有効／無効Ｔ０５０４には「有効」を格納する。その後注文処理手段Ｓ２３０に注文処理の再開を指示する（図１：ステップａ０９）。
【０１０９】
＜本実施形態におけるデータ処理方法：重複注文判断手段による重複チェック＞
最後に重複注文判断手段Ｓ２６０がどのように処理をおこなっているかについて述べる。重複注文の判定は、以下に説明するとおり、３通りのパラメータに基づいて行われる。したがって、まず重複注文の判定の指示を受けた場合にはまず渡されたパラメータが何であるかを判定し、パラメータの種類に応じて以下の通り動作する。したがって、重複注文判定手段Ｓ２６０に対して判定を指示する申し込み受付手段Ｓ２１０および決済情報受付手段Ｓ２４０は、ステップＦ０１２１、Ｆ０１６１、Ｆ０２１２において重複注文判断手段Ｓ２６０にパラメータを渡す際には、重複注文判断手段Ｓ２６０においてパラメータの種別を識別できるように渡す必要がある。そのためには、たとえばパラメータ毎にコードを添付したり、あるいはパラメータを渡す形式において、順序やフィールドを固定的に定めても良い。いずれにしても、重複注文判断手段Ｓ２６０は渡されたパラメータの意味を判別できる。
【０１１０】
（商品コード、商品種別、ユーザＩＤに基づく重複判断）
まず、重複注文判断手段Ｓ２６０が商品コードと商品種別、ユーザＩＤの通知を受けた場合について説明する。これは、図１７のステップＦ０１２１において重複判定を指示された場合に相当する。また、ステップＦ０１６１において、ユーザＩＤを含めて重複判定を指示された場合に相当する。
【０１１１】
商品コードと商品種別、ユーザＩＤの通知をうけた重複注文判断手段Ｓ２６０は、当該ユーザＩＤと当該商品コードがそれぞれユーザＩＤＴ０１０９、商品コードＴ０１０２に格納されているレコードを、情報保持手段Ｓ２７０中の注文情報テーブルＴ０１００から検索する。該当するレコードが存在し、以下のいずれかの条件に該当する時、既に同一種の注文が行われており、重複が存在すると判断され、その旨を指示元に通知する。
（１）当該レコードの商品コードＴ０１０２に対応するサービスＴ０６０４が「１」であり、当該レコードの決済結果Ｔ０１０８が「２」の時（サービスＴ０６０４は、注文情報テーブルＴ０１００に含まれる商品コードＴ０１０２をキーとして商品情報テーブルＴ０６００から検索できる。以下ではこの検索により得られるサービスを単に当該レコードのサービスと呼ぶ）
（２）当該レコードのサービスが「０」であり決済結果Ｔ０１０８が「２」の時で当該オーダに対応する契約内容テーブルＴ０５００のレコードの申し込み再開日時Ｔ０５０５が現在より後である時
（３）当該レコードの決済方法Ｔ０１０６が長期型決済方法であり決済結果Ｔ０１０８が「１」で決済有効期限Ｔ０１０７が現在より後である時。
【０１１２】
（商品コード、商品種別に基づく重複判断）
次に重複注文判断手段Ｓ２６０が商品コードと商品種別の通知を受けた場合について説明する。ステップＦ０１６１において、ユーザＩＤなしで重複判定を指示された場合に相当する。
【０１１３】
重複注文判断手段Ｓ２６０が商品コードと商品種別の通知を受けた場合、注文情報テーブルＴ０１００の商品コードＴ０１０２が等しく、かつ注文者情報テーブルＴ０３００の注文者姓名Ｔ０３０２、Ｔ０３０３、メールアドレスＴ０３１１が等しい注文が存在するかを、情報保持手段Ｓ２７０中の注文情報テーブルＴ０１００、注文者情報テーブルＴ０３００を検索する。該当する注文が存在し、以下のいずれかの条件に該当する時、既に同一種の注文が行われており、重複が存在すると判断され、その旨を指示元に通知する。
（１）当該レコードのサービスが「１」であり決済結果Ｔ０１０８が「２」の時
（２）当該レコードのサービスが「０」であり決済結果Ｔ０１０８が「２」の時
で当該オーダに対応する契約内容テーブルＴ０５００のレコードの申し込み再開日時Ｔ０５０５が現在より後である時
（３）当該レコードの決済方法Ｔ０１０６が長期型決済方法であり決済結果Ｔ０１０８が「１」で決済有効期限Ｔ０１０７が現在より後である時。
【０１１４】
（オーダ番号に基づく重複判断）
最後にオーダ番号の通知を受けた場合について説明する。これは、図１８のステップＦ０２１２において重複判断を指示された場合に相当する。情報保持手段Ｓ２７０中の注文情報テーブルＴ０１００中からこのオーダ番号のレコードを検索する。Ｔ０１０９にユーザＩＤが含まれているなら、当該レコード以外にユーザＩＤと商品コードが等しいレコードが存在しないかをＴ０１００中を検索する。該当するレコードが存在し、以下のいずれかの条件に該当する時、既に同一種の注文が行われており、重複が存在すると判断され、その旨を指示元に通知する。
（１）当該レコードのサービスが「１」であり決済結果Ｔ０１０８が「２」の時
（２）当該レコードのサービスが「０」であり決済結果Ｔ０１０８が「２」の時で当該オーダに対応する契約内容テーブルＴ０５００のレコードの申し込み再開日時Ｔ０５０５が現在より後である時
（３）当該レコードの決済方法Ｔ０１０６が長期型決済方法であり決済結果Ｔ０１０８が「１」で決済有効期限Ｔ０１０７が現在より後である時。
【０１１５】
また通知されたオーダ番号から検索された注文情報テーブルＴ０１００のレコードにユーザＩＤが含まれていないなら、注文情報テーブルＴ０１００の商品コードＴ０１０２が等しく、かつ注文者情報テーブルＴ０３００の注文者姓Ｔ０３０２、注文者名Ｔ０３０３、メールアドレスＴ０３１１が等しい注文が当該注文以外に存在するかを、情報保持手段Ｓ２７０中の注文情報テーブルＴ０１００、注文者情報テーブルＴ０３００を検索する。該当する注文が存在し、以下のいずれかの条件に該当する時、重複が存在する旨を指示元に通知する。
（１）当該レコードのサービスが「１」であり決済結果Ｔ０１０８が「２」の時
（２）当該レコードのサービスが「０」であり決済結果Ｔ０１０８が「２」の時
で当該オーダに対応する契約内容テーブルＴ０５００のレコードの申し込み再開日時Ｔ０５０５が現在より後である時
（３）当該レコードの決済方法Ｔ０１０６が長期型決済方法であり決済結果Ｔ０１０８が「１」で決済有効期限Ｔ０１０７が現在より後である時。
【０１１６】
以上述べた通り、本実施形態のネットワーク販売システムによれば、インターネットなどのコンピュータネットワークに接続された環境を使用し、商品やサービスを注文する際に、二重注文や二重決済の危険を防止し、正常に行われた決済が放置されることを防ぐことができ、注文者にとって安全な環境を提供することが可能となる。また決済システムへのキャンセル処理なども可能な限り自動化し、二重注文が禁止されている商品・サービスに対する二重注文を完全に防ぐことが可能となるので、サイト運営者の効率を高めることが可能となる。
【０１１７】
図１９として、図１に示したシステムを実現するハードウエア環境の一例を示す。注文者端末Ｓ１００、販売システムＳ２００、決済システムＳ４００は、インターネット等の広域ネットワーク１９０１に接続され、相互に通信を行える。注文者端末Ｓ１００は一般的なパーソナルコンピュータにウェブブラウザプログラムを実装したものであり、もちろんそのウェブブラウザプログラムが稼働可能な程度にメモリ等のハードウエア資源や、ネットワーク１９０１に接続するためのオペレーティングシステムやプロトコルスタック等のソフトウエア資源も含まれる。
【０１１８】
これは管理者端末Ｓ５００についても同様である。図１９の例では管理者端末Ｓ５００は販売システムＳ２００に含まれているが、ネットワーク１９０１を介して販売システムＳ２００と接続する構成とすることもできる。
【０１１９】
販売システムＳ２００は、図１９では複数のサーバコンピュータを含む。そして各コンピュータが、図１に含まれる各手段を、その手段により実現される手順を記述したプログラムを実行することで実現している。たとえば、図１７および図１８の流れ図は、このサーバコンピュータ２００１により実行されるプログラムの手順であり、これをコンピュータにより実行することで、申し込み受付手段Ｓ２１０および決済情報受付手段Ｓ２４０が販売システムＳ２００において実現される。販売システムＳ２００は１台のサーバコンピュータにより実現することもできる。その場合には、図１７及び図１８のプログラムは、同一のコンピュータにより実行される。
【０１２０】
また、情報保持手段Ｓ２７０もまたサーバコンピュータのひとつであるコンピュータ２００２により実現される。コンピュータ２０２は図１１〜図１６に示したテーブルを含むデータベースを格納するために十分なハードディスク等のストレージを有し、他のコンピュータからの検索、更新、追加コマンドを受信して、そのコマンドに応じた動作、すなわち指定された条件に適合するデータを読み、更新し、あるいは追加してコマンドの指示元に応答を返すなどの動作を行うデータベース管理プログラムを実行する。
【０１２１】
決済システムは、販売システムと同様にネットワークに接続されたコンピュータで構成される。したがって、販売システムＳ２００から決済システムへの情報の提供を行い、逆に提供を受ける場合には、ネットワーク１９０１を介してデータの送信および受信が行われる。これは販売システムＳ２００と注文者端末Ｓ１００との間、及び、決済システムＳ４１０と注文者端末Ｓ１００との間、および、販売システムＳ１００と管理者端末Ｓ５００との間においても全く同様である。ただし、販売システムＳ２００と決済システムＳ５００との間においては、特定の注文者に関する情報を交換する限りにおいては、その注文者端末Ｓ２００（のブラウザプログラム）を介して情報の送受信を行ってもよい。そうすることで、送受信の手順において注文者の意思確認操作を介入させることが容易となる。
【０１２２】
＜他の実施形態＞
本発明の目的は前述した実施形態の機能を実現するソフトウェアのプログラムコードを記録した記録媒体を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ（またはＣＰＵまたはＭＰＵ）が記録媒体に格納されたプログラムコードを読み出し実行することによっても、達成されることは言うまでもない。この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施形態の機能を実現することとなり、そのプログラムコードを記憶した記憶媒体は本発明を構成することになる。
【０１２３】
プログラムコードを供給するための記憶媒体としては、例えば、フロッピ（登録商標）ディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、磁気テープ、不揮発性のメモリカード、ＲＯＭ、ＤＶＤなどを用いることができる。
【０１２４】
またコンピュータが読み出したプログラムコードを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼動しているＯＳ（オペレーションシステム）などが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【０１２５】
さらに、記憶媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書きこまれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【０１２６】
【発明の効果】
以上述べた通り、本発明の情報処理方法、情報処理装置、情報処理システムおよ記憶媒体によれば、インターネットなどのコンピュータネットワークに接続された環境を使用し、商品やサービスを注文する際に、二重注文や二重決済の危険を防止し、正常に行われた決済が放置されることを防ぐことができ、注文者にとって安全な環境を提供することが可能となる。また決済システムへのキャンセル処理なども可能な限り自動化し、二重注文が禁止されている商品・サービスに対する二重注文を完全に防ぐことが可能となるので、サイト運営者の効率を高めることが可能となる。
【図面の簡単な説明】
【図１】本実施形態によるシステムの概略の構成を表す図である。
【図２】商品やサービスの申し込み開始の画面を表した図である。
【図３】商品やサービスの申し込みにおいて、注文者の情報を入力する画面を表した図である。
【図４】商品やサービスの申し込みにおいて、注文者と配送先の情報を入力する画面を表した図である。
【図５】クレジットカード会社が提供するクレジットカード番号と有効期限の入力画面を表した図である。
【図６】商品やサービスの申し込みにおいて、注文結果を表示する画面を表した図である。
【図７】商品やサービスの申し込みにおいて、重複した注文が存在することを表示する画面を表した図である。
【図８】システムの管理者向けに、注文を受けたオーダの一覧を表示する画面を表した図である。
【図９】システムの管理者向けに、注文を受けたオーダの詳細情報を表示する画面を表した図である。
【図１０】システムの管理者が注文の再開処理を行った際の結果を表示する画面を表した図である。
【図１１】注文情報を格納するテーブルのデータ構成例を示す図である。
【図１２】事前登録者の情報を格納するテーブルのデータ構成例を示す図である。
【図１３】注文者の情報を格納するテーブルのデータ構成例を示す図である。
【図１４】配送先の情報を格納するテーブルのデータ構成例を示す図である。
【図１５】契約内容の情報を格納するテーブルのデータ構成例を示す図である。
【図１６】商品の情報を格納するテーブルのデータ構成例を示す図である。
【図１７Ａ】申し込み受付手段におけるフローチャートである。
【図１７Ｂ】申し込み受付手段におけるフローチャートである。
【図１８Ａ】決済情報受付手段におけるフローチャートである。
【図１８Ｂ】決済情報受付手段におけるフローチャートである。
【図１９】システム全体のハードウエア構成の一例を示す図である。
【発明の属する技術分野】
本発明は情報処理装置、情報処理方法、及びそれをコンピュータで実施するためのプログラム及びそのプログラムをコンピュータ可読に記録した記憶媒体に関し、特に、ネットワークを通して顧客からの注文を重複なく受け付けることができるものである。
【０００２】
【従来の技術】
近年、通信インフラの整備及び情報通信技術の発展により、インターネットを利用し、ＷＥＢページを閲覧した人が商品やサービスを注文することが可能となっている。このようなインターネットを通した商取引の決済手段としてはクレジットカード決済、コンビニエンスストア決済、電子マネーなどがあり、一つの販売サイトにおいて複数の決済手段がサポートされていることも多い（例えば、非特許文献１参照。）。
【０００３】
これら決済手段を提供する決済業者の中には、決済を受け付けるＷＥＢページを提供しているものもある。決済を受け付けるＷＥＢページを使用することにより、商品やサービスを注文するユーザは決済業者に直接決済情報を通知でき、商品やサービスの販売者にクレジットカード番号など決済情報を知られないで済む。
【０００４】
従来は商品やサービスの販売者が決済情報を受付け、それを決済業者に通知する方法が一般的であった。しかし購入者にとっては決済情報が第三者に漏洩しづらく、販売者にとっては漏洩の責任を問われる可能性が少ないので、最近は決済業者が提供するＷＥＢページを使用するケースが増えている。
【０００５】
決済業者が提供するＷＥＢページを使用して決済を行う場合は、通常以下のような過程を踏む。まず、販売する商品やサービスの説明を行うＷＥＢページを表示し、次に注文者の氏名などを入力するＷＥＢページを表示する。注文者がここで決済を行う旨のボタンなどを押下すると、決済業者の提供するＷＥＢページに遷移し、その際に販売者から決済業者に決済に必要な商品やサービスの金額などの情報などが引き渡される。注文者は決済業者の提供するＷＥＢページにおいて、クレジットカード番号など決済に必要な情報を入力すると、決済業者から販売者に対し、決済が正常に完了したかどうかが通知され、販売者によってこの決済の結果と注文の内容などを含むＷＥＢページが表示される。
【０００６】
一方、決済業者の提供するＷＥＢページを使用しない場合は、以下のような過程が一般的である。まず、販売する商品やサービスの説明を行うＷＥＢページを表示し、次に注文者の氏名と共にクレジットカード番号など決済に必要な情報を入力するＷＥＢページを表示する。注文者がここで決済を行う旨のボタンなどを押下すると、販売者から決済業者に対し金額やクレジットカード番号などの情報などが引き渡される。これに対し、決済業者は販売者に、決済が正常に完了したかどうかが通知し、販売者によってこの決済の結果と注文の内容などを含むＷＥＢページが表示される（例えば、非特許文献２参照）。
【０００７】
【非特許文献１】
インターネットホームページ「ｈｔｔｐ：／／ｗｗｗ．ｄｉｇｉｐｒｉ．ｃｏ．ｊｐ／ｄ／ｐａｙｍｅｎｔ．ｈｔｍｌ」、デジプリ株式会社、出願日（２００３年５月２０日）付け
【非特許文献２】
インターネットホームページ「ｈｔｔｐ：／／ｗｗｗ．ａｔ−ｌｉｎｋ．ａｄ．ｊｐ／ｔｏｐｉｃｓ／ｔ７４．ｈｔｍｌ」、三井住友ＶＩＳＡ、出願日（２００３年５月２０日）付け
【０００８】
【発明が解決しようとする課題】
このようにインターネットを利用した商取引ではネットワークを通した情報のやり取りの中で、商品の特定・注文者の特定・決済方法の特定・申し込みなどが行われるので、途中で作業が終わったり、注文者は一回申し込んだつもりが複数回申し込まれていたりといった問題が生じやすい。決済業者の提供するＷＥＢページを使用すると、他のサイトとの情報のやりとりが発生するため、さらにこのような問題が生じやすい。
【０００９】
このような問題は、有体物の販売の時も問題にはなるが、一定期間特定サービスの提供に対して課金するような場合、同一注文者に同一内容の申し込みを禁止する場合もありうるので、より大きな問題となり得る。
【００１０】
また前述したように一つの販売サイトにおいて、複数の決済システムをサポートすることが多いので、同一ユーザが同一商品を申し込む際に異なる決済システムを使用し決済することも考えられる。このため同一注文者に同一内容の申し込みを禁止する場合は、複数の決済システムに渡ることを考慮する必要がある。
【００１１】
本発明は上記従来例に鑑みてなされたもので、オンライン販売において重複注文の有無を判定し、重複注文ができない旨、あるいは重複する注文が既にされている旨を注文者に通知し、重複注文を抑制した時に発生する返金など運用上の問題を解決しサイト運用者の効率を高めることを可能とする情報処理装置等を提供することを目的とする。
【００１２】
【課題を解決するための手段】
上記目的を達成するために本発明は以下の構成を有する。
（１）情報処理装置であって、顧客からの注文を受け付ける注文受付手段と、
前記顧客が前記注文以外に同一種の注文を行っていないかを判断する重複注文判断手段と、
前記重複注文判断手段の判断結果を顧客に通知するよう制御する注文受付通知手段と、
前記注文を受付できると判定された注文についての情報を保持する情報保持手段とを有する。
（２）さらに好ましくは、外部決済システムへの情報を提供する決済情報提供手段と、
前記外部決済システムからの情報を受け付ける決済情報受付手段とをさらに備え、
前記注文受付可否表示手段はさらに、前記決済情報受付手段により受け取った情報に基づいて、前記注文の受け付けの可否を顧客に通知するよう制御し、前記情報保持手段はさらに前記外部決済情報も保持する。
（３）さらに好ましくは、前記決済情報提供手段及び決済情報受付手段は、前記注文受付手段により受け付けられた決済方法に応じた決済システムに対して情報の提供及び情報の受付を行う。
（４）さらに好ましくは、前記外部決済システムからの情報を前記決済情報受付手段が受け付けることを失敗した場合に、当該注文に対する決済後の処理を再開する注文処理再開手段をさらに有し、
前記注文処理再開手段により処理の再開が行われる際に、前記重複注文判断手段によって注文のチェックを判断し、判断結果を管理者に通知するための管理者用注文受付可否通知手段をさらに有する。
（５）さらに好ましくは、前記注文処理再開手段により処理の再開が行われた際に、前記重複注文判断手段によって注文できないと判断された場合に、前記外部決済システムに対して当該注文の決済のキャンセル処理を要求するキャンセル情報提供手段をさらに有する。
（６）さらに好ましくは、前記注文処理再開手段により処理の再開が行われた際に、前記重複注文判断手段によって注文できないと判断された場合に、管理者に対して前記外部決済システムに対してキャンセル処理を要求するよう通知するキャンセル情報通知手段をさらに有する。
（７）さらに好ましくは、前記重複注文判断手段の判断結果に基づいて前記注文の受け付けの可否を表示する管理者用注文受付可否表示手段をさらに有する。
【００１３】
【発明の実施の形態】
以下に、図面を参照して、本発明の好適な実施形態を例示的に詳しく説明する。尚、本実施形態に記載されている構成要素の相対配置、表示画面等は、特に特定的な記載がない限りは、本発明の範囲をそれらのみに限定する趣旨のものではない。ネットワークを使用するサービスにおいての共通の課題を解決する発明であり、これらも本発明に含まれる。
【００１４】
＜本実施形態の情報処理システムの構成＞
本実施例の目的は、決済システムとの連携で、ネットワークを通じて顧客からの商品・サービスの申し込みを受ける際に、その商品・サービスが同一人からの複数回の申し込みを特定条件下で禁止すべき場合に、同一商品・サービスの申し込みを拒絶し、重複注文禁止時に発生する返金など運用上の問題を解決する情報処理システムを提供することである。本発明の一実施形態として、商品・サービスを販売する場合について説明する。
【００１５】
図１は、本実施形態におけるサービスを構成するシステム全体Ｓ２００（以下では販売システムと呼ぶ）の構成、および販売システムＳ２００の運用を受けもつ管理者用の管理者端末Ｓ５００、販売システムＳ２００の顧客である注文者が利用する注文者端末Ｓ１００、注文者が販売システムＳ２００との決済に利用する決済システムの運営会社Ｓ４００の関連と情報のやり取りについて表したものである。
【００１６】
なお、図１においては各処理部の情報や要求・応答等のメッセージの交換の全てを表しているのではない。情報保持手段Ｓ２７０からの読み出しについてはそれを記述すると煩雑になるので省略し、また、そこに格納されたデータベースの更新についても全てを記載せず主たるものに限り記載されている。
【００１７】
図１では、決済システム運営会社を決済システムＳ４１０、決済システム管理者Ｓ４２０、決済システム管理用ツールＳ４３０の３つで構成されるとしているが、決済システム管理用ツールＳ４３０は必須ではない。決済システム管理用ツールＳ４３０は、決済システムＳ４１０において行われた決済の状態を一定期間たとえば１日について、後述するオーダ番号などにしたがって表示する。表示される情報はたとえば決済完了したオーダ番号のみを保存するようにしてもよいし、決済完了したオーダ番号及び中断されたオーダ番号を保存するようにしてもよい。いずれにしても、販売システムＳ２００において成立していない販売契約であるにもかかわらず、それに対応する決済が行われていないか否かを判定するために参照される情報が決済システム管理用ツールＳ４３０により表示される。この情報は、決済システムＳ４１０により提供される。
【００１８】
また図１では便宜的に決済システム運営会社Ｓ４００について一つしか表記していないが、決済システム運営会社Ｓ４００は複数あっても構わない。以下では、決済システム運営会社Ｓ４００が二つある条件の下で書かれている。つまり図１の決済システム運営会社Ｓ４００は二つのうちの一つを示している。なお現実の会社が二つ以上の決済システムを運営している場合でも、決済システム運営会社Ｓ４００が二つ以上あるのと同視すればよい。つまり決済システム運営会社Ｓ４００は、現実の単一の会社をさすのではなく、単一の決済システムＳ４１０とその運営者である決済システム管理者Ｓ４２０、決済システムの管理用ツールである決済システム管理用ツールＳ４３０を包含する概念である。
【００１９】
さらに図１では決済システム運営会社Ｓ４００が販売システムＳ２００の外にあるように記述しているが、販売システムとＳ２００と決済システムＳ４１０および決済システム管理用ツールＳ４３０が同じサイトに存在することを排除する意図ではない。決済システムＳ４１０や決済システム管理用ツールＳ４３０が使用するデータが情報保持手段Ｓ２７０上に存在することも可能である。
【００２０】
なお本実施例では、クレジットカード決済などのように決済予約という概念がなく現金等の払い込みを要せずして決済が完了する決済方式においては、決済のキャンセルが何らかの方法で可能であることを前提としている。つまり決済システムＳ４１０、決済システム管理用ツールＳ４３０、決済システム管理者Ｓ４２０のいずれかによってキャンセルが可能である。
【００２１】
また、図１において注文者端末Ｓ１００とは、注文者が利用するコンピュータ等の端末装置である。注文者のコンピュータは、販売システムＳ２００及び決済システムＳ４００と通信可能である。具体的には、注文者端末Ｓ１００はたとえばＴＣＰ／ＩＰプロトコルスタックおよびＨＴＴＰクライアントプログラム（ウェブブラウザ）実装し、そのウェブブラウザを注文者との間のユーザインターフェースとして利用する。また注文者端末Ｓ１００のウェブブラウザは、販売システムＳ１００と決済システムＳ４１０との間の情報の中継を行う場合もある。
【００２２】
また、管理者用端末Ｓ５００も注文者用端末Ｓ１００と同様に管理者が利用するコンピュータ等の端末装置である。ただし、管理者用端末Ｓ５００には、販売システムＳ２００の一部（管理用手段Ｓ３００、注文再開手段Ｓ３１０、管理者用注文受付可否表示手段Ｓ３２０、キャンセル情報提供手段Ｓ３３０、キャンセル情報通知手段Ｓ３４０）を含む構成を有していても良い。この場合には、管理者端末Ｓ５００も販売システムＳ２００の一部を構成することになる。さらに管理者端末Ｓ５００は独立したコンピュータにより実現されなくとも良く、販売システムＳ２００に属するサーバコンピュータにより実現することもできる。しかしながら、本実施形態では、管理者は管理者端末Ｓ５００を介して販売システムＳ２００にアクセスするものとして説明する。
【００２３】
図１の矢印は注文者Ｓ１００、販売システムＳ２００、決済システム運営会社Ｓ４００、管理者Ｓ５００間の情報のやり取りを示す。
【００２４】
図１に示すように、販売システムＳ２００は、申し込み受付手段Ｓ２１０、注文受付可否表示手段Ｓ２２０、注文処理手段Ｓ２３０、決済情報受付手段Ｓ２４０、決済情報提供手段Ｓ２５０、重複注文判断手段Ｓ２６０、情報保持手段Ｓ２７０、管理用手段Ｓ３００、注文再開手段Ｓ３１０、管理者用注文受付可否表示手段Ｓ３２０、キャンセル情報提供手段Ｓ３３０、キャンセル情報通知手段Ｓ３４０からなる。
【００２５】
販売システムＳ２００内の各手段は、メモリ上に存在するプログラムであって、販売システムＳ２００が存在するサーバシステム上に存在する。本実施形態はインターネットを介しての例であり、サーバシステムは、イーサネット（登録商標）等のネットワークでつながれたコンピュータにより実現される。販売システムＳ２００内の各手段は、互いに異なるコンピュータに存在する場合にはその間における情報のやり取りをこのネットワークを介して行い、また、同一のコンピュータに存在する場合には、コンピュータ上のメモリやディスク等を介したプロセス間通信などとして行う。販売システムＳ２００内の各手段は、概念としてＨＴＴＰサーバやそれより低位のネットワークプロトコル用サーバを含み得るが、サーバシステムが備えるＨＴＴＰサーバやそれより低位のネットワークプロトコル用サーバを利用しても良い。また情報保持手段Ｓ２７０は後述するデータベースを保持し、要求に応じてデータの検索や更新等を行う。データベースとしては本実施形態ではリレーショナルデータベースを使用しているが、リレーショナルデータベースでなければならないわけではない。情報保持手段Ｓ２７０は、データを磁気ディスク等のランダムアクセス可能な大容量記憶媒体上に保管する。ディスクは、情報保持手段Ｓ２７０が存在するサーバ上のディスクでも、ネットワーク上に存在する別のサーバのディスクでも構わない。なお販売システムＳ２００内の各手段は、物理的に異なるサーバ上に存在しても良いし、同一のサーバ上に存在しても良い。
【００２６】
注文処理手段Ｓ２３０は注文者Ｓ１００が申し込んだ商品・サービスによって挙動を異にする。注文者Ｓ１００が申し込んだ商品が販売システムＳ２００を運営する業者が直接扱うものであったら、注文処理手段Ｓ２３０は、担当者へのメールが送付されるものや担当者が使用するツールへの表示などを行う。また第三者の扱う商品だったら第三者へのＦＡＸやメールを送付し、または第三者が商品を作成するのに必要なデータの送信を行う。注文者Ｓ１００が申し込んだサービスが、販売システムＳ２００が存在するサイト上で扱われているものなら、注文処理Ｓ２３０は、注文者Ｓ１００に当該サービスを使用可能にする処理を行う。本実施形態は、特定の商品・サービスを目的とするものではないので、注文処理手段Ｓ２３０についての制約はない。
【００２７】
＜本実施形態の注文者からの利用＞
次に本実施形態を注文者から利用した際の振る舞いについて説明する。図２から図７は、注文者が利用する注文者端末Ｓ１００のディスプレイに表示される申し込み画面Ｕ０１００、申込者情報入力画面Ｕ０２００、配送先情報入力画面Ｕ０３００、クレジット情報入力画面Ｕ０４００、注文結果表示画面（１）Ｕ０５００、注文結果表示画面（２）Ｕ０６００を示している。注文者は、販売システムＳ２００と決済システムＳ４１０により提供されて注文者端末Ｓ１００のディスプレイに表示される画面Ｕ０１００、Ｕ０２００、Ｕ０３００、Ｕ０４００、Ｕ０５００、Ｕ０６００を介して、販売者システムＳ２００および決済システムＳ４１０から情報を獲得し、あるいは情報を入力して、商品・サービスを購入する。
【００２８】
さらに、図１中の矢印は情報の流れ（要求や応答等の命令、およびそれらに付随するデータ等の送信や受信）を表しているが、以下の説明においては、情報の流れを生じさせるきっかけとなる操作や処理を、それらにより引き起こされる情報の流れに付された参照番号によって示している。例えば「申し込みボタンＵ０１１０を押下する（図１：ステップｃ０１）。」との記載は、操作者が注文者端末Ｓ１００の画面に表示されたソフトウエアボタンを押すという操作を行うことで、注文者端末Ｓ１００から販売システムＳ２００のサーバコンピュータに対して渡される所定の情報等の流れが、図１のステップｃ０１において発生することを示す。
【００２９】
なお、この説明は操作者を含めてシステム全体としてどのように動作するかの説明を行うもので、販売システムにおけるサーバコンピュータの動作、特に利用するデータの構造や内容、処理手順や各プログラムモジュール（図１の手段）の間で交換される情報の内容等については、図１７（図１７Ａ及び図１７Ｂの総称）以降の流れ図を参照して詳しく説明する。
【００３０】
図２は商品・サービス申し込み作業の開始の申し込み画面Ｕ０１００である。申し込みメッセージＵ０１０１は便宜的に一行で表示しているが、商品・サービスの説明などどのような表記があっても構わない。また申し込みボタンＵ０１１０は商品・サービスの申し込みを行うためのボタンであるが、この画面上に二個以上存在しても構わない。
【００３１】
まず注文者は注文者端末Ｓ１００を操作し、たとえば販売システムＳ２００が提供するＨＴＴＰサーバにアクセスして商品等の注文を受け付ける画面を表示させ、その画面上に表示された商品等および数量等を選択して発注する旨の指示をする。それに応じて図２の画面が注文者端末Ｓ１００に表示される。
【００３２】
図２の申し込みボタンＵ０１１０を押下する（図１：ステップｃ０１）と、当該注文と重複する既に有効な注文が行われているかが調べられ（図１：ステップｃ０２）、既に有効な注文が存在する時は図７に示される注文結果表示画面Ｕ０６００が注文者端末Ｓ１００の画面上に表示される（図１：ステップｉ０１）。既に有効な注文が存在するかどうかの判断は、同一注文者が同一物の購入を禁じられている場合や、同一注文者は同一サービスを二つ以上契約することが無駄な場合などを基準に判断されるのが基本となる。このように同一の商品・サービスを購入することができない、もしくは許されない時は、注文結果表示画面Ｕ０６００には確認ボタンＵ０６１１は表示されない。この重複注文の判定は、具体的には情報保持手段Ｓ２７０のデータベースに格納された注文情報テーブル等に基づいて判定される。詳しいデータ構造や処理の手順は後述する。
【００３３】
同一の商品・サービスを購入することが不利益であることが考えられる場合、または確認をとることが注文者にとって有益な場合は、確認ボタンＵ０６１１の表示された注文結果表示画面Ｕ０６００が注文者端末Ｓ１００に表示される。同一商品・サービスを購入することが禁止されていないし注文者が不利益をこうむる可能性もない商品について注文された場合には、ステップｃ０２の重複注文のチェック自体が行われない。
【００３４】
注文者が注文結果表示画面Ｕ０６００の確認ボタンＵ０６１１を押下（図１：ステップｉ０２）した時、または同一商品・サービスを購入することが禁止されていないし注文者が不利益をこうむる可能性もない商品について申し込み画面Ｕ０１００の申し込みボタンＵ０１１０を押下（図１：ステップｃ０１）した時、図３に示す画面Ｕ０２００または図４に示す画面Ｕ０３００が表示される（図１：ステップｃ０３）。配送先が必要とならない場合は注文者情報入力画面Ｕ０２００が表示され、配送先が必要とされる場合は配送先情報入力画面Ｕ０３００が表示される。注文者が自分の情報を入力欄Ｕ０２０１〜Ｕ０２１０、または入力欄Ｕ０３０１〜Ｕ０３１０および入力欄Ｕ０３２０〜Ｕ０３２９に記入する。さらに決済方法としてラジオボタンＵ０２１１またはＵ０２１２、ラジオボタンＵ０３３０またはＵ０３３１を選択する。本実施形態では決済方法として２つの選択肢を表示しているが、決済方法は２つに限定されるわけではない。キャンセルボタンＵ０２２０またはＵ０３４０を押下すると、申し込み画面Ｕ０１００が表示され、商品・サービス申し込み作業が中断される。
【００３５】
ＯＫボタンＵ０２２１またはＵ０３４１を押下する（図１：ステップｃ０４）と、販売者システムＳ２００において、再度当該注文者により既に有効な注文が行われているかを調べ（図１：ステップｃ０５）、既に有効な注文が存在する時は図７に示される注文結果の表示画面Ｕ０６００が表示される（図１：ステップｉ０１）。既に有効な注文が存在するかどうかは、同一注文者が同一物の購入を禁じられている場合や同一注文者は同一サービスを二つ以上契約することが無駄な場合などに判断されるのが基本となる。このように同一の商品・サービスを購入することができない、もしくは許されない時は、注文結果表示画面Ｕ０６００に確認ボタンＵ０６１１は表示されない。
【００３６】
同一の商品・サービスを購入することが不利益であることが考えられる場合、または確認をとることが注文者にとって有益な場合は、確認ボタンＵ０６１１の表示された注文結果表示画面Ｕ０６００が注文者端末Ｓ１００に表示される。同一商品・サービスを重ねて購入することが禁止されていないし注文者が不利益をこうむる可能性もない商品については、ステップｃ０５の重複注文のチェック自体が行われない。また、同一の商品・サービスを購入することが不利益であることが考えられる場合やまたは確認をとることが注文者にとって有益な場合であっても、ステップｃ０２の段階で一度確認ボタンＵ０６１１を押下した場合にもステップｃ０５の重複注文のチェック自体が行われない。
【００３７】
注文結果表示画面Ｕ０６００の確認ボタンＵ０６１１を押下した（図１：ステップｉ０２）時、または、同一商品・サービスを購入することが禁止されていないし注文者が不利益をこうむる可能性もない商品かそのような商品でも注文者による了承を受けた場合（この画面操作に先行する重複注文の確認の際にＵ０６１１を押下していた場合）で注文者情報入力画面Ｕ０２００のＯＫボタンＵ０２２１または配送先情報入力画面Ｕ０３００のＯＫボタンＵ０３４１を押下（図１：ステップｃ０４）した時には、ラジオボタンＵ０２１１またはＵ０２１２、ラジオボタンＵ０３３０またはＵ０３３１で選択された決済システム、本例では決済システムＳ４１０に決済に必要な情報が渡され（図１：ステップｃ０８）、図５に示すカード会社のクレジット情報入力画面Ｕ０４００が注文者端末Ｓ１００に表示される（図１：ステップｃ０９）。注文者情報入力画面Ｕ０２００または配送先情報入力画面Ｕ０３００のラジオボタンは、その販売システムＳ２００から利用可能な決済システムすべてについて表示される。あるいは利用者毎に利用可能な決済システムが表示されるものであっても良い。
【００３８】
クレジット情報入力画面Ｕ０４００は決済システムＳ４１０がクレジットカードの決済を目的とするものの場合であり、画面Ｕ０４００は決済システム運営会社Ｓ４００（この場合はクレジットカード会社）の決済システム（具体的にはそのサーバコンピュータ）が注文者端末Ｓ１００に対して提供するものである。入力欄Ｕ０４０１〜Ｕ０４０３に注文者の所有するクレジットカードの番号と有効期限とを入力する。クレジットカード決済のように注文者が個人を特定する情報や注文者の支払能力を示す情報（この場合はクレジットカード番号）を入力する必要がないなら画面Ｕ０４００は必要ない。例えば、注文者が直接コンビニエンスストアで入金するコンビニエンスストア決済では画面Ｕ０４００は必要ない。画面Ｕ０４００にあたる画面での入力が必要ない場合は、ＯＫボタンＵ０２２１またはＵ０３４１を押下する（図１：ステップｃ０４）と、図６の注文結果表示画面Ｕ０５００または図７の注文結果表示画面Ｕ０６００が表示される（図１：ステップｃ１５、ｉ０４）。また個人を特定する情報や注文者の支払能力を示す情報の入力が必要な場合は、その決済システムＳ４１０が必要とする情報の入力がクレジット情報入力画面Ｕ０４００と同じように求められる。本実施形態は、特定の決済システムを対象としたものではないので、画面Ｕ０４００に関しての制約はない。
【００３９】
クレジット情報入力画面Ｕ０４００に相当する画面が存在しない場合で、注文者情報入力画面におけるＯＫボタンＵ０２２１または配送先情報入力画面におけるＯＫボタンＵ０３４１を押下（図１：ステップｃ０４）するか、またはクレジット情報入力画面Ｕ０４００に相当する画面においてＯＫボタンＵ０４１０を押下（図１：ステップｃ１０）すると、販売システムＳ２００は、再度当該注文者について既に有効な注文が行われているかを調べる（図１：ステップｃ１２）。既に有効な注文が存在する時は、図７に示される注文結果表示画面Ｕ０６００が注文者端末Ｓ１００に表示される（図１：ステップｉ０４）。既に有効な注文が存在するかどうかは、同一注文者が同一物の購入を禁じられている場合や同一注文者は同一サービスを二つ以上契約することが無駄な場合などに判断されるのが基本となる。このように同一の商品・サービスを購入することができない時、もしくは許されない時は、注文結果表示画面Ｕ０６００に確認ボタンＵ０６１１は表示されない。
【００４０】
同一の商品・サービスを購入することが不利益であることが考えられる場合、または確認をとることが注文者にとって有益な場合は、確認ボタンＵ０６１１の表示された注文結果表示画面Ｕ０６００が注文者端末Ｓ１００に表示される。一方、同一商品・サービスを購入することが禁止されていないし注文者が不利益をこうむる可能性もない商品についてはステップｃ０１２の重複注文のチェック自体が行われない。また、同一の商品・サービスを購入することが不利益であることが考えられる場合かまたは確認をとることが注文者１００にとって有益な場合であっても、ステップｃ０２またはｃ０５の段階で一度確認ボタンＵ０６１１を押下した場合にもステップｃ０１２の重複注文のチェック自体が行われない。
【００４１】
注文結果表示画面Ｕ０６００の確認ボタンＵ０６１１を押下（図１：ステップｉ０５）したとき、または同一商品・サービスを購入することが禁止されていないし注文者が不利益をこうむる可能性もない商品かそのような商品でも注文者による了承を受けた場合でかつ決済システムＳ４１０が独自の画面を持たない場合で画面Ｕ０２００のＯＫボタンＵ０２２１または画面Ｕ０３００のＯＫボタンＵ０３４１を押下（図１：ステップｃ０４）した時、または同一商品・サービスを購入することが禁止されていないし注文者が不利益をこうむる可能性もない商品かそのような商品でも注文者による了承を受けた場合でかつ決済システムＳ４１０が独自の画面を持つ場合でクレジット情報入力画面Ｕ０４００のＯＫボタンＵ０４１０を押下（図１：ステップｃ１０）した時、図６の注文結果表示画面Ｕ０５００が表示される（図１：ステップｃ１５）。注文結果表示画面Ｕ０５００では、決済システムＳ４１０からもたらされる（図１：ステップｃ１１）決済が成立したか否かの情報をもとに、メッセージＵ０５０１において注文が正常に受け付けられたかどうかが表示される。オーダ番号Ｕ０５０２には、受け付けられた、または受け付けられなかった注文の情報が書かれている。例としてオーダ番号を表示しているがより詳しい情報を表示しても構わない。ＯＫボタンＵ０５１０を押下すると、申し込み画面Ｕ０１００が表示され、再度別の商品サービスの注文をすることが可能となる。
【００４２】
以上のようにして、注文者は所望の商品等を注文できると共に、重複して注文しても利益がないであろう商品の重複注文について注意を喚起されるため、重複した購入を防止できる。また、同一人に対する重複的な販売を制限している商品等に関して、その制限にしたがって販売を行うことができる。
【００４３】
＜本実施形態の管理者からの利用＞
次に本実施形態を管理者端末Ｓ５００から利用した際の振る舞いについて説明する。図８から図１０は管理者端末Ｓ５００に表示されるオーダ一覧画面Ｕ０７００、オーダ詳細画面Ｕ０８００、再開結果画面Ｕ０９００を示している。管理者は、管理者端末Ｓ５００に表示されるオーダ一覧画面Ｕ０７００、オーダ詳細画面Ｕ０８００、再開結果画面Ｕ０９００を使用して注文の処理状況を調べ、注文再開の処理ができる。
【００４４】
注文再開の処理とは、決済システムＳ４１０側の情報による決済は正常に完了しているのにも関わらず、情報保持手段Ｓ２７０が保持する注文情報テーブル（図１１に示す。）に含まれる当該注文の状態が完了していないことを示している時、管理者端末Ｓ５００によって行われる処理である。注文者からの注文過程において、決済情報提供手段Ｓ２５０によって決済システムＳ４１０に決済に必要な情報が渡されて（図１のステップｃ０８）、決済システム運営会社での処理に移ってから何らかの障害が起こる場合もありえる。そのような障害によって決済システムＳ４１０から決済が成立したか否かの情報（ステップｃ１１）が販売システムＳ２００にもたらされなかった時は、販売システムＳ２００からは、注文者が端末Ｓ１００上でクレジット情報入力画面Ｕ０４００を自ら閉じた時との区別がつかない。
【００４５】
しかしながら、これら２つの場合は以下の点において相違している。注文者が端末Ｓ１００上でクレジット情報入力画面Ｕ０４００を自ら閉じた場合には、販売システムＳ２００において当該注文は中止されており販売契約は成立していない。そのために、決済システムＳ４１０において当該注文の決済が成立していなくとも、両システムの保持する情報の一貫性は保持される。これに対して決済システムＳ４１０の障害等により決済システムＳ４１０から決済が成立したか否かの情報（ステップｃ１１）が販売システムＳ２００にもたらされなかった時には、販売システムＳ２００においては販売契約がその注文過程において中断しているために成立していないにも関わらず、決済システムＳ４１０においては当該注文についての決済は完了している場合がある。この場合には両システムの保持する情報の一貫性が失われている。
【００４６】
そこで、このような時、管理者は、通常直接あるいは管理者端末Ｓ５００を介するなどして決済システム管理用ツールＳ４３０などを使用して、決済が正常に完了している旨を知ることができるので、そのような注文に関して情報保持手段Ｓ２７０が保持する状態が完了していない時は、注文の処理を中断している状態から再開させる必要がある。注文再開の処理とはそのための機能である。決済が正常に完了しているか否かの監視はたとえば管理者が定期的に行うことで実施される。
【００４７】
図８は管理用手段Ｓ３００が管理者端末Ｓ５００に対し表示するオーダ一覧画面Ｕ０７００を示している。オーダ一覧画面Ｕ０７００が表示される前の仕組みについては、ボタンを押すと情報保持手段Ｓ２７０に保持されたデータベースを検索し、有効な注文の一覧を示す（図１：ステップａ０１）のでも良いし、特定のＵＲＬにおいて常にオーダ一覧画面Ｕ０７００が表示し、一定時間ごとに情報保持手段Ｓ２７０に保持されたデータベースを検索し、有効な注文の一覧を示す（図１：ステップａ０１）のでも良い。
【００４８】
オーダ一覧画面Ｕ０７００にはオーダ番号Ｕ０７０１が列挙され、前のページボタンＵ０７１０、次のページボタンＵ０７１１を押下することで表示されるオーダ番号が変化する。前のページボタンＵ０７１０は最初のページにおいては表示されず、次のページボタンＵ０７１１は最後のページにおいては表示されない。
【００４９】
オーダ番号Ｕ０７０１はリンクとなっていて、押下する（図１：ステップａ０２）ことにより、図９に示されるオーダ詳細画面Ｕ０８００が管理者用端末Ｓ５００に表示される（図１：ステップａ０３）。商品名表示Ｕ０８０１、申込者表示Ｕ０８０３、配送者表示Ｕ０８０４、決済方法Ｕ０８０５、作成日時Ｕ０８０６が表示されるが、これ以上の詳しい情報が表示されても構わない。ステータス表示として、本実施形態では図１のステップのどこが終了したかをステータス表示Ｕ０８０２に表示しているが、管理者にわかりやすい「決済サイトへの遷移後」といった表現を使用しても構わない。戻るボタンＵ０８１１を押下すると、オーダ一覧画面Ｕ０７００へ遷移する。
【００５０】
オーダ処理再開ボタンＵ０８１０は前述した注文再開の処理をする際に押下する。オーダ処理再開ボタンＵ０８１０を押下すると、再開結果画面Ｕ０９００へ遷移する。結果メッセージＵ０９０１に再開した結果について表示される。図１０の画面表示から確認ボタンＵ０９１１の表示を除いたものが、重複注文判断手段Ｓ２６０で重複が確認され（図１：ステップａ０６）、再開できなかった時の例になる。同一商品・サービスを購入することが禁止されていないし注文者が不利益をこうむる可能性もない商品については、ステップａ０６による重複チェックは行われない。
【００５１】
管理者は、管理者端末Ｓ５００に表示される作業指示メッセージＵ０９０２に表示される作業指示に従い、決済システム運営会社Ｓ４００の決済システム管理用ツールＳ４３０を使用するか、決済システム管理者に連絡するか、または直接注文者に連絡することで、該当注文の注文者に返金を行う。後述するように自動的に返金処理が行われる場合は、作業指示メッセージＵ０９０２には何も表示されない。またオーダ処理を正常に再開できた場合は結果メッセージＵ０９０１に「再開に成功しました。」と表示され、作業指示メッセージＵ０９０２には何も表示されない。
【００５２】
同一の商品・サービスを購入することが不利益であることが考えられる場合、または確認をとることが注文者にとって有益な場合は、作業指示メッセージＵ０９０２に注文者への確認を即す旨表示され、確認ボタンＵ０９１１が表示される（図１：ステップａ１０）。管理者は注文者に対して確認した上で確認ボタンＵ０９１１を押下する（図１：ステップａ１１）。確認ボタンＵ０９１１を押下すると、確認Ｕ０９１１が表示されない再開結果表示画面Ｕ０９００が表示される。このとき結果メッセージＵ０９０１には「再開に成功しました。」と書かれ、作業指示メッセージＵ０９０２には何も表示されない。
【００５３】
ＯＫボタンＵ０９１０を押下するとオーダ一覧画面Ｕ０７００が管理者端末Ｓ５００に表示され、管理者は他の注文に対する処理を行うことができる。
【００５４】
以上の操作手順により、管理者は中断した注文処理を再開あるいは中止して決済をキャンセルすることが可能であり、販売システム及び決済システムの間の一貫性を維持することができる。そしてその処理手順において、注文者からの注文処理と同様に、重複して注文しても利益がないであろう商品の重複注文について注意を喚起されるため、重複した購入を防止できる。また、同一人に対する重複的な販売を制限している商品等に関して、その制限にしたがって販売を行うことができる。
【００５５】
本実施例においては決済システム管理用ツールＳ４３０などを利用して決済が正常に完了しているかを調べ、必要に応じて管理者が管理者端末Ｓ５００を使用して注文再開の処理を行うこととしている。しかしオーダ番号を通知すると決済状況を返す機能を決済システムＳ４１０がもつ時は、以下のような方法によって注文再開の処理の自動化の割合をさらに上げることも可能である。情報保持手段Ｓ２７０中の注文情報から決済システムＳ４１０へのデータ送信後注文処理が中断されている注文を一日に数回探し、決済システムＳ４１０での処理が正常に終了しているかを決済システムＳ４１０に問い合わせる。そして決済システムＳ４１０において正常に処理されていたら、自動的に注文の再開を行い（管理者が管理者端末Ｓ５００から当該注文の再開を行ったのと同等の処理を行い）、ステップａ１０、ａ１１相当の注文者または管理者による判断が必要なら、管理者へのメールを送付する。管理者は注文者への確認を行い、本実施例で説明した手作業による注文の再開を行う。
【００５６】
＜本実施形態におけるデータ処理方法：情報保持手段＞
注文者および管理者によるオペレーションについて述べたので、これらのオペレーションがどのような仕組みで動くのかについて述べる。まずは情報保持手段に存在するテーブル構造について述べる。本実施形態で述べる情報保持手段はリレーショナルデータベースであることを仮定しており、これから示す各テーブルもリレーショナルデータベースでのテーブルであるが、本発明が情報保持手段としてリレーショナルデータベースでなければならないわけではない。
【００５７】
図１１は注文の情報を格納する注文情報テーブルＴ０１００を示している。オーダ番号Ｔ０１０１を主キーとし、商品コードＴ０１０２からサービスＴ０１１１まで個々の注文に関する情報が格納される。注文情報テーブルＴ０１００は、後述する図１７の処理手順の中で作成される。
【００５８】
ステータスＴ０１０４には、前述したように図１のどのステップが終了したかを格納するものとする。例えば、注文者端末Ｓ１００がＯＫボタンＵ０３４１を押下し、決済情報が決済システムＳ４１０に送られた後では、ステータスＴ０１０４には決済情報が決済システムＳ４１０に送られたことを示すコード、たとえば「ｃ０８」が格納される。もちろん、ステータスはこの方法で管理しなければならないというわけではなく、ステータスＴ０１０４に格納される値も、ステータスを適切に示す値であれば特に制約はない。
【００５９】
なおこのように各ステップが終了した時にステータスを更新することとしているので情報保持手段Ｓ２７０へのアクセスは図１より頻繁にあるはずである。これはステータスの更新については各ステップに含まれるものとし、省略したものである。また情報保持手段Ｓ２７０からの読み出しについても記述すると煩雑になるので、それも省略している。
【００６０】
さらに商品コードＴ０１０２には注文者が購入した商品・サービスを特定する商品コードを格納する。注文者が申し込もうとしている商品・サービスが、同一注文者による重複の購入を禁じている場合は商品種別Ｔ０１０３には「１」が格納され、同一の商品・サービスを購入することが不利益であることが考えられる場合、または確認をとることが注文者にとって有益な場合は商品種別Ｔ０１０３には「２」が格納され、どちらにも該当しないものには「３」が格納される。値１〜３は、注文情報レコード作成時に後述する商品情報テーブルＴ０６００の商品種別Ｔ０６０２から初期値としてコピーされる。注文者が申し込もうとしている商品・サービスが確認をとることが注文者にとって有益な場合（つまり商品種別Ｔ０１０２の初期値が「２」であった場合）で、注文者端末Ｓ１００に表示された注文結果表示画面Ｕ０６００において確認ボタンＵ０６１１が押下され、注文者の確認が取れた場合は、商品種別Ｔ０１０３には「４」が格納される。
【００６１】
決済方法Ｔ０１０６には、この注文が行われた時使用された決済システムＳ４１０を示すコードが格納される。そして使用された決済システムがコンビニエンスストア決済のように瞬間に決済が終了するわけではなく、入金が行われるまでの期限があるときにはこの期限が決済有効期限Ｔ０１０７に格納される。さらにこの注文の決済の状態を示すために決済結果Ｔ０１０８が使用され、コンビニエンスストア決済のように一旦決済予約が済んだ状態（払い込み前）の時は「１」が、決済予約の後払い込みがされた時やクレジットカード決済など決済予約が必要でなく決済が正常に終了した場合は「２」が、決済予約が済んだまま払込が行われなく決済有効期限を過ぎた場合は「３」が、決済処理が注文者端末Ｓ１００には終了しなかったと通知されこれから手動でキャンセルする必要がある時は「４」が、キャンセルが行われた時は「５」が、クレジットカード番号間違いなどで決済が失敗した時は「６」が格納される。なお入金による「１」から「２」への変更や決済有効期限の経過による「１」から「３」への変更は通常決済システムＳ４１０からの通知により決済情報受付手段Ｓ２４０により行われるが、後者については販売システムＳ２００自身が決済有効期限Ｔ０１０７を調べることにより更新することも可能である。
【００６２】
またユーザＩＤＴ０１０９にはユーザＩＤを格納しているが、これは注文者が事前登録をする場合に、注文者ごとに割り当てられるものである。本実施形態としては、事前登録は可能だが、登録していない人も、商品やサービスを購入することができるとする。ただし本実施形態で説明している各ステップでは（つまり申し込み画面Ｕ０１００が表示される前に）すでにログイン認証などが済んでおり、申し込み画面Ｕ０１００以降の注文のプロセスでは明示的に登録されている旨を示さなくても、事前登録している注文者が申し込み画面Ｕ０１００のＯＫボタンＵ０１１０を押下したら、申し込み受付手段Ｓ２１０には注文者のユーザＩＤが通知されるものとする。なお登録されていない場合は、ユーザＩＤＴ０１０９についてはｎｕｌｌ値が格納される。
【００６３】
この他、作成日時Ｔ０１０５にはこの注文が行われた日時が、数量Ｔ０１１０にはこの注文で申し込まれた商品・サービスの数量が、価格Ｔ０１１１にはこの注文の金額の総合計が格納される。
【００６４】
図１２は注文者が事前登録した場合に使用されるユーザ情報テーブルＴ０２００を示している。ユーザＩＤを主キーＴ０２０１に、登録した人の情報がＴ０２０２からＴ０２１１に格納される。注文情報テーブルＴ０１００のユーザＩＤＴ０１０９に格納されるのは、ユーザ情報テーブルのユーザＩＤＴ０２０１である。
【００６５】
姓Ｔ０２０２には注文者の氏名の姓の部分、名Ｔ０２０３には注文者の氏名の名の部分が、郵便番号上Ｔ０２０４には郵便番号の上３桁、郵便番号下Ｔ０２０５には郵便番号の下４桁が格納される。また都道府県コードＴ０２０６は都道府県コード、住所Ｔ０２０７は都道府県名を除いた住所、市外局番Ｔ０２０８は電話番号の市外局番、市内局番Ｔ０２０９は電話番号の市内局番、電話番号Ｔ０２１０は市外局番と市内局番を除いた電話番号、メールアドレスＴ０２１１は注文者のメールアドレスを示す。これらカラムと同じ名称を持つカラムの意味は後述する注文者情報テーブルＴ０３００、配送先情報テーブルＴ０４００についても同じである。
【００６６】
図１３は注文者の情報を格納する注文者テーブルＴ０３００を示している。オーダ番号を主キーＴ０３０１に、注文者に関する情報をＴ０３０２からＴ０３１１に格納する。注文者が事前登録している場合はこのテーブルのデータ格納する必要は必ずしもないが、本実施形態では事前登録している場合も格納するものとする。
【００６７】
図１４は注文者が購入した商品・サービスが配送を要するものである時、配送先に関する情報を格納する配送先情報テーブルＴ０４００を示している。オーダ番号を主キーＴ０４０１に、配送先に関する情報をＴ０４０２からＴ０４１１に格納する。
【００６８】
図１５は注文者が購入したものがサービスである場合に、そのサービスの契約内容を格納するための契約内容テーブルＴ０５００を示している。オーダ番号を主キーＴ０５０１に、契約内容についてＴ０５０２からＴ０５０５に格納する。
【００６９】
開始日時Ｔ０５０２にはサービスを開始する日時、終了日時Ｔ０５０３にはサービスを終了する日時を、有効／無効Ｔ０５０４にはサービスの提供が有効か無効かを格納する。またサービスの販売においては、注文者に一定期間購入を禁止する必要がある場合も考えられるので、申し込みの解禁を行う日時を指定できるようにする必要がある。この日時を格納するのが申し込み再開日時Ｔ０５０５である。
【００７０】
図１６は商品の内容を格納するための商品情報テーブルＴ０６００を示している。商品コードを主キーＴ０６０１に、商品の内容についてＴ０６０２からＴ０６０８に格納する。
【００７１】
商品・サービスが、同一注文者による重複の購入を禁じている場合は商品種別Ｔ０６０２には「１」が格納され、同一の商品・サービスを購入することが不利益であることが考えられる場合、または確認をとることが注文者１００にとって有益な場合は商品種別Ｔ０６０２には「２」が格納され、どちらにも該当しないものには「３」が格納される。商品種別Ｔ０６０２は、注文情報テーブルＴ０１００のステータスＴ０１０４の初期値として格納されることになるが、値「４」は注文者の承認が取られたときにのみ格納されるものなので、商品種別Ｔ０６０２に格納されることはない。
【００７２】
配送可否Ｔ０６０３は、注文者によって配送先の特定が必要かどうかを示すもので、注文者が購入した商品・サービスによって特定される。配送先の指定が必要な場合は、「１」が、配送先の指定が不要な場合は「２」が配送可否Ｔ０６０３に格納される。
【００７３】
サービスＴ０６０４は、この商品がサービス契約か否かを示すもので、この商品がサービス契約である場合「０」が、サービス契約でない場合は「１」が格納される。期間Ｔ０６０５はこの商品がサービス契約である場合に契約の有効期間を示すものである。またサービスの販売においては、一定期間購入を禁止する必要がある場合も考えられるので、申し込みの解禁を行うまでの期間を指定できるようにする必要がある。この期間を格納するのが申し込み再開期間Ｔ０６０６である。
【００７４】
価格Ｔ０６０７にはこの商品の単価が格納され、税区分Ｔ０６０８にはこの商品の価格が内税なのか外税なのかが格納される。価格Ｔ０６０７、税区分Ｔ０６０８に格納された情報と、注文者が申し込み画面Ｕ０１００が表示されるまでの注文過程において指定した商品等の数量から、価格Ｔ０１１１に格納されるべき価格が計算される。
【００７５】
注文情報テーブルＴ０１００、ユーザ情報テーブルＴ０２００、注文者情報テーブルＴ０３００、配送先情報テーブルＴ０４００、契約内容テーブルＴ０５００、商品情報テーブルＴ０６００は、本実施形態で最低限必要とされるテーブルであり、これ以外にもテーブルが存在することが考えられる。例えば、管理者を管理するテーブル、注文者が注文した商品・サービスの内訳を管理するテーブルなどが考えられる。これらのテーブルについては必須とはいえないので説明を省略する。また後述する決済システムＳ４１０に関する種別を管理するテーブルなども考えられるが、本実施形態では決済情報提供手段、決済情報受付手段などにハードコーディングされているものとする。
【００７６】
＜本実施形態におけるデータ処理方法：注文者による注文＞
次に注文者端末Ｓ１００によって注文が行われた際に販売システムＳ２００がどのような仕組みで動くのかについて、図１、図１７（図１７Ａ及び図１７Ｂの総称）、図１８（図１８Ａ及び図１８Ｂの総称）を使用して説明する。なおフローチャートの破線は販売システムＳ２００内の別の手段や注文者端末Ｓ１００における動作が入る場合である。
【００７７】
この手順により注文の内容に応じて注文情報テーブルＴ０１００、注文者情報テーブルＴ０３００に新たなレコードが作成され、また必要に応じて配送先情報テーブルＴ０４００、契約内容テーブルＴ０５００にも新たなレコードが作成される。しかし、新たなレコードの追加は後述する段階で行われ、途中の段階においては必要な情報は申し込み受付手段Ｓ２１０のプログラムが実行されるコンピュータのメモリなどに確保された作業領域に、必要な情報が一時的に格納されて参照や更新の対象となる。一時的に保存される情報としては、商品コード、商品種別、ユーザＩＤ、配送可否のほか、処理途中に入力される注文者に関する情報や、配送先に関する情報、検索により得られた商品テーブルＴ０６００やユーザ情報テーブルＴ０２００のレコードが含まれる。これら一時メモリに保持される情報は、以下の説明では「一時メモリに保存した」という語を付して特定する。なお文脈から明らかな場合にはそれを省略する場合もある。またステータスＴ０１０４の更新についてはレコードの新規作成後の図１の各ステップにおいて行われものとし、以後言及しないこととする。
【００７８】
なお、これらの一時的に保存される情報を、注文情報テーブルＴ０１００、注文者情報テーブルＴ０３００、配送先情報テーブルＴ０４００、契約内容テーブルＴ０５００の形式で、メモリ等に保存すれば、テーブルの更新時において充填すべきフィールド、たとえば作成日時などに適切な値を書き込めば、そのままテーブルへ追加することができる。
【００７９】
まず申し込み画面Ｕ０１００には、注文者が選択した商品の商品コードが埋め込まれており、注文者端末Ｓ１００に表示された画面Ｕ０１００のボタンＵ０１１０が押下されると、画面Ｕ０１００から申し込み受付手段Ｓ２１０に対し注文者が購入する商品・サービスの商品コードが渡される。また注文者が事前登録済みの場合はユーザＩＤも申し込み画面Ｕ０１００から申し込み受付手段Ｓ２１０に対し通知される（図１：ステップｃ０１、図１７：ステップＦ０１０１）。ユーザＩＤは、申し込み画面Ｕ０１００の前の段階で注文者が入力しても良いし、所定の記憶場所に記憶されている情報を添付するようにしても良い。申し込み受付手段Ｓ２１０は商品コードに対応する商品種別、配送可否を、情報保持手段Ｓ２７０中の商品情報テーブルＴ０６００から検索し、一時メモリに商品コードやユーザＩＤ（入力されている場合）と対応付けて保存する（図１７：ステップＦ０１０２）。検索された商品種別が「１」または「２」でかつユーザＩＤが通知されている時は（図１７：ステップＦ０１２０）、重複注文判断手段Ｓ２６０に商品コードと商品種別、ユーザＩＤが通知される（図１：ステップｃ０２、図１７：ステップＦ０１２１）。
【００８０】
商品コードと商品種別、ユーザＩＤの通知を受けた重複注文判断手段Ｓ２６０は、後述する方法で重複をチェックし、重複が存在すると判断した場合は申し込み受付手段Ｓ２１０に重複が存在する旨を通知する。重複が存在する旨の通知を受けた（図１７：ステップＦ０１２２、Ｆ０１２３）申し込み受付手段Ｓ２１０は、注文者端末Ｓ１００に注文結果表示画面Ｕ０６００を表示させる（図１：ステップｉ０１、図１７：ステップＦ０１２５、Ｆ０１２４、Ｆ０１２６）。一時メモリに保存した商品種別が「１」である時（図１７：ステップＦ０１２５）は確認ボタンＵ０６１１は表示されず（図１７：ステップＦ０１２４）、「２」である時（図１７：ステップＦ０１２５）は確認ボタンＵ０６１１は表示される（図１７：ステップＦ０１２６）。
【００８１】
注文者が端末Ｓ１００上の画面Ｕ０６００において確認ボタンＵ０６１１を押下した（図１：ステップｉ０２、図１７：ステップＦ０１２７）場合、申し込み受付手段Ｓ２１０は、一時メモリに保存した商品種別を「４」に更新し（図１７：ステップＦ０１２８）、一時メモリに保存した配送可否を判定して（図１７：ステップＦ０１４０）、その値が「１」の時は配送先情報入力画面Ｕ０３００を表示し（図１：ステップｃ０３、図１７：ステップＦ０１４３）、配送可否が「２」の時（図１７：ステップＦ０１４０）は注文者情報入力画面Ｕ０２００を表示する（図１：ステップｃ０３、図１７：ステップＦ０１４１）。
【００８２】
また申し込み受付手段Ｓ２１０が、重複注文判別手段Ｓ２６０から重複が存在しない旨の通知を受けた場合（図１７：ステップＦ０１２２、Ｆ０１２３）は、一時メモリに保存した配送可否を判定して（図１７：ステップＦ０１４０）、その値が「１」の時は配送先情報入力画面Ｕ０３００が表示され（図１：ステップｃ０３、図１７：ステップＦ０１４３）、配送可否が「２」の時（図１７：ステップＦ０１４０）は注文者情報入力画面Ｕ０２００が表示される（図１：ステップｃ０３、図１７：ステップＦ０１４１）。
【００８３】
一方、ステップＦ０１０３においてユーザＩＤが通知されていないと判定された場合には、一時メモリに保存された商品種別を判定し（図１７：ステップＦ０１１０）、その値が「１」の場合は注文結果表示画面Ｕ０６００が表示される（図１：ステップｉ０１、図１７：ステップＦ０１１１）。この時、結果メッセージＵ０６０１には「この商品・サービスは事前登録されていないと購入できません。」と表示され、ボタンＵ０６０２、Ｕ０６１１は表示されない。ユーザＩＤの通知を受けていて、一時メモリに保存された商品種別が「１」「２」以外の時（図１７：ステップＦ０１２０−Ｎｏ）、またはユーザＩＤの通知を受けていなくて一時メモリに保存された商品種別が「１」以外の時（図１７：ステップＦ０１１０−Ｎｏ）は、配送可否が判定されて（図１７：ステップＦ０１４０）、その値が「１」の時は配送先情報入力画面Ｕ０３００が表示され（図１：ステップｃ０３、図１７：ステップＦ０１４３）、配送可否が「２」の時（図１７：ステップＦ０１４０）は注文者情報入力画面Ｕ０２００が表示される（図１：ステップｃ０３、図１７：ステップＦ０１４１）。
【００８４】
注文者端末Ｓ１００に表示された注文者情報入力画面Ｕ０２００または配送先情報入力画面Ｕ０３００において、ＯＫボタンＵ０２２１、Ｕ０３４１を押下した（図１：ステップｃ０４、図１７：ステップＦ０１４２、Ｆ０１４５）場合、一時メモリに保存された商品種別が「１」または「２」の時（図１７：ステップＦ０１６０）は、申し込み受付手段Ｓ２１０は、重複注文判断手段Ｓ２６０に、一時メモリに保存された商品コードと商品種別、存在するならユーザＩＤを通知する（図１：ステップｃ０５、図１７：ステップＦ０１６１）。
【００８５】
商品コードと商品種別、ユーザＩＤの通知を受けた重複注文判断手段Ｓ２６０は、後述する方法で重複をチェックし、重複が存在すると判断した場合は申し込み受付手段Ｓ２１０に重複が存在する旨を通知する。重複が存在する旨の通知を受けた（図１７：ステップＦ０１６２、Ｆ０１６３）申し込み受付手段Ｓ２１０は、注文者端末Ｓ１００に画面Ｕ０６００を表示させる（図１：ステップｉ０１、図１７：ステップＦ０１６３、Ｆ０１６４、Ｆ０１６５、Ｆ０１６６）。一時メモリに保存された商品種別が「１」である時（図１７：ステップＦ０１６４−「１」）は、ボタンＵ０６１１は表示されず（図１７：ステップＦ０１６５）、「２」である時（図１７：ステップＦ０１６４−「２」）はボタンＵ０６１１は表示される（図１７：ステップＦ０１６６）。
【００８６】
注文者端末Ｓ１００に表示された注文結果表示画面Ｕ０６００において確認ボタンＵ０６１１が押下された（図１：ステップｉ０２、図１７：ステップＦ０１６７）場合、申し込み受付手段Ｓ２１０は、一時メモリに保存された商品種別を「４」に更新する（図１７：ステップＦ０１６８）。一時メモリに保存された商品種別が「１」でも「２」でもなかった場合（図１７：ステップＦ０１６０）、もしくは重複注文判断手段Ｓ２６０から重複が存在しない旨の通知を受けた場合（図１７：ステップＦ０１６２、Ｆ０１６３）、もしくは画面Ｕ０６００に対して確認ボタンＵ０６１１が押されて一時メモリに保存された商品種別を「４」に更新した場合（図１７：ステップＦ０１６８）は、申し込み受付手段Ｓ２１０は、当該注文の情報を情報保持手段Ｓ２７０中に存在するテーブルＴ０１００、Ｔ０３００、Ｔ０４００に新規に追加する（図１：ステップｃ０６、図１７：ステップＦ０１６９）。
【００８７】
追加されるレコードは、一時メモリに保存してある商品コード、商品種別、ユーザＩＤ、配送可否の各情報に基づいて作成される。また、オーダ番号はこの段階で新たに割り当てられる。オーダ番号をシーケンシャルに割り当てるためには、情報保持手段Ｓ２７０を実装するのに使用したＤＢＭＳに順序列があればそれを使用しても良いし、オーダ番号が割り当てられる毎に値が増加されるレジスタ等を用意しそこから割り当ててもよい。たとえば、注文情報テーブルＴ０１００のレコードを作成するためには、オーダ番号を新たに割り当て、入力あるいは検索されて一時保存された商品コード、商品種別、決済方法、ユーザＩＤ、数量、価格から追加すべき新たなレコードを作成し、テーブルにそれを追加すればよい。そのほかのテーブルＴ０３００、Ｔ０４００についても同様である。
【００８８】
そして申し込み受付手段Ｓ２１０は、決済情報提供手段Ｓ２５０に対しオーダ番号と注文者情報入力画面Ｕ０２００または配送先情報入力画面Ｕ０３００で選択された決済方法を通知する（図１：ステップｃ０７、図１７：ステップＦ０１７０）。決済情報提供手段Ｓ２５０は、情報保持手段Ｓ２７０上の注文情報テーブルＴ０１００から通知されたオーダ番号を使用して当該注文の価格を取得する。また決済システム４１０の特性に応じて、他に必要な情報を情報保持手段Ｓ２７０上から取得する。そして決済システムＳ４１０に情報を通知する（図１：ステップｃ０８）。
【００８９】
決済情報提供手段Ｓ２５０からオーダ番号や価格等の情報を受信した決済システムＳ４１０は、注文者端末Ｓ１００に画面Ｕ０４００を表示する（図１：ステップｃ０９）。注文者がカード番号Ｕ０４０１、有効期限Ｕ０４０２、Ｕ０４０３を入力し、ＯＫボタンＵ０４１０を押下した時（図１：ステップｃ１０）、決済システムＳ４１０は決済情報受付手段Ｓ２４０にオーダ番号などオーダを特定する情報と対応する決済の結果について通知する（図１：ステップｃ１１）。
【００９０】
決済システムＳ４１０が画面Ｕ０４００と異なる画面で注文者に対して入力を求める場合の情報の流れは、ステップｃ０８からｃ１１と何ら変わらない。ただ決済情報提供手段Ｓ２５０と決済情報受付手段Ｓ２４０は決済システムＳ４１０に対応した機能を要する。また決済システムＳ４１０が画面を注文者端末Ｓ１００に表示しない時は、ステップｃ０９とｃ１０は存在せず、注文者端末Ｓ１００と決済システムＳ４１０との間の情報の交換はないが、それ以外の情報の流れは変わらない。
【００９１】
図１８は、決済システムＳ４１０からの決済結果について通知を受けた販売システムＳ２００による処理手順である。
【００９２】
オーダ番号など注文を特定する情報と対応する決済結果（コンビニエンス決済などのようにまず決済予約が行われその後現金等の払い込みがなされ決済が終了する決済方法については決済有効期限も含まれる）について通知を受けた（図１８：ステップＦ０２０１）決済情報受付手段Ｓ２４０は、もし決済結果が失敗であるならば（図１８：ステップＦ０２１０−Ｎｏ）、情報保持手段Ｓ２７０上に保持された注文情報テーブルＴ０１００において当該注文に対するレコードの決済結果Ｔ０１０８を「６」に更新し（図１：ステップｃ１３、図１８：ステップＦ０２０２）、その決済結果を注文受付可否表示手段Ｓ２２０に通知して注文結果表示画面Ｕ０５００の表示を指示する（図１：ステップｃ１４、図１８：ステップＦ０２０３）。指示を受けた注文受付可否表示手段Ｓ２２０は、Ｕ０５０１に「決済に失敗しました。」と表示された画面Ｕ０５００を注文者端末Ｓ１００に表示する（図１：ステップｃ１５）。
【００９３】
次に決済結果が成功だった場合には（図１８：ステップＦ０２１０−Ｙｅｓ）、当該注文の商品種別、商品コードを注文情報テーブルＴ０１００より取得し、当該商品コードに対応するサービス、期間、申し込み再開期間について商品情報テーブルＴ０６００より取得する（図１８：ステップＦ０２１１）。そして重複注文判断手段Ｓ２６０にオーダ番号を通知する（図１：ステップｃ１２、図１８：ステップＦ０２１２）。オーダ番号の通知を受けた重複注文判断手段Ｓ２６０は、後述する方法で重複をチェックし、重複が存在すると判断した場合は決済情報受付手段Ｓ２４０に重複が存在する旨を通知する。重複が存在する旨の通知を受けた（図１８：ステップＦ０２１３、Ｆ０２１４）決済情報受付手段Ｓ２４０は、商品種別が「２」の場合（図１８：ステップＦ０２２０−「２」）は、注文結果表示画面Ｕ０６００を表示するよう注文受付可否表示手段Ｓ２２０に対し指示する（図１：ステップｉ０３、図１８：ステップＦ０２４０）。
【００９４】
注文受付可否表示手段Ｓ２２０が注文者端末Ｓ１００に注文結果表示画面Ｕ０６００を表示し（図１：ステップｉ０４）、画面Ｕ０６００の確認ボタンＵ０６１１を注文者が押下した時（図１：ステップｉ０５）は、注文受付可否表示手段Ｓ２２０は決済情報受付手段Ｓ２４０に対しその旨を通知し（図１：ステップｉ０６、図１８：ステップＦ０２４１）、情報保持手段Ｓ２７０の注文情報テーブルＴ０１００の当該注文に対するレコードの決済結果Ｔ０１０８を「１」または「２」に更新する（図１：ステップｃ１３、図１８：ステップＦ０２５０、Ｆ０２５１、Ｆ０２５２）。「１」に更新される（図１８：ステップＦ０２５１）のは、決済システムＳ４１０の決済方式がコンビニエンスストア決済などのようにまず決済予約が行われその後現金等の払い込みがなされ決済が終了する決済方法（以下では長期型決済方式と呼ぶ）の場合（図１８：ステップＦ０２５０−「長期型決済方式」）であり、この時同時に決済有効期限Ｔ０１０７も決済システムから通知された決済有効期限で更新する（図１８：ステップＦ０２５１）。「２」に更新される（図１８：ステップＦ０２５２）のは、決済システムＳ４１０の決済方式がクレジットカード決済などのように決済予約という概念がなく現金等の払い込みを要せずして決済が完了する決済方式（以下では瞬間型決済方式と呼ぶ）の場合（図１８：ステップＦ０２５０−「瞬間型決済方法」）である。
【００９５】
商品情報テーブルＴ０６００から取得したサービスＴ０６０４が「０」である時（図１８：ステップＦ０２５３−Ｙｅｓ）は、さらに情報保持手段Ｓ２７０の契約内容テーブルＴ０５００に対しレコードを追加する（図１：ステップｃ１３、図１８：ステップＦ０２５４）。開始日時Ｔ０５０２には現在の時刻を、終了日時Ｔ０５０３には現在の時刻と商品情報テーブルＴ０６００から取得した期間Ｔ０６０５から計算される値を、申し込み再開日時Ｔ０５０５には現在の時刻と商品情報テーブルＴ０６００から取得した申し込み再開期間Ｔ０６０６から計算される値を、有効／無効Ｔ０５０４には「有効」を格納する。この後、決済情報受付手段Ｓ２４０は注文受付可否表示手段Ｓ２２０に対して注文結果表示画面Ｕ０５００の表示を指示する（図１：ステップｃ１４、図１８：ステップＦ０２５５）。注文結果表示画面Ｕ０５００の表示の指示を受けた注文受付可否表示手段Ｓ２２０は、画面Ｕ０５００を利用者端末Ｓ１００に表示する（図１：ステップｃ１５）。そして決済情報受付手段Ｓ２４０は注文処理手段Ｓ２３０に注文処理を指示する（図１：ステップｃ１６、図１８：ステップＦ０２５６）。
【００９６】
ステップＦ０２２０において、商品種別が「１」の時は、決済情報受付手段Ｓ２４０は、キャンセル情報提供手段Ｓ３３０またはキャンセル情報通知手段Ｓ３４０に決済システムＳ４１０へのキャンセル処理を行うように指示し（図１：ステップｃ１６、ｃ１７、図１８：ステップＦ０２２５、Ｆ０２２７、Ｆ０２３０）、情報保持手段Ｓ２７０上の注文情報テーブルＴ０１００の当該注文に対するレコードのＴ０１０８を「４」または「５」に更新する（図１：ステップｃ１３、図１８：ステップＦ０２２４、Ｆ０２２６、Ｆ０２２９）。「４」に更新される（図１８：ステップＦ０２２６）のは決済システムＳ４１０が自動的なキャンセルの処理は不可能であるが決済システム管理用ツールＳ４３０においてキャンセル処理が可能である場合（図１８：ステップＦ０２２１、Ｆ０２２２）であり、「５」に更新される（図１８：ステップＦ０２２４、Ｆ０２２９）のは決済システムＳ４１０が自動的なキャンセル処理が可能な場合（図１８：ステップＦ０２２１）もしくは自動的なキャンセルの処理は不可能で決済システム管理用ツールＳ４３０においてもキャンセル処理ができないが決済システム管理者にメールなどで通知すればキャンセル処理が可能である場合（図１８：ステップＦ０２２１、Ｆ０２２２、Ｆ０２２３）である。このような各場合分けについては、たとえば決済システムから通知されたり、あるいは予め販売システムに情報が与えられている。この後、注文受付可否表示手段Ｓ２２０に注文結果表示画面Ｕ０６００の表示を指示する（図１：ステップｉ０３、図１８：ステップＦ０２２８）。このとき確認ボタンＵ０６１１は表示されない。
【００９７】
なお決済情報受付手段Ｓ２４０が決済システムＳ４１０へのキャンセル処理を指示した際に行うのは、以下の処理である。決済システムＳ４１０が自動的なキャンセル処理が可能である場合（図１８：ステップＦ０２２１−Ｙｅｓ）は、当該注文のキャンセル処理を決済システムＳ４１０に対し行うようキャンセル情報提供手段Ｓ３３０に指示する（図１：ステップｃ１６、図１８：ステップＦ０２３０）。キャンセル情報提供手段Ｓ３３０は決済システムＳ４１０に対応した方法でキャンセルの処理を行う（図１：ステップａ１３）。
【００９８】
また自動的なキャンセルの処理は不可能であるが決済システム管理用ツールＳ４３０においてキャンセル処理が可能であれば（図１８：ステップＦ０２２１→Ｆ０２２２−Ｙｅｓ）、管理者端末Ｓ５００によって決済システム管理用ツールＳ４３０でキャンセルする（図１：ステップａ１８）ために、キャンセル情報通知手段Ｓ３４０によって管理者端末Ｓ５００へメールなどで連絡する（図１：ステップａ１６）よう、キャンセル情報通知手段に指示する（図１：ステップｃ１７、図１８：ステップＦ０２２７）。
【００９９】
自動的なキャンセルの処理は不可能で決済システム管理用ツールＳ４３０においてもキャンセル処理ができないが決済システム管理者Ｓ４２０にメールなどで通知すればキャンセル処理が可能である場合（図１８：ステップＦ０２２１→Ｆ０２２２→Ｆ０２２３−Ｙｅｓ）は、キャンセル情報通知手段Ｓ３４０が決済システム管理者Ｓ４２０に対しメールなどでキャンセルする旨を通知するよう（図１：ステップａ１５）、決済情報受付手段Ｓ２４０はキャンセル情報通知手段Ｓ３４０に対し指示する（図１：ステップｃ１７、図１８：ステップＦ０２２５）。
【０１００】
ステップＦ０２１３において、決済情報受付手段Ｓ２４０が重複注文判断手段Ｓ２６０から重複は存在しない旨の通知を受けた（図１８：ステップＦ０２１３）と判定された場合、または当該商品の商品種別が「１」でも「２」でもない時は（図１８：ステップＦ２０２０）、情報保持手段Ｓ２７０上の注文情報テーブルＴ０１００の当該注文に対するレコードの決済結果Ｔ０１０８を「１」または「２」に更新する（図１：ステップｃ１３、図１８：ステップＦ０２５１、Ｆ０２５２）。「１」に更新される（図１８：ステップＦ０２５１）のは、決済システムＳ４１０の決済方式が長期型決済方式の場合（図１８：ステップＦ０２５０−「長期型決済方式」）であり、この時同時にＴ０１０７にも決済システムから通知された決済有効期限で更新する（図１８：ステップＦ０２５１）。「２」に更新される（図１８：ステップＦ０２５２）のは決済システムＳ４１０の決済方式が瞬間型決済方式の場合（図１８：ステップＦ０２５０−「瞬間型決済方式」）である。商品情報テーブルＴ０６００から取得した当該商品のサービスＴ０６０４が「０」である時（図１８：ステップＦ０２５３−Ｙｅｓ）は、さらに情報保持手段Ｓ２７０の契約内容テーブルＴ０５００に対してレコードを追加する（図１：ステップｃ１３、図１８：ステップＦ０２５４）。開始日時Ｔ０５０２には現在の時刻を、終了日時Ｔ０５０３には現在の時刻と商品情報テーブルＴ０６００から取得した期間Ｔ０６０５から計算される値を、申し込み再開日時Ｔ０５０５には現在の時刻と商品情報テーブルＴ０６００から取得した申し込み再開期間Ｔ０６０６から計算される値を、有効／無効Ｔ０５０４には「有効」を格納する。この後、注文受付可否表示手段Ｓ２２０に、注文結果表示画面Ｕ０５００の表示を指示する（図１：ステップｃ１４、図１８：ステップＦ０２５５）。画面Ｕ０５００の表示の指示を受けた注文受付可否表示手段Ｓ２２０は、画面Ｕ０５００を表示する（図１：ステップｃ１５）。そして決済情報受付手段Ｓ２４０は注文処理手段Ｓ２３０に注文処理を指示する（図１：ステップｃ１６、図１８：ステップＦ０２５６）。
【０１０１】
＜本実施形態におけるデータ処理方法：管理者による注文再開＞
さらに管理者端末Ｓ５００によって注文再開の処理が行われた際にどのような仕組みで動くのかについて、図１を用いて説明する。
【０１０２】
管理用手段Ｓ３００は情報保持手段Ｓ２７０よりオーダに関する情報、たとえば注文情報テーブルに含まれるオーダ番号等を取得し、管理者端末Ｓ５００に対しオーダ一覧画面Ｕ０７００を表示する（図１：ステップａ０１）。管理者端末Ｓ５００において管理者がオーダ番号Ｕ０７０１を押下する（図１：ステップａ０２）と、管理用手段Ｓ５００はオーダ番号Ｕ０７０１の押下により通知されたオーダ番号を用いて、選択されたオーダ番号に対応する注文情報レコードを情報保持手段２７０中の注文情報テーブルＴ０１００、注文者情報テーブルＴ０３００、配送先情報テーブルＴ０４００より取得し、オーダ詳細画面Ｕ０８００を管理者端末Ｓ５００に対し表示する（図１：ステップａ０３）。ステータスがｃ０８で、決済方法に書かれた決済システムが瞬間型決済方法であって、作成日時が十分に古い場合はステップｃ１１において問題が生じた可能性が高い可能性があるので、決済システム管理用ツールＳ４３０で当該注文の決済が正常に終了しているかを調べる（図１：ステップａ１８）か、決済システム管理者Ｓ４２０に対し照会（図１：ステップａ１７）をし、決済システムＳ４１０での処理が正常に終了している旨が確認された場合は、管理者端末Ｓ５００はＵ０８１０を押下してオーダ再開処理を再開する必要がある。
【０１０３】
管理者端末Ｓ５００が再開ボタンＵ０８１０を押下する（図１：ステップａ０４）と、管理用手段Ｓ３００は注文再開手段Ｓ３１０に対し注文再開処理を指示する（図１：ステップａ０５）。注文再開処理の指示を受けた注文再開手段Ｓ３１０は、重複注文判断手段Ｓ２６０にオーダ番号を通知する（図１：ステップａ０６）。オーダ番号の通知を受けた重複注文判断手段Ｓ２６０は、後述する方法で重複をチェックし、重複が存在すると判断した場合は注文再開手段Ｓ３１０に重複が存在する旨を通知する。重複が存在する旨の通知を受けた注文再開手段Ｓ３１０は、情報保持手段Ｓ２７０中の注文情報テーブルＴ０１００から当該注文の商品種別を取得する。
【０１０４】
当該注文の商品種別が「１」の場合は再開結果表示画面Ｕ０９００を管理者端末Ｓ５００に表示する（図１：ステップａ１０）よう管理者用注文受付可否表示手段Ｓ３２０に対し指示する（図１：ステップａ０７）。この時再開確認ボタンＵ０９１１は表示されず、決済システムＳ４１０が自動的なキャンセルの処理は不可能であるが決済システム管理用ツールＳ４３０においてキャンセル処理が可能である場合は図１０のようにメッセージＵ０９０２にはキャンセル処理を管理者端末Ｓ５００に即す文言が表示される。この時管理者端末Ｓ５００に対しメールなどを送付する（図１：ステップａ１４、ａ１６）ことも可能である。またこの時、情報保持手段Ｓ２７０内の注文情報テーブルＴ０１００中の当該注文に対する決済結果Ｔ０１０８は「４」に更新される（図１：ステップａ０８）。
【０１０５】
また決済システムＳ４１０が自動的なキャンセル処理が可能な場合もしくは自動的なキャンセルの処理は不可能で決済システム管理用ツールＳ４３０においてもキャンセル処理ができないが決済システム管理者にメールなどで通知すればキャンセル処理が可能である場合、メッセージＵ０９０２には何も表示されない。そして決済システムＳ４１０が自動的なキャンセル処理が可能な場合は、管理者用注文受付可否表示手段Ｓ３２０は、キャンセル情報提供手段Ｓ３３０に対し決済サイトＳ４１０へのキャンセル処理を行うように指示をする（図１：ステップａ１２）。そしてこの時、情報保持手段Ｓ２７０内の注文情報テーブルＴ０１００中の当該注文に対する決済結果Ｔ０１０８は「５」に更新される（図１：ステップａ０８）。
【０１０６】
キャンセル処理の指示を受けたキャンセル情報提供手段Ｓ３３０は、決済システムＳ４１０に対しキャンセル処理の指示をする（図１：ステップａ１３）。
自動的なキャンセルの処理は不可能で決済システム管理用ツールＳ４３０においてもキャンセル処理ができないが決済システム管理者にメールなどで通知すればキャンセル処理が可能である場合は、管理者用注文受付可否表示手段Ｓ３２０はキャンセル情報通知手段Ｓ３４０に対し決済システム管理者Ｓ４２０（実際にはその者が利用するコンピュータ等）へメールなどでキャンセルする旨が通知するよう指示をする（図１：ステップａ１４）。この時、情報保持手段Ｓ２７０内の注文情報テーブルＴ０１００中の当該注文に対する決済結果は「５」に更新される（図１：ステップａ０８）。指示を受けたキャンセル情報通知手段Ｓ３４０は決済システム管理者Ｓ４２０へメールなどでキャンセルする旨を通知する（図１：ステップａ１５）。
【０１０７】
当該注文の商品種別が「２」の場合は再開結果表示画面Ｕ０９００を表示する（図１：ステップａ１０）よう管理者用注文受付可否表示手段Ｓ３２０に対し指示する（図１：ステップａ０７）。この時再開ボタンＵ０９１１は表示され、メッセージＵ０９０２には「ユーザへの確認を行ってください」と表示される。ユーザへの確認の結果、再開する場合、管理者は端末Ｓ５００に表示された再開ボタンＵ０９１１を押下する（図１：ステップａ１１）。それに応じて、管理者用注文受付可否表示手段Ｓ３２０は情報保持手段Ｓ２７０中の注文情報テーブルＴ０１００の当該注文の商品種別Ｔ０１０３を「４」に、決済結果Ｔ０１０８を「２」に更新する（図１：ステップａ０８）。そして商品情報テーブルＴ０６００から取得したサービスＴ０６０４が「０」である時は、さらに情報保持手段Ｓ２７０に保持された契約内容テーブルＴ０５００に対してレコードを追加する（図１：ステップａ０８）。新たに追加されるレコードの開始日時Ｔ０５０２には現在の時刻を、終了日時Ｔ０５０３には現在の時刻と商品情報テーブルＴ０６００から取得した期間から計算される値を、申し込み再開日時Ｔ０５０５には現在の時刻と商品情報テーブルＴ０６００から取得した申し込み再開期間から計算される値を、有効／無効Ｔ０５０４には「有効」を格納する。その後注文処理手段Ｓ２３０に注文処理を指示する（図１：ステップａ０９）。そして画面Ｕ０９００を管理者端末Ｓ５００に対し表示する（図１：ステップａ１０）。メッセージＵ０９０１には「再開に成功しました。」と表示され、操作指示メッセージＵ０９０２および再開ボタンＵ０９１１は表示されない。
【０１０８】
当該注文にかかる商品種別が「１」「２」以外の場合、再開結果表示画面Ｕ０９００を表示する（図１：ステップａ１０）よう管理者用注文受付可否表示手段Ｓ３２０に対し指示する（図１：ステップａ０７）。この時再開ボタンＵ０９１１は表示されず、メッセージＵ０９０１には「再開に成功しました。」と表示され、操作指示メッセージＵ０９０２には何も表示されない。この時、情報保持手段Ｓ２７０内の注文情報テーブルＴ０１００中の当該注文に対する決済結果Ｔ０１０８は「２」に更新される（図１：ステップａ０８）。そして商品情報テーブルＴ０６００から取得したサービスＴ０６０４が「０」である時は、さらに情報保持手段Ｓ２７０の契約内容テーブルＴ０５００に対してレコードを追加する（図１：ステップａ０８）。追加されるレコードの開始日時Ｔ０５０２には現在の時刻を、終了日時Ｔ０５０３には現在の時刻と商品情報テーブルＴ０６００から取得した期間Ｔ０６０５から計算される値を、申し込み再開日時Ｔ０５０５には現在の時刻と商品情報テーブルＴ０６００から取得した申し込み再開期間Ｔ０６０６から計算される値を、有効／無効Ｔ０５０４には「有効」を格納する。その後注文処理手段Ｓ２３０に注文処理の再開を指示する（図１：ステップａ０９）。
【０１０９】
＜本実施形態におけるデータ処理方法：重複注文判断手段による重複チェック＞
最後に重複注文判断手段Ｓ２６０がどのように処理をおこなっているかについて述べる。重複注文の判定は、以下に説明するとおり、３通りのパラメータに基づいて行われる。したがって、まず重複注文の判定の指示を受けた場合にはまず渡されたパラメータが何であるかを判定し、パラメータの種類に応じて以下の通り動作する。したがって、重複注文判定手段Ｓ２６０に対して判定を指示する申し込み受付手段Ｓ２１０および決済情報受付手段Ｓ２４０は、ステップＦ０１２１、Ｆ０１６１、Ｆ０２１２において重複注文判断手段Ｓ２６０にパラメータを渡す際には、重複注文判断手段Ｓ２６０においてパラメータの種別を識別できるように渡す必要がある。そのためには、たとえばパラメータ毎にコードを添付したり、あるいはパラメータを渡す形式において、順序やフィールドを固定的に定めても良い。いずれにしても、重複注文判断手段Ｓ２６０は渡されたパラメータの意味を判別できる。
【０１１０】
（商品コード、商品種別、ユーザＩＤに基づく重複判断）
まず、重複注文判断手段Ｓ２６０が商品コードと商品種別、ユーザＩＤの通知を受けた場合について説明する。これは、図１７のステップＦ０１２１において重複判定を指示された場合に相当する。また、ステップＦ０１６１において、ユーザＩＤを含めて重複判定を指示された場合に相当する。
【０１１１】
商品コードと商品種別、ユーザＩＤの通知をうけた重複注文判断手段Ｓ２６０は、当該ユーザＩＤと当該商品コードがそれぞれユーザＩＤＴ０１０９、商品コードＴ０１０２に格納されているレコードを、情報保持手段Ｓ２７０中の注文情報テーブルＴ０１００から検索する。該当するレコードが存在し、以下のいずれかの条件に該当する時、既に同一種の注文が行われており、重複が存在すると判断され、その旨を指示元に通知する。
（１）当該レコードの商品コードＴ０１０２に対応するサービスＴ０６０４が「１」であり、当該レコードの決済結果Ｔ０１０８が「２」の時（サービスＴ０６０４は、注文情報テーブルＴ０１００に含まれる商品コードＴ０１０２をキーとして商品情報テーブルＴ０６００から検索できる。以下ではこの検索により得られるサービスを単に当該レコードのサービスと呼ぶ）
（２）当該レコードのサービスが「０」であり決済結果Ｔ０１０８が「２」の時で当該オーダに対応する契約内容テーブルＴ０５００のレコードの申し込み再開日時Ｔ０５０５が現在より後である時
（３）当該レコードの決済方法Ｔ０１０６が長期型決済方法であり決済結果Ｔ０１０８が「１」で決済有効期限Ｔ０１０７が現在より後である時。
【０１１２】
（商品コード、商品種別に基づく重複判断）
次に重複注文判断手段Ｓ２６０が商品コードと商品種別の通知を受けた場合について説明する。ステップＦ０１６１において、ユーザＩＤなしで重複判定を指示された場合に相当する。
【０１１３】
重複注文判断手段Ｓ２６０が商品コードと商品種別の通知を受けた場合、注文情報テーブルＴ０１００の商品コードＴ０１０２が等しく、かつ注文者情報テーブルＴ０３００の注文者姓名Ｔ０３０２、Ｔ０３０３、メールアドレスＴ０３１１が等しい注文が存在するかを、情報保持手段Ｓ２７０中の注文情報テーブルＴ０１００、注文者情報テーブルＴ０３００を検索する。該当する注文が存在し、以下のいずれかの条件に該当する時、既に同一種の注文が行われており、重複が存在すると判断され、その旨を指示元に通知する。
（１）当該レコードのサービスが「１」であり決済結果Ｔ０１０８が「２」の時
（２）当該レコードのサービスが「０」であり決済結果Ｔ０１０８が「２」の時
で当該オーダに対応する契約内容テーブルＴ０５００のレコードの申し込み再開日時Ｔ０５０５が現在より後である時
（３）当該レコードの決済方法Ｔ０１０６が長期型決済方法であり決済結果Ｔ０１０８が「１」で決済有効期限Ｔ０１０７が現在より後である時。
【０１１４】
（オーダ番号に基づく重複判断）
最後にオーダ番号の通知を受けた場合について説明する。これは、図１８のステップＦ０２１２において重複判断を指示された場合に相当する。情報保持手段Ｓ２７０中の注文情報テーブルＴ０１００中からこのオーダ番号のレコードを検索する。Ｔ０１０９にユーザＩＤが含まれているなら、当該レコード以外にユーザＩＤと商品コードが等しいレコードが存在しないかをＴ０１００中を検索する。該当するレコードが存在し、以下のいずれかの条件に該当する時、既に同一種の注文が行われており、重複が存在すると判断され、その旨を指示元に通知する。
（１）当該レコードのサービスが「１」であり決済結果Ｔ０１０８が「２」の時
（２）当該レコードのサービスが「０」であり決済結果Ｔ０１０８が「２」の時で当該オーダに対応する契約内容テーブルＴ０５００のレコードの申し込み再開日時Ｔ０５０５が現在より後である時
（３）当該レコードの決済方法Ｔ０１０６が長期型決済方法であり決済結果Ｔ０１０８が「１」で決済有効期限Ｔ０１０７が現在より後である時。
【０１１５】
また通知されたオーダ番号から検索された注文情報テーブルＴ０１００のレコードにユーザＩＤが含まれていないなら、注文情報テーブルＴ０１００の商品コードＴ０１０２が等しく、かつ注文者情報テーブルＴ０３００の注文者姓Ｔ０３０２、注文者名Ｔ０３０３、メールアドレスＴ０３１１が等しい注文が当該注文以外に存在するかを、情報保持手段Ｓ２７０中の注文情報テーブルＴ０１００、注文者情報テーブルＴ０３００を検索する。該当する注文が存在し、以下のいずれかの条件に該当する時、重複が存在する旨を指示元に通知する。
（１）当該レコードのサービスが「１」であり決済結果Ｔ０１０８が「２」の時
（２）当該レコードのサービスが「０」であり決済結果Ｔ０１０８が「２」の時
で当該オーダに対応する契約内容テーブルＴ０５００のレコードの申し込み再開日時Ｔ０５０５が現在より後である時
（３）当該レコードの決済方法Ｔ０１０６が長期型決済方法であり決済結果Ｔ０１０８が「１」で決済有効期限Ｔ０１０７が現在より後である時。
【０１１６】
以上述べた通り、本実施形態のネットワーク販売システムによれば、インターネットなどのコンピュータネットワークに接続された環境を使用し、商品やサービスを注文する際に、二重注文や二重決済の危険を防止し、正常に行われた決済が放置されることを防ぐことができ、注文者にとって安全な環境を提供することが可能となる。また決済システムへのキャンセル処理なども可能な限り自動化し、二重注文が禁止されている商品・サービスに対する二重注文を完全に防ぐことが可能となるので、サイト運営者の効率を高めることが可能となる。
【０１１７】
図１９として、図１に示したシステムを実現するハードウエア環境の一例を示す。注文者端末Ｓ１００、販売システムＳ２００、決済システムＳ４００は、インターネット等の広域ネットワーク１９０１に接続され、相互に通信を行える。注文者端末Ｓ１００は一般的なパーソナルコンピュータにウェブブラウザプログラムを実装したものであり、もちろんそのウェブブラウザプログラムが稼働可能な程度にメモリ等のハードウエア資源や、ネットワーク１９０１に接続するためのオペレーティングシステムやプロトコルスタック等のソフトウエア資源も含まれる。
【０１１８】
これは管理者端末Ｓ５００についても同様である。図１９の例では管理者端末Ｓ５００は販売システムＳ２００に含まれているが、ネットワーク１９０１を介して販売システムＳ２００と接続する構成とすることもできる。
【０１１９】
販売システムＳ２００は、図１９では複数のサーバコンピュータを含む。そして各コンピュータが、図１に含まれる各手段を、その手段により実現される手順を記述したプログラムを実行することで実現している。たとえば、図１７および図１８の流れ図は、このサーバコンピュータ２００１により実行されるプログラムの手順であり、これをコンピュータにより実行することで、申し込み受付手段Ｓ２１０および決済情報受付手段Ｓ２４０が販売システムＳ２００において実現される。販売システムＳ２００は１台のサーバコンピュータにより実現することもできる。その場合には、図１７及び図１８のプログラムは、同一のコンピュータにより実行される。
【０１２０】
また、情報保持手段Ｓ２７０もまたサーバコンピュータのひとつであるコンピュータ２００２により実現される。コンピュータ２０２は図１１〜図１６に示したテーブルを含むデータベースを格納するために十分なハードディスク等のストレージを有し、他のコンピュータからの検索、更新、追加コマンドを受信して、そのコマンドに応じた動作、すなわち指定された条件に適合するデータを読み、更新し、あるいは追加してコマンドの指示元に応答を返すなどの動作を行うデータベース管理プログラムを実行する。
【０１２１】
決済システムは、販売システムと同様にネットワークに接続されたコンピュータで構成される。したがって、販売システムＳ２００から決済システムへの情報の提供を行い、逆に提供を受ける場合には、ネットワーク１９０１を介してデータの送信および受信が行われる。これは販売システムＳ２００と注文者端末Ｓ１００との間、及び、決済システムＳ４１０と注文者端末Ｓ１００との間、および、販売システムＳ１００と管理者端末Ｓ５００との間においても全く同様である。ただし、販売システムＳ２００と決済システムＳ５００との間においては、特定の注文者に関する情報を交換する限りにおいては、その注文者端末Ｓ２００（のブラウザプログラム）を介して情報の送受信を行ってもよい。そうすることで、送受信の手順において注文者の意思確認操作を介入させることが容易となる。
【０１２２】
＜他の実施形態＞
本発明の目的は前述した実施形態の機能を実現するソフトウェアのプログラムコードを記録した記録媒体を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ（またはＣＰＵまたはＭＰＵ）が記録媒体に格納されたプログラムコードを読み出し実行することによっても、達成されることは言うまでもない。この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施形態の機能を実現することとなり、そのプログラムコードを記憶した記憶媒体は本発明を構成することになる。
【０１２３】
プログラムコードを供給するための記憶媒体としては、例えば、フロッピ（登録商標）ディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、磁気テープ、不揮発性のメモリカード、ＲＯＭ、ＤＶＤなどを用いることができる。
【０１２４】
またコンピュータが読み出したプログラムコードを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼動しているＯＳ（オペレーションシステム）などが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【０１２５】
さらに、記憶媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書きこまれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【０１２６】
【発明の効果】
以上述べた通り、本発明の情報処理方法、情報処理装置、情報処理システムおよ記憶媒体によれば、インターネットなどのコンピュータネットワークに接続された環境を使用し、商品やサービスを注文する際に、二重注文や二重決済の危険を防止し、正常に行われた決済が放置されることを防ぐことができ、注文者にとって安全な環境を提供することが可能となる。また決済システムへのキャンセル処理なども可能な限り自動化し、二重注文が禁止されている商品・サービスに対する二重注文を完全に防ぐことが可能となるので、サイト運営者の効率を高めることが可能となる。
【図面の簡単な説明】
【図１】本実施形態によるシステムの概略の構成を表す図である。
【図２】商品やサービスの申し込み開始の画面を表した図である。
【図３】商品やサービスの申し込みにおいて、注文者の情報を入力する画面を表した図である。
【図４】商品やサービスの申し込みにおいて、注文者と配送先の情報を入力する画面を表した図である。
【図５】クレジットカード会社が提供するクレジットカード番号と有効期限の入力画面を表した図である。
【図６】商品やサービスの申し込みにおいて、注文結果を表示する画面を表した図である。
【図７】商品やサービスの申し込みにおいて、重複した注文が存在することを表示する画面を表した図である。
【図８】システムの管理者向けに、注文を受けたオーダの一覧を表示する画面を表した図である。
【図９】システムの管理者向けに、注文を受けたオーダの詳細情報を表示する画面を表した図である。
【図１０】システムの管理者が注文の再開処理を行った際の結果を表示する画面を表した図である。
【図１１】注文情報を格納するテーブルのデータ構成例を示す図である。
【図１２】事前登録者の情報を格納するテーブルのデータ構成例を示す図である。
【図１３】注文者の情報を格納するテーブルのデータ構成例を示す図である。
【図１４】配送先の情報を格納するテーブルのデータ構成例を示す図である。
【図１５】契約内容の情報を格納するテーブルのデータ構成例を示す図である。
【図１６】商品の情報を格納するテーブルのデータ構成例を示す図である。
【図１７Ａ】申し込み受付手段におけるフローチャートである。
【図１７Ｂ】申し込み受付手段におけるフローチャートである。
【図１８Ａ】決済情報受付手段におけるフローチャートである。
【図１８Ｂ】決済情報受付手段におけるフローチャートである。
【図１９】システム全体のハードウエア構成の一例を示す図である。
Claims (10)
- 顧客からの注文を受け付ける注文受付手段と、
前記顧客が前記注文以外に同一種の注文を行っていないかを判断する重複注文判断手段と、
前記重複注文判断手段の判断結果を顧客に通知するよう制御する注文受付通知手段と、
前記注文を受付できると判定された注文についての情報を保持する情報保持手段と、
を有することを特徴とする情報処理装置。 - 外部決済システムへの情報を提供する決済情報提供手段と、
前記外部決済システムからの情報を受け付ける決済情報受付手段とをさらに備え、
前記注文受付通知手段はさらに、前記決済情報受付手段により受け取った情報に基づいて、前記注文の受け付けの可否を顧客に通知するよう制御し、前記情報保持手段はさらに前記外部決済情報も保持することを特徴とする請求項１に記載の情報処理装置。 - 前記決済情報提供手段及び決済情報受付手段は、前記注文受付手段により受け付けられた決済方法に応じた決済システムに対して情報の提供及び情報の受付を行うことを特徴とする請求項２に記載の情報処理装置。
- 前記外部決済システムからの情報を前記決済情報受付手段が受け付けることを失敗した場合に、当該注文に対する決済後の処理を再開する注文処理再開手段をさらに有し、
前記注文処理再開手段により処理の再開が行われる際に、前記重複注文判断手段によって注文のチェックを判断し、判断結果を管理者に通知するための管理者用注文受付可否通知手段をさらに有することを特徴とする請求項２または３に記載の情報処理装置。 - 前記注文処理再開手段により処理の再開が行われた際に、前記重複注文判断手段によって注文できないと判断された場合に、前記外部決済システムに対して当該注文の決済のキャンセル処理を要求するキャンセル情報提供手段をさらに有することを特徴とする請求項２乃至４のいずれか１項に記載の情報処理装置。
- 前記注文処理再開手段により処理の再開が行われた際に、前記重複注文判断手段によって注文できないと判断された場合に、管理者に対して前記外部決済システムに対してキャンセル処理を要求するよう通知するキャンセル情報通知手段をさらに有することを特徴とする請求項２乃至４のいずれか１項に記載の情報処理装置。
- 前記重複注文判断手段の判断結果に基づいて前記注文の受け付けの可否を表示する管理者用注文受付可否表示手段をさらに有することを特徴とする請求項１に記載の情報処理装置。
- 顧客からの注文を受け付ける注文受付工程と、
前記顧客が前記注文以外に同一種の注文を行っていないかを判断する重複注文判断工程と、
前記重複注文判断工程の判断結果を顧客に通知する注文受付通知工程と、
前記注文を受付できると判定された注文についての情報を情報保持手段により保持させる情報保持工程と、
を有することを特徴とする情報処理方法。 - 請求項１乃至６のいずれかに記載の装置をコンピュータで実現するために該コンピュータにより実行されるプログラム。
- 請求項９記載のプログラムを記録したコンピュータ可読の記憶媒体。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003142407A JP4328557B2 (ja) | 2003-05-20 | 2003-05-20 | 情報処理装置およびプログラム |
| US10/848,163 US7346557B2 (en) | 2003-05-20 | 2004-05-19 | Information processing apparatus and information processing method |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003142407A JP4328557B2 (ja) | 2003-05-20 | 2003-05-20 | 情報処理装置およびプログラム |
Publications (3)
| Publication Number | Publication Date |
|---|---|
| JP2004348269A true JP2004348269A (ja) | 2004-12-09 |
| JP2004348269A5 JP2004348269A5 (ja) | 2006-07-13 |
| JP4328557B2 JP4328557B2 (ja) | 2009-09-09 |
Family
ID=33530505
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2003142407A Expired - Fee Related JP4328557B2 (ja) | 2003-05-20 | 2003-05-20 | 情報処理装置およびプログラム |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US7346557B2 (ja) |
| JP (1) | JP4328557B2 (ja) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2006350468A (ja) * | 2005-06-13 | 2006-12-28 | Nippon Fukushi Net Kk | 生活支援システムとそのシステムを用いた商品・サービス提供方法 |
Families Citing this family (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2006092116A (ja) * | 2004-09-22 | 2006-04-06 | Canon Inc | Ｗｅｂサーバ及びその制御方法 |
| US8874477B2 (en) | 2005-10-04 | 2014-10-28 | Steven Mark Hoffberg | Multifactorial optimization system and method |
| US7647251B2 (en) * | 2006-04-03 | 2010-01-12 | Sap Ag | Process integration error and conflict handling |
| US20070276766A1 (en) | 2006-05-24 | 2007-11-29 | Carlos Antonio Lorenzo Hoyos | System and Method for Preventing Multiple Charges for a Transaction in a Payment System |
| US8731527B1 (en) * | 2010-09-22 | 2014-05-20 | Cellco Partnership | Automated voicemail preservation and deletion |
| US10721296B2 (en) * | 2017-12-04 | 2020-07-21 | International Business Machines Corporation | Optimized rolling restart of stateful services to minimize disruption |
| US10379985B1 (en) * | 2018-02-01 | 2019-08-13 | EMC IP Holding Company LLC | Automating and monitoring rolling cluster reboots |
| TWI682685B (zh) * | 2018-05-15 | 2020-01-11 | 聯華電信股份有限公司 | 通訊系統及其方法 |
| US11842382B2 (en) * | 2018-12-12 | 2023-12-12 | App8 Incorporated | Systems and methods for interfacing with point-of-sale systems and customer devices at an establishment |
Family Cites Families (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6237035B1 (en) * | 1997-12-18 | 2001-05-22 | International Business Machines Corporation | System and method for preventing duplicate transactions in an internet browser/internet server environment |
| US7003494B2 (en) * | 1999-02-03 | 2006-02-21 | International Business Machines Corporation | Preprocessor system and method for rejection of duplicate invoices |
| US7110969B1 (en) * | 1999-07-30 | 2006-09-19 | Crossmar, Inc. | Methods and systems for electronic order routing (CORS) |
| US20020143655A1 (en) * | 2001-04-02 | 2002-10-03 | Stephen Elston | Remote ordering system for mobile commerce |
| US7558758B2 (en) * | 2002-06-26 | 2009-07-07 | International Business Machines Corporation | Business event triggered, policy-driven payment management |
| US20040002886A1 (en) * | 2002-06-27 | 2004-01-01 | Dickerson William M. | System and method for processing a service order |
-
2003
- 2003-05-20 JP JP2003142407A patent/JP4328557B2/ja not_active Expired - Fee Related
-
2004
- 2004-05-19 US US10/848,163 patent/US7346557B2/en not_active Expired - Fee Related
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2006350468A (ja) * | 2005-06-13 | 2006-12-28 | Nippon Fukushi Net Kk | 生活支援システムとそのシステムを用いた商品・サービス提供方法 |
Also Published As
| Publication number | Publication date |
|---|---|
| JP4328557B2 (ja) | 2009-09-09 |
| US7346557B2 (en) | 2008-03-18 |
| US20050004847A1 (en) | 2005-01-06 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4914533B2 (ja) | 情報処理装置及び情報処理方法 | |
| US20030036987A1 (en) | Method and system for handling escrow arrangements | |
| US20080140838A1 (en) | Electronic service system using main site server and partner site server | |
| US20040034567A1 (en) | On-line transactions and system therefore | |
| JP4328557B2 (ja) | 情報処理装置およびプログラム | |
| JP2008112326A (ja) | 決済処理システム、サービス提供サーバ、認証課金サーバ、決済処理方法及びプログラム | |
| JP5128176B2 (ja) | 物件情報管理装置及び物件情報管理方法 | |
| KR20230150909A (ko) | 이알피 연계형 전자 구매 시스템 및 그 방법 | |
| JPWO2003038700A1 (ja) | 商品に係わる情報を通知する方法 | |
| JP2004503019A (ja) | 電子コマース介在システムおよび方法 | |
| JP2020144514A (ja) | 海外対応アプリケーション販売管理サーバシステム | |
| KR20110035571A (ko) | 위젯을 이용한 쇼핑 서비스 제공 장치 및 방법 | |
| JP2002329071A (ja) | 保険処理サーバ、そのコンピュータプログラム、保険処理システム及びその処理方法 | |
| KR101662707B1 (ko) | 중고 물품 관리 시스템 및 이를 이용한 중고 물품의 거래 시스템 | |
| US20120116899A1 (en) | Management of prospective customer data over a communications network | |
| JP2006202335A (ja) | オンラインショップサーバ上の商品を自動注文する処理をコンピュータに実行させるための自動注文プログラム、前記自動注文プログラムを記録した記録媒体、自動注文装置及び自動注文システム | |
| JP4009430B2 (ja) | 駐車場物件契約サーバ装置、方法及びプログラム | |
| JP2004265268A (ja) | 商品又はサービス情報処理システム及び方法 | |
| KR20060121430A (ko) | 소프트웨어 컨텐츠 다이렉트 다운로드 서비스 시스템 및방법 | |
| JP2020144515A (ja) | 海外対応アプリケーション販売管理システム | |
| JP7314112B2 (ja) | 配送管理装置、配送管理方法及びプログラム | |
| US20220335491A1 (en) | Method and system for providing electronic commerce service using partnership service cart realized by api in shopping mall | |
| KR102704625B1 (ko) | 상품거래 서비스를 제공하는 방법 및 그 전자장치 | |
| JP5548033B2 (ja) | 予約処理装置、予約処理プログラム、コンピュータ読み取り可能な記録媒体及び予約処理方法 | |
| JP5552030B2 (ja) | 商品の販売および配送のためのシステム、方法 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20060522 |
|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20060522 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20081215 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20081219 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20090213 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20090319 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20090518 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20090605 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20090615 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120619 Year of fee payment: 3 |
|
| R150 | Certificate of patent or registration of utility model |
Ref document number: 4328557 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120619 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130619 Year of fee payment: 4 |
|
| LAPS | Cancellation because of no payment of annual fees |