JP2014194779A - 要求処理システム、要求処理方法、プログラムおよび情報記憶媒体 - Google Patents

Abstract

【課題】要求元からの要求に応じて処理を実行する場面において、通常と異なる対応をとるべき場合に、通常とは異なる手順により必要な処理が進むようにすること。
【解決手段】要求処理システムは、内的要因と外的要因との少なくともいずれかに基づき通常と異なる方針で処理要求に対応する旨を決定し、前記通常と異なる方針で処理要求に対応する旨が決定された場合に、即時の応答が必要とされる第１方法により要求元から送出されていた前記処理要求が即時の応答が必要とされない第２方法により送出されるよう誘導する。
【選択図】図３

Description

本発明は要求処理システム、要求処理方法、プログラムおよび情報記憶媒体に関する。

インターネットにおいて電子商取引などを取扱うシステムでは、多数のユーザが短時間に集中してそのシステムにアクセスするケースがあることがよく知られている。アクセスが集中すると、サーバやネットワーク機器などの処理が追いつかなくなり、ユーザからの注文を処理できなくなるなどの問題が生じる。これを避けるために、たとえば予めピーク時のアクセス数を予測し、そのピークでも処理できるハードウェアやネットワーク回線を準備しておくことが行われている。また、負荷に応じて動的にサーバの台数を増やしスケールアウトするシステムも知られている（例えば、特許文献１参照）。

特開２００２−３４２２９６号公報

しかしながら、通常時の対応を継続することが困難又は不適当な場面を想定した対策として、ハードウェア資源を増強するというアプローチは現実的でないことがある。

一例として、輻輳対策に関して言えば、アクセス数のピークに合わせてリソースを準備しておくことが必ずしも容易でない点が挙げられる。これは、例えば、ピークに合わせてリソースを準備すると通常時の稼働率が下がりコスト効率が悪い、アクセスのピークの大きさを正確に予測することがそもそも難しい、等の事情による。

本発明が解決しようとする課題は、要求元からの要求に応じて処理を実行する場面において、通常と異なる対応をとるべき場合に、通常とは異なる手順により必要な処理が進むように仕向ける、という点である。

上記課題を解決するために、本発明にかかる要求処理システムは、内的要因と外的要因との少なくともいずれかに基づき通常と異なる方針で処理要求に対応する旨を決定する決定手段と、前記決定手段により決定がなされた場合に、即時の応答が必要とされる第１方法により要求元から送出されていた前記処理要求が即時の応答が必要とされない第２方法により送出されるよう誘導する誘導手段と、を含むことを特徴とする。

また、本発明にかかる要求処理方法は、内的要因と外的要因との少なくともいずれかに基づき通常と異なる方針で処理要求に対応する旨を決定する決定ステップと、前記決定ステップにおいて決定がなされた場合に、即時の応答が必要とされる第１方法により要求元から送出されていた前記処理要求が即時の応答が必要とされない第２方法により送出されるよう誘導する誘導ステップと、を含むことを特徴とする。

また、本発明にかかるプログラムは、内的要因と外的要因との少なくともいずれかに基づき通常と異なる方針で処理要求に対応する旨を決定し、前記通常と異なる方針で処理要求に対応する旨の決定がなされた場合に、即時の応答が必要とされる第１方法により要求元から送出されていた前記処理要求が即時の応答が必要とされない第２方法により送出されるよう誘導する、処理をコンピュータに実行させることを特徴とする。

また、本発明にかかるコンピュータ読取り可能な記憶媒体は、上記プログラムを格納する。

本発明によれば、要求元からの要求に応じて処理を実行する場面において、通常と異なる対応をとるべき場合に、通常とは異なる手順により必要な処理が進むようにできる。

本発明の一態様では、前記誘導手段は、前記決定手段により決定がなされた場合に、前記要求元から前記第１方法により送出される他の処理要求に続く、該他の処理要求と一連の前記処理要求が前記第２方法により送出されるよう誘導してもよい。

本発明の一態様では、前記誘導手段が、前記処理要求を前記第２方法により送出するための宛先を特定する宛先特定情報を前記要求元に報知してもよい。

本発明の一態様では、前記誘導手段が、前記宛先特定情報を含む誘導情報を前記要求元により指定される指定宛先に前記第２方法により送信してもよい。

本発明の一態様では、前記誘導手段が、前記処理要求を含むトランザクションに関連して前記要求元に確認させるべき要確認情報を含む確認依頼情報を前記第２方法により前記指定宛先に前記誘導情報とは別に送信し、当該確認依頼情報に対する返信として前記処理要求を前記宛先特定情報により特定される宛先に前記第２方法により送信するよう誘導してもよい。

本発明の一態様では、前記要求処理システムは、前記処理要求の直前に前記要求元から前記第１方法により送出された他の要求に対し、前記第２方法により前記確認依頼情報が送信された旨を応答する案内手段をさらに含んでもよい。

本発明の一態様では、前記要求処理システムは、前記トランザクションごとに前記宛先特定情報を生成する生成手段をさらに含んでもよい。

本発明の一態様では、前記要求処理システムは、前記生成手段により前記宛先特定情報が生成されてから所定の期間が経過した場合に、当該宛先特定情報により特定される宛先を無効化する無効化手段をさらに含んでもよい。

本発明の一態様では、前記トランザクションは商品またはサービスの注文を目的とするものであり、前記要求処理システムは、前記生成手段により生成される宛先特定情報に関連付けて、当該宛先特定情報に対応するトランザクションにより注文されるべき商品またはサービスの在庫を仮に引き当てる在庫確保手段と、前記無効化手段により前記宛先特定情報が無効化された場合に、当該無効化された宛先特定情報に関連付けられている前記仮の在庫の引当てを解除する引当解除手段と、をさらに含んでもよい。

本発明の一態様では、前記要求処理システムは、前記第１方法により送出される前記処理要求に応じて所定処理を即時に実行し、当該所定処理が完了した後直ちに前記要求元に応答する第１処理手段と、前記第２方法により送出される前記処理要求に応じて前記所定処理に相当する代替処理を随時に実行する第２処理手段と、をさらに含んでもよい。

本発明の一態様では、前記第２処理手段が、前記第２方法により前記処理要求を受領した時刻を当該処理要求の受付時刻とみなして前記代替処理を実行してもよい。

本発明の一態様では、前記処理要求は、商品またはサービスの注文を受け付ける注文受付処理の要求であり、前記第２処理手段が、前記注文の対象をキーとして複数の前記処理要求をソートし、当該注文の対象ごとにまとめて前記注文受付処理を実行してもよい。

本発明の一態様では、前記第２処理手段が、早期に注文を確定させるべき商品またはサービスに関連する前記注文受付処理を優先的に実行してもよい。

本発明の一態様では、前記要求処理システムは、システムの負荷の大きさを示す数値を取得する負荷取得手段をさらに含み、前記決定手段は、前記負荷取得手段により取得される数値が所定の閾値以上又はこれを越える場合に、通常と異なる方針で処理要求に対応する旨を決定してもよい。

本発明の一態様では、前記要求処理システムは、前記要求元のランクの特定に資するランク特定情報を取得するランク取得手段をさらに含み、前記決定手段が、さらに、前記ランク取得手段により取得されるランク特定情報により特定される前記要求元のランクが所定の範囲内である場合に、通常と異なる方針で処理要求に対応する旨を決定してもよい。

本発明の実施形態にかかる電子商取引システムの構成の一例を示す図である。 電子商取引システムに含まれるサーバのハードウェア構成の一例を示す図である。 本発明の実施形態にかかる電子商取引システムが実現する機能を示す機能ブロック図である。 負荷取得部および振分け部の処理フローの一例を示す図である。 第１通信方法のみを用いる場合の処理の流れの一例を示すシーケンス図である。 買い物かご確認画面の一例を示す図である。 注文確認画面の一例を示す図である。 第１通信方法と第２通信方法とを用いる場合の処理の流れの一例を示すシーケンス図である。 仮応答部の処理フローの一例を示す図である。 送信依頼部の処理フローの一例を示す図である。 注文確認メールの一例を示す図である。 順次処理部の処理フローの一例を示す図である。

以下では、本発明の実施形態を図面に基づいて説明する。同じ符号が付された構成については、重複する説明を省略する。

図１は、本発明の実施形態にかかる電子商取引システム１のハードウェア構成の一例を示す図である。この電子商取引システム１は、ネットワーク３を介してユーザ端末２からの商品およびサービスの注文や発送、決済（支払ともいう）などの要求を処理するシステムである。以下ではこのシステムが複数の店舗に対して電子商取引の場を提供する電子商店街システムであるとして説明する。なお、以下では「商品」と呼ぶ場合、特に断りがない場合はサービスも含むものとする。

電子商取引システム１は、負荷分散サーバ４と、複数の通常ウェブサーバ５と、データベースサーバ６と、高負荷対応ウェブサーバ７と、メール送信サーバ８と、メール受信サーバ９と、順次処理サーバ１０とを含む。負荷分散サーバ４は、いわゆるロードバランサであり、通常ウェブサーバ５のそれぞれの負荷が限界に達しないようにユーザ端末２からのｈｔｔｐ要求を転送する。負荷分散サーバ４は、この電子商取引システム１の負荷を示す情報を定期的に取得しており、その情報に基づいてユーザ端末２からのｈｔｔｐ要求を複数の通常ウェブサーバ５のいずれかまたは高負荷対応ウェブサーバ７に転送する。

通常ウェブサーバ５はユーザ端末２からの各種ｈｔｔｐ要求をリアルタイムに処理し、その処理結果を、ｈｔｔｐ要求に対するｈｔｔｐ応答としてユーザ端末２に返す。高負荷対応ウェブサーバ７、メール送信サーバ８、メール受信サーバ９、順次処理サーバ１０は、この電子商取引システム１の負荷を示す値が上限を超えた場合にｈｔｔｐ要求に対応する処理を行う。これらのサーバの処理の詳細については後述する。ここで、ｈｔｔｐ要求およびｈｔｔｐ応答を用いる通信プロトコルをｈｔｔｐプロトコルという。ｈｔｔｐプロトコルは、ｈｔｔｐ要求に対し一定時間内にｈｔｔｐ応答があることを前提とする通信プロトコルである。ｈｔｔｐプロトコルのようにリアルタイムで応答が帰ってくることを前提とする通信方法による要求を以下では「即時処理要求」と記載する。

データベースサーバ６は商品マスタと、顧客データベースと、ユーザからの注文商品や決済・発送方法などを含む注文情報のデータベース（注文データベース）と、その他のデータベースを格納する。データベースサーバ６はいわゆるデータベース管理ソフトウェアを実行することでこれらのデータを格納し管理する。注文情報はいわゆるトランザクションデータの一種である。

図２は電子商取引システム１に含まれる各サーバのハードウェア構成の一例を示す図である。負荷分散サーバ４、複数の通常ウェブサーバ５、データベースサーバ６、高負荷対応ウェブサーバ７、メール送信サーバ８、メール受信サーバ９、および順次処理サーバ１０のそれぞれは、プロセッサ２１、記憶部２２、通信部２３、入出力部２４を含む。

プロセッサ２１は、記憶部２２に格納されているプログラムに従って動作する。またプロセッサ２１は通信部２３、入出力部２４を制御する。なお、上記プログラムは、インターネット等を介して提供されるものであってもよいし、フラッシュメモリやＤＶＤ−ＲＯＭ等のコンピュータで読み取り可能な記憶媒体に格納されて提供されるものであってもよい。

記憶部２２は、ＲＡＭやフラッシュメモリ等のメモリ素子やハードディスクドライブによって構成されている。記憶部２２は、上記プログラムを格納する。また、記憶部２２は、各部から入力される情報や演算結果を格納する。

通信部２３は、他の装置と通信する機能を実現するものであり、例えば無線ＬＡＮの集積回路やアンテナなどにより構成されている。通信部２３は、プロセッサ２１の制御に基づいて、他の装置から受信した情報をプロセッサ２１や記憶部２２に入力し、他の装置に情報を送信する。

入出力部２４は、ビデオコントローラや、キーボードやマウスなどの入力デバイスからのデータを取得するコントローラなどにより構成される。入出力部２４は、プロセッサ２１の制御に基づいて、表示出力デバイスに表示データを出力し、入力デバイスをユーザが操作することにより入力されるデータを取得する。

図３は、本発明の実施形態にかかる電子商取引システム１が実現する機能を示す機能ブロック図である。電子商取引システム１は、機能的に、負荷取得部５１と、振分け部５２と、即時処理要求受信部５３と、即時処理部５４と、仮応答部５８と、送信依頼部５９と、メールアドレス管理部６０と、メール受信格納部６１と、順次処理部６２と、引当解除部６３とを含む。また、即時処理部５４は、カート処理部５５と、注文確認部５６と、注文即時処理部５７とを含む。

負荷分散サーバ４が負荷取得部５１および振分け部５２を実現し、通常ウェブサーバ５は即時処理要求受信部５３および即時処理部５４を実現し、高負荷対応ウェブサーバ７は仮応答部５８を実現し、メール送信サーバ８は送信依頼部５９を実現し、メール受信サーバ９はメール受信格納部６１およびメールアドレス管理部６０を実現し、順次処理サーバ１０は順次処理部６２および引当解除部６３を実現する。より具体的には、これらの機能は、その機能のそれぞれを実現するサーバに含まれるプロセッサ２１が、記憶部２２に格納されたプログラムを実行し通信部２３等を制御することにより実現される。

以下では、電子商取引システム１が実現する各機能について、シーケンス図や処理フローなどの図面を用いて説明する。

図４は、負荷取得部５１および振分け部５２の処理フローの一例を示す図である。図４に示す処理は、ユーザ端末２から即時処理要求を受信するたびに実行される。

負荷取得部５１は、負荷分散サーバ４のプロセッサ２１、記憶部２２および通信部２３を中心として実現される。負荷取得部５１は、システムの負荷を示す情報を取得する（ステップＳ１０１）。システムの負荷を示す情報は、通常ウェブサーバ５のそれぞれが処理しているｈｔｔｐセッションの数や、通常ウェブサーバ５およびデータベースサーバ６のＣＰＵ使用率やメモリ使用率などに基づいて計算される値であってよい。

振分け部５２は、負荷分散サーバ４のプロセッサ２１、記憶部２２および通信部２３を中心として実現される。振分け部５２は、内的要因と外的要因との少なくともいずれかに基づいて、通常の通信方法（第１通信方法）で処理要求に対応するか、通常と異なる通信方法（第２通信方法）で処理要求に対応するかを決定し、その決定にしたがって即時処理要求を通常ウェブサーバ５または高負荷対応ウェブサーバ７に振分ける。ここでは、振分け部５２は、負荷取得部５１が取得したシステムの負荷を示す数値などの情報に基づいて、数値が所定の閾値以上又はこれを越える場合に、第２通信方法で処理要求に対応することを決定する。第１通信方法はｈｔｔｐなど、要求（例えば、ｈｔｔｐリクエスト）に対して即時の応答（例えば、ｈｔｔｐレスポンス）が必要とされるプロトコルに基づく通信の方法であり、第２通信方法はＳＭＴＰなど、即時の応答が必要とされないプロトコルに基づく通信の方法（例えば、電子メール）である。第１通信方法で処理要求に対応する場合は、電子商取引システム１が応答の送信を必要とする即時処理要求をリアルタイムで処理し、その処理結果に基づいて即時処理要求に対する応答を送信する。第２通信方法で処理要求に対応する場合には、電子商取引システム１が即時処理要求に基づいて取得した順次処理要求をキューに格納する。キューには未処理の１または複数の順次処理要求が格納される。そして、電子商取引システム１がそのキューに格納された前記順次処理要求を順に取得して処理する。

振分け部５２はより具体的には、ユーザ端末２から受信した即時処理要求を受信し（ステップＳ１０２）、電子商取引システム１の負荷を示す値が閾値以下である場合（ステップＳ１０３のＮ）または即時処理要求が購入指示情報でない場合（ステップＳ１０４のＮ）には、即時処理要求を通常ウェブサーバ５のいずれかに転送する（ステップＳ１０５）。この転送は、第１通信方法で処理要求に対応すると決定することに相当する。ここで、振分け部５２は、複数の通常ウェブサーバ５の間で負荷が平準化するように転送先の通常ウェブサーバ５を選択する。一方、電子商取引システム１の負荷の値が閾値より高く（ステップＳ１０３のＹ）かつ即時処理要求が購入指示情報である場合（ステップＳ１０４のＹ）には即時処理要求を高負荷対応ウェブサーバ７に転送する（ステップＳ１０６）。この転送は、第２通信方法で処理要求に対応すると決定することに相当する。なお、購入指示情報などの詳細については後述する。

次に、常に第１通信方法で処理要求に対応する場合の処理の流れおよびそれに関連する処理について説明する。図５は、第１通信方法のみを用いる場合の処理の流れの一例を示すシーケンス図である。これは一般的な電子商店街サイトの処理内容とほぼ同じものである。本図におけるカート確認指示情報、購入指示情報、注文受付指示情報は即時処理要求として送信される情報（つまり、即時の応答が必要とされるｈｔｔｐリクエストと一体化して送信される情報）である。本図に示さないが、商品を選択するための画面を表示させる情報を含む要求および応答も実際には存在する。また、カート確認情報、注文確認情報、注文結果応答は、それぞれカート確認指示情報、購入指示情報、注文受付指示情報に対する応答であり、例えばユーザ端末２のブラウザ等に画面を表示させるためのＨＴＭＬデータなどに含まれる（つまり、即時の応答であるｈｔｔｐレスポンスと一体化して送信される）。ここで、カート確認指示情報、購入指示情報、注文受付指示情報の一連の即時処理要求は処理の流れのトランザクションを構成する。また、即時処理要求は属するトランザクションを特定するＩＤ（例えば、ｈｔｔｐセッションを識別するセッションＩＤ又はこれに対応する文字列（例えば、セッションＩＤを所定の規則により変換した文字列））を含んでいる。通常ウェブサーバ５がユーザ端末２からの最初のアクセスの際にセッションＩＤを生成し、そのセッションＩＤはユーザ端末２のブラウザによってクッキーなどとして保存される。

即時処理要求受信部５３は、通常ウェブサーバ５のプロセッサ２１、記憶部２２および通信部２３を中心として実現される。即時処理要求受信部５３は、振分け部５２から転送された即時処理要求を通信部２３を介して受信し、即時処理部５４に渡す。

即時処理部５４、および即時処理部５４に含まれるカート処理部５５、注文確認部５６、注文即時処理部５７は、通常ウェブサーバ５のプロセッサ２１、記憶部２２および通信部２３を中心として実現される。カート処理部５５、注文確認部５６、注文即時処理部５７は、それぞれカート確認指示情報、購入指示情報、注文受付指示情報に含まれる注文に関するデータを処理し、その処理結果を含むｈｔｔｐ応答をユーザ端末２に向けて送信する。

カート処理部５５はカート確認指示情報に基づいて、データベースサーバ６または記憶部２２内のキャッシュから買い物かごの情報を検索し、検索された買い物かごに含まれる商品の名称や価格などの情報を含む買い物かご確認画面を示すカート確認情報を生成し、そのカート確認情報をｈｔｔｐ応答としてユーザ端末２に向けて送信する。ここで、カート確認指示情報は、ユーザが電子商取引において商品を選択し、商品を買い物かごに入れる、または買い物かごを確認する旨のボタンが押下された場合に、ユーザ端末２から送信されるものである。

図６は、買い物かご確認画面の一例を示す図である。買い物かご確認画面には、その買い物かごに含まれる商品を販売する店舗の情報、商品名や単価といったデータベース内の商品マスタから取得される情報、そして商品の数量といったカート情報から取得される情報が配置されている。また、買い物かご確認画面には、それぞれの商品について購入するか否かを指定するチェックボックスや、商品を買い物かごから削除するか否かを指定する「削除」ボタンが配置されている。ユーザが「削除」ボタンを押下すると、ユーザ端末２はその商品を買い物かごから削除する旨を含むカート確認指示情報を電子商取引システム１に向けて送信する。また、ユーザが「購入手続き」ボタンを押下すると、ユーザ端末２は購入指示情報を電子商取引システム１に向けて送信する。

注文確認部５６は、購入指示情報に基づいて、顧客データベースからそのユーザについての決済情報や配送情報などを取得し、さらに支払金額の情報を生成する。そして、支払金額、決済情報や配送情報を含む注文確認画面を示す注文確認情報を生成し、その注文確認情報をｈｔｔｐ応答としてユーザ端末２に向けて送信する。また注文確認部５６は、確定前の注文の注文情報を注文データベースに格納する。

図７は、注文確認画面の一例を示す図である。注文確認画面には、商品の代金の支払に用いる支払手段やポイント利用の有無、配送方法、配送先の情報が配置される。これらの情報はユーザをキーとして顧客データベースに格納されたものである。顧客データベースには、この注文確認画面に出力させる支払方法や配送先の情報が格納されている。ユーザがその項目のそれぞれの右側にある「変更」ボタンを押下すると、これらの情報を変更することが可能になり、これらの情報を変更する旨の注文受付指示情報がユーザ端末２から送信されると、注文確認部５６は変更された注文確認画面を示す注文確認情報を送信する。また、ユーザが「注文申込」ボタンを押下すると、ユーザ端末２は注文受付指示情報を電子商取引システム１に向けて送信する。

注文即時処理部５７は、注文受付指示情報に基づいて、受け付けられた注文への対応を進めるための処理を行う。より具体的には、注文即時処理部５７は、ユーザの注文に対する決済処理や在庫割当てなどの処理を行う。より具体的には、注文即時処理部５７は注文受付指示情報により指定される注文について、支払種類に応じた支払の処理を行い、店舗の在庫データベースにアクセスして商品の在庫があればそれを割当て、割り当てられた商品の発送を外部のシステムに対して指示する。支払の処理は例えば支払の種類がクレジットカードであれば与信や売上の処理であり、銀行振込であれば振込依頼票を外部システムに発行させる処理である。また、注文即時処理部５７は、在庫の割当ての際に在庫がなければエラーまたは予約扱いにする。注文即時処理部５７は、発送の指示において、在庫の割当て状況や、支払の結果などに応じてバッチ処理システムに発送の準備等の処理をさせるよう指示する。また注文即時処理部５７は、支払状況などに基づいて注文の情報を更新する。この際、注文即時処理部５７は、この処理を行っている時刻を注文時刻として注文情報に設定する。そして、注文即時処理部５７は、その上述の処理の結果、注文が受け付けられた場合にはその旨を示す情報と注文番号とを含む画面を示す注文結果応答を生成して送信し、注文がエラーとなった場合にはその旨を示す情報を含む画面を示す注文結果応答を生成して送信する。

注文即時処理部５７の処理は、注文情報の更新や外部システムとの連携が絡むため、時間がかかりやすくシステムに負荷をかけやすい。一方で顧客の注文を受け付けるという重要な処理であるため、処理そのものをなくすことはできない。第１通信方法だけで処理を行う従来のシステムでは、注文受付指示情報を受信してから注文結果応答を送信するまでのごくわずかな時間内に実行されるべき注文即時処理部５７の処理の負荷が問題となる。また、電子商店街では、所定の期間内に所定の購買が行われたことを条件にユーザに何らかの特典を付与するキャンペーン（すなわち、注文情報の受付時刻がキャンペーンの適否を判定する上で極めて重要な意味をもつタイプのキャンペーン）を行う場合がある。この場合には、期間限定のキャンペーンの適用を受けるために、多数のユーザがその期間の終了間際に電子商店街システムにアクセスすることが多い。そのためキャンペーンの期限間近に電子商店街システム全体に対してアクセスが集中する傾向がある。この場合は例えば動的なハードウェアの増強は非常に難しい。

次に、上述の従来の問題に対処するために第１通信方法だけでなく第２通信方法も用いる場合の処理の流れおよびそれに関連する処理について説明する。図８は、第１通信方法と第２通信方法とを用いる場合の処理の流れの一例を示すシーケンス図である。本図におけるカート確認指示情報、購入指示情報は即時処理要求である。また、カート確認指示情報および仮応答情報は、それぞれカート確認指示情報および購入指示情報に対するｈｔｔｐ応答であり、ユーザ端末２のブラウザ等に画面を表示させるためのＨＴＭＬデータなどである。

カート確認指示情報は、振分け部５２により通常ウェブサーバ５に転送される。この処理内容は図５を用いて説明したものと同じであるので省略する。なお、図８に示さない商品を選択するための画面を表示させる要求や応答についても通常ウェブサーバ５が処理する。なお、カート処理部５５の処理までを通常ウェブサーバ５に処理させるのは、いくつか理由がある。１つは、商品の選択の操作をしないと注文を確定することが難しいことである。原則的に用いる支払や発送の方法に関する情報は事前に設定できるが、商品の選択についてはウェブを用いたリアルタイム処理の必要性が高い。もう１つの理由は、システムの負荷が後続の画面に関する処理に比べて小さいことである。カート処理部５５の処理では、注文情報といったトランザクションデータに対するアクセスや更新が発生するものの、アクセス箇所は限られるためその処理の負荷は注文即時処理部５７等に比べれば小さい。

第２通信方法を用いると決定された場合には、ユーザからの購入指示情報は、振分け部５２により、高負荷対応ウェブサーバ７に転送される。

仮応答部５８は、高負荷対応ウェブサーバ７のプロセッサ２１、記憶部２２および通信部２３を中心として実現される。仮応答部５８は、第２通信方法を用いることが決定された場合に転送された即時処理要求に対して、順次処理要求によって注文に関する手続きを進める旨の画面を示す仮応答情報をｈｔｔｐ応答としてユーザ端末２に向けて送信する。この仮応答情報には、ユーザ端末２の画面に即時処理要求を送信させるためのボタンやリンクなどの要素は含まれていない。こうすると、あるトランザクションにおいて以降の第１通信方法（ｈｔｔｐなど）でのアクセスを抑止し、ユーザに第２通信方法（メールなど）を用いたアクセスに誘導することが可能になる。

また、仮応答部５８は、この順次処理要求をユーザに送信させるための情報をメール送信サーバ８に送信させるためのメール送信待ちキューに、この即時処理要求に含まれる注文を特定する情報（「順次購入要求」とも呼ぶ）を格納する。仮応答部５８の処理の対象となる即時処理要求は購入指示情報である。

図９は、仮応答部５８の処理フローの一例を示す図である。仮応答部５８は、はじめに、振分け部５２から転送された即時処理要求を受信して取得する（ステップＳ２０１）、そして、仮応答部５８は、その注文を特定する情報（順次購入要求）をメール送信待ちキューに格納する（ステップＳ２０２）。そして、即時処理要求への応答として、ユーザが順次処理要求を送信するためのメールをユーザのメールアドレスに向けて送信することを示す画面を示す仮応答情報を送信する（ステップＳ２０３）。

送信依頼部５９は、メール送信サーバ８のプロセッサ２１、記憶部２２および通信部２３を中心として実現される。送信依頼部５９は、購入指示情報の即時処理要求を送信したユーザに対して、第２通信方法（応答を必要としない通信プロトコル）で順次処理要求を送信することを依頼する情報である送信依頼情報を送信する。送信依頼情報は、図８の例では、注文確認メールである。さらにいえば、送信依頼部５９は、メール送信待ちキューに格納された順次購入要求を順に取得し、その順次購入要求が示す注文をしたユーザに対して送信依頼情報を送信する。言い換えれば、送信依頼部５９は、送信依頼情報に基づいて、ユーザに第２通信方法を用いて電子商取引システム１に向けて（順次）処理要求を送信させるよう誘導している。

図１０は、送信依頼部５９の処理フローの一例を示す図である。はじめに、メール送信サーバ８に含まれる送信依頼部５９は、メール送信待ちキューから、順次処理要求の格納順にしたがって、１件の順次購入要求を取得する（ステップＳ３０１）。次に、送信依頼部５９は、この順次購入要求から注文を特定する情報を取得し、注文データベースや顧客データベースから注文に関する情報や、顧客のメールアドレスなどの情報を取得する（ステップＳ３０２）。ここで送信依頼部５９が取得する注文に関する情報は、注文確認部５６が取得するものと同じものである。次に、注文に含まれる商品が数量限定の商品や定員限定サービスの予約など、品切れになると注文が成立しない種類の商品である場合には、送信依頼部５９は在庫をこの注文に対して引き当てる（ステップＳ３０３）。ここで送信依頼部５９が行う在庫の引き当ては一種の予約であり、仮の在庫引き当てである。引き当てられた在庫はこれからの処理の過程で自動的にキャンセルされる場合もある。

次に、送信依頼部５９は、このトランザクションに１対１で対応する受信用メールアドレスを生成する（ステップＳ３０４）。この受信用メールアドレスはメール受信サーバ９が順次処理要求である注文受付指示メールを受信するためのアドレスとして用いられる。送信依頼部５９は、ハッシュ関数等を用いて受信用メールアドレスを生成する。この受信用メールアドレスは第１通信方法により送信された即時処理要求と、送信依頼情報によって、ユーザが操作する端末（ユーザ端末２または他の端末）から送信される順次処理要求（ここでは注文受付指示メール）とを関連づける情報であり、トランザクションやセッションＩＤを特定することを可能とする情報である。受信用メールアドレスは、ハッシュ関数により生成され、受信用メールアドレスからユーザを特定することも防がれる。そして、送信依頼部５９はメール受信サーバ９のメールアドレス管理部６０にこの受信用メールアドレスを渡し（ステップＳ３０５）、また注文データベース中のこのトランザクションに対応する注文情報にこのメールアドレスを追加して格納する。

次に、送信依頼部５９は、注文確認メール（送信依頼情報）の文面を生成する（ステップＳ３０６）。そして、この順次購入要求の注文をしたユーザのメールアドレスに生成された注文確認メールを送信する（ステップＳ３０７）。なお、送信依頼部５９は、In-Reply-Toフィールドに生成された受信用メールアドレスを設定して注文確認メールを送信する。送信依頼部５９は、この受信用メールアドレスが埋め込んだ注文確認メールを送信することで、注文確認メールに、即時処理要求に関連づけられた順次処理要求として注文確認メールに対する返信（注文受付指示メール）をユーザに送信させることが可能になる。

図１１は、注文確認メールの一例を示す図である。注文確認メールには、注文確認画面と同様に、商品の代金の支払に用いる支払手段やポイント利用の有無、配送方法、配送先の情報が記載される。これらの情報はユーザをキーとして顧客データベースに格納されたものである。ただし、注文確認画面と異なり、内容を変更するには再度電子商店街のサイトのウェブページにアクセスする必要がある。また注文確認メールには、注文受付指示メールを送信することにより注文を受付する旨の文面が記載されている。ユーザが用いる支払方法や発送方法を予め設定していれば、支払方法の変更などが生じるケースはそれ以外のケースに比して十分に小さい。

ここで、送信依頼部５９の処理を、高負荷対応ウェブサーバ７で実現してもよい。この場合、送信依頼部５９が仮応答部５８の代わりに即時処理要求を受信し、送信依頼情報を即時処理要求に対する応答としてユーザ端末２に向けて送信してもよい。ここでは送信依頼情報は、注文確認メールに相当する内容が配置され、かつ受信用メールアドレスにメールを送信させる要素が配置された画面を示す情報である。この要素は、例えば「ｍａｉｌｔｏ」のリンクが設定されたテキスト、画像やボタンのうちいずれかであり、この要素に対する所定の操作（例えば、クリック，タップなど）が検出されると送信先などの必要な情報が設定されたメール作成画面を立ちあげさせるような情報である。この場合、注文確認メールを送信する場合に比べると、メール送信待ちキューが不要になる代わりに、送信依頼部５９の処理をリアルタイムで行う必要が生じる。このため、システムの負荷をコントロールしづらくなるが、それでもシステム全体の負荷をある程度削減することや、ピークにおけるシステムの負荷を平準化することができる。

メール受信サーバ９は、ユーザからのメールを受信するサーバである。メール受信サーバ９に含まれるメール受信格納部６１は、プロセッサ２１、記憶部２２、通信部２３を中心として実現される。メール受信格納部６１は、複数のユーザから受信メールアドレスに送信される注文受付指示メール（順次処理要求）を受信し、メール受信キューにそのメールを格納する。その際、メール受信格納部６１は注文受付指示メールを受信した受信時刻もメール本体とともにメール受信キューに格納するとともに、送信元のメールアドレスに受信確認メールを送信する。なお、メール受信格納部６１はどの受信用メールアドレスに向けて送信されたメールも、１つの同じメール受信キューに格納する。メール受信格納部６１は、いわゆるメールサーバソフトウェアであってよい。

メール受信サーバ９に含まれるメールアドレス管理部６０は、プロセッサ２１、記憶部２２、通信部２３を中心として実現される。メールアドレス管理部６０は、受信用メールアドレスを管理する。メールアドレス管理部６０は、複数の受信用メールアドレスをその生成時刻とともに記憶部２２に格納し、また記憶部２２に格納された１または複数の受信用メールアドレスについて、メール受信格納部６１が受信を許可するように制御する。一方、生成時刻から一定時間（例えば、３０分間，１時間など）が経過した受信用メールアドレスを記憶部２２からの削除などで無効にし、その時間が経過した受信用メールアドレスに対する注文受付指示メールをメール受信格納部６１が受信せず、エラーメールを返すように制御する。

このようにして、生成されてから所定の時間が経過した受信用メールアドレス宛に送信されてきた注文受付指示メールに対してエラーメールが送信されることにより、ユーザに対して注文が受付できていないことをより早く知らせることが可能となる。

順次処理サーバ１０に含まれる順次処理部６２は、プロセッサ２１、記憶部２２、通信部２３を中心として実現される。順次処理部６２は、メール受信格納部６１により格納された順次処理要求を順に取得し、順次処理要求に含まれるデータを処理する。

図１２は、順次処理部６２の処理フローの一例を示す図である。はじめに、順次処理部６２は、メール受信キューから、最も早く受信している１つの注文受付指示メール（順次処理要求）を、その受信メールアドレスや受信時刻とともに取得する（ステップＳ４０１）。順次処理部６２は、例えばＰＯＰ３を用いて最も早くに受信した注文受付指示メールをメール受信キューから取得し、その取得された注文受付指示メールをメール受信キューから削除する。

なお、順次処理部６２は、必ずしも受信時刻の順番で注文受付指示メールを取得しなくてもよい。例えば、順次処理部６２が注文受付指示メールが対象とする注文の属性に基づいて注文受付指示メールを取得してもよい。この場合には、メール受信格納部６１は、メール受信キューに格納する代わりに、データベースサーバ６に格納される注文データベースに格納される注文情報のうち、受信したメールの受信メールアドレスを有する注文情報についてメールを受信しかつ未処理であることを示す順次処理フラグと受信時刻とを格納する操作をする。そして、順次処理部６２が、その順次処理フラグが立っている注文情報を所与の条件でソートし、そのソートされた順位にしたがって１または複数の注文情報を取得し、その注文情報について以降の処理を実行するとよい。

ソートのキーとしては、例えば商品やサービスの種類に応じた属性がある。例えば、順次処理部６２は、期間限定の商品や（当日分を含む）宿泊サービス、受注生産商品であるなどの早く処理する必要がある商品やサービスに対する注文情報が上位になるようにソートし、デジタルコンテンツや在庫が確保済の商品、あるいは在庫が十分にあることが予めわかっている商品に対する注文情報が下位になるようソートしてよい。そうすることで、早期に注文を確定させるべき商品またはサービスに関連する注文受付処理を優先的に実行することができる。

また、ソートのキーとして、店舗の種類、発送元と配送先との関係により定まる配達所要日数、決済手段、注文受付から配達までの標準日数などを用いてもよい。

次に、順次処理部６２は受信メールアドレスから注文を特定する（ステップＳ４０２）。順次処理部６２は、例えば注文情報のデータベースを受信メールアドレスで検索することにより、その注文受付指示メールが対象とする注文を特定する。

そして、順次処理部６２は注文に対して支払、在庫引き当ての処理を行う（ステップＳ４０３）。この処理は、注文即時処理部５７の処理に対応するものである。より具体的には、順次処理部６２は特定される注文について、支払種類に応じた支払の処理を行い、店舗の在庫データベースにアクセスして商品の在庫があればそれを引き当て、在庫が引き当てられた商品の発送を外部のシステムに対して指示する。また、順次処理部６２は在庫の引き当ての際に在庫がなければエラーまたは予約扱いにする。また順次処理部６２は、支払状況などに基づいて注文の情報を更新する。この際、順次処理部６２は、この注文受付指示メール（順次処理要求）の受信時刻を注文情報の受付時刻として注文情報に設定する。そして、順次処理部６２は、その上述の処理の結果、注文が受け付けられた場合にはその旨を示す情報と注文番号とを含む処理結果通知メールを生成し、注文がエラーとなった場合にはその旨を示す処理結果通知メールを生成する（ステップＳ４０５）。そして生成された処理結果通知メールをユーザのメールアドレスに送信する（ステップＳ４０６）。そして、ステップＳ４０１からの処理を繰り返す。

第１通信方法で対応することが決定された場合には、即時処理部５４はユーザからの即時処理要求に対してリアルタイムで応答するため、例えば並列的に処理を行っている。そのために仮にアクセスが集中すると電子商取引システム１の負荷が増大する。一方、順次処理部６２は、キュー（メール受信キュー）に格納された順次処理要求を順に処理していくので、並行して処理される順次処理要求の数は一定（本実施形態の例では１）である。アクセスが集中してもキューに格納される順次処理要求が増えていくだけなので、順次処理要求を処理することによる電子商取引システム１の負荷の増大量は限られたものになる。また、アクセスが集中する時間はごく短時間であることが多いため、キューに格納される順次処理要求が増えても、処理に必要な時間をその時間より少し増やせば問題なく処理されることが期待される。これにより、アクセスのピークに対する処理の負荷を平準化することができ、ユーザからのアクセスのピークに対応するためのハードウェアやネットワークの処理能力を削減することができる。

また、注文時刻を順次処理要求の受信時刻とすることで、キャンペーンなどにより注文時刻が重要な注文をしたユーザに対して、不利益を与えることを防ぐことができる。また、こうすることで、ユーザがキャンペーン等の特典を得るためにアクセスしづらい電子商取引システム１にアクセスすることから解放することができる。

順次処理サーバ１０に含まれる引当解除部６３は、プロセッサ２１、記憶部２２、通信部２３を中心として実現される。引当解除部６３は、送信依頼部５９が仮の在庫を引き当ててから所定の時間（例えば１時間）が経過した場合に、その在庫の引き当てをキャンセルする。送信依頼部５９に記載したように、仮の在庫を引き当てるのは数量限定商品などである。引当解除部６３は、ユーザが数量限定商品を注文しようとしたがその注文を確定することを止めたとみなされる場合に、仮の在庫の引き当てを解除し、その在庫に引き当てが解除された商品を他のユーザが購入することを可能にする。

以上で本発明の実施形態について説明してきたが、その形態は上述のものに限定されない。例えば、送信依頼部５９が１つの即時処理要求に対して、１つの送信依頼情報（注文確認メール）だけでなく、その即時処理要求に関連づけられた１または複数の追加の送信依頼情報を送信し、その送信依頼情報それぞれに商品の確認や支払方法の確認などの記載を分散させてもよい。ここで、順次処理部６２は、複数の注文確認メールの全てが返信された場合に、支払、在庫引き当てなどの処理を行ってもよい。こうすると、ユーザが一度に閲覧する文面の量を減らしたり、また外部から無作為のメールアドレスに送信する攻撃がされた場合に誤って注文が確定されてしまうおそれを無くすことも可能となる。

これまでの説明ではアクセスの集中に対応するために、振分け部５２が第１通信方法を用いるか第２通信方法を用いるかを決定しているが、他の基準を用いて決定してもよい。例えば、振分け部５２は通常ウェブサーバ５のハードウェア障害や、通常ウェブサーバ５と負荷分散サーバ４との間のネットワーク障害がある場合に第２通信方法を用いることを決定してもよいし、ユーザ端末２が共用端末である場合に、個人情報や金融関連情報を含むような情報を第２通信方法を用いて送信させるように決定してもよい。また、振分け部５２はトランザクションの途中（例えばカート確認画面情報の送信後）に一定時間以上ユーザからのアクセスがない場合に、第２通信方法を用いて注文確認メールを送るよう決定してもよい。

また、振分け部５２はユーザのランクに基づいて即時処理要求を振分けてもよい。例えば、予めデータベースサーバ６がユーザのそれぞれのランクを特定するためのランク特定情報を記憶しておき、振分け部５２が即時処理要求を送信したユーザに対するランク特定情報に基づいて第１通信方法か第２通信方法かを決定してもよい。より具体的には、負荷分散サーバ４に即時処理要求を送信したユーザＩＤを取得し、そのユーザＩＤのユーザに対するランク特定情報を取得するランク取得部を設け、振分け部５２が、ランク特定情報により特定されるランクがある閾値より高い、または低いなど、所定の範囲内にある場合に第２の通信方法で対応することを決定してもよい。さらに、振分け部５２は、負荷とユーザのランクの両方を用いて即時処理要求を振分けてもよい。この場合、予め、システムの負荷の値の範囲が複数のレベルに分割され、さらにそのレベルとユーザのランクとが関連づけられている。ユーザのランクが高くなるにつれ、対応づけられるレベルが大きくなり、振分け部５２は、システムの負荷の値がユーザのランクに応じたレベルを代表する値以上またはその値を超え、かつ予め定められた種類の即時処理要求である場合に、第２通信方法を用いると決定する。このレベルを代表する値は、そのレベルの上限あるいは下限を示す閾値であってよい。この場合、システムの負荷の値の範囲を複数のレベルに分割する境界である複数の閾値が予め決まっており、ランクが大きくなるほど対応づけられた閾値が大きくなるようにランクと閾値とが対応づけられている。

また、第１通信方法を用いるか、第２通信方法を用いるかの決定は、全ての処理要求に対して行わなくてもよい。いったん第２通信方法を用いたら、その後のユーザ端末２（ユーザが操作する他の端末でもよい）と電子商取引システム１との間の通信を第２通信方法で行うように処理を行ってもよい。

また、ここでは順次処理要求などの応答を必要としない通信はメールで行っているが、代わりに他の通信方法を用いてもよい。例えば、電子商取引システム１からユーザ端末２への通信にはショートメッセージサービス（ＳＭＳ），メッセンジャーやスマートフォンへのプッシュ通知などを用いてもよいし、ユーザ端末２から電子商取引システム１への通信にはショートメッセージサービス（ＳＭＳ）やメッセンジャーを用いてもよい。

１ 電子商取引システム、２ ユーザ端末、３ ネットワーク、４ 負荷分散サーバ、５ 通常ウェブサーバ、６ データベースサーバ、７ 高負荷対応ウェブサーバ、８ メール送信サーバ、９ メール受信サーバ、１０ 順次処理サーバ、２１ プロセッサ、２２ 記憶部、２３ 通信部、２４ 入出力部、５１ 負荷取得部、５２ 振分け部、５３ 即時処理要求受信部、５４ 即時処理部、５５ カート処理部、５６ 注文確認部、５７ 注文即時処理部、５８ 仮応答部、５９ 送信依頼部、６０ メールアドレス管理部、６１ メール受信格納部、６２ 順次処理部、６３ 引当解除部。

Claims (19)

1. 内的要因と外的要因との少なくともいずれかに基づき通常と異なる方針で処理要求に対応する旨を決定する決定手段と、
   前記決定手段により決定がなされた場合に、即時の応答が必要とされる第１方法により要求元から送出されていた前記処理要求が即時の応答が必要とされない第２方法により送出されるよう誘導する誘導手段と、
   を含むことを特徴とする要求処理システム。
2. 前記誘導手段は、前記決定手段により決定がなされた場合に、前記要求元から前記第１方法により送出される他の処理要求に続く、該他の処理要求と一連の前記処理要求が前記第２方法により送出されるよう誘導する、
   ことを特徴とする請求項１に記載の要求処理システム。
3. 前記誘導手段が、前記処理要求を前記第２方法により送出するための宛先を特定する宛先特定情報を前記要求元に報知する、
   ことを特徴とする請求項１または２に記載の要求処理システム。
4. 前記誘導手段が、前記宛先特定情報を含む誘導情報を前記要求元により指定される指定宛先に前記第２方法により送信する、
   ことを特徴とする請求項３に記載の要求処理システム。
5. 前記誘導手段が、前記処理要求を含むトランザクションに関連して前記要求元に確認させるべき要確認情報を含む確認依頼情報を前記第２方法により前記指定宛先に前記誘導情報とは別に送信し、当該確認依頼情報に対する返信として前記処理要求を前記宛先特定情報により特定される宛先に前記第２方法により送信するよう誘導する、
   ことを特徴とする請求項４に記載の要求処理システム。
6. 前記処理要求の直前に前記要求元から前記第１方法により送出された他の要求に対し、前記第２方法により前記確認依頼情報が送信された旨を応答する案内手段をさらに含む、
   ことを特徴とする請求項５に記載の要求処理システム。
7. 前記トランザクションごとに前記宛先特定情報を生成する生成手段をさらに含む、
   ことを特徴とする請求項５又は６に記載の要求処理システム。
8. 前記生成手段により前記宛先特定情報が生成されてから所定の期間が経過した場合に、当該宛先特定情報により特定される宛先を無効化する無効化手段をさらに含む、
   ことを特徴とする請求項７に記載の要求処理システム。
9. 前記トランザクションは商品またはサービスの注文を目的とするものであり、
   前記生成手段により生成される宛先特定情報に関連付けて、当該宛先特定情報に対応するトランザクションにより注文されるべき商品またはサービスの在庫を仮に引き当てる在庫確保手段と、
   前記無効化手段により前記宛先特定情報が無効化された場合に、当該無効化された宛先特定情報に関連付けられている前記仮の在庫の引当てを解除する引当解除手段と、をさらに含む、
   ことを特徴とする請求項８に記載の要求処理システム。
10. 前記第１方法により送出される前記処理要求に応じて所定処理を即時に実行し、当該所定処理が完了した後直ちに前記要求元に応答する第１処理手段と、
    前記第２方法により送出される前記処理要求に応じて前記所定処理に相当する代替処理を随時に実行する第２処理手段と、
    をさらに含むことを特徴とする請求項１から９のいずれかに記載の要求処理システム。
11. 前記第２処理手段が、前記第２方法により前記処理要求を受領した時刻を当該処理要求の受付時刻とみなして前記代替処理を実行する、
    ことを特徴とする請求項１０に記載の要求処理システム。
12. 前記処理要求は、商品またはサービスの注文を受け付ける注文受付処理の要求であり、
    前記第２処理手段が、前記注文の対象をキーとして複数の前記処理要求をソートし、当該注文の対象ごとにまとめて前記注文受付処理を実行する、
    ことを特徴とする請求項１１に記載の要求処理システム。
13. 前記第２処理手段が、早期に注文を確定させるべき商品またはサービスに関連する前記注文受付処理を優先的に実行する、
    ことを特徴とする請求項１２に記載の要求処理システム。
14. システムの負荷の大きさを示す数値を取得する負荷取得手段をさらに含み、
    前記決定手段は、前記負荷取得手段により取得される数値が所定の閾値以上又はこれを越える場合に、通常と異なる方針で処理要求に対応する旨を決定する、
    ことを特徴とする請求項１から１３のいずれかに記載の要求処理システム。
15. 前記要求元のランクの特定に資するランク特定情報を取得するランク取得手段をさらに含み、
    前記決定手段が、さらに、前記ランク取得手段により取得されるランク特定情報により特定される前記要求元のランクが所定の範囲内である場合に、通常と異なる方針で処理要求に対応する旨を決定する、
    ことを特徴とする請求項１４に記載の要求処理システム。
16. 前記システムの負荷の大きさを複数の段階に分割する複数の閾値に対して、前記複数のランクが低い方から順に１又は複数ずつ、当該複数の閾値の小さい方から順にそれぞれ対応付けられており、
    前記決定手段が、前記ランク取得手段により取得されるランク特定情報により特定される前記要求元のランクが当該ランクに対応付けられた閾値以上又はこれを越える場合に、通常と異なる方針で処理要求に対応する旨を決定する、
    ことを特徴とする請求項１５に記載の要求処理システム。
17. 内的要因と外的要因との少なくともいずれかに基づき通常と異なる方針で処理要求に対応する旨を決定する決定ステップと、
    前記決定ステップにおいて決定がなされた場合に、即時の応答が必要とされる第１方法により要求元から送出されていた前記処理要求が即時の応答が必要とされない第２方法により送出されるよう誘導する誘導ステップと、
    を含む、コンピュータによる要求処理方法。
18. 内的要因と外的要因との少なくともいずれかに基づき通常と異なる方針で処理要求に対応する旨を決定し、
    前記通常と異なる方針で処理要求に対応する旨の決定がなされた場合に、即時の応答が必要とされる第１方法により要求元から送出されていた前記処理要求が即時の応答が必要とされない第２方法により送出されるよう誘導する、
    処理をコンピュータに実行させるプログラム。
19. 内的要因と外的要因との少なくともいずれかに基づき通常と異なる方針で処理要求に対応する旨を決定し、
    前記通常と異なる方針で処理要求に対応する旨の決定がなされた場合に、即時の応答が必要とされる第１方法により要求元から送出されていた前記処理要求が即時の応答が必要とされない第２方法により送出されるよう誘導する、
    処理をコンピュータに実行させるプログラムを格納するコンピュータ読取り可能な情報記憶媒体。

Images