(57)【要約】【課題】電話サービスを提供するときに、その電話番号の信頼性を保証すること。【解決手段】Ｗｅｂサーバ２０は、利用者電話端末１１への呼接続に使用する利用者電話番号を管理する外部連携サイト４１に対して、その利用者電話番号のアクセス権を要求し、その要求に応じて認証に成功した利用者ＰＣ端末１２が取得したアクセス権をもとに、外部連携サイト４１から利用者電話番号を取得するＩＤ連携部２３と、ＩＤ連携部２３が取得した利用者電話番号を指定して利用者電話端末１１への呼接続を起動するセッション指示部２６と、を有する。【選択図】図２
2016225858.tif 000002
【特許請求の範囲】
【請求項１】
利用者電話端末への呼接続に使用する利用者電話番号を管理する外部連携サイトに対して、その利用者電話番号のアクセス権を要求し、
その要求に応じて認証に成功した利用者ＰＣ端末が取得した前記アクセス権をもとに、前記外部連携サイトから前記利用者電話番号を取得するＩＤ連携部と、
前記ＩＤ連携部が取得した前記利用者電話番号を指定して前記利用者電話端末への呼接続を起動するセッション指示部と、を有することを特徴とする
Ｗｅｂサーバ。
【請求項２】
前記Ｗｅｂサーバは、さらに、番号選択部を有しており、
前記番号選択部は、前記ＩＤ連携部が取得した前記利用者電話番号が複数個存在するときには、その複数個の前記利用者電話番号を前記利用者ＰＣ端末に提示し、その提示した前記利用者電話番号から選択された前記利用者電話番号を、前記セッション指示部に指定させることを特徴とする
請求項１に記載のＷｅｂサーバ。
【請求項３】
前記ＩＤ連携部は、前記アクセス権として、OAuth2.0のAuthorization Codeグラントにおけるアクセス権限付与トークンを用いることを特徴とする
請求項１または請求項２に記載のＷｅｂサーバ。
【請求項４】
請求項１ないし請求項３のいずれか１項に記載のＷｅｂサーバと、前記利用者ＰＣ端末と、前記外部連携サイトとを含めて構成されることを特徴とする
呼接続システム。
【請求項５】
利用者電話端末への呼接続に使用する利用者電話番号を管理するキャリア顧客ＤＢに対して、そのキャリア顧客ＤＢに登録されている利用者の前記利用者電話番号を要求し、
前記利用者電話番号の要求に併せて、前記利用者電話端末の利用者が利用者ＰＣ端末に入力した認証情報が前記キャリア顧客ＤＢに登録されていることで認証に成功した場合、前記キャリア顧客ＤＢから前記利用者電話番号を取得するＩＤ連携部と、
前記ＩＤ連携部が取得した前記利用者電話番号を指定して前記利用者電話端末への呼接続を起動するセッション指示部と、を有することを特徴とする
Ｗｅｂサーバ。
【請求項６】
Ｗｅｂサーバは、ＩＤ連携部と、セッション指示部とを有しており、
前記ＩＤ連携部は、
利用者電話端末への呼接続に使用する利用者電話番号を管理する外部連携サイトに対して、その利用者電話番号のアクセス権を要求し、
その要求に応じて認証に成功した利用者ＰＣ端末が取得した前記アクセス権をもとに、前記外部連携サイトから前記利用者電話番号を取得し、
前記セッション指示部は、
前記ＩＤ連携部が取得した前記利用者電話番号を指定して前記利用者電話端末への呼接続を起動することを特徴とする
呼接続方法。
【請求項７】
請求項６の記載の呼接続方法を、コンピュータである前記Ｗｅｂサーバに実行させるための呼接続プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、Ｗｅｂサーバ、呼接続システム、呼接続方法、および、呼接続プログラムの技術に関する。
【背景技術】
【０００２】
インターネットの普及に伴い、ＳＮＳ（Social Networking Service）などの各種Ｗｅｂサービスを利用する利用者が増えている。利用者は、複数のＷｅｂサービスに対して、それぞれ個別にＩＤとパスワードを設定し、それらの設定した情報を用いてＷｅｂサービスにログインしてサービスを利用する。
【０００３】
また、同じ利用者について、第１のＷｅｂサービスの処理結果を、第２のＷｅｂサービスに活用させたいこともある。例えば、第１のＷｅｂサービスである写真投稿サイトに写真を投稿した場合、その投稿したことを示す記事を第２のＷｅｂサービスである日記投稿サイトに掲載し、日記の閲覧者に対して、最新の写真を閲覧させたいような場合である。
【０００４】
しかし、同じ利用者による複数のＷｅｂサービス間の連携処理として、個々のＷｅｂサービスに対して利用者自身が直接操作することは煩雑である。よって、第２のＷｅｂサービスへの操作を、利用者が直接行う代わりに、利用者の許可を得た第１のＷｅｂサービスが代行するようにする認証基盤が提案されている。
例えば、非特許文献１に記載されている「OAuth 2.0」は、アクセストークンという利用許可を得た第１のＷｅｂサービスが、第２のＷｅｂサービス内のリソースを取得するための認証の仕組みを提供する。
【先行技術文献】
【非特許文献】
【０００５】
【非特許文献１】Internet Engineering Task Force(IETF)、"The OAuth 2.0 Authorization Framework"、［online］、October 2012、Request for Comments: 6749、［平成27年5月25日検索］、インターネット〈URL：https://tools.ietf.org/html/rfc6749〉
【発明の概要】
【発明が解決しようとする課題】
【０００６】
Ｗｅｂサービスは、提供するサービスを利用するためのＡＰＩ（Application Programming Interface）を公開し、そのＡＰＩを介して外部からの要求を受け付ける。例えば、提供するサービスが音声通話関連のサービスであるときには、セッション制御ＡＰＩが提供される。
【０００７】
従来の音声通話の専用網で実現されていた各種サービスも、セッション制御ＡＰＩを介して提供することにより、音声技術とインターネット技術の融合を支援する。この融合により、例えば、インターネットショッピングサイトでは、注文の決定処理などをＷｅｂブラウザで提供し、注文に関する利用者からの質問を音声通話で受け付けることができる。
【０００８】
しかし、インターネット上のＷｅｂサービスは世界中から気軽にアクセスできるので、音声専用網の閉じたサービスをインターネットに開放する際には、充分なセキュリティが要求される。例えば、電話機にいたずら電話を発信するよりも、セッション制御ＡＰＩにいたずら電話の不正アクセスを発生させる方が低コストである。
【０００９】
なお、セッション制御ＡＰＩを利用するときには、例えば、Ｗｅｂフォームを介したテキスト入力などで利用者電話番号を指定してもらう。しかし、もし、セッション制御ＡＰＩが外部から通知された利用者電話番号の電話番号を無条件に信頼して、その電話番号に対して発呼を行ってしまうと、悪意ある攻撃者が入力した電話番号や、正常な利用者であっても誤入力した電話番号に対して、誤った発呼が行われてしまう。
【００１０】
そこで、本発明は、電話サービスを提供するときに、その電話番号の信頼性を保証することを、主な課題とする。
【課題を解決するための手段】
【００１１】
前記課題を解決するために、本発明のＷｅｂサーバは、利用者電話端末への呼接続に使用する利用者電話番号を管理する外部連携サイトに対して、その利用者電話番号のアクセス権を要求し、
その要求に応じて認証に成功した利用者ＰＣ端末が取得した前記アクセス権をもとに、前記外部連携サイトから前記利用者電話番号を取得するＩＤ連携部と、
前記ＩＤ連携部が取得した前記利用者電話番号を指定して前記利用者電話端末への呼接続を起動するセッション指示部と、を有することを特徴とする。
【００１２】
これにより、利用者に手入力させた電話番号を用いる代わりに、利用者があらかじめ外部連携サイトに登録済みの電話番号を用いるので、電話サービスを提供するときに、その電話番号の信頼性を保証することができる。
【００１３】
本発明は、前記Ｗｅｂサーバが、さらに、番号選択部を有しており、
前記番号選択部が、前記ＩＤ連携部が取得した前記利用者電話番号が複数個存在するときには、その複数個の前記利用者電話番号を前記利用者ＰＣ端末に提示し、その提示した前記利用者電話番号から選択された前記利用者電話番号を、前記セッション指示部に指定させることを特徴とする。
【００１４】
これにより、複数個の登録された電話番号から利用者が所望の利用者電話端末を選択することができるので、利用者にとって便利である。
【００１５】
本発明は、前記ＩＤ連携部が、前記アクセス権として、OAuth2.0のAuthorization Codeグラントにおけるアクセス権限付与トークンを用いることを特徴とする。
【００１６】
これにより、アクセス権限付与トークンから認可サーバが発行するアクセストークンをもとに利用者電話番号を取得させるので、セキュリティの強度を向上できる。
【００１７】
本発明は、前記Ｗｅｂサーバと、前記利用者ＰＣ端末と、前記外部連携サイトとを含めて構成されることを特徴とする呼接続システムである。
【００１８】
これにより、Ｗｅｂサーバは、既存の外部連携サイトと連携して信頼ある利用者電話番号を取得することができる。
【００１９】
本発明のＷｅｂサーバは、利用者電話端末への呼接続に使用する利用者電話番号を管理するキャリア顧客ＤＢに対して、そのキャリア顧客ＤＢに登録されている利用者の前記利用者電話番号を要求し、
前記利用者電話番号の要求に併せて、前記利用者電話端末の利用者が利用者ＰＣ端末に入力した認証情報が前記キャリア顧客ＤＢに登録されていることで認証に成功した場合、前記キャリア顧客ＤＢから前記利用者電話番号を取得するＩＤ連携部と、
前記ＩＤ連携部が取得した前記利用者電話番号を指定して前記利用者電話端末への呼接続を起動するセッション指示部と、を有することを特徴とする。
【００２０】
これにより、利用者に手入力させた電話番号を用いる代わりに、利用者があらかじめキャリア顧客ＤＢに登録済みの電話番号を用いるので、電話サービスを提供するときに、その電話番号の信頼性を保証することができる。
【発明の効果】
【００２１】
本発明によれば、電話サービスを提供するときに、その電話番号の信頼性を保証することができる。
【図面の簡単な説明】
【００２２】
【図１】本発明の一実施形態に関する呼接続システムの概要図である。
【図２】本発明の一実施形態に関する呼接続システムの詳細を示す構成図である。
【図３】本発明の一実施形態に関する外部連携サイトの電話番号を取得するための認証処理を示すシーケンス図である。
【図４】図４（ａ）は、外部連携サイトの電話番号を取得する処理を示すシーケンス図である。図４（ｂ）は、取得された電話番号をもとに発呼する処理を示すシーケンス図である。
【図５】本発明の一実施形態に関するキャリア顧客ＤＢの電話番号を取得するための認証処理を示すシーケンス図である。
【発明を実施するための形態】
【００２３】
以下、本発明の一実施形態について、図面を参照して詳細に説明する。
【００２４】
図１は、呼接続システムの概要図である。
呼接続システムは、利用者電話端末１１と、利用者ＰＣ端末１２と、Ｗｅｂサーバ２０と、提供者電話端末２１と、認証中継サーバ３０と、セッション制御装置３２と、外部連携サイト４１と、キャリア顧客ＤＢ４２とがネットワークで接続されて構成される。
【００２５】
なお、図１に示す呼接続システムの各装置は、ＣＰＵ（Central Processing Unit）とメモリとハードディスク（記憶手段）とネットワークインタフェースを有するコンピュータとして構成され、このコンピュータは、ＣＰＵが、メモリ上に読み込んだプログラムを実行することにより、各処理部を動作させる。
また、各図では、各構成要素間の主要なデータの流れを矢印で表記している。つまり、この矢印はあくまで各構成要素間のデータの流れの一部を例示しただけであり、矢印が存在しない（または矢印の先が向いていない）ものであっても、データの流れは存在することもある。
【００２６】
利用者が通話に使用する利用者電話端末１１は、サービスを提供する提供者が通話に使用する提供者電話端末２１との間でセッション（呼接続）が確立される（Ｓ１７）。ここで、提供者電話端末２１から利用者電話端末１１への発呼に関して、利用者電話端末１１の電話番号（以下、利用者電話番号とする）を、利用者に手入力させてしまうと、問題が発生することもある。その問題とは、手入力された利用者電話番号がいたずらや入力ミスなどにより、本来の利用者電話番号ではなく、関係のない第三者の電話番号が入力されてしまうと、提供者電話端末２１から第三者へ誤った発呼がなされてしまうという問題である。
【００２７】
そこで、以下のＳ１１〜Ｓ１４に示すように、信頼ある利用者電話番号を取得する各手段を設ける。
利用者ＰＣ端末１２は、サービスを提供するＷｅｂサーバ２０に対して、利用者電話端末１１と提供者電話端末２１との呼接続による通話を希望し、その通話を介してＷｅｂサーバ２０が提供するサービスに対するリアルタイムの問い合わせを提供者に要求する（Ｓ１１）。このＳ１１の要求時に、すでに自身が登録を済ませている利用者電話番号を、どの外部連携サイト４１またはどのキャリア顧客ＤＢ４２から取得させるかを、利用者は指定する。以下、この指定した情報を「番号取得先指定情報」とする。
【００２８】
なお、番号取得先指定情報で指定される外部連携サイト４１は、例えば、twitter（登録商標）、facebook（登録商標）、google（登録商標）、Yahoo（登録商標）などの大手サービスプロバイダのサイトであり、このサイトには事前に各利用者が使用する利用者電話番号が登録されている。
【００２９】
Ｗｅｂサーバ２０は、Ｓ１１の要求を受け、ＡＰＩを介して認証中継サーバ３０に、利用者の認証を依頼する（Ｓ１２）。
認証中継サーバ３０は、Ｓ１２の依頼を受け、番号取得先指定情報で指定された、利用者電話番号を管理する外部連携サイト４１またはキャリア顧客ＤＢ４２に対して、利用者の認証を実施する（Ｓ１３）。
【００３０】
ここで、外部連携サイト４１は、例えば、ＯＡｕｔｈ２．０による認証のしくみを用いて、Ｓ１３で認証を要求してきた認証中継サーバ３０が、事前に利用者ＰＣ端末１２から利用者電話番号の使用を許可された信頼あるサイトか否かを認証する。
一方、キャリア顧客ＤＢ４２は、利用者がキャリア（通信事業者）の契約者である場合に、Ｓ１１の要求時に、利用者が入力した認証用情報（ＩＤとパスワードの組）が、自身のデータベースに登録されている場合に、利用者電話番号の使用を許可する。これにより、キャリア顧客ＤＢ４２は、ＯＡｕｔｈ２．０による認証のしくみを用いなくても、認証に成功した利用者に対して正しい利用者電話番号を使用させることができる。
【００３１】
外部連携サイト４１、または、キャリア顧客ＤＢ４２は、登録済みの利用者電話番号のリスト（以下、番号リスト）を、認証中継サーバ３０→Ｗｅｂサーバ２０→利用者ＰＣ端末１２の経路で応答する。なお、登録済みの番号リストを、Ｗｅｂサーバ２０に直接管理させないことで、利用者の個人情報を保護させるための提供者の管理負担を減らすことができる。
【００３２】
利用者ＰＣ端末１２は、応答された番号リストから、今回の発呼に使用する利用者電話番号を選択して、その利用者電話番号をもとにした呼接続をＷｅｂサーバ２０に依頼する（Ｓ１４）。
Ｗｅｂサーバ２０は、Ｓ１４で依頼された利用者電話番号と、Ｗｅｂサーバ２０を運営する提供者の提供者電話端末２１の電話番号（以下、提供者電話番号）との組み合わせを、セッション制御装置３２に通知する（Ｓ１５）。なお、Ｓ１２，Ｓ１５のように、サービス提供者側（Ｗｅｂサーバ２０）と、通信事業者側（認証中継サーバ３０、セッション制御装置３２）との通信のやりとりは、ＷｅｂＡＰＩなどの通信事業者側が提供するＡＰＩを介して行う。
セッション制御装置３２は、Ｓ１５で通知された提供者電話端末２１の発番号から、利用者電話番号への発呼を行う。この発呼により、両電話端末間の通話が可能になる（Ｓ１７）。
【００３３】
図２は、呼接続システムの詳細を示す構成図である。
Ｗｅｂサーバ２０は、提供者電話端末２１と、利用者要求受付部２２と、ＩＤ連携部２３と、要求結果送信部２４と、番号選択部２５と、セッション指示部２６とを有する。
認証中継サーバ３０は、認証処理部３１を有する。以下、図１を参照しつつ、図２の各処理部の詳細を説明する。
【００３４】
利用者要求受付部２２は、Ｓ１１の通話の問い合わせを利用者ＰＣ端末１２から受け付ける。
ＩＤ連携部２３は、利用者要求受付部２２が受け付けた問い合わせについて、その問い合わせ元の利用者に関する情報を管理する外部連携サイト４１またはキャリア顧客ＤＢ４２と連携することで、その利用者電話番号を取得する。そのため、ＩＤ連携部２３は、利用者電話番号の取得を認証処理部３１に依頼する（Ｓ１２）。
認証処理部３１は、ＩＤ連携部２３からの依頼を受け、外部連携サイト４１またはキャリア顧客ＤＢ４２に対して、利用者を認証するとともに、その認証が成功したときに利用者電話番号の取得を要求する（Ｓ１３）。
【００３５】
要求結果送信部２４は、利用者要求受付部２２によるＳ１１の通話の問い合わせ（要求）への結果として、利用者電話端末１１の利用者電話番号を利用者ＰＣ端末１２に応答する。なお、その応答が複数の利用者電話番号から構成される番号リストであるときには、要求結果送信部２４は、その番号リストから今回の通話に使用する１つの利用者電話番号を利用者に選択させる（Ｓ１４）。
【００３６】
番号選択部２５は、要求結果送信部２４を介して番号リストから選択された利用者電話番号と、提供者電話番号とをもとにした発呼を決定する。
セッション指示部２６は、番号選択部２５が決定した発呼をセッション制御装置３２に指示する（Ｓ１５）。
【００３７】
図３は、外部連携サイト４１の電話番号を取得するための認証処理を示すシーケンス図である。以下、ＯＡｕｔｈ２．０のAuthorization Codeグラントを用いた認証処理の例を説明する。
例えば、文献「＠ＩＴ、"第1回 「OAuth」の基本動作を知る"、［online］、［平成27年5月25日検索］、インターネット〈URL：http://www.atmarkit.co.jp/fsecurity/rensai/digid01/02.html〉」には、ＯＡｕｔｈ２．０のAuthorization Codeグラントとして、以下の各手順が記載されている。
手順0：Client Registration（クライアント登録）
手順1：Initiate（フロー開始）
手順2：Authorization Request（認可のリクエスト）
手順3：Authenticate User & Get Approval（ユーザ認証とアクセス権限付与）
手順4：Authorization Response（認可レスポンス）
手順5：Obtain Access Token（アクセストークンとの交換）
手順6：API Access（APIへのアクセス）
【００３８】
このAuthorization Codeグラントにおいて、認証中継サーバ３０は、利用者が外部連携サイト４１の利用者電話番号のアクセス権を与えることで、アクセス権限付与トークン（認可コードとも呼ばれる）が付与される「主催者サーバ」の役割を担う。換言すると、認証中継サーバ３０は、外部連携サイト４１に対して、利用者の許可範囲でのアクセスの代理権を付与される。
【００３９】
また、外部連携サイト４１は、アクセス権限付与トークンが入力されると、対応するアクセストークンを返答する「認可サーバ」の役割を担う。さらに、外部連携サイト４１は、アクセストークンとともにリソースのアクセス用要求が入力されると、そのリソースへのアクセス結果を返す「リソースサーバ（素材サーバ）」の役割を担う。
【００４０】
Authorization Codeグラントの手順０を説明する。
Ｓ１０１として、認証中継サーバ３０は、自身のアプリ名やドメインなどの登録要求を外部連携サイト４１に通知する。
Ｓ１０２として、外部連携サイト４１は、Ｓ１０１の登録要求を受け、その登録完了を認証中継サーバ３０に通知する。
【００４１】
Authorization Codeグラントの手順１を説明する。
Ｓ１１１として、利用者ＰＣ端末１２は、利用者電話端末１１と提供者電話端末２１との間の通話サービスの要求をＷｅｂサーバ２０に通知する。
Ｓ１１２として、Ｗｅｂサーバ２０は、Ｓ１１１のサービス要求を受け、その通話サービスで使用する番号リストの取得要求を認証中継サーバ３０に通知する。
【００４２】
Authorization Codeグラントの手順２を説明する。
Ｓ１２１として、認証中継サーバ３０は、Ｓ１１２で要求された利用者を認証するため、リダイレクトをＷｅｂサーバ２０に通知する。
Ｓ１２２として、Ｗｅｂサーバ２０は、Ｓ１２１でリダイレクトされたＩＤ認証要求を利用者ＰＣ端末１２経由で、外部連携サイト４１に通知する。
【００４３】
Authorization Codeグラントの手順３を説明する。
Ｓ１３１として、外部連携サイト４１は、Ｓ１２２で通知されたＩＤ認証要求を受け、そのユーザ認証の要求を利用者ＰＣ端末１２に通知する。
Ｓ１３２として、利用者ＰＣ端末１２は、Ｓ１３１の認証要求に対して、利用者ＩＤ、パスワードなどの利用者の認証情報を外部連携サイト４１に通知する。
【００４４】
Authorization Codeグラントの手順４を説明する。
Ｓ１４１として、外部連携サイト４１は、Ｓ１３２で通知された認証情報に基づく認証が成功したとき、その認可レスポンスとして、アクセス権限付与トークンを利用者ＰＣ端末１２に通知する。
Ｓ１４２として、利用者ＰＣ端末１２は、Ｓ１４１で通知されたアクセス権限付与トークンをＷｅｂサーバ２０に転送する。
Ｓ１４３として、Ｗｅｂサーバ２０は、Ｓ１４２で転送されたアクセス権限付与トークンを、さらに認証中継サーバ３０に転送する。
【００４５】
図４（ａ）は、外部連携サイト４１の電話番号を取得する処理を示すシーケンス図である。この図４（ａ）の処理は、図３の処理の後に開始される。
Authorization Codeグラントの手順５を説明する。
Ｓ１５１として、認証中継サーバ３０は、Ｓ１４３で通知されたアクセス権限付与トークンの交換を外部連携サイト４１に通知する。
Ｓ１５２として、外部連携サイト４１は、Ｓ１５１で通知されたアクセス権限付与トークンをアクセストークンに交換して、そのアクセストークンを認証中継サーバ３０に通知する。
【００４６】
Authorization Codeグラントの手順６を説明する。
Ｓ１６１として、認証中継サーバ３０は、Ｓ１５２で通知されたアクセストークンとともに、電話番号要求の指示を外部連携サイト４１にＡＰＩを介して通知する。
Ｓ１６２として、外部連携サイト４１は、Ｓ１６１の要求を受け、アクセストークンでアクセスを許可された番号リストを認証中継サーバ３０に通知する。
【００４７】
Ｓ１７１として、認証中継サーバ３０は、Ｓ１１２への応答として、Ｓ１６２で通知された番号リストをＷｅｂサーバ２０に返却する。
Ｓ１７２として、Ｗｅｂサーバ２０は、Ｓ１７１で通知された番号リストを含むサービス応答を利用者ＰＣ端末１２に通知する。
【００４８】
図４（ｂ）は、取得された電話番号をもとに発呼する処理を示すシーケンス図である。この図４（ｂ）の処理は、図４（ａ）の処理の後、または、後記する図５の処理の後に開始される。
Ｓ２０１として、利用者ＰＣ端末１２は、Ｗｅｂサーバ２０から通知された番号リストから利用者が選択した発呼先電話番号（サービス提供者から折り返しで発呼してほしい利用者電話番号）の指定をＷｅｂサーバ２０に通知する。
Ｓ２０２として、Ｗｅｂサーバ２０は、Ｓ２０１の利用者電話番号と、提供者電話番号との組み合わせである発呼指示をセッション制御装置３２に通知する。
Ｓ２０３として、セッション制御装置３２は、Ｓ２０２で指示された発呼を提供者電話端末２１に通知する。
Ｓ２０４として、セッション制御装置３２は、Ｓ２０３の発呼が正常に行われたことを示す応答をＷｅｂサーバ２０に通知する。
Ｓ２０５として、Ｗｅｂサーバ２０は、Ｓ２０４の正常応答を利用者ＰＣ端末１２に転送する。
Ｓ２０６として、利用者電話端末１１は、Ｓ２０３で発呼された提供者電話端末２１からの呼信号を着信する。これにより、Ｓ１１１で要求した利用者電話端末１１と提供者電話端末２１との通話サービスが実現できる。
【００４９】
図５は、キャリア顧客ＤＢ４２の電話番号を取得するための認証処理を示すシーケンス図である。利用者電話番号の取得先を外部連携サイト４１からキャリア顧客ＤＢ４２に置き換えることに伴い、図５のシーケンス図は、図３および図４（ａ）を置き換えるものである。
つまり、番号取得先指定情報で外部連携サイト４１が指定されたときには、図３および図４（ａ）の各処理が実行され、番号取得先指定情報でキャリア顧客ＤＢ４２が指定されたときには、図５の各処理が実行される。
なお、利用者ＩＤとパスワードとの組み合わせは、本シーケンスの実行前にキャリア顧客ＤＢ４２に登録されているとともに、利用者にも知らされている。この利用者ＩＤとは、例えば、ＮＴＴ東日本が提供するフレッツ光（登録商標）の「ＣＡＦ」から始まるお客様ＩＤである。
【００５０】
Ｓ３０１として、利用者ＰＣ端末１２は、Ｓ１１１と同様に、サービス要求をＷｅｂサーバ２０に通知する。
Ｓ３０２として、Ｗｅｂサーバ２０は、Ｓ１１２と同様に、番号リストの取得要求を認証中継サーバ３０に通知する。
Ｓ３０３として、認証中継サーバ３０は、Ｓ３０２で要求した利用者を認証するため、ＩＤ、パスワードなどの認証情報の入力要求をＷｅｂサーバ２０に通知する。
Ｓ３０４として、Ｗｅｂサーバ２０は、Ｓ３０３を受け、パスワードなどの認証情報の入力画面を利用者ＰＣ端末１２に通知する。
【００５１】
Ｓ３１１として、利用者ＰＣ端末１２は、Ｓ３０４の入力画面を介して利用者に入力された認証情報（ＩＤ、パスワード）をＷｅｂサーバ２０に通知する。
Ｓ３１２として、Ｗｅｂサーバ２０は、Ｓ３１１で通知された認証情報（ＩＤ、パスワード）を認証中継サーバ３０に転送する。
Ｓ３１３として、認証中継サーバ３０は、Ｓ３１２で通知された認証情報に基づくユーザ認証をキャリア顧客ＤＢ４２に依頼する。
Ｓ３１４として、キャリア顧客ＤＢ４２は、自身のデータベースの登録内容と照合することで、Ｓ３１３で通知された認証情報に基づく認証を行い、その認証結果を認証中継サーバ３０に通知する。
【００５２】
Ｓ３２１として、認証中継サーバ３０は、Ｓ３１４で認証が成功したとき、その利用者電話番号をキャリア顧客ＤＢ４２に要求する。
Ｓ３２２として、キャリア顧客ＤＢ４２は、Ｓ３２１で要求された電話番号情報を自身のデータベースの登録内容から読み出し、その読み出したデータを認証中継サーバ３０に通知する。
Ｓ３２３として、認証中継サーバ３０は、Ｓ３０２の応答として、Ｓ３２２で通知された電話番号情報（番号リスト）をＷｅｂサーバ２０に返却する。
【００５３】
Ｓ３２４として、Ｗｅｂサーバ２０は、Ｓ３２３で返却された番号リストをサービス応答として利用者ＰＣ端末１２に通知する。このＳ３２４の処理の後は、前記した図４（ｂ）の処理に移行する。
なお、番号リストに利用者電話番号が１つだけしか含まれなかったときには、利用者が選択するまでもなくその利用者電話番号が通話に使用されることが明らかなので、Ｓ１７２やＳ３２４の応答処理と、Ｓ２０１の指定処理を省略し、Ｓ１７１やＳ３２３の直後にＳ２０２を実行してもよい。
【００５４】
以上説明した本実施形態では、利用者電話番号の取得方法として、その利用者に手入力させた電話番号を用いる代わりに、利用者があらかじめ所定のサービス（外部連携サイト４１、キャリア顧客ＤＢ４２）に登録済みの電話番号を用いる。
そのため、ＯＡｕｔｈ２．０の認証を得た認証中継サーバ３０は、所定のサービスから登録済みの利用者電話番号を取得して、その取得した電話番号を用いてセッション制御装置３２のセッション制御ＡＰＩから利用者電話端末１１に発呼させる。
このように、利用者が電話番号を直接入力することなく、電話サービスに用いる電話番号を取得することができるので、電話番号の手入力を起因とした各種トラブル（いたずら電話、誤入力）を防止できる。
【００５５】
さらに、インターネットショッピングサイトなどのＷｅｂサーバ２０が複数存在する場合でも、利用者はそれらのサービス提供者それぞれを認証する代わりに、一元化された信頼あるサイトである認証中継サーバ３０に対して一度認証を行えばよい。
よって、各インターネットショッピングサイトは、多種多様な外部連携サイト４１（twitter、facebook等）と連携するためのインタフェースを自身で準備する必要がなく、機能提供事業者（認証中継サーバ３０、セッション制御装置３２）の用意するＡＰＩをコールするだけで簡易に利用者電話番号を利用できる。
【００５６】
なお、以下の（１）〜（３）に示すように、本実施形態の呼接続システムは、悪意ある攻撃者を適切に排除することで、その信頼性が保証される。
（１）悪意ある利用者が利用者ＰＣ端末１２を用いてなりすました場合、利用者電話番号の提供サイト（外部連携サイト４１、キャリア顧客ＤＢ４２）による利用者の認証処理が失敗することで、その認証処理以降の処理が進まず、利用者電話番号の不正アクセスを防止できる。
【００５７】
（２）悪意あるサービス提供者がＷｅｂサーバ２０を用いてなりすました場合、Ｗｅｂサーバ２０と認証中継サーバ３０との間であらかじめ共有されているAPI_keyという認証キーをもとに、ＷｅｂＡＰＩを公開する認証中継サーバ３０が信頼しているＷｅｂサーバ２０を特定できる。よって、認証キーをもたないＷｅｂサーバ２０からのアクセスを不正アクセスとして防止できる。
この認証キーについては、例えば、文献「gihyo.jp、"第6回  WebAPI，認証APIのセキュリティ"、［online］、［平成27年5月25日検索］、インターネット〈URL：http://gihyo.jp/dev/serial/01/web20sec/0006〉」に記載されている。
【００５８】
（３）悪意ある通信事業者が認証中継サーバ３０を用いてなりすました場合、利用者が利用者電話番号へのアクセス権限付与を許可しないことによってアクセストークンが発行されず、その結果認証処理が失敗することで、利用者電話番号の不正アクセスを防止できる。
【符号の説明】
【００５９】
１１    利用者電話端末
１２    利用者ＰＣ端末
２０    Ｗｅｂサーバ
２１    提供者電話端末
２２    利用者要求受付部
２３    ＩＤ連携部
２４    要求結果送信部
２５    番号選択部
２６    セッション指示部
３０    認証中継サーバ
３１    認証処理部
３２    セッション制御装置
４１    外部連携サイト
４２    キャリア顧客ＤＢ
【図２】
2016225858.tif 000003
【図３】
2016225858.tif 000004
【図４】
2016225858.tif 000005
【図５】
2016225858.tif 000006
【図１】
2016225858.tif 000007