(57)【要約】【課題】通信を介した商品販売手続の途中で通信が切断された場合に、商品販売手続の経過を速やかに調査する。【解決手段】商店サーバ１００はユーザ端末３００から商品購入申込を受けると、決済サーバ２００に決済依頼をする際、仮受注データベース１８０の仮受注テーブルに仮受注データを挿入する。決済サーバ２００は決済処理を行い、その結果を商店サーバ１００に通知する。決済処理が完了すると、商店サーバ１００はユーザ端末３００に決済完了表示をする。この一連の通信が途切れた場合、商店サーバ１００は仮受注データに基づいて決済サーバ２００と通信することにより決済処理の状況を解明する。【選択図】　　　図１
2004021780.tif 000002
【特許請求の範囲】
【請求項１】
受注データを保持する受注テーブルを格納する受注データベースと、
仮受注データを保持する仮受注テーブルを格納する仮受注データベースと、
決済処理を行い、この決済処理の結果を報告する決済サーバと、
商品購入申込を受け、この商品購入申込に対応する前記仮受注データが前記仮受注テーブルに存在する場合には前記決済サーバに前記決済処理が完了したか否かを確認して前記決済処理が完了していれば前記商品購入申込に対応する前記受注データを前記受注テーブルに挿入するとともに受注が完了している旨を表示し、前記決済処理が完了していなければ前記仮受注データを削除する商店サーバとを具備することを特徴とする商品販売システム。
【請求項２】
前記商店サーバに対して前記商品購入申込を出力するユーザ端末をさらに具備することを特徴とする請求項１記載の商品販売システム。
【請求項３】
商品購入申込を受ける手段と、
決済処理の結果を確認する確認手段と、
前記商品購入申込に対応する仮受注データが仮受注テーブルに存在する場合には前記決済処理の結果を前記確認手段に確認させて前記決済処理が完了していれば前記商品購入申込に対応する受注データを受注テーブルに挿入し、前記決済処理が完了していなければ前記仮受注データを前記仮受注テーブルから削除する手段と
を具備することを特徴とする商店サーバ。
【請求項４】
前記決済処理が完了していない場合には前記商品購入申込に対応する第二の仮受注データを前記仮受注テーブルに挿入した上で第二の決済処理を依頼する手段と、
前記第二の決済処理が完了すれば前記商品購入申込に対応する第二の受注データを前記受注テーブルに挿入し、前記第二の決済処理が完了しなければ前記第二の仮受注データを前記仮受注テーブルから削除する手段と
をさらに具備することを特徴とする請求項３記載の商店サーバ。
【請求項５】
前記商品購入申込に対応する仮受注データが仮受注テーブルに存在しない場合には前記商品購入申込に対応する第二の仮受注データを前記仮受注テーブルに挿入した上で第二の決済処理を依頼する手段と、
前記第二の決済処理が完了すれば前記商品購入申込に対応する第二の受注データを前記受注テーブルに挿入し、前記第二の決済処理が完了しなければ前記第二の仮受注データを前記仮受注テーブルから削除する手段と
をさらに具備することを特徴とする請求項３記載の商店サーバ。
【請求項６】
前記商品購入申込に対応する受注データが前記受注テーブルに存在するか否かを調べ、前記商品購入申込に対応する受注データが前記受注テーブルに存在する場合には受注が完了している旨を表示し、前記商品購入申込に対応する受注データが前記受注テーブルに存在しない場合にはさらに前記商品購入申込に対応する仮受注データが仮受注テーブルに存在するか否かを調べ、前記商品購入申込に対応する仮受注データが仮受注テーブルに存在する場合には前記決済処理の結果を前記確認手段に確認させて前記決済処理が完了していれば受注が完了している旨を表示する手段
をさらに具備することを特徴とする請求項３記載の商店サーバ。
【請求項７】
前記商品がダウンロードにより提供される場合において、前記商品購入申込に対応する前記受注データが前記受注テーブルに存在する場合には所定のダウンロード回数に達していなければダウンロードを許可する旨を表示し、所定のダウンロード回数に達していればダウンロードを許可しない旨を表示する手段
をさらに具備することを特徴とする請求項６記載の商店サーバ。
【請求項８】
前記商品が配送により提供される場合において、前記商品購入申込に対応する前記受注データが前記受注テーブルに存在し、または、前記商品購入申込に対応する前記仮受注データが前記仮受注テーブルに存在してかつ前記決済処理が完了している場合に、再購入の意思確認を促す手段
をさらに具備することを特徴とする請求項６記載の商店サーバ。
【請求項９】
商品購入申込を受ける端末インタフェースと、
決済処理の結果を確認する決済結果確認部と、
前記商品購入申込に対応する仮受注データが仮受注テーブルに存在する場合には前記決済処理の結果を前記決済結果確認部に確認させて前記決済処理が完了していれば前記商品購入申込に対応する受注データを受注テーブルに挿入し、前記決済処理が完了していなければ前記仮受注データを前記仮受注テーブルから削除する受注管理部と
を具備することを特徴とする商店サーバ。
【請求項１０】
前記決済処理が完了していない場合には前記商品購入申込に対応する第二の仮受注データを前記仮受注テーブルに挿入した上で第二の決済処理を依頼する決済依頼部をさらに具備し、
前記受注管理部は、前記第二の決済処理が完了すれば前記商品購入申込に対応する第二の受注データを前記受注テーブルに挿入し、前記第二の決済処理が完了しなければ前記第二の仮受注データを前記仮受注テーブルから削除することを特徴とする請求項９記載の商店サーバ。
【請求項１１】
前記商品購入申込に対応する仮受注データが仮受注テーブルに存在しない場合には前記商品購入申込に対応する第二の仮受注データを前記仮受注テーブルに挿入した上で第二の決済処理を依頼する決済依頼部をさらに具備し、
前記受注管理部は、前記第二の決済処理が完了すれば前記商品購入申込に対応する第二の受注データを前記受注テーブルに挿入し、前記第二の決済処理が完了しなければ前記第二の仮受注データを前記仮受注テーブルから削除することを特徴とする請求項９記載の商店サーバ。
【請求項１２】
前記受注管理部は、前記商品購入申込に対応する受注データが前記受注テーブルに存在するか否かを調べ、前記商品購入申込に対応する受注データが前記受注テーブルに存在する場合には受注が完了している旨を表示するよう前記端末インタフェースに指示し、前記商品購入申込に対応する受注データが前記受注テーブルに存在しない場合にはさらに前記商品購入申込に対応する仮受注データが仮受注テーブルに存在するか否かを調べ、前記商品購入申込に対応する仮受注データが仮受注テーブルに存在する場合には前記決済処理の結果を前記決済結果確認部に確認させて前記決済処理が完了していれば受注が完了している旨を表示するよう前記端末インタフェースに指示し、
前記端末インタフェースは、前記受注管理部からの指示により受注が完了している旨を表示することを特徴とする請求項９記載の商店サーバ。
【請求項１３】
前記受注管理部は、前記商品がダウンロードにより提供される場合において、前記商品購入申込に対応する前記受注データが前記受注テーブルに存在する場合には所定のダウンロード回数に達していなければダウンロードを許可する旨を、所定のダウンロード回数に達していればダウンロードを許可しない旨をそれぞれ表示するよう前記端末インタフェースに指示し、
前記端末インタフェースは、前記受注管理部の指示により、所定のダウンロード回数に達していなければダウンロードを許可する旨を表示し、所定のダウンロード回数に達していればダウンロードを許可しない旨を表示することを特徴とする請求項１２記載の商店サーバ。
【請求項１４】
前記受注管理部は、前記商品が配送により提供される場合において、前記商品購入申込に対応する前記受注データが前記受注テーブルに存在し、または、前記商品購入申込に対応する前記仮受注データが前記仮受注テーブルに存在してかつ前記決済処理が完了している場合に、再購入の意思確認を促すよう前記端末インタフェースに指示し、
前記端末インタフェースは、前記受注管理部からの指示により前記再購入の意思確認を促すことを特徴とする請求項１２記載の商店サーバ。
【請求項１５】
コンピュータが商品購入申込を受ける手順と、
前記商品購入申込に対応する仮受注データが仮受注テーブルに存在するか否かをコンピュータが調べる手順と、
前記商品購入申込に対応する仮受注データが仮受注テーブルに存在する場合には決済処理の結果をコンピュータが確認する手順と、
前記決済処理が完了していれば前記商品購入申込に対応する受注データを受注テーブルにコンピュータが挿入する手順と、
前記決済処理が完了していなければ前記仮受注データを前記仮受注テーブルからコンピュータが削除する手順と
を具備することを特徴とする商品販売方法。
【請求項１６】
前記決済処理が完了していない場合には前記商品購入申込に対応する第二の仮受注データを前記仮受注テーブルにコンピュータが挿入した上で第二の決済処理をコンピュータが依頼する手順と、
前記第二の決済処理が完了すれば前記商品購入申込に対応する第二の受注データを前記受注テーブルにコンピュータが挿入する手順と、
前記第二の決済処理が完了しなければ前記第二の仮受注データを前記仮受注テーブルからコンピュータが削除する手順と
をさらに具備することを特徴とする請求項１５記載の商品販売方法。
【請求項１７】
前記商品購入申込に対応する仮受注データが仮受注テーブルに存在しない場合には前記商品購入申込に対応する第二の仮受注データを前記仮受注テーブルにコンピュータが挿入した上で第二の決済処理をコンピュータが依頼する手順と、
前記第二の決済処理が完了すれば前記商品購入申込に対応する第二の受注データを前記受注テーブルにコンピュータが挿入する手順と、
前記第二の決済処理が完了しなければ前記第二の仮受注データを前記仮受注テーブルからコンピュータが削除する手順と
をさらに具備することを特徴とする請求項１５記載の商品販売方法。
【請求項１８】
前記商品購入申込に対応する受注データが前記受注テーブルに存在するか否かをコンピュータが調べる手順と、
前記商品購入申込に対応する受注データが前記受注テーブルに存在する場合には受注が完了している旨をコンピュータが表示する手順と、
前記商品購入申込に対応する受注データが前記受注テーブルに存在しない場合にはさらに前記商品購入申込に対応する仮受注データが仮受注テーブルに存在するか否かをコンピュータが調べる手順と、
前記商品購入申込に対応する仮受注データが仮受注テーブルに存在する場合には前記決済処理の結果をコンピュータが確認する手順と、
前記決済処理が完了していれば受注が完了している旨をコンピュータが表示する手順と
をさらに具備することを特徴とする請求項１５記載の商品販売方法。
【請求項１９】
前記商品がダウンロードにより提供される場合において、前記商品購入申込に対応する前記受注データが前記受注テーブルに存在するときに所定のダウンロード回数に達しているか否かをコンピュータが調べる手順と、
所定のダウンロード回数に達していなければダウンロードを許可する旨をコンピュータが表示する手順と、
所定のダウンロード回数に達していればダウンロードを許可しない旨をコンピュータが表示する手順と
をさらに具備することを特徴とする請求項１８記載の商品販売方法。
【請求項２０】
前記商品が配送により提供される場合において、
前記商品購入申込に対応する前記受注データが前記受注テーブルに存在し、または、前記商品購入申込に対応する前記仮受注データが前記仮受注テーブルに存在してかつ前記決済処理が完了している場合に、コンピュータが再購入の意思確認を促す手順をさらに具備することを特徴とする請求項１８記載の商品販売方法。
【請求項２１】
商品購入申込を受ける手順と、
前記商品購入申込に対応する仮受注データが仮受注テーブルに存在するか否かを調べる手順と、
前記商品購入申込に対応する仮受注データが仮受注テーブルに存在する場合には前記決済処理の結果を確認する手順と、
前記決済処理が完了していれば前記商品購入申込に対応する受注データを受注テーブルに挿入する手順と、
前記決済処理が完了していなければ前記仮受注データを前記仮受注テーブルから削除する手順と
をコンピュータに実行させるためのプログラムを記録したことを特徴とするコンピュータ読み取り可能な記録媒体。
【請求項２２】
前記決済処理が完了していない場合には前記商品購入申込に対応する第二の仮受注データを前記仮受注テーブルに挿入した上で第二の決済処理を前記決済サーバに依頼する手順と、
前記第二の決済処理が完了すれば前記商品購入申込に対応する第二の受注データを前記受注テーブルに挿入する手順と、
前記第二の決済処理が完了しなければ前記第二の仮受注データを前記仮受注テーブルから削除する手順と
をさらにコンピュータに実行させるためのプログラムを記録したことを特徴とする請求項２１記載のコンピュータ読み取り可能な記録媒体。
【請求項２３】
前記商品購入申込に対応する仮受注データが仮受注テーブルに存在しない場合には前記商品購入申込に対応する第二の仮受注データを前記仮受注テーブルに挿入した上で第二の決済処理を前記決済サーバに依頼する手順と、
前記第二の決済処理が完了すれば前記商品購入申込に対応する第二の受注データを前記受注テーブルに挿入する手順と、
前記第二の決済処理が完了しなければ前記第二の仮受注データを前記仮受注テーブルから削除する手順と
をさらにコンピュータに実行させるためのプログラムを記録したことを特徴とする請求項２１記載のコンピュータ読み取り可能な記録媒体。
【請求項２４】
前記商品購入申込に対応する受注データが前記受注テーブルに存在するか否かを調べる手順と、
前記商品購入申込に対応する受注データが前記受注テーブルに存在する場合には受注が完了している旨を表示する手順と、
前記商品購入申込に対応する受注データが前記受注テーブルに存在しない場合にはさらに前記商品購入申込に対応する仮受注データが仮受注テーブルに存在するか否かを調べる手順と、
前記商品購入申込に対応する仮受注データが仮受注テーブルに存在する場合には前記決済処理の結果を確認する手順と、
前記決済処理が完了していれば受注が完了している旨を表示する手順と
をさらにコンピュータに実行させるためのプログラムを記録したことを特徴とする請求項２１記載のコンピュータ読み取り可能な記録媒体。
【請求項２５】
前記商品がダウンロードにより提供される場合において、前記商品購入申込に対応する前記受注データが前記受注テーブルに存在するときに所定のダウンロード回数に達しているか否かを調べる手順と、
所定のダウンロード回数に達していなければダウンロードを許可する旨を表示する手順と、
所定のダウンロード回数に達していればダウンロードを許可しない旨を表示する手順と
をさらにコンピュータに実行させるためのプログラムを記録したことを特徴とする請求項２４記載のコンピュータ読み取り可能な記録媒体。
【請求項２６】
前記商品が配送により提供される場合において、
前記商品購入申込に対応する前記受注データが前記受注テーブルに存在し、または、前記商品購入申込に対応する前記仮受注データが前記仮受注テーブルに存在してかつ前記決済処理が完了している場合に、再購入の意思確認を促す手順をさらにコンピュータに実行させるためのプログラムを記録したことを特徴とする請求項２４記載のコンピュータ読み取り可能な記録媒体。
【請求項２７】
商品購入申込を受ける手順と、
前記商品購入申込に対応する仮受注データが仮受注テーブルに存在するか否かを調べる手順と、
前記商品購入申込に対応する仮受注データが仮受注テーブルに存在する場合には前記決済処理の結果を確認する手順と、
前記決済処理が完了していれば前記商品購入申込に対応する受注データを受注テーブルに挿入する手順と、
前記決済処理が完了していなければ前記仮受注データを前記仮受注テーブルから削除する手順と
をコンピュータに実行させることを特徴とするプログラム。
【請求項２８】
前記決済処理が完了していない場合には前記商品購入申込に対応する第二の仮受注データを前記仮受注テーブルに挿入した上で第二の決済処理を前記決済サーバに依頼する手順と、
前記第二の決済処理が完了すれば前記商品購入申込に対応する第二の受注データを前記受注テーブルに挿入する手順と、
前記第二の決済処理が完了しなければ前記第二の仮受注データを前記仮受注テーブルから削除する手順と
をさらにコンピュータに実行させることを特徴とする請求項２７記載のプログラム。
【請求項２９】
前記商品購入申込に対応する仮受注データが仮受注テーブルに存在しない場合には前記商品購入申込に対応する第二の仮受注データを前記仮受注テーブルに挿入した上で第二の決済処理を前記決済サーバに依頼する手順と、
前記第二の決済処理が完了すれば前記商品購入申込に対応する第二の受注データを前記受注テーブルに挿入する手順と、
前記第二の決済処理が完了しなければ前記第二の仮受注データを前記仮受注テーブルから削除する手順と
をさらにコンピュータに実行させることを特徴とする請求項２７記載のプログラム。
【請求項３０】
前記商品購入申込に対応する受注データが前記受注テーブルに存在するか否かを調べる手順と、
前記商品購入申込に対応する受注データが前記受注テーブルに存在する場合には受注が完了している旨を表示する手順と、
前記商品購入申込に対応する受注データが前記受注テーブルに存在しない場合にはさらに前記商品購入申込に対応する仮受注データが仮受注テーブルに存在するか否かを調べる手順と、
前記商品購入申込に対応する仮受注データが仮受注テーブルに存在する場合には前記決済処理の結果を確認する手順と、
前記決済処理が完了していれば受注が完了している旨を表示する手順と
をさらにコンピュータに実行させることを特徴とする請求項２７記載のプログラム。
【請求項３１】
前記商品がダウンロードにより提供される場合において、前記商品購入申込に対応する前記受注データが前記受注テーブルに存在するときに所定のダウンロード回数に達しているか否かを調べる手順と、
所定のダウンロード回数に達していなければダウンロードを許可する旨を表示する手順と、
所定のダウンロード回数に達していればダウンロードを許可しない旨を表示する手順と
をさらにコンピュータに実行させることを特徴とする請求項３０記載のプログラム。
【請求項３２】
前記商品が配送により提供される場合において、
前記商品購入申込に対応する前記受注データが前記受注テーブルに存在し、または、前記商品購入申込に対応する前記仮受注データが前記仮受注テーブルに存在してかつ前記決済処理が完了している場合に、再購入の意思確認を促す手順をさらにコンピュータに実行させることを特徴とする請求項３０記載のプログラム。
【請求項３３】
商店サーバと、決済サーバと、前記商店サーバと前記決済サーバとの間を接続する第一の通信手段と、前記商店サーバと前記決済サーバとの間を接続する第二の通信手段とを備える商品販売システムであって、
前記商店サーバは、
商品購入申込を受ける端末インタフェースと、
前記第一の通信手段により前記決済サーバに決済処理を依頼する決済依頼部と、
前記第二の通信手段により前記決済サーバに前記決済処理の結果確認を依頼する決済結果確認部と、
前記商品購入申込に対応する受注データが受注テーブルに存在せず、かつ、仮受注データが仮受注テーブルに存在しない場合には前記決済依頼部により前記決済処理を依頼し、前記仮受注データが前記仮受注テーブルに存在する場合には前記決済処理の結果を前記決済結果確認部に確認させて前記決済処理が完了していれば前記商品購入申込に対応する前記受注データを前記受注テーブルに挿入し、前記決済処理が完了していなければ前記仮受注データを前記仮受注テーブルから削除する受注管理部と、
を具備し、
前記決済サーバは、
前記商店サーバから前記決済処理の依頼を受けて前記第一の通信手段により前記商店サーバに前記決済処理の結果を通知する決済受付部と、
前記商店サーバからの前記決済処理の結果確認依頼を受けて前記第二の通信手段により前記商店サーバに前記決済処理の結果を通知する決済結果応答部と、前記決済受付部が受けた前記決済処理の依頼に応答して前記決済処理を行ってその結果を前記決済受付部に通知し、前記決済結果応答部が受けた前記決済処理の結果確認依頼に応答して前記決済処理の結果を前記決済結果応答部に通知する決済処理部とを具備する
ことを特徴とする商品販売システム。
【請求項３４】
前記第一の通信手段と前記第二の通信手段とは、互いに独立して通信を行うことを特徴とする請求項３３記載の商品販売システム。
【請求項３５】
前記商品購入申込を出力するユーザ端末をさらに含み、
前記第一の通信手段は前記ユーザ端末の状態と同調して通信を進行させ、
前記第二の通信手段は前記ユーザ端末の状態と同調せずに通信を進行させることを特徴とする請求項３４記載の商品販売システム。
【請求項３６】
前記決済サーバは、決済代行サーバと、決済実行サーバと、前記決済代行サーバと前記決済実行サーバとの間を接続する第三の通信手段と、前記決済代行サーバと前記決済実行サーバとの間を接続する第四の通信手段とを備え、
前記決済代行サーバは、
前記商店サーバから前記決済処理の依頼を受けて前記第一の通信手段により前記商店サーバに前記決済処理の結果を通知する決済代行受付部と、
前記商店サーバからの前記決済処理の結果確認依頼を受けて前記第二の通信手段により前記商店サーバに前記決済処理の結果を通知する決済結果代行応答部と、
前記第三の通信手段により前記決済実行サーバに前記決済処理を依頼する決済代行依頼部と、
前記第四の通信手段により前記決済実行サーバに前記決済処理の結果確認を依頼する決済結果代行確認部と、
前記決済代行受付部が受けた前記決済処理の依頼に応答して前記決済代行依頼部に決済処理を依頼させてその結果を前記決済代行受付部に通知し、前記決済結果代行応答部が受けた前記決済処理の結果確認依頼に応答して前記決済結果代行確認部に前記決済処理の結果確認を依頼させてその結果を前記決済結果代行応答部に通知する振分け部とを具備し、
前記決済実行サーバは、
前記決済代行サーバから前記決済処理の依頼を受けて前記第三の通信手段により前記決済代行サーバに前記決済処理の結果を通知する決済実行受付部と、
前記決済代行サーバからの前記決済処理の結果確認依頼を受けて前記第四の通信手段により前記決済代行サーバに前記決済処理の結果を通知する決済実行結果応答部と、
前記決済実行受付部が受けた前記決済処理の依頼に応答して前記決済処理を行ってその結果を前記決済実行受付部に通知し、前記決済実行結果応答部が受けた前記決済処理の結果確認依頼に応答して前記決済処理の結果を前記決済実行結果応答部に通知する決済実行処理部とを具備する
ことを特徴とする請求項３３記載の商品販売システム。
【請求項３７】
前記第一の通信手段と前記第二の通信手段とは、互いに独立して通信を行い、
前記第三の通信手段と前記第四の通信手段とは、互いに独立して通信を行うことを特徴とする請求項３６記載の商品販売システム。
【請求項３８】
前記商品購入申込を出力するユーザ端末をさらに含み、
前記第一の通信手段および前記第三の通信手段は前記ユーザ端末の状態と同調して通信を進行させ、
前記第二の通信手段および前記第四の通信手段は前記ユーザ端末の状態と同調せずに通信を進行させることを特徴とする請求項３７記載の商品販売システム。
【発明の詳細な説明】
【発明の属する技術分野】
本発明は、商品販売システム、商店サーバ、商品販売方法、および、商品販売方法を実行させるためのプログラムならびにその記録媒体に関し、例えば通信を介した商品販売の途中で通信が切断された場合に復旧を行う商品販売システムに適用して好適なものに関する。なお、ここにいう商品は有形物としての商品に限られず、ダウンロードにより提供されるコンテンツや、役務を含む広い概念を意味するものとする。
【０００１】
【従来の技術】
従来この種の技術では、商品購入者は商品を販売する商店サーバに通信を介して接続し、商店サーバの提供する商品一覧から商品を選択し、商品購入を申し込む。商店サーバは商品購入者からの商品購入申込を受けた後、決済サーバに対して決済処理を依頼する。決済サーバでは決済処理を行い、その結果を商店サーバに通知する。その結果、決済処理が正常に完了すれば、商店サーバは商品購入者に対してその旨を伝え、商品の発送手続を進める。
【０００２】
【発明が解決しようとする課題】
上述の従来技術では、一連の商品販売の流れにおいて通信の接続状態が継続していることを前提としており、通信が途絶えた場合には商品購入が成立したか否かについて調査するために時間を要することになる。このような通信の切断は、通信経路の障害に起因する場合もあるが、商品購入者が端末の操作を行う過程で誤ってブラウザ（通信アプリケーション）を閉じてしまう等の要因により不可避的に生じるおそれがある。このことは、特に、商品の発送を急ぐ場合や商品がダウンロードにより即座に提供されるような場合に、商品購入者に対して商品入手の可否を速やかに通知することができないという問題を発生させる。
【０００３】
本発明の目的は、通信を介した商品販売手続の途中で通信が切断された場合に、商品販売手続の経過を速やかに調査することにある。
【０００４】
【課題を解決するための手段】
上記課題を解決するために本発明の商品販売システムは、受注データを保持する受注テーブルを格納する受注データベースと、仮受注データを保持する仮受注テーブルを格納する仮受注データベースと、決済処理を行なってその決済処理の結果を報告する決済サーバと、商品購入申込を受けてこの商品購入申込に対応する上記仮受注データが上記仮受注テーブルに存在する場合には上記決済サーバに上記決済処理が完了したか否かを確認して上記決済処理が完了していれば上記商品購入申込に対応する上記受注データを上記受注テーブルに挿入するとともに受注が完了している旨を表示し、上記決済処理が完了していなければ上記仮受注データを削除する商店サーバとを具備する。これにより、商品販売手続の途中で通信が切断された場合に、商店サーバから決済サーバに決済処理が完了したか否かの確認を速やかに行う機能を提供する。
【０００５】
また、本発明の他の商品販売システムは、上記商店サーバに対して上記商品購入申込を出力するユーザ端末をさらに具備することにより、商品購入申込を行う機能を商品購入者に提供する。
【０００６】
また、本発明の商店サーバは、商品購入申込を受ける手段と、決済サーバに決済処理の結果を確認する確認手段と、上記商品購入申込に対応する仮受注データが仮受注テーブルに存在する場合には上記決済処理の結果を上記確認手段に確認させて上記決済処理が完了していれば上記商品購入申込に対応する受注データを受注テーブルに挿入し、上記決済処理が完了していなければ上記仮受注データを上記仮受注テーブルから削除する手段とを具備する。これにより、商品販売手続の途中で通信が切断された場合に、決済サーバに対して決済処理が完了したか否かの確認を速やかに行う機能を提供する。
【０００７】
また、本発明の他の商店サーバは、上記決済処理が完了していない場合には上記商品購入申込に対応する第二の仮受注データを上記仮受注テーブルに挿入した上で第二の決済処理を上記決済サーバに依頼する手段と、上記第二の決済処理が完了すれば上記商品購入申込に対応する第二の受注データを上記受注テーブルに挿入し、上記第二の決済処理が完了しなければ上記第二の仮受注データを上記仮受注テーブルから削除する手段とをさらに具備することにより、決済処理が完了していない場合に新たに決済処理を決済サーバに依頼するという機能を提供する。
【０００８】
また、本発明の他の商店サーバは、上記商品購入申込に対応する仮受注データが仮受注テーブルに存在しない場合には上記商品購入申込に対応する第二の仮受注データを上記仮受注テーブルに挿入した上で第二の決済処理を上記決済サーバに依頼する手段と、上記第二の決済処理が完了すれば上記商品購入申込に対応する第二の受注データを上記受注テーブルに挿入し、上記第二の決済処理が完了しなければ上記第二の仮受注データを上記仮受注テーブルから削除する手段とをさらに具備することにより、商品購入申込に対応する仮受注データが仮受注テーブルに存在しない場合に新たに決済処理を決済サーバに依頼するという機能を提供する。
【０００９】
また、本発明の他の商店サーバは、上記商品購入申込に対応する受注データが上記受注テーブルに存在するか否かを調べ、上記商品購入申込に対応する受注データが上記受注テーブルに存在する場合には受注が完了している旨を表示し、上記商品購入申込に対応する受注データが上記受注テーブルに存在しない場合にはさらに上記商品購入申込に対応する仮受注データが仮受注テーブルに存在するか否かを調べ、上記商品購入申込に対応する仮受注データが仮受注テーブルに存在する場合には上記決済処理の結果を上記確認手段に確認させて上記決済処理が完了していれば受注が完了している旨を表示する手段をさらに具備することにより、商品購入状況を表示する機能を提供する。
【００１０】
また、本発明の他の商店サーバは、上記商品がダウンロードにより提供される場合において、上記商品購入申込に対応する上記受注データが上記受注テーブルに存在する場合には所定のダウンロード回数に達していなければダウンロードを許可する旨を表示し、所定のダウンロード回数に達していればダウンロードを許可しない旨を表示する手段をさらに具備することにより、ダウンロードにより提供される商品の性質に応じた商品購入状況を表示する機能を提供する。
【００１１】
また、本発明の他の商店サーバは、上記商品が配送により提供される場合において、上記商品購入申込に対応する上記受注データが上記受注テーブルに存在し、または、上記商品購入申込に対応する上記仮受注データが上記仮受注テーブルに存在してかつ上記決済処理が完了している場合に、再購入の意思確認を促す手段をさらに具備することにより、配送により提供される商品の性質に応じた商品購入状況を表示する機能を提供する。
【００１２】
また、本発明の他の商品販売システムは、商店サーバと、決済サーバと、前記商店サーバと前記決済サーバとの間を接続する第一の通信手段と、前記商店サーバと前記決済サーバとの間を接続する第二の通信手段とを備える商品販売システムであって、前記商店サーバは、商品購入申込を受ける手段と、前記第一の通信手段により前記決済サーバに決済処理を依頼する決済依頼手段と、前記第二の通信手段により前記決済サーバに前記決済処理の結果確認を依頼する決済結果確認手段と、前記商品購入申込に対応する受注データが受注テーブルに存在せず、かつ、仮受注データが仮受注テーブルに存在しない場合には前記決済依頼手段により前記決済処理を依頼する手段と、前記仮受注データが前記仮受注テーブルに存在する場合には前記決済処理の結果を前記決済結果確認手段に確認させて前記決済処理が完了していれば前記商品購入申込に対応する前記受注データを前記受注テーブルに挿入し、前記決済処理が完了していなければ前記仮受注データを前記仮受注テーブルから削除する手段とを具備し、前記決済サーバは、前記商店サーバから前記決済処理の依頼を受けて前記第一の通信手段により前記商店サーバに前記決済処理の結果を通知する決済受付手段と、前記商店サーバからの前記決済処理の結果確認依頼を受けて前記第二の通信手段により前記商店サーバに前記決済処理の結果を通知する決済結果応答手段と、前記決済受付手段が受けた前記決済処理の依頼に応答して前記決済処理を行ってその結果を前記決済受付手段に通知し、前記決済結果応答手段が受けた前記決済処理の結果確認依頼に応答して前記決済処理の結果を前記決済結果応答手段に通知する決済処理手段とを具備する。これにより、商品販売手続の途中で通信が切断された場合に、商店サーバから決済サーバに決済処理が完了したか否かの確認を速やかに行う機能を提供する。
【００１３】
また、本発明の他の商品販売システムにおいて、前記決済サーバは、決済代行サーバと、決済実行サーバと、前記決済代行サーバと前記決済実行サーバとの間を接続する第三の通信手段と、前記決済代行サーバと前記決済実行サーバとの間を接続する第四の通信手段とを備え、前記決済代行サーバは、前記商店サーバから前記決済処理の依頼を受けて前記第一の通信手段により前記商店サーバに前記決済処理の結果を通知する決済代行受付手段と、前記商店サーバからの前記決済処理の結果確認依頼を受けて前記第二の通信手段により前記商店サーバに前記決済処理の結果を通知する決済結果代行応答手段と、前記第三の通信手段により前記決済実行サーバに前記決済処理を依頼する決済代行依頼手段と、前記第四の通信手段により前記決済実行サーバに前記決済処理の結果確認を依頼する決済結果代行確認手段と、前記決済代行受付手段が受けた前記決済処理の依頼に応答して前記決済代行依頼手段に決済処理を依頼させてその結果を前記決済代行受付手段に通知し、前記決済結果代行応答手段が受けた前記決済処理の結果確認依頼に応答して前記決済結果代行確認手段に前記決済処理の結果確認を依頼させてその結果を前記決済結果代行応答手段に通知する振分け手段とを具備し、前記決済実行サーバは、前記決済代行サーバから前記決済処理の依頼を受けて前記第三の通信手段により前記決済代行サーバに前記決済処理の結果を通知する決済実行受付手段と、前記決済代行サーバからの前記決済処理の結果確認依頼を受けて前記第四の通信手段により前記決済代行サーバに前記決済処理の結果を通知する決済実行結果応答手段と、前記決済実行受付手段が受けた前記決済処理の依頼に応答して前記決済処理を行ってその結果を前記決済実行受付手段に通知し、前記決済実行結果応答手段が受けた前記決済処理の結果確認依頼に応答して前記決済処理の結果を前記決済実行結果応答手段に通知する決済実行処理手段とを具備する。これにより、決済サーバを決済代行サーバと決済実行サーバとに分散させた分散環境においても上述の仮受注テーブルに基づく決済処理完了の調査を速やかに行う機能を提供する。
【００１４】
また、本発明の他の商品販売システムにおいて、前記第一の通信手段と前記第二の通信手段とは互いに独立して通信を行い、前記第三の通信手段と前記第四の通信手段とは互いに独立して通信を行うことにより、上述の決済処理完了の調査を確実に行う機能を提供する。
【００１５】
また、本発明の他の商品販売システムは、前記商品購入申込を出力するユーザ端末をさらに含み、前記第一の通信手段および前記第三の通信手段は前記ユーザ端末の状態と同調して通信を進行させ、前記第二の通信手段および前記第四の通信手段は前記ユーザ端末の状態と同調せずに通信を進行させることにより、上述の決済処理完了の調査をユーザ端末の状態に影響されず確実に行う機能を提供する。
【００１６】
【発明の実施の形態】
次に本発明の実施の形態について図面を参照して詳細に説明する。
【００１７】
図１を参照すると、本発明における商品販売システムの実施の形態は、商品を販売する商店サーバ１００と、販売金額に応じた決済処理を行う決済サーバ２００と、商品購入者が商品購入申し込みを行うためのユーザ端末３００とを、ネットワーク９００を介して接続して構成される。また、商店サーバ１００には、商品データベース１７０と、受注データベース１９０と、仮受注データベース１８０とが接続される。また、決済サーバ２００には、決済データベース２９０が接続される。
【００１８】
商品データベース１７０は商品一覧を格納する。受注データベース１９０は受注テーブルを格納する。この受注テーブルには販売が確定した商品に関する受注データが保持される。仮受注データベース１８０は仮受注テーブルを格納する。この仮受注テーブルには販売が確定していない商品に関する仮受注データが保持される。また、決済データベース２９０は決済処理の結果を格納する。
【００１９】
商店サーバ１００は、商品データベース１７０に保持された商品一覧に基づき、ネットワーク９００を介してユーザ端末３００に商品を提示して商品購入者に商品の選択を促す。商店サーバ１００は、商品購入者による商品の購入申込を受け、仮受注データベース１８０を更新して、その商品購入金額に応じた決済処理を決済サーバ２００にネットワーク９００を介して依頼する。商店サーバ１００は、決済サーバ２００からの決済処理結果を受け、その後、受注データベース１９０を更新して、商品を提供するための処理を実行する。
【００２０】
決済サーバ２００は、商店サーバ１００からの決済処理依頼を受け、決済処理を行う。この決済処理の結果は決済データベース２９０に反映されるとともに、ネットワーク９００を介して商店サーバ１００に通知される。
【００２１】
ユーザ端末３００は、商品購入者の操作により商品購入申込を商店サーバ１００に、ネットワーク９００を介して送信する。
【００２２】
次に、本発明の実施の形態における処理の流れについて図２から図６を参照して説明する。
【００２３】
まずユーザ端末３００が商品購入申込３００１をすると、商店サーバ１００がこの商品購入申込３００１を受け付ける（処理１０１）。このときのユーザ端末３００側の画面には例えば図３のような表示がされる。この表示例では、購入商品の一覧として、商品名３０１と、商品の単価３０２と、購入する数量３０３と、購入金額３０４とが商品毎に表示されている。そして、購入金額の税抜合計３０５および税額３０６の合計３０７が最終的な支払金額として表示されている。また、支払方法についてもこの画面から入力できるようになっており、ラジオボタン３０８を押下することにより、例えばクレジットカードで決済をするのか、電子マネーで決済するのかといった選択をすることができる。商品購入者は、これらの条件下で商品を購入する場合にはボタン３０９を押下するが、商品の購入を取り止める場合にはボタン３１０を押下する。
【００２４】
商店サーバ１００は商品購入申込３００１を受け付けると（処理１０１）、指定された決済方法に従って、決済サーバ２００に決済依頼１０１１をする。決済サーバ２００は、この決済依頼１０１１を受け付けると（処理２０２）、切替要求２０２１によってユーザ端末３００のアクセス先を商店サーバ１００から決済サーバ２００へ切り替える。これは、例えば、ＨＴＴＰ（Ｈｙｐｅｒ　Ｔｅｘｔ　Ｔｒａｎｓｆｅｒ　Ｐｒｏｔｏｃｏｌ）におけるリダイレクト機能を利用することにより実現できる。
【００２５】
決済サーバ２００は決済処理２０３を実行するために、ユーザ端末３００に決済金額の確認等を行う。このときのユーザ端末３００側の画面には例えば図４のような表示がされる。この表示例は、商品購入者が電子マネーによる決済を希望した場合の例であり、今回の利用金額３１１に加えて、利用前の電子マネーの残高３１２と、利用後の電子マネーの残高３１３とが表示されている。商品購入者は、これらの条件下で支払いを行う場合にはボタン３１４を押下するが、支払いを取り止める場合にはボタン３１５を押下する。
【００２６】
決済サーバ２００は、商品購入者によるユーザ端末３００からの指示に従い、決済処理２０３を行い、その結果通知２０４１を商店サーバ１００に対して行う（処理２０４）。商店サーバ１００は決済サーバ２００からの決済処理結果通知２０４１を受け取り、受け取ったことの確認として決済サーバ２００に応答１０５１を返す（処理１０５）。
【００２７】
このようにして決済処理を終了した後、決済サーバ２００は決済結果の確認要求２０６１をユーザ端末３００に送る（処理２０６）。商品購入者がユーザ端末３００により確認応答３０７１をすると、決済サーバ２００は切替要求２０８１によってユーザ端末３００のアクセス先を決済サーバ２００から商店サーバ１００へ再び切り替える（処理２０８）。
【００２８】
これにより、商店サーバ１００は、ユーザ端末３００に対して商品提供を行う旨の表示１０９１をする（処理１０９）。例えば、購入した商品がダウンロードにより提供される場合には、図５の例のような表示を行い、商品購入者に対してダウンロードを促す。商品購入者はボタン３２１を押下することにより、購入した商品をユーザ端末３００においてダウンロードすることができる。また、例えば、購入した商品がハードウェア機器や、記録媒体によって提供されるソフトウェアである場合には、配送による届け日の予定等を知らせる表示をすることができる。
【００２９】
ここまで説明したとおり、商品の販売が完遂されるためには、ユーザ端末３００、商店サーバ１００、および、決済サーバ２００の三者間における通信が滞りなく実行される必要がある。商品販売手続中に何れかの通信経路で障害が発生したり、ユーザ端末３００で商品購入者が端末の操作を行う過程で誤ってブラウザを閉じてしまう等の要因によりセッションが中断した場合に備え、本発明の実施の形態では、図６のように商店サーバ１００と決済サーバ２００との間に通信手段を設ける。この図６における通信は、図２における通信とは独立して行われる。すなわち、図２における通信はユーザ端末３００の状態に同調して進行し、最終的にユーザ端末３００に結果表示を行うものであるが、図６における通信は一度開始するとユーザ端末３００の状態に同調せず独立して進行する。
【００３０】
図６では、商店サーバ１００がユーザ端末３００からの商品購入申込３００１を受け付けるまでは（処理１０１）、図２と重複して記載されている。その後、所定の要件を満たした場合に、商店サーバ１００は決済サーバ２００に対して過去の決済処理結果の問合せ１１１１をする（処理１１１）。この問合せ１１１１を受けた決済サーバ２００は、決済処理の履歴を調べて、商店サーバ１００に対して決済処理結果の通知２１２１をする（処理２１２）。商店サーバ１００は、その通知２１２１の内容に応じてその後の処理を行う。決済が正常に完了していれば、例えば商品提供の表示１０９（図２）を行うことができる。一方、決済が完了していなければ、決済サーバ２００に対して例えば決済依頼１０１１（図２）を行うことができる。
【００３１】
次に、本発明の実施の形態における構成例について図面を参照して説明する。
【００３２】
図７を参照すると、商店サーバ１００は、ユーザ端末３００と接続する端末インタフェース１１０と、ユーザ端末３００側から受けた商品購入申込の管理を行う受注管理部１２０と、決済サーバ２００に決済を依頼する決済依頼部１３０と、決済サーバ２００に決済結果を確認する決済結果確認部１４０とを備える。また、受注管理部１２０には、商品データベース１７０と、仮受注データベース１８０と、受注データベース１９０とが接続される。
【００３３】
端末インタフェース１１０は、受注管理部１２０からの商品提示データによりユーザ端末３００に対して商品提示を行い、ユーザ端末３００から商品購入申込３００１（図２）を受けて受注管理部１２０に出力する。また、端末インタフェース１１０は、受注管理部１２０からの指示により商品提供の表示１０９１（図２）をユーザ端末３００に行う。
【００３４】
受注管理部１２０は、商品データベース１７０に保持された商品一覧に基づき商品提示データを作成して端末インタフェース１１０に出力する。また、受注管理部１２０は、端末インタフェース１１０から商品購入申込を受けて、仮受注データベース１８０に格納された仮受注テーブルおよび受注データベース１９０に格納された受注テーブルの内容に応じて、決済処理の依頼または決済結果の確認をそれぞれ決済依頼部１３０または決済結果確認部１４０に指示する。また、受注管理部１２０は、仮受注データベース１８０に格納された仮受注テーブルおよび受注データベース１９０に格納された受注テーブルを適宜更新する。なお、この受注管理部１２０の具体的動作例は後述の図１０及び図１１に示される。
【００３５】
決済依頼部１３０は、受注管理部１２０からの指示により決済サーバ２００に決済処理を依頼する。また、決済依頼部１３０は、この決済処理の結果を決済サーバ２００から受け取り、受注管理部１２０に出力する。
【００３６】
決済結果確認部１４０は、受注管理部１２０からの指示により決済サーバ２００に過去の決済処理の結果を問い合わせる。また、決済依頼部１３０は、この問合せに対する応答を決済サーバ２００から受け取り、受注管理部１２０に出力する。
【００３７】
図８を参照すると、決済サーバ２００は、商店サーバ１００から決済処理の依頼を受ける決済受付部２１０と、決済処理を行う決済処理部２２０と、商店サーバ１００からの決済処理結果の問合せに応答する決済結果応答部２３０とを備える。また、決済処理部２２０には、決済データベース２９０が接続される。
【００３８】
決済受付部２１０は、商店サーバ１００から決済処理の依頼を受けて決済処理部２２０に決済処理を指示する。また、この決済処理の結果を決済処理部２２０から受けて商店サーバ１００に通知する。
【００３９】
決済処理部２２０は、決済受付部２１０からの指示により決済処理を行い、その結果を決済受付部２１０に出力する。また、決済処理部２２０は、決済結果応答部２３０からの決済処理結果問合せの指示により、決済データベース２９０の履歴を調べ、決済処理結果を決済結果応答部２３０に知らせる。
【００４０】
決済結果応答部２３０は、商店サーバ１００からの決済処理結果の問合せに対して決済処理部２２０に決済処理結果問合せの指示を行い、その結果を受けて商店サーバ１００に通知する。
【００４１】
図７および図８を参照すると、商店サーバ１００の決済依頼部１３０と決済サーバ２００の決済受付部２１０とは、通信経路１３１（第一の通信手段）により接続される。また、商店サーバ１００の決済結果確認部１４０と決済サーバ２００の決済結果応答部２３０とは、通信経路１４１（第二の通信手段）により接続される。これら通信経路１３１および１４１は、物理的にはともにネットワーク９００を介して実現されるが、論理的には別々の経路であって互いに独立して通信を行う。通信経路１３１（第一の通信手段）は図２における商店サーバ１００と決済サーバ２００との間の通信を実現し、通信経路１４１（第二の通信手段）は図６における商店サーバ１００と決済サーバ２００との間の通信を実現する。
【００４２】
図９を参照すると、仮受注データベース１８０に格納される仮受注テーブルは、仮受注コード１８１と、商品購入者のログインＩＤ１８２と、商品コード１８３と、金額１８４と、決済ステータス１８５と、受注ステータス１８６とを、仮受注データ毎に含んでいる。決済ステータス１８５は、決済処理の結果を示すものであり、ここでは例として決済が完了した場合を「０」、商品購入者が購入申込をキャンセルした場合を「１」、購入申込中にシステム側のエラーが発生した場合を「−１」とそれぞれ表示し、未確定の場合にはこれらの値以外を示すものと仮定する。また、受注ステータス１８６は、受注完了の有無を示すものであり、ここでは例として受注が完了した場合を「１」、受注が完了していない場合を「０」とそれぞれ表示している。
【００４３】
図９の例では、ログインＩＤ１８２が「ＧＨＩ」である商品購入者について商品コード１８３が「００１」である商品の決済が完了し、受注が完了していることを示している。また、ログインＩＤ１８２が「ＤＥＦ」である商品購入者は、商品コード１８３が「００２」である商品の購入申込をしたが、決済前に商品購入をキャンセルしたことを示している。これ以外の仮受注データについては受注が完了しておらず、その原因もこの仮受注テーブルからは判断できない。
【００４４】
次に、本発明の実施の形態における商店サーバ１００（特に、図７の受注管理部１２０）の動作例について図面を参照して説明する。
【００４５】
図１０において、商店サーバ１００がユーザ端末３００から商品購入申込３００１（図２）を受けると、その申込内容について受注データが受注データベース１９０に既に存在するか否かを調べる（ステップＳ１５１）。具体的には、ログインＩＤ、商品コード、および、金額が全て一致していることを確認する。もし、受注データが存在すれば、その商品を既に正式に購入していることになるので、決済完了表示を行う（ステップＳ１５３）。この際、商品の性質によって次のような措置をとることが可能である。例えば、商品がダウンロードにより提供される場合、商店サーバ１００はその商品のダウンロード回数の制限の有無を商品データベース１７０により調べる（ステップＳ１５２）。もし、既に商品購入者によりダウンロードが行われており、所定のダウンロード回数を超えている場合には、商店サーバ１００は決済完了表示（ステップＳ１５３）として、決済は正常に終了しているが所定のダウンロード回数を超えている旨を表示することができる。また、例えば、商品が商品購入者に配送されるものである場合、商店サーバ１００は決済完了表示（ステップＳ１５３）として、決済は一度正常に終了していて既に配送段階にある旨を表示した上で、同一商品を再度購入する意図であるのか否かを商品購入者に確認することができる。なお、これら商品に関する情報は商品データベース１７０に保持することができる。
【００４６】
ステップＳ１５１において受注データが存在しないと判断した場合、次に商店サーバ１００は商品購入申込３００１（図２）の申込内容について仮受注データが仮受注データベース１９０に既に存在するか否かを調べる（ステップＳ１５４）。具体的には、商品購入者のログインＩＤ、商品コード、および、金額が、仮受注テーブル１８０（図９）のログインＩＤ１８２、商品コード１８３、および、金額１８４とそれぞれ一致していることを確認する。仮受注データも存在しない場合には、過去に関連する商品購入申込はないものとして、新規の決済処理を行うべくステップＳ１６０に進む。一方、仮受注データが存在する場合には、仮受注コード１８１（図９）に基づいて、その仮受注データに関する決済処理の結果を決済サーバ２００に確認する（ステップＳ１５５）。この確認は通信経路１４１（図７）を介して行われる。決済サーバ２００は、商品購入申込に係るログインＩＤ、商品コード、および、金額と、決済データベース２９０のデータとを比較して、全て一致していることを確認する。その結果、決済が完了していれば（ステップＳ１５６）、受注データを受注データベース１９０の受注テーブルに挿入して、決済完了表示を行う（ステップＳ１５３）。一方、決済が完了していなければ（ステップＳ１５６）、その仮受注データを仮受注データベース１８０の仮受注テーブルから削除して、新たな決済処理を行うべくステップＳ１６０に進む。また、購入申込中にシステム側のエラーが発生したのであれば（ステップＳ１５６）、所定のエラー処理を行う。
【００４７】
図１１を参照すると、図１０の決済依頼処理（ステップＳ１６０）は、例えば次の手順により実現される。まず、商品購入者の選択した支払方法（図３）に応じて、仮受注をする必要があるか否かを判断する（ステップＳ１６１）。例えば、電子マネー決済の場合はユーザ端末３００側の操作途中で止めてしまう確率が高いと考えて仮受注をしておく必要があると判断してもよく、また、クレジットカード決済の場合は瞬時に行われると考えて仮受注をしておく必要がないと判断してもよい。これらの判断はシステム毎の都合により自由に設定することができる。
【００４８】
ステップＳ１６１において仮受注が必要でないと判断した場合には、商品購入申込の必要記載項目をチェックした上で、通信経路１３１（図７）を介して決済処理を決済サーバ２００に依頼する（ステップＳ１６２）。決済処理が完了すると（ステップＳ１６３）受注データベース１９０の受注テーブルに受注データを挿入する（ステップＳ１６４）。何らかの理由により決済が完了しない場合には（ステップＳ１６３）、再びステップＳ１６２以降の処理を行う。また、システム側のエラーが発生した場合には（ステップＳ１６３）、所定のエラー処理を行う。
【００４９】
ステップＳ１６１において仮受注が必要であると判断した場合には、商品購入申込の必要記載項目をチェックした上で、仮受注データを仮受注データベース１８０の仮受注テーブルに挿入し（ステップＳ１６５）、通信経路１３１（図７）を介して決済処理を決済サーバ２００に依頼する（ステップＳ１６６）。決済処理が完了すると（ステップＳ１６７）受注データベース１９０の受注テーブルに受注データを挿入する（ステップＳ１６８）。何らかの理由により決済が完了しない場合には（ステップＳ１６７）、一旦仮受注データを仮受注データベース１８０の仮受注テーブルから削除して（ステップＳ１６９）、再びステップＳ１６５以降の処理を行う。また、システム側のエラーが発生した場合には（ステップＳ１６７）、所定のエラー処理を行う。
【００５０】
このように、本発明の実施の形態によれば、商店サーバ１００と決済サーバ２００との間のサーバ間通信において、決済処理を行うための通信経路１３１（第一の通信手段）に加えて、決済処理結果を問合せるための通信経路１４１（第二の通信手段）を設けたことにより、ユーザ端末３００とのセッションが途切れて決済完了表示を行うことができなかった場合でも、通信経路１４１を介して速やかに決済処理完了の有無を調査することができる。また、本発明の実施の形態によれば、商店サーバ１００から決済サーバ２００に決済処理の依頼をする際に仮受注データを仮受注データベース１８０の仮受注テーブルに保持させておくことにより、通信経路１４１を介した決済処理結果の問合せを速やかに行うことができる。
【００５１】
これらは、一連の決済処理においてセッション管理を厳重に行うことが困難な基盤システム（例えば、ＷＷＷ（Ｗｏｒｌｄ−Ｗｉｄｅ−Ｗｅｂ）ブラウザを前提としたシステム等）に適用すると特に有用である。また、電子マネー決済後のダウンロード配信のように、即時決済・即時配信が求められるシステムに適用すると特に有用である。
【００５２】
次に、本発明の他の実施の形態について図面を参照して詳細に説明する。
【００５３】
図１２を参照すると、本発明における商品販売システムの他の実施の形態は、図１の実施の形態において、決済サーバ２００がさらに決済代行サーバ４００と決済実行サーバ５００および６００を含んで構成される。決済代行サーバ４００は、商店サーバ１００と決済実行サーバ５００および６００とを仲介して、商店サーバ１００に対して決済処理の代行機能を提供するものである。決済実行サーバ５００および６００は、決済データベース２９０にアクセスして実際に決済処理を行うものである。この決済実行サーバの台数はシステムの都合により１台だけでもよく、また、複数台でもよい。複数台設けた場合には、例えば、１台目でクレジットカードの決済を行い、２台目で電子マネーの決済を行うというように、処理の分散を図ることも可能である。
【００５４】
図１３を参照すると、決済代行サーバ４００は、商店サーバ１００から決済処理の依頼を受ける決済代行受付部４１０と、決済実行サーバ５００または６００に決済を依頼する決済代行依頼部４３０と、商店サーバ１００からの決済処理結果の問合せに応答する決済結果代行応答部４４０と、決済実行サーバ５００に決済結果を確認する決済結果代行確認部４５０と、これらの間で処理を振り分ける振分け部４２０とを備える。
【００５５】
決済代行受付部４１０は、商店サーバ１００から決済処理の依頼を受けて振分け部４２０に出力する。また、この決済処理の結果を振分け部４２０から受けて商店サーバ１００に通知する。
【００５６】
振分け部４２０は、決済代行受付部４１０が受けた決済処理の依頼に応答して決済代行依頼部４３０に決済処理を依頼させてその結果を決済代行受付部４１０に通知する。また、振分け部４２０は、決済結果代行応答部４４０が受けた決済処理の結果確認依頼に応答して決済結果代行確認部４５０に決済処理の結果確認を依頼させてその結果を決済代行応答部４４０に通知する。
【００５７】
決済代行依頼部４３０は、振分け部４２０からの指示により決済実行サーバ５００または６００に決済処理を依頼する。また、決済代行依頼部４３０は、この決済処理の結果を決済実行サーバ５００または６００から受け取り、振分け部４２０に出力する。
【００５８】
決済結果代行応答部４４０は、商店サーバ１００からの決済処理結果の問合せを受けて振分け部４２０に出力する。また、決済結果代行応答部４４０は、その問合せ結果を受けて商店サーバ１００に通知する。
【００５９】
決済結果代行確認部４５０は、振分け部４２０からの指示により決済実行サーバ５００または６００に過去の決済処理の結果を問い合わせる。また、決済結果代行確認部４５０は、この問合せに対する応答を決済実行サーバ５００または６００から受け取り、振分け部４２０に出力する。
【００６０】
図１４を参照すると、決済実行サーバ５００（または６００）は、決済代行サーバ４００から決済処理の依頼を受ける決済実行受付部５１０と、決済処理を行う決済実行処理部５２０と、決済代行サーバ４００からの決済処理結果の問合せに応答する決済実行結果応答部５３０とを備える。また、決済実行処理部５２０には、決済データベース２９０が接続される。
【００６１】
決済実行受付部５１０は、決済代行サーバ４００から決済処理の依頼を受けて決済実行処理部５２０に決済処理を指示する。また、この決済処理の結果を決済実行処理部５２０から受けて決済代行サーバ４００に通知する。
【００６２】
決済実行処理部５２０は、決済実行受付部５１０からの指示により決済処理を行い、その結果を決済実行受付部５１０に出力する。また、決済実行処理部５２０は、決済実行結果応答部５３０からの決済処理結果問合せの指示により、決済データベース２９０の履歴を調べ、決済処理結果を決済実行結果応答部５３０に知らせる。
【００６３】
決済実行結果応答部５３０は、決済代行サーバ４００からの決済処理結果の問合せに対して決済実行処理部５２０に決済処理結果問合せの指示を行い、その結果を受けて決済代行サーバ４００に通知する。
【００６４】
図７および図１３を参照すると、商店サーバ１００の決済依頼部１３０と決済代行サーバ４００の決済代行受付部４１０とは、通信経路１３１（第一の通信手段）により接続される。また、商店サーバ１００の決済結果確認部１４０と決済代行サーバ４００の決済結果代行応答部４４０とは、通信経路１４１（第二の通信手段）により接続される。これら通信経路１３１および１４１は、物理的にはともにネットワーク９００を介して実現されるが、論理的には別々の経路であって互いに独立して通信を行う。通信経路１３１（第一の通信手段）は図１５における商店サーバ１００と決済代行サーバ４００との間の通信を実現し、通信経路１４１（第二の通信手段）は図１６における商店サーバ１００と決済代行サーバ４００との間の通信を実現する。
【００６５】
図１３および図１４を参照すると、決済代行サーバ４００の決済代行依頼部４３０と決済実行サーバ５００の決済実行受付部５１０とは、通信経路４３１（第三の通信手段）により接続される。また、決済代行サーバ４００の決済結果代行確認部４５０と決済実行サーバ５００の決済実行結果応答部５３０とは、通信経路４５１（第四の通信手段）により接続される。これら通信経路４３１および４５１は、物理的にはともにネットワーク９００を介して実現されるが、論理的には互いに独立して通信を行う。通信経路４３１（第三の通信手段）は図１５における決済代行サーバ４００と決済実行サーバ５００との間の通信を実現し、通信経路４５１（第四の通信手段）は図１６における決済代行サーバ４００と決済実行サーバ５００との間の通信を実現する。
【００６６】
次に、本発明の上記他の実施の形態における処理の流れについて図面を参照して説明する。
【００６７】
図１５において、まずユーザ端末３００が商品購入申込３００１をすると、商店サーバ１００がこの商品購入申込３００１を受け付ける（処理１０１）。商店サーバ１００は指定された決済方法に従って、決済代行サーバ４００に決済依頼１０１１をする。決済代行サーバ４００は、この決済依頼１０１１を受け付けると（処理４０２）、切替要求４０２１によってユーザ端末３００のアクセス先を商店サーバ１００から決済実行サーバ５００へ切り替える。
【００６８】
決済実行サーバ５００は決済処理５０３を実行するために、ユーザ端末３００に決済金額の確認等を行う。決済実行サーバ５００は、商品購入者によるユーザ端末３００からの指示に従い、決済処理５０３を行い、その結果通知５０４１を決済代行サーバ４００に対して行う（処理５０４）。決済代行サーバ４００はこの通知を受け取り、さらにその結果通知４０４１を商店サーバ１００に対して行う（処理４０４）。商店サーバ１００は決済代行サーバ４００からの決済処理結果通知４０４１を受け取り、受け取ったことの確認として決済代行サーバ４００に応答１０５１を返す（処理１０５）。決済代行サーバ４００はこの応答を受け取り、さらにその応答４０４２を決済実行サーバ５００に対して行う（処理４０４）。
【００６９】
このようにして決済処理を終了した後、決済実行サーバ５００は決済結果の確認要求５０６１をユーザ端末３００に送る（処理５０６）。商品購入者がユーザ端末３００により確認応答３０７１をすると、決済代行サーバ４００は切替要求４０８１によってユーザ端末３００のアクセス先を決済実行サーバ５００から商店サーバ１００へ再び切り替える（処理４０８）。これにより、商店サーバ１００は、ユーザ端末３００に対して商品提供を行う旨の表示１０９１をする（処理１０９）。
【００７０】
本発明の上記他の実施の形態では、図６の場合と同様に、図１６のような通信手段を商店サーバ１００と決済代行サーバ４００との間、ならびに、決済代行サーバ４００と決済実行サーバ５００との間に設ける。この図１６における通信は、図６の場合と同様に、図１５における通信とは独立して行われる。
【００７１】
図１６では、商店サーバ１００がユーザ端末３００からの商品購入申込３００１を受け付けるまでは（処理１０１）、図１５と重複して記載されている。その後、所定の要件を満たした場合に、商店サーバ１００は決済代行サーバ４００に対して過去の決済処理結果の問合せ１１１１をする（処理１１１）。この問合せ１１１１を受けた決済代行サーバ４００は、さらに決済処理結果の問合せ４１２２を決済実行サーバ５００にする（処理４１２）。決済実行サーバ５００は、決済処理の履歴を調べて、決済代行サーバ４００に対して決済処理結果の通知５１２１をする（処理５１２）。決済代行サーバ４００はその通知５１２１を受けてさらに商店サーバ１００に対して決済処理結果の通知４１２１をする（処理４１２）。商店サーバ１００は、その通知４１２１の内容に応じてその後の処理を行う。決済が正常に完了していれば、例えば商品提供の表示１０９（図１５）を行うことができる。一方、決済が完了していなければ、決済サーバ２００に対して例えば決済依頼１０１１（図１５）を行うことができる。
【００７２】
このように、本発明の上記他の実施の形態によれば、決済サーバ２００が決済代行サーバ４００と決済実行サーバ５００または６００とに分散されている場合において、商店サーバ１００と決済サーバ２００の間の通信経路１４１（第二の通信手段）に加えて、決済サーバ２００内の決済代行サーバ４００と決済実行サーバ５００または６００との間にも通信経路４５１（第四の通信手段）を設けたことにより、このような分散環境においても上述の仮受注テーブルに基づく決済処理完了の調査を速やかに行うことができる。
【００７３】
【発明の効果】
以上の説明で明らかなように、本発明によると、通信を介した商品販売手続において、商品販売手続とは独立した通信経路を用意し、決済処理の依頼をする際に仮受注データを保持しておくことにより、商品販売手続の途中で通信が切断された場合に、商品販売手続とは独立した通信経路を用いて商品販売手続の経過を速やかに調査することができるという効果が得られる。
【図面の簡単な説明】
【図１】本発明による商品販売システムの実施の形態を示すブロック図である。
【図２】本発明の実施の形態における全体処理の流れを示すシーケンスチャートである。
【図３】本発明の実施の形態における購入内容の確認画面の一例を示す図である。
【図４】本発明の実施の形態における決済内容の確認画面の一例を示す図である。
【図５】本発明の実施の形態における決済完了表示画面の一例を示す図である。
【図６】本発明の実施の形態における決済結果問合せ処理の流れを示すシーケンスチャートである。
【図７】本発明の実施の形態における商店サーバの構成例を示す図である。
【図８】本発明の実施の形態における決済サーバの構成例を示す図である。
【図９】本発明の実施の形態における仮受注テーブルの構成例を示す図である。
【図１０】本発明の実施の形態における商店サーバの商品購入申込を受けた際の動作例を示す図である。
【図１１】本発明の実施の形態における商店サーバの決済依頼処理の動作例を示す図である。
【図１２】本発明による商品販売システムの他の実施の形態を示すブロック図である。
【図１３】本発明の上記他の実施の形態における決済代行サーバの構成例を示す図である。
【図１４】本発明の上記他の実施の形態における決済実行サーバの構成例を示す図である。
【図１５】本発明の上記他の実施の形態における全体処理の流れを示すシーケンスチャートである。
【図１６】本発明の上記他の実施の形態における決済結果問合せ処理の流れを示すシーケンスチャートである。
【符号の説明】
１００　商店サーバ
１７０　商品データベース
１８０　仮受注データベース
１９０　受注データベース
２００　決済サーバ
２９０　決済データベース
３００　ユーザ端末
４００　決済代行サーバ
５００、６００　決済実行サーバ
９００　ネットワーク
【図１】
2004021780.tif 000003
【図２】
2004021780.tif 000004
【図３】
2004021780.tif 000005
【図４】
2004021780.tif 000006
【図５】
2004021780.tif 000007
【図６】
2004021780.tif 000008
【図７】
2004021780.tif 000009
【図８】
2004021780.tif 000010
【図９】
2004021780.tif 000011
【図１０】
2004021780.tif 000012
【図１１】
2004021780.tif 000013
【図１２】
2004021780.tif 000014
【図１３】
2004021780.tif 000015
【図１４】
2004021780.tif 000016
【図１５】
2004021780.tif 000017
【図１６】
2004021780.tif 000018