JP2011501322A - オンライン連帯保証を処理するための方法およびシステム - Google Patents

Abstract

オンライン連帯保証を処理するための方法およびシステムが開示される。サーバは、ユーザから申請を受信した後に、選択のために、ユーザに様々な種類の連帯保証グルーピングを提供する。サーバは、ユーザの選択に従って、固有のＩＤを有する連帯保証グループを生成し、その連帯保証グループの情報をデータパケットに編成し、そのデータパケットを、承認されるために銀行システムに送信する。この方法は、潜在的に、連帯保証グルーピングの成功率を上げ、地理的な制限を取り除く。この方法は、インターネットを介して、様々な地理的場所の企業がオンライン連帯保証に参加することを可能にする。また、この方法は、完全にオンラインのアラートメカニズムを確立し、融資のリスクコントロールを実現して事業クレジットシステムを改善する。

Description

本出願は、２００７年１０月２５日に出願され「ＭＥＴＨＯＤ ＡＮＤ ＳＹＳＴＥＭ ＦＯＲ ＰＲＯＣＥＳＳＩＮＧ ＯＮＬＩＮＥ ＪＯＩＮＴ ＧＵＡＲＡＮＴＥＥ」と題する中国特許出願第２００７１０１６３４４８．５号に基づく優先権を主張し、当該中国出願は、参照することによりその全体を本明細書に組み込まれる。

本出願は、電子商取引の分野に関し、より詳細には、オンライン連帯保証を処理する方法およびシステムに関する。

中小企業の最も大きな障害の１つは、資金が不足していることと、銀行から融資を受けるための保証人を見つけるのが難しいことである。連帯保証は、この問題を解決するための試みである。従来の連帯保証とは、３つ以上の中小企業が、自発的に保証体（すなわち、連帯保証グループ）として連帯し、企業間の内的な通信および調整を通じて、連帯的に銀行から融資を受けることを示す。連帯保証グループの１つのメンバーが、銀行からの特定のクレジットを申請する際に、連帯保証グループの他のメンバーが、申請者の銀行のクレジットに対して連帯保証を提供する。また、融資申請者は、無限個人無限責任を負う。従来の連帯保証グループの開始および形成は、完全にオフラインである。従来の連帯保証のリスクコントロールは、以下のメカニズムを有する。すなわち、（１）連帯保証グループが、任意のその他の機関を含むことなく、直接、銀行と通信すること、および（２）モニタリングは、貸出担当者によって実行され、担当者の訪問に依存する。現在では、企業の貸付状況の情報を、複数の銀行間で交換および取得することができる。たとえば、銀行は、企業の融資カードを通じて、企業の融資記録を問い合わせることができる。しかしながら、従来の連帯保証モデルでは、企業の融資記録およびクレジット記録は、銀行間通信にのみ制限されている。

従来の連帯保証のいくつかの欠点がある。

（１）連帯保証グルーピングのうち１つの種類のみが利用できる。従来の連帯保証は、完全にオフラインであり、実質的には地理的場所が同じまたは近い場合に限られる。この方法は、銀行に依存して企業間のマッチングを行い、したがってグルーピングの成功率を非常に少なくし、成功数が制限される。

（２）不完全なモニタリングメカニズム。従来の方法は、モニタリングメカニズムのうち１つの種類のみ、つまり銀行のオンサイト検査の手段によるモニタリングを使用し、その結果、リスクコントロールメカニズムが不完全になる。

（３）銀行間でのみ融資記録が使用され、そのような記録には、企業のクレジット設定に対する明確な恩恵が全くない。

オンライン連帯保証を処理するための方法およびシステムが開示され、これらの方法およびシステムにより、ユーザは、連帯保証グループを形成するための様々な方法からオンラインを選択できるようになる。この方法は、モニタリングシステムの完全なセットを構築することを目的とする。企業による融資申請および融資活用の間、開示されたシステムは、インターネットを介して、その企業の挙動を監視し、アラートを出すことができる。

本開示の１つの態様は、オンライン連帯保証を処理するための方法である。サーバがユーザから申請を受信した後に、様々なユーザ選択可能な種類の連帯保証グルーピングを提供する。ユーザによってなされた選択にしたがって、サーバは、固有のＩＤを有する連帯保証グループを生成し、連帯保証グループの情報をデータパケットに編成し、そのデータパケットを、さらなる処理のために、銀行システムに送信する。

一実施形態では、サーバは、ユーザから申請を受信した後に、ユーザが申請の要件を満たすかどうかを判定する。ユーザが要件を満たす場合には、サーバは、様々な種類の連帯保証グルーピングを、選択のために、ユーザに提供する。ユーザが要件を満たさない場合には、サーバは、ユーザ申請の情報をデータベースに保存する。

別の実施形態では、サーバが、連帯保証グループの情報をデータパケットに編成して、そのデータパケットを銀行システムに送信した後に、サーバは、銀行システムから、ユーザ申請が認められるかどうかを示すフィードバックを受信し、そのフィードバックをユーザに通知する。

一実施形態では、サーバは、ユーザの選択にしたがって、固有の連帯保証ＩＤを生成し、連帯保証グループの情報をユーザのメンバー情報と結び付ける。このメンバー情報に基づいて、サーバは、ユーザがグルーピング要件を満たすかどうかを判定する。要件を満たす場合、サーバは、連帯保証グループを生成する。

連帯保証グルーピングの種類は、自動マッチング、フラタニティ、およびオンライン開始／参加のいずれか１つまたはそれらの組合せを含むことができる。連帯保証グルーピングの自動マッチングの一例は、最初に申請の情報を記入するユーザの予め設定された基準に基づいて行われる。サーバは、ユーザに、申請の事業情報に関連する他のユーザを自動的に推薦し、ユーザのデータを相互に提供し、ユーザ間の連帯保証グループを形成するように提案する。

フラタニティグルーピングの一例は、複数のユーザに、フラタニティを形成させ、連帯保証グループの開始を同意させる。フラタニティのユーザの１つが、連帯保証グループを生成し、フラタニティのそれ以外のユーザを加えて、連帯して融資事業に申請する。

連帯保証グルーピングのオンライン開始／参加の一例は、事業ニーズを有するユーザに、グルーピング要求をサーバ上で発行させ、ユーザ自身の資格およびグルーピング基準を示させ、資格のあるユーザを待つおよび／または加えて前記連帯保証グループを形成させる。

本開示の別の態様は、処理モジュールと、グルーピングモジュールと、送信モジュールとを有するサーバである。処理モジュールは、ユーザから申請を受信し、ユーザ選択のために様々な種類の連帯保証グルーピングを提供し、ユーザ選択をグルーピングモジュールに送信するように適合される。グルーピングモジュールは、ユーザ選択にしたがって、固有のＩＤを有する連帯保証グループ生成し、連帯保証グループの情報を送信モジュールに送信するように適合される。送信モジュールは、連帯保証グループの情報をグルーピングモジュールから受信し、連帯保証の情報をデータパケットに編成し、そのデータパケットを送出するように適合される。

一実施形態では、サーバはさらに、ユーザの申請情報を受信し、ユーザが申請の要件を満たすかどうかを判定するように適合される判定モジュールを備える。ユーザが要件を満たす場合には、判定モジュールは、ユーザの申請情報を処理モジュールに送信する。要件を満たさない場合には、判定モジュールは、ユーザの申請情報を保存モジュールに送信する。

また、サーバは、ユーザが申請の要件を満たさない場合には、ユーザの申請情報を保存するように適合される保存モジュールを含むことができる。

サーバはさらに、受信モジュールと、通知モジュールとを有することができる。受信器モジュールは、ユーザの申請が承認されるかどうかを示すメッセージを受信し、そのメッセージを通知モジュールに送信するように適合される。通知モジュールは、メッセージをユーザに送信するように適合される。

既存の技術と比較すると、本明細書に開示された方法およびシステムは、いくつかの利点を有する。開示された方法を使用すると、連帯保証グルーピングの成功率を上げ、地理的な制限を取り除くことができる。インターネットを通じて、この方法は、様々な地理的場所の企業から連帯保証グループを形成することができるようにする。また、この方法は、オンラインのアラートメカニズムの完全なセットを設立し、それによって、融資のリスクコントロールをコンピュータ化し、事業のクレジットシステムを改善することができる。

この発明の概要は、以下の発明を実施するための形態にさらに記載される選択された概念を単純化された形式で紹介するために提供されるものである。この発明の概要は、特許請求された主題の重要な特徴または必須の特徴を識別することを意図するものでも、特許請求された主題の範囲を判定する際の一助として使用されることを意図するものでもない。

発明を実施するための形態は、添付の図面を参照して記載される。

本発明による、オンライン連帯保証を処理するための第１の例示的な方法のフローチャートである。 本発明による、オンライン連帯保証を処理するための第２の例示的な方法のフローチャートである。 サーバと銀行システムの間の例示的な情報交換のフローチャートである。 例示的なリスクコントロールプロセスのフローチャートである。 本発明による、オンライン連帯保証を処理するための第３の例示的な方法のフローチャートである。 本発明による、オンライン連帯保証を処理するための第４の例示的な方法のフローチャートである。 本発明による、オンライン連帯保証を処理するためのサーバの概略図である。 本開示の方法を実施するための例示的な環境を示す図である。

オンライン連帯保証は、中小企業のための融資保証の問題に対処するための、インターネット電子商取引申請に基づく新しい種類のファイナンシングリスクコントロール方法である。オンライン連帯保証は、ビジネスツービジネス（Ｂ２Ｂ）のインターネット電子商取引申請に基づいている。また、オンライン連帯保証は、インターネット電子商取引およびオフラインビジネスに関して生成される連帯保証グループの連帯保証によって裏書きされた融資契約であり、連帯保証グループの企業間でリスクコントロールを行う。連帯保証グループのメンバーは、銀行および電子商取引プラットフォームのリスクのモニタリングおよびコントロールを容認し、かつ、連帯保証の動態をインターネットに直接反映させることができるようにし、それにより、融資プロセス全体をコントロールできるようになる。

オンライン連帯保証を処理するための新しい方法およびシステムが、本明細書に開示される。この方法は、連帯保証グルーピングの真のユーザ選択可能な方法を提供し、サーバを使用して、連帯保証グループの形成（すなわち、グルーピング）および融資承認を含む、融資プロセス全体を集中的に管理する。また、参加企業の融資記録は、それらの企業のクレジット履歴に効率的に連結される。この方法およびシステムを、図面および以下の例示的な実施形態を使用して、さらに詳しく記載する。

図１は、本発明による、オンライン連帯保証を処理するための第１の例示的な方法のフローチャートである。この記述において、プロセスが記載される順序は限定的に解釈することを意図するものではなく、任意の数の記載されたプロセスブロックを任意の順番で組み合わせて、本方法または代替的な方法を実施することができる。

ブロックＳ１０１において、ユーザは、ネットワークを介してサーバにログオンし、そのサーバに、連帯保証グループを形成する、または連帯保証グループに参加するための申請または要求を提出する。

ブロックＳ１０２において、サーバは、ユーザの申請を受信した後に、ユーザが申請要件を満たすかどうかを判定する。ユーザが要件を満たす場合には、プロセスはブロックＳ１０３に進む。ユーザが要件を満たさない場合には、サーバは、ユーザの情報をデータベースに保存する。

ブロックＳ１０３において、サーバは、様々なユーザ選択可能な種類の連帯保証グルーピングを提供する。一実施形態では、サーバは、様々なユーザ選択可能な種類の連帯保証グルーピングを、ユーザ選択のために直接ユーザに提供する。

様々な種類の連帯保証グルーピングの例として、自動マッチング、フラタニティ、オンライン加入／参加、またはそれらの組合せが挙げられる。

ブロックＳ１０４において、ユーザによってなされた選択にしたがって、サーバは、固有のＩＤを有する連帯保証グループを生成する。

ブロックＳ１０５において、連帯保証グループを正常に生成した後、サーバは、連帯保証グループの情報をデータパケットに編成し、そのデータパケットをデータベースに保存し、さらなる処理のために、インターネットを介してデータパケットを銀行システムに送信する。

ブロックＳ１０６において、サーバは、銀行システムから、ユーザ申請が認められたかどうかを示すフィードバックを受信し、ユーザにそのフィードバックを知らせる。

本開示の方法は、サーバを介して銀行システムに提出される企業の融資申請を含む以下の例示的な実施形態を使用して、さらに詳細に記載される。示された諸実施形態において、方法がユーザとしての企業に適用されるので、用語「企業」および「ユーザ」およびそれらの複数形は、別段の記載がない限り、相互に交換可能に使用される。

図２は、本発明による、オンライン連帯保証を処理するための第２の例示的な方法のフローチャートである。第２の例示的な実施形態では、例示的な種類の連帯保証グルーピングとして自動マッチングを使用して、オンライン連帯保証を処理するための方法を図示する。以下の記載において、ブロックＳ２０１からブロックＳ２０７がグルーピングプロセスとして参照される。

ブロックＳ２０１において、企業（ユーザ）は、インターネットを介して、サーバにログオンする。

ブロックＳ２０２において、サーバは、企業がエントリのための基礎的要件を満たすかどうかを判定する。基礎的要件を満たす場合、プロセスは、ブロックＳ２０３に進む。基礎的要件を満たさない場合、サーバは、企業のログインを拒否する。

たとえば、企業がログインする間、サーバは、データベース（ＤＢＡ）内の企業の情報を検索することによって、企業がエントリのための基礎的要件を満たすかどうかを判定する。基礎的なエントリ要件は、企業のログイン地域、独自性、業界、企業サイズなどを含むことができる。様々な状態に応じて、基礎的要件を、サーバによって適時に調節することができる。

ブロックＳ２０３において、企業が正常にログインした後、サーバは、企業の情報を検索することによって、企業が権限を与えられたグループまたはクラブのメンバーかどうかを判定する。そのような権限を与えられたクラブの１つの例は、ＴｒｕｓｔＰａｓｓである。ＴｒｕｓｔＰａｓｓのメンバーは、Ａｌｉｂａｂａ．ｃｏｍのウェブサイトの会費を支払っているクラブメンバーである。ＴｒｕｓｔＰａｓｓのメンバーになるためには、エンティティは、特別の識別認証に合格することが求められる。企業が権限を与えられたグループ（たとえば、ＴｒｕｓｔＰａｓｓのメンバー）である場合、プロセスは、ブロックＳ２０４に進む。企業が権限を与えられたグループでない場合、プロセスは終了する。代替的には、新たなプロセスを開始して、異なる種類の融資申請を企業に提案する、あるいは、該企業を権限を与えられたグループに参加するように招待することができる。

ブロック２０４では、サーバは、記入されるべき融資申請のフォームを企業に提供し、企業によって記入された融資申請の情報をデータベースに保存する。

たとえば、企業が融資申請のフォームを記入すると、サーバは、データベース内の企業のメンバー情報を自動的に呼び出す。メンバー情報は、サーバによって構成されるのであって、企業が修正することはできない。企業が融資申請のフォームを提出した後、サーバは、企業によって記入された融資申請情報をデータベースに保存し、固有の申請フォームシリアル番号をデータベース内で生成する。次いで、サーバは、この固有の申請フォームシリアル番号を企業のメンバー情報と結び付ける。

ブロックＳ２０５において、サーバは、企業の融資申請情報に基づいて、企業が融資申請要件を満たすかどうかを判定する。企業が要件を満たす場合には、プロセスは、ブロックＳ２０６に進む。企業が要件を満たさない場合には、サーバは、企業のデータをデータベースに保存し、後で（たとえば、企業が融資申請要件を満たすことができる際に）再利用する可能性がある。

一実施形態では、たとえば、企業は、以下の３つの融資申請要件を満たすことが求められる。すなわち、（１）企業は、ＴｒｕｓｔＰａｓｓのメンバーであること、（２）企業は、少なくとも１８ヶ月間にわたって合法的な事業として登録されていること、および（３）企業に対して提訴された苦情の記録がないことである。

企業がＴｒｕｓｔＰａｓｓのメンバーであることをサーバが判定すると、サーバは、融資申請のフォームを企業に提供する。企業が記入した融資申請の情報に基づいて、サーバは、企業が上述の２つ目および３つ目の融資申請要件を満たすかどうかを判定する。企業が２つ目および３つ目の要件を満たす場合には、申請は通る。２つ目および３つ目の要件を満たさない場合には、企業の申請は通らず、サーバは、企業のデータをデータベースに保存し、後で（たとえば、企業が融資申請要件を満たすことができる際に）再利用する可能性がある。

たとえば、企業が不正調査を受けていることが発見される場合には、申請を拒絶することができ、その不正が確認される場合には、企業のＩＤを取り消すことができる。あるいは、企業が過去６ヶ月間に２つ以上の苦情を受けている場合には、申請は拒絶される。

ブロック２０６において、サーバは、データベースに保存された企業の融資申請情報を読み出し、その情報をウェブサイトに表示する。

具体的には、サーバは、カテゴリー分けされた表示リストを作成し、データベースに保存された企業の融資申請情報（たとえば、企業の地域的場所、企業名、規模など）を読み出し、ウェブサイト上に情報を対応して表示する。その企業またはその他のメンバーは、キーワード検索によって、その企業の融資申請情報を検索することができる。キーワード検索は、２つの検索種類、つまり曖昧な照会と厳密な照会とを含むことができる。その企業またはその他の企業ユーザ（メンバー）がカテゴリー化された検索を行うとき、サーバは、申請情報およびメンバー情報の一部を読み出すことができる。より詳細な情報が求められると、サーバは、融資申請の情報を結びつけ、ウェブサイト上に詳細な形式で表示することができる。

企業の申請が通った後には、銀行およびその他の企業ユーザ（メンバー）は、ウェブサイト上に以下の表に示されるような形式で、企業の情報を読み出すことができる。

ブロック２０７において、企業は、自動マッチングを選択して連帯保証グループを生成し、連帯保証グループを正常に生成した後に、連帯保証グループの情報をサーバに送信する。

自動マッチングは、ユーザ選択可能な種類の連帯保証グルーピングのうち１つである。例示的な自動マッチングは、企業が融資申請のための情報を記入した後に、サーバに、その他のマッチング企業をその企業に対して自動的に推薦させる。その他のマッチング企業とは、条件が類似するローン申請中の企業である。サーバは、企業の予め設定された基準に基づいて、自動的に推薦する。サーバは、マッチングされた企業同士がそれらのデータを互いに提供することを推薦し、企業間の連帯保証グループを作成するように指示する。

１つの例において、企業の申請が通った後、サーバは、連帯保証グルーピングの自動マッチングを既に選択しているかどうかを判定する。企業が、連帯保証グルーピングの自動マッチングを選択済みの場合、次いで、サーバは、企業が連帯保証グループを生成するための要件を満たすかどうかを判定する。連帯保証グループを生成するための要件は、企業のログインの基本的なエントリ要件と種類は同じだが、レベルは異なるものとすることができる。これらの要件は、様々な条件に基づいて、サーバによって適時に調節することができる。企業が連帯保証グループを生成するための要件を満たす場合には、サーバは、企業のために連帯保証グループを生成し、企業のマッチング要件を満たすその他の企業の情報について、データベースを検索する。次いで、サーバは、類似の条件の企業を推薦し、連帯保証グループを形成するように指示する。サーバが企業を推薦するたびに、サーバは、瞬時のまたは同時の通知を通じて、関連企業に通知する。企業が連帯保証グルーピングのために自動マッチングを選択しない場合、サーバは、その他の種類の連帯保証グルーピングを実行することができる。

サーバは、選択のために、企業の要件を満たす複数の連帯保証グループを、企業に提供することができる。企業は、サーバによって提供された連帯保証グループのうちいずれかの１つを選択し、グルーピングに適用することができる。たとえば、サーバは、ある特定の地域にある複数の企業を含むグループ、同じ業種の複数の企業を含むグループ、企業規模が類似している複数の企業を含むグループ、または融資要求が類似している複数の企業を含むグループを提供することができる。サーバが、要件を満たす企業を１つも発見できない場合、サーバは、企業に通知メッセージを送り、その融資申請需要を変更するまたは待つように企業に依頼することができる。

サーバによって企業のために生成された連帯保証グループは、固有の連帯保証グループＩＤを有する。サーバは、企業のメンバー情報を生成された連帯保証グループの情報と結び付ける。連帯保証グループを生成した後に、企業は、その要件で検索することによって、グループのメンバーとして加えることができるその他の企業を発見し、それらの企業を連帯保証グループに参加するように招待することができる。企業が新しい企業をメンバーとして加えると、サーバは、データベース内のそのメンバーの情報を検索することによって、新しい企業が融資要件を満たすかどうか判定することができる。

グルーピングプロセスにおいて、連帯保証グループの各企業は新しいメンバーを加えることを容認することができる。メンバーとして加えられるためには、新しい企業は、連帯保証グループの全ての現行メンバーによる審査および容認を受ける場合がある。１つの現行メンバーが承認しない場合、このメンバーの加入を拒否される場合がある。

連帯保証グループを生成している企業が連帯保証グループの情報を提出する前に、その他の企業は、いつでも取り下げることができる。この時点で、データベース内に保存される企業の記録は、以下の情報を含む。すなわち、その企業が連帯保証グループの発起人かどうか、メンバーシップＩＤ、申請フォームのシリアル番号、連帯保証グループＩＤおよび連帯保証グループのステータスである。連帯保証グループのステータスの一例は、グループがグルーピング段階にあるかどうか、である。グループがグルーピング段階にある場合、その他のメンバーは撤退することができる。グルーピング段階にない場合には、ステータス情報は、修正できず、企業は連帯保証グループから撤退することができない

上記のブロックＳ２０１からブロックＳ２０７は、グルーピングプロセスを構成するものとみなされる。

ブロックＳ２０８において、サーバは、連帯保証グループの情報を企業から受信し、認証を行う。

具体的には、サーバは、グループのメンバーが、連帯保証グループを生成するための要件を満たすかどうかを判定する。連帯保証グループを生成するための要件とは、グループ内の企業メンバーの独自性および数、関連業界、企業間の関係性、ならびに企業の関連資格を含むことができる。これらの要件は、サーバによって適時に調節することができる。グルーピング要件を満たす場合には、サーバは、連帯保証グループ内の全ての企業が互いに容認および賛同しあって、連帯してリスクに耐えるかどうかを判定する。そのような場合には、グルーピングは成功し、プロセスは、ブロックＳ２０９に進む。連帯保証グループ内の１つまたは複数の企業が異議を唱える場合、グルーピングは失敗し、サーバは、再びマッチングし、異なる種類のグルーピングを選択する必要がある。サーバは、インサイトメッセージ、ｅメール、テキストメッセージ、またはウェブページなどの任意の好適な手段を介して、上述の判定結果の連帯保証グループを生成した企業に直ちに知らせる。

グルーピングの失敗を引き起こす理由は、以下の例示的なシナリオを含むことができる。グループ内の企業のうち１つが同意せず、それによりグルーピングが失敗し、サーバはグループを削除する。あるいは、グループ内の企業のうち１つが排除されて（たとえば、強制的に脱退させられ）、したがってグルーピングは失敗であるが、その他の企業がグループの形成を続けることができる。連帯保証グループ候補（形成途中の連帯保証グループ）のメンバーによる投票の結果、１つの企業が元々のグループからはじき出されると、サーバは、該企業を、融資を申請している類似の条件を分け合う他の候補企業とマッチングし、これらの企業に別の連帯保証グループを形成するように指示することができる。代替的には、承諾しているまたは同意している企業は、新しい連帯保証グループを作成することができるが、反対しているまたは同意していない企業は、元々の連帯保証グループのままである。

連帯保証グループが生成されるのを待っている段階において、連帯保証グループ候補および融資申請中の企業がグループを形成するために時間がかかり過ぎると、サーバは、自ら率先して、企業に、その他の候補企業またはグループを推薦する旨の通知を送り、新しい企業に連帯保証グループを形成するように指示することができる。

また、サーバは、自動フィードバック機能を提供する。たとえば、１つの企業または１つの連帯保証グループ候補が、現在のマッチング結果または任意のその他の条件を満たさない場合には、その企業または連帯保証グループ候補は、自動マッチングを使用して、条件が類似する連帯保証グループ候補および候補企業とマッチングするように要求することができる。次いで、サーバは、自動マッチングの要求結果を伝えるフィードバックを、マッチング要求に応じて、要求する企業または複数の企業に戻す。

さらに、サーバは、クオリティ推薦機能を提供する。たとえば、サーバは、融資契約義務の履行にしたがって、以前に融資を受けたことがある企業を格付けし、格付け結果に基づいて、連帯保証グループから脱退したが、いまだに融資需要を有する企業を好みに応じて推薦する。

上記のブロック２０８は、受容プロセスと称されることがある。

ブロック２０９において、認証に合格した後、サーバは、連帯保証グループの情報をデータパケットに編成し、ネットワークを介してそのデータパケットを銀行システムに送信する。

サーバと銀行システムとの間のインターフェースは、機能を送信するメッセージおよび機能を受信するメッセージを有する。各メッセージまたはステータスフィードバックが送信されると、反対側のシステム（サーバまたは銀行）からの応答が予測される。反対側のシステムからの応答がフィードバックの時間内にない場合、メッセージは、自動的に再送信され、対応するＩＤを有するメッセージのステータスがインターフェースを介して取得され、自動同期される。

ブロックＳ２１０において、銀行システムは、サーバから送信されたユーザ融資申請の情報にしたがって、企業を審査する。銀行システムは、企業が融資要件を満たすかどうかを判定する。融資要件を満たす場合には、プロセスは、ブロックＳ２１１に進む。要件を満たさない場合には、融資申請は通らない。銀行システムは、サーバに、企業が申請した融資を受けることができるかどうかを示す審査結果を送信する。審査結果を受信するとすぐに、サーバは、企業に通知する。その通知の形式は、ｅメール、テキストメッセージなどとすることができる。企業が融資の許可を受領した場合、サーバは、企業が審査内容の一部をウェブサイトに開示することを選択するかどうかを問い合わせる。企業が審査内容を開示することを選択する場合、サーバは、企業のＴｒｕｓｔＰａｓｓ指標を増加させる。

ブロック２１１において、銀行システムは、通知メッセージを、融資要件を満たす企業に送信し、融資を支出する。その結果、認証が通った企業は、銀行から融資を受け、さらにサーバによるＴｒｕｓｔＰａｓｓ指標の上昇を受け取る。

ブロック２１２において、サーバと銀行システムとは、インターフェースを介して情報を交換し、企業の融資のリスクコントロールを完了する。

図３は、サーバと銀行システムとの間の例示的な情報交換のフローチャートである。融資申請プロセス全体の各段階において、サーバと銀行システムとの相互間の交換情報は、そのような情報交換プロセスを使用する。

ブロックＳ３０１において、企業は、ネットワークを介してサーバにログオンし、融資申請の要求をサーバに送信する。

ブロックＳ３０２では、サーバは、企業によって提出された融資申請の情報を受信し、予備認証を実行する（たとえば、企業が融資申請要件を満たすかどうかを審査する）。企業が要件を満たす場合には、プロセスは、ブロックＳ３０３に進む。企業が認証を通らなかった場合、サーバは、企業に通知する。

ブロック３０３では、サーバは、銀行システムに、認証を通った企業の情報を送信する。

ブロック３０４では、銀行システムが企業の融資申請情報をサーバから受信した後、銀行システムは、企業が融資申請要件を満たすかどうかを審査する。要件を満たす場合には、プロセスは、ブロックＳ３０５に進む。企業が認証を通らなかった場合もまた、銀行システムは、サーバに企業の情報を送信し、企業とサーバの双方に通知する。

ブロックＳ３０５では、銀行システムは、認証に合格した企業の情報をサーバに送信し、企業にオンラインで契約書にサインするように要求し、それによって、企業にクレジットを発行して、融資への企業のアクセス（たとえば、融資限度）の権限を与える。

ブロックＳ３０６では、企業は、銀行システムを介して、融資を返済し、次いで、銀行システムは、企業の返済情報をサーバに送信する。次いで、サーバは、企業の返済状態にしたがって、企業のＴｒｕｓｔＰａｓｓ指標を増やしたり、減らしたりする。

銀行システムとの情報の交換を通じて、サーバは、企業のクレジット記録の報告を取得することができる。クレジット報告は、企業の融資申請、融資審査、融資の減額、融資の返済などのステータス情報を有する。サーバは、正常に融資を受け、適時に融資の返済を行った企業のＴｒｕｓｔＰａｓｓ指標を上昇させる。サーバが、企業が融資を適時に返済しなかったと判定する場合、サーバは、その企業のＴｒｕｓｔＰａｓｓ指標を下げ、損失防止およびリスクコントロールのプロセスを開始することができる。

企業が融資の申請を開始しているので、サーバは、リスクコントロールのメカニズムを既に適用している場合もある。具体的には、リスクコントロールメカニズムは、企業の融資申請および融資の減額のような状態を監視することを含むことができる。

図４は、例示的なリスクコントロールプロセスのフローチャートである。

ブロックＳ４０１において、サーバは、企業から融資申請を受信する。

ブロックＳ４０２において、サーバは、企業の履歴記録をサーバ自身の保存内容から取得し、企業が不正を行うなどの何らかの悪い記録を有するかどうかを判定する。悪い記録が発見されない場合、サーバは、企業の情報を銀行システムに送信する。企業が悪い記録を有する場合、申請のための要件を満たさない。サーバは、企業が要件を将来満たしたときに、後で情報を再利用することができるように、企業のデータを保存する。

ブロックＳ４０３では、企業が正常に融資を受けた後、サーバは、企業の状態を監視する。

ブロックＳ４０４では、サーバは、企業の状態が異常である旨の判定をし、警告を与える。

具体的には、企業の状態は、以下の例を含む。すなわち、日常活動、融資取引の関連動作、メンバー間の相互格付け、関連取引の格付け、苦情情報、融資プロセスのステータス、ＴｒｕｓｔＰａｓｓによるサービス期間のステータス、ならびにサーバおよびに銀行システムよって取り込まれた関連するオフライン情報である。上記の項目のうちいずれかが、企業が融資を受ける前に平均的な状態を超える、あるいは、異常な状態になると、サーバは、警告またはアラートを与える。

図５は、本発明による、オンライン連帯保証を処理するための第３の例示的な方法のフローチャートである。第３の例示的な実施形態は、オンライン連帯保証を処理するための方法を示すために、例示的な種類の連帯保証グルーピングとしてフラタニティを使用する。

ブロックＳ５０１からブロックＳ５０６は、まとめてグルーピングプロセスと呼ばれ、第２の例示的な実施形態のブロックＳ２０１からブロックＳ２０６に記載されたグルーピングプロセスと同じである。したがって、これらのブロックはについて、ここでは再び記載することはない。

ブロックＳ５０７において、企業は、連帯保証グループを生成するための手段として、フラタニティを選択し、正常にグルーピングした後に、連帯保証グループの情報をサーバに送信する。

フラタニティは、互いに認識する、面識がある、または信用する企業で成り立つ。連帯保証グルーピングのためにフラタニティを使用する例では、複数の元々相互に認識している企業が、同意して連帯保証グループを開始し、フラタニティのうち１つの企業に、フラタニティを代表して連帯保証グループを設立するための融資申請のフォームを完成させる。フラタニティのその他の企業は、後で加入する。フラタニティのメンバーは、フラタニティに基づく連帯保証グループが正常に設立された後に、融資の申請を開始することができる。フラタニティに基づく連帯保証グループは、私的な非公開のグループであることが多い。

具体的には、開始企業の申請が通った後に、サーバは、企業が、連帯保証グルーピングの手段として、フラタニティを選択済みかどうか判定する。企業がフラタニティを選択して連帯保証グループを生成した場合、サーバは、次いで、企業が連帯保証グループを生成するための要件を満たすかどうかを判定する。連帯保証グループを生成するための要件は、企業がログインするための基礎的なエントリ要件と種類が同じであるが、レベルが異なるものとすることができる。これらの要件を、サーバによって適時に調節することができる。企業が連帯保証グループを生成するための要件を満たす場合には、サーバは、その企業のための連帯保証グループを生成する。連帯保証グループは、固有のＩＤを有する。グルーピングを始める開始企業をマネージャと称する。マネージャがグループを生成した後に、フラタニティのその他の企業を連帯保証グループに加えることができる。企業が連帯保証グルーピングの手段としてフラタニティを選択しなかった場合には、サーバは、その他の種類の連帯保証グルーピングを実行することができる。

サーバは、企業に対して固有の連帯保証グループＩＤを有する連帯保証グループを生成し、企業のメンバー情報を連帯保証グループの情報と結び付ける。連帯保証グループの生成後、企業は、メンバーを加えるための要件にしたがって検索し、その他の企業を連帯保証グループに参加するように招待することができる。企業が新しいメンバーを加えると、サーバは、データベース内のその新しいメンバーの情報を検索することによって、その新しいメンバーが、融資要件を満たすかどうかを判定する。

グルーピングプロセスにおいて、連帯保証グループ内の企業は、その他のメンバーを加えることができる。メンバーとして加入するためには、企業は、連帯保証グループの全ての現行メンバーによる審査および承認を受ける。１つの現行メンバーが承認しない場合、新しいメンバーの加入は許可されない。連帯保証グループを生成する開始企業が連帯保証グループの情報を提出する前ならば、その他の企業は、いつでも取り下げることができる。

ブロックＳ５０８において、サーバは、連帯保証グループの情報を企業から受信し、認証を行う。

具体的には、サーバは、グループのメンバーが、連帯保証グループを生成するための要件を満たすかどうかを判定する。連帯保証グループを生成するための例示的な要件は、グループ内の企業メンバーの独自性および数、関連業界、企業間の関係性、および企業の関連資格を含む。これらの要件は、サーバによって適時に調節することができる。グルーピング要件を満たす場合には、サーバは、連帯保証グループ内の全ての企業が互いに容認および賛同しあって、連帯してリスクに耐えるかどうかを判定する。判定が肯定的なものである場合には、グルーピングは成功し、プロセスは、ブロックＳ５０９に進む。連帯保証グループ内の１つまたは複数の企業が異議を唱える場合、グルーピングは失敗し、サーバは、別のマッチングを見つける、またはグルーピングの異なる方法を選択する必要がある場合がある。サーバは、インサイトメッセージ、ｅメール、テキストメッセージ、またはウェブページなどの任意の好適な含意の手段を介して、判定結果を開始企業に知らせる。

連帯保証グループ内の全ての企業が互いに容認および賛同する場合、グルーピングは成功する。正常にグルーピングされた企業は、別の連帯保証グループに参加したり、別の連帯保証グループを生成したりすることはできない。連帯保証グループ内の１つまたは複数の企業が異議を唱える場合、グルーピングは失敗し、連帯保証グループのマネージャは、同意しない企業を取り除くかどうか、または、要件を満たす別の１つまたは複数の企業を加えるかどうか、を判定できるようになる。プロセスは、グループ内の全ての企業が互いに容認および賛同するまで続けられる場合がある。

ブロックＳ５０９からブロックＳ５１２までの動作は、図２の第２の例示的な実施形態のブロックＳ２０９からブロックＳ２１２までの動作と同じであり、ここでは再び記載しない

図６は、本発明による、オンライン連帯保証を処理するための第４の例示的な方法のフローチャートである。第４の例示的な実施形態は、オンライン連帯保証を処理する方法を示すために、連帯保証グルーピングの例示的な方法として、オンライン開始／参加を使用する。

ブロックＳ６０１からブロックＳ６０６は、グルーピングプロセスを構成し、図２のブロックＳ２０１からブロックＳ２０６で記載したグルーピングプロセスと同じである。したがって、これらのブロックはについて、ここでは再び記載することはない。

ブロックＳ６０７において、企業は、連帯保証グルーピングの方法として、オンライン開始／参加を選択し、正常にグルーピングした後に、連帯保証グループの情報をサーバに送信する。

連帯保証グルーピングのための例示的なオンライン開始／参加において、企業は、グルーピング要求をサーバに表明し、企業の資格およびグルーピング要件を示し、次いで、グループに参加および形成するその他の資格を与えられた企業を待つ、または招待する。この手法を使用してグルーピング要求を表明する企業は、融資の必要性を有するが、一時的には、その他の方法を通じた連帯保証グループの生成に失敗している場合がある。自身のグルーピング要求を表明しているかどうかにかかわらず、別の企業は、その企業がまだ、別の連帯保証グループに参加いない、および／または連帯保証同意書に署名していないならば、連帯保証グループ候補への参加を申請することができる。たとえば、自動マッチングが正常に行われなかった、およびフラタニティに参加しなかったまたはフラタニティへの参加資格が与えられなかった任意の企業は、このオプションを選択することができる。

ブロックＳ６０８において、サーバは、連帯保証グループの情報を企業から受信し、認証を行う。ブロックＳ６０８からブロックＳ６１２の動作は、図２のブロックＳ２０９からブロックＳ２１２までの動作と同じであり、ここでは再び記載することはない。

連帯保証グルーピングのための自動マッチング、フラタニティおよびオンライン開始／参加をそれぞれ使用するいくつかの例示的な実施形態を使用して、本開示の方法を上述した。上述の諸実施形態に加えて、その方法は、その他の種類の実施形態にも適用することができる。以下に、いくつかの例を示す。

（１）自動マッチング＋オンライン開始による連帯保証グルーピング
開始企業が融資申請のための情報を記入した後、サーバは、選択するために、様々な種類の連帯保証グルーピング方法を企業に提供することができる。企業が自動マッチング＋オンライン開始を選択する場合、サーバは、最初に企業の融資申請情報を表明し、次いで、企業の設定にしたがって、開始企業と要件が類似するその他の企業を検索する。企業は、現在は、オンラインでもオフラインでもよい。サーバは、様々なカテゴリーおよび特徴にしたがって、自動的に企業をマッチングして、連帯保証グループを生成する。

（２）自動マッチング＋オンライン参加による連帯保証グルーピング
自身の融資申請情報を開示し、連帯保証グループを生成することを望まない企業の場合、サーバは、様々なカテゴリーおよび特徴にしたがって、融資需要が類似するその他のオンラインまたはオフライン企業と自動的にマッチングすることを補助し、自動的に連帯保証グループを形成する。

（３）自動マッチング＋一時的空白による連帯保証グルーピング
連帯保証グループ候補が、同意されないことを理由にはじき出されたメンバー企業を有するときには、要件を修正することができ、サーバは、新しい要件を満たすその他の企業を連帯保証グループに自動的に推薦することができる。

（４）自動マッチング＋グループからの排除による連帯保証グルーピング
連帯保証グループ候補が、同意されないことを理由にはじき出されたメンバー企業を有するときは、サーバは、その他の連帯保証グループまたは企業を、グループから排除された企業に自動的に推薦する。

図７は、本発明による、オンライン連帯保証を処理するためのサーバの概略図である。

サーバ７００は、ユーザから申請を受信し、様々なユーザ選択可能な種類の連帯保証グルーピングを提供し、そのユーザ選択をグルーピングモジュール７１２に送るように適合される処理モジュール７１１を有する。連帯保証グループを形成するユーザ選択可能な方法は、自動マッチング、フラタニティ、オンライン開始／参加、またはそれらの組合せを含む。グルーピングモジュール７１２は、ユーザによってなされた選択にしたがって、固有のＩＤを有する連帯保証グループを生成し、連帯保証グループの情報を送信モジュール７１３に送るように適合される。送信モジュール７１３は、グルーピングモジュール７１２から連帯保証グループの情報を受信し、連帯保証の情報をデータパケットに編成し、そのデータパケットを送出するように適合される。

一実施形態では、サーバは、さらに、ユーザの申請情報を受信し、ユーザが申請の要件を満たすかどうかを判定するように適合される判定モジュール７１４を有する。ユーザが申請の要件を満たす場合、判定モジュール７１４は、ユーザの申請情報を処理モジュール７１１に送信する。ユーザが申請の要件を満たさない場合、判定モジュール７１４は、ユーザの申請情報を保存モジュール７１５に送信する。保存モジュール７１５は、ユーザが申請の要件を満たさない場合には、ユーザの申請情報を保存するように適合される。

別の実施形態では、サーバはさらに、ユーザの申請が承認されたかどうかを示すメッセージを受信し、そのメッセージを通知モジュール７１７に送信するように適合される受信モジュール７１６を有する。通知モジュール７１７は、ユーザに、ユーザの申請が承認されたかどうかを示すメッセージを送信するように適合される。

実施環境
開示された方法およびシステムは、ハードウェアのみを使用して実施することができるが、ユニバーサルハードウェアプラットフォームなど、ソフトウェアとハードウェアの組合せを使用して実施するのが好ましいことを留意されたい。開示された方法自体は、保存媒体に保存されたソフトウェア製品の形態で実施することができる。ソフトウェアは、本開示の例示的な諸実施形態に記載された方法を実行するためのコンピュータデバイス（独立型またはネットワーク型）のための指令を含む。

具体的には、上述の技法は、以下に示すように、コンピューティングユニットを有するサーバまたはパーソナルコンピュータ（ＰＣ）などのコンピューティングデバイスを利用して実施することができる。

図８は、本開示の方法を実施するための例示的な環境を示す。図示されたシステム８００において、いくつかのコンポーネントは、クライアント側に常駐し、その他のコンポーネントは、サーバ側に常駐する。しかしながら、これらのコンポーネントは、複数のその他の場所に常駐してもよい。さらに、図示されたコンポーネントのうち２つ以上を組み合わせて、１つのコンポーネントを一か所に形成することができる。

オンライン連帯保証を処理するためのシステム８０１は、好ましくはサーバであるコンピューティングデバイス８０２により実施され、１つまたは複数のプロセッサ８１０、Ｉ／Ｏデバイス８２０、コンピュータ読取可能媒体８３０およびネットワークインターフェース（図示せず）を含む。コンピュータデバイス８０２は、１つまたは複数のネットワーク８９０を介して、８４１、８４２および８４３などのクライアント側のコンピューティングデバイス（クライアント端末）に接続される。一実施形態では、コンピューティングデバイス８０２は、本明細書に記載されたサーバ（たとえば、サーバ７００）であり、一方クライアント側のコンピューティングデバイス８４１、８４２および８４３はそれぞれ、ユーザ端末として使用されるコンピュータまたはポータブルデバイスとすることができる。

コンピュータ読取可能媒体８３０は、アプリケーションプログラムモジュール８３２およびデータ８３４（申請情報、グループ情報、融資記録およびメッセージなど）を保存する。アプリケーションプログラムモジュール８３２は、１つまたは複数のプロセッサ８１０によって実行されるときに、１つまたは複数のプロセッサ８１０に本明細書に記載されたプロセス（たとえば、図２の図示のプロセス）の動作を実行させる指令を含む。コンピュータ読取可能媒体８３０内に保存される指令を実行することによって、オンライン連帯保証を処理するためのシステム８０１によって実行され得る例示的なプロセスは、以下の通りである。すなわち、
サーバがユーザから申請を受信した後に、様々なユーザ選択可能な種類の連帯保証グルーピングを提供すること、
ユーザの選択にしたがって、固有のＩＤを有する連帯保証グループを生成すること、および、
連帯保証グループの情報をデータパケットに編成し、そのデータパケットを銀行システムに送信すること、である。

コンピュータ読取可能媒体は、コンピュータデータを保存するための好適なストレージまたはメモリデバイスのいずれかとすることができることを理解されたい。そのようなストレージまたはメモリデバイスは、ハードディスク、フラッシュメモリデバイス、光学データストレージ、およびフロッピーディスクを含むが、これらには限定されない。さらに、コンピュータ実行可能な指令を含むコンピュータ読取可能媒体は、ローカルシステム内の１つまたは複数のコンポーネント、または複数のリモートシステムのネットワークを介して分配されるコンポーネントで構成することができる。コンピュータ実行可能な指令のデータは、有形の物理的メモリデバイスに配信しても、電子的に伝送してもよい。

また、コンピューティングデバイスは、プロセッサ、Ｉ／Ｏデバイス、およびメモリ（内部メモリまたは外部メモリ）を有する任意のデバイスとすることができ、パーソナルコンピュータには限定されないことを理解されたい。特に、コンピュータデバイス８０２は、インターネットまたはイントラネットのいずれかとすることができる１つまたは複数のネットワーク８９０を介して接続される、サーバコンピュータ、またはそのようなサーバコンピュータのクラスタとすることができる。

上記の例示的な諸実施形態で提供される方法およびシステムを使用すると、潜在的に連帯保証グルーピングの成功率を上げ、地理的な制限を取り除くことができる。この開示は、インターネットを介して、様々な地理的場所の企業をグルーピングする可能性を提供する。また、開示された方法は、完全にオンラインのアラートメカニズムを確立し、かつ、融資プロセスのリスクコントロールをコンピュータ化し、企業のクレジットシステムを改善するのに役立つことができる。

本明細書に記載された潜在的な恩恵および利益は、添付の特許請求の範囲に限定または制限されることを意図するものではないことを理解されたい。

主題について、構造的特徴および／または手法的な動作に特定の言葉で記載してきたが、添付の特許請求の範囲に規定された主題は、記述された具体的な特徴または動作に必ずしも限定されるものではいことを理解されたい。むしろ、具体的な特徴および動作は、各請求項を実施する例示的な形態として開示されるものである。

Claims (15)

1. オンライン連帯保証を処理するための方法であって、
   サーバが、ユーザから申請を受信した後に、サーバにより様々なユーザ選択可能な種類の連帯保証グルーピングを提供するステップと、
   前記ユーザによってなされた選択にしたがって、前記サーバにより、固有のＩＤを有する連帯保証グループを生成するステップと、
   前記サーバにより、前記連帯保証グループの情報をデータパケットに編成し、前記データパケットを銀行システムに送信するステップと、
   を含むことを特徴とする方法。
2. サーバが、ユーザから申請を受信した後に、サーバにより様々なユーザ選択可能な種類の連帯保証グルーピングを提供するステップが、
   前記サーバにより、前記ユーザが前記申請の要件を満たすかどうかを判定するステップと、
   前記サーバにより、前記ユーザが前記要件を満たす場合には、ユーザ選択のために、前記様々な種類の連帯保証グルーピングを前記ユーザに提供し、前記ユーザが前記要件を満たさない場合には、前記ユーザの前記申請をデータベースに保存するステップと
   を含むことを特徴とする請求項１に記載のオンライン連帯保証を処理する方法。
3. 前記サーバが、前記連帯保証グループの前記情報を前記データパケットに編成して、前記データパケットを前記銀行システムに送信した後に、
   前記サーバにより、前記銀行システムから、前記申請が認められるかどうかを示すフィードバックを受信するステップと、
   前記フィードバックを前記ユーザに通知するステップと
   をさらに含むことを特徴とする請求項１に記載のオンライン連帯保証を処理する方法。
4. 固有のＩＤを有する連帯保証グループを生成するステップが、
   前記ユーザの前記選択にしたがって、前記サーバにより、前記固有の連帯保証ＩＤを生成し、前記連帯保証グループの情報を前記ユーザのメンバー情報を結びつけるステップと、
   前記ユーザの前記メンバー情報に基づいて、前記サーバにより、前記ユーザがグルーピング要件を満たすかどうかを判定するステップと、
   前記ユーザが前記グルーピング要件を満たす場合には、前記サーバにより、前記連帯保証グループを生成するステップと
   を含むことを特徴とする請求項１に記載のオンライン連帯保証を処理する方法。
5. 前記様々な種類の連帯保証グルーピングが、自動マッチング、フラタニティ、およびオンライン開始／参加のうち１つまたはそれらの組合せを含むことを特徴とする請求項１に記載のオンライン連帯保証を処理する方法。
6. 前記様々な種類の連帯保証グルーピングが、前記申請の業務情報を提供する前記ユーザの予め設定された基準に基づいて、前記サーバによって行われる自動マッチングを含み、前記自動マッチングが、
   前記ユーザに、前記申請の前記業務情報に関連する他のユーザを自動的に推薦するステップと、
   前記ユーザのデータを相互に提供するステップと、
   前記ユーザ間の連帯保証グループを形成するように提案するステップと
   を含むことを特徴とする請求項１に記載のオンライン連帯保証を処理する方法。
7. 前記様々な種類の連帯保証グルーピングが、複数のユーザが、連帯保証グループを形成することに同意し、前記ユーザのうち１つが前記連帯保証グループを設立し、それ以外のユーザを加えて融資事業に連帯して申請する、フラタニティグルーピングを含むことを特徴とする請求項１に記載のオンライン連帯保証を処理する方法。
8. 前記様々な種類の連帯保証グルーピングが、事業ニーズを有する前記ユーザが、グルーピング要求を前記サーバ上で発行し、前記ユーザ自身の資格およびグルーピング基準を示し、資格を持つユーザを待つおよび／または加えて前記連帯保証グループを形成する、オンライン開始／参加を含むことを特徴とする請求項１に記載のオンライン連帯保証を処理する方法。
9. 処理モジュールと、
   グルーピングモジュールと、
   送信モジュールと
   を備え、前記処理モジュールが、ユーザから申請を受信し、ユーザ選択のために様々な種類の連帯保証グルーピングを提供し、前記ユーザ選択を前記グルーピングモジュールに送信するように適合され、前記グルーピングモジュールが、前記ユーザ選択にしたがって、固有のＩＤを有する連帯保証グループ生成し、前記連帯保証グループの情報を前記送信モジュールに送信するように適合され、前記送信モジュールが、前記連帯保証グループの前記情報を前記グルーピングモジュールから受信し、前記連帯保証の前記情報をデータパケットに編成し、前記データパケットを送出するように適合されることを特徴とするサーバ。
10. 判定モジュールと、
    保存モジュールと
    をさらに備え、前記判定モジュールが、前記ユーザの申請情報を受信し、前記ユーザが前記申請の要件を満たすかどうかを判定し、前記ユーザが前記要件を満たす場合には、前記ユーザの前記申請情報を前記処理モジュールに送信し、前記ユーザが前記要件を満たさない場合には、前記ユーザの前記申請情報を前記保存モジュールに送信するように適合され、
    前記保存モジュールが、前記ユーザの前記申請情報を保存するように適合されることを特徴とする請求項９に記載のサーバ。
11. 受信モジュールと、
    通知モジュールと
    をさらに備え、前記受信モジュールが、前記ユーザの前記申請が承認されたかどうかを示すメッセージを受信し、前記メッセージを前記通知モジュールに送信するように適合され、前記通知モジュールが、前記メッセージを前記ユーザに送信するように適合されることを特徴とする請求項９に記載のサーバ。
12. コンピュータ実行可能な指令を保存する１つまたは複数のコンピュータ可読媒体であって、前記コンピュータ実行可能な指令は、実行されるときに、
    サーバがユーザから申請を受信した後に、様々なユーザ選択可能な種類の連帯保証グルーピングを提供することと、
    前記ユーザによってなされた選択にしたがって、固有のＩＤを有する連帯保証グループを生成することと、
    前記連帯保証グループの情報をデータパケットに編成して、前記データパケットを銀行システムに送信することと
    を含む動作を実行することを特徴とする１つまたは複数のコンピュータ可読媒体。
13. 前記コンピュータ実行可能な指令が、サーバによって実行されることを特徴とする請求項１２に記載の１つまたは複数のコンピュータ可読媒体。
14. 固有のＩＤを有する連帯保証グループを生成することが、
    前記ユーザの前記選択にしたがって、前記サーバにより、前記固有の連帯保証ＩＤを生成し、前記連帯保証グループの情報を前記ユーザのメンバー情報を結びつけることと、
    前記サーバにより、前記ユーザの前記メンバー情報に基づいて、前記ユーザがグルーピング要件を満たすかどうかを判定することと、
    前記サーバにより、前記ユーザが前記グルーピング要件を満たす場合には、前記連帯保証グループを生成することと
    を含むことを特徴とする請求項１２に記載される１つまたは複数のコンピュータ可読媒体。
15. 前記様々な種類の連帯保証グルーピングが、自動マッチング、フラタニティおよびオンライン開始／参加のうち１つまたはそれらの組合せを含むことを特徴とする請求項１２に記載される１つまたは複数のコンピュータ可読媒体。

Images