JP2021089734A - 商品を予約購入する方法およびシステム - Google Patents

Abstract

【課題】 本開示は、商品予約購入方法に関するものである。【解決手段】 商品予約購入方法は、ユーザー端末からユーザー情報、購入対象商品に対する情報および希望購入条件を含む予約購入要請を受信するステップと、購入対象商品に対する複数の決済情報を受信するステップと、受信された複数の決済情報のうち少なくとも１つが前記希望購入条件を満たすか否かをモニタリングするステップと、モニタリング結果に基づいて、ユーザー端末から受信された決済手段情報を利用した購入対象商品の購入取引を処理するステップを含む。【選択図】図３

Description

本開示は、商品予約購入方法およびシステムに関するものであって、具体的には、ユーザー端末から受信した予約購入要請を利用して購入対象商品の購入取引を自動的に処理し、商品予約購入サービスを提供できる商品予約購入方法およびシステムに関するものである。

モバイル機器の普及およびインターネットの発達により電子商取引の規模が大きくなるにつれて、電子商取引を利用して商品を販売、購入する販売者と購入者が急激に増加している。インターネット上には同じ商品を販売する多数の販売者が存在し、販売者は販売数量の確保のために同じ商品に対して異なる価格を策定したり、価格を頻繁に調整したりしている。したがって、消費者は、自分が希望する商品を希望価格で購入するために、インターネット上の多数の販売サイトを検索してモニタリングするなど、時間を投資し続ける必要がある。

また、消費者のインターネット活用能力によって同じ商品に対して購入する価格が異なる場合があるため、インターネット活用能力の低い消費者は、希望する商品を希望価格で購入するのが難しい問題点がある。これを解決するために、各種の商品に対する最低価格の商店を検索するサービスも提供されているが、販売者が登録する偽の商品など、購入者が即時購入できる最低価格の商店を検索するのが容易ではない場合がある。

一方、電子商取引の取引特性からして、消費者を直接対面しない販売者は、消費者の需要を予測するのが難しい。これにより、販売者は、消費者の需要の変化に迅速に対応することができない。また、これにより、販売者が商品の在庫を効率的に管理するのが難しいという問題がある。

韓国公開特許第１０−２０１３−０００５６９３号公報

本開示は、前記のような問題点を解決するための商品予約購入方法、記録媒体に格納されたコンピュータプログラムおよびシステムを提供する。

購入対象商品に対する予約購入要請と複数の決済情報を受信し、受信された複数の決済情報のうち少なくとも１つが予約購入要請に含まれた希望購入条件を満たすか否かをモニタリングして、購入対象商品の購入取引を処理する商品予約購入方法およびシステムが提供される。

複数の予約購入要請に基づいて統計情報を生成し、生成された統計情報を販売者アカウントに提供することができる消費者需要予測方法およびシステムが提供される。

本開示は、方法、システム、装置またはコマンドを格納するコンピュータ読み取り可能な記憶媒体を含む、多様な方式で具現されることができる。

本開示の一実施例による商品予約購入方法は、ユーザー端末からユーザー情報、購入対象商品に対する情報および希望購入条件が含む予約購入要請を受信するステップと、購入対象商品に対する複数の決済情報を受信するステップと、受信された複数の決済情報のうち少なくとも１つが希望購入条件を満たすか否かをモニタリングするステップと、モニタリング結果に基づいて、ユーザー端末から受信された決済手段情報を利用した購入対象商品の購入取引を処理するステップとを含む。

本開示の一実施例において前述された商品予約購入方法をコンピュータで実行するためにコンピュータ読み取り可能な記録媒体に格納されたコンピュータプログラムが提供される。

本開示の一実施例による商品予約購入システムは、メモリと、メモリと連結され、メモリに含まれたコンピュータ読み取り可能なコマンドを実行するように構成された少なくとも１つのプロセッサとを含み、少なくとも１つのプロセッサは、ユーザー情報、購入対象商品に対する情報および希望購入条件を含む予約購入要請を受信してメモリに格納するように構成された予約情報管理部と、購入対象商品に対する複数の決済情報を受信してメモリに格納するように構成された決済情報管理部と、複数の決済情報のうち少なくとも１つが希望購入条件を満たすか否かをモニタリングするように構成された条件判定部と、モニタリング結果に基づいて、受信された決済手段情報を利用した購入対象商品の購入取引を処理するように構成された決済処理部とを含む。

本開示の一実施例による消費者需要予測方法は、ユーザー情報、購入対象商品に対する情報および希望購入条件をそれぞれ含む複数の予約購入要請を受信するステップと、複数の予約購入要請に基づいて統計情報を生成するステップと、生成された統計情報を販売者アカウントに提供するステップとを含む。

本開示の一実施例において前述された消費者需要予測方法をコンピュータで実行するためにコンピュータ読み取り可能な記録媒体に格納されたコンピュータプログラムが提供される。

本開示の一実施例による消費者需要予測システムは、メモリと、メモリと連結され、メモリに含まれたコンピュータ読み取り可能なコマンドを実行するように構成された少なくとも１つのプロセッサとを含み、少なくとも１つのプロセッサは、ユーザー情報、購入対象商品に対する情報および希望購入条件をそれぞれ含む複数の予約購入要請を受信してメモリに格納し、複数の予約購入要請に基づいて統計情報を生成するように構成された予約情報管理部と、生成された統計情報を販売者アカウントに関連した外部デバイスに提供するように構成された通信モジュールとを含む。

本開示の一部実施例によると、他のユーザーの決済情報を積極的に活用して予約購入要請を処理することにより、ユーザーは、自分の欲しい商品を希望する価格で購入するために時間を投資し続ける必要がなく、容易に購入することが可能である。つまり、他のユーザーの決済情報を利用して、偽の売物ではない実際に取引可能な最低価格の商品を検索することが可能である。

本開示の一部実施例によると、販売者は、購入者の需要を予測することが難しく、在庫管理にも努力が必要であるが、ユーザーが登録した予約購入要請に対する統計情報を販売者に提供することにより、販売者は、商品に対する需要と需要価格を容易に把握して戦略的に利用することも可能である。

本開示の効果は、以上で言及した効果に制限されず、言及されていない他の効果は、請求の範囲の記載から当業者に明確に理解されることができる。

本開示の実施例は、以下で説明する添付図面を参照して説明され、ここで類似する参照番号は類似する要素を示すが、これに限定されない。
本開示の一実施例に係る商品予約購入サービスを提供するために、情報処理システムが複数のユーザー端末と通信可能に連結された構成を示す概要図である。 本開示の一実施例に係るユーザー端末および情報処理システムの内部構成を示すブロック図である。 本開示の一実施例に係る情報処理システムの構成を示すブロック図である。 本開示の一実施例に係るユーザー端末および情報処理システムの内部構成を示すブロック図である。 本開示の一実施例に基づいて予約購入要請を標準化された表記に変換した後、格納する例示を示す図面である。 本開示の一実施例に係る例示的な予約購入要請ＤＢを示す図面である。 本開示の一実施例に基づいて決済要請を標準化された表記に変換した後、格納する例示を示す図面である。 本開示の一実施例に係る例示的な決済情報ＤＢを示す図面である。 本開示の一実施例に基づいて特定の商品を購入または予約購入するための画面の例示を示す図面である。 本開示の一実施例に係る予約購入要請を生成する例示を示す図面である。 本開示の一実施例に基づいてユーザーが生成した予約購入要請を照会する例示を示す図面である。 本開示の一実施例に係る購入対象商品が自動的に購入された後、購入取引に関連した情報をユーザーに提供する例示を示す図面である。 本開示の一実施例に係る商品予約購入方法を示すフローチャートである。 本開示の一実施例に基づいて予約購入要請に対する統計情報をユーザー端末の画面に表示する例示を示す図面である。 本開示の一実施例に係る消費者需要予測方法を示すフローチャートである。

<発明の概要>
一実施例によると、予約購入要請は、決済手段情報をさらに含み、購入対象商品の購入取引を処理するステップは、受信された複数の決済情報のうち希望購入条件を満たす決済情報に含まれた商店情報および予約購入要請に含まれたユーザー情報と決済手段情報を利用して、購入対象商品の購入取引をユーザー入力なしで自動的に遂行するステップと、購入取引に関連した情報をユーザー端末に送信するステップとを含む。

一実施例によると、購入対象商品の購入取引を処理するステップは、受信された複数の決済情報のうち希望購入条件を満たす決済情報に含まれた商品情報または決済金額に対する情報のうち少なくとも１つをユーザー端末に送信するステップと、ユーザー端末から購入対象商品に対する購入承認を受信するステップと、商店情報、ユーザー情報および決済手段情報を利用して購入対象商品の購入取引を実行するステップとを含む。

一実施例によると、予約購入要請を受信するステップは、受信された購入対象商品に対する情報または希望購入条件のうち少なくとも１つを標準化された表記に変換して格納するステップを含む。

一実施例によると、複数の決済情報のそれぞれは、商品情報、商店情報または決済金額に対する情報のうち少なくとも１つを含み、購入対象商品に対する複数の決済情報を受信するステップは、受信された各決済情報に含まれた商品情報、商店情報または決済金額に対する情報のうち少なくとも１つを標準化された表記に変換して格納するステップを含む。

一実施例によると、購入対象商品の購入取引を処理するステップは、複数の決済情報に基づいて購入対象商品が希望購入条件を満たす商店で予め決められた数量以上購入されたと判断された場合、該当の商店に対する情報、ユーザー情報および決済手段情報を利用して購入対象商品の購入取引を処理するステップを含む。

一実施例によると、購入対象商品の購入取引を処理するステップは、購入対象商品に対して特定の商店で予め決められた期間以上、希望購入条件を満たす購入が行われたと判断された場合、特定の商店に対する情報、ユーザー情報および決済手段情報を利用して購入対象商品の購入取引を処理するステップを含む。

一実施例によると、購入対象商品の購入取引を処理するステップは、予約購入要請と競合する他の予約購入要請が存在する場合、要請を受信した時間に基づいて優先順位を付与するステップと、優先順位に基づいて各要請に対する購入取引を処理するステップとを含む。

一実施例によると、購入対象商品の購入取引を処理するステップは、予約購入要請と競合する他の予約購入要請が存在する場合、要請を生成したユーザーランクに基づいて優先順位を付与するステップと、優先順位に基づいて各要請に対する購入取引を処理するステップとを含む。

一実施例によると、購入対象商品に対する情報は、商品名、商品モデル名、商品イメージまたは詳細オプションのうち少なくとも１つを含む。

一実施例によると、受信された複数の決済情報のうち少なくとも１つが希望購入条件を満たすか否かをモニタリングするステップは、複数の決済情報のうち希望購入条件より有利であると判断される決済情報を、希望購入条件を満たす決済情報として判定するステップを含む。

一実施例によると、モニタリング結果に基づいて、ユーザー端末から受信された決済手段情報を利用した購入対象商品の購入取引を処理するステップは、受信された複数の決済情報のうち希望購入条件を満たす決済情報に含まれた商店情報および決済手段情報を利用して、購入対象商品を希望購入条件で購入できるか否かを判断するステップと、購入対象商品を希望購入条件で購入するために他の種類の決済手段が要求されると判定することに応答して、前記ユーザー端末に決済手段の再入力を要求するメッセージを送信するステップとを含む。

一実施例によると、複数の予約購入要請を受信するステップは、受信された購入対象商品に対する情報または希望購入条件のうち少なくとも１つを標準化された表記に変換して格納するステップを含む。

一実施例によると、複数の予約購入要請に基づいて統計情報を生成するステップは、各購入対象商品別に希望購入条件に対する統計を生成するステップを含み、生成された統計情報を販売者アカウントに提供するステップは、販売者アカウントが販売する商品を確認するステップと、販売者アカウントが販売する商品に対する希望購入条件の統計を販売者アカウントに提供するステップとを含む。

一実施例によると、消費者需要予測方法は、販売者アカウントから販売する商品に対する修正された販売価格を受信するステップと、修正された販売価格に基づいて希望購入条件が満たされる少なくとも１つの予約購入要請を判定するステップと、希望購入条件が満たされる少なくとも１つの予約購入要請に対する購入取引を処理するステップとをさらに含む。

<発明の詳細な説明>
以下では、本開示の実施のための具体的な内容を添付された図面を参照して詳細に説明する。ただし、以下の説明において、本開示の要旨を不必要に曖昧にする恐れがある場合には、広く知られた機能や構成に関する具体的な説明は省略することにする。

添付された図面において、同一または対応する構成要素には同一の参照符号が付与されている。また、以下の実施例の説明において、同一または対応する構成要素を重複して記述することが省略されることができる。しかし、構成要素に関する記述が省略されても、そのような構成要素がある実施例に含まれないものと意図されるのではない。

開示された実施例の利点および特徴、そしてそれらを達成する方法は、添付される図面と共に後述されている実施例を参照すると明確になるだろう。しかし、本開示は、以下で開示される実施例に限定されるものではなく、互いに異なる多様な形態で具現されることができ、単に本実施例は本開示が完全であるようにし、本開示が属する技術分野における通常の知識を有する者に発明の範疇を完全に知らせるために提供されるだけのものである。

本明細書において使用される用語について簡略に説明し、開示された実施例について具体的に説明する。本明細書において使用される用語は、本開示における機能を考慮しながら可能な限り現在広く使用される一般的な用語を選択したが、これは関連分野に携わる技術者の意図または判例、新しい技術の出現などによって変わることができる。また、特定の場合は出願人が任意に選定した用語もあり、この場合、該当する発明の説明部分で詳細にその意味を記載する。したがって、本開示において使用される用語は、単純な用語の名称ではなく、その用語が有する意味と本開示の全般にわたる内容に基づいて定義されるべきである。

本明細書での単数の表現は、文脈上明らかに単数のものであると特定しない限り、複数の表現を含む。また、複数の表現は、文脈上明らかに複数のものであると特定しない限り、単数の表現を含む。明細書全体においてある部分がある構成要素を「含む」とするとき、これは特に反対の記載がない限り、他の構成要素を除外するのではなく、他の構成要素をさらに含むことが可能であることを意味する。

また、明細書において使用される「モジュール」または「部」という用語は、ソフトウェアまたはハードウェア構成要素を意味し、「モジュール」または「部」は、ある役割を遂行する。しかしながら、「モジュール」または「部」は、ソフトウェアまたはハードウェアに限定される意味ではない。「モジュール」または「部」は、アドレッシングできる格納媒体にあるように構成されることもでき、１つまたはそれ以上のプロセッサを再生させるように構成されることもできる。したがって、一例として、「モジュール」または「部」は、ソフトウェア構成要素、オブジェクト指向ソフトウェア構成要素、クラス構成要素およびタスク構成要素のような構成要素と、プロセス、関数、属性、プロシージャ、サブルーチン、プログラムコードのセグメント、ドライバ、ファームウェア、マイクロコード、回路、データ、データベース、データ構造、テーブル、アレイまたは変数のうち少なくとも１つを含むことができる。構成要素と「モジュール」または「部」は、もっと小さい数の構成要素および「モジュール」または「部」で結合されたり、追加の構成要素と「モジュール」または「部」にさらに分離されたりすることができる。

本開示の一実施例によると、「モジュール」または「部」は、プロセッサおよびメモリで具現されることができる。「プロセッサ」は、汎用プロセッサ、中央処理装置（ＣＰＵ）、マイクロプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、コントローラ、マイクロコントローラ、状態マシンなどを含むように広く解釈されるべきである。いくつかの環境において、「プロセッサ」は、注文型半導体（ＡＳＩＣ）、プログラム可能な論理デバイス（ＰＬＤ）、フィールドプログラム可能ゲートアレイ（ＦＰＧＡ）などを指すこともできる。「プロセッサ」は、例えば、ＤＳＰとマイクロプロセッサの組み合わせ、複数のマイクロプロセッサの組み合わせ、ＤＳＰコアと結合した１つ以上のマイクロプロセッサの組み合わせ、または任意の他のそのような構成の組み合わせのような処理デバイスの組み合わせを指すこともできる。また、「メモリ」は、電子情報を格納可能な任意の電子コンポーネントを含むように広く解釈されるべきである。「メモリ」は、ランダムアクセスメモリ（ＲＡＭ）、読み出し-専用メモリ（ＲＯＭ）、不揮発性ランダムアクセスメモリ（ＮＶＲＡＭ）、プログラム可能な読み出し専用メモリ（ＰＲＯＭ）、消去プログラム可能な読み出し専用メモリ（ＥＰＲＯＭ）、電気的に消去可能ＰＲＯＭ（ＥＥＰＲＯＭ）、フラッシュメモリ、磁気または光学データ格納装置、レジスタなどのプロセッサ読み出し可能媒体などの多様なタイプを指すこともできる。プロセッサがメモリから情報を読み出し/またはメモリに情報を記録することができれば、メモリは、プロセッサと電子通信状態にあると呼ばれる。プロセッサに集積されたメモリは、プロセッサと電子通信状態にある。

図１は、本開示の一実施例に係る商品予約購入サービスを提供するために、情報処理システム（１３０）が複数のユーザー端末（１１２、１１４、１１６）と通信可能に連結された構成を示す概要図である。情報処理システム（１３０）は、ネットワーク（１２０）を介して複数のユーザー端末（１１２、１１４、１１６）に予約購入サービスを提供することができるだけでなく、決済サービスを提供するシステム（例えば、ラインペイなど）を含むことができる。一実施例によると、情報処理システム（１３０）は、商品予約購入サービスに関連したコンピュータ実行可能なプログラム（例えば、ダウンロード可能なアプリケーション）およびデータを格納、提供および実行できる１つ以上のサーバー装置および/またはデータベース、またはクラウドコンピューティングサービス基盤の１つ以上の分散コンピューティングデバイスおよび/または分散データベースを含むことができる。情報処理システム（１３０）によって提供される商品予約購入サービスは、複数のユーザー端末（１１２、１１４、１１６）にインストールされた専用アプリケーションまたはウェブブラウザアプリケーションなどを介してユーザーに提供されることができる。

複数のユーザー端末（１１２、１１４、１１６）は、ネットワーク（１２０）を介して情報処理システム（１３０）と通信することができる。ネットワーク（１２０）は、複数のユーザー端末（１１２、１１４、１１６）と情報処理システム（１３０）間の通信が可能なように構成されることができる。ネットワーク（１２０）は、設置環境に応じて、例えば、イーサネット（Ｅｔｈｅｒｎｅｔ）、有線ホームネットワーク（Ｐｏｗｅｒ Ｌｉｎｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎ）、電話回線通信装置およびＲＳ-ｓｅｒｉａｌ通信などの有線ネットワーク、移動通信網、ＷＬＡＮ（Ｗｉｒｅｌｅｓｓ ＬＡＮ）、Ｗｉ-Ｆｉ、ＢｌｕｅｔｏｏｔｈおよびＺｉｇＢｅｅなどのような無線ネットワークまたはその組み合わせで構成されることができる。

図１において、携帯電話端末（１１２）、タブレット端末（１１４）およびＰＣ端末（１１６）がユーザー端末の例として図示されたが、これに限定されず、ユーザー端末は、有線および/または無線通信が可能で、ユーザーからの予約購入要請に対する情報を受信できるユーザーインターフェースを備えた任意のコンピューティングデバイスであることができる。例えば、ユーザー端末は、スマートフォン、携帯電話、ナビゲーション、コンピュータ、ラップトップ、デジタル放送用端末、ＰＤＡ（Ｐｅｒｓｏｎａｌ Ｄｉｇｉｔａｌ Ａｓｓｉｓｔａｎｔｓ）、ＰＭＰ（Ｐｏｒｔａｂｌｅ Ｍｕｌｔｉｍｅｄｉａ Ｐｌａｙｅｒ）、タブレットＰＣ、ゲームコンソール、ウェアラブルデバイス、ＩｏＴ（ｉｎｔｅｒｎｅｔ ｏｆ ｔｈｉｎｇｓ）デバイス、ＶＲ（ｖｉｒｔｕａｌ ｒｅａｌｉｔｙ）デバイス、ＡＲ（ａｕｇｍｅｎｔｅｄ ｒｅａｌｉｔｙ）デバイスなどを含むことができる。また、図１において、３つのユーザー端末（１１２、１１４、１１６）がネットワーク（１２０）を介して情報処理システム（１３０）と通信するものとして図示されているが、これに限定されず、異なる数のユーザー端末がネットワーク（１２０）を介して情報処理システム（１３０）と通信するように構成されることもできる。

通信方式は制限されず、ネットワーク（１２０）が含むことができる通信網（例えば、移動通信網、有線インターネット、無線インターネット、放送網、衛星網など）を活用する通信方式だけでなく、ユーザー端末間の近距離無線通信もまた含まれることができる。例えば、ネットワーク（１２０）は、ＰＡＮ（ｐｅｒｓｏｎａｌ ａｒｅａ ｎｅｔｗｏｒｋ）、ＬＡＮ、（ｌｏｃａｌ ａｒｅａ ｎｅｔｗｏｒｋ）、ＣＡＮ（ｃａｍｐｕｓ ａｒｅａ ｎｅｔｗｏｒｋ）、ＭＡＮ（ｍｅｔｒｏｐｏｌｉｔａｎ ａｒｅａ ｎｅｔｗｏｒｋ）、ＷＡＮ（ｗｉｄｅ ａｒｅａ ｎｅｔｗｏｒｋ）、ＢＢＮ（ｂｒｏａｄｂａｎｄ ｎｅｔｗｏｒｋ）、インターネットなどのネットワークのうち１つ以上の任意のネットワークを含むことができる。また、ネットワーク（１２０）は、バスネットワーク、スターネットワーク、リングネットワーク、メッシュネットワーク、スター−バスネットワーク、ツリーまたは階層的（ｈｉｅｒａｒｃｈｉｃａｌ）ネットワークなどを含むネットワークトポロジのうち任意の１つ以上を含むことができるが、これに制限されない。

情報処理システム（１３０）は、ネットワーク（１２０）を介して複数のユーザー端末（１１２、１１４、１１６）から予約購入要請を受信することができる。受信される予約購入要請は、予約購入情報として情報処理システム（１３０）のメモリに格納されることができる。予約購入要請は、予約購入要請を生成したユーザー情報、ユーザーが購入しようとする購入対象商品に対する情報（例えば、商品名、商品モデル名、商品イメージ、詳細オプションなど）、購入しようとする数量、購入者の該当の商品に対する希望購入条件（例えば、希望価格、希望割引率、希望ペイバック、希望リワードポイント、歴代最低価格など）、決済手段情報（例えば、クレジットカード情報、チェックカード情報、電話代請求書情報、金融口座、簡単決済など）などを含むことができ、ユーザーが特定の商品を特定の条件が満たされる未来に自動的に購入することを希望する場合に生成することができる。例えば、ユーザーＡが現在５０万ウォンで販売されるＡ商品をもっと安い４５万ウォンで購入しようとする場合、該当のユーザーは、Ａ商品を４５万ウォン以下で販売する任意の商店が確認される未来の時点で自動的に購入取引が処理されるように予約購入要請を生成することができる。購入対象商品は、品物に限定されず、オンライン上で購入できる任意のサービス、クーポン、チケットなどをすべて含む。

情報処理システム（１３０）は、ネットワーク（１２０）を介して複数のユーザー端末（１１２、１１４、１１６）から決済要請を受信することができる。決済要請は、該当の要請を生成したユーザー情報、決済商品に対する情報、数量、決済商店（例えば、オンライン販売サイト）に対する情報、決済価格、決済手段情報などを含むことができ、ユーザーが特定の商店で特定の商品を、現在販売価格で直ちに購入することを希望する場合に生成することができる。例えば、ユーザーＡが、現在Ａ商店において５０万ウォンで販売されるＡ製品を５０万ウォンで購入しようとする場合、ユーザーは、直ちに購入取引が処理されるように決済要請を生成することができる。この場合、情報処理システム（１３０）は、受信された決済要請に基づいて決済を処理し、処理結果を決済情報としてメモリに格納することができる。

一実施例において、情報処理システム（１３０）は、格納された決済情報のうち既に受信された予約購入要請の購入対象商品および希望購入条件を満たす決済情報があるか否かをモニタリングするように構成されることができる。この場合、情報処理システム（１３０）は、モニタリング結果に基づいて、受信された決済手段情報を利用して希望購入条件が満たされた購入対象商品の購入取引を処理することができる。例えば、ユーザーＡが生成した予約購入要請（Ａ商品を４５万ウォン以下で購入しようとする）を満たす決済情報がある場合（ユーザーＢがＡの商品をＢ商店で４４万円で購入）、情報処理システム（１３０）は、該当の決済情報を利用してユーザーＡがＢ商店でＡ商品を４４万円で購入する取引を、ユーザー入力なしで自動的に実行したり、ユーザー確認後に遂行したりすることができる。該当の購入取引に使用される決済情報は、ユーザーが予約購入要請の生成時に入力したり、ユーザーが取引を進行するか否かを確認するときに入力したりすることができる。

上述したように、他のユーザーの決済情報を積極的に活用して予約購入要請を処理することにより、ユーザーは、自分の欲しい商品を希望の価格で購入するために時間を投資し続ける必要がなく、容易に購入を進めることが可能である。つまり、他のユーザーの決済情報を利用して、偽の売物ではなく、実際に取引可能な最低価格の商品を検索することが可能である。また、販売者は、購入者の需要を予測するのが難しく、在庫管理にも努力が必要であるが、ユーザーが登録する予約購入要請に対する統計情報を販売者に提供することにより、販売者は、商品に対する需要と需要価格を容易に把握して戦略的に利用することも可能である。

図２は、本開示の一実施例に係るユーザー端末（１１２）および情報処理システム（１３０）の内部構成を示すブロック図である。ユーザー端末（１１２）は、メモリ（２１６）、プロセッサ（２１８）、通信モジュール（２２０）および入出力インターフェース（２１４）を含むことができる。これと同様に、情報処理システム（１３０）は、メモリ（２３４）、プロセッサ（２３６）、通信モジュール（２３８）および入出力インターフェース（２３２）を含むことができる。図２に図示されたように、ユーザー端末（１１２）および情報処理システム（１３０）は、それぞれの通信モジュール（２２０、２３８）を利用し、ネットワーク（１２０）を介して情報および/またはデータを通信するように構成されることができる。また、入出力デバイス（２１２）は、入出力インターフェース（２１４）を介してユーザー端末（１１２）の情報および/またはデータを入力したり、ユーザー端末（１１２）から生成された情報および/またはデータを出力したりするように構成されることができる。図２では、メモリ（２３４）、プロセッサ（２３６）、通信モジュール（２３８）および入出力インターフェース（２３２）がユーザー端末（１１２）の内部構成として図示されているが、他のユーザー端末（例えば、図１のユーザー端末（１１４、１１６））もユーザー端末（１１２）の内部構成と同一または類似の内部構成を含むことができる。

メモリ（２１６、２３４）は、非一時的な任意のコンピュータ読み取り可能な記録媒体を含むことができる。一実施例によると、メモリ（２１６、２３４）は、ＲＡＭ（ｒａｎｄｏｍ ａｃｃｅｓｓ ｍｅｍｏｒｙ）、ＲＯＭ（ｒｅａｄ ｏｎｌｙ ｍｅｍｏｒｙ）、ディスクドライブ、ＳＳＤ（ｓｏｌｉｄ ｓｔａｔｅ ｄｒｉｖｅ）、フラッシュメモリなどのような不揮発性の永久的大容量記憶装置を含むことができる。他の例として、ＲＯＭ、ＳＳＤ、フラッシュメモリ、ディスクドライブなどのような不揮発性の大容量記憶装置は、メモリ（２１６、２３４）とは区分される別途の永久記憶装置としてユーザー端末（１１２）または情報処理システム（１３０）に含まれることができる。また、メモリ（２１６、２３４）には、オペレーティングシステムと少なくとも１つのプログラムコード（例えば、ユーザー端末（１１２）にインストールされて駆動されるブラウザや予約購入サービスの提供のためにユーザー端末（１１２）にインストールされる予約購入サービス専用アプリケーションなどのためのコード）が格納されることができる。

このようなソフトウェアコンポーネントは、メモリ（２１６、２３４）とは別途のコンピュータ読み取り可能な記録媒体からロードされることができる。このような別途のコンピュータ読み取り可能な記録媒体は、このようなユーザー端末（１１２）および情報処理システム（１３０）に直接連結可能な記録媒体を含むことが可能であり、例えば、フロッピードライブ、ディスク、テープ、ＤＶＤ/ＣＤ ＲＯＭドライブ、メモリーカードなどのコンピュータ読み取り可能な記録媒体を含むことができる。他の例として、ソフトウェアコンポーネントは、コンピュータ読み取り可能な記録媒体ではなく、通信モジュール（２２０、２３８）を通じてメモリ（２１６、２３４）にロードされることもできる。例えば、少なくとも１つのプログラムは、開発者またはアプリケーションのインストールファイルを配布するファイル配布システムがネットワーク（１２０）を介して提供するファイルによってインストールされるコンピュータプログラム（例えば、上述された予約購入サービス専用アプリケーション）に基づいて、メモリ（２１６、２３４）にロードされることができる。

プロセッサ（２１８、２３６）は、基本的な算術、論理および入出力演算を遂行することにより、コンピュータプログラムのコマンドを処理するように構成されることができる。コマンドは、メモリ（２１６、２３４）または通信モジュール（２２０、２３８）によってプロセッサ（２１８、２３６）に提供されることができる。例えば、プロセッサ（２１８、２３６）は、メモリ（２１６、２３４）のような記録装置に格納されたプログラムコードによって受信されるコマンドを実行するように構成されることができる。

通信モジュール（２２０、２３８）は、ネットワーク（１２０）を介してユーザー端末（１１２）と情報処理システム（１３０）が相互通信するための構成または機能を提供することができ、ユーザー端末（１１２）および/または情報処理システム（１３０）が他のユーザー端末または他のシステム（例えば、別途のクラウドシステム、オープンマーケット、ショッピングモールシステムなど）と通信するための構成または機能を提供することができる。一例として、ユーザー端末（１１２）のプロセッサ（２１８）がメモリ（２１６）のような記録装置に格納されたプログラムコードに基づいて生成した要請（例えば、予約購入要請）は、通信モジュール（２２０）の制御に基づいてネットワーク（１２０）を介して情報処理システム（１３０）に伝達されることができる。逆に、情報処理システム（１３０）のプロセッサ（２３６）の制御に基づいて提供される制御信号やコマンドなどが、通信モジュール（２３８）とネットワーク（１２０）を経て、ユーザー端末（１１２）の通信モジュール（２２０）を通じてユーザー端末（１１２）に受信されることができる。例えば、ユーザー端末（１１２）は、通信モジュール（２２０）を通じて情報処理システム（１３０）から予約購入要請に関連した情報を受信することができる。

入出力インターフェース（２１４）は、入出力デバイス（２１２）とのインターフェースのための手段であることができる。一例として、入力デバイスは、カメラ、キーボード、マイクロフォン、マウスなどのデバイスを、そして出力デバイスは、ディスプレイ、スピーカー、触覚フィードバックデバイスなどのようなデバイスを含むことができる。他の例として、入出力インターフェース（２１４）は、タッチスクリーンなどのように入力と出力を遂行するための構成または機能が１つに統合されたデバイスとのインターフェースのための手段であることができる。例えば、ユーザー端末（１１２）のプロセッサ（２１８）がメモリ（２１６）にロードされたコンピュータプログラムのコマンドを処理するにおいて、情報処理システム（１３０）や他のユーザー端末が提供する情報および/またはデータを利用して構成されるサービス画面やコンテンツが入出力インターフェース（２１４）を介してディスプレイに表示されることができる。入出力デバイス（２１２）は、ユーザー端末（１１２）と１つのデバイスに構成されることができる。また、情報処理システム（１３０）の入出力インターフェース（２３２）は、情報処理システム（１３０）と連結されたり、情報処理システム（１３０）が含んだりできる入力または出力のためのデバイス（図示せず）とのインターフェースのための手段であることができる。図２では、入出力インターフェース（２１４、２３２）がプロセッサ（２１８、２３６）と別途に構成された要素として図示されたが、これに限定されず、入出力インターフェース（２１４、２３２）がプロセッサ（２１８、２３６）に含まれるように構成されることができる。

ユーザー端末（１１２）および情報処理システム（１３０）は、図２の構成要素より多くの構成要素を含むことができる。しかし、ほとんどの従来技術の構成要素を明確に図示する必要はない。一実施例によると、ユーザー端末（１１２）は、上述された入出力デバイスのうち少なくとも一部を含むように具現されることができる。また、ユーザー端末（１１２）は、トランシーバ、ＧＰＳ（Ｇｌｏｂａｌ Ｐｏｓｉｔｉｏｎｉｎｇ Ｓｙｓｔｅｍ）モジュール、カメラ、各種センサ、データベースなどのような他の構成要素をさらに含むことができる。例えば、ユーザー端末（１１２）がスマートフォンである場合、一般的にスマートフォンが含んでいる構成要素を含むことができ、例えば、加速度センサやジャイロセンサ、カメラモジュール、各種の物理的ボタン、タッチパネルを利用したボタン、入出力ポート、振動のためのバイブレーターなどの多様な構成要素がユーザー端末（１１２）にさらに含まれるように具現されることができる。

一実施例によると、ユーザー端末（１１２）のプロセッサ（２１８）は、予約購入サービスを提供するインスタントメッセージングアプリケーションまたはウェブブラウザアプリケーションを動作するように構成されることができる。このとき、該当のアプリケーションに関連したプログラムコードがユーザー端末（１１２）のメモリ（２１６）にロードされることができる。アプリケーションが動作される間に、ユーザー端末（１１２）のプロセッサ（２１８）は、入出力デバイス（２１２）から提供された情報および/またはデータを入出力インターフェース（２１４）を介して受信したり、通信モジュール（２２０）を通じて情報処理システム（１３０）から情報および/またはデータを受信したりすることができ、受信された情報および/またはデータを処理してメモリ（２１６）に格納することができる。また、このような情報および/またはデータは、通信モジュール（２２０）を通じて情報処理システム（１３０）に提供することができる。

一実施例によると、インスタントメッセージングアプリケーションが動作される間に、プロセッサ（２１８）は、入出力インターフェースと連結されたタッチスクリーン、キーボードなどの入力デバイスを介して入力、または選択されたテキスト、イメージなどを受信することができ、受信されたテキストおよび/またはイメージをメモリ（２１６）に格納したり、通信モジュール（２２０）およびネットワーク（１２０）を介して情報処理システム（１３０）に提供したりすることができる。例えば、プロセッサ（２１８）は、タッチスクリーン、キーボードなどの入力デバイスを介して予約購入要請または取引要請を生成するための情報を受信することができる。これにより、受信されたテキストおよび/またはイメージを通信モジュール（２２０）およびネットワーク（１２０）を介して情報処理システム（１３０）に提供することができる。

プロセッサ（２１８）は、ユーザー端末（１１２）のディスプレイ出力可能デバイス（例えば、タッチスクリーン、ディスプレイなど）、音声出力可能デバイス（例えば、スピーカー）などの出力デバイスを介して、処理された情報および/またはデータを出力するように構成されることができる。一実施例によると、予約購入サービスを提供するインスタントメッセージングアプリケーションまたはウェブブラウザアプリケーションが提供する情報および/またはデータは、ディスプレイ出力可能デバイスなどを介して表示されることができる。他の実施例によると、予約購入サービスを提供するインスタントメッセージングアプリケーションまたはウェブブラウザアプリケーションが提供する情報および/またはデータは、音声出力可能デバイスなどを介して出力されることができる。

一実施例によると、情報処理システム（１３０）のプロセッサ（２３６）は、ユーザー端末（１１２）を含む複数のユーザー端末および/または複数の外部システムから受信された情報および/またはデータを管理、処理および/または格納するように構成されることができる。例えば、プロセッサ（２３６）は、複数のユーザー端末から受信した予約購入要請を満たす取引情報をモニタリングするように構成されることができる。さらに他の例示として、プロセッサ（２３６）は、受信された予約購入要請に対する統計情報を特定の販売者に対して適合なものとして加工するように構成されることができる。以下では、情報処理システム（１３０）のプロセッサ（２３６）が、予約購入要請に基づいて購入対象商品に対する購入取引を処理し、ユーザーに予約購入サービスを提供する具体的な方式について詳細に説明される。

図３は、本開示の一実施例に係る情報処理システム（１３０）の構成を示すブロック図である。情報処理システム（１３０）のプロセッサ（２３６）は、予約情報管理部（３１０）、決済情報管理部（３２０）、条件判定部（３３０）および決済処理部（３４０）を含むように構成されることができる。また、プロセッサ（２３６）は、通信モジュール（２３８）を通じて情報および/またはデータを外部システムと送受信することができる。これに加えて、プロセッサ（２３６）は、情報および/またはデータをメモリ（２３４）に格納したり、メモリ（２３４）から情報および/またはデータを取得したりすることができる。

予約情報管理部（３１０）は、通信モジュール（２３８）から予約購入要請を受信し、受信された予約購入要請をメモリ（２３４）に格納するように構成されることができる。予約購入要請は、購入対象商品に対する情報、希望購入条件、決済手段情報などを含むことができる。ここで、購入対象商品に対する情報は、商品名、商品モデル名、商品イメージまたは詳細オプションのうち少なくとも１つを含み、希望購入条件は、希望する購入金額情報（例えば、歴代最低金額、具体的な金額など）または特典情報（例えば、割引率、ペイバック、リワードポイントなど）のうち少なくとも１つを含むことができる。このとき、希望購入条件が希望する購入金額情報である場合、ユーザーから入力された金額より少ない、または同じ金額で購入を希望すると判断することができる。また、希望購入条件が、ユーザーが購入によって得る特典情報に関連される場合、ユーザーから入力された特典またはもっと大きい特典の購入を希望すると判断することができる。

一実施例において、予約情報管理部（３１０）は、受信された予約購入要請に含まれた情報を標準化された表記に変換した後、メモリ（２３４）に格納するように構成されることができる。例えば、予約情報管理部（３１０）は、予約購入要請に含まれた購入対象商品に対する情報または希望購入条件のうち少なくとも１つを標準化された表記に変換することができる。メモリに格納された予約購入要請に対しては、以下で図５および図６を参照して詳細に説明する。

一方、予約情報管理部（３１０）は、メモリ（２３４）に格納された予約購入要請を削除することもできる。一実施例において、予約情報管理部（３１０）は、特定の商品が販売終了になる場合、該当の商品に対する予約購入要請を削除するように構成されることができる。また、予約情報管理部（３１０）は、予約購入要請が登録された時点から予め決められた期間が経過すると、該当の予約購入要請を削除するように構成されることができる。例えば、予約情報管理部（３１０）は、登録されてから３年が経過した予約購入要請を削除することができる。さらに、予約情報管理部（３１０）は、希望購入条件が満たされた後、予め決められた期間が経過すると、該当の予約購入要請を削除するように構成されることができる。例えば、希望購入条件が満たされたが、ユーザーが該当の商品を一定期間購入しない場合、予約情報管理部（３１０）は、予約購入要請を削除することができる。予約購入要請を削除する場合、予約情報管理部（３１０）はこれに対する情報を、通信モジュール（２３８）を通じて、削除された予約購入要請を生成したユーザーアカウントに関連したユーザー端末に提供することができる。

決済情報管理部（３２０）は、決済情報を受信してメモリ（２３４）に格納するように構成されることができる。決済情報は、ユーザー情報、商品情報、商店情報または決済金額に対する情報のうち少なくとも１つを含むことができる。一実施例において、決済情報管理部（３２０）は、決済処理部（３４０）または外部システム（例えば、オープンマーケットシステム、ショッピングモールシステム、決済プラットフォームシステムなど）から決済情報を受信することができる。一実施例において、決済情報管理部（３２０）は、受信された決済情報に含まれた情報を標準化された表記に変換した後、メモリ（２３４）に格納するように構成されることができる。例えば、決済情報管理部（３２０）は、決済情報に含まれた商品情報、商店情報または決済金額に対する情報のうち少なくとも１つを標準化された表記に変換することができる。メモリに格納された決済情報に対しては、以下で図７および図８を参照して詳細に説明する。

条件判定部（３３０）は、受信される複数の決済情報が格納された予約購入要請の購入対象商品および希望購入条件を満たすか否かをモニタリングするように構成されることができる。一実施例において、条件判定部（３３０）は、決済情報に含まれた商品情報および決済金額に対する情報を格納された予約購入要請に含まれた購入対象商品および希望購入条件と比較し、希望購入条件を満たす決済情報があるか否かを確認することができる。このとき、条件判定部（３３０）は、複数の決済情報のうち希望購入条件を満たすか、または希望購入条件より有利であると判断される決済情報を、ユーザーが購入を希望する決済情報として判定することができる。一実施例によると、希望購入条件が、ユーザーが購入対象商品に対して購入を希望する金額に対する情報である場合、ユーザーから入力された金額より少ないか、または同じ金額で購入を希望すると判断することができる。例えば、ユーザーが購入しようとする商品が「クローバーフレンズ」、「ブラウン」であって、ユーザーから入力された金額（つまり、希望購入条件）が６２,５００ウォンである場合、「クローバーフレンズ」、「ブラウン」が６２,５００ウォンで決済された決済情報だけでなく、６２,５００ウォン以下の金額で決済された決済情報もまた希望購入条件を満たすものとして判断することができる。

一実施例によると、希望購入条件が、ユーザーが購入によって得る特典情報に関連される場合、ユーザーから入力された特典またはもっと大きい特典の購入を希望すると判断することができる。例えば、ユーザーから入力された割引率（つまり、特典情報）が１０％である場合、「クローバーフレンズ」、「ブラウン」が１０％割引された金額で決済された決済情報だけでなく、１０％以上の割引金額で決済された決済情報もまた希望購入条件を満たす決済情報として判断することができる。

希望購入条件が満たされた予約購入要請がある場合、条件判定部（３３０）は、該当の予約購入要請と対応する決済情報を決済処理部（３４０）に提供し、該当の予約購入要請に対する購入取引がユーザーの入力なしで自動的に処理されるようにすることができる。代案として、条件判定部（３３０）は、該当の予約購入要請と対応する決済情報に含まれた情報のうち一部または全部を、通信モジュール（２３８）を通じて、該当の予約購入要請を生成したユーザーアカウントに関連したユーザー端末に提供することができる。この場合、ユーザーが購入取引を進行するか否かを確認した後、購入取引が処理されることができる。

一実施例において、条件判定部（３３０）は、複数の決済情報に基づいて購入対象商品が希望購入条件で特定の商店で予め決められた数量以上購入されたと判断された場合、条件が満たされたと判定するように構成されることができる。代案的または追加的に、決済処理部（３４０）は、購入対象商品に対して特定の商店で予め決められた期間以上、希望購入条件を満たす購入が行われたと判断された場合、条件が満たされたと判定するように構成されることができる。このような構成により、イベント特価販売、早い者勝ち特価販売のような一般的な方式で購入することが難しいイベントを除外することができる。

決済処理部（３４０）は、予約購入要請および決済要請を受信して、商品の購入取引を処理するように構成されることができる。予約購入要請は、条件判定部（３３０）から受信され、決済要請は、ユーザー端末または外部システム（例えば、オープンマーケットシステム、ショッピングモールシステム、決済プラットフォームシステムなど）から受信されることができる。決済処理部（３４０）は、商品の購入/決済取引を処理するとき、受信された決済手段情報を利用して決済/購入を進めることができる。ここで、決済手段情報は、クレジットカード情報、チェックカード情報、電話代請求書情報、金融口座情報、簡単決済情報などを含むことができる。

決済処理部（３４０）は、希望購入条件が満たされた決済情報の提供を受けて購入対象商品に対する決済/購入を進めるときに、購入対象商品を該当の決済金額で購入するための条件の有無を判断することができる。一実施例によると、ユーザー端末から受信された決済情報手段を利用して決済/購入を進めるときに、決済処理部は、希望購入条件を満たす購入対象商品をユーザー端末から受信した決済手段情報を利用して希望購入条件で購入できるか否かを判断することができる。このとき、決済処理部（３４０）が、購入対象商品を希望購入条件で購入するために他の種類の決済手段が要求されると判定する場合、決済処理部（３４０）は、通信モジュール（２３８）を通じて決済手段の再入力を要求するメッセージをユーザー端末に送信することができる。例えば、購入対象商品を希望購入条件で購入するために、特定決済手段（例えば、ＬＩＮＥ Ｐａｙ）が要求される場合、決済処理部（３４０）は、ユーザーに、決済手段を該当の決済手段に変更することを要請するメッセージを送信することができる。このとき、購入のために要求される決済手段情報が受信される場合、決済処理部（３４０）は、変更された決済手段情報を利用して購入対象商品の購入取引を処理することができる。

決済処理部（３４０）は、同一の商品に対して希望購入条件を満たす複数の予約購入要請がある場合、要請を受信した時間および/または要請を生成したユーザーランクに基づいて優先順位を付与することができる。この場合、互いに競合する予約購入要請は、付与された優先順位に基づいて順次的に処理されることができる。一実施例において、決済処理部（３４０）は、互いに競合する予約購入要請がある場合、要請を受信した時間に基づいて優先順位を付与することができる。つまり、予約購入要請を先入先出処理（Ｆｉｒｓｔ Ｉｎ Ｆｉｒｓｔ Ｏｕｔ、ＦＩＦＯ）アルゴリズムに基づいて処理することができる。代案的または追加的に、決済処理部（３４０）は、互いに競合する予約購入要請がある場合、要請を生成したユーザーランクに基づいて優先順位を付与することができる。例えば、決済処理部（３４０）は、もっと高いユーザーランクを保有したユーザーに予約購入優先権を付与することができる。

図４は、本開示の一実施例に係るユーザー端末（４１０_１〜４１０_ｎ、４２０_１〜４２０_ｎ）および情報処理システム（４３０）の内部構成を示すブロック図である。図示されたように、情報処理システム（４３０）は、決済サーバー（４３２）および予約購入サーバー（４３４）を含むように構成されることができる。つまり、情報処理システム（４３０）において決済サービスを提供するサーバーと予約購入サービスを提供するサーバーが別途のサーバーで構成されることができる。

予約購入サーバー（４３４）は、ネットワークを介して複数の第１のユーザー端末（４１０_１〜４１０_ｎ）からユーザー情報、購入対象商品に対する情報、購入しようとする数量、希望購入条件、決済手段情報などをそれぞれ含む複数の予約購入要請を受信することができる。代案的に、購入しようとする数量、決済手段情報などは、予約購入要請に含まれず、希望購入条件が満たされて製品を購入する将来の時点で、第１のユーザー端末（４１０_１〜４１０_ｎ）から受信することもできる。さらに、ユーザーは、希望購入条件が満たされる将来の時点で、予約購入要請に含まれた情報を修正することもできる。例えば、希望購入条件が満たされて製品の購入処理を行う前にユーザーが情報を修正したり、購入処理を行った後にユーザーが情報を修正したりすることができる。

一実施例において、予約購入サーバー（４３４）は、受信された複数の予約購入要請を標準化された表記に変換して格納することができる。例えば、予約購入サーバー（４３４）は、それぞれの予約購入要請に含まれた購入対象商品に対する情報、希望購入条件などを標準化された表記に変換することができる。標準化された表記に変換された予約購入要請は、予約購入サーバー（４３４）のメモリに格納されることができる。代案的または追加的に、標準化された表記に変換された予約購入要請は、情報処理システム（４３０）の外部に別途備えられた格納デバイス（例えば、クラウドサーバー装置）に格納されることができる。

決済サーバー（４３２）は、ネットワークを介して複数の第２のユーザー端末（４２０_１〜４２０_ｎ）からユーザー情報、決済商品に対する情報、数量、決済商店に対する情報、決済価格、決済手段情報などをそれぞれ含む複数の決済要請を受信することができる。この場合、情報処理システム（４３０）は、受信された決済要請に応じて決済を処理し、処理結果を決済情報としてメモリに格納することができる。図４において、複数の第１のユーザー端末（４１０_１〜４１０_ｎ）と複数の第２のユーザー端末（４２０_１〜４２０_ｎ）が別個のグループとして図示されたが、これに限定されず、ユーザー端末は、ユーザーの要請によって決済要請または予約購入要請を情報処理システム（４３０）に送信することができる。

一実施例において、決済サーバー（４３２）は、生成された決済情報を標準化された表記に変換して格納することができる。例えば、決済サーバー（４３２）は、それぞれの決済情報に含まれた決済商品に対する情報、決済商店に対する情報、決済価格などを標準化された表記に変換することができる。標準化された表記に変換された決済情報は、決済サーバー（４３２）のメモリに格納されることができる。代案的または追加的に、標準化された表記に変換された決済情報は、情報処理システム（４３０）の外部に別途備えられた格納デバイス（例えば、クラウドサーバー装置）に格納されることができる。

決済サーバー（４３２）は、予約購入サーバー（４３４）に決済情報を提供することができる。一実施例において、決済サーバー（４３２）は、格納される決済情報をすべてリアルタイムで予約購入サーバー（４３４）に提供することができる。他の実施例において、決済サーバー（４３２）は、定期的にまたは非定期的に決済情報を予約購入サーバー（４３４）に提供することができる。代案的に、決済サーバー（４３２）は、同一商品に対して決済価格に変化が生じた決済情報のみを予約購入サーバー（４３４）に提供することができる。さらに他の実施例において、決済サーバー（４３２）は、予約購入サーバー（４３４）に格納された予約購入要請に関連した商品に対する決済情報のみを予約購入サーバー（４３４）に提供することができる。

予約購入サーバー（４３４）は、決済サーバー（４３２）から提供される決済情報に基づいて、格納された予約購入要請のうち希望購入条件を満たす予約購入要請があるか否かをモニタリングすることができる。ここで、希望購入条件は、歴代最低価格、割引率、ペイバック、リワードポイント、購入しようとする具体的な金額などであることができる。予約購入サーバー（４３４）は、モニタリング結果に基づいて、希望購入条件が満たされた予約購入要請を決済サーバー（４３２）に提供し、決済サーバー（４３２）が購入取引を処理するようにすることができる。この場合、決済サーバー（４３２）は、処理された購入取引に対する決済情報を格納し、該当の決済情報を予約購入サーバー（４３４）に提供することができる。

一実施例において、希望購入条件が満たされた予約購入要請の購入取引処理は、ユーザーの入力なしで自動的に遂行されたり、ユーザーの確認後に遂行されたりすることができる。予約購入サーバー（４３４）は、購入取引が処理された後、予約購入に関連した情報（決済情報など）を該当の予約購入要請を送信した第１のユーザー端末（４１０_１〜４１０_ｎ）に送信することができる。

図４において、第２のユーザー端末（４２０_１〜４２０_ｎ）が情報処理システム（４３０）と直接通信して決済を行うものとして図示されているが、これに限定されない。例えば、第２のユーザー端末（４２０_１〜４２０_ｎ）は、オープンマーケット、ショッピングモールシステムなどの外部サーバーを経由して決済サーバー（４３２）に決済要請を提供することができる。

図５は、本開示の一実施例に基づいて予約購入要請を標準化された表記に変換した後、格納する例示を示す図面である。購入対象商品に対する情報の場合、同一の商品であっても商品を販売する主体によって、異なる言語（例えば、英語、ハングルなど）や異なる名称で表記され得るため、効率的な情報管理のために標準化された表記に変換する必要がある。したがって、商品を販売する主体別に使用する商品の表記を収集し、該当の表記を標準化した表記と一緒に格納することにより、商品ＤＢ（５１０）を構築することができる。

一実施例において、予約情報管理部は、予約購入要請に含まれた購入対象商品に対する情報を商品ＤＢ（５１０）で照会して、該当の商品の標準化された表記に変換した後、予約購入要請ＤＢ（５２０）に格納することができる。例えば、同一商品をショッピングモールＡでは「Ｉｔｅｍ ａａ」、ショッピングモールＢでは「Ｉｔｅｍ ａａａ」と互いに異なるように表記する場合、商品ＤＢ（５１０）を構築するとき、「Ｉｔｅｍ ａａ」と「Ｉｔｅｍ ａａａ」を「Ｉｔｅｍ １」に統一して格納することができる。この場合、予約情報管理部は、受信される予約購入要請に含まれた購入対象商品に対する情報が「Ｉｔｅｍ ａａ」または「Ｉｔｅｍ ａａａ」である場合、標準化された表記である「Ｉｔｅｍ １」に変換して予約購入要請ＤＢに格納することができる。また、購入対象商品に対する情報が商品名以外に詳細オプション（色、容量など）も含む場合、詳細オプションも同様の方式で標準化されて予約購入要請ＤＢ（５２０）に格納されることができる。

希望購入条件表記の場合にも、ユーザーが入力する希望購入価格の通貨（ＫＲＷ、ＵＳＤ、ＪＰＹなど）が異なったり、歴代最低価格または一定パーセンテージ割引のオプションを選択したりする場合、効率的な情報管理のために標準化された表記に変換される必要がある。したがって、予約情報管理部は、予約購入要請に含まれた希望購入条件を標準化された表記に変換して予約購入要請ＤＢ（５２０）に格納することができる。例えば、希望購入価格は、１つの通貨（例えば、ＫＲＷ）に換算されて格納され、歴代最低価格および一定パーセンテージ割引のオプションは、価格に換算されて格納されることができる。

図示されたように、受信された予約購入要請は、表記が標準化された後、予約情報管理部によってデータベース化されて格納されることができる。例えば、標準化された予約購入要請は、情報処理システムのメモリ（例えば、インメモリデータベース）にデータベース化されて格納され、管理および/または分類されることができる。他の実施例によると、格納デバイス（例えば、クラウドサーバー装置）が外部に別途備えられ、予約購入要請が外部格納デバイスにデータベース化されて格納されることができる。

図６は、本開示の一実施例に係る例示的な予約購入要請ＤＢ（６００）を示す図面である。前述したように、予約購入要請ＤＢ（６００）は、予約購入要請が標準化された表記に変換、格納されて構築されることができる。予約購入要請ＤＢ（６００）は、ユーザー情報（６１０）、商品名（６２０）、詳細オプション（６３０）、希望購入条件（６４０）、決済手段情報（６５０）などが互いに関連して格納される任意のデータ構造として構築されることができる。

ユーザー情報（６１０）は、例えば、ユーザーアカウント、ユーザー個人情報などのように予約購入要請を生成したユーザーに関連した情報であることができる。商品名（６２０）、詳細オプション（６３０）は、商品ＤＢを照会することによって標準化された表記に格納されることができる。ここで、詳細オプション（６３０）は、予約購入要請時にユーザーが購入対象商品に対して選択できる詳細条件であることができる。例えば、「Ｉｔｅｍ １」の詳細オプションは、図６に図示されたように、「黒」または「赤」であることができる。

希望購入条件（６４０）は、歴代最低価格、割引率（例えば、２０％割引）、希望する購入金額などが標準化された表記に格納されたものであることができる。決済手段情報（６５０）は、希望購入条件が満たされて商品購入処理を進めるときに、費用の決済を行うための情報として、クレジットカード情報、チェックカード情報、電話代請求書情報、金融口座情報または簡単決済情報のうち少なくとも１つを含むことができる。例えば、図６に図示されたように、決済手段情報（６５０）は、例えば、「ＬＩＮＥ Ｐａｙ」のような簡単決済情報であることができる。

図７は、本開示の一実施例に基づいて決済要請を標準化された表記に変換した後、格納する例示を示す図面である。決済情報管理部は、受信された決済情報を標準化して決済情報ＤＢ（７３０）に格納することができる。一実施例において、決済情報管理部は、決済情報に含まれた商品情報を商品ＤＢ（７１０）で照会し、該当の商品の標準化された表記に変換した後、決済情報ＤＢ（７３０）に格納することができる。商品ＤＢ（７１０）は、図５に図示された商品ＤＢ（５１０）と同一であることができる。この場合、予約情報管理部と決済情報管理部は、１つの商品ＤＢを共有して使用することができる。

商店情報も同じ商店であっても生成する主体によって、異なる言語や異なる名称で表記され得るため、効率的な情報管理のために標準化された表記に変換される必要がある。商店ＤＢ（７２０）は、商品ＤＢと同様の方式で構築されることができる。一実施例において、決済情報管理部は、決済情報に含まれた商品情報を商品ＤＢ（７２０）で照会し、標準化された表記に変換した後、決済情報ＤＢ（７３０）に格納することができる。例えば、同じ商店が「Ｓｈｏｐ ａａ」、「Ｓｈｏｐ ａａａ」のように互いに異なる表記で記載された場合、決済情報管理部は、商店ＤＢ（７２０）を照会して、標準化された表記である「Ｓｈｏｐ １」に変換して決済情報ＤＢ（７３０）に格納することができる。

最後に、決済情報に含まれた決済金額に対する情報も標準化されて決済情報ＤＢ（７３０）に格納することができる。例えば、決済金額を同じ通貨（例えば、ＫＲＷ）に標準化して格納することができる。

図示されたように、受信された決済情報は、表記が標準化された後、決済情報管理部によってデータベース化されて格納されることができる。例えば、標準化された決済情報は、情報処理システムのメモリ（例えば、インメモリデータベース）にデータベース化されて格納され、管理および/または分類されることができる。他の実施例よると、格納デバイス（例えば、クラウドサーバー装置）が外部に別途備えられ、決済情報が外部格納デバイスにデータベース化されて格納されることができる。

図８は、本開示の一実施例に係る例示的な決済情報ＤＢ（８００）を示す図面である。前述したように、決済情報ＤＢ（８００）は、決済情報が標準化され表記に変換、格納されて構築されることができる。決済情報ＤＢ（８００）は、商店名（８１０）、商品名（８２０）、詳細オプション（８３０）、決済金額（８４０）などが互いに関連して格納される任意のデータ構造として構築されることができる。

商店名（８１０）は、商店ＤＢを照会することにより、標準化された表記で格納されることができる。また、商品名（８２０）と詳細オプション（８３０）は、商品ＤＢを照会することにより、標準化された表記に格納されることができる。ここで、詳細オプション（８３０）は、決済要請時にユーザーが決済商品に対して選択できる詳細条件であることができる。例えば、図８に図示されたように、「Ｉｔｅｍ １」の詳細オプションは、「黒」または「赤」であり、「Ｉｔｅｍ ２」の詳細オプションは、「１００ ｍｌ」または「５０ ｍｌ」であることができる。

図９は、本開示の一実施例に基づいて特定の商品を購入または予約購入するための画面の例示を示す図面である。一実施例によると、ユーザーは、価格比較サイトなどで商品を購入するために、ユーザー検索インターフェース（９１０）に検索しようとする商品名を入力することができる。例えば、ユーザーは、ユーザー検索インターフェース（９１０）に「クローバーフレンズ」という検索キーワードを入力し、該当のキーワードに関連した商品を検索することができる。

この場合、検索結果が画面上に表示されてユーザーに提供されることができる。例えば、検索した商品のイメージと現在該当の商品を販売している商店が、価格順に画面に表示されることができる。ユーザーが画面に表示された商店のうち１つを選択し、購入ボタン（９２０）をタッチ入力などを通じて選択する場合、「クローバーフレンズ」を直ちに購入できる画面に移動して、決済要請を生成することができる。一方、ユーザーが画面に表示された商店のうち１つを選択し、予約購入ボタン（９３０）をタッチ入力などを通じて選択する場合、「クローバーフレンズ」を予約購入するための画面（図１０参照）に移動して、予約購入要請を生成することができる。

図１０は、本開示の一実施例に係る予約購入要請を生成する例示を示す図面である。ユーザー端末には、予約購入要請を生成するためのインターフェースが表示されることができる。図１０に図示されたように、ユーザーは、タッチ入力などを通じて購入数量（１０１０）、詳細オプション（１０２０）、希望購入条件（１０３０）、決済手段（１０４０）に対する情報を入力することができる。例えば、ユーザーは、購入数量を「１」、詳細オプションは「ブラウン」、希望購入条件は「歴代最低金額」、決済手段は「ＬＩＮＥ Ｐａｙ」に選択することができる。

その後、ユーザーは、希望購入条件が満たされると製品が直ちに購入される自動購入要請ボタン（１０５０）または希望購入条件が満たされると購入可能な商店と購入可能な価格に対する情報を受信できる通知要請ボタン（１０６０）を、タッチ入力などを通じて選択し、購入対象商品に対する予約購入を要請することができる。ユーザーが購入要請ボタン（１０５０）を選択する場合、決済手段に対するユーザー認証を要請するページが呼び出されることができる。ユーザーが通知要請ボタン（１０６０）を選択する場合、ユーザーは、決済手段を予約購入要請の生成時点ではなく、それ以降の商品購入時点で入力することができる。

図１１は、本開示の一実施例に基づいてユーザーが生成した予約購入要請を照会する例示を示す図面である。図示されたように、ユーザーが生成した予約購入要請は、自動購入リストと予約通知リストが区分されて整列され、画面に表示されることができる。例えば、ユーザーは予約購入要請のリストを確認して修正するためのユーザーインターフェースである、予約購入カートを通じて、自分が生成した予約購入要請のリストを照会および管理することができる。

一実施例によると、ユーザーは、予約購入要請を修正または削除するためのユーザーインターフェース（１１１０、１１２０、１１３０、１１４０、１１５０）を利用して予約購入カートに含まれた予約購入要請を修正または削除することができる。例えば、ユーザーは、修正または削除しようとする予約購入要請に対するチェックボックス（１１１０、１１２０、１１３０）を選択し、修正ボタン（１１４０）または削除ボタン（１１５０）をタッチ入力などで選択することにより、該当の予約購入要請リストを修正または削除することができる。ユーザーが修正ボタン（１１４０）を選択する場合、購入数量、詳細オプション、決済手段、希望購入条件などを修正することができ、自動購入を予約通知に修正することも可能である。

一実施例によると、ユーザーは、予約購入要請のリストに表示される予約購入要請のうち１つを選択して、該当の予約購入要請に含まれた購入対象商品に対する情報の提供を受けることができる。ここで、購入対象商品に対する情報は、購入対象商品の現在の最低価格、該当の購入対象商品に対する決済情報、レビュー情報、商品詳細イメージおよび関連イベント情報を含むことができる。例えば、ユーザーは、予約購入カートに表示された商品名「クローバーフレンズ」、詳細オプション「ブラウン」に対する予約購入要請が表示された領域（１１６０）をタッチして、「クローバーフレンズ」、「ブラウン」に対する現在の最低価格、他のユーザーの決済情報（決済商品、決済金額などを含む）、レビュー情報、詳細イメージ、関連イベント情報などを照会することができる。

図１２は、本開示の一実施例に係る購入対象商品が自動的に購入された後、購入取引に関連した情報をユーザーに提供する例示を示す図面である。図示されたように、ユーザーが生成した予約購入要請の希望取引条件が満たされて購入対象商品が自動的に購入される場合、ユーザーは、ユーザー端末を通じて完了された購入取引に関連した情報の提供を受けることができる。このとき、ユーザー端末には、処理された購入取引に関連した情報と一緒に自動購入の取り消しのためのユーザーインターフェース（１２２０）が表示されることができる。

図１２に図示されたように、自動購入された製品である「クローバーフレンズブラウン」のイメージと製品名がユーザー端末の画面に表示され、その下端に「クローバーフレンズブラウン１つが歴代最低価格である６２,０００ウォンでＬＩＮＥ ＳＴＯＲＥで自動購入されました。」のメッセージ（１２１０）が一緒に表示されることができる。また、自動的に購入された取引を取り消すための自動購入取り消しボタン（１２２０）が、ユーザー端末の画面に一緒に出力されることができる。ユーザーは、自動購入取り消しボタン（１２２０）を選択して、該当の自動購入を取り消すことができる。代案的に、ユーザーは、自動購入取り消しボタン（１２２０）なしに自動購入に関連した情報のみ提供を受けることもできる。また、ユーザーは、自動購入に関連した情報を提供する画面に連結されるＵＲＬなどのリンクの提供を受けることができる。購入取引に関連した情報は、ポップアップ画面だけでなく、ユーザー端末にインストールされたアプリケーションを介して提供されることができる。一例として、ユーザーが生成した予約購入要請の希望取引条件が満たされて購入対象商品が自動的に購入される場合、ユーザーのユーザー端末にインストールされたインスタントメッセージングアプリケーションを介して完了された購入取引に関連した情報が提供されることができる。このとき、完了された購入取引に関連した情報は、自動購入の取り消しのためのユーザーインターフェース（１２２０）を含むアクションメッセージの形態でメッセンジャーを介して伝達されることができる。購入取引に関連した情報は、ＳＭＳ、専用アプリケーションを介したチャットボックス、音声形態出力などの形態で提供されることができるが、これに限定されるものではない。

図１３は、本開示の一実施例に係る商品予約購入方法（１３００）を示すフローチャートである。商品予約購入方法（１３００）は、図１、図２および図４の情報処理システム（１３０、４３０）によって遂行されることができる。図示されたように、商品予約購入方法（１３００）は、ユーザー端末からユーザー情報、購入対象商品に対する情報および希望購入条件を含む予約購入要請を受信するステップ（Ｓ１３１０）で開始されることができる。ここで、購入対象商品に対する情報は、商品名または詳細オプションのうち少なくとも１つを含むことができる。また、希望購入条件は、歴代最低金額、割引率または希望する購入金額のうち少なくとも１つを含むことができる。一実施例において、受信された予約購入要請に含まれた購入対象商品に対する情報または希望購入条件のうち少なくとも１つは、標準化された表記に変換されて格納されることができる。

そして、ステップ（Ｓ１３２０）において購入対象商品に対する複数の決済情報が受信されることができる。複数の決済情報のそれぞれは、ユーザー情報、商品情報、商店情報または決済金額に対する情報のうち少なくとも１つを含むことができる。一実施例において、受信された決済情報に含まれた商品情報、商店情報または決済金額に対する情報のうち少なくとも１つは、標準化された表記に変換されて格納されることができる。

次に、受信された複数の決済情報のうち少なくとも１つが希望購入条件を満たすか否かをモニタリングするステップ（Ｓ１３３０）が遂行されることができる。一実施例によると、受信された複数の決済情報のうち予約購入要請の希望購入条件を満たす決済情報があるか否かがモニタリングされることができる。具体的には、複数の決済情報に含まれた商品情報および決済金額に対する情報を、予約購入要請に含まれた購入対象商品および希望購入条件と比較して、希望購入条件を満たす決済情報があるか否かを確認することができる。

最後に、ステップ（Ｓ１３４０）において、モニタリング結果に基づいて、ユーザー端末から受信された決済手段情報を利用した購入対象商品の購入取引を処理することができる。ここで、決済手段情報は、クレジットカード情報、チェックカード情報、電話代請求書情報、金融口座情報または簡単決済情報のうち少なくとも１つを含むことができる。一実施例によると、希望購入条件を満たす決済情報に含まれた商店情報および予約購入要請に含まれたユーザー情報と決済手段情報を利用して、購入対象商品の購入取引をユーザー入力なしで自動的に遂行することができる。代案的に、希望購入条件を満たす決済情報に含まれた商店情報または決済金額に対する情報のうち少なくとも１つをユーザー端末に送信し、ユーザー端末から購入対象商品に対する購入承認を受信すると、商店情報、ユーザー情報および決済手段情報を利用して購入対象商品の購入取引を遂行することも可能である。

一実施例において、購入対象商品の購入取引は、購入対象商品が希望購入条件を満たす商店で予め決められた数量以上購入されたと判断された場合に処理されることができる。代案的または追加的に、購入対象商品の購入取引は、購入対象商品に対して特定の商店で予め決められた期間以上、希望購入条件を満たす購入が行われたと判断された場合に処理されることができる。また、希望購入条件を満たす複数の予約購入要請がある場合（例えば、互いに競合する予約購入要請がある場合）は、要請を受信した時間および/または要請を生成したユーザーランクに基づいて優先順位を付与し、付与した優先順位に基づいて順次的に購入取引を処理することができる。

図１４は、本開示の一実施例に基づいて予約購入要請に対する統計情報をユーザー端末の画面に表示する例示を示す図面である。予約情報管理部は、複数のユーザー端末から受信した複数の予約購入要請に基づいて統計情報を生成することができる。ここで、受信された複数の予約購入要請は、購入対象商品に対する情報または希望購入条件のうち少なくとも１つが標準化された表記に変換された後、メモリに格納されることができる。

一実施例によると、各購入対象商品別に希望購入条件に対する統計を生成し、通信モジュールを通じて販売者アカウントに関連したユーザー端末に提供することができる。図示されたように、予約情報管理部は、「クローバーフレンズ」の詳細オプション（例えば、ブラウン、サリー）別に希望購入条件に対する統計情報を生成し、生成された統計情報を「クローバーフレンズ」を販売、または関心商品として登録した販売者アカウントに提供することができる。このとき、希望購入条件は、標準化された表記（例えば、ＫＲＷ）に変換されて表示されることができる。

一実施例によると、予約情報管理部から受信された統計情報は、グラフ形式でユーザー端末の画面に表示されることができる。図示されたように、「クローバーフレンズブラウン」および「クローバーフレンズサリー」に対する予約購入要請の統計情報が画面上にグラフ形式で表示されることができる。このとき、グラフには、予約購入要請の形態、すなわち、自動購入要請と通知要請の数が分離されて表示されることができる。

統計情報は、グラフ形式だけではなく、テキスト形式など、多様な形式で出力されて販売者に提供されることができる。販売者は、予約購入要請に対する統計情報の提供を受けることによって、各商品に対する需要と需要価格を把握し、戦略的に使用することができる。つまり、販売者は、統計情報を通じて自分が販売している商品の販売価格をどの程度下げたら販売量がどの程度増えるかを高い精度で予測することができる。例えば、「クローバーフレンズブラウン」製品を販売する販売者は、統計情報に基づいて、販売価格を「６５,０００ウォン」に下げると１０個の製品が自動購入され、１１人のユーザーに希望購入条件を満たすとの通知が通報されるであることを確認することができる。

図１５は、本開示の一実施例に係る消費者需要予測方法（１５００）を示すフローチャートである。図１、図２および図４の情報処理システム（１３０、４３０）によって遂行されることができる。図示されたように、消費者需要予測方法（１５００）は、ユーザー情報、購入対象商品に対する情報および希望購入条件をそれぞれ含む複数の予約購入要請を受信するステップ（Ｓ１５１０）で開始されることができる。一実施例によると、受信された購入対象商品に対する情報または希望購入条件のうち少なくとも１つは、標準化された表記に変換されて格納されることができる。

そして、複数の予約購入要請に基づいて統計情報を生成するステップ（Ｓ１５２０）が遂行されることができる。一実施例によると、各購入対象商品別に希望購入条件に対する統計が生成されることができる。このとき、希望購入条件は、標準化された表記（例えば、ＫＲＷ）に変換されて表示されることができる。

最後に、ステップ（Ｓ１５３０）において生成された統計情報は、販売者アカウントに提供されることができる。一実施例によると、販売者アカウントが販売する商品を確認した後、該当の販売者アカウントが販売する商品に対する希望購入条件の統計が販売者アカウントに提供されることができる。代案的または追加的に、販売者アカウントが関心商品として選択した商品を確認した後、該当の商品に対する希望購入条件の統計が販売者アカウントに提供されることができる。

販売者は、情報処理システム（例えば、消費者需要予測システム）から提供される統計情報に基づいて自分が販売する商品の販売価格を修正し、格納された予約購入要請に対する購入取引を成功させることができる。一実施例において、消費者需要予測システムは、販売者アカウントから販売する商品に対する修正された販売価格を受信することができる。この場合、消費者需要予測システムは、受信した販売価格に基づいて希望購入条件が満たされる少なくとも１つの予約購入要請を判定し、希望購入条件が満たされる少なくとも１つの予約購入要請に対する購入取引を処理することができる。

上述された商品予約購入方法および消費者需要予測方法は、コンピュータ読み取り可能な記録媒体にコンピュータ読み取り可能なコードで具現されることもできる。コンピュータ読み取り可能な記録媒体は、コンピュータシステムにより読み取り可能なデータが格納されるすべての種類の記録装置を含む。コンピュータ読み取り可能な記録媒体の例としては、ＲＯＭ、ＲＡＭ、ＣＤ ＲＯＭ、磁気テープ、フロッピーディスク、光データ格納装置などがある。また、コンピュータ読み取り可能な記録媒体は、ネットワークに連結されたコンピュータシステムに分散され、分散方式でコンピュータ読み取り可能なコードが格納されて実行されることができる。そして、前記実施例を具現するための関数プログラム、コードおよびコードセグメントは、本発明が属する技術分野のプログラマーによって容易に推論されることができる。

本開示の方法、動作または技法は、多様な手段によって具現されることもできる。例えば、これらの技法は、ハードウェア、ファームウェア、ソフトウェア、またはこれらの組み合わせによって具現されることもできる。本願の開示と連携して説明された多様な例示的論理ブロック、モジュール、回路およびアルゴリズムのステップは、電子ハードウェア、コンピュータソフトウェア、または両者の組み合わせで具現され得るということを当業者は理解できるであろう。ハードウェアおよびソフトウェアのこのような相互代替を明確に説明するために、多様な例示的構成要素、ブロック、モジュール、回路およびステップがそれらの機能的観点から一般的に上述された。そのような機能がハードウェアとして具現されるか否か、またはソフトウェアとして具現されるか否かは、特定のアプリケーションおよび全体システムに課される設計要求事項によって異なることになる。当業者は、それぞれの特定のアプリケーションのために多様な方式で説明された機能を具現することもできるが、そのような具現は本開示の範囲を逸脱するものと解釈されてはならない。

ハードウェアの具現において、技法を遂行するのに利用されるプロセッシングユニットは、１つ以上のＡＳＩＣ、ＤＳＰ、デジタル信号プロセッシングデバイス（ｄｉｇｉｔａｌ ｓｉｇｎａｌ ｐｒｏｃｅｓｓｉｎｇ ｄｅｖｉｃｅｓ; ＤＳＰＤ）、プログラム可能な論理デバイス（ｐｒｏｇｒａｍｍａｂｌｅ ｌｏｇｉｃ ｄｅｖｉｃｅｓ; ＰＬＤ）、フィールドプログラム可能なゲートアレイ（ｆｉｅｌｄ ｐｒｏｇｒａｍｍａｂｌｅ ｇａｔｅ ａｒｒａｙｓ; ＦＰＧＡ）、プロセッサ、コントローラ、マイクロコントローラ、マイクロプロセッサ、電子デバイス、本開示において説明された機能を遂行するように設計された他の電子ユニット、コンピュータ、またはこれらの組み合わせの中から具現されることもできる。

したがって、本開示と連携して説明された多様な例示的論理ブロック、モジュール、および回路は、汎用プロセッサ、ＤＳＰ、ＡＳＩＣ、ＦＰＧＡや他のプログラム可能な論理デバイス、ディスクリートゲートやトランジスタロジック、ディスクリートハードウェアコンポーネント、または本願において説明された機能を遂行するように設計されたものの任意の組み合わせで具現されたり、遂行されたりすることもできる。汎用プロセッサは、マイクロプロセッサであることもできるが、代案として、プロセッサは、任意の従来のプロセッサ、コントローラ、マイクロコントローラ、または状態マシンであることもできる。プロセッサは、また、コンピューティングデバイスの組み合わせ、例えば、ＤＳＰとマイクロプロセッサ、複数のマイクロプロセッサ、ＤＳＰコアと連携した１つ以上のマイクロプロセッサ、または任意の他の構成の組み合わせで具現されることもできる。

ファームウェアおよび/またはソフトウェアの具現において、技法は、ランダムアクセスメモリ（ｒａｎｄｏｍ ａｃｃｅｓｓ ｍｅｍｏｒｙ; ＲＡＭ）、読み出し専用メモリ（ｒｅａｄ-ｏｎｌｙ ｍｅｍｏｒｙ; ＲＯＭ）、不揮発性ＲＡＭ（ｎｏｎ-ｖｏｌａｔｉｌｅ ｒａｎｄｏｍ ａｃｃｅｓｓ ｍｅｍｏｒｙ; ＮＶＲＡＭ）、ＰＲＯＭ（ｐｒｏｇｒａｍｍａｂｌｅ ｒｅａｄ-ｏｎｌｙ ｍｅｍｏｒｙ）、ＥＰＲＯＭ（ｅｒａｓａｂｌｅ ｐｒｏｇｒａｍｍａｂｌｅ ｒｅａｄ-ｏｎｌｙ ｍｅｍｏｒｙ）、ＥＥＰＲＯＭ（ｅｌｅｃｔｒｉｃａｌｌｙ ｅｒａｓａｂｌｅ ＰＲＯＭ）、フラッシュメモリ、コンパクトディスク（ｃｏｍｐａｃｔ ｄｉｓｃ; ＣＤ）、磁気または光データストレージデバイスなどのようなコンピュータ読み取り可能な媒体上に格納されたコマンドで具現されることもできる。コマンドは、１つ以上のプロセッサによって実行することもでき、プロセッサが本開示において説明された機能の特定の態様を遂行するようにすることもできる。

ソフトウェアで具現される場合、前記の技法は、１つ以上のコマンドまたはコードとしてコンピュータ読み取り可能な媒体上に格納されたり、またはコンピュータ読み取り可能な媒体を通じて送信されたりすることもできる。コンピュータ読み取り可能な媒体は、ある場所から別の場所へのコンピュータプログラムの転送を容易にする任意の媒体を含めてコンピュータ格納媒体および通信媒体の両者を含む。格納媒体は、コンピュータによってアクセス可能な任意の利用可能な媒体であることもできる。非限定的な例として、これらのコンピュータ読み取り可能な媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、ＣＤ ＲＯＭまたは他の光ディスクストレージ、磁気ディスクストレージまたは他の磁気ストレージデバイス、または所望のプログラムコードをコマンドまたはデータ構造の形態に移送または格納するために使用されることができ、コンピュータによってアクセス可能な任意の他の媒体を含むことができる。また、任意の接続がコンピュータ読み取り可能な媒体に適切に称される。

例えば、ソフトウェアが同軸ケーブル、光ファイバーケーブル、撚線、デジタル加入者回線（ＤＳＬ）、または赤外線、無線およびマイクロ波などのワイヤレス技術を使用して、ウェブサイト、サーバー、または他のリモートソースから送信されると、同軸ケーブル、光ファイバーケーブル、撚線、デジタル加入者回線、または赤外線、無線およびマイクロ波などのワイヤレス技術は、媒体の定義内に含まれる。本願において使用されたディスク（ｄｉｓｋ）とディスク（ｄｉｓｃ）は、ＣＤ、レーザーディスク、光ディスク、ＤＶＤ（ｄｉｇｉｔａｌ ｖｅｒｓａｔｉｌｅ ｄｉｓｃ）、フロッピーディスクおよびブルーレイディスクを含み、ここでディスク（ｄｉｓｋｓ）は、通常、磁気的にデータを再生し、一方ディスク（ｄｉｓｃｓ）は、レーザーを利用して光学的にデータを再生する。前記の組み合わせもコンピュータ読み取り可能な媒体の範囲内に含まれるべきである。

ソフトウェアモジュールは、ＲＡＭメモリ、フラッシュメモリ、ＲＯＭメモリ、ＥＰＲＯＭメモリ、ＥＥＰＲＯＭメモリ、レジスタ、ハードディスク、移動式ディスク、ＣＤ ＲＯＭ、または公知された任意の他の形態の格納媒体内に常駐することもできる。例示的な格納媒体は、プロセッサが格納媒体より情報を読み出したり、格納媒体に情報を記録したりすることができるように、プロセッサに連結されることができる。代案として、格納媒体は、プロセッサに統合されることもできる。プロセッサと格納媒体は、ＡＳＩＣ内に存在することもできる。ＡＳＩＣは、ユーザー端末内に存在することもできる。代案として、プロセッサと格納媒体は、ユーザー端末において個別のコンポーネントとして存在することもできる。

以上で説明された実施例が１つ以上のスタンドアロンコンピュータシステムで現在開示された主題の態様を活用するものとして記述されたが、本開示はこれに限定されず、ネットワークや分散コンピューティング環境のような任意のコンピューティング環境と連携して具現されることもできる。さらに、本開示における主題の様相は、複数のプロセッシングチップやデバイスで具現されることもでき、ストレージは、複数のデバイスにわたって同様に影響を受けることもできる。これらのデバイスは、ＰＣ、ネットワークサーバーおよびハンドヘルドデバイスを含むこともできる。

本明細書において、本開示は一部実施例に関連して説明されたが、本開示の発明の属する技術分野の通常の技術者が理解できる本開示の範囲を逸脱しない範囲で多様な変形および変更が行われることができる。また、そのような変形および変更は、本明細書に添付された特許請求の範囲内に属するものとして考えられなければならない。

１１２、１１４、１１６：ユーザー端末
１２０：ネットワーク
１３０、４３０：情報処理システム
２１２：入出力デバイス
２１４、２３２：入出力インターフェース
２１６、２３４：メモリ
２１８、２３６：プロセッサ
２２０、２３８：通信モジュール
３１０：予約情報管理部
３２０：決済情報管理部
３３０：条件判定部
３４０：決済処理部
４１０_１〜４１０_ｎ：第１のユーザー端末
４２０_１〜４２０_ｎ：第２のユーザー端末
４３２：決済サーバー
４３４：予約購入サーバー

Claims (20)

1. 商品予約購入方法であって、
   ユーザー端末からユーザー情報、購入対象商品に対する情報および希望購入条件を含む予約購入要請を受信するステップと、
   前記購入対象商品に対する複数の決済情報を受信するステップと、
   前記受信された複数の決済情報のうち少なくとも１つが前記希望購入条件を満たすか否かをモニタリングするステップと、
   前記モニタリングの結果に基づいて、前記ユーザー端末から受信された決済手段情報を利用した前記購入対象商品の購入取引を処理するステップとを含む、商品予約購入方法。
2. 前記予約購入要請は、前記決済手段情報をさらに含み、
   前記購入対象商品の購入取引を処理するステップは、
   前記受信された複数の決済情報のうち前記希望購入条件を満たす決済情報に含まれた商店情報および前記予約購入要請に含まれた前記ユーザー情報と前記決済手段情報を利用して、前記購入対象商品の購入取引をユーザー入力なしで自動的に遂行するステップと、
   前記購入取引に関連した情報を前記ユーザー端末に送信するステップとを含む、請求項１に記載の商品予約購入方法。
3. 前記購入対象商品の購入取引を処理するステップは、
   前記受信された複数の決済情報のうち前記希望購入条件を満たす決済情報に含まれた商店情報または決済金額に対する情報のうち少なくとも１つを前記ユーザー端末に送信するステップと、
   前記ユーザー端末から前記購入対象商品に対する購入承認を受信するステップと、
   前記商店情報、前記ユーザー情報および前記決済手段情報を利用して前記購入対象商品の購入取引を遂行するステップとを含む、請求項１に記載の商品予約購入方法。
4. 前記予約購入要請を受信するステップは、
   前記受信された購入対象商品に対する情報または希望購入条件のうち少なくとも１つを標準化された表記に変換して格納するステップを含む、請求項１〜３のいずれか１項に記載の商品予約購入方法。
5. 前記複数の決済情報のそれぞれは、商品情報、商店情報または決済金額に対する情報のうち少なくとも１つを含み、
   前記購入対象商品に対する複数の決済情報を受信するステップは、
   受信された各決済情報に含まれた商品情報、商店情報または決済金額に対する情報のうち少なくとも１つを標準化された表記に変換して格納するステップを含む、請求項１〜４のいずれか１項に記載の商品予約購入方法。
6. 前記購入対象商品の購入取引を処理するステップは、
   前記複数の決済情報に基づいて前記購入対象商品が前記希望購入条件を満たす商店で、予め決められた数量以上購入されたと判断された場合、該当の商店に対する情報、前記ユーザー情報および前記決済手段情報を利用して前記購入対象商品の購入取引を処理するステップを含む、請求項１に記載の商品予約購入方法。
7. 前記購入対象商品の購入取引を処理するステップは、
   前記購入対象商品に対して特定の商店で予め決められた期間以上、前記希望購入条件を満たす購入が行われたと判断された場合、前記特定の商店に対する情報、前記ユーザー情報および前記決済手段情報を利用して前記購入対象商品の購入取引を処理するステップを含む、請求項１に記載の商品予約購入方法。
8. 前記購入対象商品の購入取引を処理するステップは、
   前記予約購入要請と競合する他の予約購入要請が存在する場合、要請を受信した時間に基づいて優先順位を付与するステップと、
   優先順位に基づいて各要請に対する購入取引を処理するステップとを含む、請求項１に記載の商品予約購入方法。
9. 前記購入対象商品の購入取引を処理するステップは、
   前記予約購入要請と競合する他の予約購入要請が存在する場合、要請を生成したユーザーランクに基づいて優先順位を付与するステップと、
   優先順位に基づいて各要請に対する購入取引を処理するステップとを含む、請求項１に記載の商品予約購入方法。
10. 前記購入対象商品に対する情報は、商品名、商品モデル名、商品イメージまたは詳細オプションのうち少なくとも１つを含む、請求項１〜９のいずれか１項に記載の商品予約購入方法。
11. 前記受信された複数の決済情報のうち少なくとも１つが前記希望購入条件を満たすか否かをモニタリングするステップは、
    前記複数の決済情報のうち前記希望購入条件より有利であると判断される決済情報を、希望購入条件を満たす決済情報として判定するステップを含む、請求項１〜１０のいずれか１項に記載の商品予約購入方法。
12. 前記モニタリングの結果に基づいて、前記ユーザー端末から受信された決済手段情報を利用した前記購入対象商品の購入取引を処理するステップは、
    前記受信された複数の決済情報のうち前記希望購入条件を満たす決済情報に含まれた商店情報および前記決済手段情報を利用して、前記購入対象商品を前記希望購入条件で購入できるか否かを判断するステップと、
    前記購入対象商品を前記希望購入条件で購入するために他の種類の決済手段が要求されると判定することに応答して、前記ユーザー端末に決済手段の再入力を要求するメッセージを送信するステップとを含む、請求項１に記載の商品予約購入方法。
13. 請求項１〜１２のいずれか１項による商品予約購入方法をコンピュータで実行するためのコンピュータプログラム。
14. 商品予約購入システムであって、
    メモリと、
    前記メモリと連結され、前記メモリに含まれたコンピュータ読み取り可能なコマンドを実行するように構成された少なくとも１つのプロセッサとを含み、
    前記少なくとも１つのプロセッサは、
    ユーザー情報、購入対象商品に対する情報および希望購入条件を含む予約購入要請を受信して前記メモリに格納するように構成された予約情報管理部と、
    前記購入対象商品に対する複数の決済情報を受信して前記メモリに格納するように構成された決済情報管理部と、
    前記複数の決済情報のうち少なくとも１つが前記希望購入条件を満たすか否かをモニタリングするように構成された条件判定部と、
    前記モニタリングの結果に基づいて、受信された決済手段情報を利用した前記購入対象商品の購入取引を処理するように構成された決済処理部とを含む、商品予約購入システム。
15. 消費者需要予測方法であって、
    ユーザー情報、購入対象商品に対する情報および希望購入条件をそれぞれ含む複数の予約購入要請を受信するステップと、
    前記複数の予約購入要請に基づいて統計情報を生成するステップと、
    生成された統計情報を販売者アカウントに提供するステップとを含む、消費者需要予測方法。
16. 前記複数の予約購入要請を受信するステップは、
    前記受信された購入対象商品に対する情報または希望購入条件のうち少なくとも１つを標準化された表記に変換して格納するステップを含む、請求項１５に記載の消費者需要予測方法。
17. 前記複数の予約購入要請に基づいて統計情報を生成するステップは、
    各購入対象商品別に希望購入条件に対する統計を生成するステップを含み、
    前記生成された統計情報を販売者アカウントに提供するステップは、
    前記販売者アカウントが販売する商品を確認するステップと、
    前記販売者アカウントが販売する商品に対する希望購入条件の統計を前記販売者アカウントに提供するステップとを含む、請求項１５または１６に記載の消費者需要予測方法。
18. 前記販売者アカウントから販売する商品に対する修正された販売価格を受信するステップと、
    前記修正された販売価格に基づいて希望購入条件が満たされる少なくとも１つの予約購入要請を判定するステップと、
    前記希望購入条件が満たされる少なくとも１つの予約購入要請に対する購入取引を処理するステップとをさらに含む、請求項１５〜１７のいずれか１項に記載の消費者需要予測方法。
19. 請求項１５〜１８のいずれか１項による消費者需要予測方法をコンピュータで実行するためのコンピュータプログラム。
20. 消費者需要予測システムであって、
    メモリと、
    前記メモリと連結され、前記メモリに含まれたコンピュータ読み取り可能なコマンドを実行するように構成された少なくとも１つのプロセッサとを含み、
    前記少なくとも１つのプロセッサは、
    ユーザー情報、購入対象商品に対する情報および希望購入条件をそれぞれ含む複数の予約購入要請を受信して前記メモリに格納し、前記複数の予約購入要請に基づいて統計情報を生成するように構成された予約情報管理部と、
    前記生成された統計情報を販売者アカウントに関連した外部デバイスに提供するように構成された通信モジュールとを含む、消費者需要予測システム。

Images