特許 6799142 認証方法及びシステム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6799142

(24)【登録日】2020年11月24日

(45)【発行日】2020年12月9日

(54)【発明の名称】認証方法及びシステム

(51)【国際特許分類】

   G06F 21/31 20130101AFI20201130BHJP

   H04L 9/32 20060101ALI20201130BHJP

   G06F 21/44 20130101ALI20201130BHJP

【ＦＩ】

   G06F21/31

   H04L9/00 673A

   G06F21/44

【請求項の数】6

【全頁数】23

(21)【出願番号】特願2019-507057(P2019-507057)

(86)(22)【出願日】2017年3月28日

(65)【公表番号】特表2019-517087(P2019-517087A)

(43)【公表日】2019年6月20日

(86)【国際出願番号】KR2017003340

(87)【国際公開番号】WO2017188610

(87)【国際公開日】20171102

【審査請求日】2018年10月23日

(31)【優先権主張番号】10-2016-0049777

(32)【優先日】2016年4月25日

(33)【優先権主張国】KR

(31)【優先権主張番号】10-2016-0069790

(32)【優先日】2016年6月3日

(33)【優先権主張国】KR

(73)【特許権者】

【識別番号】518375926

【氏名又は名称】イーストーム カンパニー，リミテッド

(74)【代理人】

【識別番号】110000338

【氏名又は名称】特許業務法人ＨＡＲＡＫＥＮＺＯ ＷＯＲＬＤ ＰＡＴＥＮＴ ＆ ＴＲＡＤＥＭＡＲＫ

(72)【発明者】

【氏名】ウ，ジョン ヒョン

【審査官】 岸野 徹

(56)【参考文献】

【文献】 国際公開第２０１４／２０２７１８（ＷＯ，Ａ１）

【文献】 特開２０１４−２１５６２０（ＪＰ，Ａ）

【文献】 特開２００９−２９５０３７（ＪＰ，Ａ）

【文献】 特開２００７−３２３５８０（ＪＰ，Ａ）

【文献】 韓国公開特許第２０１４−０１０６３６０（ＫＲ，Ａ）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｆ ２１／３１

Ｇ０６Ｆ ２１／４４

Ｈ０４Ｌ ９／３２

(57)【特許請求の範囲】

【請求項1】

利用者中心の認証を行う認証システムであって、
オンラインサービスサーバーに関する認証手続きを代行する認証サービスコンポーネントと、上記オンラインサービスサーバーに接続する接続端末機に関する認証手続きを代行するモバイル認証エージェントコンポーネントを含み、
上記オンラインサービスサーバーは、上記接続端末機を介して上記オンラインサービスサーバーへのアクセス要求があるとき、利用者ＩＤ入力窓は表示されているが、利用者暗号入力窓は表示されていないサービスログイン画面を上記接続端末機の画面に表示させ、上記サービスログイン画面の利用者ＩＤ入力窓への利用者ＩＤの入力が完了し、上記オンラインサービスサーバーから利用者ＩＤが伝送されると、上記認証サービスコンポーネントは、利用者ＩＤに対応するモバイル認証エージェントコンポーネントを確認し、認証暗号値を、確認された上記モバイル認証エージェントコンポーネントおよび上記接続端末機がアクセスする上記オンラインサービスサーバーにそれぞれ伝送し、
上記オンラインサービスサーバーは、上記認証暗号値を受信すると、受信した上記認証暗号値を上記サービスログイン画面に表示させ、
上記モバイル認証エージェントコンポーネントは、上記認証暗号値を受信すると、受信した上記認証暗号値をモバイル認証機の画面に表示させ、
上記認証暗号値は、所定の有効期間に利用可能なワンタイムパスワード値であり、
上記モバイル認証エージェントコンポーネントはソフトウェアアプリケーションであり、上記モバイル認証機にインストールされており、上記モバイル認証機はモバイル端末であって、上記接続端末機とは異なるものであり、
サービスログイン画面に認証暗号が表示されることにより、上記モバイル認証エージェントコンポーネントから伝送された、認証暗号値を検証するための暗号検証値、または認証暗号値に対応する認証同意値を受信し、かつ、上記モバイル認証機の画面に表示されている認証暗号値と相互に一致するとき、上記認証サービスコンポーネントは、上記オンラインサービスサーバーのサービスが認証されているかを決定し、上記接続端末機を介してアクセス要求した利用者かどうか決定するための利用者認証が認証されるかを決定するためのサービス認証が、バッチ処理されるように、認証アクセスサービスを上記オンラインサービスサーバーに送信する、認証システム。

【請求項2】

上記サービスログイン画面には、認証暗号表示窓が含まれ、
上記オンラインサービスサーバーは、上記認証暗号値を受信すると、上記認証暗号値を上記認証暗号表示窓に表示し、上記サービスログイン画面では、対応する認証暗号値の有効時間の経過が、グラフィック効果で視覚的に案内するように上記認証暗号表示窓に反映されて、表示され、
上記認証暗号値を受信すると、上記モバイル認証エージェントコンポーネントは、上記サービスログイン画面に表示される上記認証暗号表示窓と同じグラフィック効果を持つグラフィカルユーザーインターフェイス（ＧＵＩ）が反映された認証暗号表示窓を上記モバイル認証機の画面に表示し、上記認証暗号値を表示する、請求項１に記載の認証システム。

【請求項3】

上記認証暗号値は、上記認証暗号表示窓内に数字列または文字列に表示され、上記有効時間は、上記認証暗号表示窓内でタイムラップスバー（Ｔｉｍｅ Ｌａｐｓｅ Ｂａｒ）形態で表示され、上記有効時間の経過を視覚的に案内することを特徴とする、請求項２に記載の認証システム。

【請求項4】

上記認証サービスコンポーネントは、上記有効時間の経過によって上記認証暗号値を更新生成し、上記オンラインサービスサーバー及び上記モバイル認証エージェントコンポーネントに再度伝送し、
上記認証暗号値の更新によって認証暗号値と上記有効時間は、上記認証暗号表示窓内で更新して表出されることを特徴とする、請求項３に記載の認証システム。

【請求項5】

認証成功メッセージの伝送によって上記接続端末機に関するオンラインサービスサーバーへのサービス使用が許容された後、上記モバイル認証エージェントコンポーネントから上記認証サービスコンポーネントに接続解止値が受信される場合、
上記認証サービスコンポーネントは、上記接続解止値の伝送主体がサービス接続者に相応する登録されたモバイル認証エージェントコンポーネントであるか否かを確認し、登録されたモバイル認証エージェントコンポーネントから上記接続解止値が受信されたものと確認された場合、上記オンラインサービスサーバーに接続解止要請メッセージを伝送することを特徴とする、請求項１に記載の認証システム。

【請求項6】

上記認証暗号値を受信したモバイル認証エージェントコンポーネントから上記認証サービスコンポーネントに接続遮断値が受信される場合、
上記認証サービスコンポーネントは、上記接続遮断値の伝送主体がサービス接続者に相応する登録されたモバイル認証エージェントコンポーネントであるかいな否を確認し、登録されたモバイル認証エージェントコンポーネントから上記接続遮断値が受信されたものと確認された場合、上記オンラインサービスサーバーに接続遮断要請メッセージを伝送することを特徴とする、請求項１に記載の認証システム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、利用者認証または／及びサービス認証と係る認証方法及びシステムに関する。

【背景技術】

【0002】

各種ウェブサイト、モバイルアプリ、金融または決済サービスなどのアクセス過程で利用者認証の重要性が益々増加している。また、最近は、フィッシングなどの危険性が高くなり、該当サービスサイトが虚偽サイトではないことを確認する必要性に応じて、サービス認証という概念も導入している。

【0003】

先ず、利用者本人認証のために最も一般的に利用されている方式は、該当利用者のＩＤとパスワード（Ｐａｓｓｗｏｒｄ）を活用する方式がある。しかし、利用者ＩＤ及びパスワードを活用する方式は、該当情報の洩れまたは奪取が容易で、保安性が高くないという問題点がある。

【0004】

ここで、最近ではＳＭＳ（Ｓｈｏｒｔ Ｍｅｓｓａｇｅ Ｓｅｒｖｉｃｅ）を活用する方式として、オンラインウェブ（Ｗｅｂ）やモバイルアプリ（Ａｐｐ）サービスで利用者確認（つまり、サービス利用者本人確認）または機器所持確認のためにＳＭＳを利用した本人認証サービスまたは機器所持認証サービスが広く利用されている。

【0005】

通常、ＳＭＳを利用した本人認証サービスは、利用者より入力される利用者情報（例えば、氏名、住民登録番号、携帯電話番号など）と通信会社に加入されている会員情報を比べる実名確認サービスであって、無線通信網を通して入力されたモバイルフォン番号へＳＭＳ認証値を伝送し、該モバイルフォンの利用者が所定有効時間内に該認証値を認証窓に入力して、伝送された認証値と入力された認証値が互いに一致すれば、入力された利用者情報と該利用者のモバイルフォンの所持を同時に確認する本人認証サービスである（図１参照）。

【0006】

また、ＳＭＳを利用したモバイルフォン所持認証サービスは、通信会社の会員ＤＢにかかわらず、サービスシステムが利用者より入力されたモバイルフォン番号で合ってるのか確認するために無線通信網を通して入力されたモバイルフォン番号にＳＭＳ認証値を伝送し、該当モバイルフォン利用者が有効時間内に認証窓に認証値を入力し、互いに一致すれば該当利用者のモバイルフォン所持可否を確認する機器所持認証サービスである。

【0007】

しかし、ＳＭＳを利用した認証サービスを通してハッカーが利用者を成り済ます事故が頻繁に発生し、ＳＭＳを利用した認証サービスがこれ以上信頼できる認証手段ではなくなった。ＳＭＳ認証が容易くハッキングされる最大の理由は、ＳＭＳ認証サービスで使われる個人情報（例えば、氏名、携帯番号、住民登録番号、電子メールなど）が大規模個人情報流出事故によって既にハッカーに露出された状態で、またターゲットとなったモバイルフォン番号や電子メールアカウントにマルウェア（ｍａｌｗａｒｅ）設置を誘導するＳＭＳや電子メールなどが伝送され、利用者が悪性コードやマルウェアを設置するようになると、該当モバイルフォンに伝送されるＳＭＳをハッカーが横取りすることができるためである。

【0008】

よって、利用者のモバイルフォンに伝送されたＳＭＳがハッカーによって取られても、本人のモバイルフォンのみで該当ＳＭＳ認証値が検証できるようにする新しいＳＭＳ基盤の認証技術が必要である。

【0009】

数十個のオンラインサービスが活用されながら、利用者の立場での暗号管理はさらに大変なことになっている。容易に暗号管理をするために憶えやすい単純な暗号一つで使っていると、全てのサービスの保安が不安になり、逆にサービスごとに様々な暗号を使うと憶えにくくなる。また、保安政策にしたがって周期的に暗号を変えなければならないなら、利用者の暗号管理負担は加重される。

【0010】

また、保安性と暗号管理負担を改善するために導入されているＯＴＰトークンやモバイルアクセス承認アプリの場合、暗号を易しくし、所持している機器を通して利用者認証をすることで保安性と便利性が高くなるが、最初接続したサービスが実際サービスを装ったハッキングサービスなら、利用者は接続したサービスの真偽が分からなくてファーミング攻撃を防ぐことができない。

【0011】

これは、電算サービスの認証概念自体が、利用者が認証情報を提示してサーバーがこれを判断するサービス中心の認証技術に起因する問題で、利用者が本物を装った間違ったサービスに会った場合、解決できない問題である。

【0012】

したがって、既存のサービス中心の利用者認証技術は、利用者が暗号を管理することが負担なだけでなく費用発生を引き起こし、パスワードの類推攻撃や中間子攻撃に脆弱であるしかないので、このような限界を克服できる新しい概念の認証技術（つまり、利用者中心の認証技術）が必要である。

【0013】

また、別の側面において、利用者がオンラインサービスの暗号を覚えないで利用者を認証できるようにするキルパスワードムーブメントが活性化しながら、利用者が所持したスマートフォンを通して正常の利用者であるか否かを確認する認証技術が拡散されている。

【0014】

代表的な従来技術の作動流れ（図８参照）をよく見れば、利用者がオンライン接続端末機を利用してオンラインサービスに接続してＩＤを入力すれば、オンラインサービスで利用者が事前登録したモバイル認証アプリにプッシュ通知を伝送する。これを受信したモバイル認証アプリから利用者に接続許容可否を表示し、利用者がサービス接続に対する同意を入力すれば、モバイル認証アプリからオンラインサービスに利用者本人であることを確認できる認証値を伝送する。これによって、接続端末機に係るオンラインサービスへのログインを許容する。

【0015】

しかし、利用者が端末機を用いてサービスへのアクセスを試みた時、利用者の意図とは違い、利用者接続を奪取するために作動しているファーミングサービスに接続して利用者がＩＤを入力する場合、該当ＩＤはハッカーに提供される。したがって、該当時点で確保されたＩＤをハッカーの端末機を利用して正常のサービスにアクセスして入力すれば、利用者に正常的な認証要請プッシュ通知が伝送する。この時、利用者は自分の接続による認証と誤解してモバイル認証アプリで接続を承認すれば、ハッカーの接続を承諾する状況が発生する。

【0016】

また、利用者のＩＤは、様々なサービスで同一文字列にしょっちゅう登録されて公開的に利用されるので、ＩＤを確保したハッカーがオンラインサービスにＩＤを入力する場合、該ＩＤの利用者のスマートフォンにハッカーが認証を試みる度に随時不要な認証要請試みを受けなければならない。また、認証要請選択過程で利用者が操作の未熟によって接続を許容をする場合、ハッカーがサービスに接続することになる。

【0017】

また、利用者がＩＤを入力した後、サービスが利用者にサービス暗号を提示し、利用者がサービス暗号検証機モバイルアプリでサービス暗号を検証し、利用者接続可否を選択するサービス認証技術でも、利用者がサービスが提示する暗号とモバイルアプリが提示する暗号を確かに確認しない場合がたびたび発生する。もし、利用者がデザインが似ているパターンが表示されたことだけを見てモバイルサービス暗号生成器アプリに無条件接続を承認する場合、実際のサービスを装ったファーミングサイトに接続するようになり、ハッカーに接続を許容することになる。

【0018】

したがって、既存のＩＤとスマート機器で認証を行う場合、サービスを装った中間子攻撃にかかったり、頻繁な認証要請による操作未熟が発生する場合、ハッカーの接続を許容するようになるが、これを克服できる新しい技術が必要である。

【発明の概要】

【発明が解決しようとする課題】

【0019】

上述した問題点を解決するために、本発明の第１側面によれば、ＳＭＳを利用した本人認証サービスを提供するにあたり、本人確認サービスに接続する該当利用者のモバイルフォンのアクセス情報とモバイルフォンに受信されたＳＭＳ認証値を利用してモバイルフォン利用者が本人であることを認証する利用者認証サービスであって、該当モバイルフォンにのみＳＭＳ認証値が有効であるようにする利用者認証サービスに対する方法及びシステムを提供する。

【0020】

本発明の第２側面によれば、オンラインサービスを利用するために利用者を認証するにあたり、サービス中心で利用者暗号情報を検証するのではなく、利用者中心でサービス暗号を検証するとともに、利用者を認証する利用者中心のサービス認証に対する方法及びシステムを提供する。

【0021】

本発明の第３側面によれば、暗号のない便利なオンラインサービスを提供するために、利用者ＩＤと利用者のモバイル機器を利用した利用者認証を提供するオンラインサービスにおいて、利用者本人の要請による認証要請ではなく、ハッカーによる認証要請が該当利用者のモバイル機器に入ってくる時、利用者のごまかしや間違いでモバイル機器で利用者認証を許容したとしても、利用者が認証同意後、現在サービスに接続された端末機にサービスを中断させられるようにしたり、該当サービスにハッカーによって利用者ＩＤが入力されてサービスサーバーに認証要請が受付られれば、これを事前に遮断する方法及びシステムを提供する。

【課題を解決するための手段】

【0022】

本発明の一側面によれば、ＳＭＳ（Ｓｈｏｒｔ Ｍｅｓｓａｇｅ Ｓｅｒｖｉｃｅ）を利用して利用者認証を行い、認証サービスコンポーネント及び検証コンポーネントを含む認証サービスシステムが開始される。

【0023】

上記認証サービスコンポーネントは、認証基本情報として受信された利用者情報を上記検証コンポーネントに伝達し、利用者認証のために接続されたモバイル機器の接続情報であるＩＰアドレスを確認し、確認された上記モバイル機器のＩＰアドレス及び上記モバイル機器から入力されたＳＭＳ認証値を上記検証コンポーネントに伝達する。

【0024】

上記検証コンポーネントは、上記伝達された利用者情報に相応し、該当利用者の認証に使われるＳＭＳ認証値を生成し、生成されたＳＭＳ認証値を該当利用者情報に相応する登録されたモバイル機器に伝送し、上記登録されたモバイル機器に対して通信会社が割り当てたＩＰアドレスを確認し、上記認証サービスコンポーネントから伝達されたＳＭＳ認証値と、上記生成されたＳＭＳ認証値の間の一致可否及び上記認証サービスコンポーネントから伝達されたＩＰアドレスと上記確認された通信会社が割り当てたＩＰアドレスの間の一致可否によって利用者認証の適否に関する検証を行う。

【0025】

一実施例において、上記ＳＭＳ認証値は、上記登録されたモバイル機器に対して通信会社が割り当てたＩＰアドレスの全部または一部をシード値として活用して生成した認証値であってもよい。

【0026】

一実施例において、上記利用者認証が該当利用者のモバイル機器に設けられたモバイルアプリを通して実行されている場合、
上記認証サービスコンポーネントは、上記モバイルアプリのプッシュＩＤを受信し、受信されたプッシュＩＤを上記検証コンポーネントに伝達することができる。また、上記検証コンポーネントは、プッシュ認証値を生成し、上記プッシュＩＤを参照して生成されたプッシュ認証値をプッシュ通知で上記モバイルアプリに伝送し、上記プッシュ認証値を利用者認証過程の追加認証要素として活用することができる。

【0027】

一実施例において、上記認証サービスコンポーネントは、接続されたモバイル機器から受信されたプッシュ認証値を上記検証コンポーネントに伝達することができる。また、上記検証コンポーネントは、上記認証サービスコンポーネントから伝達されたプッシュ認証値と上記生成されたプッシュ認証値の間の追加一致可否を上記利用者認証の適否に関する検証に活用することができる。

【0028】

一実施例において、上記利用者認証のために接続されたモバイル機器と、上記ＳＭＳ認証値を受信する登録されたモバイル機器が互いに異なる機器である場合、
上記検証コンポーネントは、上記接続されたモバイル機器のＩＰアドレスに相応して獲得される位置情報と、上記登録されたモバイル機器の現在ＧＰＳ情報に相応して獲得される位置情報の間を比べて互いに事前に指定された位置範囲内にあるのか否かによって、上記利用者認証の適否に係る検証を行うことができる。

【0029】

一実施例において、上記認証サービスコンポーネントは、利用者が接続しようとするサービスに関するサービスサーバー、または該当サービスサーバーに関する認証手続きを代行する認証代行サーバーに具現され、上記検証コンポーネントは、通信会社サーバーまたは上記認証代行サーバーに具現されることができる。

【0030】

本発明の別の側面によれば、利用者中心の認証を行う認証システムであって、オンラインサービスサーバーに関する認証手続きを代行する認証サービスコンポーネントと、上記オンラインサービスサーバーに接続する接続端末機に関する認証手続きを代行するモバイル認証エージェントコンポーネントを含むことができる。

【0031】

ここで、上記認証サービスコンポーネントは、認証基本情報として上記接続端末機から入力された利用者情報に相応するモバイル認証エージェントコンポーネントを確認し、確認されたモバイル認証エージェントコンポーネント及び上記接続端末機が接続しようとするオンラインサービスサーバーに認証暗号値をそれぞれ伝送し、上記モバイル認証エージェントコンポーネントから上記認証暗号値に相応する暗号検証値または認証同意値が受信される場合、上記オンラインサービスサーバーに認証成功メッセージを伝送することができる。

【0032】

一実施例において、上記認証サービスコンポーネントは、上記オンラインサービスサーバーに、上記認証暗号値に対する暗号有効時間情報を上記追加伝送することができる。

【0033】

この時、上記オンラインサービスサーバーは、認証暗号表示窓を通して上記認証暗号値と上記暗号有効時間を一緒に表示さsteamえるＧＵＩ（Ｇｒａｐｈｉｃａｌ Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）が上記接続端末機の画面上に表出されるようにすることができる。

【0034】

一実施例において、上記認証サービスコンポーネントは、上記モバイル認証エージェントコンポーネントに、上記認証暗号値に対する暗号有効時間情報を上記追加伝送することができる。

【0035】

この時、上記モバイル認証エージェントコンポーネントは、認証暗号表示窓を通して上記認証暗号値と上記暗号有効時間を一緒に表示させるＧＵＩ（Ｇｒａｐｈｉｃａｌ Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）が認証機の画面上に表出されるようにすることを特徴とする、認証システム。

【0036】

一実施例において、上記認証暗号値は、上記認証暗号表示窓内に数字列または文字列で表示され、上記暗号有効時間は、上記認証暗号表示窓内でタイムラップスバー（Ｔｉｍｅ Ｌａｐｓｅ Ｂａｒ）の形態で表示され、暗号有効時間の経過を視覚的に案内することができる。

【0037】

一実施例において、上記認証サービスコンポーネントは、上記暗号有効時間の経過によって上記認証暗号値を更新生成し、上記オンラインサービスサーバー及び上記モバイル認証エージェントコンポーネントに再伝送することができる。この時、上記認証暗号値の更新によって認証暗号値と暗号有効時間は、上記認証暗号表示窓内で更新表出されることができる。

【0038】

一実施例において、上記認証成功メッセージの伝送によって、上記接続端末機に関するオンラインサービスサーバーへのサービス使用が許容された以来、上記モバイル認証エージェントコンポーネントから上記認証サービスコンポーネントに接続解止値が受信される場合、
上記認証サービスコンポーネントは、上記接続解止値の伝送主体がサービス接続者に相応する登録されたモバイル認証エージェントコンポーネントであるか否かを確認し、登録されたモバイル認証エージェントコンポーネントから上記接続解止値が受信されたことと確認された場合、上記オンラインサービスサーバーへ接続解止要請メッセージを伝送することができる。

【0039】

一実施例において、上記認証暗号値を受信したモバイル認証エージェントコンポーネントから上記認証サービスコンポーネントに接続遮断値が受信される場合、
上記認証サービスコンポーネントは、上記接続遮断値の伝送主体がサービス接続者に相応する登録されたモバイル認証エージェントコンポーネントであるか否かを確認し、登録されたモバイル認証エージェントコンポーネントから上記接続遮断値が受信されたことと確認された場合、上記オンラインサービスサーバーへ接続遮断要請メッセージを伝送することができる。

【0040】

一実施例において、上記認証サービスコンポーネントは、上記接続遮断が行われた接続端末機に関する関連情報を保管し、接続遮断された接続端末機から同一条件の認証要請が再び試みられる場合、該当認証要請を自動遮断することができる。

【発明の効果】

【0041】

本発明の第１側面によれば、ＳＭＳ認証値がハッカーに奪取されても正当な利用者のみＳＭＳを利用して本人認証サービスを利用できるようになることで、フィンテックサービス、ＩｏＴサービス、各種オンラインサービスなどで信頼できる利用者認証サービスが可能となる効果がある。

【0042】

本発明の第２側面によれば、利用者がオンラインサービスを利用することにあたり、暗号を熟知したり、周期的に変更して入力する必要がなく、サービスが提供した暗号とサービス暗号検証機で表示する暗号が一致するかを検証してサービスを認証させることで、サービス暗号検証機を所持した正当な利用者のみサービス利用が可能となる。さらに、初めて接続したサービスがファーミングされたサービスなのかもサービス暗号を通じて利用者が明らかに弁別できるので、既存の中間子攻撃によるハッキング事故に弱いモバイル基盤の接続承認アプリ技術の限界も克服できるようになる。

【0043】

また、本発明の第３側面によれば、利用者がオンラインサービスを利用するにあたり、サービスＩＤと認証のためのモバイルアプリで利用者認証を行うことにおいて、サービスを装ったファーミング攻撃にかかったり、使用上の不注意によってハッカーの接続可否を確認せずに接続を承認したり、モバイル認証アプリにひんぱんな認証要請が来る時、使用上接続を承認する操作に間違いが生じたとしても、既存に承認した接続を利用者が自分の意志で取り消すことができるので、正当な検証機を所持した正当な利用者のみサービスが利用できるよう、利用者認証に対する保安が可能となる。特に、利用者ＩＤとモバイル認証アプリだけで利用者認証を行う過程に慣れて、長期間使用による利用者の習慣が固着される場合も、別に判断せずとも利用者認証をする習慣を大きく保安することができる。さらに、利用者のＩＤがハッカーに露出されたとしてもモバイル認証アプリで認証要請による接続を遮断すれば、サービスサーバーで該当ＩＤ、またはＩＤとＩＰアドレスを遮断し、攻撃者がそれ以上該当ＩＤでサービスに接続を試みることができないようにするので、ＩＤと認証機アプリのみで構成された既存の認証技術の限界点を克服することができるようになる。

【図面の簡単な説明】

【0044】

【図1】従来技術におけるＳＭＳを利用した本人認証サービスを図示した図面。

【図2】本発明の実施例によって、ＩＰアドレスとＳＭＳを利用した本人認証サービス方法及びシステムを説明するための図面。

【図3】本発明の実施例によって、ＩＰアドレスとＳＭＳを利用した本人認証サービス方法及びシステムを説明するための図面。

【図4】本発明の実施例によって、ＩＰアドレスとＳＭＳを利用した本人認証サービス方法及びシステムを説明するための図面。

【図5】本発明の実施例によって、ＩＰアドレスとＳＭＳを利用した本人認証サービス方法及びシステムを説明するための図面。

【図6】本発明の実施例による利用者中心のサービス認証技術の流れを図示した図面。

【図7】既存のサービス中心の利用者認証に関する実施例示と、本発明の実施例による利用者中心のサービス認証に関する実施例示を図示した図面。

【図8】利用者のサービス暗号なしに利用者のＩＤとモバイル機器を利用した既存の利用者認証の流れを図示した図面。

【図9】利用者のサービス暗号なしに利用者のＩＤとモバイル機器を利用して利用者認証をするシステムにおいて、接続者を認証した以後、該接続者のサービス接続を取り消す流れを図示した図面。

【図10】利用者のサービス暗号なしに利用者のＩＤとモバイル機器を利用して利用者認証をするシステムにおいて、悪意を持つ接続者が利用者のＩＤで認証を試みる場合、これを遮断する流れを図示した図面。

【発明を実施するための形態】

【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】

他の実施例によると、上述した図３の本人認証手続きは、下記説明のように、通信環境である時のみに正常に行うこともできる。例えば、モバイルアプリ５０が利用者モバイル機器１００の通信状態を点検して、通信網が３Ｇ／ＬＴＥ網である時だけ上述した本人認証手続きが行われるようにしてもよい。ハッキング方法の一つとしてＷＩＦＩなど近距離無線通信ができる範囲内にいるハッカーが利用者の情報を奪取する場合が存在するので、このようなハッキングの試みを遮断するために、３Ｇ／ＬＴＥ網などのように遠距離無線通信網を接続及び認証試みだけを許容する方式を取り入れることもできる。

【0071】

また、他の実施例によると、図３を通じて説明した本人認証手続き以外に次のような手続きがさらに加えられてもよい。

【0072】

前述した図３の場合、モバイルアプリ５０が利用者モバイル機器１００に設置された場合を中心として説明したが、様々なケースが存在することができる。例えば、モバイルアプリ５０が認証用モバイルアプリで、このような認証用モバイルアプリが設置された端末機（以下、これを認証端末機と命名する）と、サービスに接続する端末機（以下、これを接続端末機と命名する）がそれぞれ別に存在するケースも存在する。

【0073】

上記のような場合であれば、追加認証条件として該当サービスに接続する接続端末機と、該当接続者が使用する認証端末機の位置を比べて、相互位置が予め指定された範囲内にある場合にのみ（すなわち、接続端末機と認証端末機が所定範囲内に接して位置する場合にのみ）本人認証手続きが正常に許容されるようにする制限をすることもできる。

【0074】

この時、接続端末機の位置は確認された接続ＩＰアドレス値に基づいて獲得し、認証端末機の位置は、該当端末機のＧＰＳ情報に基づいて獲得することができる。もちろん、接続端末機の位置も該当端末機のＧＰＳ情報に基づいて獲得できるのは勿論である。このような方法で互いの位置の差を計算し、その位置の差が大きくない場合のみに本人認証手続きを正常に許容することができる。認証端末機を所持する利用者が接続端末機を利用してサービス接続を試みる場合が通常であるところ、これと違って、認証端末機と遠く離れている接続端末機を通じるサービス接続のための試みは、ハッカーによる接続への試みであると考えるのが大概なためである。

【0075】

以下、図４の本人認証手続きに関して説明する。ただし、図４の本人認証手続きで、Ｓ５１、Ｓ５２、Ｓ５３、Ｓ５５、Ｓ５６、Ｓ５７、Ｓ５８、Ｓ５９、Ｓ６０は、前述した図２と実質的に大同小異な内容の段階であるところ、以下では、図２と相違する事項に対してのみ説明する。

【0076】

図４のケースでは、Ｓ５４を通してＳＭＳ認証値を生成する過程で利用者モバイル機器１００のＩＰアドレスを利用している。このため、図４のＳ５３-２によれば、ＳＭＳ認証値の生成に利用される利用者モバイル機器１００のＩＰアドレスを確認する。すなわち、図４では、通信会社が該利用者のモバイル機器１００に割り当てたＩＰアドレス（そのＩＰアドレスの全部または一部）を認証値生成変数として活用している点で前述の図２と相違する。

【0077】

以下、図５の本人認証手続きに関して説明する。ただし、図５の本人認証手続きでも、Ｓ７１、Ｓ７３、Ｓ７４、Ｓ７５、Ｓ７６、Ｓ７７、Ｓ７８、Ｓ７９、Ｓ８０は、前述した図２、図４と実質的に大同小異な内容の段階であるところ、以下では上述した図面と相違する事項に対してのみ説明する。

【0078】

図５のケースでは、Ｓ７２-２を通して本人認証サービスサーバー２００が利用者情報を通信会社サーバー３００に伝送する時、その利用者情報だけでなく、利用者モバイル機器１００のＩＰアドレスも共に送る点で特徴がある。このため、本人認証サービスサーバー２００は、全手続きの前半部（図５のＳ７２参照）に予め利用者モバイル機器１００のＩＰアドレスを確認する過程を行っている。

【0079】

図６〜図１０において、「モバイル認証機４０」は、サービス認証または／及び利用者認証を行う別の認証用モバイル機器であってもよく、認証機能を代行するエージェントプログラムまたはモバイルアプリであってもよい。また、図６〜図１０では、「モバイル認証機４０」が「利用者端末機１０」と分離された装置のように図示されているが、必ずこれと同じである必要はない。もし、「利用者端末機１０が本当の利用者が使う端末機の場合であれば、モバイル認証機としての機能も一緒に行うこともできる。例えば、モバイル認証アプリまたはこのような機能を行うウィジェット形態のプログラムが利用者端末機に設置されてもよく、モバイルＯＳが提供する方式によって、一つのサービスアプリの上に別途のウィンドウレイヤーで構成されたモバイル認証アプリで構成されてもよい。また、図６〜図１０では、「オンラインサービスサーバー２０」と「認証サーバー３０」がそれぞれ別に備えられた場合を仮定しているが、オンラインサービスサーバー２０が認証サーバーの役割も共に行ってもよい。

【0080】

また、以下説明する図６〜図１０の認証手続きにおける各段階に関する識別番号（つまり、Ｓ１１１、Ｓ１１２、Ｓ１１３など）は、各段階を分けて説明するためのものであって、手続きの手順を定義したものではないことを明確にしておく。論理的に、ある一段階が実行された後に次の段階が行われる場合ではない限り、各段階は識別番号の先後と関係なく並列的にまたは同時に行われるのは勿論である。場合によって、その識別番号の先後と異なる手順で各段階が行われてもよいことは自明である。本発明の核心的技術特徴が十分に反映できる限度で、各段階の手順また様々な変形が可能なためである。ただし、以下では、説明の集中及び便宜上、図面に図示された手順にしたがって各段階を説明する。以下、添付の図面を参照して本発明の実施例を詳しく説明する。

【0081】

図６は、本発明の実施例による利用者中心のサービス認証技術の流れを図示した図面で、図７は、既存のサービス中心の利用者認証に関する実施例示と本発明の実施例による利用者中心のサービス認証に関する実施例示を図示した図面である。

【0082】

本発明の実施例による利用者中心のサービス認証技術は、利用者がオンラインサービスを利用するにあたって、サービス中心でオンラインサービスサーバーが利用者暗号を検証するのではなく、利用者中心でサービス暗号を検証することで、利用者が暗号を覚えたり入力しなくても利用者中心でサービスを認証する方法及びシステムに関する。

【0083】

より具体的には、サービスが先にサービス暗号を利用者端末機の画面上に提示し、この時提示されたサービス暗号と利用者のモバイル認証機に表示されたサービス暗号の間の一致するか否かを判断し、モバイル認証機から互いの暗号一致による検証値が認証サーバーに伝達されれば、利用者端末機にサービスを提供する利用者中心のサービス認証技術が提供される。以下、これに関して図６及び図７を参照して具体的に説明する。

【0084】

図６を参照すれば、利用者はオンラインサービスを利用しようとする端末機１０に利用者ＩＤを入力する［図６のＳ１１１参照］。

【0085】

従来の技術によると、特定オンラインサービスを利用しようとする利用者は、図７のＡに図示されたように、自分の端末機の画面上に表れる入力フォームに利用者ＩＤと利用者暗号（Ｕｓｅｒ Ｐａｓｓｗｏｒｄ）を入力し、ログインボタンを選択してサービス利用のための利用者認証を要請する。これと違って、本発明の実施例による利用者中心のサービス認証技術では、図７のＢの右側の画面のような入力フォーム（図面番号１２参照）のうち、上段のＩＤ入力窓（図面番号１３参照）に自分の利用者ＩＤのみを入力する。

【0086】

このような利用者ＩＤの入力によって、利用者端末機１０はサービスを利用しようとするオンラインサービスサーバー２０に入力された利用者ＩＤを伝送する［図６のＳ１１２参照］。例えば、利用者端末機１０は、利用者がＩＤ入力窓にＩＤ文字列とエンターキーが入力されたり、またはＩＤ文字列を入力した後、ＩＤ入力窓の外にカーソルの動くイベントが発生すれば、入力された利用者ＩＤをオンラインサービスサーバー２０に伝送することができる。

【0087】

利用者ＩＤを受信したオンラインサービスサーバー２０は、該当ＩＤがサービスに加入されている登録ＩＤであるかを確認し［図６のＳ１１３参照］、加入されたＩＤと判断された場合、認証サーバー３０にサービス暗号を要請する［図６のＳ１１４参照］。ここで、サービス暗号は、利用者が接続したサービスが該サービスを提供する本当のサービス主体によるサービスであるかを確認するための用途の暗号を意味する。同時に、サービス暗号は、サービスに接続した利用者がハッカーや悪意的接続者でない真の利用者であるかを判断するためにも活用される。場合によって、図６のＳ１１４のサービス暗号要請過程で利用者ＩＤも認証サーバー３０に伝送されてもよい。

【0088】

この時、前述した図６のＳ１１３は、次のように変形されてもよい。もし、該当サービスが利用者の選択によって通常の認証手続き（利用者ＩＤと利用者暗号の入力を要求する認証手続き）と、本発明の実施例による利用者中心のサービス認証手続きのうち、いずれか一つを選択できるように具現された場合であれば、図６のＳ１１３は、利用者ＩＤが登録されたＩＤであるかを確認する手続き以外にも、利用者中心のサービス認証方式に、さらに加入されている利用者であるかを確認する手続きも一緒に行うことができる。もし、利用者中心のサービス認証方式に加入されていない利用者と判別された場合、オンラインサービスサーバー２０は、図７のＡのように、通常の利用者認証のための入力フォームが利用者端末機１０の画面上に表出されるようにして、利用者暗号入力窓にカーソルが表示させることができる。ただし、以下では、説明の便宜及び集中のために、該利用者が本発明の実施例による利用者中心のサービス認証方式に加入された利用者の場合を仮定して説明する。

【0089】

オンラインサービスサーバー２０からのサービス暗号要請によって、認証サーバー３０はサービス暗号を生成する［図６のＳ１１５参照］。この時、サービス暗号は、任意のランダム値、乱数値、ＯＴＰ（ｏｎｅ ｔｉｍｅ ｐａｓｓｗｏｒｄ）などが使われてもよく、その生成方式も特に制限されないことは勿論である。また、場合によって、該当利用者ＩＤに相応する特定情報を暗号生成のシード値にしてサービス暗号を生成することもでき、サービス暗号の生成過程で、暗号生成条件として時間、試み回数などをさらに活用してもよい。これは、以後説明する各種暗号値にも同一または累次に適用されてもよい。

【0090】

認証サーバー３０は、生成したサービス暗号を該当利用者ＩＤに相応して予め登録されたモバイル認証機４０に伝達することができる［図６のＳ１１６参照］。この時、モバイル認証機４０が認証アプリである場合、該認証アプリのプッシュＩＤに基づいて該サービス暗号をプッシュ通知で認証アプリに伝達することができる。他の例として、ＡＲＳを利用したり、ＳＭＳを利用する方式でサービス暗号を伝達することもできる。また、場合によって、後述する暗号条件値もモバイル認証機４０にさらに伝達されてもよいことは勿論である。

【0091】

また、認証サーバー３０は、生成したサービス暗号をオンラインサービスサーバー２０に伝送することができる。この時、必要に応じて、サービス暗号とともに暗号条件値も一緒にオンラインサービスサーバー２０に伝送してもよい［図６のＳ１１７参照］。ここで、暗号条件値とは、サービス暗号が一致するか否かを承認できる最大有効時間（例えば、１分など）、または生成されたサービス暗号を取り消すことができるように、ログイン窓の下段に表示される取り消しボタンの表出可否などであってもよい（図７のＢの図面番号１２の入力フォーム参照）。

【0092】

オンラインサービスサーバー２０を該当情報を利用者端末機１０に伝送し［図６のＳ１１８参照］、利用者端末機１０は、受信されたサービス暗号または／及び暗号条件が端末画面上に表出されるようにする［図６のＳ１１９参照］。この時、図６のＳ１１９によって、利用者端末機１０に表出される画面の例示が図７のＢの図面番号１２の入力フォームの中で、図面番号１４で図示されている。

【0093】

このように、利用者端末機１０の画面上にサービス暗号または／及び暗号条件が表示された後は、サービス認証の完了可否に関する周期的確認過程が追加されることがある［図６のＳ１２０参照］。すなわち、利用者端末機１０は、オンラインサービスにサービス暗号の検証値が着いてサービス認証が行われたのかを周期的に確認することができる。もちろん、この時、技術的な具現方式にしたがって、オンラインサービスサーバー１０が利用者端末機１０に先に通知する方式で構成してもよいことは自明である。

【0094】

また、前述の図６のＳ１１６にしたがってサービス暗号がモバイル認証機４０に伝達されれば、モバイル認証機４０は、端末機画面上にまたはアプリ画面上に受信したサービス暗号を表出することができる［図６のＳ１２１参照］。この時、モバイル認証機４０にサービス暗号が表出される例示が図７のＢの左側画面の図面番号４４を通じて図示されている。

【0095】

図７のＢの図面番号１４及び図面番号４４のサービス暗号表示窓を参照すれば、両者ともにサービス暗号表示窓の中にサービス暗号が表示されると同時に、暗号条件として該当サービス暗号の検証有効時間がサービス暗号表示窓にタイムラップスバー（Ｔｉｍｅ Ｌａｐｓｅ Ｂａｒ）の形態で表示されていることが確認できる。すなわち、サービス暗号表示窓には、サービス暗号とともにサービス暗号の表示条件として検証有効時間の経過または残余有効時間が表示窓内で表出されることで、該サービス暗号の有効時間を利用者が視覚的に確認することができる。このように、構成によってサービス暗号表示窓に自動にサービス暗号が表示され、サービス暗号条件にしたがってサービス暗号検証有効時間が一緒に表示されたり、時間と関係なくサービス暗号表示を取り消すことができる。また、構成によって、サービス暗号条件は別途伝送される変数ではなく、サービス暗号表示窓に固定形態で事前に適用されて構成されてもよいことは自明である。

【0096】

上述したことによって、もし、該当サービス暗号の有効時間が経過される場合、前述した図６のＳ１１５、Ｓ１１６、Ｓ１１７、Ｓ１１８、Ｓ１１９、Ｓ１２１が再度行われ、更新されたサービス暗号が各画面上に再び表示されてもよい。この時、検証有効時間に係る視覚的表示も更新される。

【0097】

また、図７では、一つの画面に利用者ＩＤとサービス暗号が同時に表出される場合を例示しているが、利用者ＩＤ入力画面とサービス暗号表示画面は異なる画面に構成されてもよいことは自明である。

【0098】

上述したように、モバイル認証機４０の画面を通してサービス暗号が表出されれば、利用者は、モバイル認証機４０の画面上に表出されたサービス暗号（図７のＢの図面番号４４参照）と利用者端末機１０の画面上に表出されたサービス暗号（図７のＢの図面番号１４参照）の間の一致可否を確認することができる。もし、その２つのサービス暗号が一致する場合、利用者は自分が接続したサービスが本当のサービス主体によるサービスであることを確認できる。これによって、利用者が該当サービスに対する同意を入力すれば、モバイル認証機４０は認証サーバー３０にサービス暗号検証値を伝送する［図６のＳ１２２参照］。

【0099】

ここで、該当サービスに対する利用者同意は、次のような方法が利用されてもよい。一例として、図７のＢの左側の図面下段のログインボタン４５を選択する方式が利用されてもよい。他の例として、図６のＳ１１６ 段階によるサービス暗号の伝達がプッシュ通知で行われた場合は、そのプッシュ通知に関する回答として同意する方式が利用されてもよい。また他の例として、ＡＲＳを利用してサービス暗号を音声で聞かせた後、利用者が同意する時＊、＃ボタンが押すようにすることができるし、ＳＭＳを利用して利用者が同意するか否かをメールで返事したり、ＳＭＳに含まれた特定住所をクリックさせて同意を求められることは自明である。図７のＢの左側図面の下段には、利用者同意のためのログインボタン４５のみ表示されているが、取り消しボタンがさらに表示されてもよいことは自明である。

【0100】

また、ここで、図６のＳ１２２を通して認証サーバー３０に伝達されるサービス暗号検証値は、モバイル認証機４０が受信したサービス暗号と同じ値であってもよいが、場合によっては、これと異なる値が利用されるか、または追加されることもある。例えば、サービス暗号検証値は、該当値が利用者のモバイル認証機４０から発送されたことであることを検証できるように、公開鍵に基づく取り引き否認防止技術やＯＴＰを利用したデータ連動ＯＴＰ値が利用されるか、さらに追加されてもよい。ただし、以下では、説明の便宜及び集中のために、サービス暗号と同一なサービス暗号検証値が認証サーバー３０に伝送されると仮定して説明する。

【0101】

上述した過程を通して、サービス暗号と一致するサービス検証値が受信されれば［図６のＳ１２３参照］、認証サーバー３０は、認証成功を知らせる認証結果をオンラインサービスサーバー２０に伝送し［図６のＳ１２４参照］、これによってオンラインサービスサーバー２０は、該当利用者端末機１０を介するサービス使用を許容する［図６のＳ１２５参照］。

【0102】

以上の手続きを通して確認できるように、本発明の実施例による利用者中心のサービス認証技術によれば、該サービスが本当のサービス主体によるサービスであることを確認できるし、これと同時に、該サービス暗号に基づく検証値が予め登録されたモバイル認証機４０から認証サーバー３０に伝達される過程を通して利用者真偽可否も確認できるところ、利用者認証とサービス認証を非常に簡単な方法で一緒に処理できる効果がある。

【0103】

図９及び図１０は、本発明の他の実施例による悪意的接続者の接続遮断技術を説明するための図面である。本発明の実施例による悪意的接続者の接続遮断技術は、利用者暗号がなくても、利用者ＩＤと利用者のモバイル端末機を利用して利用者本人であることを認証するシステムで悪意的攻撃を遮断する方法及びシステムに関する。

【0104】

より具体的には、利用者ＩＤとモバイル認証機で、利用者認証の代わりに、オンラインサービスを盗用するためにハッカーによってサービスに正常の利用者ＩＤが入力されれば、モバイル認証機に該サービス接続を承認、取り消し、解止、遮断する接続判断要請情報が伝達され、利用者が与えられた時間内で接続遮断命令を選択すれば、該当ＩＤに対する接続が予め指定された条件によって該当サービスで遮断されるようにし、利用者が与えられた時間内に接続を承認したとしても、該当認証機で予め指定された時間内に接続を再び解止できるようにする技術が提供される。以下、これに関して図９及び図１０を参照して具体的に説明する。以下の説明過程で、前述した内容と重複する説明は省略する。

【0105】

図９は、利用者のサービス暗号なしに利用者のＩＤとモバイル機器を利用して利用者認証をするシステムにおいて、接続者を認証した後、該接続者のサービス接続を取り消す流れを図示した図面である。

【0106】

図９を参照すれば、利用者が端末機１０を利用してサービスに接続した後、ＩＤを入力すれば［図９のＳ１３１参照］、利用者端末機１０は入力された利用者ＩＤをオンラインサービスサーバー２０に伝送する［図９のＳ１３２参照］。オンラインサービスサーバー２０は、受信した利用者ＩＤが加入された（登録された）ＩＤであるかを確認し［図９のＳ１３３参照］、登録されたＩＤの場合、認証サーバー３０に該当利用者ＩＤに関する認証を要請する［図９のＳ１３４参照］。この時、図９のＳ１３４でオンラインサービスサーバー２０は、認証に必要な利用者情報、端末機情報、サーバー情報などを認証サーバー３０に一緒に伝送することができる。

【0107】

ここで、上記利用者情報は、接続した利用者のＩＤを含んだ個人識別情報であり、上記端末機情報は、接続した端末機のＩＰアドレス（公認または私説ＩＰ）、接続したクライアント種類とバージョンなどのサーバー変数を通じて自動にオンラインサービスサーバーが分かることができる情報であり、上記サーバー情報は、オンラインサービスサーバーのＩＰアドレスと、認証を要請した接続クライアントとの接続のために生成したサーバーのセッションＩＤなどであってもよい。また、構成によってクライアント端末機に対応するために自動に生成されるセッションＩＤ以外に、オンラインサービスサーバーがクライアント端末機との通信のために任意の固有値を生成する全ての技術は、以下、セッションＩＤと総称する。

【0108】

利用者ＩＤの認証要請にしたがって、認証サーバー３０は、該利用者ＩＤに連動された（すなわち、該利用者ＩＤに関して事前に登録された）モバイルアプリのプッシュＩＤを照会し［図９のＳ１３５参照］、該当プッシュＩＤを利用して認証要請プッシュ通知（すなわち、認証要請値を含むプッシュ通知）をモバイル認証機４０に伝達する［図９のＳ１３６参照］。

【0109】

この時、上記認証要請値は、認証要請ＩＤ、認証要請試み回数、認証要請現在の時間、サーバーＩＰアドレス、サーバーセッションＩＤ、接続した利用者端末機の公認ＩＰアドレス、接続した利用者端末機の私説ＩＰアドレス、接続した利用者端末機のブラウザーバージョンなど、オンラインサービスサーバー２０から伝達されたり、認証サーバー３０に事前に登録された様々な値の中で少なくとも一つであってもよい。

【0110】

上記プッシュ通知の受信によって、モバイル認証機４０は認証アプリを駆動して［図９のＳ１３７参照］、該プッシュ通知の受信による上述した情報、またはこれを加工した情報とともに利用者の接続同意可否を表示することができる［図９のＳ１３８参照］。この時、認証アプリ画面には、利用者から指定された時間内に接続同意または取り消しの入力を受けることができる項目が表出される。

【0111】

もし利用者から接続同意入力が存在する場合［図９のＳ１３９参照］、モバイル認証機４０は、認証同意値を生成して認証サーバー３０に伝送する［図９のＳ１４０参照］。この時、認証同意値は、モバイルアプリが駆動されるモバイル認証機４０の環境値（例えば、該当モバイル機器のＩＰアドレス、プロセスＩＤ、機器時間、通信会社で与えてくれた時間など）と認証サーバー３０から受けた情報のうち、少なくとも一つに基づいて生成されてもよい。

【0112】

認証サーバー３０は、受信された認証同意値が正当なモバイル認証機４０（または認証アプリ）から伝達されたものであるかを検証し［図９のＳ１４１参照］、該認証値が正当なモバイル認証機４０から受信されたもので合ってる場合、オンラインサービスサーバー２０に認証成功メッセージを伝達する［図９のＳ１４２参照］。

【0113】

図９では、認証サーバー３０がモバイル認証機４０から認証同意値を直接受信する場合を図示したが、認証同意値はオンラインサービスサーバー２０を経由するか、または第３の別途の中継サーバーを経由して認証サーバー３０に伝達されてもよいことは自明である。

【0114】

認証成功メッセージの受信によって、オンラインサービスサーバー２０は、該当利用者の端末機１０に関する利用者認証を完了し、これによるサービスを開始する［図９のＳ１４３参照］。

【0115】

以上で説明した図９のＳ１３１〜Ｓ１４３までの過程は、従来技術（図８参照）と実質的に同一である。ただし、前述したとおり、利用者はしばしばモバイル認証機４０に表示される暗号などを正確に確認しない理由で、あるいは操作未熟、間違いによって悪意のある接続者によるサービス使用を許容することがしょっちゅう発生する。したがって、利用者の間違いで悪意のある接続者によるサービス使用を一応許容した後でも、これを取り消し（つまり、その接続を解止）できる方法が必要である。このために、本発明の実施例では、図９のＳ１４４〜Ｓ１４９にしたがって、悪意的接続者の接続を解止できる方法を提案する。

【0116】

本発明の実施例によると、前段階によって悪意的接続者のサービス使用を許容したことを認知した（あるいは、自分の操作の間違いを認知した）利用者は、所定の制限された時間内に該当サービスに対する接続解止または取り消しを要請することができる。このため、接続同意がされた後でも、指定された一定時間、モバイル認証機４０のアプリ画面上には、該サービスに関する接続解止要請ボタンが活性化されてもよい［図９のＳ１４４参照］。

【0117】

この時、接続解止は、予め指定された時間内（例えば、接続同意後３分、またはセッションＩＤが有効な時間内など）のみに可能とするなど、政策的に制限することができる。このような場合、指定された時間を超えると、アプリ画面を初期化させたり、認証アプリを終了させることができる。勿論、接続解止要請に関する時間制限は、必須事項ではないことは勿論である。

【0118】

これによって、利用者が接続解止を要請すれば［図９のＳ１４５参照］、モバイル認証機４０は接続解止値を生成し、これを認証サーバー３０に伝送する［図９のＳ１４６参照］。この時、接続解止値もモバイルアプリが駆動されるモバイル認証機４０の環境値（例えば、該当モバイル機器のＩＰアドレス、プロセスＩＤ、機器時間、通信会社から与えられた時間など）と、認証サーバー３０から受けた情報のうち、少なくとも一つに基づいて生成されることができる。

【0119】

接続解止値が受信されれば、認証サーバー３０は、該当接続解止値が正当なモバイル認証機４０から伝達されたのかを検証し［図９のＳ１４７参照］、正当なモバイル認証機４０から伝達されたもので合ってる場合、オンラインサービスサーバー２０に接続解止要請メッセージを伝送する［図９のＳ１４８参照］。これによって、オンラインサービスサーバー２０は、既存のサービス接続を解止処理することができる［図９のＳ１４９参照］。

【0120】

図１０は、利用者のサービス暗号なしに利用者のＩＤとモバイル機器を利用して利用者認証をするシステムにおいて、悪意的な接続者が利用者のＩＤで認証を試みる場合、これを遮断する流れを図示した図面である。ここで、図１０のＳ１５１、Ｓ１５２、Ｓ１５３、Ｓ１５４、Ｓ１５５、Ｓ１５６、Ｓ１５７は、前述した図９と実質的に同一な過程であるので、これに対する重複説明は省略する。

【0121】

図１０は、悪意的な接続者が自分の端末機（図１０の利用者端末機１０参照）を利用し、他人の利用者ＩＤを利用してサービスに接続しようと試みる場合、これを予め遮断する方法に関する。すなわち、図１０は、悪意的接続者のサービス接続のための認証要請にしたがって、本当の利用者のモバイル認証機４０に認証要請値を含むプッシュ通知が伝達された場合を図示したものである。

【0122】

上述したように、認証要請値が受信されれば、モバイル認証機４０は、画面を通して該当プッシュ通知受信による前述した情報、またはこれを加工した情報とともに、利用者の接続同意、取り消し、遮断を表示する［図９のＳ１５８参照］。この時、利用者から制限された時間内の接続遮断または取り消し要請が入力されれば［図９のＳ１５９参照］、モバイル認証機４０は、接続遮断値を生成してこれを認証サーバー３０に伝送する［図９のＳ１６０参照］。

【0123】

この時、接続遮断値もモバイルアプリが駆動されるモバイル認証機４０の環境値（例えば、該当モバイル機器のＩＰアドレス、プロセスＩＤ、機器時間、通信会社で与えられた時間など）と認証サーバー３０から受けた情報のうち、少なくとも一つに基づいて生成されてもよい。

【0124】

接続遮断値が受信されれば、認証サーバー３０は、該接続遮断値が正当なモバイル認証機４０から伝達されたものであるかを検証し［図９のＳ１６１参照］、正当なモバイル認証機４０から伝達されたもので合ってる場合、オンラインサービスサーバー２０に接続遮断要請メッセージを伝送する［図９のＳ１６２参照］。これによって、オンラインサービスサーバー２０は、悪意的接続者による接続試みを遮断処理し［図９のＳ１６３参照］、これを該当利用者端末機１０に案内することができる［図９のＳ１６４参照］。

【0125】

また、構成方式によって、オンラインサービスサーバー２０または認証サーバー３０は、遮られるように送られてきた利用者ＩＤ、遮断された端末機ＩＰアドレス、遮断時間（開始時間、締め切り時間など）、有効時間を保管管理し、接続した利用者端末機で同一な条件で認証要請が行われる場合、自体的に利用者認証要請を遮断することもできる。また、この時、事前に指定した周期によって有効時間を検査し、該当遮断条件を更新することができる。

【0126】

上述した本発明の実施例による認証方法は、コンピューターで読み取ることのできる記録媒体で、コンピューターが読み取れるコードとして具現されることが可能である。コンピューターが読み取れる記録媒体には、コンピューターシステムによって読み取りできるデータが保存された全ての種類の記録媒体を含む。例えば、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）、磁気テープ、磁気ディスク、フラッシュメモリー、光データ保存装置などがある。また、コンピューターが読み取れる記録媒体は、コンピューター通信網に連結されたコンピューターシステムに分散され、分散方式で読み取れるコードとして保存されて行われてもよい。

【0127】

以上では本発明の実施例を参照して説明したが、当該技術分野における通常の知識を有する者であれば、下記特許請求の範囲に記載した本発明の思想及び領域から脱しない範囲内で本発明を様々に修正及び変更できることを容易に理解することができる。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】