JP2016110607A - 表示制御方法 - Google Patents

Abstract

【課題】ウェブ上で提供されるサービスが開始されるまでの導線として、顧客の利便性が高い導線を実現する。
【解決手段】ビデオチャットシステム１０は、顧客端末２０が顧客応対システムのサーバにビデオチャットサービスを要求した場合に、ビデオチャットサービスを要求可能な複数の経路のうち顧客端末２０が辿った経路を識別する。ビデオチャットシステム１０は、顧客端末２０が辿った経路に応じて、顧客応対システムのサーバからビデオチャットサービスが提供されるまでに顧客端末２０に異なる画面遷移を実行させる。
【選択図】図２

Description

本発明は、データ処理技術に関し、特に表示制御方法に関する。

本出願人は、顧客応対を支援するためのビデオチャット技術を提案している（例えば特許文献１参照）。また、ウェブを介してリアルタイムに動画や音声を交換するための技術仕様としてＷｅｂＲＴＣ（Web Real-Time Communication）が提唱されている（例えば特許文献２参照）。

特開２０１３−０８４１２３号公報 特開２０１４−０７１５３３号公報

企業のウェブサイトでは、ビデオチャットを含む様々なサービスが提供される。タブレット端末やスマートフォンの普及に伴い、企業のウェブサイトにアクセスする顧客端末の環境は多様化している。例えば、ＯＳ（Operating System）が異なる複数種類の顧客端末が存在する。また、顧客がサービスを要求するまでの経路も、ウェブやＩＭ（Instant Messenger）、電子メール、店頭広告（ＰＯＰ）等、複数種類存在する。本発明者は、ウェブ上で提供されるサービスについて、顧客の離脱を抑制するために、サービス開始までの導線として、顧客の利便性が高い導線を実現することが重要であると考えた。

本願発明は上記課題に鑑みたもので、その主な目的は、ウェブ上で提供されるサービスが開始されるまでの導線として、顧客の利便性が高い導線を実現することである。

上記課題を解決するために、本発明のある態様の表示制御方法は、クライアント端末と、１つのサービスを提供するサーバを含むシステムが実行する方法であって、クライアント端末がサーバに１つのサービスを要求した場合に、１つのサービスを要求可能な複数の経路のうちクライアント端末が１つのサービスを要求した経路を識別する識別ステップと、識別ステップにおいて識別された経路に応じて、サーバから１つのサービスが提供されるまでにクライアント端末に異なる画面遷移を実行させる表示制御ステップと、を備える。

なお、以上の構成要素の任意の組合せ、本発明の表現を、装置、システム、プログラム、プログラムを格納した記録媒体などの間で変換したものもまた、本発明の態様として有効である。

本発明によれば、ウェブ上で提供されるサービスが開始されるまでの導線として、顧客の利便性が高い導線を実現することができる。

ＷｅｂＲＴＣを使用した通信例を模式的に示す図である。 実施の形態のビデオチャットシステムの構成を示す図である。 図２のＡＰサーバの機能構成を示すブロック図である。 図２のｉＯＳ端末の機能構成を示すブロック図である。 図２のｉＯＳ端末の機能構成を示すブロック図である。 図２のｉＯＳ端末の画面遷移図である。 図２のｉＯＳ端末の画面遷移図である。 図２のｉＯＳ端末の画面遷移図である。 図２のＡｎｄｒｏｉｄ端末の機能構成を示すブロック図である。 図２のＡｎｄｒｏｉｄ端末の画面遷移図である。

現在、リアルタイムでの動画配信技術としてＦＬＡＳＨ（登録商標）が知られている。しかし、タブレット端末やスマートフォンは通常、ＦＬＡＳＨ形式の動画データの復号・再生に未対応である。そこで本発明者は、ＦＬＡＳＨに代わる動画配信技術としてＷｅｂＲＴＣ（Web Real-Time Communication）に着目した。ＷｅｂＲＴＣは、ウェブブラウザからカメラへアクセスして動画データを取得する機能、ウェブブラウザからマイクへアクセスして音声データを取得する機能、リアルタイム通信機能等を含む。実施の形態では、ＷｅｂＲＴＣをビデオチャットに活用する。ビデオチャットは、映像および音声の同時交換サービスであり、テレビ電話とも言える。

図１は、ＷｅｂＲＴＣを使用した通信例を模式的に示す。通常、ＷｅｂＲＴＣの通信では、動画データを送受する端末間（図１のオペレータ端末と顧客端末）で直接接続できる経路を探し出すＩＣＥサーバ（ＳＴＵＮサーバ）を設ける。ＩＣＥサーバ（ＳＴＵＮサーバ）は例えばクラウドサービスとして提供される。そして、ＳＴＵＮサーバが仲介して、オペレータ端末と顧客端末を接続させ、音声データと映像データを直接やり取りさせる。この方式では、オペレータ端末と顧客端末間の通信経路において数万に及ぶＴＣＰ・ＵＤＰポートを開放する必要がある。

一方、企業のイントラネット１１には、セキュリティの観点から、外部ネットワークとの通信を制限するファイヤウォールが設けられることが多い。ファイヤウォールは通常、ごく一部のポート、例えばウェルノウンポートである８０番ポートや４４３番ポートのみ開放し、他のポートによる通信は遮断する。したがって、企業のビデオチャットシステムにおける動画配信に、図１の構成を適用することは現実的に困難である。

そこで実施の形態では、ＩＣＥサーバ（ＴＵＲＮサーバ）を企業のイントラネット内部に構築し、オペレータ端末と顧客端末はＴＣＰ８０番ポートでＴＵＲＮサーバへアクセスする構成とする。図２は、実施の形態のビデオチャットシステム１０の構成を示す。ビデオチャットシステム１０は、ＡＰサーバ１２、ＶＣサーバ１４（ビデオチャットサーバ）、オペレータ端末１６、ＩＣＥサーバ１８、顧客端末２０を備える。ＡＰサーバ１２、ＶＣサーバ１４、オペレータ端末１６、ＩＣＥサーバ１８は、企業のイントラネット１１内部に構築される。顧客端末２０は、インターネットを介してイントラネット１１内の各装置へアクセスする。

イントラネット１１では、ＡＰサーバ１２、ＶＣサーバ１４、オペレータ端末１６、ＩＣＥサーバ１８の連携によって顧客応対システムが実現される。顧客応対システムは、商品の説明や、疑問・お悩みに対する相談を行うための、企業（例えばメーカや小売）の担当者と顧客とのビデオチャットサービスを提供する。なお、実施の形態ではＡＰサーバ、ＶＣサーバ、ＩＣＥサーバの各機能を別個の装置で実現する構成とするが、このうち２つの機能もしくは３つの機能の全てを物理的に単一の装置（筐体）で実現してもよいことはもちろんである。

オペレータ端末１６は、企業における顧客応対の担当者（以下「オペレータ」と呼ぶ）が操作する情報機器であり、例えばＰＣである。ＡＰサーバ１２は、企業のウェブサイトをインターネット上に公開し、企業のウェブサイトへアクセスしたクライアント装置へ企業のウェブページを提供するウェブアプリケーションサーバである。ＶＣサーバ１４は、オペレータと顧客がビデオチャットを行うための公知の機能を提供するビデオチャットサーバである。例えば、ＶＣサーバ１４は、オペレータと顧客とが会話を行うための仮想的な会議室を生成し、オペレータと顧客の会議室への入退室管理を実行する。

ＩＣＥサーバ１８は、ＴＵＲＮサーバとして機能し、ビデオチャットの対象端末、すなわちオペレータ端末１６と顧客端末２０それぞれのアドレスを管理する。ＩＣＥサーバ１８は、オペレータ端末１６から送信された音声データ・映像データをＴＣＰ８０番ポートで受信し、顧客端末２０へ転送する。この音声データは、オペレータ端末１６のマイクロフォンで取得された音声であり、典型的にはオペレータの声が記録されたものである。また映像データは、オペレータ端末１６のウェブカメラ（リアルタイムカメラ・ライブカメラ）による撮像データであり、典型的にはオペレータの顔等の映像である。

またＩＣＥサーバ１８は、顧客端末２０から送信された音声データ・映像データをＴＣＰ８０番ポートで受信し、オペレータ端末１６へ転送する。この音声データは、顧客端末２０のマイクロフォンで取得された音声であり、典型的には顧客の声が記録されたものである。また映像データは、顧客端末２０のウェブカメラによる撮像データであり、典型的には顧客の顔等の映像である。

このように実施の形態のビデオチャットシステム１０では、企業のファイヤウォールが通常開放するポートであるＴＣＰ８０番ポートを使用し、映像データ・音声データの中継処理をＩＣＥサーバ１８（ＴＵＲＮサーバ）が実行する。これにより、セキュリティの問題を回避しつつ、ＷｅｂＲＴＣによる高速通信等のメリットを享受できる。言い換えれば、企業ユースに堪えるＷｅｂＲＴＣによるビデオチャットシステムを実現できる。

実施の形態のＶＣサーバ１４が提供するビデオチャットサービスは２種類存在する。１つ目は、ＷｅｂＲＴＣを利用したビデオチャットサービスであり、以下「フルビデオチャット」とも呼ぶ。フルビデオチャットは、オペレータと顧客の双方向に音声と映像を提供しあう双方向フルビデオチャットと、音声は双方向だが、映像はオペレータから顧客への片方向で提供する片方向フルビデオチャットを含む。片方向フルビデオチャットでは、オペレータ映像が顧客へ提供される一方、顧客映像はオペレータへ提供されない。映像データおよび音声データはＩＣＥサーバ１８が中継する。

２つ目は、ＷｅｂＲＴＣを利用しないビデオチャットサービスであり、以下「制限ビデオチャット」とも呼ぶ。制限ビデオチャットは、映像をオペレータから顧客への片方向で提供し、音声（会話）は従来の電話で行う。したがって、ｉＯＳ端末２２でのカメラ映像や音声の取得は不要である。制限ビデオチャットは、片方向フルビデオチャットに近いが、音声の伝達がなされない点で異なる。制限ビデオチャットではＩＣＥサーバ１８は使用せず、ＶＣサーバ１４が映像データを中継する。

顧客端末２０は、ＡＰサーバ１２、ＶＣサーバ１４、ＩＣＥサーバ１８が提供するビデオチャットサービスを享受するクライアントとなる情報処理装置である。顧客端末２０は、ｉＯＳ端末２２とＡｎｄｒｏｉｄ端末２４を含む（「Ａｎｄｒｏｉｄ」は商標または登録商標）。ｉＯＳ端末２２は、ｉＯＳがインストールされた携帯情報端末であり、例えばスマートフォンやタブレット端末である。Ａｎｄｒｏｉｄ端末２４は、Ａｎｄｒｏｉｄ ＯＳがインストールされた携帯情報端末であり、例えばスマートフォンやタブレット端末である。顧客端末２０は、不図示の据置型端末（例えばデスクトップＰＣ等）を含んでもよい。

以下、第１の実施の形態として、企業の顧客応対システムにアクセスする顧客端末２０がｉＯＳ端末２２である場合のビデオチャットシステム１０の構成と動作を説明する。また、第２の実施の形態のビデオチャットシステム１０として、企業の顧客応対システムに顧客端末２０がｉＯＳ端末２２およびＡｎｄｒｏｉｄ端末２４である場合のビデオチャットシステム１０の構成と動作を説明する。

（第１の実施の形態）
ｉＯＳ端末２２では、カメラやマイクロフォンに対するウェブブラウザからの直接アクセスが禁止され、ウェブブラウザが直接カメラやマイクから映像データや音声データを取得することはできない。そこで、ｉＯＳ端末２２では、ＷｅｂＲＴＣによるビデオチャットの全機能（すなわち上記のフルビデオチャット）を利用するためには、ビデオチャットを実行するためのネイティブアプリ（以下「チャットアプリ」と呼ぶ）を導入する必要がある。

このチャットアプリは、ＷｅｂＲＴＣのＡＰＩを使用して、カメラやマイクからローカル（顧客）の映像データや音声データを取得し、それらのデータをＩＣＥサーバ１８へ送信する。またチャットアプリは、ＩＣＥサーバ１８から提供されたリモート（オペレータ）の映像データや音声データを取得する。チャットアプリは、リモートの音声データをスピーカから出力させる。また、双方向フルビデオチャットの場合、ローカルおよびリモートの映像データをディスプレイに表示させ、片方向フルビデオチャットの場合、リモートの映像データをディスプレイに表示させる。なお、ｉＯＳ端末においても、ウェブブラウザにて制限ビデオチャットを実行可能である。この場合、ｉＯＳ端末のウェブブラウザにはオペレータ側の映像が表示されるが、音声は出力されない。

図３は、図２のＡＰサーバ１２の機能構成を示すブロック図である。本明細書のブロック図において示す各ブロックは、ハードウェア的には、コンピュータのＣＰＵやメモリをはじめとする素子や機械装置で実現でき、ソフトウェア的にはコンピュータプログラム等によって実現されるが、ここでは、それらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックはハードウェア、ソフトウェアの組合せによっていろいろなかたちで実現できることは、当業者には理解されるところである。例えば、制御部３２内の各ブロックは、プログラムモジュールとして実装されてＡＰサーバ１２のストレージに格納され、ＡＰサーバ１２のＣＰＵがそれらのプログラムモジュールをメインメモリに読み出して適宜実行することにより、各ブロックの機能が発揮されてよい。

ＡＰサーバ１２は、通信部３０と制御部３２を備える。通信部３０は、種々の通信プロトコルにしたがって外部装置との通信処理を実行する。例えば、図２で示すように、オペレータ端末１６および顧客端末２０とＴＣＰ４４３番ポートを使用したＨＴＴＰＳ通信を実行する。

制御部３２は各種データ処理を実行し、通信部３０を介して他装置とデータを送受信する。制御部３２は、要求受付部３４、ＣＬ種類識別部３６、アクセス経路識別部３８、表示データ提供部４０、ＶＣサーバ連携部４２を含む。ウェブアプリケーションサーバとしての基本的な機能は公知であるため説明は省略する。

要求受付部３４は、顧客端末２０から送信された、ビデオチャットサービスの提供を要求する要求電文を受け付ける。ＣＬ種類識別部３６は、要求電文にしたがって、顧客端末２０の種類を識別する。具体的には、要求電文が含むユーザエージェント情報、例えばＨＴＴＰリクエストヘッダに記載された「User-Agent」の値を参照して、顧客端末２０のＯＳ種類やウェブブラウザの種類を識別する。

アクセス経路識別部３８は、要求電文にしたがって、顧客端末２０がビデオチャットサービスを要求したときのアクセス経路を識別する。言い換えれば、顧客端末２０がどの経路を辿ってビデオチャットサービスを要求したか、さらに言い換えれば、ビデオチャットサービス要求時の顧客端末２０のロケーションを識別する。実施の形態では、ビデオチャットサービスの提供を要求可能なアクセス経路は以下の４つを含む。

アクセス経路１．インセンティブ経路：
ＩＭやメール等のメッセージに記載されたリンクから、企業オペレータとのビデオチャットを要求する経路である。後述するように、当該アクセス経路は、顧客にインセンティブが提供される経路であるためインセンティブ経路と呼ぶこととする。
アクセス経路２．通常ウェブ経路：
企業のウェブページの中に配置されたリンクから、企業オペレータとのビデオチャットを要求する経路である。

アクセス経路３．店頭経路：
小売店の店頭に記載された情報を介して、企業オペレータとのビデオチャット（例えば店頭に置かれた商品の説明等）を要求する経路である。典型的には顧客は、小売店において当該企業の商品の販売棚に設置された広告やＰＯＰに記載されたＵＲＬや二次元コードを端末に読み込ませ、ビデオチャットサービスへアクセスさせる。
アクセス経路４．後日アプリ起動経路：
チャットアプリ導入後、ある程度時間が経過してからチャットアプリを起動し、チャットアプリから直接ビデオチャットサービスの提供を要求する経路である。

ビデオチャットシステム１０では、上記の経路ごとに異なる識別情報が設定される。具体的には、各経路にはビデオチャットサービスを要求するための異なるＵＲＬが付与される。アクセス経路識別部３８は、上記４つの経路と、各経路からのアクセスで指定されるＵＲＬとの対応関係を保持する。顧客端末２０からの要求電文に記述されたＵＲＬ（例えばリクエスト行のパス名）が、インセンティブ経路を示すＵＲＬ文字列であれば、アクセス経路がインセンティブ経路と判別する。他のアクセス経路についても同様である。

表示データ提供部４０は、ＣＬ種類識別部３６により識別された顧客端末２０の種類と、アクセス経路識別部３８により識別されたアクセス経路とに応じたウェブコンテンツを顧客端末２０へ提供する。実施の形態の顧客端末２０はｉＯＳ端末２２であるため、表示データ提供部４０は、ｉＯＳ端末２２用のアクセス経路に応じたウェブコンテンツを顧客端末２０へ提供する。例えば、アクセス経路がインセンティブ経路または店頭経路である場合と、アクセス経路が通常経路である場合とでは異なるウェブコンテンツのデータをｉＯＳ端末２２へ送信する。これにより、ｉＯＳ端末２２における画面表示内容や画面遷移態様もアクセス経路に応じて異なるものになる。

ＶＣサーバ連携部４２は、ＶＣサーバ１４と連携して、ビデオチャットサービスを顧客端末２０へ提供するための所定の処理を実行する。例えば、顧客端末２０からの要求に応じて、仮想会議室の作成要求をＶＣサーバ１４へ送信してもよい。また、顧客端末２０およびオペレータ端末１６からのアクセスをＶＣサーバ１４へ転送してもよい。

ＶＣサーバ連携部４２は、顧客端末２０のアクセス経路に応じた、顧客端末２０へ提供すべきビデオチャットサービスの種類をＶＣサーバ１４へ通知する。例えば、顧客端末２０のアクセス経路がインセンティブ経路、通常ウェブ経路、または後日アプリ起動経路で片方向が選択された場合に、片方向フルビデオチャットを実行するようＶＣサーバ１４へ指示する。また、顧客端末２０のアクセス経路が店頭経路、または後日アプリ起動経路で双方向が選択された場合に、双方向フルビデオチャットを実行するようＶＣサーバ１４へ指示する。また、顧客端末２０のアクセス経路が通常ウェブ経路で制限ビデオチャットが要求された場合に、制限ビデオチャットを実行するようＶＣサーバ１４へ指示する。ＶＣサーバ１４とＩＣＥサーバ１８は、相互に連携して、ＡＰサーバ１２の指示に応じたビデオチャットサービスを顧客端末２０に提供する。

図４は、図２のｉＯＳ端末２２の機能構成を示すブロック図である。本図は、ｉＯＳ端末２２にチャットアプリをインストールし、チャットアプリによるフルビデオチャットを実行する場合の構成を示している。ｉＯＳ端末２２は、タッチスクリーン５０、ホームボタン５２、インタフェース部５４、制御部５６を備える。図４には不図示だが、ｉＯＳ端末２２は、マイクロフォンとウェブカメラも備える。

タッチスクリーン５０は、表示装置と入力装置が一体化したユーザインタフェースである。ホームボタン５２は、タッチスクリーン５０の表示内容をホーム画面に戻すためのボタンである。ホームボタン５２を素早く２回押した場合、起動中のアプリの一覧を示す履歴画面がタッチスクリーン５０に表示される。

インタフェース部５４は、操作検出部５８、表示制御部６０、通信部６２を含む。操作検出部５８は、タッチスクリーン５０およびホームボタン５２に入力された操作内容を検出する。表示制御部６０は、制御部５６の指示に応じてタッチスクリーン５０の表示内容を制御する。例えば、制御部５６から出力された表示対象データをタッチスクリーン５０に表示させる。

通信部６２は、種々の通信プロトコルにしたがって外部装置との通信処理を実行する。例えば、図２で示すように、ＡＰサーバ１２およびＶＣサーバ１４とＴＣＰ４４３番ポートを使用したＨＴＴＰＳ通信を実行し、ＩＣＥサーバ１８とＴＣＰ８０番ポートを使用したＷｅｂＲＴＣ通信を実行する。インタフェース部５４は、マイクロフォン、ウェブカメラに対するインタフェース機能も提供する。

制御部５６は各種データ処理を実行し、通信部６２を介して他装置とデータを送受信する。制御部５６は、ウェブブラウザ部６４、電話処理部６６、チャットアプリ部６８、画面切替部７０を含む。

ウェブブラウザ部６４は、例えば、ｉＯＳ端末２２の標準ブラウザであるＳａｆａｒｉ（商標または登録商標）により実現されてもよい。ウェブブラウザ部６４は、アプリ導入有無識別部７２、アプリ導入支援部７４、引継情報記録部７６を含む。

アプリ導入有無識別部７２は、公知の手法により、ｉＯＳ端末２２におけるチャットアプリの導入有無を識別する。例えば、ｉＯＳ端末２２の所定の記憶領域に記憶された管理情報を参照して、チャットアプリの導入有無や導入済のバージョンを識別してもよい。アプリ導入有無識別部７２は、ｉＯＳ端末２２が、最新版のチャットアプリを導入済か、古いバージョンを導入済か、またはチャットアプリを未導入かを判別する。

アプリ導入支援部７４は、ｉＯＳ端末２２においてチャットアプリが未導入である場合に、チャットアプリのダウンロードサイト（例えばアプリケーションストアのウェブサイト）へアクセスし、ダウンロードサイトの情報をタッチスクリーン５０に表示させる。

またアプリ導入支援部７４は、フルビデオチャットを実行可能、言い換えれば、フルビデオチャットサービスがサポートしているチャットアプリのバージョン（以下「サポートバージョン」とも呼ぶ）を示す情報を保持する。アプリ導入支援部７４は、アプリ導入有無識別部７２により識別された導入済チャットアプリのバージョンがサポートバージョン外であれば、上記ダウンロードサイトへアクセスしサポートバージョン（典型的には最新版）のチャットアプリをｉＯＳ端末２２に導入させる。導入済チャットアプリのバージョンがサポートバージョンに含まれればチャットアプリの更新処理をスキップする。

引継情報記録部７６は、チャットアプリの処理へ引き継ぐべき情報、例えばチャットアプリの画面（トップ画面等）に表示させるべき情報をｉＯＳ端末２２の所定の記憶領域に保存する。引継情報は、チャットアプリ起動後のユーザ操作を支援するための情報であり、顧客をビデオチャットに誘導するメッセージであってもよく、例えば「ログイン後、チャットが始まります」等の文字列であってもよい。実施の形態では、引継情報は、ＡＰサーバ１２から提供された、もしくは自端末で識別したアクセス経路の情報も含む。

アプリ導入有無識別部７２、アプリ導入支援部７４、引継情報記録部７６の機能を実現するためのスクリプトコードが、ＡＰサーバ１２から提供されるウェブコンテンツデータに記述されてもよい。そして、そのスクリプトコードをウェブブラウザ部６４のスクリプトエンジンが解析・実行することで、これらの機能が発揮されてもよい。すなわちＡＰサーバ１２は、ビデオチャットサービスを要求したｉＯＳ端末２２に、アプリ導入有無識別部７２、アプリ導入支援部７４、引継情報記録部７６の機能を発揮させるとも言える。なお、上記のスクリプトコードは、例えば、Ｊａｖａ Ｓｃｒｉｐｔ（商標または登録商標）のプログラムコードであってもよい。

電話処理部６６は公知の電話機能、通話機能を提供し、通話画面表示部７８を含む。通話画面表示部７８は、電話機能の実行中、例えばｉＯＳ端末２２のユーザとオペレータとの通話中、少なくとも通話の開始時に、通話画面を表示させる。通話画面は、音量の調整ボタンや、スピーカモードへの切替ボタン、通話終了ボタン等を含む。

チャットアプリ部６８は、ｉＯＳ端末２２のネイティブアプリであるチャットアプリの機能を提供し、チャットアプリの画面をタッチスクリーン５０に表示させる。チャットアプリ部６８は、ログイン処理部８０、引継情報表示部８２、接続処理部８４、メニュー表示部８６、ローカルデータ取得部８８、ローカルデータ提供部９０、リモートデータ取得部９２、チャット画面表示部９４、チャット音声出力部９６を含む。チャットアプリは、ＷｅｂＲＴＣのライブラリを含む。チャットアプリがｉＯＳ端末２２にインストールされることにより、ｉＯＳ端末２２にＷｅｂＲＴＣのライブラリが組み込まれる。

ログイン処理部８０は、ログイン画面を表示させ、ＩＤ・パスワードによるユーザ認証処理を実行する。ログイン処理部８０は、ログイン画面に入力されたＩＤ・パスワードをＡＰサーバ１２へ送信し、ＡＰサーバ１２にユーザ認証処理を実行させてもよい。また、ｉＯＳ端末２２のローカル情報によりスタンドアロンでユーザ認証を実行してもよい。

引継情報表示部８２は、引継情報記録部７６により所定の記憶領域に保存された引継情報をチャットアプリ画面に表示させる。例えば、ログイン画面に引継情報「ログイン後、チャットが始まります」等を表示させてもよい。また、チャットアプリ画面に限らず、例えばｉＯＳ端末２２が有する通知領域や、通知バー、ステータスバー等に引継情報を表示させてもよい。

接続処理部８４は、公知の手法でＶＣサーバ１４との接続を確立する。例えば、ＴＣＰ４４３番ポートを指定したＨＴＴＰＳ通信により、仮想会議室への入室要求をＶＣサーバ１４へ送信してもよい。

メニュー表示部８６は、チャットアプリのメニュー画面を表示させる。メニュー画面には、オペレータとの会議室（チャットルーム）への入室する場合に選択されるボタンを表示させてもよい。またメニュー表示部８６は、後述の時間条件を満たす場合に、双方向フルビデオチャットを実行するか、片方向フルビデオチャットを実行するかをユーザに選択させるための方向選択画面を表示させる。

ローカルデータ取得部８８は、チャットアプリ部６８が含むＷｅｂＲＴＣのライブラリ（例えばマイクロフォンアクセス用のメソッド）をコールすることにより、ｉＯＳ端末２２のマイクロフォンから音声データ（以下「ローカル音声データ」と呼ぶ）を取得する。また、双方向フルビデオチャットを実行する場合、チャットアプリ部６８が含むＷｅｂＲＴＣのライブラリ（例えばカメラアクセス用のメソッド）をコールすることにより、ｉＯＳ端末２２のウェブカメラから撮像データ（以下「ローカル撮像データ」と呼ぶ）も取得する。

ローカルデータ提供部９０は、双方向フルビデオチャットの場合、ローカル音声データとローカル撮像データをＩＣＥサーバ１８へ送信することにより、これらのデータをオペレータ端末１６へ提供する。片方向フルビデオチャットの場合、ローカル音声データを、ＩＣＥサーバ１８を介してオペレータ端末１６へ提供するが、ローカル撮像データは提供しない。

リモートデータ取得部９２は、オペレータ端末１６から送信されてＩＣＥサーバ１８により転送された、オペレータ端末１６の音声データおよび撮像データを取得する。これらをリモート音声データ、リモート撮像データとも呼ぶ。

チャット画面表示部９４は、片方向フルビデオチャットまたは双方向フルビデオチャットの画面を表示させる。片方向フルビデオチャットの場合、リモート撮像データ（例えばオペレータの外観画像）をタッチスクリーン５０に表示させる。双方向フルビデオチャットの場合、リモート撮像データとローカル撮像データ（例えば顧客の外観画像）の両方をタッチスクリーン５０に表示させる。チャット音声出力部９６は、片方向フルビデオチャット、双方向フルビデオチャットに関わらず、リモート音声データをｉＯＳ端末２２のスピーカから出力する。

図５も、図２のｉＯＳ端末２２の機能構成を示すブロック図である。本図は、ｉＯＳ端末２２にチャットアプリをインストールせず、ウェブブラウザによる制限ビデオチャットを実行する場合の構成を示している。図５の機能ブロックのうち、図４の機能ブロックに同一または対応するブロックには同一の符号を付している。以下、図４と重複する説明は適宜省略する。

ｉＯＳ端末２２の制御部５６はチャットアプリ部６８を含まない。制御部５６のウェブブラウザ部６４は、アプリ導入有無識別部７２、ログイン処理部８０、電話番号入力画面表示部１００、アプリ導入支援部７４、電話番号通知部１０２、接続処理部８４、開始指示画面表示部１０４、開始指示通知部１０６、リモートデータ取得部９２、チャット画面表示部９４を含む。既述したように、これらの機能は、ＡＰサーバ１２から提供されるウェブコンテンツデータを表示させることで実現されてもよく、そのウェブコンテンツデータに記述されたスクリプトコードを、ウェブブラウザ部６４のスクリプトエンジンが実行することで実現されてもよい。

アプリ導入有無識別部７２は、公知の手法により、ｉＯＳ端末２２におけるチャットアプリの導入有無を識別する。ログイン処理部８０は、ログイン画面を表示させ、ＩＤ・パスワードによるユーザ認証処理を実行する。例えば、ＩＤ・パスワードをＡＰサーバ１２へ送信し、ＡＰサーバ１２にユーザ認証処理を実行させてもよい。

電話番号入力画面表示部１００は、顧客自身の電話番号、すなわちｉＯＳ端末２２の電話番号の入力画面を表示させる。電話番号入力画面は、ログイン処理部８０によるログイン要求への応答としてＡＰサーバ１２が提供したウェブページであってもよい。電話番号入力画面表示部１００は、電話番号を入力する代わりにチャットアプリを導入してもよい旨を電話番号入力画面に表示させる。

電話番号通知部１０２は、電話番号入力画面に電話番号が入力された場合に、その電話番号をＡＰサーバ１２へ送信する。ＡＰサーバ１２は、受け付けた電話番号をオペレータ端末１６へ送信し、オペレータへ通知する。アプリ導入支援部７４は、電話番号入力画面でチャットアプリの導入が選択された場合に、チャットアプリのダウンロードサイトへアクセスし、ダウンロードサイトの情報を表示させる。

開始指示画面表示部１０４は、ビデオチャットの開始指示を顧客に入力させるウェブブラウザ画面（以下「開始指示画面」と呼ぶ）を表示させる。開始指示画面は、電話番号通知部１０２による電話番号通知への応答としてＡＰサーバ１２が提供したウェブページであってもよい。開始指示画面表示部１０４は、チャットの開始を指示するためのボタンとともに、「オペレータから電話がかかってきますので通話して下さい」等のメッセージを開始指示画面に表示させる。開始指示画面は、オペレータからの電話を待ち、ビデオチャットが可能な状態になるまで待機する待機画面とも言える。

開始指示通知部１０６は、開始指示画面でチャット開始を指示するボタンが選択された場合に、チャット開始を指示する所定のデータをＶＣサーバ１４へ送信する。ＶＣサーバ１４は、ｉＯＳ端末２２からチャット開始指示を受け付けたことを契機にビデオチャット処理を開始し、オペレータ端末１６から送信された映像データの中継処理を開始させる。リモートデータ取得部９２は、リモート撮像データをＶＣサーバ１４から取得し、チャット画面表示部９４は、リモート撮像データをチャット画面に表示させる。ただし、リモート音声データの取得・出力は行わない。

以上の構成によるビデオチャットシステム１０の動作を、図６〜図８を参照しつつ説明する。図６〜図８は、図２のｉＯＳ端末２２の画面遷移図である。

図６は、アクセス経路がインセンティブ経路および店頭経路の場合の画面遷移を示している。インセンティブ経路は、典型的には企業の公式アカウントから配信された情報（インスタントメッセージ等）に記載されたリンクからアクセスする経路であり、通常、ビデオチャットを利用する顧客に対して何らかのインセンティブが提供される。このインセンティブは、例えばサンプルや粗品、クーポン、アドバイス情報等の提供である。また、店頭経路は、企業の商品の購入を検討中の顧客が一層の情報提供を求めて流入する経路である。したがって、インセンティブ経路または店頭経路の顧客はビデオチャットを利用しようとする意識が比較的高く、ｉＯＳ端末２２にチャットアプリを導入することを許容しやすいと考えられる。言い換えれば、チャットアプリの導入を課しても離脱が少ないと想定される。

また、チャットアプリを使用したフルビデオチャットは、映像と音声が分断されず、かつ、ＷｅｂＲＴＣのメリットを享受できる点で、制限ビデオチャットより優れる。したがって、利便性の高いビデオチャットサービスを提供するためには、ｉＯＳ端末２２にチャットアプリが導入された方がよい。そこで、アクセス経路がインセンティブ経路または店頭経路の場合、チャットアプリを導入させる導線、言い換えれば、フルビデオチャットを提供する導線に基づく画面遷移をｉＯＳ端末２２で実行させる。

図６で示すように、インセンティブ経路の場合、ｉＯＳ端末２２には、企業からのメッセージを示すＩＭ画面またはメーラー画面が表示されている。この企業からのメッセージは、企業の公式アカウントが直接配信したものかもしれないし、友人等が転送したものかもしれない。メッセージに記載されたビデオチャットのリンクが選択されると、ｉＯＳ端末２２のウェブブラウザ部６４は、企業サイトにアクセスし、ＡＰサーバ１２から提供されたウェブページであり、リンク先のウェブページであるランディングページを表示させる。

店頭経路の場合、ｉＯＳ端末２２には、所定の二次元コード読取り画面が表示される。ｉＯＳ端末２２は店頭広告に記載された二次元コードを読込み、ｉＯＳ端末２２のウェブブラウザ部６４は、企業サイトにアクセスし、ＡＰサーバ１２から提供されたウェブページであり、二次元コードが示すランディングページを表示させる。変形例として、店頭広告に記載されたＵＲＬを顧客がウェブブラウザ部６４へ直接入力してもよい。

ランディングページのデータは、図４のアプリ導入有無識別部７２、アプリ導入支援部７４、引継情報記録部７６の機能に対応するスクリプトコードを含む。ｉＯＳ端末２２のウェブブラウザ部６４のスクリプトエンジンがスクリプトコードを実行することでこれらのブロックの機能が発揮される。引継情報記録部７６は、チャットアプリへの引継情報（ここではチャットアプリ導入後の顧客誘導メッセージと、アクセス経路を示す情報）を
ｉＯＳ端末２２の所定の記憶領域に保存する。

アプリ導入有無識別部７２は、アプリ検査画面を表示させつつ、ｉＯＳ端末２２におけるチャットアプリ導入有無を識別する。チャットアプリが導入済であれば、アプリ導入有無識別部７２はチャットアプリを起動する。チャットアプリが未導入であれば、アプリ導入支援部７４は、チャットアプリのダウンロードサイトへアクセスし、アプリ導入画面を表示させる。また、チャットアプリが導入済であるが、最新版でなければ、チャットアプリのダウンロードサイトへアクセスし、アプリ更新画面を表示させる。チャットアプリの新規インストールまたは更新が完了すると、ｉＯＳ端末２２のホーム画面にチャットアプリのアイコンが表示される。顧客は、そのアイコンをタップする等のアプリ起動操作を入力して、チャットアプリを起動する。

以降の画面遷移はチャットアプリが実行する。チャットアプリが起動されると、チャットアプリ部６８のログイン処理部８０はログイン画面を表示させる。引継情報表示部８２は、所定の記憶領域に記憶された引継情報の顧客誘導メッセージをログイン画面に表示させる。ログインに成功すると、メニュー表示部８６は、チャットアプリのメニュー画面を表示させる。メニュー画面でビデオチャットの開始操作が入力されると、接続処理部８４は、ＶＣサーバ１４に対する接続処理を実行し、ビデオチャット開始までの間、接続待ち画面を表示させる。

ＶＣサーバ１４は、ｉＯＳ端末２２から接続要求（例えば仮想会議室への入室要求）を受け付けると、会議室への入室をオペレータに求めるメッセージをオペレータ端末１６へ送信し、オペレータ端末１６から会議室への入室要求を受け付けると、オペレータと顧客の双方を会議室へ入室させ、ビデオチャットを開始させる。例えば、ＩＣＥサーバ１８における音声データおよび映像データの中継処理を開始させる。接続完了がＶＣサーバ１４から通知されると、チャット画面表示部９４はビデオチャット画面を表示させる。引継情報としてインセンティブ経路が記憶されていれば、チャット画面表示部９４は、片方向フルビデオチャットの画面を表示させる。その一方、引継情報として店頭経路が記憶されていれば、チャット画面表示部９４は、双方向フルビデオチャットの画面を表示させる。

図７は、アクセス経路が通常ウェブ経路の場合の画面遷移を示している。通常ウェブ経路は企業のウェブページからのリンクであり、インセンティブ経路とは異なり、一般的には顧客へのインセンティブ提供はない。したがって、通常ウェブ経路でアクセスした顧客はビデオチャットを利用しようとする意識が比較的低く、ｉＯＳ端末２２にチャットアプリを導入することへの抵抗が強いと考えられる。言い換えれば、チャットアプリの導入を課すと離脱が多くなると想定される。そこで、アクセス経路が通常ウェブ経路の場合は、チャットアプリ導入不要の導線、言い換えれば、制限ビデオチャットを提供する導線に基づく画面遷移をｉＯＳ端末２２で実行させる。

図７で示すように、通常ウェブ経路の場合、ｉＯＳ端末２２には、企業ウェブページが表示される。企業ウェブページに配置されたビデオチャットのリンクを顧客が選択すると、リンク先のランディングページのデータがｉＯＳ端末２２に提供される。ウェブブラウザ部６４のアプリ導入有無識別部７２は、アプリ検査画面を表示させつつ、ｉＯＳ端末２２におけるチャットアプリ導入有無を識別する。

チャットアプリが導入済であれば、アプリ導入有無識別部７２はチャットアプリを起動する。以降、図６で説明したように、チャットアプリ部６８は、ログイン画面、メニュー画面、接続待ち画面、チャット画面を表示させる。この場合、アクセス経路が通常ウェブ経路である旨の引継情報が記録されるため、チャットアプリ部６８のチャット画面表示部９４は、通常ウェブ経路に対応付けられた片方向フルビデオチャットを表示させる。

チャットアプリが未導入であれば、ウェブブラウザ部６４のログイン処理部８０はログイン画面を表示させ、ログインに成功すると、ウェブブラウザ部６４の電話番号入力画面表示部１００は、電話番号入力画面を表示させる。電話番号入力画面に対して顧客がｉＯＳ端末２２の電話番号を入力すると、電話番号通知部１０２はその電話番号をＡＰサーバ１２へ送信する。接続処理部８４は、ＶＣサーバ１４との接続を確立する。開始指示画面表示部１０４は開始指示画面を表示させる。ＡＰサーバ１２は、ｉＯＳ端末２２の電話番号をオペレータへ通知し、オペレータはｉＯＳ端末２２へ電話をかける。

オペレータからの電話がｉＯＳ端末２２に着信すると、電話処理部６６は、着信画面を表示させる。顧客が通話開始操作を入力すると、電話処理部６６は、オペレータと顧客との通話を開始させるとともに通話画面を表示させる。オペレータは、ホームボタン５２を２回押して履歴画面を表示させ、履歴画面から開始指示画面を選択するよう顧客に指示する。顧客が、指示にしたがい開始指示画面への切替操作を入力すると、画面切替部７０は、タッチスクリーン５０での表示対象を通話画面から開始指示画面へ切り替える。

ＶＣサーバ１４は、ｉＯＳ端末２２での表示対象が通話画面から開始指示画面（すなわちウェブブラウザ画面）へ切り替わったことを検出したことを契機にｉＯＳ端末２２への映像配信を開始する。具体的には、ｉＯＳ端末２２の開始指示画面に対して顧客がチャット開始操作を入力すると、ウェブブラウザ部６４の接続処理部８４はＶＣサーバ１４と再度接続し、開始指示通知部１０６はビデオチャットの開始指示をＶＣサーバ１４へ送信する。ＶＣサーバ１４は、その開始指示を受信したことを契機にｉＯＳ端末２２への映像配信を開始する。ウェブブラウザ部６４のチャット画面表示部９４は、制限ビデオチャット画面を表示させ、リモートデータ取得部９２は、ＶＣサーバ１４から提供されたリモート撮像データを制限ビデオチャット画面に表示させる。

ｉＯＳ端末２２は、電話着信を受け付けると、ＶＣサーバ１４との接続を一旦切断するため、そのままではＶＣサーバ１４からの配信データ（ここではオペレータ映像）を取得できない。そのため、オペレータと顧客との通話が開始された後に、顧客に開始指示を入力させることで、ＶＣサーバ１４と再接続し、ＶＣサーバ１４に映像の配信開始を指示する。これにより、オペレータと顧客との電話による通話開始を挟んで、オペレータ映像の配信を実現できる。

電話番号入力画面において顧客が電話番号を入力する代わりに、チャットアプリの導入を選択した場合、ウェブブラウザ部６４のアプリ導入支援部７４は、チャットアプリのダウンロードサイトへアクセスし、アプリ導入画面を表示させる。チャットアプリの新規インストールが終了すると、ｉＯＳ端末２２のホーム画面にチャットアプリのアイコンが表示される。顧客は、そのアイコンをタップする等のアプリ起動操作を入力して、チャットアプリを起動する。以降、図６で説明したように、チャットアプリ部６８は、ログイン画面、メニュー画面、接続待ち画面、片方向フルビデオチャットの画面を表示させる。顧客の中には電話番号の入力に抵抗を感じる人もいるが、別の選択肢としてチャットアプリの導入を提示することで、ビデオチャットの利用を促進できる。また、チャットアプリの導入も促進できる。

図６、図７で示したように、アクセス経路がインセンティブ経路、通常ウェブ経路の場合に片方向フルビデオチャットを提供する一方、店頭経路の場合は双方向フルビデオチャットを提供する。インセンティブ経路や通常ウェブ経路は自宅からのアクセスが多いと想定され、顧客は顧客側の映像をオペレータに見せたくない状況が多いと考えられるためである。すなわち、オペレータの映像のみを提供する方が顧客にとって気軽にビデオチャットを利用できると考えられるためである。その一方、店頭経路の場合は、顧客は外出中であり、また、顧客が気になる商品等の映像をオペレータへ提供した方が、顧客とオペレータの意思疎通に資すると考えられるためである。

このように、アクセス経路に応じて、映像配信の方向を自動的に決定することで、ビデオチャット開始までの顧客の操作ステップ数を低減できる。ただし、アクセス経路が後日アプリ起動経路の場合、顧客にとって片方向フルビデオチャットと双方向フルビデオチャットのどちらが望ましいかの判別が難しい。そこで、アクセス経路が後日アプリ起動経路の場合は、映像配信方向を片方向とするか双方向とするかの選択画面、言い換えれば、片方向フルビデオチャットと双方向フルビデオチャットの選択画面を表示させる。

図８は、アクセス経路が後日アプリ起動経路の場合の画面遷移を示している。ｉＯＳ端末２２のホーム画面においてチャットアプリのアイコンをタップする等、チャットアプリの起動操作が入力されると、ログイン画面、メニュー画面を順次表示する。メニュー画面でチャット開始操作が入力されると、メニュー表示部８６は方向選択画面を表示させる。

メニュー表示部８６は、後日アプリ起動であることを識別するための判定条件を保持する。この判定条件は、時間に関する条件であってもよい。例えば、チャットアプリのインストールから所定時間（例えば２時間）が経過後に、チャットアプリが起動されたことであってもよい。また、チャットアプリの先の起動（もしくはその終了）から、所定時間（例えば２時間）が経過後に、再びチャットアプリが起動されたことであってもよい。チャットアプリ部６８は、チャットアプリのインストール日時や、起動日時、終了日時を所定の記憶領域に記録してもよい。メニュー表示部８６は、この判定条件が充足されて後日アプリ起動経路であると判定した場合に方向選択画面を表示させる。

方向選択画面で片方向が選択され、ＶＣサーバ１４との接続が完了すると、チャット画面表示部９４は片方向フルビデオチャットの画面を表示させる。また、双方向が選択され、ＶＣサーバ１４との接続が完了すると、チャット画面表示部９４は双方向フルビデオチャットの画面を表示させる。この態様によると、インセンティブ経路または通常ウェブ経路でチャットアプリを導入した顧客と、店頭経路でチャットアプリを導入した顧客との統一を図ることができ、また、顧客にとって都合のよい映像配信方向を選択させることができる。

このように、第１の実施の形態のビデオチャットシステム１０によると、ビデオチャットサービスに対するｉＯＳ端末２２のアクセス経路と、ｉＯＳ端末２２におけるチャットアプリの導入状況に応じて、顧客の離脱を抑制可能な好適な画面遷移をｉＯＳ端末２２に実行させることができる。言い換えれば、ビデオチャットサービスを提供するまでの導線として、顧客の状態に則した、顧客にとって利便性の高い導線を実現することができる。

（第２の実施の形態）
既述したように、第２の実施の形態では、ビデオチャットサービスを利用する顧客端末２０は、ｉＯＳ端末２２とＡｎｄｒｏｉｄ端末２４の両方を含む。以下特に断らない限り、第２の実施の形態のビデオチャットシステム１０は、第１の実施の形態のビデオチャットシステム１０の構成を含む。また、第１の実施の形態と重複する説明は適宜省略する。

Ａｎｄｒｏｉｄ端末２４では、ｉＯＳ端末２２と異なり、カメラやマイクロフォンに対するウェブブラウザからの直接アクセスが許可される。例えば、Ａｎｄｒｏｉｄ端末２４は、ウェブブラウザからＷｅｂＲＴＣの公知のＡＰＩをコールすることにより、直接カメラやマイクロフォンから映像データや音声データを取得できる。したがって、Ａｎｄｒｏｉｄ端末２４では、ＷｅｂＲＴＣによるビデオチャットの全機能（すなわちフルビデオチャット）を、ネイティブアプリを導入することなく、汎用的なウェブブラウザ、例えばＧｏｏｇｌｅ Ｃｈｒｏｍｅ（「Ｇｏｏｇｌｅ」「Ｇｏｏｇｌｅ Ｃｈｒｏｍｅ」は商標または登録商標）を用いて利用できる。

そこで第２の実施の形態のビデオチャットシステム１０では、ｉＯＳ端末２２にはチャットアプリを導入させた上でフルビデオチャットを利用させる一方、Ａｎｄｒｏｉｄ端末２４には汎用的なウェブブラウザによりフルビデオチャットを利用させる。なお第１の実施の形態と同様に、アクセス経路が通常ウェブ経路のｉＯＳ端末２２には、顧客の離脱を抑制するため、ウェブブラウザにより制限ビデオチャットを利用させる。

ＡＰサーバ１２の機能ブロックは第１の実施の形態と同様であり、すなわち図３に示す通りである。ＡＰサーバ１２のＣＬ種類識別部３６は、顧客端末２０からのサービス要求電文に含まれるユーザエージェント情報を参照して、顧客端末２０の種類を識別する。例えば、要求電文送信元の顧客端末２０が、ｉＯＳ端末２２とＡｎｄｒｏｉｄ端末２４のいずれであるかを識別する。

アクセス経路識別部３８は、ｉＯＳ端末２２のアクセス経路を識別し、また、Ａｎｄｒｏｉｄ端末２４のアクセス経路を識別する。なお、Ａｎｄｒｏｉｄ端末２４にはチャットアプリを導入しないため、後日アプリ起動経路はない。

表示データ提供部４０は、ＣＬ種類識別部３６により識別された顧客端末２０の種類と、アクセス経路識別部３８により識別されたアクセス経路とに応じたウェブコンテンツを顧客端末２０へ提供する。第１の実施の形態の説明で既述だが、顧客端末２０がｉＯＳ端末２２の場合、表示データ提供部４０は、チャットアプリの導入〜フルビデオチャット利用の導線に対応するウェブコンテンツを提供する。もしくは、ウェブブラウザによる制限チャット利用の導線に対応するウェブコンテンツを提供する。

その一方、顧客端末２０がＡｎｄｒｏｉｄ端末２４の場合、表示データ提供部４０は、ウェブブラウザによるフルビデオチャット利用の導線に対応するウェブコンテンツを提供する。このウェブコンテンツは、後述のログイン画面、メニュー画面、チャット画面のウェブページを含む。

ＶＣサーバ連携部４２は、顧客端末２０がｉＯＳ端末２２と識別された場合、第１の実施の形態に記載したＶＣサーバ１４との連携処理を実行する。ＶＣサーバ連携部４２は、顧客端末２０がＡｎｄｒｏｉｄ端末２４と識別された場合、Ａｎｄｒｏｉｄ端末２４のアクセス経路がインセンティブ経路、通常経路であるときに、片方向フルビデオチャットを実行するようＶＣサーバ１４へ指示する。また、Ａｎｄｒｏｉｄ端末２４のアクセス経路が店頭経路であるときに、双方向フルビデオチャットを実行するようＶＣサーバ１４へ指示する。

図９は、図２のＡｎｄｒｏｉｄ端末２４の機能構成を示すブロック図である。Ａｎｄｒｏｉｄ端末２４は、タッチスクリーン５０、インタフェース部５４、制御部５６を備える。図９には不図示だが、Ａｎｄｒｏｉｄ端末２４は、マイクロフォンとウェブカメラも備える。

図９の機能ブロックのうち、図４の機能ブロックに同一または対応するブロックには同一の符号を付している。図４と図９を対比すれば明らかなように、ｉＯＳ端末２２ではチャットアプリ部６８が実行する機能を、Ａｎｄｒｏｉｄ端末２４ではウェブブラウザ部６４が実行する。ウェブブラウザ部６４は、例えば、ＷｅｂＲＴＣのライブラリを標準で備えるＧｏｏｇｌｅ Ｃｈｒｏｍｅにより実現されてもよい。以下、図４と重複する説明は適宜省略する。

ウェブブラウザ部６４は、ログイン処理部８０、メニュー表示部８６、接続処理部８４、ローカルデータ取得部８８、ローカルデータ提供部９０、リモートデータ取得部９２、チャット画面表示部９４、チャット音声出力部９６を含む。これらの機能は、ＡＰサーバ１２から提供されたウェブコンテンツをウェブブラウザ部６４が表示し、また、そのウェブコンテンツが含むスクリプトコードをウェブブラウザ部６４のスクリプトエンジンが解析・実行することで実現されてもよい。なお、スクリプトコードは、ＷｅｂＲＴＣのＡＰＩの呼び出すコードも含む。

ログイン処理部８０は、ログイン画面を表示させ、ＩＤ・パスワードによるユーザ認証処理を実行する。メニュー表示部８６は、企業が提供するオペレータとのチャットサービスのメニュー画面を表示させる。メニュー画面には、オペレータとの会議室（チャットルーム）への入室する場合に選択されるボタンを表示させてもよい。接続処理部８４は、公知の手法でＶＣサーバ１４との接続を確立する。

ローカルデータ取得部８８は、ウェブブラウザ部６４が含むＷｅｂＲＴＣのライブラリ（例えばマイクロフォンアクセス用のメソッド）をコールすることにより、Ａｎｄｒｏｉｄ端末２４のマイクロフォンからローカル音声データを取得する。また、双方向フルビデオチャットを実行する場合、ウェブブラウザ部６４が含むＷｅｂＲＴＣのライブラリ（例えばカメラアクセス用のメソッド）をコールすることにより、Ａｎｄｒｏｉｄ端末２４のウェブカメラからローカル撮像データも取得する。

ローカルデータ提供部９０は、双方向フルビデオチャットの場合、ローカル音声データとローカル撮像データをＩＣＥサーバ１８へ送信することにより、これらのデータをオペレータ端末１６へ提供する。片方向フルビデオチャットの場合、ローカル音声データを、ＩＣＥサーバ１８を介してオペレータ端末１６へ提供するが、ローカル撮像データは提供しない。リモートデータ取得部９２は、オペレータ端末１６から送信されてＩＣＥサーバ１８により転送された、オペレータ端末１６のリモート音声データおよびリモート撮像データを取得する。

チャット画面表示部９４は、片方向フルビデオチャットまたは双方向フルビデオチャットの画面を表示させる。片方向フルビデオチャットの場合、リモート撮像データをタッチスクリーン５０に表示させる。双方向フルビデオチャットの場合、リモート撮像データとローカル撮像データの両方をタッチスクリーン５０に表示させる。チャット音声出力部９６は、片方向フルビデオチャット、双方向フルビデオチャットに関わらず、リモート音声データをｉＯＳ端末２２のスピーカから出力する。

以上の構成によるビデオチャットシステム１０の動作を、図２のＡｎｄｒｏｉｄ端末２４の画面遷移図である図１０を参照しつつ説明する。なお、ｉＯＳ端末２２の動作は第１の実施の形態と同じであるため説明を省略する。

Ａｎｄｒｏｉｄ端末２４が取り得るアクセス経路は、インセンティブ経路、通常ウェブ経路、店頭経路の３つである。インセンティブ経路の場合、Ａｎｄｒｏｉｄ端末２４には、企業からのメッセージを示すＩＭ画面またはメーラー画面が表示される。メッセージ内のビデオチャットのリンクが選択されると、Ａｎｄｒｏｉｄ端末２４のウェブブラウザ部６４は、企業サイトのビデオチャットサービスに関するランディングページへアクセスする。

通常ウェブ経路の場合、Ａｎｄｒｏｉｄ端末２４には、企業ウェブページが表示される。企業ウェブページで問い合わせが選択されると、Ａｎｄｒｏｉｄ端末２４のウェブブラウザ部６４は、上記ランディングページへアクセスする。また店頭経路の場合、Ａｎｄｒｏｉｄ端末２４には、所定の二次元コード読取り画面が表示される。Ａｎｄｒｏｉｄ端末２４は店頭広告に記載された二次元コードを読込み、Ａｎｄｒｏｉｄ端末２４のウェブブラウザ部６４は、上記ランディングページへアクセスする。ただし、ランディングページのＵＲＬは経路ごとに異なるものが設定される。

ＡＰサーバ１２は、ビデオチャットサービスに関するランディングページの提供要求を受け付けると、その要求電文を参照して、要求元のＡｎｄｒｏｉｄ端末２４のアクセス経路を識別する。そして、Ａｎｄｒｏｉｄ端末２４の識別情報（例えばＩＰアドレス）とアクセス経路とを対応付けて所定の記憶領域に記憶する。後述するように、インセンティブ経路および通常ウェブ経路の場合と、店頭経路の場合とでは異なるチャット画面を提供するためである。ＡＰサーバ１２は、ランディングページのデータをＡｎｄｒｏｉｄ端末２４へ提供し、表示させる。アクセス経路に関わらず同一のランディングページを提供してもよく、経路ごとに異なるランディングページを提供してもよい。

ランディングページでビデオチャットが選択されると、ウェブブラウザ部６４は、ログインページをＡＰサーバ１２へ要求する。ＡＰサーバ１２は、ログインページをＡｎｄｒｏｉｄ端末２４へ提供し、ログイン処理部８０は、ビデオチャットへのログイン画面を表示させる。ログイン処理部８０によるログイン処理が成功すると、ウェブブラウザ部６４は、メニューページをＡＰサーバ１２へ要求する。ＡＰサーバ１２は、メニューページをＡｎｄｒｏｉｄ端末２４へ提供し、メニュー表示部８６は、ビデオチャットのメニュー画面を表示させる。

メニュー画面でビデオチャットの開始操作が入力されると、接続処理部８４は、ＶＣサーバ１４に対する接続処理を実行し、ビデオチャット開始までの間、接続待ち画面を表示させる。ＶＣサーバ１４は、顧客端末２０がｉＯＳ端末２２である場合と同様のビデオチャット準備処理を実行する。ＡＰサーバ１２は、ビデオチャット準備処理の完了がＶＣサーバ１４から通知されると、Ａｎｄｒｏｉｄ端末２４のアクセス経路に応じたビデオチャット画面のウェブページをＡｎｄｒｏｉｄ端末２４へ提供する。具体的には、アクセス経路がインセンティブ経路および通常ウェブ経路の場合、片方向フルビデオチャット用画面データをＡｎｄｒｏｉｄ端末２４へ提供する。また、アクセス経路が店頭経路の場合、双方向フルビデオチャット用画面データをＡｎｄｒｏｉｄ端末２４へ提供する。

Ａｎｄｒｏｉｄ端末２４のチャット画面表示部９４は、ＡＰサーバ１２から提供されたビデオチャット画面のウェブページを表示させる。これにより、アクセス経路がインセンティブ経路および通常ウェブ経路の場合、片方向フルビデオチャット用画面をタッチスクリーン５０に表示させる。また、アクセス経路が店頭経路の場合、双方向フルビデオチャット用画面をタッチスクリーン５０に表示させる。

Ａｎｄｒｏｉｄ端末２４はチャットアプリを導入することなくフルビデオチャットを利用可能である。そのためビデオチャットシステム１０は、Ａｎｄｒｏｉｄ端末２４がいずれのアクセス経路であっても、ビデオチャットサービス提供まで共通の導線を提供する。言い換えれば、ビデオチャットシステム１０は、Ａｎｄｒｏｉｄ端末２４に対して、そのアクセス経路に関わらず、共通の画面遷移を実行させる。

このように、第２の実施の形態のビデオチャットシステム１０によると、顧客端末２０がｉＯＳ端末２２である場合と、Ａｎｄｒｏｉｄ端末２４である場合のそれぞれで、顧客端末２０の環境に応じた、顧客の離脱を抑制可能な好適な画面遷移を実行させる。言い換えれば、ビデオチャットサービスを提供するまでの導線として、顧客の状態に則した、顧客にとって利便性の高い導線を実現することができる。

例えば、顧客端末２０がＡｎｄｒｏｉｄ端末２４であれば、そのウェブブラウザからＷｅｂＲＴＣのライブラリを介してローカルのカメラやマイクロフォンに直接アクセス可能なため、ウェブブラウザによるフルビデオチャットの画面遷移を実行させる。この態様によると、ネイティブアプリの導入が不要であるため、顧客の離脱を抑制しやすくなる。その一方、顧客端末２０がｉＯＳ端末２２であれば、フルビデオチャットにはチャットアプリの導入が必要であるため、チャットアプリを導入させるための画面遷移を実行させる。また、顧客へインセンティブを提供しない経路であれば、代替サービスとしての制限ビデオチャットをウェブブラウザで実行させるための画面遷移を実行させる。これにより、顧客の離脱を可及的に抑制する。

以上、本発明を実施の形態をもとに説明した。これらの実施の形態は例示であり、それらの各構成要素や各処理プロセスの組合せによりいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。

上記実施の形態では、ｉＯＳ端末２２におけるチャットアプリの導入有無をｉＯＳ端末２２が識別することとしたが、変形例として、ＡＰサーバ１２が識別してもよい。例えば、ＡＰサーバ１２またはＡＰサーバ１２が連携可能な他のサーバがｉＯＳ端末２２におけるチャットアプリのダウンロード履歴や更新履歴を保持する場合、ＡＰサーバ１２は、その履歴情報を参照してｉＯＳ端末２２におけるチャットアプリの導入有無を識別してもよい。また、ｉＯＳ端末２２からＡＰサーバ１２への送信電文（例えばユーザエージェント情報等）にチャットアプリの導入有無を示す情報が含まれる場合、ＡＰサーバ１２は、その情報を参照してｉＯＳ端末２２におけるチャットアプリの導入有無を識別してもよい。ＡＰサーバ１２は、チャットアプリの導入有無に応じて、ｉＯＳ端末２２に異なる画面遷移を実行させる異なるウェブコンテンツをｉＯＳ端末２２へ送信してもよい。

上記実施の形態では、制限ビデオチャット実行の導線において、ｉＯＳ端末２２で通話画面からウェブブラウザ画面へ切り替えたことに伴う顧客操作により、ｉＯＳ端末２２からＶＣサーバ１４へビデオチャットの開始指示を送信した。変形例として、顧客と通話中のオペレータが、ｉＯＳ端末２２で通話画面からウェブブラウザ画面へ切り替えられたことを認識すると、オペレータ端末１６にチャット開始指示操作を入力してもよい。そして、オペレータ端末１６がＶＣサーバ１４へビデオチャットの開始指示を送信してもよい。この場合、ＶＣサーバ１４がｉＯＳ端末２２への再接続処理を実行してもよく、再接続が完了したことをトリガにｉＯＳ端末２２への映像配信処理を開始してもよい。

上記実施の形態では言及していないが、ｉＯＳ端末２２の後日アプリ起動経路で表示させる方向選択画面を、Ａｎｄｒｏｉｄ端末２４のウェブブラウザ画面に表示させてもよい。例えば、Ａｎｄｒｏｉｄ端末２４によるビデオチャットサービスの利用履歴（利用日時やアクセス経路等）をＡＰサーバ１２（またはＶＣサーバ１４）が記録してもよい。そして、Ａｎｄｒｏｉｄ端末２４によるビデオチャットの利用が所定の時間に関する条件を満たす場合、ＡＰサーバ１２は、片方向フルビデオチャットを実行するか、双方向フルビデオチャットを実行するかの選択画面のウェブページをＡｎｄｒｏｉｄ端末２４へ提供してもよい。時間に関する条件は、先のビデオチャットサービスの利用から所定時間（例えば２時間〜１日等）経過後に、再度ビデオチャットサービスの提供が要求されたことでもよい。

また、顧客端末２０は、ｉＯＳ端末２２、Ａｎｄｒｏｉｄ端末２４以外の情報処理装置であってもよい。この場合、情報処理装置が、ウェブブラウザからＷｅｂＲＴＣのライブラリを介してローカルのカメラやマイクロフォンに直接アクセス可能であれば（例えばＯＳがＷｉｎｄｏｗｓ（登録商標）のＰＣ等）、Ａｎｄｒｏｉｄ端末２４と同様の画面遷移を実行させてもよい。また、情報処理装置が、ウェブブラウザからＷｅｂＲＴＣのライブラリを介してローカルのカメラやマイクロフォンに直接アクセスできないものであれば、ｉＯＳ端末２２と同様の画面遷移を実行させてもよい。

なお、第１および第２の実施の形態のｉＯＳは、概念として、顧客端末２０（例えばモバイル端末）の供給者が当該端末のために仕様を決定したＯＳと言える。また、第１の実施の形態のＡＰサーバ１２は、まず顧客端末２０におけるチャットアプリ導入有無やバージョンを識別後、またはそれと並行してアクセス経路を識別し、それらの識別結果に応じた表示データを顧客端末２０へ提供してもよい。また、第２の実施の形態のＡＰサーバ１２は、まず顧客端末２０のアクセス経路を識別後、またはそれと並行して顧客端末２０の種類（ＯＳ種類等）を識別し、それらの識別結果に応じた表示データを顧客端末２０へ提供してもよい。

請求項に記載の各構成要件が果たすべき機能は、実施の形態および変形例において示された各構成要素の単体もしくはそれらの連携によって実現されることも当業者には理解されるところである。例えば、請求項に記載の表示制御ステップは、第１の実施の形態に記載のＡＰサーバ１２の表示データ提供部４０、ｉＯＳ端末２２のウェブブラウザ部６４、チャットアプリ部６８の連携によって実現されてもよい。また、第２の実施の形態に記載のＡＰサーバ１２の表示データ提供部４０、ｉＯＳ端末２２のウェブブラウザ部６４、チャットアプリ部６８、Ａｎｄｒｏｉｄ端末２４のウェブブラウザ部６４の連携によって実現されてもよい。

１０ ビデオチャットシステム、 １２ ＡＰサーバ、 １４ ＶＣサーバ、 １６ オペレータ端末、 １８ ＩＣＥサーバ、 ２０ 顧客端末、 ３６ ＣＬ種類識別部、 ３８ アクセス経路識別部、 ４０ 表示データ提供部、 ６４ ウェブブラウザ部、 ６６ 電話処理部、 ６８ チャットアプリ部、 ７２ アプリ導入有無識別部。

Claims (6)

1. クライアント端末と、１つのサービスを提供するサーバを含むシステムが実行する方法であって、
   前記クライアント端末が前記サーバに前記１つのサービスを要求した場合に、前記１つのサービスを要求可能な複数の経路のうち前記クライアント端末が前記１つのサービスを要求した経路を識別する識別ステップと、
   前記識別ステップにおいて識別された経路に応じて、前記サーバから前記１つのサービスが提供されるまでに前記クライアント端末に異なる画面遷移を実行させる表示制御ステップと、
   を備えることを特徴とする表示制御方法。
2. 前記１つのサービスを要求可能な複数の経路は、企業が顧客へ送付した所定のメッセージを起点とする経路と、企業のウェブページからの経路と、店舗からの経路のうち少なくとも２つを含むことを特徴とする請求項１に記載の表示制御方法。
3. 前記１つのサービスは、所定のアプリケーションを導入済のクライアント端末が享受可能な第１サービスと、前記第１サービスの一部に相当するサービスであって、前記アプリケーションを未導入のクライアント端末でも享受可能な第２サービスを含み、
   前記識別ステップは、前記クライアント端末が前記１つのサービスを要求した経路である特定経路が、前記クライアント端末のユーザにインセンティブを提供すべき所定の経路か否かを識別し、
   前記表示制御ステップは、前記特定経路が前記所定の経路である場合、前記クライアント端末に前記第１サービスに関する画面を表示させ、前記特定経路が前記所定の経路でない場合、前記クライアント端末に前記第２サービスに関する画面を表示させることを特徴とする請求項１または２に記載の表示制御方法。
4. 前記第２サービスは、前記クライアント端末のウェブブラウザ画面に所定のウェブコンテンツを表示させつつ、前記クライアント端末の電話機能を用いた担当者との会話を提供するものであり、
   前記表示制御ステップは、前記クライアント端末における表示対象が、ユーザと担当者の通話開始時の通話画面から前記ウェブブラウザ画面へ切り替えられたことを前記サーバが検出した場合に、前記サーバが前記ウェブコンテンツを前記クライアント端末へ送信することを含むことを特徴とする請求項３に記載の表示制御方法。
5. 前記１つのサービスは、前記クライアント端末のユーザと、企業の担当者とのビデオチャットサービスであり、
   前記表示制御ステップは、前記クライアント端末が前記１つのサービスを要求した経路である特定経路が企業のウェブページからの経路である場合、前記担当者側での撮像画像を前記クライアント端末に表示させる一方、前記ユーザ側での撮像画像を前記担当者の端末に表示させることを抑制し、前記特定経路が店頭からの経路である場合、前記担当者側での撮像画像を前記クライアント端末に表示させ、かつ、前記ユーザ側での撮像画像を前記担当者の端末に表示させることを特徴とする請求項１から４のいずれかに記載の表示制御方法。
6. 前記表示制御ステップは、前記識別ステップにおいて識別された経路が、企業が顧客へ送付した所定のメッセージを起点とする経路である場合と、企業のウェブページからの経路である場合とで、前記サーバから前記１つのサービスが提供されるまでに前記クライアント端末に異なる画面遷移を実行させることを特徴とする請求項１から５のいずれかに記載の表示制御方法。

Images