JP2022178138A - サーバ装置、利用者端末、担当者端末、情報処理システム、情報処理方法及びプログラム - Google Patents

Abstract

【課題】ウェブサイトを通じてサービスを提供する事業者側の担当者とサービスの利用者との画面共有を簡便に実現する。【解決手段】サーバ装置に、ウェブサイトを通じて提供されるサービスの利用者が操作する利用者端末のブラウザ画面に、画面共有による支援が可能な状態にある担当者の候補を表示させるとともに、担当者の候補に対応するピアＩＤを送付する制御部を設ける。【選択図】図１１

Description

本発明は、サーバ装置、利用者端末、担当者端末、情報処理システム、情報処理方法及びプログラムに関する。

今日、行政機関等に対する届出や手続き等の一部は、インターネット上のサイトから電子申請が可能になっている。また、電子申請が可能な届出や手続き等の数は、今後も増加すると考えられる。

特開２０１９－１３３２７０号公報

一方で、多くの利用者にとっては、届出や手続きの機会がそもそも少ない。このため、書類への記入に迷うことがある。
確かに、記入欄には、テキストベースのヘルプ画面等が用意されることもあるが、ヘルプ画面等を開く手間が利用者に発生するほか、ヘルプ画面上で解決する課題は限定的である。
また、窓口であれば、少しの補助だけで、スムーズに書類を作成できる場合でも、電子申請になった途端に記入に手間取ることがある。
今日、ビデオ通話やビデオ会議が実用化されているが、それらは、双方が相手方のＩＤ（＝Identification）を事前に知っている場合や招待側が会議用のＵＲＬ（＝Uniform Resource Locator）を事前に渡している場合に限られる。
これら従前の通信手順は、利用者との間でリアルタイムのマッチングが求められる分野での使用には適していない。

本発明は、ウェブサイトを通じてサービスを提供する事業者側の担当者とサービスの利用者との画面共有を簡便に実現することを目的とする。

請求項１に記載の発明は、制御部を有し、前記制御部は、ウェブサイトを通じて提供されるサービスの利用者が操作する利用者端末のブラウザ画面に、画面共有による支援が可能な状態にある担当者の候補を表示させるとともに、当該担当者の候補に対応するピアＩＤを送付する、サーバ装置である。
請求項２に記載の発明は、前記制御部は、前記利用者端末から支援が可能な状態にある担当者の候補との画面共有が要求された場合に、前記担当者の候補を当該利用者端末に通知する、請求項１に記載のサーバ装置である。
請求項３に記載の発明は、前記制御部は、支援が可能な状態にある担当者の候補がいない場合、その旨を前記ブラウザ画面に表示させる、請求項１又は２に記載のサーバ装置である。
請求項４に記載の発明は、前記制御部は、画面共有による支援が可能な状態の担当者及び画面共有による支援中の担当者のピアＩＤと、各担当者を識別する情報と紐付けて管理する、請求項１又は２に記載のサーバ装置である。
請求項５に記載の発明は、前記制御部は、画面共有による支援に備えて待機している担当者のみを、画面共有による支援が可能な状態の前記担当者の候補として前記利用者端末に通知する、請求項４に記載のサーバ装置である。
請求項６に記載の発明は、ウェブサイトを通じて提供されるサービスの利用者が操作する利用者端末であって、前記ウェブサイト内で画面共有による支援を要求する操作を検知した場合、画面共有による前記利用者の支援を仲介するサーバ装置に対し、画面共有による支援が可能な状態にある担当者の候補の情報を要求し、当該サーバ装置から、画面共有による支援が可能な状態にある前記担当者の情報と当該担当者のピアＩＤを取得する制御部を有する、利用者端末である。
請求項７に記載の発明は、前記制御部は、ブラウザ画面上に、前記担当者と共有したい画面を選択するためのウィンドウを表示する、請求項６に記載の利用者端末である。
請求項８に記載の発明は、シングル・ページ・アプリケーションに対応するブラウザを使用する、請求項７に記載の利用者端末である。
請求項９に記載の発明は、前記制御部は、共用中の画面に対する前記担当者による入力を、当該画面が表示されるブラウザ画面の表示に反映させる、請求項６～８のうちいずれか１項に記載の利用者端末である。
請求項１０に記載の発明は、前記制御部は、前記担当者による前記入力を、前記共用中の画面を基準とする座標とともに受信し、前記ブラウザ画面の表示に反映する、請求項９に記載の利用者端末である。
請求項１１に記載の発明は、前記制御部は、前記共用中の画面内で前記担当者が指定した位置にポインタを予め定めた時間表示する、請求項９又は１０に記載の利用者端末である。
請求項１２に記載の発明は、前記制御部は、画面共有を開始した担当者に紐付けられているピアＩＤを前記サーバ装置に通知する、請求項６～１１のうちいずれか１項に記載の利用者端末である。
請求項１３に記載の発明は、ウェブサイトを通じて提供されるサービスの利用者を支援する担当者が操作する担当者端末であって、支援中の利用者と共用中の画面に対する担当者の入力の位置を、当該共用中の画面について規定される相対的な座標に変換し、利用者側に通知する制御部を有する、担当者端末である。
請求項１４に記載の発明は、前記制御部は、前記共用中の画面の対角線方向に位置する２つの頂点を基準点に定め、当該画面上の任意の位置を２つの基準点に対する相対座標として表現する、請求項１３に記載の担当者端末である。
請求項１５に記載の発明は、ウェブサイトを通じて提供されるサービスの利用者が操作する利用者端末と、前記利用者を支援する担当者が操作する担当者端末と、前記担当者による前記利用者の支援を仲介するサーバ装置とを有し、前記サーバ装置は、前記利用者端末のブラウザ画面に、画面共有による支援が可能な状態にある担当者の候補を表示させるとともに、当該担当者の候補に対応するピアＩＤを送付し、前記利用者端末は、前記担当者のピアＩＤと自端末のピアＩＤを用い、前記担当者端末と直接通信する、ことを特徴とする情報処理システムである。
請求項１６に記載の発明は、ウェブサイトを通じて提供されるサービスの利用者と、当該利用者を支援する担当者との画面共有を仲介するサーバ装置が実行する情報処理方法であって、利用者端末のブラウザ画面に、画面共有による支援が可能な状態にある担当者の候補を表示させる処理と、前記担当者の候補に対応するピアＩＤを送付する処理と、を有する情報処理方法である。
請求項１７に記載の発明は、ウェブサイトを通じて提供されるサービスの利用者と、当該利用者を支援する担当者との画面共有を仲介するサーバ装置を構成するコンピュータに、利用者端末のブラウザ画面に、画面共有による支援が可能な状態にある担当者の候補を表示させる機能と、前記担当者の候補に対応するピアＩＤを送付する機能と、を実現させるためのプログラムである。
請求項１８に記載の発明は、ウェブサイトを通じて提供されるサービスの利用者が操作する利用者端末を構成するコンピュータに、前記ウェブサイト内で画面共有による支援を要求する操作を検知した場合、画面共有による前記利用者の支援を仲介するサーバ装置に対し、画面共有による支援が可能な状態にある担当者の候補の情報を要求する機能と、前記サーバ装置から、画面共有による支援が可能な状態にある前記担当者の情報と当該担当者のピアＩＤを取得する機能と、を実現させるためのプログラムである。

請求項１記載の発明によれば、ウェブサイトを通じてサービスを提供する事業者側の担当者とサービスの利用者との画面共有を簡便に実現できる。
請求項２記載の発明によれば、利用者が支援を要求する場合に限り、担当者の候補を表示できる。
請求項３記載の発明によれば、支援が可能な状態の担当者の候補の不在を利用者に知らせることができる。
請求項４記載の発明によれば、利用者が操作する利用者端末に通知する情報に担当者の候補のピアＩＤを含めることができる。
請求項５記載の発明によれば、すぐに支援を開始できる担当者のみを利用者に提示できる。
請求項６記載の発明によれば、画面共有による支援が可能な状態にある担当者のピアＩＤを簡易に取得できる。
請求項７記載の発明によれば、画面共有による支援が可能な状態にある担当者のピアＩＤを簡易に取得できる。
請求項８記載の発明によれば、担当者との間で共有する画面の更新に要する時間を短縮できる。
請求項９記載の発明によれば、担当者の支援を視覚的に確認できる。
請求項１０記載の発明によれば、担当者との間で支援のずれをなくすことができる。
請求項１１記載の発明によれば、入力すべき位置や確認すべき位置の支援を受けることができる。
請求項１２記載の発明によれば、サーバ装置で支援中の担当者の管理を可能にできる。
請求項１３記載の発明によれば、利用者側と担当者側とで共用する画面のサイズや解像度が違っても、担当者が入力した位置を利用者側の表示に正確に反映できる。
請求項１４記載の発明によれば、利用者側と担当者側とで共用する画面のサイズや解像度が違っても、担当者が入力した位置を利用者側の表示に正確に反映できる。
請求項１５記載の発明によれば、ウェブサイトを通じてサービスを提供する事業者側の担当者とサービスの利用者との画面共有を簡便に実現できる。
請求項１６記載の発明によれば、ウェブサイトを通じてサービスを提供する事業者側の担当者とサービスの利用者との画面共有を簡便に実現できる。
請求項１７記載の発明によれば、ウェブサイトを通じてサービスを提供する事業者側の担当者とサービスの利用者との画面共有を簡便に実現できる。
請求項１８記載の発明によれば、画面共有による支援が可能な状態にある担当者のピアＩＤを簡易に取得できる。

実施の形態１で想定するクラウド窓口システムの概念構成例を説明する図である。 クラウド窓口仲介サーバの構成例を説明する図である。（Ａ）はクラウド窓口仲介サーバのハードウェア構成を示し、（Ｂ）はプログラムの実行を通じて実現される機能構成を示す。 担当者テーブルのデータ構造の一例を示す図である。 自治体の担当者が操作する端末の構成例を説明する図である。（Ａ）は端末のハードウェア構成を示し、（Ｂ）はプログラムの実行を通じて実現される機能構成を示す。 クラウド窓口の担当者が閲覧するディスプレイの画面例と住民が閲覧するディスプレイの画面例の関係を説明する図である。（Ａ）はクラウド窓口の担当者が閲覧している画面例を示し、（Ｂ）は住民が閲覧している画面例を示す。 共有画面に対する担当者の指示位置や文字等の入力位置を、住民側で閲覧される画面の座標に変換する機能を説明する図である。（Ａ）はクラウド窓口の担当者が閲覧している画面例を示し、（Ｂ）は住民が閲覧している画面例を示す。 住民が操作する端末の構成例を説明する図である。（Ａ）は端末のハードウェア構成を示し、（Ｂ）はプログラムの実行を通じて実現される機能構成を示す。 クラウド窓口のサービスに関連して実行される通信シーケンスを説明する図である。 クラウド窓口の業務を開始する担当者が閲覧するウェブサイトの画面例を説明する図である。（Ａ）はクラウド窓口へのログイン画面を示し、（Ｂ）は担当者の氏名が入力されたログイン画面を示し、（Ｃ）は開始ボタンが操作された後のログイン画面を示す。 住民が閲覧しているウェブサイトの画面例を説明する図である。（Ａ）は担当者との通話を求める場合に使用される「ビデオ通話」ボタンを含む画面を示し、（Ｂ）は通話可能な担当者が存在しない場合に表示される画面を示す。 住民が閲覧しているウェブサイトの画面例を説明する図である。（Ａ）は担当者との通話を求める場合に使用される「ビデオ通話」ボタンを含む画面を示し、（Ｂ）は通話可能な担当者が存在した場合に表示される画面を示す。 画面共有する画面を選択する住民側の画面例を説明する図である。（Ａ）は共有画面の選択ウィンドウに候補が１つ表示された画面を示し、（Ｂ）は共有画面の選択ウィンドウに複数の候補が表示された画面を示す。 ビデオ通話が開始した状態の画面例を説明する図である。（Ａ）は担当者側の画面を示し、（Ｂ）は住民側の画面を示す。 画面共有が開始した後の画面例を説明する図である。（Ａ）は担当者側の画面を示し、（Ｂ）は住民側の画面を示す。 住民が入力中の文字列が画面共有される様子を説明する図である。（Ａ）は担当者側の画面を示し、（Ｂ）は住民側の画面を示す。 担当者がポインタでクリックした共有画面上の位置に対応する住民側の画面にマークが表示される例を説明する図である。 申請内容の確認画面が共有画面として表示されている状態を説明する図である。（Ａ）は担当者側の画面を示し、（Ｂ）は住民側の画面を示す。 通話を終了する場面を説明する図である。（Ａ）は担当者側の画面を示し、（Ｂ）は住民側の画面を示す。

以下、図面を参照して、本発明の実施の形態を説明する。
＜実施の形態１＞
＜システム構成＞
図１は、実施の形態１で想定するクラウド窓口システム１の概念構成例を説明する図である。
図１に示すクラウド窓口システム１は、自治体が提供する窓口サービスの一部又は全てを、オンラインで住民に提供するために使用されるシステムである。
なお、クラウド窓口システム１は、特許請求の範囲における「情報処理システム」の一例である。

図１に示すクラウド窓口システム１は、インターネット１０と、自治体側の担当者が操作する端末４０Ａ、４０Ｂ…と住民が操作する端末５０間におけるＰ２Ｐ通信を実現するピア接続サーバ２０と、オンラインによる窓口サービスの利用を希望する住民に対し、担当者のピアＩＤを提供するクラウド窓口仲介サーバ３０と、自治体側のネットワークシステム４０と、住民が操作する端末５０とで構成されている。
本実施の形態の場合、住民が操作する端末５０は、住民宅の住居に設けられる場合を想定するが、自治体の出張所等に設けられていてもよい。この場合、端末５０の設置者は自治体となるが、利用者は住民となる。

ピア接続サーバ２０は、ＷｅｂＲＴＣ（＝Web Real Time Communication）を用いたリアルタイムコミュニケーションを実現するサーバであり、例えばシグナリングサーバ、ＳＴＵＮ（＝Session Traversal Utilities for NAT）サーバ、ＴＵＲＮ（＝Traversal Using Relays around NAT）サーバ、ＳＦＵ（＝Selective Forwarding Unit）サーバにより構成される。
シグナリングサーバは、ピア（Peer）を一意に識別するためのＩＤ（すなわちピアＩＤ）を生成し、Ｐ２Ｐ通信を求める端末に配布するサーバである。本システムの場合、ピアＩＤは、Ｐ２Ｐ通信毎に生成される。従って、Ｐ２Ｐ通信が終了すると、廃棄される。また、シグナリングサーバは、Ｐ２Ｐ通信に必要なＩＰアドレスやコーデック等を対象者間で交換する。

ＳＴＵＮサーバは、ＮＡＴ(＝Network Address Translation)が存在する環境でのＰ２Ｐ通信に必要なグローバルＩＰとポート番号を取得するサーバである。
ＴＵＲＮサーバは、データの中継により、Ｐ２Ｐ通信が利用できないネットワーク環境で使用される端末とのＷｅｂＲＴＣを可能にするサーバである。
ＳＦＵサーバは、多人数間の通話や映像配信を実現するサーバである。
本実施の形態では、シグナリングサーバとＳＴＵＮサーバの機能を主に使用する。

クラウド窓口仲介サーバ３０は、Ｐ２Ｐ通信中の担当者やＰ２Ｐ通信の準備が整った担当者の情報を管理する機能と、Ｐ２Ｐ通信の準備が整った担当者のピアＩＤを、オンラインによる窓口サービスの利用を希望する住民の端末５０に通知する機能とを提供する。
これらの機能により、住民が操作する端末５０は、ピア接続サーバ２０に対して、待機中の担当者とのＰ２Ｐ通信の設定を要求することが可能になる。
本実施の形態のクラウド窓口仲介サーバ３０は、住民が操作する端末５０のピアＩＤは管理しない。

自治体側のネットワークシステム４０は、クラウド窓口を担当する担当者が操作する複数台の端末４０Ａ、４０Ｂ…と、クラウド窓口に対応するウェブサイトの閲覧を可能にするウェブサーバとを有している。クラウド窓口を担当する担当者が操作する複数台の端末４０Ａ、４０Ｂ…は、ＬＡＮ（Local Area Network）又はインターネット経由で、クラウド窓口に対応するウェブサイトにアクセスが可能である。
また、複数台の端末４０Ａ、４０Ｂ…は、ＬＡＮ経由でインターネット１０に接続されている。
図１の場合、８台の端末４０Ａ、４０Ｂ…のうち２台がクラウド窓口のサービスに使用され、２台がクラウド窓口のサービスの提供のために待機中であり、他の４台は他の業務に使用されているか、担当者が離席中である。

図１では、サービスの使用されている端末４０Ａ及び４０Ｅを「通話中」と表している。
本実施の形態の場合、自治体側の担当者が操作する端末４０Ａ等は、いずれも自治体側の施設に構築されたＬＡＮに接続されている。もっとも、リモートデスクトップ方式や仮想デスクトップ方式により、ＬＡＮに接続されている端末４０Ａ等を外部から操作してもよい。
クラウド窓口のサービスを利用する又は利用を希望する住民が操作する端末５０は、例えば家庭で使用するコンピュータやスマートフォンである。

図１では、説明の都合上、自治体側のネットワークシステム４０が１つの場合を例示したが、実際のクラウド窓口システム１は、複数のネットワークシステム４０を含んでもよい。すなわち、クラウド窓口仲介サーバ３０は、複数のネットワークシステム４０に対して、仲介サービスを提供してもよい。なお、複数のネットワークシステム４０は、単一の自治体が運用してもよいし、複数の自治体が運用してもよい。
また、図１では、説明の都合上、住民が操作する端末５０を１つだけ表しているが、実際のクラウド窓口システム１には、複数台の端末５０が接続され得る。

＜サーバ及び端末の構成＞
以下では、クラウド窓口仲介サーバ３０と、クラウド窓口の担当者が操作する端末４０Ａ等と、住民が操作する端末５０の各構成について説明する。

＜クラウド窓口仲介サーバの構成＞
図２は、クラウド窓口仲介サーバ３０の構成例を説明する図である。（Ａ）はクラウド窓口仲介サーバ３０のハードウェア構成を示し、（Ｂ）はプログラムの実行を通じて実現される機能構成を示す。
ここでのクラウド窓口仲介サーバ３０は、特許請求の範囲における「サーバ装置」の一例である。

図２に示すクラウド窓口仲介サーバ３０は、制御ユニット３１、ハードディスクドライブ（以下「ＨＤＤ」ともいう）３２、通信モジュール３３で構成される。なお、必要に応じて、ディスプレイ、キーボード、マウスも含まれる。
図２に示す制御ユニット３１は、ＣＰＵ（＝Central Processing Unit）３１Ａと、ＲＯＭ（＝Read Only Memory）３１Ｂと、ＲＡＭ（＝Random Access Memory）３１Ｃと、を有している。
ＣＰＵ３１Ａは、プログラムの実行を通じて各種の機能を実現する。ＲＯＭ３１Ｂには、ＢＩＯＳ（＝Basic Input/Output System）等が記憶される。また、ＲＡＭ３１Ｃは、プログラムの実行領域として使用される。

ハードディスクドライブ３２は、補助記憶装置であり、オペレーションシステムやアプリケーションプログラムが記憶される。ハードディスクドライブ３２の代わりに、半導体メモリを使用してもよい。
通信モジュール３３は、他の装置との通信に使用される。

本実施の形態では、自治体側の担当者と住民とのＰ２Ｐ通信を仲介するサービスを提供するアプリケーションプログラム３２Ａの実行により、担当者テーブル管理部３１１と非通話中ピアＩＤ通知部３１２が実現される。
担当者テーブル管理部３１１は、担当者テーブル３２Ｂの更新を通じ、クラウド窓口のサービスを提供中の担当者と待機中の担当者の情報を管理する。

図３は、担当者テーブル３２Ｂのデータ構造の一例を示す図である。図３に示す担当者テーブル３２Ｂは、職員ＩＤと、担当者の氏名と、通話状況と、ピアＩＤとで構成される。
職員ＩＤは、自治体の職員を識別するためのＩＤである。図３の場合、担当者テーブル３２Ｂには、クラウド窓口のサービスを提供中の担当者とクラウド窓口のサービスを担当する可能性がある全ての担当者の情報が登録されている。

図３の場合、クラウド窓口のサービスを提供している担当者は「平成太郎」である。このため、「平成太郎」の通信状況は「通話中」である。
また、クラウド窓口のサービスの準備が整った状態にある担当者は「令和花子」と「東明」の２名である。このうち、「令和花子」の通信状況は「待機中」であるが、「東明」は住民とのＰ２Ｐ通信が開始したので通話状況が「待機中」から「通話中」に切り替わっている。
なお、ピアＩＤは、担当者がＬＡＮへのログイン後にクラウド窓口を利用するタイミングで発行される。このため、図３に示す担当者テーブル３２Ｂには、通信状況が「通話中」か「待機中」の３名にのみ記録されている。

担当者テーブル管理部３１１は、ピア接続サーバ２０（図１参照）からピアＩＤの通知を受けた端末４０Ａ等からピアＩＤを取得して担当者テーブル３２Ｂに記録する機能、Ｐ２Ｐ通信が終了した担当者のピアＩＤを担当者テーブル３２Ｂから削除する機能を提供する。
非通話中ピアＩＤ通知部３１２は、住民が操作する端末５０（図１参照）からの要求に基づいて、非通話中である１人又は複数人の担当者のピアＩＤを通知する機能を提供する。なお、クラウド窓口のサービスの準備が整っている担当者がいない場合、非通話中ピアＩＤ通知部３１２は、対応が可能な担当者がいないことを端末５０に返信する。

＜自治体の担当者が操作する端末の構成＞
図４は、自治体の担当者が操作する端末４０Ａの構成例を説明する図である。（Ａ）は端末４０Ａのハードウェア構成を示し、（Ｂ）はプログラムの実行を通じて実現される機能構成を示す。
図４では、ネットワークシステム４０を構成する複数の端末４０Ａ、４０Ｂ…を代表して端末４０Ａの構成を示している。
ここでの端末４０Ａは、特許請求の範囲における「担当者端末」の一例である。

本実施の形態における端末４０Ａには、シングル・ページ・アプリケーションに対応するブラウザがインストールされている。シングル・ページ・アプリケーションに対応するため、ページ遷移がない。また、ブラウザで実行可能な機能はＪＡＶＡＳＣＲＩＰＴ（登録商標）で実現される。すなわち、画面遷移の場合、画面全体の再描画が不要であり、変更部分のみが更新される。このため、外部との通信容量が削減され、表示のレスポンス性能も向上する。

図４に示す端末４０Ａは、制御ユニット４１、ハードディスクドライブ４２、ディスプレイ４３、マウス４４、キーボード４５、カメラ４６、通信モジュール４７で構成される。
図４に示す制御ユニット４１は、ＣＰＵ４１Ａと、ＲＯＭ４１Ｂと、ＲＡＭ４１Ｃと、を有している。
ＣＰＵ４１Ａは、プログラムの実行を通じて各種の機能を実現する。ＲＯＭ４１Ｂには、ＢＩＯＳ等が記憶される。また、ＲＡＭ４１Ｃは、プログラムの実行領域として使用される。

ハードディスクドライブ４２は、補助記憶装置であり、オペレーションシステムやアプリケーションプログラムが記憶される。ハードディスクドライブ４２の代わりに、半導体メモリを使用してもよい。
本実施の形態の場合、ハードディスクドライブ４２には、クラウド窓口のサービスの提供に関連するアプリケーションプログラム４２Ａが記録されている。
本実施の形態の場合、アプリケーションプログラム４２Ａの実行により、ピアＩＤ登録部４１１と共有画面座標変換部４１２が実現される。

ピアＩＤ登録部４１１は、職員用のウェブサイトに担当者がログインする場合に、ピア接続サーバ２０（図１参照）から通知されたピアＩＤをクラウド窓口仲介サーバ３０（図１参照）に登録する機能を提供する。前述したように、このピアＩＤは、担当者に紐づけて担当者テーブル３２Ｂ（図３参照）に登録される。
共有画面座標変換部４１２は、ディスプレイ４３に表示された共有画面上の任意の地点を与える座標を、住民が操作する端末５０（図１参照）に表示される共有画面上の座標に変換する機能を提供する。

図５は、クラウド窓口の担当者が閲覧するディスプレイ４３の画面例と住民が閲覧するディスプレイ５３の画面例の関係を説明する図である。（Ａ）はクラウド窓口の担当者が閲覧している画面例を示し、（Ｂ）は住民が閲覧している画面例を示す。
クラウド窓口の担当者が操作する端末４０Ａ側のディスプレイ４３の解像度と、住民が操作する端末５０（図１参照）側のディスプレイ５３の解像度は必ずしも一致しない。

また、クラウド窓口の担当者が閲覧するディスプレイ４３では、住民との間で共有する画面４３０（すなわち共有画面４３０）がディスプレイ４３の一部分に表示される。また、共有画面４３０のディスプレイ４３内における表示の位置や表示のサイズは任意である。
図５の例では、住民側のディスプレイ５３の画面全体（以下「全画面」ともいう）が、共有画面４３０としてディスプレイ４３の一部分に表示されている。

図５の場合、共有画面４３０の外側には、担当者が画面上で移動させるポインタ４３０Ａ１が表示されている。また、共有画面４３０の内側には、住民が画面上で移動させるポインタ５３１が表示されている。
なお、共有画面４３０は、住民側のディスプレイ５３の画面全体とは限らない。例えば選択したアプリケーションのウィンドウやブラウザの特定のタブが共有画面４３０として指定されることもある。

担当者側のディスプレイ４３の座標は、例えば左上隅を原点（０，０）として、画面内の水平方向の画素数と垂直方向の画素数で与えられる。
一方、住民側のディスプレイ５３の座標は、例えば左上隅を原点（０，０）として、画面内の水平方向の画素数と垂直方向の画素数で与えられる。
前述したように、担当者側のディスプレイ４３の解像度と住民側のディスプレイ５３の解像度は必ずしも一致せず、担当者側のディスプレイ４３上における共有画面の表示の位置や表示のサイズも任意である。このため、担当者が指示した地点の情報を住民が操作する端末５０にそのまま送信したのでは、担当者が意図する位置を住民に知らせることができない。

図６は、共有画面に対する担当者の指示位置や文字等の入力位置を、住民側で閲覧される画面の座標に変換する機能を説明する図である。（Ａ）はクラウド窓口の担当者が閲覧している画面例を示し、（Ｂ）は住民が閲覧している画面例を示す。図６には、図５との対応部分に対応する符号を付して示している。
共有画面座標変換部４１２は、担当者側のディスプレイ４３の共有画面４３０の左上隅を原点（０，０）とし、その対角方向である右下隅を（１，１）とし、共有画面４３０内の座標（ｘ，ｙ）を相対座標として与える。すなわち、共有画面４３０内の位置を、外枠を基準とした相対座標により与える。このため、ｘとｙは、いずれも０以上１以下の数値で与えられる。

本実施の形態の場合、共有画面４３０の外枠を基準に用いるので、共有画面４３０内にタブやブックマークが表示されていても、それらの表示も含めて、共有画面４３０内の任意の位置の特定が可能になる。
図６（Ｂ）には、担当者が共有画面４３０上でクリックした位置にマーク５４０が表示されている。このマーク５４０は、共有画面４３０に対応する画面全体の左上隅を原点（０，０）とし、右下隅を（１，１）とした相対座標に表示される。
なお、相対座標は、ＷｅｂＲＴＣのデータチャネル機能を用いて、担当者が操作する端末４０Ａから住民が操作する端末５０に直接送信される。

＜住民が操作する端末の構成＞
図７は、住民が操作する端末５０の構成例を説明する図である。（Ａ）は端末５０のハードウェア構成を示し、（Ｂ）はプログラムの実行を通じて実現される機能構成を示す。
ここでの端末５０は、特許請求の範囲における「利用者端末」の一例である。
本実施の形態における端末５０にも、シングル・ページ・アプリケーションに対応するブラウザがインストールされている。
図７に示す端末５０は、制御ユニット５１、ハードディスクドライブ５２、ディスプレイ５３、マウス５４、キーボード５５、カメラ５６、通信モジュール５７で構成される。

図７に示す制御ユニット５１は、ＣＰＵ５１Ａと、ＲＯＭ５１Ｂと、ＲＡＭ５１Ｃと、を有している。
ＣＰＵ５１Ａは、プログラムの実行を通じて各種の機能を実現する。ＲＯＭ５１Ｂには、ＢＩＯＳ等が記憶される。また、ＲＡＭ５１Ｃは、プログラムの実行領域として使用される。

ハードディスクドライブ５２は、補助記憶装置であり、オペレーションシステムやアプリケーションプログラムが記憶される。ハードディスクドライブ５２の代わりに、半導体メモリを使用してもよい。
本実施の形態の場合、ハードディスクドライブ５２には、クラウド窓口のサービスの利用に関連するアプリケーションプログラム５２Ａが記録されている。
本実施の形態の場合、アプリケーションプログラム５２Ａの実行により、複数の機能が実現される。

具体的には、ＣＰＵ５１Ａは、ピアリスト要求部５１１、待機者情報要求部５１２、通話相手選択画面表示部５１３、選択ピアＩＤ設定部５１４、共有画面選択受付部５１５、担当者操作反映部５１６として機能する。
ピアリスト要求部５１１は、ピア接続サーバ２０（図１参照）に対し、ピア（Peer）のリストを要求する機能である。ここでの要求は、利用するクラウド窓口に関連するピアに限定してもよい。

待機者情報要求部５１２は、クラウド窓口の担当者とのＰ２Ｐ通信を仲介するクラウド窓口仲介サーバ３０（図１参照）に対する待機中の担当者の情報を要求する機能である。クラウド窓口仲介サーバ３０からの応答として、待機者情報要求部５１２は、待機中の担当者の氏名やピアＩＤの情報等を取得する。
担当者の氏名は、担当者を識別する情報の一例である。担当者を識別する情報は、担当者の名字や職員ＩＤでもよい。
また、待機中の担当者が存在しない場合、待機者情報要求部５１２は、待機中の担当者が存在しない旨の通知を受ける。

通話相手選択画面表示部５１３は、クラウド窓口の利用に際し、通話相手となる担当者を選択するための画面をディスプレイ５３に表示する機能である。
通話相手選択画面表示部５１３は、ピアリスト要求部５１１が取得したピアリストから、待機中の担当者の情報だけを抽出し、通話相手の候補としてディスプレイ５３に表示する。
なお、待機中の担当者が複数存在する場合、表示する人数を制限してもよい。例えば１名だけを通話相手の候補として表示してもよい。
また、待機中の担当者が存在しない場合、通話相手の候補がいない旨を表示してもよい。

選択ピアＩＤ設定部５１４は、通話相手として選択した担当者のピアＩＤをクラウド窓口仲介サーバ３０に通知する機能である。この通知により、担当者テーブル３２Ｂにおける担当者の通話状況は「待機中」から「通話中」に更新される。
共有画面選択受付部５１５は、クラウド窓口を利用する住民が担当者と共有する画面の選択を受け付ける機能を提供する。本実施の形態の場合、全画面、アプリケーションウィンドウ、ブラウザのタブの選択が可能である。
担当者操作反映部５１６は、担当者が共有画面上でクリックした位置にマーク５４０（図６参照）を表示する機能を提供する。なお、担当者操作反映部５１６は、担当者が共有画面に対して入力した文字列を、共有画面上に反映する機能も提供する。なお、入力された文字列もデータチャネルを通じて直接通信される。

＜クラウド窓口に関連する通信シーケンス＞
以下では、図８～図１８を使用し、クラウド窓口に関連する通信シーケンスについて説明する。
図８は、クラウド窓口のサービスに関連して実行される通信シーケンスを説明する図である。
図８に示す通信シーケンスは８つのステージで構成される。以下では、ステージごとに説明する。

＜ステージ１及び２＞
ステージ１では、担当者が端末４０Ａのブラウザを通じ、担当者用のウェブサイトにアクセスする。
図９は、クラウド窓口の業務を開始する担当者が閲覧するウェブサイトの画面例を説明する図である。（Ａ）はクラウド窓口へのログイン画面４３０Ａを示し、（Ｂ）は担当者の氏名が入力されたログイン画面４３０Ｂを示し、（Ｃ）は開始ボタンが操作された後のログイン画面４３０Ｃを示す。

図９（Ａ）に示すログイン画面４３０Ａには、「クラウド窓口」とのタイトルと、担当者に求める操作の説明欄４３１と、氏名の入力欄４３２が配置されている。この例の場合、説明欄４３１には、「下記に氏名を入力して下さい。開始ボタンを押すと待機状態になります。」が記載されている。この段階の入力欄４３２は空である。説明の都合上、図９（Ａ）及び（Ｂ）では、担当者の氏名の入力のみを求めているが、担当者の氏名の入力に加え、担当者が担当する手続きや業務等の選択を受付けてもよい。

図９（Ｂ）に示すログイン画面４３０Ｂの場合、担当者は、入力欄４３２に「東明」と入力し、開始ボタンを操作している。開始ボタンには、ピア接続サーバ２０（図８参照）へのリンクが埋め込まれている。
担当者が開始ボタンを操作すると、端末４０Ａは、ピア接続サーバ２０に対し、ピアの作成を要求する（図８の１－ａ）。
ピアＩＤの作成要求を受信したピア接続サーバ２０は、ピア情報を作成し（図８の１－ｂ）、作成されたピア情報を端末４０Ａに送信する（図８の１－ｃ）。ここでのピア情報には、開始ボタンを操作した担当者について作成されたピアＩＤが含まれる。

開始ボタンが操作されると、ディスプレイ４３の表示は、ログイン画面４３０Ｃに切り替わる。図９（Ｃ）に示すログイン画面４３０Ｃの説明欄４３１には、「市民の方が入り次第、ビデオ通話が始まります。」と記載されている。
また、入力欄４３２に代えて、待機中であることを示すステータスバー４３３と、キャンセルボタン４３４が表示される。キャンセルボタン４３４が操作されると、ログイン画面４３０Ａに表示が切り替わる。

ステージ２では、ピア接続サーバ２０からピアＩＤを受信した端末４０Ａが、クラウド窓口仲介サーバ３０に対し、ピアＩＤを送信する（図８の２－ａ）。
クラウド窓口仲介サーバ３０は、自治体の担当者が操作する端末４０ＡからピアＩＤを受信すると、担当者テーブル３２Ｂ（図３参照）にピアＩＤを保存する（図８の２－ｂ）。この際、クラウド窓口仲介サーバ３０は、担当者テーブル３２Ｂの担当者に紐付けてピアＩＤを保存する。なお、担当者の通信状況の欄には、「待機中」が記録される。

＜ステージ３～５＞
ステージ３では、住民が、端末５０のブラウザを通じ、住民向けのウェブサイトにアクセスする。
図１０は、住民が閲覧しているウェブサイトの画面例を説明する図である。（Ａ）は担当者との通話を求める場合に使用される「ビデオ通話」ボタンを含む画面５３０Ａを示し、（Ｂ）は通話可能な担当者が存在しない場合に表示される画面５３０Ｂを示す。

図１０（Ａ）に示す画面５３０Ａは、仮想の東京市が開設するウェブサイトに設けられているネット手続き用の申請画面である。
画面５３０Ａのうちサービスの利用者である住民に求める操作の説明欄５３１には、「東京市へのお手続きをネットで行うことができます。」が記載されている。また、説明欄５３１の下には、目的とする手続きの検索に使用する検索欄５３２が設けられている。
この他、画面５３０Ａの右下には「ビデオ通話」ボタン５３３が設けられている。

この「ビデオ通話」ボタン５３３は、東京市側の担当者とのビデオ通話を必要とする住民のために用意されている。
この「ビデオ通話」ボタン５３３が住民によりクリックされると、担当者とのＰ２Ｐ通信の実現に必要な処理が開始される。もっとも、待機中の職員がいない場合、「ビデオ通話」ボタン５３３を表示しない仕様とすることも可能である。以下では、図１０（Ａ）に示すように「ビデオ通話」ボタン５３３が表示される場合について説明する。
まず、「ビデオ通話」ボタン５３３が操作されると、端末５０は、ピア接続サーバ２０に対し、ピアの作成を要求する（図８の３－ａ）。

ピアＩＤの作成要求を受信したピア接続サーバ２０は、ピア情報を作成し（図８の３－ｂ）、作成されたピア情報を端末５０に送信する（図８の３－ｃ）。ここでのピア情報には、住民用のピアＩＤが含まれる。
端末５０は、住民用のピアＩＤを取得すると、ピア接続サーバ２０に対し、ピアのリスト（以下「ピアリスト」という）を要求する（図８の４－ａ）。
この要求に対し、ピア接続サーバ２０は、現在のピアリストを端末５０に送信する。すなわち、端末５０は、ピア接続サーバ２０からピアリストを取得する（図８の４－ｂ）。

この後、端末５０は、クラウド窓口仲介サーバ３０に対し、待機中のピアＩＤを要求する（図８の４－ｃ）。すなわち、東京市に対し、ビデオ通話のために待機している担当者のピアＩＤが要求される。
この要求に対し、クラウド窓口仲介サーバ３０は、担当者テーブル３２Ｂの通話状況が「待機中」である担当者のピアＩＤを抽出し、端末５０に送信する。すなわち、端末５０は、非通話中のピアＩＤを取得する（図８の４－ｄ）。
以上により、通話が可能なピアが特定され、住民が閲覧する画面の表示が変化する。

図１０（Ｂ）に示す画面５３０Ｂは、図８の（４－ｄ）の取得が完了した段階で表示される。因みに、画面５３０Ｂは、通話が可能な担当者が存在しない場合の表示例である。
画面５３０Ｂの右下部分に表示される情報欄５３４には、「現在、ビデオ通話が可能な職員がおりません。」とのメッセージ５３４Ａと、「閉じる」ボタン５３４Ｂと、「更新」ボタン５３４Ｃが含まれる。
「閉じる」ボタン５３４Ｂは、今回のビデオ通話を中止する場合に用いられる。この場合、端末５０からピア接続サーバ２０に対してピアの破棄要求が送信される。
一方、「更新」ボタン５３４Ｃは、待機中の担当者の情報の再取得に用いられる。「更新」ボタン５３４Ｃが操作されると、図８の（４－ａ）～（４－ｄ）の動作が再び実行される。

図１１は、住民が閲覧しているウェブサイトの画面例を説明する図である。（Ａ）は担当者との通話を求める場合に使用される「ビデオ通話」ボタンを含む画面５３０Ａを示し、（Ｂ）は通話可能な担当者が存在した場合に表示される画面５３０Ｃを示す。図１１には、図１０との対応部分に対応する符号を付して示している。
図１１（Ｂ）に示す画面５３０Ｃの場合、右下部分に情報欄５３５が表示される。情報欄５３５には、「下記の職員とビデオ通話が可能です」とのメッセージ５３５Ａと、担当者の氏名欄５３５Ｂと、「閉じる」ボタン５３５Ｃと、「更新」ボタン５３５Ｄが含まれる。図１１（Ｂ）の場合、ビデオ通話が可能な担当者の氏名は「東明」さんである。

この段階では、ビデオ通話は開始していない。表示された担当者とのビデオ通話を開始する場合、住民は、氏名欄５３５Ｂをクリックする。ここでのクリックは、通話相手のピアＩＤを選択することを意味する（図８の５－ａ）。
なお、「閉じる」ボタン５３５Ｃが操作されると、今回のビデオ通話は中止となり、ピアの破棄がピア接続サーバ２０に送信される。
一方、「更新」ボタン５３５Ｄが操作されると、図８の（４－ａ）～（４－ｄ）の動作が再び実行される。
この後、端末５０は、通信相手に選択した担当者のピアＩＤをピア接続サーバ２０に通知し、選択された担当者の端末４０Ａとの間でＰ２Ｐ通信に必要な情報の受け渡しが実行される。

＜ステージ６＞
ステージ６では、Ｐ２Ｐ通信の確立に伴い（図８の６－ａ）、端末４０Ａと端末５０との間で、ビデオ通話、画面共有、マウス座標データ等の通信が実行される。
図１２は、画面共有する画面を選択する住民側の画面例を説明する図である。（Ａ）は共有画面の選択ウィンドウ５３６に候補が１つ表示された画面５３０Ｄを示し、（Ｂ）は共有画面の選択ウィンドウ５３６に複数の候補が表示された画面５３０Ｅを示す。

画面５３０Ｄと画面５３０Ｅのいずれにも、選択ウィンドウ５３６と住民のビデオ映像５３７が表示されている。ビデオ映像５３７は、カメラ５６（図７参照）で撮像される。
選択ウィンドウ５３６の上段には、共有画面の候補として、「あなたの全画面」、「アプリケーションウィンドウ」、「ブラウザのタブ」が表示されている。
図１２（Ａ）に示す画面５３０Ｄでは、全画面の縮小画像だけが表示されている。
図１２（Ｂ）に示す画面５３０Ｅでは、各候補に対応する縮小画面が表示されている。

画面５３０Ｄと画面５３０Ｅの下部には、「共有」ボタン５３６Ａと「キャンセル」ボタン５３６Ｂが設けられている。
特定の縮小画面が選択された状態で「共有」ボタン５３６Ａが操作されると、通信相手である担当者の端末４０Ａとの画面共有が確定し、対応するビデオ映像がＰ２Ｐ通信により共有される。
一方、「キャンセル」ボタン５３６Ｂが操作されると、画面共有は行われない。

図１３は、ビデオ通話が開始した状態の画面例を説明する図である。（Ａ）は担当者側の画面４３０Ｄを示し、（Ｂ）は住民側の画面５３０Ｆを示す。図１３には、図１２との対応部分に対応する符号を付して示している。
担当者が閲覧する画面４３０Ｄには、閲覧中の画面のタイトルを示す「クラウド窓口」と、対応中の担当者の氏名欄４３５と、共用画面が表示される表示欄４３６と、担当者のビデオ映像４３７と、通話中の住民のビデオ映像４３８と、通話の終了に用いる「通話を終了する」ボタン４３９とが設けられている。

担当者のビデオ映像４３７と住民のビデオ映像４３８は、Ｐ２Ｐ通信が開始すると、画面内に表示される。ビデオ通話の開始後は、映像と音声によるコミュニケーションが可能になる。
なお、図１３（Ａ）では、住民側が画面の共有開始を指示する「共有」ボタン５３６Ａを操作していないので、表示欄４３６は空欄のままである。

一方、図１３（Ｂ）に示す画面５３０Ｆは、「共有」ボタン５３６Ａの操作前にＰ２Ｐ通信が開始した場合に表示される。
このため、画面５３０Ｆの中央には、共有画面の選択ウィンドウ５３６が表示されている。
なお、画面５３０Ｆの右下には、住民のビデオ映像５３７に加えて、東京市側の担当者である「東明」さんのビデオ映像５３８が追加されている。
また、Ｐ２Ｐ通信を終了するための「通話を終了する」ボタン５３９も追加されている。

因みに、住民と担当者とのＰ２Ｐ通信が開始すると、住民側の端末５０は、クラウド窓口仲介サーバ３０に対し、選択したピアＩＤを通話中に設定する（図８の６－ｂ）。具体的には、図１１（Ｂ）の画面５３０Ｃで選択した「東明」のピアＩＤがクラウド窓口仲介サーバ３０に送信される。
この通知を受信したクラウド窓口仲介サーバ３０は、担当者テーブル３２Ｂにおける「東明」さんの通信状況を「待機中」から「通話中」に更新する。

図１４は、画面共有が開始した後の画面例を説明する図である。（Ａ）は担当者側の画面４３０Ｄを示し、（Ｂ）は住民側の画面５３０Ｆを示す。図１４には、図１３との対応部分に対応する符号を付して示している。
図１４の場合、東京市の担当者側の画面４３０Ｄの表示欄４３６には、住民が共用画面に設定した住民側のディスプレイ５３（図７参照）の全画面の表示が開始されている。
図１４の場合、住民は、「特定検診受診券再発行・新規発行」の画面を閲覧していることが分かる。

図１５は、住民が入力中の文字列が画面共有される様子を説明する図である。（Ａ）は担当者側の画面４３０Ｄを示し、（Ｂ）は住民側の画面５３０Ｆを示す。図１５には、図１４との対応部分に対応する符号を付して示している。
図１５の例では、「申請者の情報」ページの名前の欄に「キタイブキ」が住民により入力されている。
図１５（Ａ）に示す画面４３０Ｄには、担当者が操作するポインタ４３０Ａ１が名前の欄の付近に表示されている。

図１６は、担当者がポインタ４３０Ａ１でクリックした共有画面上の位置に対応する住民側の画面５３０Ｆにマーク５４０が表示される例を説明する図である。（Ａ）は担当者側の画面４３０Ｄを示し、（Ｂ）は住民側の画面５３０Ｆを示す。図１６には、図１５との対応部分に対応する符号を付して示している。
図１６では、円形のマーク５４０が「住所を自動入力」の位置に表示されている。この場面で、担当者は、郵便番号の入力後に「住所を自動入力」のボタンをクリックすると、住所欄に対応する住所の文字列が自動的に入力されることを説明している。

図１６の場合には、ポインタの座標を共用画面内の相対位置で表現することにより、マーク５４０を共用画面上に表示させているが、入力欄の座標を相対位置で表現すれば、担当者が代理で入力した文字を住民側の画面に反映させることも可能になる。同様に、チェックボックスへの担当者によるチェックを、住民側の画面に反映させることが可能になる。
図１７は、申請内容の確認画面が共有画面として表示されている状態を説明する図である。（Ａ）は担当者側の画面４３０Ｄを示し、（Ｂ）は住民側の画面５３０Ｆを示す。図１７には、図１６との対応部分に対応する符号を付して示している。

＜ステージ７及び８＞
図１８は、通話を終了する場面を説明する図である。（Ａ）は担当者側の画面４３０Ｄを示し、（Ｂ）は住民側の画面５３０Ｆを示す。図１８には、図１７との対応部分に対応する符号を付して示している。
図１８では、申請完了時の画面が共有画面として表示されている。
通話の終了時（図８の７）、担当者と住民は、それぞれ「通話を終了する」ボタン４３９及び５３９をクリックする。

担当者が「通話を終了する」ボタン４３９をクリックすると、端末４０Ａからピア接続サーバ２０に対し、ピアの破棄が要求される（図８の８－ａ）。この要求を受信したピア接続サーバ２０は、対応するピアを破棄する（図８の８－ｂ）。なお、「通話を終了する」ボタン４３９のクリックは、端末４０Ａからクラウド窓口仲介サーバ３０に送信される。
同様に、住民が「通話を終了する」ボタン５３９をクリックすると、端末５０からピア接続サーバ２０に対し、ピアの破棄が要求される（図８の８－ｃ）。この要求を受信したピア接続サーバ２０は、対応するピアを破棄する（図８の８－ｄ）。
なお、本実施の形態では、クラウド窓口を使用した申請手続きについて説明したが、届出、請求、問い合わせ等にも応用できる。

＜まとめ＞
本実施の形態で説明したクラウド窓口仲介サーバ３０を設置し、担当者や住民とのＰ２Ｐ通信に必要となるピアＩＤの仲介を可能とすることにより、従前まではオフラインでしか対応できなかった窓口サービスのオンライン化が実現される。また、従前に比して窓口サービスのオンライン化が簡便化される。
例えば本実施の形態で説明した自治体の行政サービスへの応用により、様々なメリットが期待される。
例えば対面による窓口サービスでは、一度に対応可能な人数を増やしたい場合、物理的な窓口の増設が必要になるが、設置スペースの確保が難しい場合がある。しかし、クラウド窓口であれば、専用スペースが不要であるため、対応人数の増加も容易である。

また、窓口サービスは、繁閑の差が大きいため、人員の配置が難しい。また、閑散期でも、専属の担当者を窓口に配置する等、業務効率の改善が求められる。しかし、クラウド窓口であれば、繁閑に応じて担当者の配置の増減が容易である。このため、職員の労働生産性の向上が可能になる。
また、窓口サービスの対象となる手続きは多種多様であり、取り扱う件数の差も大きい。例えば年に数件程度しか発生しない手続きもある。このため、窓口サービスを担当する全員に全ての業務を教育するコストは膨大になる。しかし、取り扱い件数が少ない業務は特定の人員に取り次ぐことができれば、教育に要するコストの削減や人員の配置に要するコストの削減が可能になる。

また、昨今では、日本語以外の言語による行政サービスの提供が求められるが、クラウド窓口であれば、日本語以外の言語に精通した人員を教育し、全ての拠点に配置するコストを削減できる。
また、クラウド窓口であれば、遠隔地から行政サービスの提供が可能になる。結果的に、住民が居住する地域に、住民が話す言語に精通した担当者が駐在しない場合でも、遠隔地から行政サービスの提供が可能になる。また、クラウド窓口の仕組みを用いれば、在宅勤務による住民への対応や行政サービスのアウトソーシング化も可能になる。

また、クラウド窓口の利用により、住民にも以下のメリットが期待される。
例えば住民は、従前のように自治体側の施設を訪問しなくても、ビデオ通話と画面共有により、手続きを完了できる。つまり、移動の負担や、移動に要する時間の節約、移動に要する費用の削減が可能になる。
例えば高齢者や身体に障碍がある方のように移動が困難な方は、従前に比して行政サービスの利用が容易になる。
また、子育て中のために外出に制約がある方にとっても、従前に比して行政サービスの利用が容易になる。

また、仕事等の関係で時間的な制約がある方も、従前に比して行政サービスの利用が容易になる。
また、移動に時間が要する場所や他県等に居住する住民による手続きも、従前に比して行政サービスの利用が容易になる。例えば移住前の手続き、移住後の手続き、高齢の親の代理による手続き等の場合でも、クラウド窓口であれば、時間的な制約や距離的な制約が少なくなるため、手続き上の負担が軽減される。
また、自治体の窓口での手続きは待ち時間が長くなる一方で、順番になるまでその場を離れられなかったり、他の作業を行えなかったりすることがある。しかし、クラウド窓口であれば、待ち時間も自身の仕事や家事を行うことが可能になる。

また、社会的な環境として、非対面での対応が望まれる場合もある。
例えば新型コロナの蔓延下では外出の自粛が推奨され、他者との接触の可能性も低減することが望まれる。このような環境下では、クラウド窓口により、不特定の多数との接触の機会を積極的に低減できる。
また、難病指定に関連する手続き等では、心理的に対面対応を希望されない方もいる。また、家庭内暴力や生活保護の相談等、心理的に窓口に出向きたくない方もいる。
しかし、クラウド窓口であれば、窓口に出向く必要がなく、心理的な負担の軽減を実現できる。

＜他の実施の形態＞
（１）以上、本発明の実施の形態について説明したが、本発明の技術的範囲は前述した実施の形態に記載の範囲に限定されない。前述した実施の形態に、種々の変更又は改良を加えたものも、本発明の技術的範囲に含まれることは、特許請求の範囲の記載から明らかである。

（２）前述の実施の形態では、クラウド窓口の仕組みを自治体による住民サービスに活用する場合を想定したが、サービスの利用者とサービスの提供者の間で画面共有やビデオ通話を簡易な操作で実現する仕組みは、金融、医療、教育等にも活用が可能である。

（３）前述の実施の形態では、画面共有とビデオ通話の両方を同時に実行しているが、ビデオ通話や画面共有を選択的にオン又はオフできるようにしてもよい。

（４）前述の実施の形態では、サービスの利用者である住民とサービスの提供者である自治体側の担当者とのＰ２Ｐ通信を、クラウド窓口仲介サーバ３０により実現しているが、ルーム機能を用いて３人以上の通信を可能にしてもよい。すなわちメッシュ接続により、３人以上のＰ２Ｐ通信を実現してもよい。

（５）前述の実施の形態の場合には、サービスの提供側である自治体側の担当者がピアの作成をピア接続サーバ２０（図８参照）に要求し、待機状態になった後に、サービスの利用者である住民によるピアの作成がピア接続サーバ２０に要求されているが、住民によるピアの作成の要求が先に発生してもよい。

（６）前述の実施の形態の場合には、サービスの利用者である住民が「ビデオ通話」ボタン５３３（図１０参照）をクリックすることで、ピア接続サーバ２０（図１参照）に対してピアの作成が要求されているが（図８の３－ａ）、例えば画面共有のボタンのクリック、特定のページを開く操作、担当者の支援を要求するボタンその他の操作に起因して、ピアの作成の要求がピア接続サーバ２０に要求されてもよい。

１…クラウド窓口システム、１０…インターネット、２０…ピア接続サーバ、３０…クラウド窓口仲介サーバ、３２Ｂ…担当者テーブル、４０…ネットワークシステム、４０Ａ、５０…端末、３１１…担当者テーブル管理部、３１２…非通話中ピアＩＤ通知部、４１１…ピアＩＤ登録部、４１２…共有画面座標変換部、５１１…ピアリスト要求部、５１２…待機者情報要求部、５１３…通話相手選択画面表示部、５１４…選択ピアＩＤ設定部、５１５…共有画面選択受付部、５１６…担当者操作反映部

Claims (18)

1. 制御部を有し、
   前記制御部は、ウェブサイトを通じて提供されるサービスの利用者が操作する利用者端末のブラウザ画面に、画面共有による支援が可能な状態にある担当者の候補を表示させるとともに、当該担当者の候補に対応するピアＩＤを送付する、
   サーバ装置。
2. 前記制御部は、前記利用者端末から支援が可能な状態にある担当者の候補との画面共有が要求された場合に、前記担当者の候補を当該利用者端末に通知する、
   請求項１に記載のサーバ装置。
3. 前記制御部は、支援が可能な状態にある担当者の候補がいない場合、その旨を前記ブラウザ画面に表示させる、
   請求項１又は２に記載のサーバ装置。
4. 前記制御部は、画面共有による支援が可能な状態の担当者及び画面共有による支援中の担当者のピアＩＤと、各担当者を識別する情報と紐付けて管理する、
   請求項１又は２に記載のサーバ装置。
5. 前記制御部は、画面共有による支援に備えて待機している担当者のみを、画面共有による支援が可能な状態の前記担当者の候補として前記利用者端末に通知する、
   請求項４に記載のサーバ装置。
6. ウェブサイトを通じて提供されるサービスの利用者が操作する利用者端末であって、
   前記ウェブサイト内で画面共有による支援を要求する操作を検知した場合、画面共有による前記利用者の支援を仲介するサーバ装置に対し、画面共有による支援が可能な状態にある担当者の候補の情報を要求し、当該サーバ装置から、画面共有による支援が可能な状態にある前記担当者の情報と当該担当者のピアＩＤを取得する制御部
   を有する、利用者端末。
7. 前記制御部は、ブラウザ画面上に、前記担当者と共有したい画面を選択するためのウィンドウを表示する、
   請求項６に記載の利用者端末。
8. シングル・ページ・アプリケーションに対応するブラウザを使用する、
   請求項７に記載の利用者端末。
9. 前記制御部は、共用中の画面に対する前記担当者による入力を、当該画面が表示されるブラウザ画面の表示に反映させる、
   請求項６～８のうちいずれか１項に記載の利用者端末。
10. 前記制御部は、前記担当者による前記入力を、前記共用中の画面を基準とする座標とともに受信し、前記ブラウザ画面の表示に反映する、
    請求項９に記載の利用者端末。
11. 前記制御部は、前記共用中の画面内で前記担当者が指定した位置にポインタを予め定めた時間表示する、
    請求項９又は１０に記載の利用者端末。
12. 前記制御部は、画面共有を開始した担当者に紐付けられているピアＩＤを前記サーバ装置に通知する、
    請求項６～１１のうちいずれか１項に記載の利用者端末。
13. ウェブサイトを通じて提供されるサービスの利用者を支援する担当者が操作する担当者端末であって、
    支援中の利用者と共用中の画面に対する担当者の入力の位置を、当該共用中の画面について規定される相対的な座標に変換し、利用者側に通知する制御部
    を有する、担当者端末。
14. 前記制御部は、前記共用中の画面の対角線方向に位置する２つの頂点を基準点に定め、当該画面上の任意の位置を２つの基準点に対する相対座標として表現する、
    請求項１３に記載の担当者端末。
15. ウェブサイトを通じて提供されるサービスの利用者が操作する利用者端末と、
    前記利用者を支援する担当者が操作する担当者端末と、
    前記担当者による前記利用者の支援を仲介するサーバ装置と
    を有し、
    前記サーバ装置は、前記利用者端末のブラウザ画面に、画面共有による支援が可能な状態にある担当者の候補を表示させるとともに、当該担当者の候補に対応するピアＩＤを送付し、
    前記利用者端末は、前記担当者のピアＩＤと自端末のピアＩＤを用い、前記担当者端末と直接通信する、
    ことを特徴とする情報処理システム。
16. ウェブサイトを通じて提供されるサービスの利用者と、当該利用者を支援する担当者との画面共有を仲介するサーバ装置が実行する情報処理方法であって、
    利用者端末のブラウザ画面に、画面共有による支援が可能な状態にある担当者の候補を表示させる処理と、
    前記担当者の候補に対応するピアＩＤを送付する処理と、
    を有する情報処理方法。
17. ウェブサイトを通じて提供されるサービスの利用者と、当該利用者を支援する担当者との画面共有を仲介するサーバ装置を構成するコンピュータに、
    利用者端末のブラウザ画面に、画面共有による支援が可能な状態にある担当者の候補を表示させる機能と、
    前記担当者の候補に対応するピアＩＤを送付する機能と、
    を実現させるためのプログラム。
18. ウェブサイトを通じて提供されるサービスの利用者が操作する利用者端末を構成するコンピュータに、
    前記ウェブサイト内で画面共有による支援を要求する操作を検知した場合、画面共有による前記利用者の支援を仲介するサーバ装置に対し、画面共有による支援が可能な状態にある担当者の候補の情報を要求する機能と、
    前記サーバ装置から、画面共有による支援が可能な状態にある前記担当者の情報と当該担当者のピアＩＤを取得する機能と、
    を実現させるためのプログラム。

Images