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

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

Info

Publication number
JP5653545B2
JP5653545B2 JP2014077350A JP2014077350A JP5653545B2 JP 5653545 B2 JP5653545 B2 JP 5653545B2 JP 2014077350 A JP2014077350 A JP 2014077350A JP 2014077350 A JP2014077350 A JP 2014077350A JP 5653545 B2 JP5653545 B2 JP 5653545B2
Authority
JP
Japan
Prior art keywords
request
processing
communication method
information
order
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.)
Active
Application number
JP2014077350A
Other languages
English (en)
Other versions
JP2014194779A (ja
Inventor
友晴 熊谷
友晴 熊谷
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Rakuten Group Inc
Original Assignee
Rakuten Inc
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Rakuten Inc filed Critical Rakuten Inc
Priority to JP2014077350A priority Critical patent/JP5653545B2/ja
Publication of JP2014194779A publication Critical patent/JP2014194779A/ja
Application granted granted Critical
Publication of JP5653545B2 publication Critical patent/JP5653545B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Landscapes

  • Computer And Data Communications (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Information Transfer Between Computers (AREA)

Description

本発明は要求処理システム、要求処理方法、プログラムおよび情報記憶媒体に関する。
インターネットにおいて電子商取引などを取扱うシステムでは、多数のユーザが短時間に集中してそのシステムにアクセスするケースがあることがよく知られている。アクセスが集中すると、サーバやネットワーク機器などの処理が追いつかなくなり、ユーザからの注文を処理できなくなるなどの問題が生じる。これを避けるために、たとえば予めピーク時のアクセス数を予測し、そのピークでも処理できるハードウェアやネットワーク回線を準備しておくことが行われている。また、負荷に応じて動的にサーバの台数を増やしスケールアウトするシステムも知られている(例えば、特許文献1参照)。
特開2002−342296号公報
しかしながら、通常時の対応を継続することが困難又は不適当な場面を想定した対策として、ハードウェア資源を増強するというアプローチは現実的でないことがある。
一例として、輻輳対策に関して言えば、アクセス数のピークに合わせてリソースを準備しておくことが必ずしも容易でない点が挙げられる。これは、例えば、ピークに合わせてリソースを準備すると通常時の稼働率が下がりコスト効率が悪い、アクセスのピークの大きさを正確に予測することがそもそも難しい、等の事情による。
本発明が解決しようとする課題は、要求元からの要求に応じて処理を実行する場面において、通常と異なる対応をとるべき場合に、通常とは異なる手順により必要な処理が進むように仕向ける、という点である。
上記課題を解決するために、本発明にかかる要求処理システムは、内的要因と外的要因との少なくともいずれかに基づき通常と異なる方針で処理要求に対応する旨を決定する決定手段と、前記決定手段により決定がなされた場合に、即時の応答が必要とされる第1方法により要求元から送出されていた前記処理要求が即時の応答が必要とされない第2方法により送出されるよう誘導する誘導手段と、を含むことを特徴とする。
また、本発明にかかる要求処理方法は、内的要因と外的要因との少なくともいずれかに基づき通常と異なる方針で処理要求に対応する旨を決定する決定ステップと、前記決定ステップにおいて決定がなされた場合に、即時の応答が必要とされる第1方法により要求元から送出されていた前記処理要求が即時の応答が必要とされない第2方法により送出されるよう誘導する誘導ステップと、を含むことを特徴とする。
また、本発明にかかるプログラムは、内的要因と外的要因との少なくともいずれかに基づき通常と異なる方針で処理要求に対応する旨を決定し、前記通常と異なる方針で処理要求に対応する旨の決定がなされた場合に、即時の応答が必要とされる第1方法により要求元から送出されていた前記処理要求が即時の応答が必要とされない第2方法により送出されるよう誘導する、処理をコンピュータに実行させることを特徴とする。
また、本発明にかかるコンピュータ読取り可能な記憶媒体は、上記プログラムを格納する。
本発明によれば、要求元からの要求に応じて処理を実行する場面において、通常と異なる対応をとるべき場合に、通常とは異なる手順により必要な処理が進むようにできる。
本発明の一態様では、前記誘導手段は、前記決定手段により決定がなされた場合に、前記要求元から前記第1方法により送出される他の処理要求に続く、該他の処理要求と一連の前記処理要求が前記第2方法により送出されるよう誘導してもよい。
本発明の一態様では、前記誘導手段が、前記処理要求を前記第2方法により送出するための宛先を特定する宛先特定情報を前記要求元に報知してもよい。
本発明の一態様では、前記誘導手段が、前記宛先特定情報を含む誘導情報を前記要求元により指定される指定宛先に前記第2方法により送信してもよい。
本発明の一態様では、前記誘導手段が、前記処理要求を含むトランザクションに関連して前記要求元に確認させるべき要確認情報を含む確認依頼情報を前記第2方法により前記指定宛先に前記誘導情報とは別に送信し、当該確認依頼情報に対する返信として前記処理要求を前記宛先特定情報により特定される宛先に前記第2方法により送信するよう誘導してもよい。
本発明の一態様では、前記要求処理システムは、前記処理要求の直前に前記要求元から前記第1方法により送出された他の要求に対し、前記第2方法により前記確認依頼情報が送信された旨を応答する案内手段をさらに含んでもよい。
本発明の一態様では、前記要求処理システムは、前記トランザクションごとに前記宛先特定情報を生成する生成手段をさらに含んでもよい。
本発明の一態様では、前記要求処理システムは、前記生成手段により前記宛先特定情報が生成されてから所定の期間が経過した場合に、当該宛先特定情報により特定される宛先を無効化する無効化手段をさらに含んでもよい。
本発明の一態様では、前記トランザクションは商品またはサービスの注文を目的とするものであり、前記要求処理システムは、前記生成手段により生成される宛先特定情報に関連付けて、当該宛先特定情報に対応するトランザクションにより注文されるべき商品またはサービスの在庫を仮に引き当てる在庫確保手段と、前記無効化手段により前記宛先特定情報が無効化された場合に、当該無効化された宛先特定情報に関連付けられている前記仮の在庫の引当てを解除する引当解除手段と、をさらに含んでもよい。
本発明の一態様では、前記要求処理システムは、前記第1方法により送出される前記処理要求に応じて所定処理を即時に実行し、当該所定処理が完了した後直ちに前記要求元に応答する第1処理手段と、前記第2方法により送出される前記処理要求に応じて前記所定処理に相当する代替処理を随時に実行する第2処理手段と、をさらに含んでもよい。
本発明の一態様では、前記第2処理手段が、前記第2方法により前記処理要求を受領した時刻を当該処理要求の受付時刻とみなして前記代替処理を実行してもよい。
本発明の一態様では、前記処理要求は、商品またはサービスの注文を受け付ける注文受付処理の要求であり、前記第2処理手段が、前記注文の対象をキーとして複数の前記処理要求をソートし、当該注文の対象ごとにまとめて前記注文受付処理を実行してもよい。
本発明の一態様では、前記第2処理手段が、早期に注文を確定させるべき商品またはサービスに関連する前記注文受付処理を優先的に実行してもよい。
本発明の一態様では、前記要求処理システムは、システムの負荷の大きさを示す数値を取得する負荷取得手段をさらに含み、前記決定手段は、前記負荷取得手段により取得される数値が所定の閾値以上又はこれを越える場合に、通常と異なる方針で処理要求に対応する旨を決定してもよい。
本発明の一態様では、前記要求処理システムは、前記要求元のランクの特定に資するランク特定情報を取得するランク取得手段をさらに含み、前記決定手段が、さらに、前記ランク取得手段により取得されるランク特定情報により特定される前記要求元のランクが所定の範囲内である場合に、通常と異なる方針で処理要求に対応する旨を決定してもよい。
本発明の実施形態にかかる電子商取引システムの構成の一例を示す図である。 電子商取引システムに含まれるサーバのハードウェア構成の一例を示す図である。 本発明の実施形態にかかる電子商取引システムが実現する機能を示す機能ブロック図である。 負荷取得部および振分け部の処理フローの一例を示す図である。 第1通信方法のみを用いる場合の処理の流れの一例を示すシーケンス図である。 買い物かご確認画面の一例を示す図である。 注文確認画面の一例を示す図である。 第1通信方法と第2通信方法とを用いる場合の処理の流れの一例を示すシーケンス図である。 仮応答部の処理フローの一例を示す図である。 送信依頼部の処理フローの一例を示す図である。 注文確認メールの一例を示す図である。 順次処理部の処理フローの一例を示す図である。
以下では、本発明の実施形態を図面に基づいて説明する。同じ符号が付された構成については、重複する説明を省略する。
図1は、本発明の実施形態にかかる電子商取引システム1のハードウェア構成の一例を示す図である。この電子商取引システム1は、ネットワーク3を介してユーザ端末2からの商品およびサービスの注文や発送、決済(支払ともいう)などの要求を処理するシステムである。以下ではこのシステムが複数の店舗に対して電子商取引の場を提供する電子商店街システムであるとして説明する。なお、以下では「商品」と呼ぶ場合、特に断りがない場合はサービスも含むものとする。
電子商取引システム1は、負荷分散サーバ4と、複数の通常ウェブサーバ5と、データベースサーバ6と、高負荷対応ウェブサーバ7と、メール送信サーバ8と、メール受信サーバ9と、順次処理サーバ10とを含む。負荷分散サーバ4は、いわゆるロードバランサであり、通常ウェブサーバ5のそれぞれの負荷が限界に達しないようにユーザ端末2からのhttp要求を転送する。負荷分散サーバ4は、この電子商取引システム1の負荷を示す情報を定期的に取得しており、その情報に基づいてユーザ端末2からのhttp要求を複数の通常ウェブサーバ5のいずれかまたは高負荷対応ウェブサーバ7に転送する。
通常ウェブサーバ5はユーザ端末2からの各種http要求をリアルタイムに処理し、その処理結果を、http要求に対するhttp応答としてユーザ端末2に返す。高負荷対応ウェブサーバ7、メール送信サーバ8、メール受信サーバ9、順次処理サーバ10は、この電子商取引システム1の負荷を示す値が上限を超えた場合にhttp要求に対応する処理を行う。これらのサーバの処理の詳細については後述する。ここで、http要求およびhttp応答を用いる通信プロトコルをhttpプロトコルという。httpプロトコルは、http要求に対し一定時間内にhttp応答があることを前提とする通信プロトコルである。httpプロトコルのようにリアルタイムで応答が帰ってくることを前提とする通信方法による要求を以下では「即時処理要求」と記載する。
データベースサーバ6は商品マスタと、顧客データベースと、ユーザからの注文商品や決済・発送方法などを含む注文情報のデータベース(注文データベース)と、その他のデータベースを格納する。データベースサーバ6はいわゆるデータベース管理ソフトウェアを実行することでこれらのデータを格納し管理する。注文情報はいわゆるトランザクションデータの一種である。
図2は電子商取引システム1に含まれる各サーバのハードウェア構成の一例を示す図である。負荷分散サーバ4、複数の通常ウェブサーバ5、データベースサーバ6、高負荷対応ウェブサーバ7、メール送信サーバ8、メール受信サーバ9、および順次処理サーバ10のそれぞれは、プロセッサ21、記憶部22、通信部23、入出力部24を含む。
プロセッサ21は、記憶部22に格納されているプログラムに従って動作する。またプロセッサ21は通信部23、入出力部24を制御する。なお、上記プログラムは、インターネット等を介して提供されるものであってもよいし、フラッシュメモリやDVD−ROM等のコンピュータで読み取り可能な記憶媒体に格納されて提供されるものであってもよい。
記憶部22は、RAMやフラッシュメモリ等のメモリ素子やハードディスクドライブによって構成されている。記憶部22は、上記プログラムを格納する。また、記憶部22は、各部から入力される情報や演算結果を格納する。
通信部23は、他の装置と通信する機能を実現するものであり、例えば無線LANの集積回路やアンテナなどにより構成されている。通信部23は、プロセッサ21の制御に基づいて、他の装置から受信した情報をプロセッサ21や記憶部22に入力し、他の装置に情報を送信する。
入出力部24は、ビデオコントローラや、キーボードやマウスなどの入力デバイスからのデータを取得するコントローラなどにより構成される。入出力部24は、プロセッサ21の制御に基づいて、表示出力デバイスに表示データを出力し、入力デバイスをユーザが操作することにより入力されるデータを取得する。
図3は、本発明の実施形態にかかる電子商取引システム1が実現する機能を示す機能ブロック図である。電子商取引システム1は、機能的に、負荷取得部51と、振分け部52と、即時処理要求受信部53と、即時処理部54と、仮応答部58と、送信依頼部59と、メールアドレス管理部60と、メール受信格納部61と、順次処理部62と、引当解除部63とを含む。また、即時処理部54は、カート処理部55と、注文確認部56と、注文即時処理部57とを含む。
負荷分散サーバ4が負荷取得部51および振分け部52を実現し、通常ウェブサーバ5は即時処理要求受信部53および即時処理部54を実現し、高負荷対応ウェブサーバ7は仮応答部58を実現し、メール送信サーバ8は送信依頼部59を実現し、メール受信サーバ9はメール受信格納部61およびメールアドレス管理部60を実現し、順次処理サーバ10は順次処理部62および引当解除部63を実現する。より具体的には、これらの機能は、その機能のそれぞれを実現するサーバに含まれるプロセッサ21が、記憶部22に格納されたプログラムを実行し通信部23等を制御することにより実現される。
以下では、電子商取引システム1が実現する各機能について、シーケンス図や処理フローなどの図面を用いて説明する。
図4は、負荷取得部51および振分け部52の処理フローの一例を示す図である。図4に示す処理は、ユーザ端末2から即時処理要求を受信するたびに実行される。
負荷取得部51は、負荷分散サーバ4のプロセッサ21、記憶部22および通信部23を中心として実現される。負荷取得部51は、システムの負荷を示す情報を取得する(ステップS101)。システムの負荷を示す情報は、通常ウェブサーバ5のそれぞれが処理しているhttpセッションの数や、通常ウェブサーバ5およびデータベースサーバ6のCPU使用率やメモリ使用率などに基づいて計算される値であってよい。
振分け部52は、負荷分散サーバ4のプロセッサ21、記憶部22および通信部23を中心として実現される。振分け部52は、内的要因と外的要因との少なくともいずれかに基づいて、通常の通信方法(第1通信方法)で処理要求に対応するか、通常と異なる通信方法(第2通信方法)で処理要求に対応するかを決定し、その決定にしたがって即時処理要求を通常ウェブサーバ5または高負荷対応ウェブサーバ7に振分ける。ここでは、振分け部52は、負荷取得部51が取得したシステムの負荷を示す数値などの情報に基づいて、数値が所定の閾値以上又はこれを越える場合に、第2通信方法で処理要求に対応することを決定する。第1通信方法はhttpなど、要求(例えば、httpリクエスト)に対して即時の応答(例えば、httpレスポンス)が必要とされるプロトコルに基づく通信の方法であり、第2通信方法はSMTPなど、即時の応答が必要とされないプロトコルに基づく通信の方法(例えば、電子メール)である。第1通信方法で処理要求に対応する場合は、電子商取引システム1が応答の送信を必要とする即時処理要求をリアルタイムで処理し、その処理結果に基づいて即時処理要求に対する応答を送信する。第2通信方法で処理要求に対応する場合には、電子商取引システム1が即時処理要求に基づいて取得した順次処理要求をキューに格納する。キューには未処理の1または複数の順次処理要求が格納される。そして、電子商取引システム1がそのキューに格納された前記順次処理要求を順に取得して処理する。
振分け部52はより具体的には、ユーザ端末2から受信した即時処理要求を受信し(ステップS102)、電子商取引システム1の負荷を示す値が閾値以下である場合(ステップS103のN)または即時処理要求が購入指示情報でない場合(ステップS104のN)には、即時処理要求を通常ウェブサーバ5のいずれかに転送する(ステップS105)。この転送は、第1通信方法で処理要求に対応すると決定することに相当する。ここで、振分け部52は、複数の通常ウェブサーバ5の間で負荷が平準化するように転送先の通常ウェブサーバ5を選択する。一方、電子商取引システム1の負荷の値が閾値より高く(ステップS103のY)かつ即時処理要求が購入指示情報である場合(ステップS104のY)には即時処理要求を高負荷対応ウェブサーバ7に転送する(ステップS106)。この転送は、第2通信方法で処理要求に対応すると決定することに相当する。なお、購入指示情報などの詳細については後述する。
次に、常に第1通信方法で処理要求に対応する場合の処理の流れおよびそれに関連する処理について説明する。図5は、第1通信方法のみを用いる場合の処理の流れの一例を示すシーケンス図である。これは一般的な電子商店街サイトの処理内容とほぼ同じものである。本図におけるカート確認指示情報、購入指示情報、注文受付指示情報は即時処理要求として送信される情報(つまり、即時の応答が必要とされるhttpリクエストと一体化して送信される情報)である。本図に示さないが、商品を選択するための画面を表示させる情報を含む要求および応答も実際には存在する。また、カート確認情報、注文確認情報、注文結果応答は、それぞれカート確認指示情報、購入指示情報、注文受付指示情報に対する応答であり、例えばユーザ端末2のブラウザ等に画面を表示させるためのHTMLデータなどに含まれる(つまり、即時の応答であるhttpレスポンスと一体化して送信される)。ここで、カート確認指示情報、購入指示情報、注文受付指示情報の一連の即時処理要求は処理の流れのトランザクションを構成する。また、即時処理要求は属するトランザクションを特定するID(例えば、httpセッションを識別するセッションID又はこれに対応する文字列(例えば、セッションIDを所定の規則により変換した文字列))を含んでいる。通常ウェブサーバ5がユーザ端末2からの最初のアクセスの際にセッションIDを生成し、そのセッションIDはユーザ端末2のブラウザによってクッキーなどとして保存される。
即時処理要求受信部53は、通常ウェブサーバ5のプロセッサ21、記憶部22および通信部23を中心として実現される。即時処理要求受信部53は、振分け部52から転送された即時処理要求を通信部23を介して受信し、即時処理部54に渡す。
即時処理部54、および即時処理部54に含まれるカート処理部55、注文確認部56、注文即時処理部57は、通常ウェブサーバ5のプロセッサ21、記憶部22および通信部23を中心として実現される。カート処理部55、注文確認部56、注文即時処理部57は、それぞれカート確認指示情報、購入指示情報、注文受付指示情報に含まれる注文に関するデータを処理し、その処理結果を含むhttp応答をユーザ端末2に向けて送信する。
カート処理部55はカート確認指示情報に基づいて、データベースサーバ6または記憶部22内のキャッシュから買い物かごの情報を検索し、検索された買い物かごに含まれる商品の名称や価格などの情報を含む買い物かご確認画面を示すカート確認情報を生成し、そのカート確認情報をhttp応答としてユーザ端末2に向けて送信する。ここで、カート確認指示情報は、ユーザが電子商取引において商品を選択し、商品を買い物かごに入れる、または買い物かごを確認する旨のボタンが押下された場合に、ユーザ端末2から送信されるものである。
図6は、買い物かご確認画面の一例を示す図である。買い物かご確認画面には、その買い物かごに含まれる商品を販売する店舗の情報、商品名や単価といったデータベース内の商品マスタから取得される情報、そして商品の数量といったカート情報から取得される情報が配置されている。また、買い物かご確認画面には、それぞれの商品について購入するか否かを指定するチェックボックスや、商品を買い物かごから削除するか否かを指定する「削除」ボタンが配置されている。ユーザが「削除」ボタンを押下すると、ユーザ端末2はその商品を買い物かごから削除する旨を含むカート確認指示情報を電子商取引システム1に向けて送信する。また、ユーザが「購入手続き」ボタンを押下すると、ユーザ端末2は購入指示情報を電子商取引システム1に向けて送信する。
注文確認部56は、購入指示情報に基づいて、顧客データベースからそのユーザについての決済情報や配送情報などを取得し、さらに支払金額の情報を生成する。そして、支払金額、決済情報や配送情報を含む注文確認画面を示す注文確認情報を生成し、その注文確認情報をhttp応答としてユーザ端末2に向けて送信する。また注文確認部56は、確定前の注文の注文情報を注文データベースに格納する。
図7は、注文確認画面の一例を示す図である。注文確認画面には、商品の代金の支払に用いる支払手段やポイント利用の有無、配送方法、配送先の情報が配置される。これらの情報はユーザをキーとして顧客データベースに格納されたものである。顧客データベースには、この注文確認画面に出力させる支払方法や配送先の情報が格納されている。ユーザがその項目のそれぞれの右側にある「変更」ボタンを押下すると、これらの情報を変更することが可能になり、これらの情報を変更する旨の注文受付指示情報がユーザ端末2から送信されると、注文確認部56は変更された注文確認画面を示す注文確認情報を送信する。また、ユーザが「注文申込」ボタンを押下すると、ユーザ端末2は注文受付指示情報を電子商取引システム1に向けて送信する。
注文即時処理部57は、注文受付指示情報に基づいて、受け付けられた注文への対応を進めるための処理を行う。より具体的には、注文即時処理部57は、ユーザの注文に対する決済処理や在庫割当てなどの処理を行う。より具体的には、注文即時処理部57は注文受付指示情報により指定される注文について、支払種類に応じた支払の処理を行い、店舗の在庫データベースにアクセスして商品の在庫があればそれを割当て、割り当てられた商品の発送を外部のシステムに対して指示する。支払の処理は例えば支払の種類がクレジットカードであれば与信や売上の処理であり、銀行振込であれば振込依頼票を外部システムに発行させる処理である。また、注文即時処理部57は、在庫の割当ての際に在庫がなければエラーまたは予約扱いにする。注文即時処理部57は、発送の指示において、在庫の割当て状況や、支払の結果などに応じてバッチ処理システムに発送の準備等の処理をさせるよう指示する。また注文即時処理部57は、支払状況などに基づいて注文の情報を更新する。この際、注文即時処理部57は、この処理を行っている時刻を注文時刻として注文情報に設定する。そして、注文即時処理部57は、その上述の処理の結果、注文が受け付けられた場合にはその旨を示す情報と注文番号とを含む画面を示す注文結果応答を生成して送信し、注文がエラーとなった場合にはその旨を示す情報を含む画面を示す注文結果応答を生成して送信する。
注文即時処理部57の処理は、注文情報の更新や外部システムとの連携が絡むため、時間がかかりやすくシステムに負荷をかけやすい。一方で顧客の注文を受け付けるという重要な処理であるため、処理そのものをなくすことはできない。第1通信方法だけで処理を行う従来のシステムでは、注文受付指示情報を受信してから注文結果応答を送信するまでのごくわずかな時間内に実行されるべき注文即時処理部57の処理の負荷が問題となる。また、電子商店街では、所定の期間内に所定の購買が行われたことを条件にユーザに何らかの特典を付与するキャンペーン(すなわち、注文情報の受付時刻がキャンペーンの適否を判定する上で極めて重要な意味をもつタイプのキャンペーン)を行う場合がある。この場合には、期間限定のキャンペーンの適用を受けるために、多数のユーザがその期間の終了間際に電子商店街システムにアクセスすることが多い。そのためキャンペーンの期限間近に電子商店街システム全体に対してアクセスが集中する傾向がある。この場合は例えば動的なハードウェアの増強は非常に難しい。
次に、上述の従来の問題に対処するために第1通信方法だけでなく第2通信方法も用いる場合の処理の流れおよびそれに関連する処理について説明する。図8は、第1通信方法と第2通信方法とを用いる場合の処理の流れの一例を示すシーケンス図である。本図におけるカート確認指示情報、購入指示情報は即時処理要求である。また、カート確認指示情報および仮応答情報は、それぞれカート確認指示情報および購入指示情報に対するhttp応答であり、ユーザ端末2のブラウザ等に画面を表示させるためのHTMLデータなどである。
カート確認指示情報は、振分け部52により通常ウェブサーバ5に転送される。この処理内容は図5を用いて説明したものと同じであるので省略する。なお、図8に示さない商品を選択するための画面を表示させる要求や応答についても通常ウェブサーバ5が処理する。なお、カート処理部55の処理までを通常ウェブサーバ5に処理させるのは、いくつか理由がある。1つは、商品の選択の操作をしないと注文を確定することが難しいことである。原則的に用いる支払や発送の方法に関する情報は事前に設定できるが、商品の選択についてはウェブを用いたリアルタイム処理の必要性が高い。もう1つの理由は、システムの負荷が後続の画面に関する処理に比べて小さいことである。カート処理部55の処理では、注文情報といったトランザクションデータに対するアクセスや更新が発生するものの、アクセス箇所は限られるためその処理の負荷は注文即時処理部57等に比べれば小さい。
第2通信方法を用いると決定された場合には、ユーザからの購入指示情報は、振分け部52により、高負荷対応ウェブサーバ7に転送される。
仮応答部58は、高負荷対応ウェブサーバ7のプロセッサ21、記憶部22および通信部23を中心として実現される。仮応答部58は、第2通信方法を用いることが決定された場合に転送された即時処理要求に対して、順次処理要求によって注文に関する手続きを進める旨の画面を示す仮応答情報をhttp応答としてユーザ端末2に向けて送信する。この仮応答情報には、ユーザ端末2の画面に即時処理要求を送信させるためのボタンやリンクなどの要素は含まれていない。こうすると、あるトランザクションにおいて以降の第1通信方法(httpなど)でのアクセスを抑止し、ユーザに第2通信方法(メールなど)を用いたアクセスに誘導することが可能になる。
また、仮応答部58は、この順次処理要求をユーザに送信させるための情報をメール送信サーバ8に送信させるためのメール送信待ちキューに、この即時処理要求に含まれる注文を特定する情報(「順次購入要求」とも呼ぶ)を格納する。仮応答部58の処理の対象となる即時処理要求は購入指示情報である。
図9は、仮応答部58の処理フローの一例を示す図である。仮応答部58は、はじめに、振分け部52から転送された即時処理要求を受信して取得する(ステップS201)、そして、仮応答部58は、その注文を特定する情報(順次購入要求)をメール送信待ちキューに格納する(ステップS202)。そして、即時処理要求への応答として、ユーザが順次処理要求を送信するためのメールをユーザのメールアドレスに向けて送信することを示す画面を示す仮応答情報を送信する(ステップS203)。
送信依頼部59は、メール送信サーバ8のプロセッサ21、記憶部22および通信部23を中心として実現される。送信依頼部59は、購入指示情報の即時処理要求を送信したユーザに対して、第2通信方法(応答を必要としない通信プロトコル)で順次処理要求を送信することを依頼する情報である送信依頼情報を送信する。送信依頼情報は、図8の例では、注文確認メールである。さらにいえば、送信依頼部59は、メール送信待ちキューに格納された順次購入要求を順に取得し、その順次購入要求が示す注文をしたユーザに対して送信依頼情報を送信する。言い換えれば、送信依頼部59は、送信依頼情報に基づいて、ユーザに第2通信方法を用いて電子商取引システム1に向けて(順次)処理要求を送信させるよう誘導している。
図10は、送信依頼部59の処理フローの一例を示す図である。はじめに、メール送信サーバ8に含まれる送信依頼部59は、メール送信待ちキューから、順次処理要求の格納順にしたがって、1件の順次購入要求を取得する(ステップS301)。次に、送信依頼部59は、この順次購入要求から注文を特定する情報を取得し、注文データベースや顧客データベースから注文に関する情報や、顧客のメールアドレスなどの情報を取得する(ステップS302)。ここで送信依頼部59が取得する注文に関する情報は、注文確認部56が取得するものと同じものである。次に、注文に含まれる商品が数量限定の商品や定員限定サービスの予約など、品切れになると注文が成立しない種類の商品である場合には、送信依頼部59は在庫をこの注文に対して引き当てる(ステップS303)。ここで送信依頼部59が行う在庫の引き当ては一種の予約であり、仮の在庫引き当てである。引き当てられた在庫はこれからの処理の過程で自動的にキャンセルされる場合もある。
次に、送信依頼部59は、このトランザクションに1対1で対応する受信用メールアドレスを生成する(ステップS304)。この受信用メールアドレスはメール受信サーバ9が順次処理要求である注文受付指示メールを受信するためのアドレスとして用いられる。送信依頼部59は、ハッシュ関数等を用いて受信用メールアドレスを生成する。この受信用メールアドレスは第1通信方法により送信された即時処理要求と、送信依頼情報によって、ユーザが操作する端末(ユーザ端末2または他の端末)から送信される順次処理要求(ここでは注文受付指示メール)とを関連づける情報であり、トランザクションやセッションIDを特定することを可能とする情報である。受信用メールアドレスは、ハッシュ関数により生成され、受信用メールアドレスからユーザを特定することも防がれる。そして、送信依頼部59はメール受信サーバ9のメールアドレス管理部60にこの受信用メールアドレスを渡し(ステップS305)、また注文データベース中のこのトランザクションに対応する注文情報にこのメールアドレスを追加して格納する。
次に、送信依頼部59は、注文確認メール(送信依頼情報)の文面を生成する(ステップS306)。そして、この順次購入要求の注文をしたユーザのメールアドレスに生成された注文確認メールを送信する(ステップS307)。なお、送信依頼部59は、In-Reply-Toフィールドに生成された受信用メールアドレスを設定して注文確認メールを送信する。送信依頼部59は、この受信用メールアドレスが埋め込んだ注文確認メールを送信することで、注文確認メールに、即時処理要求に関連づけられた順次処理要求として注文確認メールに対する返信(注文受付指示メール)をユーザに送信させることが可能になる。
図11は、注文確認メールの一例を示す図である。注文確認メールには、注文確認画面と同様に、商品の代金の支払に用いる支払手段やポイント利用の有無、配送方法、配送先の情報が記載される。これらの情報はユーザをキーとして顧客データベースに格納されたものである。ただし、注文確認画面と異なり、内容を変更するには再度電子商店街のサイトのウェブページにアクセスする必要がある。また注文確認メールには、注文受付指示メールを送信することにより注文を受付する旨の文面が記載されている。ユーザが用いる支払方法や発送方法を予め設定していれば、支払方法の変更などが生じるケースはそれ以外のケースに比して十分に小さい。
ここで、送信依頼部59の処理を、高負荷対応ウェブサーバ7で実現してもよい。この場合、送信依頼部59が仮応答部58の代わりに即時処理要求を受信し、送信依頼情報を即時処理要求に対する応答としてユーザ端末2に向けて送信してもよい。ここでは送信依頼情報は、注文確認メールに相当する内容が配置され、かつ受信用メールアドレスにメールを送信させる要素が配置された画面を示す情報である。この要素は、例えば「mailto」のリンクが設定されたテキスト、画像やボタンのうちいずれかであり、この要素に対する所定の操作(例えば、クリック,タップなど)が検出されると送信先などの必要な情報が設定されたメール作成画面を立ちあげさせるような情報である。この場合、注文確認メールを送信する場合に比べると、メール送信待ちキューが不要になる代わりに、送信依頼部59の処理をリアルタイムで行う必要が生じる。このため、システムの負荷をコントロールしづらくなるが、それでもシステム全体の負荷をある程度削減することや、ピークにおけるシステムの負荷を平準化することができる。
メール受信サーバ9は、ユーザからのメールを受信するサーバである。メール受信サーバ9に含まれるメール受信格納部61は、プロセッサ21、記憶部22、通信部23を中心として実現される。メール受信格納部61は、複数のユーザから受信メールアドレスに送信される注文受付指示メール(順次処理要求)を受信し、メール受信キューにそのメールを格納する。その際、メール受信格納部61は注文受付指示メールを受信した受信時刻もメール本体とともにメール受信キューに格納するとともに、送信元のメールアドレスに受信確認メールを送信する。なお、メール受信格納部61はどの受信用メールアドレスに向けて送信されたメールも、1つの同じメール受信キューに格納する。メール受信格納部61は、いわゆるメールサーバソフトウェアであってよい。
メール受信サーバ9に含まれるメールアドレス管理部60は、プロセッサ21、記憶部22、通信部23を中心として実現される。メールアドレス管理部60は、受信用メールアドレスを管理する。メールアドレス管理部60は、複数の受信用メールアドレスをその生成時刻とともに記憶部22に格納し、また記憶部22に格納された1または複数の受信用メールアドレスについて、メール受信格納部61が受信を許可するように制御する。一方、生成時刻から一定時間(例えば、30分間,1時間など)が経過した受信用メールアドレスを記憶部22からの削除などで無効にし、その時間が経過した受信用メールアドレスに対する注文受付指示メールをメール受信格納部61が受信せず、エラーメールを返すように制御する。
このようにして、生成されてから所定の時間が経過した受信用メールアドレス宛に送信されてきた注文受付指示メールに対してエラーメールが送信されることにより、ユーザに対して注文が受付できていないことをより早く知らせることが可能となる。
順次処理サーバ10に含まれる順次処理部62は、プロセッサ21、記憶部22、通信部23を中心として実現される。順次処理部62は、メール受信格納部61により格納された順次処理要求を順に取得し、順次処理要求に含まれるデータを処理する。
図12は、順次処理部62の処理フローの一例を示す図である。はじめに、順次処理部62は、メール受信キューから、最も早く受信している1つの注文受付指示メール(順次処理要求)を、その受信メールアドレスや受信時刻とともに取得する(ステップS401)。順次処理部62は、例えばPOP3を用いて最も早くに受信した注文受付指示メールをメール受信キューから取得し、その取得された注文受付指示メールをメール受信キューから削除する。
なお、順次処理部62は、必ずしも受信時刻の順番で注文受付指示メールを取得しなくてもよい。例えば、順次処理部62が注文受付指示メールが対象とする注文の属性に基づいて注文受付指示メールを取得してもよい。この場合には、メール受信格納部61は、メール受信キューに格納する代わりに、データベースサーバ6に格納される注文データベースに格納される注文情報のうち、受信したメールの受信メールアドレスを有する注文情報についてメールを受信しかつ未処理であることを示す順次処理フラグと受信時刻とを格納する操作をする。そして、順次処理部62が、その順次処理フラグが立っている注文情報を所与の条件でソートし、そのソートされた順位にしたがって1または複数の注文情報を取得し、その注文情報について以降の処理を実行するとよい。
ソートのキーとしては、例えば商品やサービスの種類に応じた属性がある。例えば、順次処理部62は、期間限定の商品や(当日分を含む)宿泊サービス、受注生産商品であるなどの早く処理する必要がある商品やサービスに対する注文情報が上位になるようにソートし、デジタルコンテンツや在庫が確保済の商品、あるいは在庫が十分にあることが予めわかっている商品に対する注文情報が下位になるようソートしてよい。そうすることで、早期に注文を確定させるべき商品またはサービスに関連する注文受付処理を優先的に実行することができる。
また、ソートのキーとして、店舗の種類、発送元と配送先との関係により定まる配達所要日数、決済手段、注文受付から配達までの標準日数などを用いてもよい。
次に、順次処理部62は受信メールアドレスから注文を特定する(ステップS402)。順次処理部62は、例えば注文情報のデータベースを受信メールアドレスで検索することにより、その注文受付指示メールが対象とする注文を特定する。
そして、順次処理部62は注文に対して支払、在庫引き当ての処理を行う(ステップS403)。この処理は、注文即時処理部57の処理に対応するものである。より具体的には、順次処理部62は特定される注文について、支払種類に応じた支払の処理を行い、店舗の在庫データベースにアクセスして商品の在庫があればそれを引き当て、在庫が引き当てられた商品の発送を外部のシステムに対して指示する。また、順次処理部62は在庫の引き当ての際に在庫がなければエラーまたは予約扱いにする。また順次処理部62は、支払状況などに基づいて注文の情報を更新する。この際、順次処理部62は、この注文受付指示メール(順次処理要求)の受信時刻を注文情報の受付時刻として注文情報に設定する。そして、順次処理部62は、その上述の処理の結果、注文が受け付けられた場合にはその旨を示す情報と注文番号とを含む処理結果通知メールを生成し、注文がエラーとなった場合にはその旨を示す処理結果通知メールを生成する(ステップS405)。そして生成された処理結果通知メールをユーザのメールアドレスに送信する(ステップS406)。そして、ステップS401からの処理を繰り返す。
第1通信方法で対応することが決定された場合には、即時処理部54はユーザからの即時処理要求に対してリアルタイムで応答するため、例えば並列的に処理を行っている。そのために仮にアクセスが集中すると電子商取引システム1の負荷が増大する。一方、順次処理部62は、キュー(メール受信キュー)に格納された順次処理要求を順に処理していくので、並行して処理される順次処理要求の数は一定(本実施形態の例では1)である。アクセスが集中してもキューに格納される順次処理要求が増えていくだけなので、順次処理要求を処理することによる電子商取引システム1の負荷の増大量は限られたものになる。また、アクセスが集中する時間はごく短時間であることが多いため、キューに格納される順次処理要求が増えても、処理に必要な時間をその時間より少し増やせば問題なく処理されることが期待される。これにより、アクセスのピークに対する処理の負荷を平準化することができ、ユーザからのアクセスのピークに対応するためのハードウェアやネットワークの処理能力を削減することができる。
また、注文時刻を順次処理要求の受信時刻とすることで、キャンペーンなどにより注文時刻が重要な注文をしたユーザに対して、不利益を与えることを防ぐことができる。また、こうすることで、ユーザがキャンペーン等の特典を得るためにアクセスしづらい電子商取引システム1にアクセスすることから解放することができる。
順次処理サーバ10に含まれる引当解除部63は、プロセッサ21、記憶部22、通信部23を中心として実現される。引当解除部63は、送信依頼部59が仮の在庫を引き当ててから所定の時間(例えば1時間)が経過した場合に、その在庫の引き当てをキャンセルする。送信依頼部59に記載したように、仮の在庫を引き当てるのは数量限定商品などである。引当解除部63は、ユーザが数量限定商品を注文しようとしたがその注文を確定することを止めたとみなされる場合に、仮の在庫の引き当てを解除し、その在庫に引き当てが解除された商品を他のユーザが購入することを可能にする。
以上で本発明の実施形態について説明してきたが、その形態は上述のものに限定されない。例えば、送信依頼部59が1つの即時処理要求に対して、1つの送信依頼情報(注文確認メール)だけでなく、その即時処理要求に関連づけられた1または複数の追加の送信依頼情報を送信し、その送信依頼情報それぞれに商品の確認や支払方法の確認などの記載を分散させてもよい。ここで、順次処理部62は、複数の注文確認メールの全てが返信された場合に、支払、在庫引き当てなどの処理を行ってもよい。こうすると、ユーザが一度に閲覧する文面の量を減らしたり、また外部から無作為のメールアドレスに送信する攻撃がされた場合に誤って注文が確定されてしまうおそれを無くすことも可能となる。
これまでの説明ではアクセスの集中に対応するために、振分け部52が第1通信方法を用いるか第2通信方法を用いるかを決定しているが、他の基準を用いて決定してもよい。例えば、振分け部52は通常ウェブサーバ5のハードウェア障害や、通常ウェブサーバ5と負荷分散サーバ4との間のネットワーク障害がある場合に第2通信方法を用いることを決定してもよいし、ユーザ端末2が共用端末である場合に、個人情報や金融関連情報を含むような情報を第2通信方法を用いて送信させるように決定してもよい。また、振分け部52はトランザクションの途中(例えばカート確認画面情報の送信後)に一定時間以上ユーザからのアクセスがない場合に、第2通信方法を用いて注文確認メールを送るよう決定してもよい。
また、振分け部52はユーザのランクに基づいて即時処理要求を振分けてもよい。例えば、予めデータベースサーバ6がユーザのそれぞれのランクを特定するためのランク特定情報を記憶しておき、振分け部52が即時処理要求を送信したユーザに対するランク特定情報に基づいて第1通信方法か第2通信方法かを決定してもよい。より具体的には、負荷分散サーバ4に即時処理要求を送信したユーザIDを取得し、そのユーザIDのユーザに対するランク特定情報を取得するランク取得部を設け、振分け部52が、ランク特定情報により特定されるランクがある閾値より高い、または低いなど、所定の範囲内にある場合に第2の通信方法で対応することを決定してもよい。さらに、振分け部52は、負荷とユーザのランクの両方を用いて即時処理要求を振分けてもよい。この場合、予め、システムの負荷の値の範囲が複数のレベルに分割され、さらにそのレベルとユーザのランクとが関連づけられている。ユーザのランクが高くなるにつれ、対応づけられるレベルが大きくなり、振分け部52は、システムの負荷の値がユーザのランクに応じたレベルを代表する値以上またはその値を超え、かつ予め定められた種類の即時処理要求である場合に、第2通信方法を用いると決定する。このレベルを代表する値は、そのレベルの上限あるいは下限を示す閾値であってよい。この場合、システムの負荷の値の範囲を複数のレベルに分割する境界である複数の閾値が予め決まっており、ランクが大きくなるほど対応づけられた閾値が大きくなるようにランクと閾値とが対応づけられている。
また、第1通信方法を用いるか、第2通信方法を用いるかの決定は、全ての処理要求に対して行わなくてもよい。いったん第2通信方法を用いたら、その後のユーザ端末2(ユーザが操作する他の端末でもよい)と電子商取引システム1との間の通信を第2通信方法で行うように処理を行ってもよい。
また、ここでは順次処理要求などの応答を必要としない通信はメールで行っているが、代わりに他の通信方法を用いてもよい。例えば、電子商取引システム1からユーザ端末2への通信にはショートメッセージサービス(SMS),メッセンジャーやスマートフォンへのプッシュ通知などを用いてもよいし、ユーザ端末2から電子商取引システム1への通信にはショートメッセージサービス(SMS)やメッセンジャーを用いてもよい。
1 電子商取引システム、2 ユーザ端末、3 ネットワーク、4 負荷分散サーバ、5 通常ウェブサーバ、6 データベースサーバ、7 高負荷対応ウェブサーバ、8 メール送信サーバ、9 メール受信サーバ、10 順次処理サーバ、21 プロセッサ、22 記憶部、23 通信部、24 入出力部、51 負荷取得部、52 振分け部、53 即時処理要求受信部、54 即時処理部、55 カート処理部、56 注文確認部、57 注文即時処理部、58 仮応答部、59 送信依頼部、60 メールアドレス管理部、61 メール受信格納部、62 順次処理部、63 引当解除部。

Claims (21)

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

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2014077350A JP5653545B2 (ja) 2014-04-03 2014-04-03 要求処理システム、要求処理方法、プログラムおよび情報記憶媒体

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2014077350A JP5653545B2 (ja) 2014-04-03 2014-04-03 要求処理システム、要求処理方法、プログラムおよび情報記憶媒体

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
JP2013558825A Division JP5519880B1 (ja) 2013-03-28 2013-03-28 要求処理システム、要求処理方法、プログラムおよび情報記憶媒体

Publications (2)

Publication Number Publication Date
JP2014194779A JP2014194779A (ja) 2014-10-09
JP5653545B2 true JP5653545B2 (ja) 2015-01-14

Family

ID=51839929

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2014077350A Active JP5653545B2 (ja) 2014-04-03 2014-04-03 要求処理システム、要求処理方法、プログラムおよび情報記憶媒体

Country Status (1)

Country Link
JP (1) JP5653545B2 (ja)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5801981B1 (ja) * 2014-11-27 2015-10-28 楽天株式会社 電子取引端末、電子取引方法、記録媒体、ならびに、プログラム
JP7229684B2 (ja) * 2018-07-09 2023-02-28 ユニ・チャーム株式会社 情報提供システム、情報提供装置、情報提供方法及び情報提供プログラム

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002342296A (ja) * 2001-05-17 2002-11-29 Nec Corp ネットワークシステム
JP2003141375A (ja) * 2001-11-01 2003-05-16 Casio Comput Co Ltd 販売支援装置、オンラインショピングシステム、およびプログラム
JP2008015593A (ja) * 2006-07-03 2008-01-24 Hitachi Ltd 中継装置、プログラム、中継方法及び通信システム
JP2008250459A (ja) * 2007-03-29 2008-10-16 Adc Technology Kk 受信メール通信方法
JP5458400B2 (ja) * 2008-04-15 2014-04-02 株式会社メイクソフトウェア 写真シール作成装置、および画像提供サーバ
JP2010099144A (ja) * 2008-10-21 2010-05-06 Nomura Research Institute Ltd ゲーム結果情報管理システム
JP2011232893A (ja) * 2010-04-26 2011-11-17 Canon Inc 印刷データ作成サーバ及び印刷装置及び印刷システム
JP5732867B2 (ja) * 2011-01-21 2015-06-10 セイコーエプソン株式会社 印刷制御サーバー,印刷制御方法および印刷制御プログラム

Also Published As

Publication number Publication date
JP2014194779A (ja) 2014-10-09

Similar Documents

Publication Publication Date Title
US8478810B2 (en) Message hub apparatus, program product, and method
US8412599B2 (en) Approval workflow engine for services procurement timesheets, progress logs, and expenses
EP1182542A1 (en) On-line selection of print service provider in distributed print on demand service
US11201840B2 (en) Communication control method and information processing apparatus
JP2006309737A (ja) 開示情報提示装置、個人特定度算出装置、id度取得装置、アクセス制御システム、開示情報提示方法、個人特定度算出方法、id度取得方法、及びプログラム
US20160328783A1 (en) Information processing apparatus, information processing method, and program
JP5653545B2 (ja) 要求処理システム、要求処理方法、プログラムおよび情報記憶媒体
CN107888700A (zh) 一种共享云渲染系统及其处理流程
JP2022091966A (ja) フルフィルメントセンターの優先度値に基づくアウトバウンド予測のためのシステムおよび方法
CN102769668A (zh) 基于近似匹配的发布/订阅负载均衡方法
JP5519880B1 (ja) 要求処理システム、要求処理方法、プログラムおよび情報記憶媒体
US9524330B1 (en) Optimization of production systems
JP2017146685A (ja) 分散システム、および、メッセージ転送方法
JP7024517B2 (ja) 電子メール発信承認装置、電子メール発信承認方法および電子メール発信承認プログラム
KR20210139106A (ko) 알림을 제공하는 택배 서비스 시스템 및 그 방법
US8719181B2 (en) Managing shipments in an order by proxy service
US20050187828A1 (en) Referral system for handling information on order entry and sales
CN113761077B (zh) 一种处理单据任务的方法和装置
JP7186043B2 (ja) 管理装置、システム及びプログラム
JP5767066B2 (ja) 他の装置に処理を依頼可能なシステムのサーバ装置及びプログラム
JP2006085445A (ja) 電子データ資金の移動システム及び移動方法
JP6397627B2 (ja) 業務タスク管理装置、業務タスク管理方法および業務タスク管理プログラム
US20180096429A1 (en) Securities trading management system
JP6372089B2 (ja) 情報処理装置、及び、情報送信方法
CN113872876A (zh) 请求限制方法、装置、电子设备和计算机可读存储介质

Legal Events

Date Code Title Description
A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20140701

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20140829

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: 20141111

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20141118

R150 Certificate of patent or registration of utility model

Ref document number: 5653545

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

S531 Written request for registration of change of domicile

Free format text: JAPANESE INTERMEDIATE CODE: R313531

R350 Written notification of registration of transfer

Free format text: JAPANESE INTERMEDIATE CODE: R350

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

S533 Written request for registration of change of name

Free format text: JAPANESE INTERMEDIATE CODE: R313533

R350 Written notification of registration of transfer

Free format text: JAPANESE INTERMEDIATE CODE: R350

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250