(57)【要約】【課題】  仮想貨幣取引システム及び方法を提供する。【解決手段】  仮想貨幣取引のためのシステムは、仮想貨幣取引を要請する注文の処理のために前記注文とともに締結される他の注文をマッチングして取引対を生成する第１マッチングサーバーと、前記第１マッチングサーバーを前記取引システムに追加させたコーディネーション装置とを含み、前記コーディネーション装置は、前記第１マッチングサーバーの障害の際に第２マッチングサーバーを登録して前記注文を処理する。【選択図】  図１
2020047274.tif 000002
【特許請求の範囲】
【請求項１】
仮想貨幣取引のためのシステムであって、
仮想貨幣取引を要請する注文の処理のために前記注文とともに締結される他の注文をマッチングして取引対を生成する第１マッチングサーバーと、
前記第１マッチングサーバーを前記取引システムに追加させたコーディネーション装置とを含み、
前記コーディネーション装置は、
前記第１マッチングサーバーの障害の際に第２マッチングサーバーを登録して前記注文を処理する、仮想貨幣取引システム。
【請求項２】
前記コーディネーション装置は、
一つ以上のスレーブインスタンスの中で一つをマスターインスタンスとして選択し、前記マスターインスタンスに対応する第２マッチングサーバーを登録する、請求項１に記載の仮想貨幣取引システム。
【請求項３】
前記コーディネーション装置は、
前記第１マッチングサーバーの障害の際、前記一つ以上のスレーブインスタンスの中で一番先に登録に成功するインスタンスをマスターインスタンスに決定する、請求項２に記載の仮想貨幣取引システム。
【請求項４】
前記注文をユーザーから獲得して前記第１マッチングサーバーに伝達するアドミッションサーバーをさらに含み、
前記第１マッチングサーバーは前記アドミッションサーバーから受信した注文をキューイングする、請求項１に記載の仮想貨幣取引システム。
【請求項５】
前記第２マッチングサーバーは、
前記アドミッションサーバーからの注文をペンディングし、前記第１マッチングサーバーにキューイングされた注文をデータベースから復旧すれば、ペンディングされた注文をキューイングする、請求項４に記載の仮想貨幣取引システム。
【請求項６】
前記第１マッチングサーバーから受信した締結情報に基づいてストップ取引の注文に対応する条件が満たされれば、指定価取引の注文及び市場価取引の注文の少なくとも一つにストップ取引の注文を変換するストップオーダーサーバーをさらに含み、
前記アドミッションサーバーは、獲得した注文の種類を識別し、前記注文の種類がストップ取引であれば前記注文を前記ストップオーダーサーバーに伝達し、前記ストップオーダーサーバーから指定価取引及び市場価取引の少なくとも一つの取引を要請する注文を獲得する、請求項４に記載の仮想貨幣取引システム。
【請求項７】
前記コーディネーション装置は、
前記ストップオーダーサーバーの障害の際、一つ以上のスレーブインスタンスの中で一つをマスターインスタンスとして選択し、他のストップオーダーサーバーとして前記マスターインスタンスに対応するストップオーダーサーバーを登録する、請求項６に記載の仮想貨幣取引システム。
【請求項８】
前記注文の記録のためのデータベースと通信し、前記注文の処理のためのデータのリース（ｌｅａｓｅ）要請を受信するキャッシュサーバーをさらに含む、請求項１に記載の仮想貨幣取引システム。
【請求項９】
前記第１マッチングサーバーから前記取引対に対する締結要請を受信して前記取引対を締結するコミットサーバーをさらに含む、請求項１に記載の仮想貨幣取引システム。
【請求項１０】
前記第２マッチングサーバーは、
前記第１マッチングサーバーによって要請された締結要請に対する応答を前記コミットサーバーから獲得すれば、前記第１マッチングサーバーによってキューイングされた注文をデータベースから復旧する、請求項９に記載の仮想貨幣取引システム。
【請求項１１】
仮想貨幣取引を要請する注文の処理のために前記注文とともに締結される他の注文をマッチングして取引対を生成する第１マッチングサーバーを含む仮想貨幣取引システムが仮想貨幣を取引する方法であって、
前記第１マッチングサーバーの障害の際、第２マッチングサーバーを登録して前記注文を処理する段階を含む、仮想貨幣取引方法。
【請求項１２】
前記注文を処理する段階は、
一つ以上のスレーブインスタンスの中で一つをマスターインスタンスとして選択し、前記マスターインスタンスに対応する第２マッチングサーバーを登録する段階を含む、請求項１１に記載の仮想貨幣取引方法。
【請求項１３】
前記仮想貨幣取引システムは、前記注文をユーザーから獲得して前記第１マッチングサーバーに伝達するアドミッションサーバーをさらに含み、
前記仮想貨幣取引方法は、
前記第２マッチングサーバーが、前記アドミッションサーバーからの注文をペンディングし、前記第１マッチングサーバーにキューイングされた注文をデータベースから復旧すれば、ペンディングされた注文をキューイングする段階をさらに含む、請求項１１に記載の仮想貨幣取引方法。
【請求項１４】
前記仮想貨幣取引システムは、前記第１マッチングサーバーから前記取引対に対する締結要請を受信して前記取引対を締結するコミットサーバーをさらに含み、
前記第１マッチングサーバーによって要請された締結要請に対する応答を前記コミットサーバーから獲得すれば、前記第１マッチングサーバーによってキューイングされた注文をデータベースから復旧する段階をさらに含む、請求項１１に記載の仮想貨幣取引方法。
【請求項１５】
請求項１１に記載の方法を実行するプログラムが記録された、コンピュータ可読の記録媒体。
【請求項１６】
仮想貨幣取引システムによって実行され、請求項１１に記載の方法を遂行するために媒体に記憶された、コンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本明細書で開示する実施例は仮想貨幣を取引する方法及びシステムに係り、より詳しくは、順次締結されなければならない仮想貨幣取引において障害の発生に柔軟に対処して安全に取引が締結されるようにする仮想貨幣取引方法及びシステムに関する。
【背景技術】
【０００２】
最近になって、ビットコイン、イーサリアムのような仮想貨幣が貨幣としての信用と価値を有することになるにつれてその取引が活発になっている。例えば、実物貨幣で仮想貨幣を買収することができ、仮想貨幣で実物貨幣を買収することができる。また、仮想貨幣そのものが価値を有することによって他の仮想貨幣との交換の対象になることもある。
【０００３】
仮想貨幣の取引が活発になるにつれて仮想貨幣を安全に取引しながら早く処理することができるシステムのニーズが高くなっている。また、仮想貨幣量が流動的であるから、仮想貨幣取引の要請が急に増加したときにも増加量に対して柔軟に対処することができるシステムが必要である。ただ、今日の仮想貨幣の取引を仲介するシステムは取引を遂行するのに止まるだけ、取引を早く締結させるかシステム内の障害が発生したとき、前記障害に対する対応策が十分でない。
【０００４】
因みに、韓国特許公開第１０−２０１８−０１０７０３７号は、購買者は仮想貨幣の市勢によって現金化して使うことができ、販売者は一般決済と同様に代金を要請し、現金又は仮想貨幣で支払われることができる決済システムを提案するだけであり、上述したニーズを満たしていない。
【０００５】
したがって、上述したニーズを満たすための技術が必要になった。
【０００６】
一方、前述した背景技術は発明者が本発明の導出のために保有しているか本発明の導出過程で習得した技術情報であり、必ずしも本発明の出願前に一般の公衆に公開された公知技術であるとは言えない。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】韓国公開特許第２０１８−０１０７０３７号公報
【発明の概要】
【発明が解決しようとする課題】
【０００８】
本明細書で開示する実施例は、仮想貨幣取引システム及び方法を提示することに目的がある。
【０００９】
本明細書で開示する実施例は、秒当たり処理可能な注文処理件数を高めることができて効率的に注文を処理することができる仮想貨幣取引システム及び方法を提示することに他の目的がある。
【００１０】
本明細書で開示する実施例は、仮想貨幣取引サービスを容易に拡張させることができる仮想貨幣取引システム及び方法を提示することにさらに他の目的がある。
【００１１】
本明細書で開示する実施例は、取引システムで発生し得る障害に対して能動的に対処可能な仮想貨幣取引システム及び方法を提示することにさらに他の目的がある。
【００１２】
本明細書で開示する実施例は、データベースに加わる負荷を最小化することができる仮想貨幣取引システム及び方法を提示することにさらに他の目的がある。
【００１３】
本明細書で開示する実施例は、ユーザーデータを安全に用いることができる仮想貨幣取引システム及び方法を提示することにさらに他の目的がある。
【課題を解決するための手段】
【００１４】
上述した技術的課題を達成するための技術的手段として、一実施例によれば、仮想貨幣取引のためのシステムであって、仮想貨幣取引を要請する注文の処理のために前記注文とともに締結される他の注文をマッチングして取引対を生成する第１マッチングサーバーと、前記第１マッチングサーバーを前記取引システムに追加させたコーディネーション装置とを含み、前記コーディネーション装置は、前記第１マッチングサーバーの障害の際に第２マッチングサーバーを登録して前記注文を処理する。
【００１５】
他の実施例によれば、仮想貨幣取引を要請する注文の処理のために前記注文とともに締結される他の注文をマッチングして取引対を生成する第１マッチングサーバーを含む仮想貨幣取引システムが仮想貨幣を取引する方法であって、前記第１マッチングサーバーの障害の際、第２マッチングサーバーを登録して前記注文を処理する段階を含む。
【００１６】
さらに他の実施例によれば、仮想貨幣取引方法を実行するプログラムが記録されたコンピュータ可読の記録媒体であり、前記仮想貨幣取引方法は、第１マッチングサーバーの障害の際、第２マッチングサーバーを登録して注文を処理する段階を含む。
【００１７】
さらに他の実施例によれば、仮想貨幣取引システムによって実行され、仮想貨幣取引方法を遂行するために媒体に記憶されたコンピュータプログラムであり、前記仮想貨幣取引方法は、第１マッチングサーバーの障害の際、第２マッチングサーバーを登録して注文を処理する段階を含む。
【発明の効果】
【００１８】
前述した課題解決手段のいずれか一つによれば、仮想貨幣取引システム及び方法を提示することができる。
【００１９】
前述した課題解決手段のいずれか一つによれば、秒当たり処理可能な注文処理件数を高めることができて効率的に注文を処理することができる仮想貨幣取引システム及び方法を提示することができる。
【００２０】
前述した課題解決手段のいずれか一つによれば、仮想貨幣取引サービスを容易に拡張させることができる仮想貨幣取引システム及び方法を提示することができる。すなわち、注文量が増加するか注文の処理による取引量が増加してもシステムをスケールアウト（ｓｃａｌｅ−ｏｕｔ）することによってサービスを拡張させることができる。
【００２１】
前述した課題解決手段のいずれか一つによれば、取引システムで発生し得る障害に対して能動的に対処可能な仮想貨幣取引システム及び方法を提示することができる。よって、仮想貨幣取引サービスの提供時、サービスの中断なしに仮想貨幣の取引ができるようにする。
【００２２】
前述した課題解決手段のいずれか一つによれば、データベースに加わる負荷を最小化することができる仮想貨幣取引システム及び方法を提示することができる。取引システムを構成する注文を獲得するアドミッションサーバーが、注文を処理するマッチングサーバーに注文をキューイングすることにより、マッチングサーバーが注文をデータベースから持ってこなくても良く、その結果、データベースに加わる負荷を最小化することができる。
【００２３】
前述した課題解決手段のいずれか一つによれば、ユーザーデータを安全に用いることができる仮想貨幣取引システム及び方法を提示することができる。すなわち、ユーザーデータをリース（ｌｅａｓｅ）要請することにより、アドミッションサーバー又はコミットサーバーがキャッシュサーバーを用いるときに発生し得るデータ競合を防止することができる。
【００２４】
開示する実施例で得られる効果は以上で言及した効果に制限されず、言及しなかった他の効果は下記の記載で開示する実施例が属する技術分野で通常の知識を有する者に明らかに理解可能であろう。
【図面の簡単な説明】
【００２５】
【図１】一実施例による仮想貨幣取引システムを示す構成図である。
【図２】一実施例による仮想貨幣取引システムを示す構成図である。
【図３】一実施例による仮想貨幣取引システムを示す構成図である。
【図４】一実施例による仮想貨幣取引方法を説明するためのフローチャートである。
【図５】一実施例による仮想貨幣取引方法を説明するためのフローチャートである。
【図６】一実施例による仮想貨幣取引方法を説明するためのフローチャートである。
【発明を実施するための形態】
【００２６】
以下では添付図面に基づいて多様な実施例を詳細に説明する。以下で説明する実施例は様々な相異なる形態に変形されて実施されることもできる。実施例の特徴をより明確に説明するために、以下の実施例が属する技術分野で通常の知識を有する者に広く知られている事項についての詳細な説明は省略する。そして、図面で実施例の説明に関係ない部分は省略し、明細書全般にわたって類似の部分に対しては類似の図面符号を付けた。
【００２７】
明細書全般で、ある構成が他の構成と連結されていると言うとき、これは直接的に連結されている場合だけではなく、その中間に他の構成を挟んで連結されている場合も含む。また、ある構成が他の構成を含むというとき、特に反対の記載がない限り、さらに他の構成を除くものではなくて他の構成をさらに含むこともできることを意味する。
【００２８】
以下、添付図面に基づいて実施例を詳細に説明する。
【００２９】
図１〜図３は一実施例による仮想貨幣取引システムの構成を示す図である。
【００３０】
因みに、仮想貨幣とはコンピュータなどに情報形態として残って実物なしにサイバー上で取引される電子マネーの一種で、暗号貨幣ともいう。
【００３１】
仮想貨幣取引システム（説明の便宜上、以下では取引システムという）１００は、ユーザーから仮想貨幣の取引（例えば、仮想貨幣の売渡し、仮想貨幣の買受など）を要請されれば、前記取引を注文と認識し、注文を処理して取引が完了するようにする。
【００３２】
図１を参照すると、一実施例による取引システム１００はマッチングサーバー１２０を含む。
【００３３】
また、一実施例によるアドミッションサーバー（ａｄｍｉｓｓｉｏｎ  ｓｅｒｖｅｒ）１１０、コミットサーバー１３０、キャッシュサーバー１４０及びデータベース１５０を含むことができる。
【００３４】
一実施例によるアドミッションサーバー１１０は、取引システム１００の外部システム（図示せず）と通信して外部システム（図示せず）からユーザーの仮想貨幣売渡し要請又は買受要請を受ける。
【００３５】
アドミッションサーバー１１０は、外部システムから受信した前記売渡し／買受の要請を‘注文’として処理することができる。例えば、アドミッションサーバー１１０は、１個のビットコインを１００ウォンの価格で買収することを要請する注文を獲得することができる。ここで、注文は他の注文と区別可能な識別子を有し、前記識別子は各注文を唯一に認識することができるようにする。
【００３６】
ここで、アドミッションサーバー１１０は注文の種類を区別することができる。注文は、例えば、決まった金額のみで買受又は売渡しするようにする‘指定価取引’、要請された時点に市場で取引が締結されている金額で買受又は売渡しするようにする‘市場価取引’、及び特定の条件が満たされるとき又は特定の条件が満たされるまでだけ買受／売渡しするようにする‘ストップ取引’があり得る。アドミッションサーバー１１０は、注文の種類を区別し、要請された注文の少なくとも一部が締結されるようにすることができる。
【００３７】
アドミッションサーバー１１０は、獲得された注文の種類を区別し、注文が‘指定価取引’又は‘市場価取引’と判断されれば、前記注文をマッチングサーバー１２０に伝達することができる。また、注文が‘ストップ取引’と判断されれば、後述するストップオーダーサーバー１６０に前記注文を伝達することができる。ここで、‘ストップ取引’はストップオーダーサーバー１６０を経て‘指定価取引’又は‘市場価取引’として再獲得されることができ、再獲得された注文をマッチングサーバー１２０に伝達することができる。
【００３８】
アドミッションサーバー１１０は、注文を獲得すれば、キャッシュサーバー１４０に要請してユーザーデータを獲得することができる。
【００３９】
ここで、ユーザーデータは仮想貨幣の取引に必要な情報としてユーザーについての諸般情報を含み、例えば、ユーザーの残高についての情報などを含むことができる。また、例えば、ユーザーデータは、要請された注文を記録するか注文処理完了による注文削除を記録するオーダーブック（ｏｒｄｅｒ  ｂｏｏｋ）などを含むことができる。
【００４０】
ユーザーデータの獲得のために、一実施例によれば、アドミッションサーバー１１０はユーザーデータに対してキャッシュサーバー１４０にリース（ｌｅａｓｅ）要請することができるが、ユーザーデータを獲得するための方法は上述した例に制限されるものではなく、例えばアドミッションサーバー１１０はユーザーデータに対してロック（ｌｏｃｋ）要請をすることができる。
【００４１】
前記ユーザーデータを獲得したアドミッションサーバー１１０は、ユーザーデータを参照して、注文を要請したユーザーが前記注文を処理するための残高を持っているかを確認することができる。
【００４２】
そして、残高があると判断されれば、アドミッションサーバー１１０は、リース要請したデータをキャッシュサーバー１４０に返還しながら注文についての情報もともに伝達することができる。以下でより詳細に敍述するキャッシュサーバー１４０は、前記注文情報を獲得するとともに、データベース１５０に記憶されたユーザーのオーダーブックに注文を記録することができる。また、アドミッションサーバー１１０は、注文情報をキャッシュサーバー１４０に伝達しながら自分の識別子（例えば、サーバーＩＤ）もともに伝達してサーバーの識別子がデータベース１５０に記憶されるようにすることができる。
【００４３】
そして、アドミッションサーバー１１０は、外部システム（図示せず）に注文に対する結果値を伝達することができる。
【００４４】
また、アドミッションサーバー１１０は、注文をマッチングサーバー１２０にキューイング（ｑｕｅｕｉｎｇ）することができる。
【００４５】
上述したアドミッションサーバー１１０は一つ以上のインスタンス（ｉｎｓｔａｎｃｅ）で具現することができ、インスタンスを増加させながらスケールアウト（ｓｃａｌｅ−ｏｕｔ）することができる。
【００４６】
一実施例によるマッチングサーバー１２０は、キューイングされた注文をマッチングして取引対を生成する。
【００４７】
すなわち、マッチングサーバー１２０は、アドミッションサーバー１１０から注文を獲得することができ、獲得された注文を互いにマッチングし、取引が締結できると判断されれば、締結可能な注文対を取引対としてコミットサーバー１３０に伝達することができる。後述するコミットサーバー１３０は取引対についての情報をデータベース１５０に記録することができる。これにより、マッチングサーバー１２０が直接締結される取引対を処理するためにデータベース１５０にアクセスしなくても良く、これはマッチングサーバー１２０で発生し得るＩ／Ｏ瓶首効果を最小化する。
【００４８】
マッチングサーバー１２０は、取引対を生成すれば、前記取引対に含まれた注文をキューから削除することができる。
【００４９】
また、マッチングサーバー１２０は、取引対が締結されたことについての情報である締結情報をストップオーダーサーバー１６０に伝達することができる。ここで、締結情報はコミットサーバー１３０から受信でき、コミットサーバー１３０はマッチングサーバー１２０から伝達された締結要請に応答して締結情報をマッチングサーバー１２０に伝達することができる。
【００５０】
一方、マッチングサーバー１２０は、アドミッションサーバー１１０に障害があることを感知することができ、アドミッションサーバー１１０に障害があると判断すれば、データベース１５０のオーダーブックでアドミッションサーバー１１０のサーバー識別子を有する注文のうち自分が知っていない注文をアドミッションサーバー１１０が伝達したもののように処理するためにキューイングさせることができる。
【００５１】
また、マッチングサーバー１２０は、コミットサーバー１３０に障害があることを感知することができ、コミットサーバー１３０に障害があると判断すれば、コミットサーバー１３０から承認を受けることができなかった注文に対してデータベース１５０上のオーダーブックとトランザクション履歴を参考して、データベース１５０上に処理が完了したかを判断し、完了していなければ他のコミットサーバーに前記注文を処理するように要請することができる。
【００５２】
上述したマッチングサーバー１２０は一つ以上のインスタンスで具現されることができ、一つ以上のインスタンスの中で一つのインスタンスをマスター（ｍａｓｔｅｒ）に選定し、アドミッションサーバー１１０から注文をキューイングされ、コミットサーバー１３０と通信しながら注文を処理するようにすることができる。
【００５３】
ここで、インスタンスが複数であれば、前記複数のインスタンスは物理的に区分されたサーバーごとに組み込まれるか一つの物理的サーバーに組み込まれることができる。したがって、インスタンスがマスターインスタンスに選定されれば、前記インスタンスに対応する物理的なサーバーがマッチングサーバーとして動作し、前記物理的なサーバーは障害が発生したサーバーと異なるか同じサーバーであり得る。好ましくは、障害に柔軟に対応するために、インスタンス別に異なる物理サーバーに位置することができる。
【００５４】
一方、マスターに選定されたインスタンス以外のインスタンスはスレーブ（ｓｌａｖｅ）に設定することができる。ここで、マスターインスタンスに障害が生じてマッチングサーバー１２０として動作することができなければ、スレーブインスタンスの一つがマスターインスタンスになることができる。仮想貨幣取引の特性上、取引が順次締結されることを考慮すれば、一つのマッチングサーバーのみ動作しなければならないが、マッチングサーバーに発生し得る障害に対する対処のために複数のインスタンスの中で一つのインスタンスのみがマッチングサーバーとして動作するようにすることができる。
【００５５】
ここで、一つ以上のインスタンスの中でマスターインスタンスを選定する方法は多様であり得る。
【００５６】
一実施例によれば、スレーブインスタンスの中でランダムに選択されたスレーブインスタンスがマスターインスタンスになることができる。
【００５７】
また、他の実施例によれば、スレーブインスタンスの中で一番先にマッチングサーバーとして登録されたスレーブインスタンスがマスターインスタンスになることができる。
【００５８】
因みに、図３に示したように、取引システム１００はコーディネーション装置１７０をさらに含むことができる。コーディネーション装置１７０は、分散型構成サービス、同期化サービス及びネーミングレジストリ（ｎａｍｉｎｇ  ｒｅｇｉｓｔｒｙ）の少なくとも一つを提供し、取引システムを構成するサーバー間の情報共有、サーバーの状態チェック又はサーバー間の同期化を遂行することができる。したがって、システムで新しく登録されようとするサーバーはコーディネーション装置１７０が感知することができ、コーディネーション装置（170）はサーバーを登録することができる。このようなコーディネーション装置（170）は、例えばアパッチズーキーパー（ａｐａｃｈｅ  ｚｏｏｋｅｅｐｅｒ）で具現可能であり、あるいはアパッチズーキーパーと置換可能な任意のソリューションでも具現可能である。
【００５９】
したがって、例えば、スレーブインスタンスの中で先にコーディネーション装置（170）にマッチングサーバーとして登録したインスタンスがマスターインスタンスになることができる。
【００６０】
上述した例によってマスターインスタンスが変更されれば、新しくマスターになるマッチングサーバーはコミットサーバー１３０に直前のマスターインスタンスから締結要請を受けたが締結できなかった状態の取引対があれば、前記取引対を締結して応答することを要請することができる。前記要請に応じてコミットサーバー１３０は締結されなかった取引対を締結して新しいマスターインスタンスに応答することができる。その後、新しいマスターインスタンスはデータベース１５０上のオーダーブックに記録された注文を参照して、以前マスターインスタンスが処理することができなかった注文を復旧することができる。復旧しているうちに新しいマスターインスタンスはアドミッションサーバー１１０から新しい注文を受信することができ、新しい注文はペンディングされていて、処理することができなかった注文が復旧完了した後、復旧した注文と重複しなければ、キューイングされることができる。
【００６１】
一方、一実施例によるコミットサーバー１３０は、マッチングサーバー１２０から獲得された取引対に対して締結処理を行う。
【００６２】
すなわち、コミットサーバー１３０は、マッチングサーバー１２０から取引対を受信して締結処理しながら、締結結果によって、更新されたデータをキャッシュサーバー１４０を介してデータベース１５０に記録することができる。
【００６３】
コミットサーバー１３０は、取引対締結のためのユーザーデータに対し、キャッシュサーバー１４０にリース要請することによって獲得することができる。獲得したユーザーデータを用いて、コミットサーバー１３０は取引対に含まれた注文に対応するユーザーが前記注文を処理するための残高を持っているかを確認することができる。このように処理することにより、アドミッションサーバー１１０の確認後に変更されたかも知れないユーザーの残高を再び確認することができる。
【００６４】
そして、残高があると判断されれば、コミットサーバー１３０は、リース要請したデータをキャッシュサーバー１４０に返還しながら、キャッシュサーバー１４０を介してデータベース１５０に記憶されたユーザーのオーダーブックに記録された注文情報を削除し、残高についての情報を変更することができる。
【００６５】
コミットサーバー１３０は、締結処理が成功すれば、締結情報をマッチングサーバー１２０に伝達することができる。
【００６６】
コミットサーバー１３０は、マッチングサーバー１２０との通信を介して、取引対の締結要請を受信するか締結処理の成功を承認しながら応答することができ、よってマッチングサーバー１２０がコミットサーバー１３０の障害を感知することができる。例えば、マッチングサーバー１２０が取引対についての締結要請を伝達したが前記要請に対する承認を受けることができなければ、コミットサーバー１３０に障害が発生したことを感知することができる。コミットサーバー１３０に障害が発生することを感知すれば、マッチングサーバー１２０は承認を受けることができなかった注文に対し、データベース１５０上のオーダーブックとトランザクション履歴を参考してデータベース１５０上に処理が完了したかを判断し、完了しなかったら、他のコミットサーバーに前記注文の処理を要請することができる。
【００６７】
コミットサーバー１３０は、マッチングサーバー１２０と非同期方式で通信することができ、また一つ以上のインスタンスで具現できるので、インスタンスを増加させながらスケールアウト（ｓｃａｌｅ−ｏｕｔ）することができる。
【００６８】
一方、一実施例によるキャッシュサーバー（ｃａｃｈｅ  ｓｅｒｖｅｒ）１４０は、アドミッションサーバー１１０、マッチングサーバー１２０、コミットサーバー１３０又はストップオーダーサーバー１６０とデータベース１５０との間に位置して、アドミッションサーバー１１０、マッチングサーバー１２０、コミットサーバー１３０又はストップオーダーサーバー１６０がデータベース１５０に直接アクセスしないようにする。
【００６９】
キャッシュサーバー１４０は、ユーザーデータの要請を受けたとき、前記ユーザーデータをキャッシングしていなければ、前記ユーザーデータをデータベース１５０から獲得してキャッシングすることができる。
【００７０】
キャッシュサーバー１４０は、アドミッションサーバー１１０又はコミットサーバー１３０がオーダーブックに記録／削除の要請をするか、あるいはユーザーデータを更新するか要請するとき、キャッシングされたデータを更新するかデータベース１５０のデータを更新することができる。
【００７１】
キャッシュサーバー１４０は、データベース１５０への反映が完了したデータに対してはトランザクション履歴に追加することによって管理することができ、好ましくはデータ更新とアトミック（ａｔｏｍｉｃ）にトランザクション履歴を管理することができる。
【００７２】
キャッシュサーバー１４０はデータに対してリース要請を受けることができる。例えば、アドミッションサーバー１１０、コミットサーバー１３０又はストップオーダーサーバー１６０からリース要請を受けることができる。ただ、キャッシュサーバー１４０はデータに対してロック要請を受けることもできる。
【００７３】
キャッシュサーバー１４０は、リース要請されたデータを管理することができる。したがって、キャッシュサーバー１４０に障害が発生するとき、アドミッションサーバー１１０は注文の識別子に対応するデータがオーダーブックにあるかを確認し、コミットサーバー１３０はトランザクション履歴を参照して注文が存在するかを確認する。確認の後、アドミッションサーバー１１０又はコミットサーバー１３０はまたリース要請することにより、障害が復旧されたキャッシュサーバー１４０が前記要請に応じて動作することができる。
【００７４】
キャッシュサーバー１４０は、Ｉ／Ｏによる瓶首効果を無くすために、シャーディング（ｓｈａｒｄｉｎｇ）を支援することができる。
【００７５】
また、キャッシュサーバー１４０は、更新されるデータの遺失を防止するために、ライトスルー（ｗｒｉｔｅ−ｔｈｒｏｕｇｈ）方式で動作することができる。
【００７６】
一実施例によるデータベース１５０は取引システム１００の動作に必要なデータを記憶する。
【００７７】
例えば、データベース１５０はユーザーデータを記憶することができる。例えば、ユーザーの残高についての情報、ユーザーのオーダーブックなどを記憶することができる。
【００７８】
一方、図２を参照すると、一実施例による取引システム１００は、追加的にストップオーダーサーバー１６０をさらに含むことができる。
【００７９】
一実施例によるストップオーダーサーバー１６０は‘ストップ取引’の注文を受けたときに動作することができる。
【００８０】
アドミッションサーバー１１０の獲得した注文が‘ストップ取引’の場合、ストップオーダーサーバー１６０はアドミッションサーバー１１０から注文を受信することができる。
【００８１】
ストップオーダーサーバー１６０は注文を記憶していながら前記注文をデータベースに記録することができる。
【００８２】
また、ストップオーダーサーバー１６０は、注文が取引に処理できる条件が満たされれば、前記注文を‘指定価取引’注文又は‘市場価取引’注文に変更してアドミッションサーバー１１０に伝達することができる。
【００８３】
すなわち、ストップオーダーサーバー１６０は、注文を獲得すれば、注文にマッチングするユーザーのユーザーデータをキャッシュサーバー１４０にリース要請することによって獲得することができ、獲得したユーザーデータを用いて、注文に対応するユーザーが前記注文を処理するための残高を持っているかを確認することができる。残高があると判断されれば、ストップオーダーサーバー１６０は注文の処理が可能であると判断することができ、アドミッションサーバー１１０に応答を送り、リース要請したデータをキャッシュサーバー１４０に返還しながら、データベース１５０に記憶されたユーザーのオーダーブックに注文情報を記録することができる。また、ストップオーダーサーバー１６０は、マッチングサーバー１２０から締結情報を獲得して特定条件が満たされたかを判断することができる。特定の条件が満たされたと判断されれば、ストップオーダーサーバー１６０は‘ストップ取引’の注文を‘指定価取引’又は‘市場価取引’の注文に変更してアドミッションサーバー１１０に伝達することができる。
【００８４】
上述したストップオーダーサーバー１６０は一つ以上のインスタンスで具現されることができ、一つ以上のインスタンスの中で一つのインスタンスをマスターに選定し、アドミッションサーバー１１０から注文を受けて処理できるようにすることができる。
【００８５】
したがって、マスターに選定されることができなかったインスタンスはスレーブに設定される。このとき、マスターインスタンスに障害が生じてストップオーダーサーバー１６０として動作することができなければ、スレーブインスタンスの中で一つがマスターインスタンスになることができる。
【００８６】
ここで、一つ以上のインスタンスの中でマスターインスタンスを選定する方法は多様であり得るが、スレーブインスタンスの中でランダムに選択されたスレーブインスタンスがマスターインスタンスになるか、スレーブインスタンスの中で一番先にストップオーダーサーバーとして登録されたインスタンスがマスターインスタンスになることができる。
【００８７】
上述したアドミッションサーバー１１０、マッチングサーバー１２０、コミットサーバー１３０、キャッシュサーバー１４０及びストップオーダーサーバー１６０のそれぞれは制御部（図示せず）、通信部（図示せず）及びメモリ（図示せず）を含むことができる。
【００８８】
制御部（図示せず）は装置の全体的な動作を制御し、ＣＰＵなどのプロセッサを含むことができる。例えば、制御部（図示せず）は、メモリ（図示せず）に記憶されたプログラムを実行させるか、メモリ（図示せず）に記憶されたデータを読み取るか、新しいデータをメモリに記憶することもできる。
【００８９】
通信部（図示せず）は他のデバイス又はネットワークと有無線通信を行うことができる。このために、通信部（図示せず）は多様な有無線通信方法の少なくとも一つを支援する通信モジュールを含むことができる。例えば、通信モジュールはチップセット（ｃｈｉｐｓｅｔ）の形態に具現できる。
【００９０】
通信部（図示せず）が支援する無線通信は、例えばＷｉ−Ｆｉ（Ｗｉｒｅｌｅｓｓ  Ｆｉｄｅｌｉｔｙ）、Ｗｉ−Ｆｉ  Ｄｉｒｅｃｔ、ブルートゥース(登録商標）（Ｂｌｕｅｔｏｏｔｈ(登録商標)）、ＵＷＢ（Ｕｌｔｒａ  Ｗｉｄｅ  Ｂａｎｄ）又はＮＦＣ（Ｎｅａｒ  Ｆｉｅｌｄ  Ｃｏｍｍｕｎｉｃａｔｉｏｎ）などであってもよい。また、通信部が支援する有線通信は、例えばＵＳＢ又はＨＤＭＩ(登録商標）（Ｈｉｇｈ  Ｄｅｆｉｎｉｔｉｏｎ  Ｍｕｌｔｉｍｅｄｉａ  Ｉｎｔｅｒｆａｃｅ）などであってもよい。
【００９１】
通信部（図示せず）は有無線通信方法によってＲＰＣ（ｒｅｍｏｔｅ  ｐｒｏｃｅｄｕｒｅ  ｃａｌｌ）通信することができ、ＲＰＣ情報はコーディネーション装置１７０に記憶できる。コーディネーション装置１７０は、新しいサーバーの登録時、ＲＰＣ情報を獲得してＲＰＣチャネルを生成することにより、システム内の他のサーバーが新しいサーバーの登録を認知するようにすることができ、ＲＰＣチャネルが切れることからサーバーに障害があることを判断するようにすることができる。
【００９２】
メモリ（図示せず）には、ファイル、アプリケーション及びプログラムなどの多様な種類のデータが組み込まれて記憶されることができる。制御部（図示せず）はメモリ（図示せず）に記憶されたデータに接近してこれを用いるか、あるいは新しいデータをメモリ（図示せず）に記憶することもできる。また、制御部（図示せず）はメモリ（図示せず）に組み込まれたプログラムを実行することもできる。例えば、メモリ（図示せず）には仮想貨幣取引方法を遂行するためのプログラムが組み込まれることができる。
【００９３】
一方、取引システム１００は、追加的に取引システム１００の動作をモニタリングすることができるダッシュボードサーバー（図示せず）をさらに含むことができる。
【００９４】
また、取引システム１００は、追加的に取引システム１００を管理する管理サーバー（図示せず）をさらに含むことができる。管理サーバー（図示せず）は、管理用ＡＰＩを処理することができ、例えば、取引所システムの動作を中止させるか、新しい貨幣の追加、既存貨幣の削除、交換可能対象貨幣の追加（ビットコインを購買しようとするとき、ビットコインを購買することができる貨幣の種類を追加すること）などの動作を遂行するとき、他のサーバーを制御することができる。ダッシュボードサーバー又は管理サーバーのそれぞれはシステムを構成する他のサーバーと通信することができる。
【００９５】
一方、図４〜図６は一実施例による仮想貨幣取引方法を説明するためのフローチャートである。
【００９６】
図４〜図６に示した実施例による取引方法は、図１〜図３に示した取引システム１００で時系列的に処理される段階を含む。よって、以下で省略した内容であると言っても、図１〜図３に示した取引システム１００について以上で記述した内容は図４〜図６に示した実施例による取引方法にも適用可能である。
【００９７】
図４に示したように、アドミッションサーバー１１０は、外部システム（図示せず）から注文を獲得することができ、前記注文の種類を区分することができる（Ｓ４０１）。注文の種類を区分したアドミッションサーバー１１０は、注文が‘市場価取引’又は‘指定価取引’であれば、前記注文のためのユーザーの残高程度を確認するために、キャッシュサーバー１４０にユーザーデータをリース要請することができる（Ｓ４０２）。ユーザーに残高があって注文が処理可能であることが確認されれば（Ｓ４０３）、アドミッションサーバー１１０はリース要請したデータをキャッシュサーバー１４０に返還しながら注文についての情報もともに伝達することができる（Ｓ４０４）。注文情報を受信したキャッシュサーバー１４０は自分がキャッシングしたユーザーデータを更新しながら、データベース１５０に記憶されたユーザーのオーダーブックに注文を記録することができる（Ｓ４０５）。その後、アドミッションサーバー１１０は外部システム（図示せず）に注文に対する結果値を伝達することができる（Ｓ４０６）。したがって、仮にアドミッションサーバー１１０に障害が発生すれば、外部システムは注文に対する結果値を獲得することができないので、外部システムはアドミッションサーバー１１０の障害発生を感知して注文を再要請することができる。
【００９８】
その後、アドミッションサーバー１１０は注文をマッチングサーバー１２０にキューイングすることができる（Ｓ４０７）。仮に、アドミッションサーバー１１０の障害が発生すれば、前記障害をマッチングサーバー１２０はＲＰＣで感知することができ、データベース１５０に記憶された注文情報を読んで来て注文が処理できるようにすることができる。
【００９９】
一方、マッチングサーバー１２０は、キューイングされた注文をマッチングして取引対を生成し（Ｓ４０８）、取引対をコミットサーバー１３０に伝達することができる（Ｓ４０９）。コミットサーバー１３０は、マッチングサーバー１２０から獲得した取引対に対して締結処理を遂行し、このためにキャッシュサーバー１４０にユーザーデータをリース要請することができる（Ｓ４１０）。コミットサーバー（１３０）は、取引対処理のための残高があると判断されれば（Ｓ４１１）、リース要請したデータをキャッシュサーバー１４０に返還しながら、キャッシュサーバー１４０にキャッシングされた注文情報を削除し、残高についての情報を変更することによってユーザーデータを更新することができる（Ｓ４１２）。そして、キャッシュサーバー１４０もデータベース１５０に記憶されたユーザーのオーダーブックに記録された注文情報を削除してユーザーデータを更新し、トランザクション履歴に取引対処理についての情報を追加することができる（Ｓ４１３）。
【０１００】
一方、段階Ｓ４０１で、アドミッションサーバー１１０が外部システム（図示せず）から注文を獲得したとき、前記注文が‘ストップ取引’であれば、図５で各段階を遂行した後、図４の段階Ｓ４０２に進むことができる。
【０１０１】
すなわち、アドミッションサーバー１１０はストップ取引である注文をストップオーダーサーバー１６０に伝達することができる（Ｓ５０１）。注文を受信したストップオーダーサーバー１６０は、前記注文のためのユーザーの残高程度を確認するために、キャッシュサーバー１４０にユーザーデータをリース要請することができる（Ｓ５０２）。ユーザーに残高があって注文が処理可能であることが確認されれば（Ｓ５０３）、ストップオーダーサーバー１６０は、キャッシュサーバー１４０を介して（Ｓ５０４）、データベース１５０に注文を記録することができる（Ｓ５０５）。そして、ストップオーダーサーバー１６０はアドミッションサーバー１１０に注文要請に対する応答を伝達することができる（Ｓ５０６）。
【０１０２】
その後、ストップオーダーサーバー１６０はマッチングサーバー１２０から締結情報を実時間で受けることができ（Ｓ５０７）、締結情報に基づいてストップ取引の特定の条件が満たされることを判断すれば（Ｓ５０８）、ストップ取引を指定価取引又は市場価取引の少なくとも一つに変換してアドミッションサーバー１１０に伝達することができる（Ｓ５０９）。前記変換された注文はアドミッションサーバー１１０に伝達され、取引システム１００は段階４０２〜段階４１３の各段階を実行することができる。
【０１０３】
一方、取引システム１００はコーディネーション装置１７０をさらに含み、マッチングサーバー１２０の障害を感知すれば、コーディネーション装置１７０にとって新しいマッチングサーバー１２０が動作するようにして、順次処理されるべき仮想貨幣取引を正確に処理するようにする。
【０１０４】
すなわち、図６に示したように、取引システム１００は一つ以上のスレーブインスタンスを浮かべることができる。したがって、取引システム１００がマッチングサーバーの障害を感知すれば（Ｓ６１０）、一つ以上のスレーブインスタンスの中で一つを選択することができる（Ｓ６２０）。このとき、選択されるインスタンスは、一番先に登録を要請したインスタンスであるか、ランダムに選択されたインスタンスであり得る。取引システム１００は、選択されたインスタンスをマスターインスタンスにして新しいマッチングサーバーとして動作するようにすることができ、障害が発生した既存のマスターサーバーは動作を中断させることができる（Ｓ６３０）。
【０１０５】
上述したように、新しいマッチングサーバーが取引システム１００に登録されれば、新規に登録されたマッチングサーバーは、障害が発生した障害マッチングサーバーによって過去に要請された締結要請に対する応答をコミットサーバー１３０から獲得することにより、要請された締結要請の処理が完了したことを確認することができる。その後、新規のマッチングサーバーは、障害マッチングサーバーがキューイング又は取引対を生成したが処理することができなかった注文をデータベース１５０から復旧することができる。コミットサーバー１３０から締結要請に対する応答を受信するかデータベース１５０から注文を復旧するうち、新規のマッチングサーバーはアドミッションサーバー１１０からの注文をペンディングし、障害マッチングサーバーによって処理することができなかった注文をデータベースから復旧することを完了すれば、ペンディングされた注文をキューイングすることができる。
【０１０６】
以上の実施例で使われる‘〜部’という用語はソフトウェア又はＦＰＧＡ（ｆｉｅｌｄ  ｐｒｏｇｒａｍｍａｂｌｅ  ｇａｔｅ  ａｒｒａｙ）又はＡＳＩＣのようなハードウェア構成要素を意味し、‘〜部’はある役割をする。しかし、‘〜部’はソフトウェア又はハードウェアに限定される意味ではない。‘〜部’はアドレス可能な記憶媒体にあるように構成されることもでき、一つ又はそれ以上のプロセッサを再生させるように構成されることもできる。よって、一例として、‘〜部’はソフトウェア構成要素、オブジェクト指向ソフトウェア構成要素、クラス構成要素及びタスク構成要素のような構成要素と、プロセス、関数、属性、プロシージャ、サブルーチン、プログラム特許コードのセグメント、ドライバー、ファームウエア、マイクロコード、回路、データ、データベース、データ構造、テーブル、アレイ、及び変数を含む。
【０１０７】
構成要素及び‘〜部’内で提供される機能はより小さな数の構成要素及び‘〜部’と結合するか追加的な構成要素及び‘〜部’から分離されることができる。
【０１０８】
それだけでなく、構成要素及び’〜部’はデバイス又は保安マルチメディアカード内の一つ又はそれ以上のＣＰＵを再生させるように具現されることもできる。
【０１０９】
図４〜図６に基づいて説明した実施例による取引方法は、コンピュータによって実行可能な命令語及びデータを記憶する、コンピュータ可読の媒体の形態にも具現されることができる。ここで、命令語及びデータはプログラムコードの形態として記憶されることができ、プロセッサによって実行されたとき、所定のプログラムモジュールを生成して所定の動作を行うことができる。また、コンピュータ可読の媒体はコンピュータによってアクセス可能な任意の可用媒体であってもよく、揮発性及び非揮発性媒体、分離型及び非分離型媒体のいずれも含む。また、コンピュータ可読の媒体はコンピュータ記録媒体であってもよい。コンピュータ記録媒体はコンピュータ可読の命令語、データ構造、プログラムモジュール又はその他のデータのような情報の記憶のための任意の方法又は技術によって具現された揮発性及び非揮発性、分離型及び非分離型媒体のいずれも含むことができる。例えば、コンピュータ記録媒体は、ＨＤＤ及びＳＳＤなどのマグネチック記憶媒体、ＣＤ、ＤＶＤ及びブルーレイディスクなどの光学的記録媒体、又はネットワークを介して接近可能なサーバーに含まれるメモリであってもよい。
【０１１０】
また、図４〜図６に基づいて説明した実施例による取引方法はコンピュータによって実行可能な命令語を含むコンピュータプログラム（又はコンピュータプログラム商品）で具現されることもできる。コンピュータプログラムはプロセッサによって処理されるプログラミング可能な機械命令語を含み、高レベルプログラミング言語（Ｈｉｇｈ−ｌｅｖｅｌ  Ｐｒｏｇｒａｍｍｉｎｇ  Ｌａｎｇｕａｇｅ）、オブジェクト指向プログラミング言語（Ｏｂｊｅｃｔ−ｏｒｉｅｎｔｅｄ  Ｐｒｏｇｒａｍｍｉｎｇ  Ｌａｎｇｕａｇｅ）、アセンブリー言語又は機械言語などで具現されることができる。また、コンピュータプログラムは類型のコンピュータ判読可能記録媒体（例えば、メモリ、ハードディスク、磁気／光学媒体又はＳＳＤ（Ｓｏｌｉｄ−Ｓｔａｔｅ  Ｄｒｉｖｅ）など）に記録できる。
【０１１１】
したがって、図４〜図６に基づいて説明した実施例による取引方法は上述したようなコンピュータプログラムがコンピュータ装置によって実行されることによって具現されることができる。コンピュータ装置は、プロセッサと、メモリと、記憶装置と、メモリ及び高速拡張ポートに接続している高速インターフェースと、低速バスと記憶装置に接続している低速インターフェースの少なくとも一部を含むことができる。このような成分のそれぞれは多様なバスを用いて互いに接続されており、共通マザーボードに搭載されるか他の適切な方式で装着できる。
【０１１２】
ここで、プロセッサはコンピュータ装置内で命令語を処理することができる。このような命令語としては、例えば高速インターフェースに接続されたディスプレイのように外部入力及び出力装置上にＧＵＩ（Ｇｒａｐｈｉｃ  Ｕｓｅｒ  Ｉｎｔｅｒｆａｃｅ）を提供するためのグラフィック情報を表示するためにメモリ又は記憶装置に記憶された命令語を有することができる。他の実施例として、多数のプロセッサ及び／又は多数のバスが適切に多数のメモリ及びメモリ形態と一緒に用いられることができる。また、プロセッサは独立的な多数のアナログ及び／又はデジタルプロセッサを含むチップからなるチップセットで具現されることができる。
【０１１３】
また、メモリはコンピュータ装置内に情報を記憶する。一例として、メモリは揮発性メモリユニット又はそれらの集合で構成されることができる。他の例として、メモリは不揮発性メモリユニット又はそれらの集合で構成されることができる。また、メモリは、例えば磁気又は光ディスクのような他の形態のコンピュータ可読の媒体であってもよい。
【０１１４】
そして、記憶装置はコンピュータ装置に大容量の記憶空間を提供することができる。記憶装置はコンピュータ可読の媒体であるかこのような媒体を含む構成であってもよく、例えばＳＡＮ（Ｓｔｏｒａｇｅ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）内の装置又は他の構成も含むことができ、フロッピーディスク装置、ハードディスク装置、光ディスク装置、又はテープ装置、フラッシュメモリー、それと類似した他の半導体メモリ装置又は装置アレイであってもよい。
【０１１５】
上述した実施例は例示のためのものであり、上述した実施例が属する技術分野の通常の知識を有する者は上述した実施例が有する技術的思想又は必須な特徴を変更しなくて他の具体的な形態に易しく変形可能であることを理解することができるであろう。したがって、上述した実施例は全ての面で例示的なもので、限定的なものではないことを理解しなければならない。例えば、単一型として説明されている各構成要素は分散されて実施されることもでき、同様に分散されたものとして説明されている構成要素も結合された形態に実施されることができる。
【０１１６】
本明細書によって保護を受けようとする範囲は前記詳細な説明よりは後述する特許請求範囲によって決定され、特許請求範囲の意味及び範囲とその均等な概念から導出される全ての変更又は変形の形態を含むものに解釈されなければならない。
【符号の説明】
【０１１７】
１００  仮想貨幣取引システム
１１０  アドミッションサーバー
１２０  マッチングサーバー
１３０  コミットサーバー
１４０  キャッシュサーバー
１５０  データベース
１６０  ストップオーダーサーバー
１７０  コーディネーション装置
【図１】
2020047274.tif 000003
【図２】
2020047274.tif 000004
【図３】
2020047274.tif 000005
【図４】
2020047274.tif 000006
【図５】
2020047274.tif 000007
【図６】
2020047274.tif 000008