JP6436889B2 - 端末装置、送信方法及び送信プログラム - Google Patents

Description

本発明は、端末装置、送信方法及び送信プログラムに関する。

スマートフォン等のスマートデバイスは、正規の通信事業者から新品として販売されるほか、中古品として販売される場合もある。例えば、インターネットを介するショッピングサイトやオークションサイトにおいて、スマートデバイスが盛んに取引されている。しかし、中古品は、正規の通信事業者が提供するアフターサービス等の補償が受けられない場合がある。

このような商品の補償について、商品購入者が適切に無償修理を受けられるようにする損害保険運営システムに関する技術が知られている。

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

しかしながら、上記の従来技術では、補償サービスを促進させることは難しい。例えば、中古品として流通された商品には一定の品質が保たれているという保証がなく、そのような商品に対して補償サービスを提供することは、補償サービスを提供する事業者にとってリスクが大きい。このため、事業者は積極的に補償サービスを提供することが難しく、それに伴い、商品購入者が利用できる補償サービスが限られてしまうといった問題がある。

本願は、上記に鑑みてなされたものであって、補償サービスを促進させることができる端末装置、サーバ、送信方法及び送信プログラムを提供することを目的とする。

本願に係る端末装置は、前記端末装置の動作が、診断の対象として予め定義された動作内容を満たすか否かを検出する検出部と、前記検出部による検出結果に基づいて、前記端末装置の補償を行う補償サービスを提供するサーバに対して所定の申請を送信する送信部と、を備えたことを特徴とする。

実施形態の一態様によれば、補償サービスを促進させることができるという効果を奏する。

図１は、実施形態に係る補償システムによる処理の一例を示す図である。 図２は、実施形態に係る補償システムによる処理の一例を説明するための図である。 図３は、実施形態に係るユーザ端末の構成例を示す図である。 図４は、実施形態に係る診断情報記憶部の一例を示す図である。 図５は、実施形態に係る補償サーバの構成例を示す図である。 図６は、実施形態に係るユーザ情報記憶部の一例を示す図である。 図７は、実施形態に係る補償システムの処理手順を示すフローチャート（１）である。 図８は、実施形態に係る補償システムの処理手順を示すフローチャート（２）である。 図９は、変形例に係る補償サーバの構成例を示す図である。 図１０は、変形例に係る補償システムによる処理の一例を説明するための図である。 図１１は、ユーザ端末の機能を実現するコンピュータの一例を示すハードウェア構成図である。

以下に、本願に係る端末装置、サーバ、送信方法及び送信プログラムを実施するための形態（以下、「実施形態」と呼ぶ）について図面を参照しつつ詳細に説明する。なお、この実施形態により本願に係る端末装置、サーバ、送信方法及び送信プログラムが限定されるものではない。また、各実施形態は、処理内容を矛盾させない範囲で適宜組み合わせることが可能である。また、以下の各実施形態において同一の部位には同一の符号を付し、重複する説明は省略される。

〔１．補償システムによる処理の一例〕
まず、図１を用いて、実施形態に係る補償システム１による処理の一例について説明する。図１は、実施形態に係る補償システム１による処理の一例を示す図である。図１では、本願に係る端末装置に対応するユーザ端末１０と、本願に係るサーバに対応する補償サーバ１００とを含む補償システム１が実行する処理の一例について説明する。

図１に示すように、補償システム１には、ユーザ端末１０と、補償サーバ１００とが含まれる。ユーザ端末１０及び補償サーバ１００は、図示しないネットワーク（例えば、インターネット）を介して、有線又は無線により通信可能に接続される。なお、図１に示した補償システム１には、複数台のユーザ端末１０や、複数台の補償サーバ１００が含まれてもよい。

ユーザ端末１０は、ユーザによって利用される情報処理端末である。図１の例では、ユーザ端末１０は、スマートフォン（Smartphone）である。なお、ユーザ端末１０は、例えば、デスクトップ型ＰＣ（Personal Computer）や、ノート型ＰＣや、タブレット型端末や、ＰＤＡ（Personal Digital Assistant）や、ウェアラブル端末（Wearable Device）等であってもよい。ユーザ端末１０は、ユーザによる操作に従って、補償サーバ１００との情報の送受信等を行う。なお、以下では、ユーザ端末１０をユーザと表記する場合がある。すなわち、以下では、ユーザをユーザ端末１０と読み替えることもできる。

補償サーバ１００は、ユーザ端末１０等の端末装置（スマートデバイス）の補償サービスを提供する事業者によって管理されるサーバ装置である。端末装置の補償サービスとは、例えば、ユーザから月額の固定料金を徴収する代わりに、ユーザ端末１０が有する一部の機能が故障した場合や、部品が破損した場合に、所定の金額（補償金）や代替品をユーザに補償するサービスである。補償サーバ１００は、補償サービスへの加入の申請をユーザから受け付ける処理や、補償金の支払いの申請をユーザから受け付ける処理や、申請に対して応答する処理等を行う。

補償サーバ１００は、ユーザから補償サービスの加入の申請を受け付けるにあたり、補償サービスを受けようとする端末装置の状態を確認することが望ましい。すなわち、補償サーバ１００は、所定の動作診断により状態に問題がないと確認された端末装置の加入を認める一方で、動作不良を有する端末装置の補償サービスへの加入を制限する。これにより、補償サーバ１００は、補償サービスの加入条件を満たす動作状態にある端末装置であれば、端末装置の購入経路や通信キャリア等を問わずに加入を認めるといった、ユーザにとって加入し易い補償サービスを提供することができる。

そこで、補償システム１に係るユーザ端末１０は、補償サーバ１００から要求される所定の動作診断をユーザ端末１０側で行い、補償サーバ１００が提供する補償サービスへの加入が申請できるか否かを判定する処理を行う。そして、補償サーバ１００は、所定の動作診断によって補償サービスへの加入が認められると判定されたユーザ端末１０からの加入の申請を受け付ける。例えば、ユーザ端末１０は、予めインストールされる所定のアプリケーション（以下、「アプリ」と表記する）を用いて、ユーザ端末１０の動作診断や補償サーバ１００への申請処理を行う。以下、補償システム１が実現する一連の処理を流れに沿って説明する。

図１に示す例において、ユーザＵ０１は、例えばインターネットショップやオークション等を介してユーザ端末１０を購入し、ユーザ端末１０を取得する（ステップＳ１１）。そして、ユーザＵ０１は、取得したユーザ端末１０を操作し、補償サービスに各種申請を行うために用いられる所定のアプリをインストールする。なお、実施形態に係るアプリは、例えば、補償サーバ１００の管理者等から提供される。

ユーザ端末１０は、インストールされたアプリを実行し、ユーザ端末１０自身の動作状態を診断する（ステップＳ１２）。ユーザ端末１０は、動作の診断の結果に基づいて、ユーザ端末１０自身が補償サービスへの加入の申請を行うことができる端末装置であるか否かを判定する。そして、ユーザ端末１０は、動作診断の結果、補償サービスへの加入の申請を行うことができると判定した場合、その旨を表示部１３に表示する。ユーザＵ０１は、補償サービスへの加入を所望する場合、ユーザ端末１０を操作し、補償サービスへの加入の申請を補償サーバ１００へ送信させる（ステップＳ１３）。

ここで、図２を用いて、ステップＳ１２及びステップＳ１３で実行される処理の一例について説明する。図２は、実施形態に係る補償システム１による処理の一例を説明するための図である。図２では、ユーザ端末１０内部で実行されるアプリによって、ユーザ端末１０の表示部１３（例えば、タッチディスプレイ）に種々の情報が表示される動作例を示している。

図２に係る第１状態では、ユーザＵ０１が、アプリを用いてユーザ端末１０の動作診断を行う場合の動作例を示している。例えば、ユーザＵ０１がアプリを用いて動作診断を行う場合、図２に示す表示部１３には、診断項目１３ａや、動作検出マーク１３ｂが表示される。図２に係る第１状態が示す処理は、図１におけるステップＳ１２に対応する。

診断項目１３ａは、アプリが動作を診断する項目名を示す。例えば、診断項目１３ａには、「スピーカー」や、「電源ボタン」や、「マイク」や、「ネットワーク」が含まれる。なお、診断項目１３ａは、図２で図示した項目に限られず、より多くの項目が含まれてもよい。また、動作検出マーク１３ｂは、診断が実行された際に、診断項目に対応する機能の正常な動作が検出された場合に表示される。すなわち、動作検出マーク１３ｂが表示された機能は、正常な機能として検出されたことを示している。

なお、診断する項目や、各機能を正常な動作と判定する判定基準は、例えば補償サーバ１００の管理者等によって任意に設定される。ユーザ端末１０は、上述したアプリを介して、診断の対象とする機能や、機能が正常であると診断される動作内容の定義を把握し、診断する内容として設定する。また、ユーザ端末１０は、動作診断にあたり、ユーザＵ０１からの操作を受け付けてもよい。例えば、ユーザ端末１０は、電源ボタン等の動作の検出にあたり、ユーザＵ０１からの操作を受け付け、電源ボタンが正常に機能するか否かを検出するような手法を採用してもよい。一連の動作診断が終了した場合、表示部１３は、第１状態から第２状態に遷移する（ステップＳ２１）。

図２に係る第２状態では、ユーザ端末１０が動作診断を実行した後に表示する表示部１３の一例を示している。例えば、ユーザ端末１０は、動作診断の結果をテキストボックス１３ｃ内に表示する。ユーザ端末１０は、動作診断の結果を、例えば「ＯＫ」や「ＮＧ」といった文字で表示する。そして、動作診断の結果が「ＯＫ」であった場合、ユーザ端末１０は、補償サービスへの加入の申請を行うか否かを示した選択ボタン１３ｄを表示する。

ユーザＵ０１は、補償サービスへの加入を所望する場合、選択ボタン１３ｄをタッチする。ユーザ端末１０は、ユーザＵ０１のタッチ操作を受け付けた場合に、補償サービスへの加入の申請を補償サーバ１００に送信する。このとき、ユーザ端末１０は、申請とともに、ユーザ端末１０を識別する識別情報や、動作診断の結果の詳細や、ユーザＵ０１に関するユーザ情報等を送信してもよい。この送信処理は、図１におけるステップＳ１３に対応する。

図１に戻って説明を続ける。補償サーバ１００は、ユーザ端末１０から送信された申請を受け付ける（ステップＳ１４）。このとき、補償サーバ１００は、送信された申請に不備がないか否かを確認する。そして、補償サーバ１００は、送信された申請に不備がない場合には、申請を承認する。続いて、補償サーバ１００は、申請を受け付けた旨をユーザ端末１０に送信する（ステップＳ１５）。

すなわち、実施形態に係る補償システム１では、動作診断を行うアプリをユーザ端末１０内部で実行させ、ユーザ端末１０の動作の診断を行う。また、ユーザ端末１０は、動作診断の結果に基づいて、ユーザ端末１０が補償サービスに加入することが可能な端末装置であるか否かの判定を行う。そして、ユーザ端末１０は、ユーザＵ０１の操作に従い、補償サービスへの加入の申請を補償サーバ１００に送信する。補償サーバ１００は、ユーザ端末１０から送信された申請を承認し、承認した旨をユーザ端末１０に応答する。

このように、補償システム１では、補償サーバ１００が提供する補償サービスへの加入の申請にあたり、補償サーバ１００の管理者等により設計された診断を行うアプリをユーザ端末１０で実行させる。さらに、補償システム１は、ユーザ端末１０の動作診断の結果に基づき、ユーザ端末１０が補償サービスへ加入可能か否かについての判定を行う。

このため、補償システム１によれば、補償サービスを提供する側である補償サーバ１００は、インターネットショップやオークションを介して、中古品として販売された端末装置であっても、アプリにより実行された診断を経て申請を受け付けることで、補償サービスの加入条件を満たした端末装置であることを確認することができる。また、補償サービスを利用しようとするユーザＵ０１側は、購入した店舗や購入時期等を理由として他の補償サービスに加入が認められない端末装置であったとしても、アプリにより実行された診断を経て申請を送信することにより、補償サーバ１００が提供する補償サービスに加入することができる。

また、補償システム１によれば、ユーザ端末１０は、ユーザ端末１０が補償サービスに加入することができるかを判定する処理、及び、補償サービスへの加入の申請を送信する処理等を一元化して行うことが可能となる。すなわち、補償システム１では、ユーザＵ０１にとって利便性に優れた形で、動作診断から補償サービスの申請に至るまでの処理を実行させることができる。結果として、補償システム１によれば、補償サービスを促進させることができる。

なお、図１及び図２では、ユーザ端末１０が補償サービスに加入を申請するための処理の流れを一例として示した。しかし、補償システム１では、ユーザ端末１０が既に補償サービスに加入している場合に、例えば動作診断によって故障が検出された場合等の補償の申請を受け付ける処理を行ってもよい。この場合、ユーザ端末１０は、動作診断により、正常に動作しない機能を検出する。そして、ユーザ端末１０は、検出された機能に対応して受けることのできる補償内容を判定し、補償内容に応じた申請を補償サーバ１００に送信する。これにより、ユーザＵ０１は、ユーザ自身によって不具合箇所を特定したり、不具合箇所に応じた申請書類等を作成したりする手間をかけず、ユーザ端末１０を介して、適切な補償の申請を迅速に実行することができる。このように、補償システム１によれば、補償サービス加入の申請のみならず、補償サービス加入後についても、ユーザにとって利便性のよいサービスを提供することができる。

〔２．ユーザ端末の構成〕
次に、図３を用いて、実施形態に係るユーザ端末１０の構成について説明する。図３は、実施形態に係るユーザ端末１０の構成例を示す図である。図３に示すように、ユーザ端末１０は、通信部１１と、入力部１２と、表示部１３と、検知部１４と、記憶部１５と、制御部１６とを有する。なお、ユーザ端末１０が有する各処理部の接続関係は、図３に示した接続関係に限られず、他の接続関係であってもよい。

（通信部１１について）
通信部１１は、ネットワークと有線又は無線で接続され、補償サーバ１００等との間で情報の送受信を行う。例えば、通信部１１は、ＮＩＣ（Network Interface Card）等によって実現される。

（入力部１２について）
入力部１２は、ユーザから各種操作を受け付ける入力装置である。例えば、入力部１２は、ユーザ端末１０に備えられた操作キー等によって実現される。また、入力部１２には、画像を撮影するための撮像装置（カメラ等）や、音声を集音する集音機器（マイク等）が含まれてもよい。

（表示部１３について）
表示部１３は、各種情報を表示するための表示装置である。例えば、表示部１３は、液晶ディスプレイ等によって実現される。なお、ユーザ端末１０にタッチパネルが採用される場合には、入力部１２の一部と表示部１３とは一体化される。

（検知部１４について）
検知部１４は、ユーザ端末１０に対する各種操作や、ユーザ端末１０の周囲の環境情報等を検知する。例えば、検知部１４は、各種情報を検知するセンサやアンテナにより実現される。具体的には、検知部１４は、ユーザ端末１０と接続されている機器に関する通信状況や、ユーザ端末１０の周囲の照度や騒音、ユーザ端末１０の物理的な動き、ユーザ端末１０の位置情報等を検知する。

例えば、検知部１４は、ユーザ端末１０の周囲の音を収集するマイクロフォンや、ユーザ端末１０の周囲の照度を検知する照度センサや、ユーザ端末１０の物理的な動きを検知する加速度センサ（又は、ジャイロセンサなど）や、ユーザ端末１０の周囲の湿度を検知する湿度センサや、ユーザ端末１０の所在位置における磁場を検知する地磁気センサ等を有してもよい。また、検知部１４は、加速度センサの機能を用いて、ユーザ端末１０を利用するユーザの歩行数や行動のパターンを検知してもよい。また、検知部１４は、加速度センサの機能を用いて、ユーザ端末１０が動作しているか、静止しているか、などを示す動作情報を一定時間間隔ごとや、ユーザ端末１０が動作したタイミングごとに検知してもよい。さらに、検知部１４は、ユーザの心拍数や体温などの生体情報を検知する機能や、指紋を検知したり、電磁誘導方式や静電容量方式を用いてユーザ端末１０に触れた位置を感知したりする機能を備えてもよい。また、検知部１４は、ＧＰＳ衛星から送出される電波を受信し、受信した電波に基づいてユーザ端末１０の現在位置を示す位置情報（例えば、緯度及び経度）を検知してもよい。

（記憶部１５について）
記憶部１５は、各種情報を記憶する。記憶部１５は、例えば、ＲＡＭ、フラッシュメモリ（Flash Memory）等の半導体メモリ素子、または、ハードディスク、光ディスク等の記憶装置によって実現される。図３に示す例では、記憶部１５は、診断情報記憶部１５１を有する。

（診断情報記憶部１５１について）
診断情報記憶部１５１は、ユーザ端末１０で実行された動作診断に関する情報を記憶する。ここで、図４に、実施形態に係る診断情報記憶部１５１の一例を示す。図４は、実施形態に係る診断情報記憶部１５１の一例を示す図である。図４に示した例では、診断情報記憶部１５１は、「診断実施ＩＤ」、「診断日時」、「判定結果」、「加入申請」、「項目別結果」といった項目を有する。

「診断実施ＩＤ」は、実施された診断ごとに付与される識別情報である。例えば、ユーザ端末１０は、診断を行った際に、診断が行われた日時や結果を対応付けて、診断実施ＩＤによって特定できるよう、診断情報記憶部１５１に記憶する。

「診断日時」は、ユーザ端末１０において動作診断が実施された日時を示す。「判定結果」は、動作診断の結果が正常であるか否か、すなわち、補償サーバ１００が提供する補償サービスの加入の要件を満たすような結果と判定されたか否かを示す情報である。例えば図４に示すように、「判定結果」は、動作診断に異常が認められない場合には「○」、動作診断において何らかの不具合が認められる場合には「△」といった記号が記憶される。なお、判定結果は、補償サービスに加入を申請するか否かを問わず、診断が行われる度に、診断結果を示す情報として記憶されてもよい。

「加入申請」は、診断結果に基づいて、補償サーバ１００に対して補償サービスへの加入申請を行ったか否かを示す。なお、ユーザ端末１０の加入が既に認められている場合には、加入申請の項目は、空欄表示となる。

「項目別結果」は、動作診断において行われる診断の項目別の結果を示す。例えば、「項目別結果」には、図２で示したように、「電源ボタン」や、「スピーカー」や、「マイク」や、「ネットワーク」といった項目が含まれる。ユーザ端末１０は、各々の項目に対応する動作診断を行い、診断の結果を「○」や「△」といった記号を用いて記憶する。例えば、ユーザ端末１０は、診断した各項目（機能）のうち、正常な動作が検出された項目には「○」を記憶し、不具合が検出された項目には「△」を記憶する。

すなわち、図４では、動作診断ＩＤ「Ｔ０１」で識別される診断は、「２０１５年１１月１日 ９：００」に行われたことを示している。また、かかる診断では、判定結果は「○」であり、かかる結果を受けて、補償サーバ１００へ加入の申請が行われたことを示している。そして、かかる診断では、「電源ボタン」や、「スピーカー」や、「マイク」や、「ネットワーク」等の各項目で動作診断が行われ、いずれの項目についても、結果は「○」であることを示している。なお、ユーザ端末１０は、診断において各項目のいずれかに「△」があった場合には、判定結果を「△」と判定するようにしてもよい。例えば、図４で示すように、診断結果ＩＤ「Ｔ０３」で識別される診断は、電源ボタンの項目に「△」を含むため、判定結果は「△」であると判定される。

（制御部１６について）
制御部１６は、例えば、ＣＰＵ（Central Processing Unit）やＭＰＵ（Micro Processing Unit）等によって、ユーザ端末１０内部の記憶装置に記憶されている各種プログラムがＲＡＭ（Random Access Memory）を作業領域として実行されることにより実現される。また、制御部１６は、例えば、ＡＳＩＣ（Application Specific Integrated Circuit）やＦＰＧＡ（Field Programmable Gate Array）等の集積回路により実現される。

制御部１６は、ユーザ端末１０において行われる動作診断や、補償サービスへの加入の申請可否の判定や、補償サーバ１００との情報の送受信など、各種処理を制御する。図３に示すように、制御部１６は、受信部１６１と、診断制御部１６２と、設定部１６３と、検出部１６４と、判定部１６５と、送信部１６６とを有し、以下に説明する情報処理の機能や作用を実現または実行する。例えば、制御部１６は、ＲＡＭを作業領域として上述したアプリを実行することにより、各種情報処理を実現する。なお、制御部１６の内部構成は、図３に示した構成に限られず、後述する情報処理を行う構成であれば他の構成であってもよい。

（受信部１６１について）
受信部１６１は、各種情報を受信する。例えば、受信部１６１は、補償サーバ１００から送信される情報を受信する。また、受信部１６１は、検知部１４が検知する各種情報を受信し、取得する。受信部１６１が受信する情報は、例えば、診断制御部１６２による動作診断に利用される。

（診断制御部１６２について）
診断制御部１６２は、ユーザ端末１０の動作の診断に関する処理を制御する。例えば、診断制御部１６２は、上述したアプリが実行されることにより、ユーザ端末１０自身の動作の診断を実行する。そして、診断制御部１６２は、動作診断の結果に基づいて、補償サービスへの加入の申請や、補償の申請等の実行可否の判定処理を行う。例えば、診断制御部１６２は、動作診断を行う旨の操作をユーザＵ０１から受け付けた場合に、動作診断の処理を実行する。診断制御部１６２は、設定部１６３、検出部１６４及び判定部１６５の各部を制御することにより、動作の診断に関する処理を実行する。

（設定部１６３について）
設定部１６３は、動作の診断に関する設定を行う。例えば、設定部１６３は、ユーザ端末１０が有する機能のうち、診断の対象とする機能と、機能が正常であると診断される動作内容の定義を設定する。

診断の対象とする機能、及び、機能が正常であると診断される動作内容の定義は、補償サーバ１００の管理者等により任意に定められる。これは、補償サーバ１００の管理者等が補償サービスへの加入を認めるにあたり、ユーザ端末１０に求める条件と言い換えてもよい。

例えば、補償サーバ１００の管理者は、補償サービスへ加入を認める条件として、正常に電源の入り切りができるか、タッチディスプレイに正常な反応があるか、ネットワークアンテナが正常に機能しているかといった、ユーザ端末１０に求める正常な動作の項目を条件とする。そして、設定部１６３は、上述したアプリを介して、補償サービスへ加入が認められるための条件を参照し、ユーザ端末１０内部で実施される診断の項目を設定する。なお、所定の条件は、補償サーバ１００との通信を介して、随時更新されてもよい。設定部１６３は、補償サーバ１００によって条件が更新された場合には、更新にともない、診断する項目や、機能が正常であると診断される動作内容の定義を新たに設定する。

また、設定部１６３は、ユーザ端末１０が補償サービスに加入した後の動作診断に関する設定を行う。例えば、設定部１６３は、前回の診断から所定の期間が経過した場合に、定期的に動作診断が行われるように、診断を行うタイミングを設定する。これにより、ユーザ端末１０は、ユーザＵ０１から動作診断を実行するための操作を受けない場合であっても、定期的に行われる動作診断によって不具合箇所を検出することができる。

（検出部１６４について）
検出部１６４は、ユーザ端末１０の動作が、診断の対象として予め定義された動作内容を満たすか否かを検出する。診断の対象として予め定義された動作内容とは、診断項目として設定された機能、及び、その機能が正常に動作していると判定される動作の内容を含む。

例えば、検出部１６４は、設定部１６３によって設定された診断項目について、予め設定された動作を試みる。そして、検出部１６４は、各項目の機能が、設定部１６３によって設定された定義を満たすように動作していること、言い換えれば、正常に動作しているか否かを検出する。これにより、検出部１６４は、ユーザ端末１０において正常な動作をしている機能、及び、ユーザ端末１０における不具合箇所を検出することができる。

例えば、検出部１６４は、診断項目がスピーカーである場合には、設定部１６３によって設定された所定の音量設定を用いて、スピーカーから音声を出力させる。そして、検出部１６４は、スピーカーから出力される音声の出力レベルを観測する。この場合、検出部１６４は、例えば、検知部１４が備える各種センサ（マイクロフォン等）を利用してもよいし、外部機器を利用してもよい。そして、検出部１６４は、音声の出力レベルが所定の条件を満たすレベルで観測されること、すなわち、ユーザ端末１０が備えるスピーカーが正常に動作していることを検出する。検出部１６４は、正常な動作を検出した場合には、当該診断項目の結果にその旨を記憶する。なお、検出部１６４は、ユーザに情報を伝達するため、図２に示したように、正常な機能として検出された旨を示す動作検出マーク１３ｂを表示部１３に表示させてもよい。

検出部１６４は、設定部１６３によって設定された診断項目及び診断手法に従い、複数の項目の診断を順に行う。なお、検出部１６４は、必要な場合には、診断に際してユーザに操作を求めてもよい。例えば、検出部１６４は、タッチディスプレイの動作を診断する場合には、ユーザにディスプレイをタッチすることを要求してもよい。そして、検出部１６４は、ユーザによってタッチされた際の圧力や位置等を観測することで、タッチディスプレイが問題なく動作していることを検出する。

（判定部１６５について）
判定部１６５は、検出部１６４によって検出された結果に基づいて、ユーザ端末１０の補償を行う補償サービスを提供する補償サーバ１００に対して、所定の申請を行うことが可能か否かを判定する。

例えば、判定部１６５は、検出部１６４によって診断が行われた項目のうち、いずれの項目についても正常な動作が検出された場合に、補償サービスへの加入が可能であると判定する。一方、判定部１６５は、いずれかの項目について正常な動作が検出されなかった場合には、補償サービスへの加入ができないものと判定する。なお、かかる判定に関する基準は、診断項目等と同じく、補償サーバ１００の管理者等により任意に定められる。判定部１６５は、例えば、ネットワークを介して、補償サーバ１００から判定に関する基準の更新や変更を受け付けてもよい。

判定部１６５は、申請を行うことが可能であると判定した場合には、ユーザ端末１０を利用するユーザＵ０１から申請を行うか否かの選択を受け付ける。例えば、判定部１６５は、図２の第２状態に示したような選択ボタン１３ｄを表示部１３に表示させることで、ユーザＵ０１の選択を受け付ける。

また、判定部１６５は、ユーザ端末１０が補償サービスに加入済みである場合には、検出部１６４によって検出された結果に基づいて、補償サービスに補償の申請を行うことができるか否かを判定する。

例えば、判定部１６５は、検出部１６４によって検出された結果を参照し、正常な動作が検出されなかった項目が、ユーザ端末１０が加入している補償サービスの対象であるか否かを判定する。そして、判定部１６５は、正常な動作が検出されなかった項目が補償サービスの対象である場合、補償の申請を行うことができる旨を、表示部１３を介してユーザに伝達する。

（送信部１６６について）
送信部１６６は、各種情報を送信する。例えば、送信部１６６は、検出部１６４による検出結果に基づいて、ユーザ端末１０の補償を行う補償サービスを提供する補償サーバ１００に対して所定の申請を送信する。具体的には、送信部１６６は、判定部１６５によって所定の申請を行うことが可能であると判定された場合に、補償サーバ１００に対して所定の申請を送信する。

例えば、送信部１６６は、補償サービスへの加入の申請が可能であると判定部１６５によって判定された場合には、加入の申請を補償サーバ１００に送信する。また、ユーザ端末１０が補償サービスへ加入済みであり、動作診断によって不具合箇所が検出された場合には、送信部１６６は、不具合箇所に対応する補償の申請を補償サーバ１００に送信する。

なお、かかる送信処理は、ユーザＵ０１の選択を待って行われてもよい。すなわち、送信部１６６は、ユーザＵ０１が申請を行うことを選択した場合に、補償サーバ１００に対して申請を送信するようにしてもよい。

〔３．補償サーバの構成〕
次に、図５を用いて、実施形態に係る補償サーバ１００の構成について説明する。図５は、実施形態に係る補償サーバ１００の構成例を示す図である。図５に示すように、補償サーバ１００は、通信部１１０と、記憶部１２０と、制御部１３０とを有する。なお、補償サーバ１００は、補償サーバ１００を利用する管理者等から各種操作を受け付ける入力部（例えば、キーボードやマウス等）や、各種情報を表示するための表示部（例えば、液晶ディスプレイ等）を有してもよい。

（通信部１１０について）
通信部１１０は、例えば、ＮＩＣ等によって実現される。通信部１１０は、ネットワークと有線又は無線で接続され、ネットワークを介して、ユーザ端末１０及びとの間で情報の送受信を行う。

（記憶部１２０について）
記憶部１２０は、例えば、ＲＡＭ、フラッシュメモリ等の半導体メモリ素子、または、ハードディスク、光ディスク等の記憶装置によって実現される。記憶部１２０は、ユーザ情報記憶部１２１を有する。

（ユーザ情報記憶部１２１について）
ユーザ情報記憶部１２１は、ユーザに関する情報を記憶する。ここで、図６に、実施形態に係るユーザ情報記憶部１２１の一例を示す。図６は、実施形態に係るユーザ情報記憶部１２１の一例を示す図である。図６に示した例では、ユーザ情報記憶部１２１は、「ユーザＩＤ」、「端末ＩＤ」、「加入日時」、「機種情報」といった項目を有する。

「ユーザＩＤ」は、ユーザを識別する識別情報を示す。「端末ＩＤ」は、ユーザが利用する端末装置を識別する識別情報を示す。なお、ユーザＩＤ及び端末ＩＤは、参照符号と一致するものとする。例えば、ユーザＩＤが「Ｕ０１」であるユーザは、「ユーザＵ０１」である。また、端末ＩＤが「１０」である端末装置は、「ユーザ端末１０」である。

「加入日時」は、補償サーバ１００が提供する補償サービスに加入した日時を示す。「機種情報」は、端末ＩＤで識別される端末装置の機種情報を示す。なお、図６では、機種情報は「Ｄ０１」等の概念で表記しているが、実際には、機種の型番、メーカー名、ＯＳ（Operating System）、過去の診断情報など、端末装置に関する各種情報が記憶される。

すなわち、図６に示す一例では、ユーザＩＤ「Ｕ０１」で識別されるユーザＵ０１が、端末ＩＤ「１０」で識別されるユーザ端末１０について、「２０１５年１１月１日 ９：１０」に補償サービスに加入したことを示している。また、ユーザ端末１０の機種情報は、「Ｄ０１」であることを示している。

（制御部１３０について）
制御部１３０は、例えば、ＣＰＵやＭＰＵ等によって、補償サーバ１００内部の記憶装置に記憶されている各種プログラムがＲＡＭを作業領域として実行されることにより実現される。また、制御部１３０は、例えば、ＡＳＩＣやＦＰＧＡ等の集積回路により実現される。

図５に示すように、制御部１３０は、受付部１３１と、承認部１３２と、送信部１３３とを有し、以下に説明する機能や作用を実現または実行する。なお、制御部１３０の内部構成は、図５に示した構成に限られず、後述する情報処理を行う構成であれば、他の構成であってもよい。

（受付部１３１について）
受付部１３１は、各種情報を受け付ける。例えば、受付部１３１は、ユーザ端末１０から送信される補償サービスへの加入の申請を受け付ける。この場合、受付部１３１は、申請とともに、ユーザ端末１０を利用するユーザＵ０１の情報や、ユーザ端末１０を識別する識別情報等の情報を受け付けてもよい。受付部１３１は、受け付けた情報を適宜ユーザ情報記憶部１２１に記憶する。

また、受付部１３１は、ユーザ端末１０が補償サービスに加入済みである場合には、ユーザ端末１０から送信される補償の申請を受け付ける。この場合、受付部１３１は、動作診断においてどのような不具合が検出されたか等、診断に関する詳細な情報を受け付けてもよい。

また、受付部１３１は、補償サーバ１００の管理者等から、補償サービスの加入を認める条件や、補償金の申請の手続きの条件など、補償サービスの仕様の変更等を受け付けてもよい。

（承認部１３２について）
承認部１３２は、ユーザから受け付けた各種申請を承認する。例えば、承認部１３２は、ユーザ端末１０から送信された補償サービスへの加入の申請に応答し、ユーザ端末１０の補償サービスへの加入を承認する。この場合、承認部１３２は、所定の条件に基づいて、ユーザ端末１０の補償サービスへの加入を承認するか否かを判定してもよい。例えば、承認部１３２は、加入の申請を送信したユーザや端末装置の履歴を参照し、過去に不正な申請があった場合等には、かかるユーザが利用する端末装置からの申請を承認しないようにしてもよい。

また、承認部１３２は、ユーザ端末１０から送信された補償の申請に応答し、ユーザ端末１０への補償金の支払いを承認してもよい。この場合、承認部１３２は、診断の詳細情報を参照し、ユーザ端末１０から送信された補償の申請と、診断の詳細情報とが対応しているか否かを判定してもよい。そして、承認部１３２は、ユーザ端末１０から送信された補償の申請が正当なものと認められる場合に、ユーザ端末１０への補償金の支払いを承認する。

（送信部１３３について）
送信部１３３は、各種情報を送信する。例えば、送信部１３３は、承認部１３２が承認した補償サービスへの加入に関する情報をユーザ端末１０に送信する。また、送信部１３３は、承認部１３２が承認した補償金の支払いに関する情報をユーザ端末１０に送信する。

また、送信部１３３は、例えば、補償サービスの加入を認めるための診断項目の変更等を受付部１３１が補償サーバ１００の管理者から受け付けた場合に、かかる変更をユーザ端末１０に送信してもよい。この場合、送信部１３３は、例えばアプリがインストールされた際の情報に基づいて、変更に関する情報を送信するユーザ端末１０を特定する。なお、このような補償サービスの仕様の変更や更新は、補償サーバ１００とユーザ端末１０が直接に情報のやりとりを行うのではなく、所定のサーバ（例えば、スマートフォンに各種アプリを提供する専用サーバ）を介して行われてもよい。

〔４．処理手順〕
次に、図７及び図８を用いて、実施形態に係る補償システム１による処理の手順について説明する。図７は、実施形態に係る補償システム１の処理手順を示すフローチャート（１）である。図７では、ユーザ端末１０が補償サービスへの加入の申請を行う際の処理の流れについて説明する。

図７に示すように、ユーザ端末１０に係る診断制御部１６２は、動作診断を実行する旨をユーザから受け付けたか否かを判定する（ステップＳ１０１）。動作診断を実行する旨をユーザから受け付けていない場合には、診断制御部１６２は、受け付けるまで待機する（ステップＳ１０１；Ｎｏ）。

一方、動作診断を実行する旨をユーザから受け付けた場合には（ステップＳ１０１；Ｙｅｓ）、検出部１６４は、設定部１６３によって設定された内容に従い、ユーザ端末１０の動作の診断を実行する（ステップＳ１０２）。

そして、判定部１６５は、検出された動作、すなわち、動作診断の結果が、補償サービスの加入のための所定の基準を満たすか否かを判定する（ステップＳ１０３）。所定の基準を満たす場合には（ステップＳ１０３；Ｙｅｓ）、判定部１６５は、補償サービスの申請を行うことができる旨を表示する（ステップＳ１０４）。一方、所定の基準を満たさない場合には（ステップＳ１０３；Ｎｏ）、判定部１６５は、補償サービスの申請を行うことができない旨を表示する（ステップＳ１０５）。

さらに、判定部１６５は、申請を行う旨をユーザから受け付けたか否かを判定する（ステップＳ１０６）。申請を行う旨をユーザから受け付けた場合には（ステップＳ１０６；Ｙｅｓ）、送信部１６６は、補償サービスへの加入の申請を補償サーバ１００に送信する（ステップＳ１０７）。

送信部１６６が補償サービスへの加入の申請を補償サーバ１００に送信した場合、判定部１６５によって補償サービスの申請を行うことができないと判定された場合、あるいは、申請を行う旨をユーザから受け付けない場合（ステップＳ１０６；Ｎｏ）のいずれにおいても、診断制御部１６２は、診断に関する情報（結果）を診断情報記憶部１５１に記憶する（ステップＳ１０８）。

次に、図８を用いて、ユーザ端末１０が補償サービスに加入している場合に行われる処理の流れについて説明する。図８は、実施形態に係る補償システム１の処理手順を示すフローチャート（２）である。

図８に示すように、ユーザ端末１０に係る診断制御部１６２は、前回の診断から所定期間が経過したか否かを判定する（ステップＳ２０１）。所定期間が経過していない場合には（ステップＳ２０１；Ｎｏ）、診断制御部１６２は、所定期間が経過するまで待機する。

一方、所定期間が経過した場合には（ステップＳ２０１；Ｙｅｓ）、検出部１６４は、予め設定部１６３によって設定された内容に従い、動作の診断を実行する（ステップＳ２０２）。そして、検出部１６４は、診断において不具合が検出されたか否かを判定する（ステップＳ２０３）。検出部１６４によって不具合が検出された場合には（ステップＳ２０３；Ｙｅｓ）、判定部１６５は、検出された不具合が補償サービスの対象であるか否かを判定する（ステップＳ２０４）。

検出された不具合が補償サービスの対象であると判定した場合（ステップＳ２０４；Ｙｅｓ）、判定部１６５は、補償の申請を行うか否かを選択するボタン等を表示部１３に表示させる（ステップＳ２０５）。

そして、判定部１６５は、補償の申請を行う旨をユーザから受け付けたか否かを判定する（ステップＳ２０６）。補償の申請を行う旨をユーザから受け付けた場合（ステップＳ２０６；Ｙｅｓ）、送信部１６６は、補償の申請を補償サーバ１００に送信する（ステップＳ２０７）。

送信部１６６が補償サービスへの加入の申請を補償サーバ１００に送信した場合、ステップＳ２０３において不具合が検出されなかった場合（ステップＳ２０３；Ｎｏ）、ステップＳ２０４において不具合が補償サービスの対象でなかった場合（ステップＳ２０４；Ｎｏ）、あるいは、申請を行う旨をユーザから受け付けない場合（ステップＳ２０６；Ｎｏ）のいずれにおいても、診断制御部１６２は、診断に関する情報（結果）を診断情報記憶部１５１に記憶する（ステップＳ２０８）。

なお、診断制御部１６２は、一連の処理において、ステップＳ２０５以外であっても、各処理の流れについてユーザが確認できるよう、適宜、表示部１３に診断処理の進行具合等を表示させるようにしてもよい。

〔５．変形例〕
上述した補償システム１による処理は、上記実施形態以外にも種々の異なる形態にて実施されてよい。そこで、以下では、補償システム１の他の実施形態（変形例）について説明する。

〔５−１．補償サーバによる判定〕
動作診断の結果に基づいて、補償サービスへの加入の申請を行うことができるか否か、あるいは、加入済みの補償サービスへ補償の申請を行うことができるか否かといった判定については、ユーザ端末１０に係る判定部１６５が行うのではなく、サーバ側で行ってもよい。

この場合、サーバ側は、ユーザ端末１０に係る判定部１６５に対応する処理部を有する。ここで、図９に、変形例に係る補償サーバ２００の構成例を示す。図９は、変形例に係る補償サーバ２００の構成例を示す図である。図９に示すように、補償サーバ２００は、補償サーバ１００と比較して、判定部２３４をさらに備える。

変形例において、補償サーバ２００に係る受付部１３１は、ユーザ端末１０から送信される申請とともに、動作診断の詳細な結果を受け付ける。動作診断の詳細な結果には、例えば、動作診断で実施された項目、各項目の結果、動作診断が実施された日時等が含まれる。

そして、判定部２３４は、受付部１３１によって受け付けられた動作診断の結果が、申請に係る所定の条件を満たしているか否かを判定する。例えば、判定部２３４は、ユーザ端末１０から送信された申請が補償サービスへの加入の申請である場合には、動作診断の結果が補償サービスへの加入の条件を満たしているか否かを判定する。また、判定部２３４は、ユーザ端末１０から送信された申請が、不具合等に対応する補償の申請である場合には、動作診断の結果が補償サービスで補償される内容を満たしているか否かを判定する。かかる処理は、実施形態において、ユーザ端末１０に係る判定部１６５と同様の処理手順により行われる。

すなわち、変形例に係る補償システム１によれば、ユーザ端末１０で判定処理を行わずとも、補償サーバ２００側で申請の可否を判定することができる。このように、変形例に係る補償システム１は、柔軟な構成を用いて、実施形態で説明した情報処理を実現することができる。

なお、上記では、端末装置１００に係る送信部１６６が、所定の申請とともに、検出部１６４による検出結果を送信する場合を例に示したが、送信部１６６は、まず初めに検出結果のみを補償サーバ２００に送信するようにしてもよい。この場合、補償サーバ２００に係る判定部２３４は、検出結果に基づいて、補償サービスにおける所定の判定を行う。所定の判定とは、例えば、動作診断の結果に基づいて、検出結果の送信元であるユーザ端末１０が補償サービスに加入可能か否か、あるいは、ユーザ端末１０に対する補償が可能であるか否かといったことを判定するものである。

そして、ユーザ端末１０に係る受信部１６１は、補償サーバ２００が検出結果に基づいて所定の判定を行った判定結果を受信する。その後に、送信部１６６は、判定結果に応じて、補償サーバ２００に申請を送信する。この場合、送信部１６６は、判定結果を閲覧したユーザＵ０１の操作に応答して、補償サーバ２００に所定の申請を送信するようにしてもよい。

例えば、送信部１６６は、判定結果が、ユーザ端末１０が補償サービスに加入することを承認するものである場合には、所定の申請として、補償サーバ２００に補償サービスへの加入の申請を送信する。また、送信部１６６は、判定結果が、ユーザ端末１０が補償サービスから補償を受けることが可能であることを示すものである場合には、所定の申請として、補償サーバ２００に補償サービスへの補償の申請を送信する。このように、ユーザ端末１０は、動作診断ののち、補償サーバ２００へ検出結果を送信し、判定結果に応じて、あらためて申請を送信するようにしてもよい。

〔５−２．補償サービスの種別〕
上記実施形態では、ユーザ端末１０で実施される動作診断において、いずれの項目においても正常な動作が検出された場合に、補償サービスへの加入の申請が可能であると判定される例を示した。しかし、かかる判定基準は、適宜、柔軟に設定されてもよい。

例えば、補償システム１において、ユーザ端末１０で実施される動作診断に所定の点数（スコア）を設定し、補償サーバ１００は、スコアに応じた補償サービスを提供するようにしてもよい。ここで、図１０を用いて、変形例に係る補償システム１による処理の一例を説明する。図１０は、変形例に係る補償システム１による処理の一例を説明するための図である。

図１０に係る第１状態では、ユーザＵ０１が、アプリを用いてユーザ端末１０の動作診断を行う場合の動作例を示している。図２と同様、ユーザＵ０１がアプリを用いて動作診断を行う場合、表示部１３には、診断項目１３ａが示される。ここで、表示部１３において、正常な動作が検出されなかった項目については、不具合を示す不具合マーク１３ｅが表示されるものとする。一連の動作診断が終了した場合、表示部１３は、第１状態から第２状態に遷移する（ステップＳ２２）。

図１０に係る第２状態では、ユーザ端末１０が動作診断を実行した後に表示する表示部１３の一例を示している。例えば、ユーザ端末１０は、動作診断の結果をテキストボックス１３ｃ内に表示する。変形例において、ユーザ端末１０は、動作診断の結果を、例えば「９０」点といったスコアで表示する。例えば、スコアは、診断項目ごとに予め点数が設定され、正常な動作が検出されなかった項目については、当該項目分の点数が減点されることで算出される。

そして、ユーザ端末１０は、スコアに応じて、ユーザ端末１０が加入することのできる補償サービスに関する情報をユーザＵ０１に提示する。図１０に示す例では、ユーザ端末１０は、「月額４００円コースの補償サービスに加入することができます」といった情報が表示される。このような表示処理は、例えば、スコアが「１００」点であれば月額「３００」円で補償サービスに加入することができるといったような、スコアに応じた条件の設定をユーザ端末１０が予め受け付けておき、スコアに応じた結果を表示することにより実現される。

そして、ユーザＵ０１は、表示された条件で補償サービスへの加入を所望する場合、選択ボタン１３ｄをタッチする。ユーザ端末１０は、ユーザＵ０１のタッチ操作を受け付けた場合に、補償サービスへの加入の申請を補償サーバ１００に送信する。

このように、変形例に係る補償システム１において、ユーザ端末１０に係る判定部１６５は、検出部１６４によって検出された結果に基づいて、補償サービスが提供する補償内容のうち、ユーザ端末１０が加入することが可能な補償内容を判定する。また、送信部１６６は、判定部１６５によって加入することが可能と判定された補償内容での補償サービスへの加入の申請を送信する。

これにより、変形例に係る補償システム１では、動作診断において全ての項目で正常な動作が検出されない状態であっても、その状況に応じて、ユーザが加入することのできる補償サービスを提示することができる。例えば、補償システム１では、やや動作に難がある端末であっても、通常より高い月額の課金額を支払うこと等により補償サービスに加入できるといった、柔軟な対応が可能となる。さらに、補償システム１では、動作診断の結果を受けて対応を行うため、提供する補償サービスの種類を適切に選択することができる。

〔５−３．補償のレコメンド〕
ユーザ端末１０は、動作診断を行った場合に、補償に関するレコメンドを表示するようにしてもよい。例えば、動作診断の結果の信頼性は有限であるため、動作診断の結果に基づいて、補償サービスの加入の申請を行うことができる期間（例えば、２週間以内など）が定められる場合がある。この場合、ユーザ端末１０は、動作診断が行われた後に、加入の申請を送信することができる期間の表示などのレコメンドをユーザＵ０１に提示するようにしてもよい。

また、ユーザ端末１０は、補償サービスに加入済みである場合には、例えば、定期的に行われる診断ののち、不具合箇所をユーザＵ０１に提示するとともに、受け取れる可能性のある補償金の額等を表示し、ユーザに補償の申請を行うことを促すようなレコメンドを表示するようにしてもよい。

〔５−４．アプリの構成〕
上記実施形態において、動作診断を行うアプリと、補償サーバ１００との間で各種通信を行うアプリは、一体であってもよいし、別々のアプリとして構成されてもよい。

また、上記実施形態においてアプリによって実行されるとして説明した処理は、必ずしもアプリとしてパッケージされたプログラムであることを要しない。ユーザ端末１０は、動作診断に関するプログラムや、判定に関するプログラム等を適宜取得することにより、診断制御部１６２が実行する処理や、送信部１６６が実行する処理等を実現してもよい。

〔６．ハードウェア構成〕
また、上述してきた実施形態に対応する端末装置は、例えば図１１に示すような構成のコンピュータ１０００によって実現される。以下、端末装置の一例として、ユーザ端末１０を例に挙げて説明する。図１１は、ユーザ端末１０の機能を実現するコンピュータ１０００の一例を示すハードウェア構成図である。コンピュータ１０００は、ＣＰＵ１１００、ＲＡＭ１２００、ＲＯＭ１３００、ＨＤＤ１４００、通信インターフェイス（Ｉ／Ｆ）１５００、入出力インターフェイス（Ｉ／Ｆ）１６００、及びメディアインターフェイス（Ｉ／Ｆ）１７００を有する。

ＣＰＵ１１００は、ＲＯＭ１３００又はＨＤＤ１４００に記憶されたプログラムに基づいて動作し、各部の制御を行う。ＲＯＭ１３００は、コンピュータ１０００の起動時にＣＰＵ１１００によって実行されるブートプログラムや、コンピュータ１０００のハードウェアに依存するプログラム等を記憶する。

ＨＤＤ１４００は、ＣＰＵ１１００によって実行されるプログラム、及び、かかるプログラムによって使用されるデータ等を記憶する。通信インターフェイス１５００は、通信網５００（ネットワーク）を介して他の機器からデータを受信してＣＰＵ１１００へ送り、ＣＰＵ１１００が作成したデータを、通信網５００を介して他の機器へ送信する。

ＣＰＵ１１００は、入出力インターフェイス１６００を介して、ディスプレイやプリンタ等の出力装置、及び、キーボードやマウス等の入力装置を制御する。ＣＰＵ１１００は、入出力インターフェイス１６００を介して、入力装置からデータを取得する。また、ＣＰＵ１１００は、入出力インターフェイス１６００を介して作成したデータを出力装置へ出力する。

メディアインターフェイス１７００は、記録媒体１８００に記憶されたプログラム又はデータを読み取り、ＲＡＭ１２００を介してＣＰＵ１１００に提供する。ＣＰＵ１１００は、かかるプログラムを、メディアインターフェイス１７００を介して記録媒体１８００からＲＡＭ１２００上にロードし、ロードしたプログラムを実行する。記録媒体１８００は、例えばＤＶＤ（Digital Versatile Disc）、ＰＤ（Phase change rewritable Disk）等の光学記録媒体、ＭＯ（Magneto-Optical disk）等の光磁気記録媒体、テープ媒体、磁気記録媒体、または半導体メモリ等である。

例えば、コンピュータ１０００が実施形態に係るユーザ端末１０として機能する場合、コンピュータ１０００のＣＰＵ１１００は、ＲＡＭ１２００上にロードされたプログラムを実行することにより、制御部１６の機能を実現する。また、ＨＤＤ１４００には、記憶部１５内のデータが記憶される。コンピュータ１０００のＣＰＵ１１００は、これらのプログラムを記録媒体１８００から読み取って実行するが、他の例として、他の装置から通信網５００を介してこれらのプログラムを取得してもよい。

〔７．その他〕
また、上記実施形態において説明した各処理のうち、自動的に行われるものとして説明した処理の全部または一部を手動的に行うこともでき、あるいは、手動的に行われるものとして説明した処理の全部または一部を公知の方法で自動的に行うこともできる。この他、上記文書中や図面中で示した処理手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。例えば、各図に示した各種情報は、図示した情報に限られない。

また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。例えば、図３に示した受信部１６１と送信部１６６とは統合されてもよい。また、例えば、記憶部１５に記憶される情報は、ネットワークを介して、外部に備えられた記憶装置に記憶されてもよい。

また、例えば、上記実施形態では、ユーザ端末１０が、ユーザ端末１０の動作の診断を制御する診断制御部１６２と、情報の送信を行う送信部１６６とを備える例を示した。しかし、ユーザ端末１０は、動作の診断を制御する診断装置と、情報の送信を行う送信装置とに分離されてもよい。この場合、説明してきたユーザ端末１０による処理は、例えば、診断装置と送信装置との各装置を有する補償システム１によって実現される。

また、上述してきた各実施形態及び変形例は、処理内容を矛盾させない範囲で適宜組み合わせることが可能である。

〔８．効果〕
上述してきたように、本願に係るユーザ端末１０は、検出部１６４と、送信部１６６とを有する。検出部１６４は、ユーザ端末１０の動作が、診断の対象として予め定義された動作内容を満たすか否かを検出する。送信部１６６は、検出部１６４による検出結果に基づいて、ユーザ端末１０の補償を行う補償サービスを提供する補償サーバ１００に対して所定の申請を送信する。

このように、実施形態に係るユーザ端末１０は、自装置であるユーザ端末１０に関する動作診断を実行し、動作診断の結果に基づいて、補償サービスへの申請を行う。これにより、ユーザ端末１０は、動作診断から、動作診断の結果に基づき補償サービスへ申請するまでの処理を一元的に行うことができる。通常、ユーザが補償サービスへ申しこむ場合には、補償サービスを提供する業者の店舗等に、サービスの対象となる端末を持ち込んだり送付したりして、チェックを受けることが必要となる。実施形態に係るユーザ端末１０によれば、このような手間を掛けることなく、補償サービスへの加入の申請や、加入後の補償の申請を行うことができる。すなわち、ユーザ端末１０は、ユーザＵ０１にとって利便性のよい処理を提供する。このため、ユーザ端末１０によれば、補償サービスの利用を促進させることができる。

また、送信部１６６は、所定の申請を承認するか否かを検出結果に基づいて判定する補償サーバ２００に対して、検出部１６４による検出結果とともに、当該所定の申請を送信する。

このように、実施形態に係るユーザ端末１０は、動作診断の結果を補償サーバ２００に送信し、申請の判定を補償サーバ２００に実行させてもよい。これにより、ユーザ端末１０は、動作診断が行われた後に所定の送信処理を実行するのみで、補償サービスの利用の可否を知ることができる。かかる構成によっても、ユーザＵ０１の利便性を向上させることができるので、補償サービスの利用を促進させることができる。

また、実施形態に係るユーザ端末１０は、検出部１６４による検出結果に基づいて、補償サーバ１００に対して、所定の申請を行うことが可能か否かを判定する判定部１６５をさらに備えてもよい。送信部１６６は、判定部１６５によって所定の申請を行うことが可能であると判定された場合に、補償サーバ１００に対して当該所定の申請を送信する。

これにより、ユーザ端末１０は、動作診断から、動作診断の結果に基づき補償サービスへ申請可能な内容の判定までを一元的に行うことができる。このため、ユーザ端末１０を利用するユーザＵ０１は、補償サービスに関して、自身が申請することが可能な申請を迅速、かつ、正確に把握することができるので、補償サービスの利用が促されることとなる。このため、ユーザ端末１０によれば、補償サービスの利用を促進させることができる。

また、送信部１６６は、判定部１６５によって所定の申請を行うことが可能であると判定された場合に、補償サーバ１００に対して所定の申請を送信する。

このように、実施形態に係るユーザ端末１０は、判定部１６５によって判定された内容に基づいて補償サーバ１００への申請を送信する。これにより、ユーザ端末１０は、動作診断から申請処理までを一連の処理として行うことができる。このため、ユーザ端末１０によれば、ユーザＵ０１の手間をかけず、適切な補償サービスの利用を行うことができる。

また、判定部１６５は、所定の申請を行うことが可能であると判定した場合に、所定の申請を行うか否かの選択をユーザ端末１０のユーザＵ０１から受け付ける。送信部１６６は、ユーザＵ０１が所定の申請を行うことを選択した場合に、補償サーバ１００に対して、所定の申請を送信するようにしてもよい。

このように、実施形態に係るユーザ端末１０は、判定部１６５によって判定された内容をユーザＵ０１に提示し、ユーザＵ０１の判断に基づいて所定の申請を送信するようにすることもできる。これにより、ユーザ端末１０は、ユーザＵ０１の要望に沿った補償サービスの利用を促進させることができる。

また、判定部１６５は、所定の申請として、補償サービスへの加入の申請が可能か否かを判定する。

このように、実施形態に係るユーザ端末１０は、動作診断の結果に基づいて、補償サービスへの加入の申請が可能か否かを判定することができる。これにより、ユーザ端末１０を利用するユーザＵ０１は、動作診断を行う処理に続けて補償サービスへの加入の申請を送信することができるため、利便性に優れたサービスを享受することができる。

また、判定部１６５は、検出部１６４によって検出された結果に基づいて、補償サービスが提供する補償内容のうち、ユーザ端末１０が加入することが可能な補償内容を判定する。送信部１６６は、判定部１６５によって加入することが可能と判定された補償内容での補償サービスへの加入の申請を送信する。

このように、実施形態に係るユーザ端末１０は、検出された結果（すなわち、診断結果）に基づいて、ユーザ端末１０が加入可能な内容を判定することができる。これにより、ユーザ端末１０を利用するユーザＵ０１は、例えばユーザ端末１０の動作にやや難がある場合であっても、補償内容によっては加入の申請を送信することができる。すなわち、ユーザ端末１０によれば、より多くのユーザが補償サービスに加入することのできるような、柔軟な判定処理を行うことができる。

また、判定部１６５は、ユーザ端末１０が補償サービスに加入している場合には、所定の申請として、補償サービスに対する補償の申請が可能か否かを判定する。

このように、実施形態に係るユーザ端末１０は、補償サービスの加入の申請のみならず、動作診断の状況に応じて、補償の申請を行うことができるか否かを判定することができる。これにより、ユーザ端末１０は、不具合箇所を早期に検出することができるとともに、不具合箇所に対応する補償サービスの利用を促進させることができる。

また、判定部１６５は、検出部１６４によって検出された結果に基づいて、補償サービスが補償する補償内容のうち、ユーザ端末１０が申請することが可能な補償内容を判定する。送信部１６６は、判定部１６５によって申請することが可能と判定された補償に関する申請を送信する。

このように、実施形態に係るユーザ端末１０は、動作診断の状況に応じて、補償の申請を行うことができる内容を判定することができる。これにより、ユーザ端末１０は、ユーザＵ０１が自ら不具合箇所を特定したりする手間を省かせることができるため、ユーザＵ０１の補償サービスの利用の利便性を向上させることができる。

また、検出部１６４は、ユーザ端末１０が補償サービスに加入している場合には、予め設定された所定の期間ごとに、ユーザ端末１０の動作が、診断の対象として予め定義された動作内容を満たすか否かを検出する。判定部１６５は、検出部１６４によって定義を満たさない動作が検出された場合には、当該動作に対応する補償の申請が可能であるか否かを判定する。

このように、実施形態に係るユーザ端末１０は、定期的な動作診断を実行し、その結果に基づいた補償の申請を行うことができる。これにより、ユーザ端末１０は、ユーザＵ０１から動作診断の実行等の指示を受け付けることを要せずとも、適切な補償サービスの利用を促進させることができる。

また、判定部１６５は、補償の申請を行うことが可能であると判定した場合に、補償の申請を行うことが可能な旨をユーザ端末１０のユーザＵ０１に提示する。送信部１６６は、判定部１６５によって提示された補償の申請に対して、ユーザＵ０１が補償の申請を行うことを選択した場合に、補償サーバ１００に対して補償の申請を送信する。

このように、実施形態に係るユーザ端末１０は、動作診断の結果に基づいて、補償の申請を行うことができる旨等をユーザに提示するような、いわゆるレコメンドのような処理を行うことができる。これにより、ユーザ端末１０は、補償サービスの利用をユーザに促すことができる。

また、ユーザ端末１０は、以下の構成であってもよい。すなわち、ユーザ端末１０は、検出部１６４と、送信部１６６と、受信部１６１とを有する。検出部１６４は、ユーザ端末１０の動作が、診断の対象として予め定義された動作内容を満たすか否かを検出する。送信部１６６は、ユーザ端末１０の補償を行う補償サービスを提供するサーバであって、検出部１６４による検出結果に基づいて所定の判定を行うサーバである補償サーバ２００に対して、検出結果を送信する。受信部１６１は、補償サーバ２００が検出結果に基づいて所定の判定を行った判定結果を受信する。そして、送信部１６６は、受信部１６１によって受信された判定結果に応じて、補償サーバ２００に所定の申請を送信する。

このように、実施形態に係るユーザ端末１０は、動作診断の結果のみを補償サーバ２００に送信し、補償サーバ２００による判定結果を受けてから、申請を行ってもよい。すなわち、ユーザ端末１０は、ユーザＵ０１が受け得るサービスを伝達したうえで、ユーザＵ０１が所望するサービスの申請を行うことができる。これにより、ユーザ端末１０は、ユーザＵ０１の利便性を向上させることができる。

また、送信部１６６は、判定結果が、ユーザ端末１０が補償サービスに加入することを承認するものである場合に、所定の申請として、補償サーバ２００に当該補償サービスへの加入の申請を送信する。また、送信部１６６は、判定結果が、ユーザ端末１０が補償サービスから補償を受けることが可能であることを示すものである場合に、所定の申請として、補償サーバ２０に当該補償サービスへの補償の申請を送信する。

このように、実施形態に係るユーザ端末１０は、補償サーバ２００による判定に応答して、ユーザ端末１０に認められた申請を的確に送信することができる。これにより、ユーザ端末１０は、ユーザＵ０１にとって無駄な手間が生じない、迅速なサービスを享受させることができる。

以上、本願の実施形態のいくつかを図面に基づいて詳細に説明したが、これらは例示であり、発明の開示の欄に記載の態様を始めとして、当業者の知識に基づいて種々の変形、改良を施した他の形態で本発明を実施することが可能である。

また、上述してきた「部（section、module、unit）」は、「手段」や「回路」などに読み替えることができる。例えば、検出部１６４は、検出手段や検出回路に読み替えることができる。

１ 補償システム
１０ ユーザ端末
１６ 制御部
１００ 補償サーバ
１１０ 通信部
１２０ 記憶部
１２１ ユーザ情報記憶部
１３０ 制御部
１３１ 受付部
１３２ 承認部
１３３ 送信部
１６１ 受信部
１６２ 診断制御部
１６３ 設定部
１６４ 検出部
１６５ 判定部
１６６ 送信部
２００ 補償サーバ

Claims (9)

1. 端末装置であって、
   前記端末装置が有する機能のうち、診断の対象とする機能と、機能が正常であると診断される動作内容の定義とを設定する設定部と、
   前記設定部によって診断の対象と設定された機能における前記端末装置の動作が、当該設定部によって定義された動作内容を満たすか否かを検出し、検出した結果を示す検出結果を記憶部に格納する検出部と、
   前記記憶部に格納された検出結果を参照し、参照した検出結果に基づいて、前記端末装置の補償を行う補償サービスを提供するサーバに対して所定の申請を行うことが可能か否かを判定し、所定の申請を行うことが可能であると判定した場合に、判定結果とともに、当該判定結果に基づき申請可能なサービスを申し込むための選択ボタンを当該端末装置の画面内に表示する判定部と、
   前記判定部によって前記所定の申請を行うことが可能であると判定され、かつ、前記端末装置のユーザが前記選択ボタンを選択することによって当該所定の申請を行う選択を当該ユーザから受け付けた場合に、前記サーバに対して当該所定の申請を送信する送信部と、
   を備えたことを特徴とする端末装置。
2. 前記送信部は、
   前記所定の申請を承認するか否かを前記検出結果に基づいて判定する前記サーバに対して、前記検出部による検出結果とともに、当該所定の申請を送信する、
   ことを特徴とする請求項１に記載の端末装置。
3. 前記判定部は、
   前記所定の申請として、前記補償サービスへの加入の申請が可能か否かを判定する、
   ことを特徴とする請求項１又は２に記載の端末装置。
4. 前記判定部は、
   前記検出部による検出結果に基づいて、前記補償サービスが提供する補償内容のうち、前記端末装置が加入することが可能な補償内容を判定し、
   前記送信部は、
   前記判定部によって加入することが可能と判定された補償内容での前記補償サービスへの加入の申請を送信する、
   ことを特徴とする請求項３に記載の端末装置。
5. 前記判定部は、
   前記端末装置が前記補償サービスに加入している場合には、前記所定の申請として、前記補償サービスに対する補償の申請が可能か否かを判定する、
   ことを特徴とする請求項１〜４のいずれか一つに記載の端末装置。
6. 前記検出部は、
   前記端末装置が前記補償サービスに加入している場合には、予め設定された所定の期間ごとに、当該端末装置の動作が、診断の対象として予め定義された動作内容を満たすか否かを検出し、
   前記判定部は、
   前記検出部によって前記定義を満たさない動作が検出された場合には、当該動作に対応する補償の申請が可能であるか否かを判定する、
   ことを特徴とする請求項１〜５のいずれか一つに記載の端末装置。
7. 前記判定部は、
   前記補償の申請を行うことが可能であると判定した場合に、当該補償の申請を行うことが可能な旨を前記端末装置のユーザに提示し、
   前記送信部は、
   前記判定部によって提示された補償の申請に対して、前記ユーザが補償の申請を行うことを選択した場合に、前記サーバに対して当該補償の申請を送信する、
   ことを特徴とする請求項６に記載の端末装置。
8. 端末装置で実行される送信方法であって、
   前記端末装置が有する機能のうち、診断の対象とする機能と、機能が正常であると診断される動作内容の定義とを設定する設定工程と、
   前記設定工程によって診断の対象と設定された機能における前記端末装置の動作が、当該設定工程によって定義された動作内容を満たすか否かを検出し、検出した結果を示す検出結果を記憶部に格納する検出工程と、
   前記記憶部に格納された検出結果を参照し、参照した検出結果に基づいて、前記端末装置の補償を行う補償サービスを提供するサーバに対して所定の申請を行うことが可能か否かを判定し、所定の申請を行うことが可能であると判定した場合に、判定結果とともに、当該判定結果に基づき申請可能なサービスを申し込むための選択ボタンを当該端末装置の画面内に表示する判定工程と、
   前記判定工程によって前記所定の申請を行うことが可能であると判定され、かつ、前記端末装置のユーザが前記選択ボタンを選択することによって当該所定の申請を行う選択を当該ユーザから受け付けた場合に、前記サーバに対して当該所定の申請を送信する送信工程と、
   を含んだことを特徴とする送信方法。
9. 端末装置が有する機能のうち、診断の対象とする機能と、機能が正常であると診断される動作内容の定義とを設定する設定手順と、
   前記設定手順によって診断の対象と設定された機能における前記端末装置の動作が、当該設定手順によって定義された動作内容を満たすか否かを検出し、検出した結果を示す検出結果を記憶部に格納する検出手順と、
   前記記憶部に格納された検出結果を参照し、参照した検出結果に基づいて、前記端末装置の補償を行う補償サービスを提供するサーバに対して所定の申請を行うことが可能か否かを判定し、所定の申請を行うことが可能であると判定した場合に、判定結果とともに、当該判定結果に基づき申請可能なサービスを申し込むための選択ボタンを当該端末装置の画面内に表示する判定手順と、
   前記判定手順によって前記所定の申請を行うことが可能であると判定され、かつ、前記端末装置のユーザが前記選択ボタンを選択することによって当該所定の申請を行う選択を当該ユーザから受け付けた場合に、前記サーバに対して当該所定の申請を送信する送信手順と、
   を前記端末装置に実行させることを特徴とする送信プログラム。

Images