JP2016082294A

JP2016082294A - 携帯端末及びプログラム

Info

Publication number: JP2016082294A
Application number: JP2014208906A
Authority: JP
Inventors: 郁子黒田; Ikuko Kuroda; 雅之綾野; Masayuki Ayano; 勇人米澤; Isato Yonezawa; 恭弘山本; Takahiro Yamamoto; 松本　聡; Satoshi Matsumoto; 松本　　聡; 隆浩市川; Takahiro Ichikawa; 晃平川又; Kohei Kawamata
Original assignee: Nippon Telegraph and Telephone West Corp; Nippon Telegraph and Telephone East Corp
Current assignee: Nippon Telegraph and Telephone West Corp; Nippon Telegraph and Telephone East Corp
Priority date: 2014-10-10
Filing date: 2014-10-10
Publication date: 2016-05-16
Anticipated expiration: 2034-10-10
Also published as: JP5914614B1

Abstract

【課題】ユーザが入力した携帯電話番号をアプリの処理だけで認証することが可能な携帯端末及びプログラムを提供する。【解決手段】携帯端末１０は、携帯回線以外の電話回線（例えば、ひかり回線）を利用することが可能な携帯端末であって、ユーザが認証対象の携帯電話番号を入力するためのＵＩ機能部１１Ａと、ひかり回線の通信制御を行うひかり電話機能部１１Ｃと、携帯電話番号宛にひかり回線から発信し、携帯回線への着信を検知すると、ひかり回線からの発信を切断する認証機能部１１Ｂと、携帯電話番号の認証が成功すると、その携帯電話番号を格納するユーザ情報格納部１１Ｄとを備える。【選択図】図２

Description

本発明は、携帯端末及びプログラムに関し、特に、携帯電話番号を認証する技術に関する。

近年、スマートフォン等の携帯端末が急速に普及している。このような携帯端末に搭載されるアプリケーション（以下、単に「アプリ」という。）において、携帯端末の電話番号をユーザ識別情報として利用する場合は、ユーザのなりすましや誤入力を防ぎ、アプリがユーザの正しい電話番号を取得する必要がある。

一方、電話番号は、ユーザが自由に変更することができないＩＤであり、電話番号と個人情報がひも付いたデータベースがあれば、容易に個人情報を追跡することが可能である。そのため、ｉＰｈｏｎｅでは、ｉＯＳ５以降、アプリから携帯端末の電話番号を取得することができないようになっている。

アプリが携帯端末の電話番号を取得する方法としては、ユーザの同意を得る形で、（１）ユーザが自端末の電話番号を手入力する方法や、（２）ユーザがアドレス帳から自端末の電話番号を選択する方法がある。ただし、このようにユーザ自身が入力した電話番号が正しい番号である保証がないため、これを認証する技術が必要である。携帯電話番号の認証技術としては、サーバを介したＳＭＳ認証やＩＶＲ（Interactive Voice Response：自動音声応答）認証等による方法が一般的である（例えば、特許文献１、特許文献２参照）。

特開２０１３-１４５５３３号公報特開２０１３-２０５８６２号公報

上記したように、アプリから携帯端末ＯＳのＡＰＩ経由で携帯電話番号を取得する代わりの手段が必要である。ユーザによる手入力でアプリが携帯電話番号を取得する場合、誤入力や詐称した番号を入力する可能性があり、携帯端末ＯＳが認識している番号と一致する正しい番号である保証がない。このため、ユーザが入力した携帯電話番号を認証する技術が必要である。

携帯電話番号を認証する既存の手段として、ＳＭＳ認証やＩＶＲ認証などの認証サーバを介した認証手段があるが、これらの認証サーバを立てる場合は開発規模が大きくなり、構築コストの増大が問題となる。ＳＭＳ認証やＩＶＲ認証を外部委託する場合でも、運用コストの増大が問題となる。

以下、図９を用いて、従来の課題を具体的に説明する。ｉＯＳ４以前は、図９（ａ）に示すように、携帯端末ＯＳ１０１のＡＰＩ経由でアプリ１０２が携帯電話番号を取得することが可能であった。この場合、ＩＤ通信サーバ１０３への初期プロフィール登録時に携帯電話番号の入力は不要である。一方、ｉＯＳ５以降は、図９（ｂ）に示すように、携帯端末ＯＳ２０１のＡＰＩが利用できない。そこで、初期設定時にユーザによる手入力でアプリ２０２が携帯電話番号を取得するようになっている。サービス上の見え方としては、ＩＤ通信サーバ１０３への初期プロフィール登録時に携帯電話番号の入力が必要である。この場合、入力された携帯電話番号に詐称がないこと（携帯端末ＯＳの認識している携帯電話番号と同一であること）を何らかの仕組みで認証する必要がある。ＳＭＳ認証やＩＶＲ認証などの認証サーバを介在させるとコスト面で問題があるため、サーバ非介在の認証手段を提供することが望ましい。

本発明は、上述した従来の技術に鑑み、ユーザが入力した携帯電話番号をアプリの処理だけで認証することが可能な携帯端末及びプログラムを提供することを目的とする。

上記目的を達成するため、第１の態様に係る発明は、携帯回線以外の電話回線を利用することが可能な携帯端末であって、ユーザが認証対象の携帯電話番号を入力するためのＵＩ機能部と、前記電話回線の通信制御を行う電話機能部と、前記携帯電話番号宛に前記電話回線から発信し、前記携帯回線への着信を検知すると、前記電話回線からの発信を切断する認証機能部と、前記携帯電話番号の認証が成功すると、その携帯電話番号を格納する格納部とを備えることを要旨とする。

第２の態様に係る発明は、第１の態様に係る発明において、前記認証機能部が、前記携帯回線への着信を検知したタイミングで前記電話回線からの発信を切断することを要旨とする。

第３の態様に係る発明は、第１又は第２の態様に係る発明において、前記認証機能部が、前記携帯電話番号の認証の成功カウントが閾値に達するまで、前記発信から前記切断までのプロセスをランダムなタイミングで繰り返すことを要旨とする。

第４の態様に係る発明は、プログラムであって、第１乃至第３のいずれか１つに記載した各処理部としてコンピュータを機能させるためのプログラムであることを要旨とする。

本発明によれば、ユーザが入力した携帯電話番号をアプリの処理だけで認証することが可能な携帯端末及びプログラムを提供することが可能である。

本発明の実施の形態における認証システムのシステム構成図である。本発明の実施の形態における認証システムの機能ブロック図である。本発明の実施の形態における認証システムのシーケンス図である。本発明の実施の形態における認証システムの別のシーケンス図である。従来のＳＭＳ認証により入力された携帯電話番号の認証を行う場合の認証フローを示すシーケンス図である。本発明の実施の形態における携帯端末の動作を示すフローチャートである。本発明の実施の形態における携帯端末の動作を示すフローチャートである。本発明の実施の形態におけるユーザ情報格納部のＤＢ構成例を示す図である。従来の課題を説明するための図であり、（ａ）ｉＯＳ４以前、（ｂ）ｉＯＳ５以降。

以下、本発明の実施の形態について図面を参照して詳細に説明する。なお、以下の実施の形態は、この発明の技術的思想を具体化するための認証システムを例示するものであり、装置の構成やデータベースの構成等は以下の実施の形態に限定されるものではない。
（システム構成例）
図１は、本発明の実施の形態における認証システムのシステム構成図である。この認証システムは、スマートフォン等の携帯端末１０にユーザが入力した携帯電話番号を認証するシステムである。ユーザが携帯電話番号を入力する方法としては、（１）ユーザが自端末の電話番号を手入力する方法や、（２）ユーザがアドレス帳から自端末の電話番号を選択する方法等がある。図１に示すように、宅内には、ひかり電話網３０に接続可能なホームゲートウェイ（ＨＧＷ）２０が設置されている。ＨＧＷ２０は、ひかり電話機能に対応した装置（ＶｏＩＰアダプタ）を備える。携帯端末１０は、携帯電話網４０に接続可能であり、宅内ＷｉＦｉ環境へ接続済みである。携帯端末１０をひかり電話子機として使用するためのひかり電話内線番号はアプリ起動時に取得済みであるものとする。スマートフォン等の携帯端末１０をひかり電話子機として使用すること自体は既存の機能である。

本発明の実施の形態における認証システムでは、携帯回線以外の電話回線（例えば、光回線）から、ユーザが入力した携帯電話番号宛に発信し、携帯回線への着信を検知したタイミングで切断（ワン切り）する方式を採用している。これにより、以下に説明するように、ユーザが入力した携帯電話番号をアプリの処理だけで認証することが可能となる。

図２は、本発明の実施の形態における認証システムの機能ブロック図である。この図に示すように、ＨＧＷ２０は、ＶｏＩＰアダプタ（ひかり電話対応装置）２１を備える。また、携帯端末１０は、アプリ１１と、ＯＳ電話機能部１２と、ＯＳ１３とを備える。アプリ１１は、本発明の特徴的な各処理部として携帯端末１０を機能させるためのプログラムであり、具体的には、ＵＩ機能部１１Ａと、認証機能部１１Ｂと、ひかり電話機能部１１Ｃと、ユーザ情報格納部１１Ｄとを備える。

ＵＩ機能部１１Ａは、認証対象の携帯電話番号（以下、単に「認証対象番号」又は「対象番号」という場合がある。）をユーザが入力するＧＵＩを実現する。

ひかり電話機能部１１Ｃには、事前（例えば、アプリ起動時）に、ＨＧＷ２０から取得したひかり電話の番号が登録されている。ひかり電話機能部１１Ｃは、認証機能部１１Ｂからのひかり電話発信、切断等の指示に応じ、ひかり電話の通信制御を行う。

認証機能部１１Ｂは、認証対象番号宛にひかり電話を発信（ひかり電話機能部１１Ｃへ指示）する。また、ＯＳ電話機能部１２から携帯回線電話着信通知を受信すると、ひかり電話からの発信を切断する。更に、成功カウントを加算し、次の発信〜着信検知後ワン切りを実行する。成功カウントが閾値に達するまでこのステップを繰り返す。発信のタイミングは、アプリ１１でランダムに設定することができる。

ユーザ情報格納部１１Ｄは、ユーザが入力した携帯電話番号の認証が成功した際に、その他のユーザ属性情報とともに携帯電話番号を格納するＤＢである。
（動作例）
図３は、本発明の実施の形態における認証システムのシーケンス図である。この図では、携帯端末１０の各処理部１１Ａ〜１１Ｄ，１２間のシーケンスを示している。

まず、ＵＩ機能部１１Ａは、ユーザからの要求に基づいてアプリ１１を起動する（Ｓ１）。ユーザが画面上の入力フィールドに認証対象番号を入力すると（Ｓ２）、入力された認証対象番号を認証機能部１１Ｂへ引渡し、認証処理を要求する（Ｓ３）。

次いで、認証機能部１１Ｂは、ＵＩ機能部１１Ａから認証対象番号を受け取り、内部変数である成功カウントパラメータを初期化する（Ｓ４）。その後、認証対象番号へのひかり電話発信をひかり電話機能部１１Ｃへ要求する（Ｓ５）。

次いで、ひかり電話機能部１１Ｃは、認証機能部１１Ｂからの要求に基づいて、ひかり電話発信処理を行う（Ｓ６）。既に説明した通り、ＨＧＷ２０とは接続済みである。

次いで、ＯＳ電話機能部１２は、携帯電話網４０からの着信を受付ける（Ｓ７）。このステップＳ７は、携帯端末１０のＯＳ機能により実現される。

次いで、認証機能部１１Ｂは、携帯電話着信の通知をＯＳ１３のＡＰＩ経由で取得する（Ｓ８）。このステップＳ８は、アプリ１１側のＩＦ機能により実現される。

次いで、ＵＩ機能部１１Ａは、ユーザが着信に応答した場合は（Ｓ８−１：Ｙｅｓ）、エラーにより認証処理を中断し、認証リトライを要求する（Ｓ８−２）。

一方、ひかり電話機能部１１Ｃは、ひかり回線からの発信が携帯端末１０側に着信した際の応答信号（呼出し信号）を受信すると、認証機能部１１Ｂへ通知する（Ｓ９）。

次いで、認証機能部１１Ｂは、ひかり電話機能部１１Ｃから呼出し信号通知を受信すると（Ｓ１０）、ひかり回線からの発信切断をひかり電話機能部１１Ｃへ要求する（Ｓ１１）。

次いで、ひかり電話機能部１１Ｃは、通話を切断する（Ｓ１２）。

次いで、ＯＳ電話機能部１２は、携帯電話網４０経由で通話切断通知を受信すると、切断確認信号を返信する（Ｓ１３）。

次いで、ひかり電話機能部１１Ｃは、ひかり電話網３０経由で切断確認信号を受信すると、認証機能部１１Ｂへ通知する（Ｓ１４）。

次いで、認証機能部１１Ｂは、ひかり電話機能部１１Ｃからの切断確認通知を受信すると（Ｓ１５）、成功カウントを加算し（Ｓ１６）、成功カウントが閾値に達成したか否かを判定する（Ｓ１７）。成功カウントが閾値に達成した場合は（Ｓ１７：Ｙｅｓ）、認証成功とし、認証対象番号をユーザ情報格納部に登録する（Ｓ１８）。一方、成功カウントが閾値に未達成の場合は（Ｓ１７：Ｎｏ）、ステップＳ５の「発信要求」に戻り、認証フローを繰り返す。

最後に、ユーザ情報格納部１１Ｄは、認証対象番号をその他のユーザ属性情報とともに登録する（Ｓ１９）。すなわち、認証が成功すると、携帯電話番号をアプリ１１に登録する等の成功後のアクションを行うようになっている。

図４は、本発明の実施の形態における認証システムの別のシーケンス図である。この図では、携帯端末１０の各処理部１１Ａ〜１１Ｄ，１２だけでなく、ＨＧＷ２０、ひかり電話網３０、携帯電話網４０も表している。例えば、携帯電話番号は「０９０−ｘｘｘｘ−ｙｙｙｙ」、ひかり電話の番号は「０６−ａａａａ―ｂｂｂｂ」であるとする。この場合、「０６−ａａａａ―ｂｂｂｂ」から「０９０−ｘｘｘｘ−ｙｙｙｙ」へひかり電話発信処理を行うことになる（Ｓ５−Ｓ６）。図４中の符号（Ｓ１，Ｓ２，…）は、それぞれ、図３中の符号に対応している。各ステップの内容は図３と同様であるため、ここでは詳しい説明を省略する。

図５は、従来のＳＭＳ認証により入力された携帯電話番号の認証を行う場合の認証フローを示すシーケンス図である。

まず、携帯端末のアプリ１１１を起動して認証対象番号「０９０−ｘｘｘｘ−ｙｙｙｙ」を入力すると（Ｓ１０１）、認証対象番号が認証サーバ２００に送信される（Ｓ１０２）。これにより、認証サーバ２００において認証キーが発行され（Ｓ１０３）、認証キーが認証対象番号宛にＳＭＳ送信される（Ｓ１０４）。次いで、携帯端末側で受信した認証キーが認証サーバ２００に送信されると（Ｓ１０５）、認証サーバ２００において受信したキーと発行キーの照合が行われる（Ｓ１０６）。この結果、「不一致」であった場合は認証失敗と判定され（Ｓ１０７）、「一致」した場合は認証成功と判定される（Ｓ１０８）。このように認証成功と判定されると（Ｓ１０８）、認証された番号「０９０−ｘｘｘｘ−ｙｙｙｙ」が携帯端末のユーザ情報格納部１１１Ｄに格納されるようになっている（Ｓ１０９）。

このように、認証サーバ２００との連携によりユーザ入力の携帯電話番号の認証を実現する場合は、専用のサーバを構築するか、ＳＭＳ認証を外部委託する必要がある。そのため、構築コストや運用コストが増大する問題が生じる。

図６は、本発明の実施の形態における携帯端末１０の動作を示すフローチャート（全体フロー）である。既に説明した通り、携帯端末１０は、宅内ＷｉＦｉ環境へ接続済みであり、また、携帯端末１０をひかり電話子機として使用するためのひかり電話内線番号をアプリ起動時に取得済みである。この図６では、各ステップの主体を明記している（下線部分参照）。例えば、ステップＳ３の主体はＵＩ機能部１１Ａである。図６中の符号（Ｓ１，Ｓ２，…）は、それぞれ、図３や図４中の符号に対応している。各ステップの内容は図３や図４と同様であるため、ここでは詳しい説明を省略する。

図７は、本発明の実施の形態における携帯端末１０の動作を示すフローチャートである。以下、図７を用いて、認証フロー中に携帯回線着信に応答した場合について詳細に説明する。

まず、ＯＳ電話機能部１２が携帯電話網４０からの着信を受付けると（Ｓ２１）、携帯端末１０に着信画面が表示されるため、この着信にユーザが応答する可能性がある（Ｓ２２）。ユーザが応答した場合は（Ｓ２２：Ｙｅｓ）、ＯＳ電話機能部１２が携帯回線通話を開始する（Ｓ２４）。このとき、ひかり電話機能部１１Ｃが発信中でない場合は（Ｓ２５：Ｎｏ）、ＯＳ電話機能部１２が携帯回線通話を継続する（Ｓ２６）。一方、ひかり電話機能部１１Ｃが発信中である場合は（Ｓ２５：Ｙｅｓ）、ひかり電話機能部１１Ｃが発信を切断し（Ｓ２７）、ＯＳ電話機能部１２が携帯回線通話を継続する（Ｓ２８）。

このように、認証フロー中に携帯回線着信に応答した場合は、携帯回線通話を行うことができる。この場合は、エラーにより認証処理を中断されるが、既に説明した通り、認証リトライを要求するようになっているため、遅滞なく認証処理を継続することが可能である。
（データベース構成例）
図８は、ユーザ情報格納部１１Ｄのデータベース構成例を示す図である。この図に示すように、ユーザ情報格納部１１Ｄには、「ユーザＩＤ」「携帯電話番号」「氏名」「ハンドルネーム」「写真」等が対応付けて格納される。「ユーザＩＤ」は、ユーザを識別するための情報である。「携帯電話番号」は、認証された携帯電話番号である。「氏名」「ハンドルネーム」「写真」は、例えば、初期プロフィール登録時にユーザが登録した氏名、ハンドルネーム、写真である。このように、ユーザ情報格納部１１Ｄには、携帯電話番号だけでなく、種々のユーザ属性情報を対応付けて格納することが可能である。

以上のように、本発明の実施の形態における認証システムは、サーバ非介在型のシステムであり、ユーザが入力した携帯電話番号をアプリ１１の処理だけで認証することが可能である。

すなわち、本発明の実施の形態における携帯端末１０は、携帯回線以外の電話回線（例えば、ひかり回線）を利用することが可能な携帯端末であって、ユーザが認証対象の携帯電話番号を入力するためのＵＩ機能部１１Ａと、ひかり回線の通信制御を行うひかり電話機能部１１Ｃと、携帯電話番号宛にひかり回線から発信し、携帯回線への着信を検知すると、ひかり回線からの発信を切断する認証機能部１１Ｂと、携帯電話番号の認証が成功すると、その携帯電話番号を格納するユーザ情報格納部１１Ｄとを備える。これにより、ユーザによる手入力でアプリ１１が携帯電話番号を取得した場合でも、この携帯電話番号が誤入力や虚偽の番号ではなく正しい番号であることを認証することが可能となる。また、携帯回線以外にひかり回線等が使用できる環境であれば、サーバ非介在の簡便な方法により携帯電話番号の認証が可能となる。

具体的には、サービス提供事業者にとっては、携帯電話番号の認証サーバを必要としないので、構築コスト、運用コストが軽減される効果がある。一方、ユーザにとっては、メール等の別アプリを起動してＳＭＳを送信する手間や、認証サーバからの受信を待つ煩わしさから解放される効果がある。

また、認証機能部１１Ｂは、携帯回線への着信を検知したタイミングでひかり回線からの発信を切断してもよい。このようにワン切りする方式を採用すれば、ユーザが着信に応答することを極力回避することができるため、不要に認証リトライを要求しなくて済む。

また、認証機能部１１Ｂは、携帯電話番号の認証の成功カウントが閾値に達するまで、発信から切断までのプロセスをランダムなタイミングで繰り返してもよい。これにより、成功カウントが閾値に達するまで認証対象番号が登録されないため、なりすまし（虚偽の電話番号登録）を防止することが可能である。

なお、上記の説明では言及しなかったが、図３のステップＳ９に示される応答信号を受信するタイミングよりも僅かに早いタイミングで外部から呼出し信号（割り込み）を受信した場合は、この割り込みの影響により応答信号を受信できない可能性がある。このような場合でも、発信から切断までのプロセスをランダムなタイミングで複数回繰り返すようにしているため、複数回にわたって割り込みの影響を受ける不具合を回避することが可能である。

また、本発明は、携帯端末１０として実現することができるだけでなく、この携帯端末１０が備える特徴的な処理部としてコンピュータを機能させるためのプログラムとして実現することも可能である。このようなプログラムは、ＣＤ−ＲＯＭ等の記録媒体やインターネット等の伝送媒体を介して配信することができるのはいうまでもない。

１０…携帯端末
１１…アプリケーション
１１Ａ…ＵＩ機能部
１１Ｂ…認証機能部
１１Ｃ…ひかり電話機能部（電話機能部）
１１Ｄ…ユーザ情報格納部（格納部）
１２…ＯＳ電話機能部
２０…ＨＧＷ
３０…ひかり電話網
４０…携帯電話網

Claims

携帯回線以外の電話回線を利用することが可能な携帯端末であって、
ユーザが認証対象の携帯電話番号を入力するためのＵＩ機能部と、
前記電話回線の通信制御を行う電話機能部と、
前記携帯電話番号宛に前記電話回線から発信し、前記携帯回線への着信を検知すると、前記電話回線からの発信を切断する認証機能部と、
前記携帯電話番号の認証が成功すると、その携帯電話番号を格納する格納部と
を備えることを特徴とする携帯端末。
前記認証機能部は、前記携帯回線への着信を検知したタイミングで前記電話回線からの発信を切断することを特徴とする請求項１に記載の携帯端末。
前記認証機能部は、前記携帯電話番号の認証の成功カウントが閾値に達するまで、前記発信から前記切断までのプロセスをランダムなタイミングで繰り返すことを特徴とする請求項１又は２に記載の携帯端末。
請求項１乃至３のいずれか１項に記載した各処理部としてコンピュータを機能させるためのプログラム。