(57)【要約】【課題】電話網やインターネットの通信網に輻輳が生じることを防止し、ユーザ情報を速やかに確認可能にする。【解決手段】第１サービスシステム１０において、ユーザ端末からユーザの安否情報を含む音声データを受信すると、当該音声データを当該ユーザの識別子に対応させて音声データ記憶装置に記憶し、第１サービスシステム１０において、音声データ記憶装置に記憶される音声データをテキストデータに変換し、変換したテキストデータを、当該音声データを生成したユーザの属性に関するテキストデータと関連付けてテキストデータ記憶装置に記憶し、第２サービスシステム２０において、ユーザの属性を含み、当該ユーザのテキストデータの提供を要求するリクエストを送信し、第１サービスシステム１０において、第２サービスシステムからリクエストを受信すると、当該リクエストで要求されたテキストデータを送信する。【選択図】図１
2014154993.tif 000002
【特許請求の範囲】
【請求項１】
ユーザ端末から入力する音声データを記憶し、他のユーザ端末に提供する第１サービスシステムと、ユーザ端末から入力するテキストデータを記憶し、他のユーザ端末に提供する第２サービスシステムとが接続されるユーザデータ提供システムで実行されるユーザデータ提供方法であって、
前記第１サービスシステムにおいて、ユーザ端末からユーザの安否情報を含む音声データを受信すると、当該音声データを当該ユーザの識別子に対応させて音声データ記憶装置に記憶するステップと、
前記第１サービスシステムにおいて、前記音声データ記憶装置に記憶される音声データをテキストデータに変換し、変換したテキストデータを、当該音声データを生成したユーザの属性に関するテキストデータと関連付けてテキストデータ記憶装置に記憶するステップと、
前記第２サービスシステムにおいて、ユーザの属性を含み、当該ユーザのテキストデータの提供を要求するリクエストを送信するステップと、
前記第１サービスシステムにおいて、前記第２サービスシステムからリクエストを受信すると、当該リクエストで要求されたテキストデータを送信するステップと、
を実行することを特徴とするユーザデータ提供方法。
【請求項２】
ユーザ端末からユーザの安否情報を含む音声データを受信すると、当該音声データを当該ユーザの識別子に対応させて音声データ記憶装置に記憶する受付手段と、
ユーザ端末から識別子を含む音声データの提供を要求するリクエストを受信すると、当該識別子に対応する音声データを、音声データ記憶装置から読み出して当該ユーザ端末に送信する第１提供手段と、
前記音声データ記憶装置に記憶される音声データをテキストデータに変換し、変換したテキストデータを、当該音声データを生成したユーザの属性に関するテキストデータと関連付けてテキストデータ記憶装置に記憶する変換手段と、
他装置からユーザの属性を含むテキストデータの提供を要求するリクエストを受信すると、要求されたテキストデータを当該他装置に送信する第２提供手段と、
を備えることを特徴とするサービスシステム。
【請求項３】
前記テキストデータが含むデータの各項目には、データの公開の可否を特定するフラグがそれぞれ関連付けられ、
前記第２提供手段は、リクエストに応じてデータを送信する際、前記テキストデータにおいて、フラグにより公開可能とされている項目のデータのみを送信する
ことを特徴とする請求項２記載のサービスシステム。
【請求項４】
テキストデータの提供を要求するリクエストを受信すると、リクエストに含まれる特定の項目の内容が認証用データ記憶装置に記憶される認証用データに含まれているか否かを判定する判定手段を備え、
前記第２提供手段は、前記判定手段の判定結果に応じて要求されたデータを送信する
ことを特徴とする請求項２又は３に記載のサービスシステム。
【請求項５】
認証用データは、データの提供を要求する他者の識別子、予め定められるパスワード又は、ユーザの属性の一部のいずれかである
ことを特徴とする請求項４に記載のサービスシステム。
【請求項６】
認証用データを新たに入力すると、当該認証用データを前記認証用データ記憶装置に登録する登録手段を備える
ことを特徴とする請求項４又は５に記載のサービスシステム。
【請求項７】
前記テキストデータ記憶装置に記憶されるテキストデータの少なくとも一部は暗号化されている
ことを特徴とする請求項２乃至６のいずれかに記載のサービスシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ユーザが登録したデータを他者からのリクエストに応じて提供するユーザデータ提供方法及びサービスシステムに関する。
【背景技術】
【０００２】
電話網の輻輳は、電話がつながりにくい状態であり、これは、交換機に一定時間内に処理できる能力を超える電話が集中することにより発生する。例えば、災害発生時には、安否確認等の電話が増加し、輻輳が発生することがある。輻輳により電話がつながらずに安否確認がとれない場合、相手につながるまで電話が繰り返しかけられ、輻輳が増大することもある。また、電話に限られずインターネットにおける通信でも、通信回線の許容量が超えるデータが送信されると、輻輳が発生する。
【０００３】
災害発生時に使用可能な安否確認の方法としては、相手に直接電話する方法の他、災害用伝言ダイヤルや災害用伝言板等がある。災害伝言用ダイヤルを利用する場合、災害時等にユーザが、災害伝言用ダイヤル特定の電話番号に電話をかけて自身が加入する電話番号に関連付けて音声データのメッセージを登録する。また、ユーザの安否を確認する他のユーザは、特定の電話番号に電話をかけてユーザの電話番号をキーとしてメッセージを聞くことができる。
【０００４】
また、災害用伝言板は、インターネットを利用するサービスであり、災害時にユーザが、災害用伝言板用の特定のサーバにアクセスして自身が加入する電話番号等に関連付けて文字データ等のメッセージを登録する。また、ユーザの安否を確認する他のユーザは、特定のサーバにアクセスしてユーザの電話番号等をキーとしてメッセージを閲覧することができる。
【０００５】
一般的に異なる形式でデータを収集するシステム同士でデータを共有することは困難である（例えば、特許文献１参照）。災害用伝言ダイヤル及び災害用伝言板は両システムともに安否に関するデータを有しているものの、災害用伝言ダイヤルのシステムは音声のデータを使用しており、災害用伝言板のシステムはテキスト形式のデータを使用している。したがって、各システムでデータは共有されていない。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開平８−２５６１７６号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
上述したように、従来は複数のシステムで互いに必要なデータを有していても、それぞれ独立していた。そのため、ユーザはそれぞれのシステムに別々にアクセスする必要があり、災害発生時には各システムにユーザからの電話やリクエスト送信がされ、電話網の輻輳や通信回線の輻輳が生じやすくなることがあった。
【０００８】
上記課題に鑑み、本発明は、電話網に輻輳が生じやすい状況の場合であっても、電話網やインターネットの通信網に輻輳が生じることを防止し、ユーザ情報を速やかに確認可能にすることを目的とする。
【課題を解決するための手段】
【０００９】
上記目的を達成するために、本発明に係るユーザデータ提供方法は、ユーザ端末から入力する音声データを記憶し、他のユーザ端末に提供する第１サービスシステムと、ユーザ端末から入力するテキストデータを記憶し、他のユーザ端末に提供する第２サービスシステムとが接続されるユーザデータ提供システムで実行される。このユーザデータ提供方法は、前記第１サービスシステムにおいて、ユーザ端末からユーザの安否情報を含む音声データを受信すると、当該音声データを当該ユーザの識別子に対応させて音声データ記憶装置に記憶するステップと、前記第１サービスシステムにおいて、前記音声データ記憶装置に記憶される音声データをテキストデータに変換し、変換したテキストデータを、当該音声データを生成したユーザの属性に関するテキストデータと関連付けてテキストデータ記憶装置に記憶するステップと、前記第２サービスシステムにおいて、ユーザの属性を含み、当該ユーザのテキストデータの提供を要求するリクエストを送信するステップと、前記第１サービスシステムにおいて、前記第２サービスシステムからリクエストを受信すると、当該リクエストで要求されたテキストデータを送信するステップとを有する。
【発明の効果】
【００１０】
本発明によれば、電話網に輻輳が生じやすい状況の場合であっても、電話網やインターネットの通信網に輻輳が生じることを防止し、ユーザ情報を速やかに確認可能にすることができる。
【図面の簡単な説明】
【００１１】
【図１】図１は、実施形態に係るユーザデータ提供システムを説明する概略図である。
【図２】図２は、第１サービスシステムの構成を表すブロック図である。
【図３】図３は、第１サービスシステムで利用する契約者データの構成を説明する概略図である。
【図４】図４は、第１サービスシステムで利用する受付データの構成を説明する概略図である。
【図５】図５は、第１サービスシステムで利用するテキストデータの構成を説明する概略図である。
【図６】図６は、テキストデータの一例である。
【図７】図７は、第２サービスシステムの構成を表すブロック図である。
【図８】図８は、音声データを受信した第１サービスシステムの処理を説明するフローチャートである。
【図９】図９は、認証データを受信した第１サービスシステムの処理を説明するフローチャートである。
【図１０】図１０は、端末からリクエストを受信した第１サービスシステムの処理を説明するフローチャートである。
【図１１】図１１は、第２サービスシステムからリクエストを受信した第１サービスシステムの処理を説明するフローチャートである。
【発明を実施するための形態】
【００１２】
以下に、図面を用いて本発明に係るユーザデータ提供方法及びユーザデータ提供方法で使用されるサービスシステムについて説明する。以下の説明において、同一の構成及び同一の処理には同一の符号を付して説明を省略する。
【００１３】
図１に示すように、本発明に係るユーザデータ提供方法を実現するユーザデータ提供システム１は、「災害用伝言ダイヤルシステム」である第１サービスシステム１０と、「災害用伝言掲示板システム」又は「類似の災害時に利用可能な安否確認システム」である第２サービスシステム２０とを有している。ユーザデータ提供システム１においては、第１サービスシステム１０と第２サービスシステム２０とはネットワーク３０を介して接続されている。このネットワーク３０は、パケット通信によりサービスシステム１０，２０間でデータを送受信することのできる通信ネットワークである。
【００１４】
第１サービスシステム１０は、電話網３１を介して、端末４０ａ，４０ｂと接続されている。この端末４０ａ，４０ｂは、有線の電話機や携帯電話機等である。または、音声入出力装置を有し、電話網３１を介して音声の送受信が可能なパーソナルコンピュータ等の情報処理装置であっても良い。なお、ここで、電話網３１は、有線であっても無線であっても良い。または、電話網３１は、ＩＰ電話網等のインターネット回線を利用する電話網であってもよい。以下では、端末４０ａを用いた例で説明するが、端末４０ａを端末４０ｂに置き換えても同様である。なお、図１において、第１サービスシステム１０に接続される電話機の台数は２台であるが、接続される電話機の台数は限定されない。
【００１５】
また、第１サービスシステム１０は、ネットワーク３２を介して端末４０ｃ，４０ｄと接続されている。このネットワーク３２は、パケット通信を実現することのできるＮＧＮ回線やインターネット回線等の通信ネットワークである。端末４０ｃ，４０ｄは、パーソナルコンピュータ、携帯電話機、タブレット端末、スマートフォン等の情報処理装置である。以下では、端末４０ｃを用いた例で説明するが、端末４０ｃを端末４０ｄに置き換えても同様である。また、図１において、第１サービスシステム１０に接続される情報処理装置の台数は２台であるが、接続される情報処理装置の台数は限定されない。
【００１６】
第２サービスシステム２０は、ネットワーク３３を介して情報処理装置である端末５０ａ，５０ｂと接続されている。このネットワーク３３は、パケット通信により、第２サービスシステム２０と端末５０ａ間でデータを送受信することのできる通信ネットワークである。以下では、端末５０ａを用いた例で説明するが、端末５０ａを端末５０ｂに置き換えても同様である。また、図１において、第２サービスシステム２０に接続される情報処理装置の台数は２台であるが、接続される情報処理装置の台数は限定されない。
【００１７】
なお、図１では、端末４０ｃが接続されるネットワーク３２と端末５０ａが接続されるネットワーク３３は別であるが、同一であってもよい。また、ネットワーク３２及び３３の他、ネットワーク３０も同一であってもよい。その他、サービスシステム１０，２０間で送受信されるデータのセキュアを重要視する場合、ネットワーク３０は、専用の回線を利用してもよい。さらに、図１では、１台の第１サービスシステム１０と１台の第２サービスシステム２０とが接続されるユーザデータ提供システム１の一例を説明しているが、接続される第１サービスシステム１０及び第２サービスシステム２０の数は限定されない。
【００１８】
〈第１サービスシステム〉
図２に示すように、第１サービスシステム１０は、音声データを受け付ける受付手段１１ａ、音声データをテキストデータに変換する変換手段１１ｂ、端末４０ａに音声データを提供する第１提供手段１１ｃ、認証用のデータを登録する登録手段１１ｄ、データ提供の可否を判定する判定手段１１ｅ及び第２サービスシステム２０にデータを提供する第２提供手段１１ｆを有している。
【００１９】
例えば、第１サービスシステム１０は、ＣＰＵ１１や記憶装置１２を備えるサーバ等の情報処理装置であって、記憶装置１２に記憶されるサービスプログラムＰ１の実行により、ＣＰＵ１１が受付手段１１ａ、変換手段１１ｂ、第１提供手段１１ｃ、登録手段１１ｄ、判定手段１１ｅ及び第２提供手段１１ｆの処理を実行する。また、記憶装置１２は、サービスプログラムＰ１の他、第１サービスシステム１０が提供する電話サービスに契約するユーザに関する契約者データＤ１、受け付けた音声データを含む受付データＤ２、音声データから変換されたテキスト形式のテキストデータＤ３及びアクセスの可否の判定に利用する認証用データＤ４を記憶している。
【００２０】
契約者データＤ１は、第１サービスシステム１０が提供する電話サービスに契約するユーザの「氏名」やユーザに割り当てられた「電話番号」等を含むデータである。この契約者データＤ１では、例えば、図３に示すように、ユーザに定められた「契約者ＩＤ」をキーとして「氏名」や「電話番号」を関連付けている。なお、記憶装置１２では、複数のユーザの契約者データＤ１を記憶することができる。
【００２１】
受付手段１１ａは、端末４０ａから電話網３１を介して音声データを入力すると、図４に一例を示すように、入力した音声データと、音声データの入力の際に得られたメタデータとを関連付けて受付データＤ２として記憶装置１２に記憶させる。
【００２２】
具体的には、音声データは、ユーザに関するデータであって、ユーザの「氏名」、「年齢」、「住所」、「メッセージ」等を含むデータである。ここで、「住所」については、番地までの全てを含める必要はなく、都道府県や市区町村で特定してもよい。また、「メッセージ」の内容については、ユーザが自由に入力することが可能であって、例えば、安否の詳細や移動先に関する情報である。
【００２３】
例えば、受付手段１１ａは、音声データ受付の際、音声アナウンスによりユーザを誘導し、ユーザはこの誘導に従って音声データを入力する。これにより、受付手段１１ａは、「氏名」、「年齢」、「住所」又は「メッセージ」等の項目の内容を区別して記憶（録音）することができる。その他、受付手段１１ａで音声認識の処理が可能な場合、受付手段１１ａは、音声認識により、入力した音声データから、各項目の内容を区別して受付データＤ２を生成してもよい。
【００２４】
また、例えば、メタデータは、音声データを受け付けた「受付時刻」やユーザの識別子としてユーザに入力されたユーザの「電話番号」等を含むデータである。すなわち、第１サービスシステム１０では、各処理においてユーザの「電話番号」をキーとして使用する。
【００２５】
その他、メタデータは、ユーザの位置情報を含んでいてもよい。ユーザが音声データの入力に使用した端末が固定電話（有線電話）である場合、電話番号が含む市外局番からユーザが存在する「位置情報」が特定される。また、ユーザが音声データの入力に使用した端末が携帯電話機である場合、携帯電話機が接続される基地局からユーザが存在する「位置情報」が特定される。したがって、メタデータは、このように特定される「位置情報」を含むことができる。
【００２６】
なお、記憶装置１２では、複数の受付データＤ２を記憶することができる。すなわち、記憶装置１２では、複数のユーザの受付データＤ２を記憶することができる。
【００２７】
変換手段１１ｂは、受付データＤ２に含まれる音声データの各項目の内容をテキスト形式に変換する。また、変換手段１１ｂは、変換したデータとユーザの属性とからテキストデータを生成する。具体的には、変換手段１１ｂは、「変換した各項目の内容」、「受付データＤ２のメタデータに含まれる必要な項目の内容」及び「契約者データＤ１に含まれる項目」の内容等を含むデータをテキストデータＤ３として記憶装置１２に記憶させる。このとき、変換手段１１ｂは、契約者データＤ１及び受付データＤ２に含まれておらず、端末４０ａから入力された内容をテキストデータＤ３に含めることもできる。ここで、変換手段１１ｂは、識別子である「電話番号」をキーとして受付データＤ２に対応する契約者データＤ１を選択することができる。
【００２８】
図５はテキストデータＤ３が含むデータの一例を説明する概念図である。例えば、「氏名（漢字）」及び「電子メールアドレス」は契約者データＤ１から抽出される。また、「氏名（カナ）」、「年齢」、「住所」、「メッセージ」は、受付データＤ２の音声データから抽出されて変換される。さらに、「電話番号」、「受付時刻」は、受付データＤ２のメタデータから抽出される。
【００２９】
その他、テキストデータＤ３の「暗号化された電話番号」は、例えば、受付データＤ２のメタデータに含まれる「電話番号」から変換手段１１ｂによって暗号化される。個人情報の一つでありユーザと１対１で対応する「電話番号」を広い範囲に公開することが好ましくない場合、この「暗号化された電話番号」を利用することで、個人情報の流出を防ぐことが可能となる。すなわち、個人情報である「電話番号」が流出した場合、これが悪用される恐れもあるためである。暗号化の方式がユーザデータ提供システム１内で統一されていれば、「暗号化された電話番号」をキーとしてユーザの特定が可能となる。
【００３０】
電話番号を暗号化する方式としては、様々な方式が考えられるが、例えば、「電話番号のハッシュ値」を「暗号化された電話番号」として利用することができる。ハッシュ化は、「文字列を別の文字列へ一意に変換する方式で、逆方向への変換が容易でない手法」である。したがって、例えばこのような「一意に変換可能かつ逆方向への変換が容易でない方法」を用いて電話番号を変換（暗号化）する。具体的には、ＳＨＡ−１、ＳＨＡ−２といった暗号的ハッシュ関数によって暗号化された電話番号として利用することができる。これにより、元の電話番号を秘匿したい場合、逆変換の困難性であるため、他者に電話番号を知られることなく、この暗号化された電話番号は、電話番号を元に生成された文字列であるため、一意に個人を指定できる。
【００３１】
より具体的には、名前「石田」及び電話番号「XXXXXXXXXX」のうち電話番号をハッシュ化（暗号化）すると、名前「石田」、電話番号「badjoifafdaxcp」を得ることができる。一方、名前「石田」及び電話番号「YYYYYYYYYY」のうちの電話番号をハッシュ化すると名前「石田」及び電話番号「bfsriklnfsbmq」を得ることができる。したがって、ハッシュ化した電話番号を使用する場合、電話番号「XXXXXXXXXX」の石田と電話番号「YYYYYYYYYY」の石田を区別することができる。
【００３２】
なお、ここでは、ユーザの属性（個人情報）のうち、電話番号を暗号化する例で説明しているが、暗号化の対象は、電話番号に限られない。例えば、情報の流出が好ましくない場合、電子メールアドレス等、他の属性の内容を暗号化してもよい。
【００３３】
また、「削除時刻」は、端末４０ａや端末４０ｃから入力される時刻であったり、「受付時刻」から所定時間経過後（例えば、１ヶ月後）の時刻である。この場合の「所定時間」も端末４０ａや端末４０ｃから入力された値（時間）を使用することもできる。第１サービスシステム１０は、例えば更新手段（図示せず）を備え、テキストデータＤ３が、「削除時刻」を含んでいる場合、削除時刻の経過後に、更新手段によってこのテキストデータＤ３及び対応する受付データＤ２を記憶装置１２から削除する。
【００３４】
さらに、図５に含む情報の他、「他のＷＥＢサービスで使用する識別子（ＩＤ）」や「血液型」等を含んでいてもよい。これらは、契約者データＤ１や受付データＤ２から抽出する他、端末４０ａから電話網３１を介して入力したり、端末４０ｃからネットワーク３２を介して入力し、テキストデータＤ３に含めるようにしてもよい。
【００３５】
また、テキストデータＤ３の各項目には、公開の可否を表す「フラグ」を関連付けることができる。また、公開の範囲を区別して複数のフラグを関連付けていてもよい。図５に示す例では、「全体に公開可能な項目に関するフラグ」と「認証されたユーザにのみ公開可能な項目に関するフラグ」とを含んでいる。例えば、図５に示す例では、「氏名（漢字）」は、「全体」には公開されず、「認証されたユーザ」にのみ公開される。一方、「氏名（カナ）」は、「全体」及び「認証されたユーザ」に公開される。なお、図５では、１人分のユーザに関する内容のみを示しているが、テキストデータＤ３では、複数のユーザのデータを有することができる。
【００３６】
例えば、各フラグの値は、端末４０ａから電話網３１を介して受付手段１１ａが音声のデータで入力してテキストデータＤ３含めることができる。または、端末４０ｃからネットワーク３２を介してフラグ設定手段（図示せず）が入力し、テキストデータＤ３に含めてもよい。
【００３７】
テキストデータＤ３は、例えば、図６のように図５を用いて上述した項目の内容をテキスト形式で含むデータである。テキスト形式の種別は問わず、テキストデータＤ３は、例えば、図６に示すようなＸＭＬを使用してもよい。テキストデータＤ３の形式は、ＸＭＬ（Extensible Markup Language）の他、構造化されていれば、ＪＳＯＮ（JavaScript Object Notation）やＹＡＭＬ（YAML Ain’t Markup Language）等他の形式でもよい。図６（ａ）の<privacy_flag>はテキストデータの各項目に対応するフラグの値を示すものであり、<privacy_flag>のＡに続く値が各項目と対応し、これらが「全体に公開可能であるか否か」を表す。また、<privacy_flag>のＢに続く値が各項目と対応し、これらが「認証されたユーザにのみ公開可能であるか否か」を表す。
【００３８】
その他、図５及び図６では省略されているが、<privacy_flag>には、さらに文字「Ｃ」と文字Ｃに続いて「各項目と対応する値」が含まれていてもよい。具体的には、認証の方法に複数の方法が存在するとき、認証方法に応じて公開の範囲を制限する必要がある。したがって、「認証方法１で認証された場合」はＢに続く値を利用して公開し、「認証方法２で認証された場合」はＣに続く値を利用して公開するように規定することができる。
【００３９】
例えば、「認証方法１」とは、「電話番号を利用して認証された場合」であり、「認証方法２」とは、「氏名及び住所（都道府県又は市区町村）を使用して認証された場合」である。電話番号はユーザをほぼ１対１で特定するものであるが、氏名については同姓同名の場合もあるため、ユーザを１対１とで特定するものとはいい難い。したがって、「認証方法２」で認証された場合、「認証方法１」で認証された場合よりも得られる情報（公開される情報）の数が少なく規定する。例えば、「認証方法１」で認証された場合、「名前（漢字）、名前（カナ）、年齢、住所（都道府県）、住所（市区町村）、電話番号、メッセージ」の項目の情報が公開され、「認証方法２」で認証された場合、「名前（カナ）、年齢、住所（都道府県）、暗号化された電話番号」の項目の情報が公開されるように規定することができる。なお、認証の方法についてもこれに限られず、他に後述する「ホワイトリストを利用した認証」等も考えられるし、テキストデータＤ３の<privacy_flag>で規定する認証の方法の数についても限定されない。
【００４０】
第１提供手段１１ｃは、端末４０ａから電話網３１を介して音声データのメッセージの提供を要求するリクエストを受信すると、記憶装置１２から該当する音声データを抽出する。また、第１提供手段１１ｃは、電話網３１を介して端末４０ａに抽出したデータを送信して提供する。例えば、第１提供手段１１ｃは、識別子である「電話番号」を含むリクエストを受信すると、この「電話番号」と関連付ける受付データＤ２を記憶装置１２から検索して抽出する。
【００４１】
登録手段１１ｄは、端末４０ａや端末４０ｃから認証用のデータを入力すると、入力したデータを、認証用データＤ４として記憶装置１２に記憶させる。また、登録手段１１ｄは、端末４０ａや端末４０ｃからの操作にしたがって、記憶装置１２に記憶されている認証用データを変更することもできる。
【００４２】
例えば、登録手段１１ｄは、電話網３１を介して端末４０ａから認証用のデータを入力する。また例えば、登録手段１１ｄは、ネットワーク３２を介して端末４０ｃから認証用のデータを入力する。認証用のデータは、例えば、データを提供可能な他者の識別子（例えば、電話番号や電子メールアドレス等）を含むホワイトリストである。「ホワイトリスト」は、あらかじめ決められた特定の者以外には公開（提供）しないよう、公開の対象である他者の識別子を含むデータである。または、認証用のデータは、データの提供を要求する他者に入力させるパスワードであってもよい。
【００４３】
その他、認証用のデータは、契約者データＤ１やテキストデータＤ３に含まれるユーザの属性（個人情報）の一部であってもよい。具体的には、予めユーザの属性のうち、いずれが認証用のデータであるか否かが定められており、認証用に定められる属性の全てを把握している他者に対してこのユーザのデータの提供を許可するようにしてもよい。例えば、ユーザの属性である「氏名」、「電話番号」、「電子メールアドレス」及び「住所」を認証用データとすることができる。
【００４４】
認証用データＤ４は、上述したような「ホワイトリスト」、「パスワード」又は「ユーザの属性（個人情報）」等をユーザの識別子である「電話番号」に関連付けるデータである。なお、記憶装置１２では、複数のユーザの認証用データＤ４を記憶することができる。
【００４５】
判定手段１１ｅは、ネットワーク３３を介して第２サービスシステム２０からテキストデータの提供を要求するリクエストを受信すると、記憶装置１２から該当するテキストデータＤ３を検索する。このリクエストには、少なくともデータの提供を要求する他者の識別子と、データの提供が要求されているユーザの識別子が含まれている。
【００４６】
例えば、識別子は、１対１でユーザを特定する「電話番号」や「電子メールアドレス」である。また、リクエストには、データの提供のための認証用のデータを含むことができる。この場合「氏名」及び「住所」をユーザの識別子とすることができる。
【００４７】
また例えば、複数のユーザに関するデータを検索する場合、リクエストには、複数のユーザを特定する識別子を含んでいてもよい。具体的には、公的機関が安否確認を行う目的で「住所」を識別子とするリクエストを送信したとき、特定の地域の全ての住民についてのデータを検索することもできる。さらに、学校や企業が生徒や社員等複数人の安否確認を行う目的で複数の「電話番号」を含むリクエストを送信したとき、これら複数人のデータを検索することもできる。
【００４８】
テキストデータＤ３を検索すると、判定手段１１ｅは、リクエストが認証用データＤ４で許可されるか否か判定する。このとき、判定手段１１ｅは、データの提供が要求されているユーザの認証用データＤ４を使用する。
【００４９】
例えば、認証用データＤ４が、データを提供可能なユーザ（他者）の識別子を含む「ホワイトリスト」である場合、判定手段１１ｅは、他者の識別子がリクエストに含まれるか否か判定する。また、認証用データＤ４が、「パスワード」である場合、判定手段１１ｅは、認証用データＤ４に含まれるユーザのパスワードがリクエストに含まれるか否か判定する。さらに、認証用データＤ４が「ユーザの属性」である場合、判定手段１１ｅは、認証用データＤ４に含まれる属性が、リクエストに含まれるか否か判定する。
【００５０】
第２提供手段１１ｆは、判定手段１１ｅの判定結果に応じて、該当するテキストデータＤ３から送信対象である項目の内容を含む送信用のテキストデータを生成する。すなわち、第２提供手段１１ｆは、<privacy_flag>に従って選択された項目のデータを含むテキストデータを生成する。また、第２提供手段１１ｆは、生成したテキストデータをネットワーク３０を介して第２サービスシステム２０に送信する。なお、判定手段１１ｅによって該当するテキストデータＤ３が検索されない場合、第２提供手段１１ｆは、リクエストで要求されたユーザのテキストデータＤ３は存在しない応答をネットワーク３０を介して第２サービスシステム２０に送信する。
【００５１】
第２提供手段１１ｆは、ＡＰＩ（アプリケーションプログラミングインタフェース）を利用することで、容易に実現が可能となる。これにより、データの送受信を利用した他のシステムとのデータの共有を実現することができる。また、第２提供手段１１ｆでは、悪意を持ってＡＰＩを通じたアクセスをする人を除外するため、時間当たりのリクエストの上限を設けるように設定していてもよい。
【００５２】
例えば、図６（ａ）に示すテキストデータＤ３が抽出され、判定手段１１ｅで認証されないユーザからのリクエストであると判定されたとする。この場合、図６（ｂ）に一例を示すように、全体に公開可能な「氏名（カナ）」、「年齢」、「暗号化された電話番号」、「住所」、「受付時刻」及び「削除時刻」のみを含むテキストデータが生成される。
【００５３】
なお、第１サービスシステム１０は、１台の装置で実現される必要はなく、複数台の装置で実現されてもよい。例えば、複数の処理手段１１ａ〜１１ｆのうちいずれかが外部の装置で実現されたり、複数のデータＤ１〜Ｄ４のうちいずれかが外部の装置で記憶されていてもよい。
【００５４】
〈第２サービスシステム〉
図７に示すように、第２サービスシステム２０は、受付手段２１ａ、提供手段２１ｂ及び取得手段２１ｃを有している。例えば、第２サービスシステム２０は、ＣＰＵ２１や記憶装置２２を備えるサーバ等の情報処理装置であって、記憶装置２２に記憶されるサービスプログラムＰ２の実行により、ＣＰＵ２１が受付手段２１ａ、提供手段２１ｂ及び取得手段２１ｃの処理を実行する。また、記憶装置２２は、サービスプログラムＰ２の他、受け付けたデータに関する受付データＤ６を記憶している。
【００５５】
受付手段２１ａは、ネットワーク３３を介して端末５０ａからユーザの属性や安否情報を含むテキストデータを入力すると、入力したテキストデータと、テキストの入力の際に得られたメタデータとを関連付けて受付データＤ６として記憶装置２２に記憶させる。
【００５６】
受付データＤ６は、ユーザの識別子にユーザの属性や安否情報が関連付けられるデータである。ユーザの識別子とは、例えば、ユーザの名前、電話番号又は電子メールアドレス等である。
【００５７】
提供手段２１ｂは、ネットワーク３３を介して端末５０ａからテキストデータの提供を要求するリクエストを受信すると、記憶装置２２から該当する受付データＤ６を抽出し、ネットワーク３３を介して端末５０ａにデータを提供する。
【００５８】
提供手段２１ｂは、該当するデータが受付データＤ２から抽出されないとき、取得手段２１ｃに受信したリクエストを出力する。また、提供手段２１ｂは、リクエストに応じて取得手段２１ｃから入力されたテキストデータを端末５０ａに提供する。
【００５９】
取得手段２１ｃは、リクエストを入力すると、リクエストを第１サービスシステム１０に送信する。また、送信したリクエストに応じてテキストデータを受信すると、受信したテキストデータを提供手段２１ｂに出力する。
【００６０】
仮に、第２サービスネットワーク２０が複数の第１サービスネットワークと接続されている場合、取得手段２１ｃは、接続される全ての第１サービスネットワークに同時にリクエストを送信してもよいし、予め定められる順序でリクエストを送信してもよい。予め定められる順序で送信する際には、１の装置に送信したリクエストに対して、ユーザのテキストデータが存在しないとの応答を受信すると、他の装置に同様にリクエストを送信する処理を繰り返す。
【００６１】
次に、第１サービスシステム１０における種々の処理について説明する。
【００６２】
〈音声データ追加処理〉
まず、図８のフローチャートを用いて端末４０ａから音声データを受信し、新たな音声データを記憶装置１２に記憶する処理について説明する。
【００６３】
受付手段１１ａは、端末４０ａから電話網３１を介して送信された音声データを入力する（Ｓ０１）。ここで、音声データには、ユーザの「氏名」、「年齢」、「住所」又は「メッセージ」等の項目に関する音声が、項目毎に区別されて含まれている。
【００６４】
受付手段１１ａは、入力された音声データ及び音声データに関するメタデータをユーザの識別子である電話番号とともに受付データＤ２として記憶装置１２に記憶させる（Ｓ０２）。
【００６５】
また、変換手段１１ｂは、受付データＤ２の音声データをテキスト形式に変換する（Ｓ０３）。ここで、変換手段１１ｂが受付データＤ２の音声データをテキスト形式に変換するタイミングは、定期的なタイミング（例えば、５分毎のタイミング）であったり、新たな受付データＤ２が記憶装置１２に記憶されたタイミングである。例えば、定期的なタイミングで変換処理する場合、変換手段１１ｂは、前回音声データをテキスト形式に変換後、新たに記憶装置１２に記憶された全ての受付データＤ２をテキスト形式に変換する。一方、新たな受付データＤ２が記憶装置１２に記憶されたタイミングで変換処理する場合、変換手段１１ｂは、記憶装置１２に新たに記憶された受付データＤ２のみをテキスト形式に変換する。
【００６６】
その後、変換手段１１ｂは、ステップＳ０３でテキスト形式に変換したデータとともに、関連するデータを関連付けてテキストデータＤ３を生成し、記憶装置１２に記憶させる（Ｓ０４）。
【００６７】
〈認証用データ登録処理〉
図９のフローチャートを用いて端末４０ａ，４０ｃから認証用のデータを受信し、新たな認証用データＤ４を記憶装置１２に記憶する処理について説明する。
【００６８】
登録手段１１ｄは、端末４０ａから電話網３１を介して又は端末４０ｃからネットワーク３２を介して認証用のデータを入力する（Ｓ１１）。認証用のデータがユーザの「名前」及び「電話番号」等の個人情報等である場合、認証に使用するユーザの個人情報を入力する。
【００６９】
その後、登録手段１１ｄは、ステップＳ１１で入力したデータを認証用データD４として記憶装置１２に記憶させる（Ｓ１２）。
【００７０】
〈音声データ提供処理〉
図１０のフローチャートを用いてリクエストに応じて端末４０ａに音声データを提供する処理について説明する。
【００７１】
第１提供手段１１ｃは、端末４０ａから電話網３１を介して音声データの提供を要求するリクエストを入力する（Ｓ２１）。
【００７２】
続いて、第１提供手段１１ｃは、リクエストに含まれる「電話番号」を含む受付データＤ２を記憶装置１２から抽出する（Ｓ２２）。この受付データＤ２では、図４で上述したように、音声データを含んでいる。
【００７３】
ステップＳ２３で該当する受付データを抽出すると、抽出した受付データＤ２の音声データをリクエストで要求した端末４０ａに送信する（Ｓ２３）。
【００７４】
〈テキストデータ提供処理〉
図１１のフローチャートを用いてテキストのデータを第２サービスシステム２０に提供する処理について説明する。
【００７５】
判定手段１１ｅは、第２サービスシステム２０からネットワーク３０を介してテキストデータの提供を要求するリクエストを入力する（Ｓ３１）。
【００７６】
続いて、判定手段１１ｅは、リクエストに含まれる識別子を含むテキストデータＤ３を記憶装置１２から抽出する（Ｓ３２）。
【００７７】
また、判定手段１１ｅは、記憶装置１２から対象の認証用データＤ４が抽出されると、このリクエストを認証する（Ｓ３３）。
【００７８】
第２提供手段１１ｆは、ステップＳ３３の認証結果に応じて、ステップＳ３２で抽出されたテキストデータＤ３のうち、送信の対象（公開の対象）である項目のデータから送信用のテキストデータを生成する（Ｓ３４）。
【００７９】
その後、第２提供手段１１ｆは、ステップＳ３４で生成した送信用のテキストデータを第２サービスシステム２０に送信する（Ｓ３５）。
【００８０】
なお、このテキストデータを受信した第２サービスシステム２０では、取得手段２１ｃから提供手段２１ｂにテキストデータが出力される。その後、提供手段２１ｂは、ネットワーク３３を介して端末５０ａにテキストデータを送信する。
【００８１】
ここでは、第１サービスシステム１０は、音声のデータを入力し、音声のデータを端末４０ａに提供するとともに、テキスト形式のデータを第２サービスシステム２０に提供するものとして説明したが、その他の処理を実行可能であってもよい。例えば、図示を用いた説明は省略するが、第１サービスシステム１０でも、第２サービスシステム２０と同様にテキスト形式のデータを入力し、テキスト形式のデータを端末４０ｃに提供可能であってもよい。
【００８２】
上述したユーザデータ提供システム１では、第１サービスシステム１０が音声で受け付けたデータもテキスト形式のデータに変換して、他装置である第２サービスシステム２０に提供することができる。したがって、このようにしてユーザの安否情報を得ることができれば、各サービスシステムを利用する端末は複数回サービスシステムにアクセスを試みることがなく、他のサービスシステムが有する情報を１回のアクセスで取得することができる。したがって、電話網やネットワークの輻輳を防止することができる。
【００８３】
また、ユーザデータ提供システム１では、ＡＰＩを利用することで、他装置で利用可能な形式のデータとしてデータを提供することができる。したがって、データの提供（共有）を容易に実現することができる。
【００８４】
さらに、ユーザデータ提供システム１では、公開に好ましくないデータの内容は暗号化をして送信することができる。また、ユーザが公開に好ましくないと判断したデータの内容は自由に選択して非公開にすることも可能である。したがって、個人情報の流出や拡散を防止することができる。すなわち、迅速な安否確認と個人情報の流出や拡散とは表裏一体であり、両方を同時に成立させることは困難であったが、暗号化や公開の範囲を制限することで、個人情報の流出や拡散を防止することができる。
【００８５】
以上、実施形態を用いて本発明を詳細に説明したが、本発明は本明細書中に説明した実施形態に限定されるものではない。本発明の範囲は、特許請求の範囲の記載及び特許請求の範囲の記載と均等の範囲により決定されるものである。
【符号の説明】
【００８６】
１…ユーザデータ提供システム
Ｐ１，Ｐ２…サービスプログラム
１０…第１サービスシステム
１１…ＣＰＵ
１１ａ…受付手段
１１ｂ…変換手段
１１ｃ…第１提供手段
１１ｄ…登録手段
１１ｅ…判定手段
１１ｆ…第２提供手段
１２…記憶装置
D４…認証用データ
Ｄ１…契約者データ
Ｄ２…受付データ
Ｄ３…テキストデータ
Ｄ４…認証用データ
２０…第２サービスシステム
２１…ＣＰＵ
２１ａ…受付手段
２１ｂ…提供手段
２１ｃ…取得手段
２２…記憶装置
Ｄ６…受付データ
３０，３２，３３…ネットワーク
３１…電話網
４０ａ〜４０ｄ，５０ａ，５０ｂ…端末
【図１】
2014154993.tif 000003
【図２】
2014154993.tif 000004
【図３】
2014154993.tif 000005
【図４】
2014154993.tif 000006
【図５】
2014154993.tif 000007
【図６】
2014154993.tif 000008
【図７】
2014154993.tif 000009
【図８】
2014154993.tif 000010
【図９】
2014154993.tif 000011
【図１０】
2014154993.tif 000012
【図１１】
2014154993.tif 000013