(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2022-07-06
(45)【発行日】2022-07-14
(54)【発明の名称】支払い方法およびシステム
(51)【国際特許分類】
G06Q 20/40 20120101AFI20220707BHJP
【ＦＩ】
G06Q20/40
【請求項の数】
5
(21)【出願番号】P 2021081042
(22)【出願日】2021-05-12
(62)【分割の表示】P 2019530182の分割
【原出願日】2016-12-13
(65)【公開番号】P2021185477
(43)【公開日】2021-12-09
【審査請求日】2021-05-12
(73)【特許権者】
【識別番号】321003371
【氏名又は名称】ＬＩＮＥ株式会社
(74)【代理人】
【識別番号】100107766
【弁理士】
【氏名又は名称】伊東 忠重
(74)【代理人】
【識別番号】100070150
【弁理士】
【氏名又は名称】伊東 忠彦
(74)【代理人】
【識別番号】100135079
【弁理士】
【氏名又は名称】宮崎 修
(72)【発明者】
【氏名】チェー，ウォンジュン
【審査官】宮地 匡人
(56)【参考文献】
【文献】米国特許出願公開第２０１６／０１０４１３３（ＵＳ，Ａ１）
【文献】特開２０１０－２１７９３７（ＪＰ，Ａ）
【文献】特開２００６－３０２２２１（ＪＰ，Ａ）
【文献】特開２００７－１０２６２０（ＪＰ，Ａ）
【文献】米国特許出願公開第２０１６／０１０４１３２（ＵＳ，Ａ１）
【文献】韓国公開特許第１０－２０１３－００１５１３９（ＫＲ，Ａ）
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ｇ０６Ｑ １０／００－９９／００
(57)【特許請求の範囲】
【請求項1】
差出人の端末からネットワークを介して受信した送金要請と関連して前記差出人の引出口座および受取人の受取口座を特定する特定手段、前記引出口座と前記受取口座との間の過去取引履歴を取引履歴データベースから検索する検索手段、
前記過去取引履歴が存在しない場合、前記受取人の他のユーザとの取引履歴、および前記差出人が指定した受取口座リストのうちの少なくとも１つに基づいて前記受取人の危険性程度を計算する計算手段、
前記計算された受取人の危険性程度により、前記差出人に警告メッセージを送信する第１プロセスおよび前記受取人に本人証明メッセージを要請する第２プロセスのうちの少なくとも一方のプロセスを処理する決定手段、
前記受取人に本人証明メッセージを要請した場合、前記受取人の端末から受信される本人証明メッセージを前記差出人に送信する発信手段、および
前記差出人から前記本人証明メッセージに対する確認応答を受信した場合、前記差出人の前記送金要請を処理する処理手段、
を含むことを特徴とする、支払いシステム。
【請求項2】
前記差出人に送信した警告メッセージに対する確認応答を前記差出人の端末から受信した場合、前記差出人の前記送金要請を処理する処理手段をさらに含むことを特徴とする、請求項１に記載の支払いシステム。
【請求項3】
前記受取人の危険性程度を計算する計算手段は、（１）前記受取人の受取口座を利用して前記他のユーザと取引が行われた回数および期間のうちの少なくとも一方によって計算される第１危険性程度、並びに（２）前記差出人が指定した受取口座リストに前記受取人の受取口座が含まれているかによって計算される第３危険性程度、のうちの少なくとも１つを利用して前記受取人の危険性程度を計算することを特徴とする、請求項１に記載の支払いシステム。
【請求項4】
支払いシステムが実行する支払い方法であって、
差出人の端末からネットワークを介して受信した送金要請と関連して前記差出人の引出口座および受取人の受取口座を特定する特定工程、
前記引出口座と前記受取口座との間の過去取引履歴を取引履歴データベースから検索する検索工程、
前記過去取引履歴が存在しない場合、前記受取人の他のユーザとの取引履歴、および前記差出人が指定した受取口座リストのうちの少なくとも１つに基づいて前記受取人の危険性程度を計算する計算工程、
前記計算された受取人の危険性程度により、前記差出人に警告メッセージを送信する第１プロセスおよび前記受取人に本人証明メッセージを要請する第２プロセスのうちの少なくとも一方のプロセスを処理する決定工程、
前記受取人に本人証明メッセージを要請した場合、前記受取人の端末から受信される本人証明メッセージを前記差出人に送信する工程、および
前記差出人から前記本人証明メッセージに対する確認応答を受信した場合、前記差出人の前記送金要請を処理する工程
を含むことを特徴とする、支払い方法。
【請求項5】
コンピュータに、
差出人の端末からネットワークを介して受信した送金要請と関連して前記差出人の引出口座および受取人の受取口座を特定する特定工程、
前記引出口座と前記受取口座との間の過去取引履歴を取引履歴データベースから検索する検索工程、
前記過去取引履歴が存在しない場合、前記受取人の他のユーザとの取引履歴、および前記差出人が指定した受取口座リストのうちの少なくとも１つに基づいて前記受取人の危険性程度を計算する計算工程、
前記計算された受取人の危険性程度により、前記差出人に警告メッセージを送信する第１プロセスおよび前記受取人に本人証明メッセージを要請する第２プロセスのうちの少なくとも一方のプロセスを処理する決定工程、
前記受取人に本人証明メッセージを要請した場合、前記受取人の端末から受信される本人証明メッセージを前記差出人に送信する工程、および
前記差出人から前記本人証明メッセージに対する確認応答を受信した場合、前記差出人の前記送金要請を処理する工程
を実行させるためのコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【0001】
以下の説明は、支払い方法およびシステムに関し、より詳細には、差出人の送金要請と関連して送金要請の対象となる受取人の本人確認をすることができる技術に関する。
【背景技術】
【0002】
オンライン上で差出人が受取人に一定金額を伝達するための多様な従来技術が存在する。例えば、特許文献１は、受取人の名前と携帯電話番号だけを利用して送金を行うことができる送金方法および送金サービスシステムに関し、差出人が受取人の名前と携帯電話番号だけを利用して送金が可能であり、受取人が加入者であるかに関係なく、差出人が送金した時点に直ぐに送金額を基本口座から引き出せるようにすることにより、差出人の立場では、送金時点と非加入者である受取人の受取時点との間に発生し得る口座残額変動に対する心配なく直ぐに送金額を送金することができ、受取人の立場では、希望する時点に送金額を受け取ることができる技術について説明している。
【0003】
このように、オンライン上で便利に送金できるようにするための多様な従来技術が開発および実用化されている。しかし、このような便利な送金技術の発達に伴い、第三者が受取人の情報を盗用して受取人のふりをしながら接近して差出人に送金を要請する危険が発生するようになった。例えば、メッセージングサービスを利用した送金技術において、受取人のメッセージングアカウントや銀行受取口座を乗っ取った第三者が、メッセージングサービスを利用しながら受取人のふりをして送金者に接近し、自身の口座番号への送金要請をする場合などが発生している。このため、差出人の送金要請に対しても受取人本人であることを確認することにより、このような偽の受取人を選別することができる技術が求められている。
【先行技術文献】
【特許文献】
【0004】
【文献】韓国公開特許第１０－２０１３－００４７３３８号公報
【発明の概要】
【発明が解決しようとする課題】
【0005】
送金を要請する差出人と受取人との間の過去取引履歴の存在の有無に応じて受取人を認証するための方式を選択して進行することができる、支払い方法およびシステムを提供する。
【0006】
送金過程において差出人と受取人との間に過去取引履歴が存在しない場合、受取人が本当に本人であるかを証明するための認証方式を追加で取り入れることにより、差出人が受取人を確信できるようにして送金差出人を保護し、誤った送金を防ぐことができる支払い方法およびシステムを提供する。
【課題を解決するための手段】
【0007】
差出人の端末からネットワークを介して受信した送金要請と関連して前記差出人の引出口座および受取人の受取口座を特定する工程、前記引出口座と前記受取口座との間の過去取引履歴を取引履歴データベースから検索する工程、前記過去取引履歴が存在しない場合、前記受取人の他のユーザとの取引履歴、前記差出人と前記受取人との間のメッセージングサービスを利用した会話記録、および前記差出人が指定した受取口座リストのうちの少なくとも１つに基づいて前記受取人の危険性程度を計算する工程、および前記計算された受取人の危険性程度に基づいて前記受取人の認証方式を決定する工程を含むことを特徴とする、支払い方法を提供する。
【0008】
差出人の端末からネットワークを介して受信した送金要請と関連して前記差出人の引出口座および受取人の受取口座を特定する手段、前記引出口座と前記受取口座との間の過去取引履歴を取引履歴データベースから検索する手段、前記過去取引履歴が存在しない場合、前記受取人の他のユーザとの取引履歴、前記差出人と前記受取人との間のメッセージングサービスを利用した会話記録、および前記差出人が指定した受取口座リストのうちの少なくとも１つに基づいて前記受取人の危険性程度を計算する手段、および前記計算された受取人の危険性程度に基づいて前記受取人の認証方式を決定する決定手段を含むことを特徴とする、支払いシステムを提供する。
【発明の効果】
【0009】
送金を要請した差出人と受取人との間の過去取引履歴の存在の有無に応じて受取人を認証するための方式を選択して進行することができる。
【0010】
送金過程において差出人と受取人との間の過去取引履歴が存在しない場合、受取人が本当に本人であるかを証明するための認証方式を追加で取り入れることにより、差出人が受取人を確信できるようにして送金差出人を保護し、誤った送金を防ぐことができる。
【図面の簡単な説明】
【0011】
【図1】本発明の一実施形態における、ネットワーク環境の例を示した図である。
【図2】本発明の一実施形態における、電子機器およびサーバの内部構成を説明するためのブロック図である。
【図3】本発明の一実施形態における、支払いシステムの全体的な構造の例を示した図である。
【図4】本発明の一実施形態における、送金過程の例を示したフローチャートである。
【図5】本発明の一実施形態における、本人証明メッセージが伝達された差出人端末の画面例を示した図である。
【図6】本発明の一実施形態における、警告メッセージが伝達された差出人端末の画面例を示した図である。
【図7】本発明の一実施形態における、支払いサーバのプロセッサが含むことができる構成要素の例を示したブロック図である。
【図8】本発明の一実施形態における、支払いサーバが実行することができる支払い方法の例を示したフローチャートである。
【図9】本発明の一実施形態における、警告メッセージを送信する支払い方法の例を示したフローチャートである。
【発明を実施するための形態】
【0012】
以下、実施形態について、添付の図面を参照しながら詳しく説明する。
【0013】
本発明の実施形態に係る支払いシステムは、以下で説明される電子機器および／またはサーバのようなコンピュータ装置によって実現されてよく、本発明の実施形態に係る支払い方法は、上述した電子機器および／またはサーバによって実行されてよい。例えば、サーバには、本発明の一実施形態に係るコンピュータプログラム（一例として、オペレーティングシステムおよび／またはアプリケーション）がインストールおよび駆動されてよく、電子機器は、駆動されたコンピュータプログラムの制御に従って本発明の一実施形態に係る支払い方法を実行してよい。上述したコンピュータプログラムは、上述したコンピュータで実現されるサーバと結合して支払い方法をコンピュータに実行させるためにコンピュータ読取可能な記録媒体に格納されてよい。このとき、電子機器は、支払い方法を実行するサーバとネットワークを介して通信して送金サービスの提供を受ける、送金のための差出人と受取人のユーザ端末装置であってよい。
【0014】
図１は、本発明の一実施形態における、ネットワーク環境の例を示した図である。図１のネットワーク環境は、複数の電子機器１１０、１２０、１３０、１４０、複数のサーバ１５０、１６０、およびネットワーク１７０を含む例を示している。このような図１は、本発明の説明のための一例に過ぎず、電子機器の数やサーバの数が図１のように限定されることはない。
【0015】
複数の電子機器１１０、１２０、１３０、１４０は、コンピュータ装置によって実現される固定端末や移動端末であってよい。複数の電子機器１１０、１２０、１３０、１４０の例としては、スマートフォン、携帯電話、ナビゲーション、ＰＣ（ｐｅｒｓｏｎａｌ ｃｏｍｐｕｔｅｒ）、ノート型パンコン、デジタル放送用端末、ＰＤＡ（Ｐｅｒｓｏｎａｌ Ｄｉｇｉｔａｌ Ａｓｓｉｓｔａｎｔ）、ＰＭＰ（Ｐｏｒｔａｂｌｅ Ｍｕｌｔｉｍｅｄｉａ Ｐｌａｙｅｒ）、タブレットなどがある。一例として、図１では電子機器１（１１０）の例としてスマートフォンの形状を示しているが、本発明の実施形態において、電子機器１（１１０）は、実質的に無線または有線通信方式を利用し、ネットワーク１７０を介して他の電子機器１２０、１３０、１４０および／またはサーバ１５０、１６０と通信することができる多様な物理装置のうちの１つを意味してよい。
【0016】
通信方式が限定されることはなく、ネットワーク１７０が含むことができる通信網（一例として、移動通信網、有線インターネット、無線インターネット、放送網）を活用する通信方式だけではなく、機器間の近距離無線通信が含まれてもよい。例えば、ネットワーク１７０は、ＰＡＮ（ｐｅｒｓｏｎａｌ ａｒｅａ ｎｅｔｗｏｒｋ）、ＬＡＮ（ｌｏｃａｌ ａｒｅａ ｎｅｔｗｏｒｋ）、ＣＡＮ（ｃａｍｐｕｓ ａｒｅａ ｎｅｔｗｏｒｋ）、ＭＡＮ（ｍｅｔｒｏｐｏｌｉｔａｎ ａｒｅａ ｎｅｔｗｏｒｋ）、ＷＡＮ（ｗｉｄｅ ａｒｅａ ｎｅｔｗｏｒｋ）、ＢＢＮ（ｂｒｏａｄｂａｎｄ ｎｅｔｗｏｒｋ）、インターネットなどのネットワークのうちの１つ以上の任意のネットワークを含んでよい。さらに、ネットワーク１７０は、バスネットワーク、スターネットワーク、リングネットワーク、メッシュネットワーク、スター－バスネットワーク、ツリーまたは階層的（ｈｉｅｒａｒｃｈｉｃａｌ）ネットワークなどを含むネットワークトポロジのうちの任意の１つ以上を含んでもよいが、これらに限定されることはない。
【0017】
サーバ１５０、１６０のそれぞれは、複数の電子機器１１０、１２０、１３０、１４０とネットワーク１７０を介して通信して命令、コード、ファイル、コンテンツ、サービスなどを提供するコンピュータ装置または複数のコンピュータ装置によって実現されてよい。例えば、サーバ１５０は、ネットワーク１７０を介して接続される複数の電子機器１１０、１２０、１３０、１４０に第１サービスを提供するシステムであってよく、サーバ１６０も、ネットワーク１７０を介して接続される複数の電子機器１１０、１２０、１３０、１４０に第２サービスを提供するシステムであってよい。より具体的な例として、サーバ１５０は、第１サービスとして送金サービスを複数の電子機器１１０、１２０、１３０、１４０に提供するシステムであってよい。また、サーバ１６０は、第２サービスとしてメッセージングサービスや決済サービスを複数の電子機器１１０、１２０、１３０、１４０に提供するシステムであってよい。メッセージングサービスを提供するサーバ１６０と送金サービスを提供するサーバ１５０が連動してメッセージングサービスによって送金が処理されてもよい。このような送金サービスやメッセージングサービスに対する一般的な処理技術については、周知の従来技術から当業者が容易に理解することができるであろう。
【0018】
図２は、本発明の一実施形態における、電子機器およびサーバの内部構成を説明するためのブロック図である。図２では、電子機器に対する例として電子機器１（１１０）の内部構成と、サーバ１５０の内部構成について説明する。また、他の電子機器１２０、１３０、１４０やサーバ１６０も、上述した電子機器１（１１０）またはサーバ１５０と同一または類似の内部構成を備えてよい。
【0019】
電子機器１（１１０）とサーバ１５０は、それぞれ、メモリ２１１、２２１、プロセッサ２１２、２２２、通信モジュール２１３、２２３、および入力／出力インタフェース２１４、２２４を含んでよい。メモリ２１１、２２１は、コンピュータ読取可能な記録媒体であって、ＲＡＭ（ｒａｎｄｏｍ ａｃｃｅｓｓ ｍｅｍｏｒｙ）、ＲＯＭ（ｒｅａｄ ｏｎｌｙ ｍｅｍｏｒｙ）、およびディスクドライブのような永久大容量記憶装置（ｐｅｒｍａｎｅｎｔ ｍａｓｓ ｓｔｏｒａｇｅ ｄｅｖｉｃｅ）を含んでよい。ここで、ＲＯＭやディスクドライブのような永久大容量記憶装置は、メモリ２１１、２２１とは区分される別の永久格納装置として電子機器１（１１０）やサーバ１５０に含まれてもよい。また、メモリ２１１、２２１には、オペレーティングシステムと、少なくとも１つのプログラムコード（一例として、電子機器１（１１０）にインストールされて駆動されるブラウザや特定サービスの提供のために電子機器１（１１０）にインストールされたアプリケーションなどのためのコード）が格納されてよい。このようなソフトウェア構成要素は、メモリ２１１、２２１とは別のコンピュータ読取可能な記録媒体からロードされてよい。このような別のコンピュータ読取可能な記録媒体は、フロッピー（登録商標）ドライブ、ディスク、テープ、ＤＶＤ／ＣＤ－ＲＯＭドライブ、メモリカードなどのコンピュータ読取可能な記録媒体を含んでよい。他の実施形態において、ソフトウェア構成要素は、コンピュータ読取可能な記録媒体ではない通信モジュール２１３、２２３を通じてメモリ２１１、２２１にロードされてもよい。例えば、少なくとも１つのプログラムは、開発者またはアプリケーションのインストールファイルを配布するファイル配布システムがネットワーク１７０を介して提供するファイルによってインストールされるプログラム（一例として、上述したアプリケーション）に基づいて、メモリ２１１、２２１にロードされてよい。
【0020】
プロセッサ２１２、２２２は、基本的な算術、ロジック、および入力／出力演算を実行することにより、コンピュータプログラムの命令を処理するように構成されてよい。命令は、メモリ２１１、２２１または通信モジュール２１３、２２３によって、プロセッサ２１２、２２２に提供されてよい。例えば、プロセッサ２１２、２２２は、メモリ２１１、２２１のような記録装置に格納されたプログラムコードに従って受信される命令を実行するように構成されてよい。
【0021】
通信モジュール２１３、２２３は、ネットワーク１７０を介して電子機器１（１１０）とサーバ１５０とが互いに通信するための機能を提供してもよいし、電子機器１（１１０）および／またはサーバ１５０が他の電子機器（一例として、電子機器２（１２０））または他のサーバ（一例として、サーバ１６０）と通信するための機能を提供してもよい。一例として、電子機器１（１１０）のプロセッサ２１２がメモリ２１１のような記録装置に格納されたプログラムコードに従って生成した要求が、通信モジュール２１３の制御に従ってネットワーク１７０を介してサーバ１５０に伝達されてよい。これとは逆に、サーバ１５０のプロセッサ２２２の制御に従って提供される制御信号や命令、コンテンツ、ファイルなどが、通信モジュール２２３とネットワーク１７０を介して電子機器１（１１０）の通信モジュール２１３を通じて電子機器１（１１０）に受信されてもよい。例えば、通信モジュール２１３を通じて受信したサーバ１５０の制御信号や命令、コンテンツ、ファイルなどは、プロセッサ２１２やメモリ２１１に伝達されてよく、コンテンツやファイルなどは、電子機器１（１１０）がさらに含むことができる格納媒体（上述した永久格納装置）に格納されてよい。
【0022】
入力／出力インタフェース２１４は、入力／出力装置２１５とのインタフェースのための手段であってよい。例えば、入力装置は、キーボードまたはマウスなどの装置を含んでよく、出力装置は、ディスプレイやスピーカのような装置を含んでよい。他の例として、入力／出力インタフェース２１４は、タッチスクリーンのように入力と出力のための機能が１つに統合された装置とのインタフェースのための手段であってもよい。入力／出力装置２１５は、電子機器１（１１０）と１つの装置で構成されてもよい。また、サーバ１５０の入力／出力インタフェース２２４は、サーバ１５０と連結するかサーバ１５０が含むことができる入力または出力のための装置（図示せず）とのインタフェースのための手段であってよい。より具体的な例として、電子機器１（１１０）のプロセッサ２１２がメモリ２１１にロードされたコンピュータプログラムの命令を処理するにあたり、サーバ１５０や電子機器２（１２０）が提供するデータを利用して構成されるサービス画面やコンテンツが入力／出力インタフェース２１４を通じてディスプレイに表示されてよい。
【0023】
また、他の実施形態において、電子機器１（１１０）およびサーバ１５０は、図２の構成要素よりも多くの構成要素を含んでもよい。しかし、大部分の従来技術的構成要素を明確に図に示す必要はない。例えば、電子機器１（１１０）は、上述した入力／出力装置２１５のうちの少なくとも一部を含むように実現されてもよいし、トランシーバ、ＧＰＳ（Ｇｌｏｂａｌ Ｐｏｓｉｔｉｏｎｉｎｇ Ｓｙｓｔｅｍ）モジュール、カメラ、各種センサ、データベースなどのような他の構成要素をさらに含んでもよい。より具体的な例として、電子機器１（１１０）がスマートフォンである場合、一般的にスマートフォンに含まれる加速度センサやジャイロセンサ、カメラモジュール、物理的な各種ボタン、タッチパネルを利用したボタン、入力／出力ポート、振動のための振動器などの多様な構成要素が電子機器１（１１０）にさらに含まれるように実現されてよい。
【0024】
図３は、本発明の一実施形態における、支払いシステムの全体的な構造の例を示した図である。図３は、支払いサーバ３１０、取引履歴データベース３２０、差出人端末３３０、および受取人端末３４０を示している。一例として、支払いサーバ３１０は、上述したサーバ１５０のように実現されてよく、差出人端末３３０と受取人端末３４０は、上述した電子機器１（１１０）のように実現されてよい。取引履歴データベース３２０は、支払いサーバ３１０に含まれるように実現されてもよいが、実施形態によっては、支払いサーバ３１０とは別の装置に含まれ、別の装置と支払いサーバ３１０がネットワークを介して通信することによって支払いサーバ３１０が取引履歴データベース３２０にアクセスするように実現されてもよい。
【0025】
基本的に、支払いサーバ３１０は、差出人端末３３０から送金要請を受信することによって、対象者である受取人のアカウントを識別し、識別された受取人のアカウントに、要請された金額が送金されるように処理することができる。基本的に、支払いサーバ３１０は、差出人端末３３０からネットワークを介して受信した送金要請と関連して差出人の引出口座と受取人の受取口座を特定することができる。一例として、支払いサーバ３１０に適用される送金技術に応じて、送金要請が差出人の引出口座と受取人の受取口座を含んでもよいし、支払いサーバ３１０がユーザの口座を予め登録しておき、送金要請に含まれる識別情報（ユーザ識別子、メッセンジャーアカウント識別子、電話番号など）を利用して、対応する口座を抽出してもよい。このような送金技術自体は、周知の従来技術から当業者が容易に理解することができるであろう。
【0026】
このとき、支払いサーバ３１０は、特定された引出口座と受取口座を利用して取引履歴データベース３２０を検索することによって、差出人と受取人との間に過去取引履歴が存在するかを判断することができ、このような過去取引履歴の存在の有無に応じて互いに異なる受取人認証方式を適用してよい。例えば、差出人の引出口座と受取人の受取口座との間に過去取引履歴が存在する場合には、受取人を疑う必要性が低くなるため、支払いサーバ３１０は、受取人確認のための別途の手順を省略して要請された送金を処理してよい。送金の処理自体は、周知の従来技術から当業者が容易に理解することができるであろう。
【0027】
この反面、差出人と受取人との間の過去取引履歴が存在しない場合、支払いサーバ３１０は、受取人を確認するための手順を行ってよい。先ず、支払いサーバ３１０は、受取人と他のユーザとの取引履歴、差出人と受取人との間のメッセージングサービスを利用した会話記録、および差出人が指定した受取口座リストのうちの少なくとも１つに基づいて受取人の危険性程度を計算してよく、計算された受取人の危険性程度に応じて受取人の認証方式を決定してよい。
【0028】
例えば、支払いサーバ３１０は、受取人の受取口座を利用し、他のユーザとの取引が行われた回数と期間のうちの少なくとも一方によって第１危険性程度を計算してよい。受取人の受取口座が他のユーザとの取引に随分前から利用されていた口座であれば、受取人の第１危険性程度は相対的に低くなる。したがって、第１危険性程度は、前記期間が長いほど低くなるように計算されてよい。さらに、前記回数も、受取人の第１危険性程度を判断するために活用されてよい。この場合、第１危険性程度は、前記回数が多いほど低くなるように計算されてよい。さらに、前記回数と前記期間の両方が利用される場合、前記期間にさらに高い加重値を付与して第１危険性程度が計算されてよい。これは、ここ最近多くの回数で取引が行われた場合には、取引が行われた回数の信頼性が低くなるためである。
【0029】
他の例として、支払いサーバ３１０は、差出人と受取人との間のメッセージングサービスを利用した会話記録の存在の有無、会話記録から抽出される会話回数、および会話記録から抽出される会話期間のうちの少なくとも１つによって第２危険性程度を計算してよい。例えば、差出人と受取人が長期間にわたってメッセージングサービスで多くの会話を行っていれば、受取人の危険性は低いと判断し、支払いサーバ３１０は第２危険性程度が相対的に低くなるように計算してよい。より具体的な例として、支払いサーバ３１０は、会話記録が存在する場合、前記会話回数が高いほど、さらに前記会話期間が長いほど、相対的に第２危険性程度が低くなるように第２危険性程度を計算してよい。このために、支払いサーバ３１０は、メッセージングサービスを提供するメッセンジャーサーバを含んでユーザ間の会話記録を直接格納および管理してもよいし、別途で実現されるメッセンジャーサーバ（一例として、サーバ１６０）とネットワークを介して通信するように連携させて差出人と受取人との会話記録の提供を受けてもよい。
【0030】
他の例として、ユーザＡとユーザＢがメッセンジャー会話を行った日（一例として、５月５日）以後にユーザＢが新しい銀行口座を受取口座として支払いサーバ３１０に登録（一例として、５月７日）する場合が考えられる。このような受取口座の登録以後にユーザＡとユーザＢが一定期間以上にわたってメッセンジャー会話を行い（一例として、５月８日～５月９日）、その後にユーザＡがユーザＢに送金（一例として、５月１０日）をしようとする状況について考慮してみる。この場合、支払いサーバ３１０は、メッセンジャー会話記録による期間と受取口座の登録日に基づいて第２危険性程度を計算してもよい。
【0031】
また他の例として、支払いサーバ３１０は、差出人が指定した受取口座リストに受取人の受取口座が含まれているかどうかによって第３危険性程度を計算してよい。一例として、支払いサーバ３１０は、差出人が指定した受取口座リストに受取人の受取口座が含まれている場合には、第１危険性程度と第２危険性程度の計算を省略し、受取人の危険性程度を閾値以下に設定してよい。
【0032】
このように、受取人の危険性程度は、上述した第１危険性程度、第２危険性程度、および第３危険性程度のうちの少なくとも１つを利用して計算されてよい。支払いサーバ３１０は、受取人の危険性程度が閾値以上の場合には追加の受取人本人確認手順に進んでよく、受取人の危険性程度が閾値未満の場合には受取人本人確認手順を行う必要なく、直ぐに送金手順に進んでよい。
【0033】
受取人本人確認手順は、支払いサーバ３１０が差出人に警告メッセージを送信する第１プロセス、および受取人に本人証明メッセージを要請する第２プロセスのうちの少なくとも一方のプロセスを処理することによって行われてよい。一例として、第１プロセスは、差出人に、受取人を確認するよう警告するために、ネットワークを介して警告メッセージを差出人端末３３０に送信するプロセスであってよい。この場合、支払いサーバ３１０は、差出人端末３３０から警告メッセージに対する確認応答を受信することによって差出人の送金要請を処理することができる。また、第２プロセスは、受取人に、本人証明メッセージを送信するよう要請するプロセスであってよい。この場合、支払いサーバ３１０は、本人証明メッセージを直接認証するのではなく、ネットワークを介して本人証明メッセージを差出人端末３３０に伝達し、差出人端末３３０からネットワークを介して本人証明メッセージに対する確認応答を受信した場合に差出人の送金要請を処理することができる。このために、本人証明メッセージは、受取人が受取人本人であることを差出人が認証することができる情報を含んでよい。例えば、本人証明メッセージは、差出人と受取人だけが分かる内容に関する情報を含んだり、受取人本人を撮影した写真（撮影時間情報を含むイメージ情報）を含んだりするなど、受取人が、差出人に受取人本人を認証させるために生成した情報を含んでよい。
【0034】
【0035】
段階４１０は、口座特定過程であって、支払いサーバ３１０は、段階４１０において、差出人の引出口座および受取人の受取口座を特定することができる。差出人の送金要請に従って差出人の引出口座および受取人の受取口座を特定する方法については上述したとおりである。
【0036】
段階４２０は、取引履歴検索過程であって、支払いサーバ３１０は、段階４２０において、取引履歴データベース３２０から差出人の引出口座と受取人の受取口座との間の過去取引履歴を検索することができる。
【0037】
段階４３０は、取引履歴存在の有無を判断する過程であって、支払いサーバ３１０は、段階４３０において、取引履歴データベース３２０に、差出人の引出口座と受取人の受取口座との間の過去取引履歴が存在するかどうかを決定することができる。このとき、取引履歴が存在する場合には段階４６０が実行されてよく、取引履歴が存在しない場合には段階４４０が実行されてよい。
【0038】
段階４４０は、危険性程度計算過程であって、支払いサーバ３１０は、段階４４０において、受取人の危険性程度を計算することができる。受取人の危険性程度を計算する例については上述したとおりである。
【0039】
段階４５０は、危険性程度が第１閾値未満であるかどうかを判断する過程であって、支払いサーバ３１０は、段階４５０において、受取人の危険性程度と予め設定された第１閾値とを比較し、危険性程度が第１閾値未満の場合には段階４６０を、危険性程度が第１閾値以上の場合には段階４５１を実行してよい。
【0040】
段階４６０は、送金処理過程であって、支払いサーバ３１０は、段階４６０において、差出人の送金要請に従って要請された金額を、差出人の引出口座から受取人の受取口座に振り込むための過程を処理することができる。例えば、支払いサーバ３１０は、引出口座と受取口座が開設された銀行のサーバと通信して要請された金額の送金を処理してもよいし、引出口座から支払いサーバ３１０と関連する基本口座に要請金額を振り込んだ後、基本口座から受取人の受取口座に要請された金額を振り込むなどのように、周知の従来技術の１つを利用して要請金額の送金を処理してよい。
【0041】
段階４５１は、危険性程度が第２閾値を超過するかどうかを判断する過程であって、支払いサーバ３１０は、段階４５１において、受取人の危険性程度と予め設定された第２閾値とを比較し、危険性程度が第２閾値を超過する場合には段階４５２を、危険性程度が第２閾値以下の場合には段階４５４を実行してよい。
【0042】
段階４５２は、本人証明メッセージを要求する過程であって、支払いサーバ３１０は、段階４５２において、受取人に本人証明メッセージを伝達することを要請することができる。本人証明メッセージについては上述したとおりである。
【0043】
段階４５３は、差出人による受取人確認過程であって、支払いサーバ３１０は、受取人から伝達された本人証明メッセージを差出人に送信し、差出人が本人証明メッセージから受取人を認証することができる。支払いサーバ３１０は、差出人から本人証明メッセージに対する確認応答を受信することによって段階４６０を実行して送金を処理してよいが、本人証明メッセージに対する確認応答が差出人から受信されない場合（差出人が本人証明メッセージから受取人を認証できないことによって取消応答が受信されるか、または確認応答が一定期間を過ぎても受信されない場合）、送金を取り消してよい。
【0044】
段階４５４は、警告メッセージ送信過程であって、支払いサーバ３１０は、段階４５４において、受取人の危険性程度が第１閾値以上であるが第２閾値以下である場合、差出人に警告メッセージを送信することができる。このとき、段階４５３は、支払いサーバ３１０が警告メッセージに対する差出人の確認応答を受信する過程であってよい。支払いサーバ３１０は、警告メッセージに対する差出人の確認応答を受信した場合には段階４６０を実行して送金を処理してよいが、警告メッセージに対する確認応答が差出人から確認されない場合（警告メッセージを受信した差出人から取消応答が受信されるか、または確認応答が一定期間を過ぎても受信されない場合）、送金を取り消してよい。
【0045】
このように、支払いサーバ３１０は、取引履歴の存在の有無と受取人の危険性程度に応じて段階的に、受取人を認証するための方式を異なるものとすることができ、必要によっては、受取人自らが本人を証明するための情報を提供して差出人が受取人を直接認証することにより、さらに安全な送金処理が可能となる。
【0046】
図５は、本発明の一実施形態における、本人証明メッセージが伝達された差出人端末の画面例を示した図である。図５は、差出人端末３３０に、受取人の本人証明メッセージ「私のニックネームはＯＯ」が表示された画面５１０を示している。差出人端末３３０に伝達された受取人の本人証明メッセージは、差出人端末３３０の画面５１０にポップアップウィンドウ５２０のような形態で表示されてよい。このような本人証明メッセージの表示形態は一例に過ぎず、実施形態によって多様に異なってもよいことは、当業者が容易に理解することができるであろう。
【0047】
差出人は、このような本人証明メッセージから受取人を認証してよく、認証結果に応じて「確認」ボタン５３０または「送金取消」ボタン５４０を選択（一例として、タッチスクリーン環境で各ボタンが表示された領域を指でタッチ）することにより、支払いサーバ３１０は、差出人に受取人を確認させ、送金を進めたり取り消したりすることが可能となる。
【0048】
図６は、本発明の一実施形態における、警告メッセージが伝達された差出人端末の画面例を示した図である。図６は、差出人端末３３０に伝達された警告メッセージが表示された画面６１０を示している。支払いサーバ３１０は、受取人や口座番号を再度確認することを警告するための警告メッセージを差出人端末３３０に送信してよく、警告メッセージに対する確認応答を差出人に要請してよい。差出人が「確認」ボタン６３０または「送金取消」ボタン６４０を選択（一例で、タッチスクリーン環境で各ボタンが表示された領域を指でタッチ）することにより、支払いサーバ３１０は、送金を進めたり取り消したりすることが可能となる。
【0049】
図７は、本発明の一実施形態における、支払いサーバのプロセッサが含むことができる構成要素の例を示したブロック図であり、図８は、本発明の一実施形態における、支払いサーバが実行することができる支払い方法の例を示したフローチャートである。本実施形態では、上述した支払いサーバ３１０がサーバ１５０によって実現された例について説明する。
【0050】
図７は、サーバ１５０のプロセッサ２２２が含むことができる構成要素として、口座特定部７１０、取引履歴検索部７２０、危険性程度計算部７３０、認証方式決定部７４０、および送金要請処理部７５０を示している。このようなプロセッサ２２２およびプロセッサ２２２の構成要素は、図８の支払い方法に含まれる段階８１０～段階８６０を実行してよい。このとき、プロセッサ２２２およびプロセッサ２２２の構成要素は、メモリ２２１が含むオペレーティングシステムのコードおよび／または少なくとも１つのコンピュータプログラムのコードによる命令（ｉｎｓｔｒｕｃｔｉｏｎ）を実行するように実現されてよい。ここで、プロセッサ２２２の構成要素は、サーバ１５０に格納されたコンピュータプログラムのコードが提供する制御命令に従ってプロセッサ２２２によって実行される、プロセッサ２２２の互いに異なる機能（ｄｉｆｆｅｒｅｎｔ ｆｕｎｃｔｉｏｎｓ）の表現であってよい。例えば、プロセッサ２２２は、サーバ１５０の制御と関連する命令がロードされたメモリ２２１から必要な制御命令を読み取ってよく、読み取った制御命令に従って以下で説明される段階８１０～段階８６０を実行するようにサーバ１５０を制御してよい。
【0051】
段階８１０において、口座特定部７１０は、差出人の端末からネットワークを介して受信した送金要請と関連して差出人の引出口座および受取人の受取口座を特定することができる。
【0052】
段階８２０において、取引履歴検索部７２０は、引出口座と受取口座との間の過去取引履歴を取引履歴データベースから検索することができる。ここで、取引履歴データベースは、図３を参照しながら上述した取引履歴データベース３２０に対応してよい。
【0053】
段階８３０において、危険性程度計算部７３０は、過去取引履歴が存在しない場合には、受取人の他のユーザとの取引履歴、差出人と受取人との間のメッセージングサービスを利用した会話記録、および差出人が指定した受取口座リストのうちの少なくとも１つに基づいて、受取人の危険性程度を計算することができる。例えば、危険性程度計算部７３０は、受取人の受取口座を利用して他のユーザと取引が行われた回数および期間のうちの少なくとも一方によって計算される第１危険性程度、差出人と受取人との間のメッセージングサービスを利用した会話記録の存在の有無、会話記録から抽出される会話回数、および会話記録から抽出される会話期間のうちの少なくとも１つによって計算される第２危険性程度、並びに差出人が指定した受取口座リストに受取人の受取口座が含まれているかによって計算される第３危険性程度のうちの少なくとも１つを利用して受取人の危険性程度を計算してよい。
【0054】
段階８４０において、認証方式決定部７４０は、計算された受取人の危険性程度に基づいて受取人の認証方式を決定することができる。このとき、認証方式決定部７４０は、計算された受取人の危険性程度により、受取人に本人証明メッセージを要請する第２プロセスを処理してよい。
【0055】
段階８５０において、送金要請処理部７５０は、受取人に本人証明メッセージを要請した場合、受取人の端末から受信した本人証明メッセージを差出人に送信することができる。
【0056】
段階８６０において、送金要請処理部７５０は、差出人から本人証明メッセージに対する確認応答を受信した場合、差出人の送金要請を処理することができる。
【0057】
以上、図８の段階８１０～段階８６０は、取引履歴が存在せず、受取人に対して計算された危険性程度が予め設定された第２閾値を超過する場合の実施形態に対応してよい。
【0058】
図９は、本発明の一実施形態における、警告メッセージを送信する支払い方法の例を示したフローチャートである。図９の支払い方法は、図８の段階８１０～段階８６０のうちの段階８１０～段階８４０を含んでよく、段階９１０および段階９２０をさらに含んでよい。段階９１０および段階９２０は、段階８４０以後に実行されてよい。
【0059】
先ず、段階８４０において、認証方式決定部７４０は、計算された受取人の危険性程度に基づいて受取人の認証方式を決定することができる。このとき、認証方式決定部７４０は、図８とは異なり、計算された受取人の危険性程度により、差出人に警告メッセージを送信する第１プロセスを処理してよい。
【0060】
段階９１０において、送金要請処理部７５０は、差出人に送信した警告メッセージに対する確認応答を差出人の端末から受信してよい。
【0061】
段階９２０において、送金要請処理部７５０は、警告メッセージに対する確認応答の受信によって差出人の送金要請を処理することができる。
【0062】
このような図９の段階８４０、段階９１０、段階９２０は、段階８２０の検索で取引履歴が存在せず、受取人に対して計算された危険性程度が予め設定された第１閾値以上であり、かつ第２閾値以下である場合の実施形態に対応してよい。
【0063】
図８の段階８２０の検索で取引履歴が存在した場合、プロセッサ２２２は、要請された送金を、受取人本人確認の手順を経ずに処理してよい。また、プロセッサ２２２は、取引履歴が存在しない場合であっても、受取人の危険性程度が予め設定された第１閾値未満であれば、受取人本人確認の手順を経ずに送金を処理してよい。これだけでなく、プロセッサ２２２は、本人証明メッセージに対して差出人からの確認応答や警告メッセージに対する差出人からの確認応答がない場合には、送金処理を取り消してよい。
【0064】
以上のように、本発明の実施形態によると、送金を要請する差出人と受取人との間の過去取引履歴の存在の有無に応じて受取人を認証するための方式を選択して進行することができる。さらに、送金過程において、差出人と受取人との間の過去取引履歴が存在しない場合、受取人が本当に本人であることを証明するための認証方式を追加で取り入れることにより、差出人が受取人を確信できるようにして送金の差出人を保護して、誤った送金を防ぐことができる。
【0065】
上述したシステムまたは装置は、ハードウェア構成要素、ソフトウェア構成要素、またはハードウェア構成要素とソフトウェア構成要素との組み合わせによって実現されてよい。例えば、実施形態で説明された装置および構成要素は、例えば、プロセッサ、コントローラ、ＡＬＵ（ａｒｉｔｈｍｅｔｉｃ ｌｏｇｉｃ ｕｎｉｔ）、デジタル信号プロセッサ、マイクロコンピュータ、ＦＰＧＡ（ｆｉｅｌｄ ｐｒｏｇｒａｍｍａｂｌｅ ｇａｔｅ ａｒｒａｙ）、ＰＬＵ（ｐｒｏｇｒａｍｍａｂｌｅ ｌｏｇｉｃ ｕｎｉｔ）、マイクロプロセッサ、または命令を実行して応答することができる様々な装置のように、１つ以上の汎用コンピュータまたは特殊目的コンピュータを利用して実現されてよい。処理装置は、オペレーティングシステム（ＯＳ）および前記ＯＳ上で実行される１つ以上のソフトウェアアプリケーションを実行してよい。また、処理装置は、ソフトウェアの実行に応答し、データにアクセスし、データを格納、操作、処理、および生成してもよい。理解の便宜のために、１つの処理装置が使用されるとして説明される場合もあるが、当業者は、処理装置が複数個の処理要素および／または複数種類の処理要素を含んでもよいことが理解できるであろう。例えば、処理装置は、複数個のプロセッサまたは１つのプロセッサおよび１つのコントローラを含んでよい。また、並列プロセッサのような、他の処理構成も可能である。
【0066】
ソフトウェアは、コンピュータプログラム、コード、命令、またはこれらのうちの１つ以上の組み合わせを含んでもよく、所望のとおりに動作するように処理装置を構成したり、独立的または集合的に処理装置に命令したりしてよい。ソフトウェアおよび／またはデータは、処理装置に基づいて解釈されたり、処理装置に命令またはデータを提供したりするために、いかなる種類の機械、コンポーネント、物理装置、仮想装置、コンピュータ格納媒体または装置に永久的または一時的に具現化されてよい。ソフトウェアは、ネットワークによって接続されたコンピュータシステム上に分散され、分散された状態で格納されても実行されてもよい。ソフトウェアおよびデータは、１つ以上のコンピュータ読取可能な記録媒体に格納されてよい。
【0067】
実施形態に係る方法は、多様なコンピュータ手段によって実行可能なプログラム命令の形態で実現されてコンピュータ読取可能な媒体に記録されてよい。コンピュータ読取可能な媒体は、プログラム命令、データファイル、データ構造などを単独でまたは組み合わせて含んでよい。媒体に記録されるプログラム命令は、実施形態のために特別に設計されて構成されたものであってもよいし、コンピュータソフトウェア当業者に公知な使用可能なものであってもよい。コンピュータ読取可能な記録媒体の例としては、ハードディスク、フロッピー（登録商標）ディスク、および磁気テープのような磁気媒体、ＣＤ－ＲＯＭ、ＤＶＤのような光媒体、フロプティカルディスク（ｆｌｏｐｔｉｃａｌ ｄｉｓｋ）のような光磁気媒体、およびＲＯＭ、ＲＡＭ、フラッシュメモリなどのようなプログラム命令を格納して実行するように特別に構成されたハードウェア装置が含まれる。プログラム命令の例は、コンパイラによって生成されるもののような機械語コードだけではなく、インタプリタなどを使用してコンピュータによって実行される高級言語コードを含む。
【0068】
以上のように、実施形態を、限定された実施形態と図面に基づいて説明したが、当業者であれば、上述した記載から多様な修正および変形が可能であろう。例えば、説明された技術が、説明された方法とは異なる順序で実行されたり、かつ／あるいは、説明されたシステム、構造、装置、回路などの構成要素が、説明された方法とは異なる形態で結合されたりまたは組み合わされたり、他の構成要素または均等物によって代替されたり置換されたとしても、適切な結果を達成することができる。
【0069】
したがって、異なる実施形態であっても、特許請求の範囲と均等なものであれば、添付される特許請求の範囲に属する。
【符号の説明】
【0070】
３１０：支払いサーバ
３２０：取引履歴データベース
３３０：差出人端末
３４０：受取人端末
３２０：取引履歴データベース
３３０：差出人端末
３４０：受取人端末
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】