(57)【要約】【課題】実行中の複数のアプリのうち、ディスカバリ信号を送信するアプリを特定し、当該特定されたアプリのディスカバリ信号を優先して送信するＵＥを提供する。【解決手段】ＵＥは、他のＵＥとＤ２Ｄ通信が可能である。ＵＥは、各々がデバイス間通信に対応した複数のアプリと、複数のアプリにおける各々のアプリの優先度とを記憶している。ＵＥは、自端末の存在を他のＵＥに通知するためのディスカバリ信号を送信可能であるする。ディスカバリ信号は、複数のアプリのうちのいずれか１つのアプリの識別情報を含む。ＵＥは、複数のアプリが実行されている場合、優先度の高いアプリの識別情報を含むディスカバリ信号を、当該アプリよりも優先度の低いアプリの識別情報を含むディスカバリ信号よりも優先して送信する。【選択図】図４
2016116160.tif 000002
【特許請求の範囲】
【請求項１】
基地局装置を介さずに通信機器と直接通信を行なうデバイス間通信が可能な携帯端末装置であって、
各々が前記デバイス間通信に対応した複数のアプリケーションプログラムと、前記複数のアプリケーションプログラムにおける各々のアプリケーションプログラムの優先度とを記憶するための記憶手段と、
前記携帯端末装置の存在を前記通信機器に通知するための第１の信号を送信する送信手段とを備え、
前記第１の信号は、前記複数のアプリケーションプログラムのうちのいずれか１つのアプリケーションプログラムの識別情報を含み、
前記複数のアプリケーションプログラムが実行されている場合、前記優先度の高い前記アプリケーションプログラムの識別情報を含む前記第１の信号を、当該アプリケーションプログラムよりも前記優先度の低いアプリケーションプログラムの識別情報を含む前記第１の信号よりも優先して、前記送信手段に送信させる送信制御手段をさらに備える、携帯端末装置。
【請求項２】
ユーザによる操作入力および前記アプリケーションプログラムの利用履歴の少なくとも一方を用いて、前記優先度を設定する、請求項１に記載の携帯端末装置。
【請求項３】
前記通信機器から、前記通信機器の存在を前記携帯端末装置に通知するための第２の信号を受信する受信手段をさらに備え、
前記第２の信号は、前記複数のアプリケーションプログラムのうちのいずれか１つのアプリケーションプログラムの識別情報を含み、
前記識別情報毎の前記第２の信号の受信回数を用いて前記優先度を設定する、請求項１または２に記載の携帯端末装置。
【請求項４】
前記識別情報毎の前記第１の信号の未送信回数を用いて前記優先度を設定する、請求項１から３のいずれか１項に記載の携帯端末装置。
【請求項５】
前記通信機器から、前記通信機器の存在を前記携帯端末装置に通知するための第２の信号を受信する受信手段と、
予め割り当てられた無線リソースプールに割り当てられた前記第２の信号の数に基づき、前記無線リソースプールが混雑しているか否かを判断する判断手段とをさらに備え、
前記送信制御手段は、前記無線リソースが混雑していると判断されたことを条件に、前記優先度を用いた前記第１の信号の送信制御を行なう、請求項１から４のいずれか１項に記載の携帯端末装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、Ｄ２Ｄ通信が可能な携帯端末装置に関する。
【背景技術】
【０００２】
従来、基地局装置（ｅＮＢ：evolved NodeB）を介さずに端末（ＵＥ：User Equipment）同士が通信を行なう端末間（D2D: device to device）通信が知られている。Ｄ２Ｄ通信は、D2D Proximity Services (ProSe)とも称される。Proximity Servicesは、特許文献１〜３に示すとおり、3GPP（3rd Generation Partnership Project）のRelease 12において規格化されている。特に、特許文献２には、D2D Proximity Servicesにおける近接検知サービスである“Proximity discovery”（以下、「Ｄ２Ｄディスカバリサービス」と称する）が開示されている。
【０００３】
Ｄ２Ｄディスカバリサービスは、Ｄ２Ｄディスカバリ機能を有するＬＴＥ（Long Term Evolution）端末およびD2D Proximity Servicesを利用するアプリケーションプログラムによって実行可能である。また、ｅＮＢがＤ２Ｄディスカバリをサポートする圏内に位置するＵＥ間において近接検知を可能するサービスが検討されている。
【０００４】
Ｄ２Ｄディスカバリサービスでは、D2D Proximity Servicesを利用するアプリケーションプログラムの実行により、ｅＮＢが割り当てたディスカバリ専用の無線リソースプール、あるいは予めＳＩＭ（Subscriber Identity Module）等により設定された無線リソースプールから、ＵＥが任意に１つあるいは複数のリソース（ブロック）を選択し、ディスカバリ信号を送信する。これにより、ＵＥは、他のＵＥに自身の存在を通知する。また、ＵＥは、他のＵＥの存在を発見するために、ディスカバリ用の無線リソースのすべてあるいは一部を受信する。
【０００５】
ディスカバリ信号は、ProSe (Proximity Service) UE IDと、ProSe Application IDとを含む。ProSe Application IDは、アプリケーションプログラム毎に割り当てられた専用のＩＤである。それゆえ、Ｄ２Ｄを利用する複数のアプリケーションプログラムは、それぞれ、ProSe Application IDを含むディスカバリ信号の送信要求を自端末の制御部に行なう。また、各アプリケーションプログラムは、ＵＥにおいて受信された他のＵＥのディスカバリ信号に基づき、同じアプリケーションプログラムを実行している他のＵＥの存在を識別できる。その際、ＵＥは、識別結果をディスプレイに表示させることによって当該ＵＥの利用者に通知する。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特表２０１３−５２９４１６号公報
【特許文献２】特開２０１４−１７１０９３号公報
【非特許文献】
【０００７】
【非特許文献１】3GPP TR 36.843 V12.0.1 (2014-03): 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; Study on LTE Device to Device Proximity Services; Radio Aspects (Release 12)
【非特許文献２】3GPP TR 23.703 V12.0.0 (2014-02)： 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Study on architecture enhancements to support Proximity-based Services (ProSe) (Release 12)
【非特許文献３】3GPP TS 23.303 V12.1.0 (2014-06)： 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Proximity-based services (ProSe);  Stage 2 (Release 12)
【発明の概要】
【発明が解決しようとする課題】
【０００８】
ユーザが複数のアプリケーションプログラムの各々においてＤ２Ｄディスカバリサービスを利用する場合、ＵＥは、規格において１台のＵＥに利用が許可されている１つあるいは複数の無線リソースを選択して、各アプリケーションプログラムのProSe Application IDを含むディスカバリ信号を複数送信する必要がある。１台のＵＥが利用可能な無線リソース内で、複数のアプリケーションプログラムのディスカバリ信号を１タイムフレームで送信できないような場合は、各アプリケーションプログラムのディスカバリ信号が全て送信されるまでにライムラグが発生する。
【０００９】
Ｄ２Ｄ通信を行なっているＵＥ同士の各々の移動を考慮すると、各ＵＥは、定期的にディスカバリ信号を送受信し、近接しているＵＥを検知する必要がある。また、各ＵＥに個々の無線リソースをｅＮＢによって割り当てるようなシステム構成とすることも可能である。しかしながら、ｅＮＢの構成を簡易化するため、ｅＮＢは各ＵＥでのディスカバリ信号の送受信用として、複数の無線リソースで構成される無線リソースプールをＵＥに割り当てる。各ＵＥはディスカバリ信号を送信する際は、その割り当てられた無線リソースプールを各ＵＥで共有し、無線リソースプールから任意に無線リソースを選択してディスカバリ信号を送信するシステムが導入される予定である。この場合、各ＵＥのディスカバリ信号は、衝突する可能性が生じる。特に、ディスカバリ信号のトラフィックが高い場合は、ディスカバリ信号の衝突確率が高くなる。
【００１０】
このような状況では、あるＵＥにおいて複数のアプリケーションプログラムからディスカバリ信号の送信要求がある場合には、そのユーザが所望するアプリケーションプログラムのディスカバリ信号を、他のＵＥまたはＤ２Ｄ通信の相手のＵＥが迅速に検知できない、あるいは検知すらできないという事態も生じ得る。
【００１１】
また、複数のアプリケーションプログラムの各々についてのユーザにとっての重要度は、必ずしも同じとは言えない。
【００１２】
本願発明は、上記の問題点に鑑みなされたものであって、その目的は、実行中の複数のアプリケーションプログラムのうち、ディスカバリ信号を送信するアプリケーションプログラムを特定し、当該特定されたアプリケーションプログラムのディスカバリ信号を優先して送信可能な携帯端末装置を提供することにある。
【課題を解決するための手段】
【００１３】
本発明ある局面に従うと、携帯端末装置は、基地局装置を介さずに通信機器と直接通信を行なうデバイス間通信が可能である。携帯端末装置は、各々がデバイス間通信に対応した複数のアプリケーションプログラムと、複数のアプリケーションプログラムにおける各々のアプリケーションプログラムの優先度とを記憶するための記憶手段と、携帯端末装置の存在を通信機器に通知するための第１の信号を送信する送信手段とを備える。第１の信号は、複数のアプリケーションプログラムのうちのいずれか１つのアプリケーションプログラムの識別情報を含む。携帯端末装置は、複数のアプリケーションプログラムが実行されている場合、優先度の高いアプリケーションプログラムの識別情報を含む第１の信号を、当該アプリケーションプログラムよりも優先度の低いアプリケーションプログラムの識別情報を含む第１の信号よりも優先して、送信手段に送信させる送信制御手段をさらに備える。
【発明の効果】
【００１４】
上記の発明によれば、実行中の複数のアプリケーションプログラムのうち、ディスカバリ信号を送信するアプリケーションプログラムを特定し、当該特定されたアプリケーションプログラムのディスカバリ信号を優先して送信可能となる。
【図面の簡単な説明】
【００１５】
【図１】通信システムの概略構成を表した図である。
【図２】ＵＥ１１の機能的構成を説明するための機能ブロック図である。
【図３】ディスカバリ用の無線リソースプールにおけるディスカバリ信号の送受信例を説明するための図である。
【図４】ＵＥ１１における処理の流れの一例を表したフローチャートである。
【図５】ある局面におけるデータテーブル５００を説明するための図である。
【図６】図５の状態（第１の状態）の後のある局面におけるデータテーブル５００を説明するための図である。
【図７】アプリケーション＃４がディスカバリ信号の送信要求をＤ２Ｄ管理部１５２に上げた後のデータテーブル５００を説明するための図である。
【図８】アプリケーション＃４のディスカバリ信号の受信回数が１５回となった後のデータテーブル５００を説明するための図である。
【図９】ＵＥ１１のハードウェア構成を説明するための図である。
【発明を実施するための形態】
【００１６】
以下、図面を参照しつつ、本発明の各実施の形態に係る通信システムについて説明する。また、以下の説明では、同一の部材には同一の参照符号を付してある。それらの名称および機能も同じである。したがって、それらについての詳細な説明は繰り返さない。なお、以下では、アプリケーションプログラムを、略して、「アプリ」と称する。
【００１７】
＜Ａ．システム構成＞
【００１８】
図１は、通信システムの概略構成を表した図である。図１を参照して、通信システム１は、少なくとも、ＵＥ１１と、ＵＥ１２と、ｅＮＢ２０とを備えている。ＵＥ１１は、ｅＮＢ２０を介さずにＵＥ１２と直接通信を行なうデバイス間通信が可能である。つまり、ＵＥ１１とＵＥ１２とは、Ｄ２Ｄ通信を行なう。
【００１９】
ＵＥ１１，１２は、Ｄ２Ｄディスカバリ機能を有するＬＴＥ端末（ＬＴＥ規格に準拠した携帯端末装置）である。典型的には、ＵＥ１１，１２は、スマートフォンである。ＵＥ１１，１２には、Ｄ２Ｄディスカバリサービスを利用するアプリ（以下、「Ｄ２Ｄ対応アプリ」とも称する）が予め複数インストールされている。Ｄ２Ｄ対応アプリとは、上述したように、D2D Proximity Serviceを利用することが可能なアプリである。Ｄ２Ｄ対応アプリの例としては、たとえば、ＳＮＳ、ゲーム、広告、コミュニケーションアプリ等のアプリが挙げられる。
【００２０】
以下では、ＵＥ１１，１２には、D2D Proximity Servicesを実行可能な端末の識別子として“ProSe UE ID”が割り振られているものとする。また、以下では、通信システム１においては、一例として、ｅＮＢ２０が、Ｄ２Ｄ通信の認証、無線リソースプールの割り当て、タイミングのリファレンス信号の生成等を制御しているものとする。なお、ｅＮＢの代わりにＵＥに当該制御を行なわせることも可能である。
【００２１】
ＵＥ１１，１２は、ｅＮＢ２０からの無線リソースプールの情報に基づき、Ｄ２Ｄのディスカバリ信号を送信するための無線リソースを任意に選択する。また、ＵＥ１１とＵＥ１２とは、ｅＮＢ２０を介さずに、互いに、ディスカバリ信号の送受信を行なう。ＵＥ１１および１２の各々は、任意に選択したディスカバリ信号送信用の無線リソースを用いて、ＵＥ自身の存在を周りのＵＥに通知するためのディスカバリ信号を送信する。ディスカバリ信号には、典型的には、アプリを識別するためのProSe Application ID、およびＵＥを識別するProSe UE IDが含まれている。
【００２２】
説明を補足すると以下のとおりである。Ｄ２Ｄ通信においては、現状、アプリベースで通信およびＵＥを発見する想定で検討がなされている。詳しくは、アプリ毎にＩＤが振られ、ＵＥが当該ＩＤを含むディスカバリ信号を発信することにより、相手のＵＥに検出してもらう仕組みになっている。
【００２３】
たとえば、Facebook（登録商標）およびTwitter（登録商標）の各々にProSe Application IDが割り振られ、Facebookを利用するときに、近くにFacebookの友達がいないか探すというような利用シーンが想定されている。したがって、Facebook、Twitter、各種のゲームアプリなどを複数同時に立ち上げて、友達検出するような場合、１台のＵＥでも複数のアプリのディスカバリ信号を送信することになる。また、ＵＥは、ディスカバリ信号を検出する際も、アプリにより発見した他のＵＥのディスカバリ信号をフィルタリングすることにより、たとえばFacebookの友達だけを近くに検出したことをユーザに通知する。
【００２４】
＜Ｂ．優先度を用いた処理の概要＞
【００２５】
次に、上述したシステム構成を前提とした上で、実行中の複数のアプリのうち、ディスカバリ信号を送信するアプリを特定し、当該特定されたアプリのディスカバリ信号を優先して送信可能とするために、優先度を用いる構成について説明する。なお、以下では、優先度とは、ディスカバリ信号を送信する順位（優先順位）を表すものとして説明する。また、以下では、説明の便宜上、ＵＥ１１をディスカバリ信号の送信側、ＵＥ１２をディスカバリ信号の受信側として例に挙げて説明するが、ＵＥ１１，ＵＥ１２はそれぞれディスカバリ信号の送信および受信の処理を同様に行う。また、以下の説明では、ＵＥ１１のＤ２Ｄ通信相手ＵＥ１２として説明するが、ディスカバリ信号の相手先はＵＥ１２のみでなく、複数のＵＥで受信され、検知されるものである。
【００２６】
ＵＥ１１は、上述したように、ｅＮＢ２０を介さずにＵＥ１２とＤ２Ｄ通信が可能である。ＵＥ１１は、各々がＤ２Ｄ通信に対応した複数のアプリと、当該複数のアプリにおける各々のアプリの優先度（以下、「アプリ優先度」と称する）とを記憶している。
【００２７】
ＵＥ１１は、ＵＥ１１の存在を通知するためのディスカバリ信号を送信する。ディスカバリ信号は、上述したように、複数のアプリのうちのいずれか１つのアプリの識別情報（つまり、ProSe Application ID）を含む。
【００２８】
ＵＥ１１は、複数のアプリが実行されている場合、上記アプリ優先度の高いアプリの識別情報を含むディスカバリ信号を、当該アプリよりもアプリ優先度の低いアプリの識別情報を含むディスカバリ信号よりも優先して送信する。
【００２９】
その結果、ＵＥ１１においては、ディスカバリ信号を送信するアプリとしてアプリ優先度の高いアプリが特定でき、当該特定されたアプリのディスカバリ信号を他のアプリのディスカバリ信号よりも優先して、相手のＵＥに送信可能となる。その結果、優先度の高いアプリのディスカバリ信号が他のＵＥ（通信相手）によって検出されないといった事態の発生を低減することができる。なお、アプリ優先度の設定方法等の詳細については後述する。
【００３０】
＜Ｃ．機能的構成＞
【００３１】
図２は、ＵＥ１１の機能的構成を説明するための機能ブロック図である。図２を参照して、ＵＥ１１は、アプリ実行部１５１と、Ｄ２Ｄ管理部１５２と、ＧＵＩ部１５３と、記憶部１５４と、受信部１５５と、送信部１５６とを備えている。Ｄ２Ｄ管理部１５２は、記憶部１５２１と、ディスカバリ受信判定部１５２２と、優先度設定部１５２３と、ディスカバリ送信制御部１５２４とを有する。ＧＵＩ（Graphical User Interface）部１５３は、表示部１５３１と入力部１５３２とを有する。受信部１５５は、Ｄ２Ｄディスカバリ信号受信部１５５１を有する。送信部１５６は、ディスカバリ信号送信部１５６１を有する。
【００３２】
（ｃ１．全体概要）
【００３３】
アプリ実行部１５１は、記憶部１５４に予め記憶されているＤ２Ｄ対応のアプリ＃１，＃２，＃３，…を記憶部１５４から読出し、各々のアプリを実行する。なお、以下では、Ｄ２Ｄ通信を行なうための設定（ユーザＩＤやProSe Application ID等の設定）がされている構成を例に挙げて説明する。実行中の各アプリ＃１，＃２，＃３，…は、ディスカバリ信号の送受信が必要となった場合、ディスカバリ信号の送受信要求をＤ２Ｄ管理部１５２に送る。
【００３４】
Ｄ２Ｄ管理部１５２は、Ｄ２Ｄ通信に関する各種の処理を管理する。Ｄ２Ｄ管理部１５２の処理の詳細については後述する。
【００３５】
ＧＵＩ部１５３の表示部１５３１は、各種の情報を表示する。表示部１５３１は、ある局面において、アプリ優先度の設定に関する入力画面を表示する。入力部１５３２は、ユーザから各種の入力を受け付ける。入力部１５３２は、アプリ優先度の設定に関する入力画面が表示部１５３１に表示されている状態において、アプリ優先度を決定する１つの要素（因子）の優先度（以下、「要素優先度」とも称する）を指定するユーザ入力を受け付ける。
【００３６】
受信部１５５は、ｅＮＢ２０から送信されるデータ、および他のＵＥ（ＵＥ１２等）から送られてくる各種のデータ（ユーザデータ等）を受信する。特に、受信部１５５のディスカバリ信号受信部１５５１は、Ｄ２Ｄ通信により他のＵＥから送信されてくるディスカバリ信号等を受信する。
【００３７】
送信部１５６は、ｅＮＢ２０に対して、Ｄ２Ｄ通信の場合には他のＵＥに対して、データ（ユーザデータ等）を送信する。特に、ディスカバリ信号送信部１５６１は、ディスカバリ信号を送信する。
【００３８】
（ｃ２．Ｄ２Ｄ管理部１５２の詳細）
【００３９】
以下、Ｄ２Ｄ管理部１５２における各部の処理の詳細について説明する。
【００４０】
各アプリ＃１，＃２，＃３，…について、ＵＥ１１のユーザがいずれのアプリを主に使用するかについて、ユーザが、利用度レベルをＧＵＩ部１５３を用いて設定する。設定された利用度レベルは、Ｄ２Ｄ管理部１５２における記憶部１５２１に格納される。
【００４１】
Ｄ２Ｄ管理部１５２は、各アプリ＃１，＃２，＃３，…から送信された、ディスカバリ信号の送受信要求を受信すると、ディスカバリ信号の送受信を管理（制御）する。特に、Ｄ２Ｄ管理部１５２は、複数のアプリ＃１，＃２，＃３，…の各々におけるアプリ優先度を算出し、算出結果（アプリ優先度）を記憶する。なお、当該送受信要求には、各アプリ用のディスカバリ信号の生成に必要となる、ProSe Application IDおよびProSe UE ID等の情報が含まれている。
【００４２】
ディスカバリ受信判定部１５２２は、ｅＮＢ２０が割り当てたディスカバリ信号の無線リソース数と、受信したディスカバリ信号の数とから、ディスカバリ信号用に割り当てられた無線リソースプールの利用度（混雑状況）を判定する。また、ディスカバリ受信判定部１５２２は、受信したディスカバリ信号のProSe Application IDおよびUEIDなど（以下、両者を合わせて「アプリ情報」とも称する）を判定する。ディスカバリ受信判定部１５２２は、これらの判定結果を優先度設定部１５２３へ通知する。
【００４３】
優先度設定部１５２３は、ディスカバリ受信判定部１５２２から受信した各種の判定結果を用いて、記憶部１５２１に予め記憶されているデータテーブルの値を更新することにより、アプリ優先度（優先順位）を設定するための合計点数（図５〜図８）を算出する。
【００４４】
Ｄ２Ｄ管理部１５２は、典型的には、上述した無線リソースプールの利用度（混雑状況）が高い場合には、アプリ優先度を利用する。なお、これに限定されるものではなく、ディスカバリ信号用に割り当てられた無線リソースプールの利用度（混在状況）に関係なく、ＵＥ１１が当該アプリ優先度を利用した処理を実行する構成としてもよい。
【００４５】
優先度設定部１５２３は、具体的には、ＵＥ１２等の他のＵＥから受信したディスカバリ信号に含まれるアプリ情報（ProSe Application IDおよびProSe UE IDなど）、ＧＵＩ部１５３を用いたユーザによる設定内容、およびアプリの利用履歴の少なくとも１つに基づき、アプリ優先度を判定する。より詳しくは、優先度設定部１５２３は、アプリ情報に基づく判定としては、詳細については後述するが、ディスカバリ信号の受信回数およびディスカバリ信号の未送信回数（累積値）を用いた判定を行なう。
【００４６】
Ｄ２Ｄ管理部１５２は、各アプリからのディスカバリ信号の送信要求と上記算出されたアプリ優先度とに応じて、各アプリのディスカバリ信号の送信順序、送信頻度、および送信フレームタイミングを決定する。ディスカバリ送信制御部１５２４は、当該決定に基づき、ディスカバリ信号をディスカバリ信号送信部１５６１に送信させる。
【００４７】
以上のように、Ｄ２Ｄ管理部１５２は、以下の項目［Ａ］と項目［Ｂ］との判定（算出）を行なう。
【００４８】
［Ａ］ディスカバリ信号用の無線リソースプール（詳しくは、後述するディスカバリ用のサブフレームにおける無線リソース）の利用度（混在状況）
【００４９】
［Ｂ］次のディスカバリ用サブフレームにおいて、どのアプリのディスカバリ信号を送信するか（つまり、アプリ優先度の算出）
【００５０】
特に、項目［Ｂ］のアプリ優先度を決定する要素としては、典型的には、上述したように、以下の要素（α）〜（δ）が挙げられる。
【００５１】
（α）ＧＵＩを用いたユーザによるアプリについての要素優先度の設定
【００５２】
（β）アプリの利用履歴（詳しくは、アプリでＤ２Ｄを使った履歴（利用回数））
【００５３】
（γ）他端末から受信した各アプリに対するディスカバリ信号の受信回数
【００５４】
（δ）前回のディスカバリ用のサブフレームまでにディスカバリ信号を送信できなかった回数（未送信回数）
【００５５】
本実施の形態では、ＵＥ１１は、一例として、上記の項目［Ａ］の判定を行なうとともに、項目［Ｂ］の判定に関しては上記の要素（α）〜（δ）の全てを考慮してアプリ優先度の算出を行なうものとする。
【００５６】
なお、要素（α）〜（δ）のうちの１つの要素毎に要素優先度を算出するように、Ｄ２Ｄ管理部１５２を構成してもよい。ただし、アプリ優先度の算出において要素（δ）を考慮することが好ましい。理由は、ユーザ設定や受信回数の状況などよって優先度が低いと判定されたアプリのディスカバリ信号が全く送信できないといった状況が生じることを防止するためのである。また、利用履歴は、たとえば、直近の１週間以内の利用回数とすることができる。なお、利用回数の代わりに、利用時間の合計としてもよい。
【００５７】
また、上述したように、無線リソースプールの利用度（混雑状況）を考慮してもよいし、考慮しなくてもよい。つまり、Ｄ２Ｄ管理部１５２は、アプリ優先度だけでディスカバリ信号の送信制御を行なってもよい。無線リソースプールの利用度が高いと判定された場合（つまり、混雑している場合）には、各ＵＥの無線リソースプールからの無線リソースの任意選択によりディスカバリ信号の送信が衝突する確率が高いため、優先度の高いアプリのディスカバリ信号の送信回数を更に増やすように制御してもよい。具体的には、「無線リソースの利用度の高いときには、要素（δ）についての要素優先度を用いたアプリ優先度の調整をしないように、優先度設定部１５２３を構成してもよい。
【００５８】
（ｃ３．ディスカバリ用サブフレームの無線リソースプールにおけるディスカバリ信号の送受信例）
【００５９】
図３は、ディスカバリ用のサブフレームの無線リソースプールにおけるディスカバリ信号の送受信例を説明するための図である。図３を参照して、所定の周波数帯域において、ｅＮＢ２０によってディスカバリ用のサブフレームとして無線リソースプールＰ１，Ｐ２，Ｐ３，…が割り当てられている。
【００６０】
また、このディスカバリ用のサブフレームは、時間と周波数で分割した複数の無線リソースの集合である無線リソースプールとして、ｅＮＢからに割り当てられている。各ＵＥはこの無線リソースプールから、１つないし複数の無線リソースを任意に選択し、その無線リソースを用いてディスカバリ信号を送信する。
なお、以下では、無線リソースプールＰ１，Ｐ２，Ｐ３等のディスカバリ信号の送受信用に割り当てられたＬＴＥサブフレームを、「ディスカバリ用のサブフレーム」と称する。
【００６１】
特に、図３においては、１つの無線リソースで１つのアプリのディスカバリ信号が送信されるような形式を例示している。１つのディスカバリ用サブフレームにおいて、複数のユーザが複数のアプリのディスカバリ信号を送信する。例えば、図３では、ユーザａ〜ｄがアプリ＃１のディスカバリ信号を送信している。また、このリソースプールでは、各ユーザからアプリ＃１、＃２、＃３の３種類のアプリのディスカバリ信号が送信されている状態を例示している。
【００６２】
なお、規格によっては１つの無線リソースで複数のアプリのディスカバリ信号を送信することもある。あるいは、複数の無線リソースで１つのアプリのディスカバリ信号を送信する場合もある。
【００６３】
ディスカバリ受信判定部１５２２（図２）は、１つのディスカバリ用のサブフレーム中において複数のユーザすなわち複数のＵＥからのディスカバリ信号を受信した場合、ディスカバリ信号をデコードすることにより、アプリ情報を判定する。さらに、ディスカバリ受信判定部１５２２は、アプリ別のディスカバリ信号の受信回数、全てのアプリについてのディスカバリ信号の受信回数を判定する。
【００６４】
図３のディスカバリ用サブフレームをＵＥ１１が受信した場合では、アプリ＃２の受信回数が最も多く、次にアプリ＃１、アプリ＃３の順の受信回数が多かった場合を示している。この場合には、受信回数のみから判定されるアプリ優先度（優先順位）は、アプリ＃２，アプリ＃１，アプリ＃３の順となる。このように、ＵＥ１１が、ディスカバリ信号の受信回数からアプリの優先度を算出すると、同じアプリを利用するＵＥ１２等の他のＵＥにＵＥ１（自端末）を発見されやすくなる。
【００６５】
また、ディスカバリ信号用の無線リソースプールにおける無線リソースの使用割合が高い状況（無線リソースプールが混雑している状況）は、ｅＮＢ２０より割り当てられた１つの無線リソースプール（１つのディスカバリ用のサブフレーム）に含まれるディスカバリ信号数に対する、当該無線リソースプールにおける無線リソース総数の比で判定される。ＵＥ１１は、当該比が予め定められた値（たとえば５０％）以上となった場合に、「混在している（トラフィック高）」と判定する。
【００６６】
優先度設定部１５２３によって行われるアプリ優先度の設定は、上述したように、ＧＵＩによる利用者が設定する要素優先度（要素（α）のみに基づく優先度）、利用履歴による要素優先度（要素（β）のみに基づく優先度）、ディスカバリ信号の受信回数から判定した要素優先度（要素（γ）のみに基づく優先度）、およびディスカバリ信号の未送信回数に基づく要素優先度（要素（δ）のみに基づく優先度）の各々を正規化して点数で表し、各項目の和を求めることにより行われる。また、ディスカバリ信号の送信順序は、優先度の高い順とする。なお、アプリ優先度の算出の具体例については、後述する。
【００６７】
Ｄ２Ｄ管理部１５２は、送信頻度と送信タイミングとの決定に関しては、各アプリからの送信要求が１つのディスカバリ用のサブフレームで１つのＵＥから送信可能な数を超えた場合は、ディスカバリ信号を送信できたアプリのアプリ優先度を下げるとともに、送信できなかったアプリのアプリ優先度を上げる制御を行なう。これにより、次のディスカバリ用のサブフレームにおけるアプリ優先度が変化する。つまり、Ｄ２Ｄ管理部１５２は、アプリ優先度の更新をディスカバリ用のサブフレーム毎に行なう。
【００６８】
ディスカバリ用のサブフレームについて詳しく説明すると、以下のとおりである。Ｄ２Ｄ通信は、ＴＤＤ（Time Division Duplex）方式のＬＴＥと、ＦＤＤ（Frequency Division Duplex）方式のＬＴＥに適用できる。
【００６９】
ＦＤＤ方式のＬＴＥの場合には、アップリンク用のチャネルの一部のＬＴＥサブフレームをディスカバリ用に割り当てる。ＵＥ１１，１２は、当該ディスカバリ用に割り当てられたＬＴＥサブフレーム（つまり、ディスカバリ用のサブフレーム）を用いて、ｅＮＢ２０との間でディスカバリ信号の送受信を行なう。なお、ディスカバリ用のサブフレームの周期は、たとえば、１０〜２０秒などとすることができる。
【００７０】
ＴＤＤ方式のＬＴＥの場合には、アップリンク用のサブフレーム、ダウンリンク用のサブフレーム、およびＤ２Ｄ用のサブフレームが、同じ周波数において、タイムフレームで切り替えることになる。たとえば、アップリンク用のサブフレーム、ダウンリン用のサブフレーム、ディスカバリ用のサブフレーム、アップリンク用のサブフレーム、…といった順で、サブフレームの用途が切り替えられる。
【００７１】
なお、ディスカバリ用のサブフレームは、送信用と受信用との区別はない。１つのディスカバリ用のサブフレームで、ディスカバリ信号の送受信が行われる。
【００７２】
＜Ｄ．制御構造＞
【００７３】
図４は、ＵＥ１１における処理の流れの一例を表したフローチャートである。図４を参照して、ステップＳ２において、ＵＥ１１のＤ２Ｄ管理部１５２は、アプリ優先度（優先順位）の初期値を設定する。ステップＳ４において、実行中のアプリがＤ２Ｄ管理部１５２に対してディスカバリ信号の送信要求を行なう。ステップＳ６において、Ｄ２Ｄ管理部１５２は、ｅＮＢ２０から受信した制御情報から、ディスカバリ用のサブフレームのタイミングを抽出する。
【００７４】
ステップＳ８において、Ｄ２Ｄ管理部１５２は、ディスカバリ用のサブフレームのタイミングが到来したか否かを判断する。タイミングが到来したと判断された場合（ステップＳ８においてＹＥＳ）、Ｄ２Ｄ管理部１５２は、ステップＳ１０において、ディスカバリ信号の送信処理を行なう。具体的には、Ｄ２Ｄ管理部１５２は、記憶部１５２１に記憶されたデータテーブルのアプリ優先度に基づきディスカバリ信号を送信させる処理を行なう。タイミングが到来していないと判断された場合（ステップＳ８においてＮＯ）、Ｄ２Ｄ管理部１５２は、処理をステップＳ８に戻す。
【００７５】
ステップＳ１２において、Ｄ２Ｄ管理部１５２は、ディスカバリ信号の受信処理を行なう。具体的には、Ｄ２Ｄ管理部１５２は、受信したディスカバリ信号をデコードして、ProSe Application IDおよびProSe UE IDを取得する。さらに、Ｄ２Ｄ管理部１５２は、当該ディスカバリ信号に、実行中のProSe Application IDが存在している場合、ProSe Application IDを識別子として有するアプリに対して、ディスカバリ信号の受信通知を行なう。
【００７６】
ステップＳ１４おいて、Ｄ２Ｄ管理部１５２は、優先度設定部１５２３による演算処理によってアプリ優先度を再度算出することにより、アプリ優先度を更新する。ステップＳ１６において、Ｄ２Ｄ管理部１５２は、ディスカバリ信号の送信要求をしているアプリの全てについてディスカバリ信号の送信が完了したか否かを判断する。送信が完了したと判断された場合（ステップＳ１６においてＹＥＳ）、Ｄ２Ｄ管理部１５２は、一連の処理を終了する。送信が完了していないと判断された場合（ステップＳ１６においてＮＯ）、Ｄ２Ｄ管理部１５２は、処理をステップＳ８に戻す。
【００７７】
＜Ｅ．アプリ優先度の設定処理の具体例＞
【００７８】
以下では、アプリ優先度の設定処理の具体例を図５〜図８に基づいて説明する。より詳しくは、上述した要素（α）〜（δ）を全て利用する処理例を説明する。
【００７９】
（ｅ１．ある局面におけるアプリ優先度について）
【００８０】
図５は、ある局面におけるデータテーブル５００を説明するための図である。データテーブル５００は、ディスカバリ信号の送信要求をＤ２Ｄ管理部１５２に送信した各アプリについての上記各要素（α）〜（δ）についての数値と、当該要素別の当該数値の合計と、当該要素別の合計に対する各アプリの数値の比の値（以下、「要素点数」とも称する）と、アプリ毎の当該比の値の合計である合計点数とが書き込まれる。以下、要素（α）〜（δ）毎に、各要素についての数値と、当該数値の合計と、上記比の値と、上記合計点数とについて説明する。
【００８１】
（１）ＧＵＩを用いたユーザによるアプリについての要素優先度の設定（要素（α））について
【００８２】
Ｄ２Ｄ管理部１５２からの指示に基づき、ＧＵＩ部１５３は、ＵＥ１１にインストールされているアプリ＃１，＃２，＃３，…のリストを表示部１５３１に表示するとともに、アプリ毎に要素優先度を高または低で選択するためのＧＵＩを設定する。また、ＵＥ１１のユーザが設定しなかったものは未設定としておく。なお、各アプリのＤ２Ｄの対応状況およびディスカバリ信号の送受状況を表示するように、ＧＵＩを構成としてもよい。
【００８３】
要素優先度の計算法として、一例として、ユーザが、各アプリ＃１，＃２，＃３の要素優先度を、それぞれ、「高」、「低」、「未設定」と設定したとすると、各アプリ＃１，＃２，＃３の点数（要素優先度）は、それぞれ、「６点」、「１点」、「３点」となる。
【００８４】
Ｄ２Ｄ管理部１５２の優先度設定部１５２３は、要素（α）についての点数の合計を算出する。この場合、合計は、１０点（＝６＋１＋３）となる。優先度設定部１５２３は、要素（α）の合計（１０点）に対する各アプリの数値（つまり、６，１，３）の比の値（要素点数）を算出し、データテーブル５００に算出結果を書き込む。具体的には、優先度設定部１５２３は、算出結果である、「０．６」と「０．１」と「０．３」とを、対応するアプリに関連付けた状態でデータテーブル５００に書き込む。
【００８５】
（２）アプリの利用履歴（要素（β））について
【００８６】
Ｄ２Ｄ管理部１５２は、たとえば過去一週間において、ディスカバリ信号の送受信後にＤ２Ｄ通信を行った回数、あるいは、ディスカバリ信号を受信してクーポン情報および相手のＵＥの端末情報等をアプリ上で利用した回数をカウントする。具体的には、Ｄ２Ｄ管理部１５２は、データテーブル５００の数値をインクリメントすることにより、上記の回数をカウントする。
【００８７】
優先度設定部１５２３は、全てのアプリについて、回数の合計を計算する。この場合、合計は、２０（＝１３＋５＋２）となる。優先度設定部１５２３は、要素（β）の合計（２０点）に対する各アプリの回数（つまり、１３，５，２）の比の値（要素点数）を算出し、データテーブル５００に算出結果を書き込む。具体的には、優先度設定部１５２３は、算出結果である、「０．６５」と「０．２５」と「０．１」とを、対応するアプリに関連付けた状態でデータテーブル５００に書き込む。
【００８８】
（３）ディスカバリ信号の受信回数（要素（γ））について
【００８９】
Ｄ２Ｄ管理部１５２は、一定期間（たとえば、１つのディスカバリ用のサブフレーム中）における、他のＵＥから受信したディスカバリ信号に含まれるProSe Application IDを抽出する。さらに、Ｄ２Ｄ管理部１５２は、当該抽出されたProSe Application IDで特定されるアプリ毎に上記ディスカバリ信号の受信回数をカウントする。具体的には、Ｄ２Ｄ管理部１５２は、データテーブル５００の数値をインクリメントすることにより、上記受信回数をカウントする。
【００９０】
優先度設定部１５２３は、全てのアプリについて、回数の合計を計算する。この場合、合計は、５０（＝２５＋５＋２０）となる。優先度設定部１５２３は、要素（γ）の合計（５０点）に対する各アプリの回数（つまり、２５，５，２０）の比の値（要素点数）を算出し、データテーブル５００に算出結果を書き込む。具体的には、優先度設定部１５２３は、算出結果である、「０．５」と「０．１」と「０．４」とを、対応するアプリに関連付けた状態でデータテーブル５００に書き込む。
【００９１】
（４）ディスカバリ信号の未送信回数（要素（δ））について
【００９２】
Ｄ２Ｄ管理部１５２は、各アプリがディスカバリ信号の送信要求を上げているにもかかわらずディスカバリ信号を送信できなかった場合における、ディスカバリ信号の未送信回数をデータテーブル５００に蓄積する。具体的には、Ｄ２Ｄ管理部１５２は、全てのアプリについて、ディスカバリ信号の未送信回数を、データテーブル５００に書き込む。図５では、全てのアプリ＃１，＃２，＃３の各々の未送信回数が０回であるため、デフォルト値である“０”から更新（インクリメント）がなされていない。
【００９３】
なお、典型的には、Ｄ２Ｄ管理部１５２は、ディスカバリ信号を送信できたときは、ディスカバリ信号の送信要求を行なったアプリに対応付けられた未送信回数を０とすることが好ましい。
【００９４】
（５）アプリ優先度の算出
【００９５】
以下では、説明の便宜上、一定期間（時間）内（具体的には、一周期内）に送信可能なディスカバリ信号は、２つのアプリのディスカバリ信号であるとする。つまり、具体的には、ＵＥ１１は、１つのディスカバリ用のサブフレームにおいて、２つのアプリのディスカバリ信号を送信可能であるとする。なお、実際には、Ｄ２Ｄ通信のディスカバリ信号用のフレーム構成、１台のＵＥあたりに割り当てられる無線リソース数、１つの無線リソースあたりの伝送速度、ディスカバリ信号のデータ量、下位層での再送制御回数等で、送信可能なディスカバリ信号の数が決定されるが、ここでは一例として上記の条件で説明する。
【００９６】
現在、３つのアプリ＃１，＃２，＃３がＤ２Ｄ通信を希望しているとする。この場合、優先度設定部１５２３は、３つのアプリ＃１，＃２，＃３についての上記各要素（α）〜（δ）の要素優先度の算出に基づき、アプリ優先度（全体の優先度）を求める。典型的には、優先度設定部１５２３は、アプリ毎に、要素（α）〜（δ）の点数の総和である合計点数を算出する。図５の場合、アプリ＃１，＃２，＃３の合計点数が、それぞれ、「１．７５」、「０．４５」、「０．８」となっている状態を表している。
【００９７】
Ｄ２Ｄ管理部１５２では、合計点数が高いものほどアプリ優先度が高くなるように設定されているため、Ｄ２Ｄ管理部１５２は、合計点数が高いアプリから順に、優先的にディスカバリ信号を送信させる処理を行なう。
【００９８】
上記の場合、優先度設定部１５２３は、アプリ＃１の優先度を最も高く設定（優先順位を１位に設定）し、次いで、アプリ＃３、アプリ＃２の順に優先度を低く設定する。詳しくは、ＵＥ１１は、ディスカバリ信号の送受信タイミングになったとき、記憶部１５２１に記憶されたデータテーブル５００の総合点数の高いものから順に（つまり、優先度の高い順）に、ディスカバリ信号を送信する。上記の条件に基づけば、１つのディスカバリ用のサブフレームにおいて２つのアプリのディスカバリ信号が送信可能であるため、ＵＥ１１は、アプリ＃１のディスカバリ信号と、アプリ＃３のディスカバリ信号とが、直近の１つのディスカバリ用のサブフレームを用いて送信する。
【００９９】
（ｅ２．アプリ優先度の更新）
【０１００】
次に、アプリ優先度の更新について説明する。優先度設定部１５２３は、ディスカバリ信号の送信要求を上げているにもかかわらずディスカバリ信号を送信できなかったアプリ＃２についての要素（δ）の値をインクリメントする。つまり、アプリ＃２におけるディスカバリ信号の未送信回数を、「０」から「１」に変更することにより、要素（δ）についての要素優先度を上げる。
【０１０１】
また、ＵＥ１１のＤ２Ｄ管理部１５２は、新たに他のＵＥからディスカバリ信号を受信していれば、要素（γ）の要素優先度を更新する。つまり、Ｄ２Ｄ管理部１５２は、ディスカバリ信号の受信回数を更新する。さらに、Ｄ２Ｄ管理部１５２は、要素（α），（β）についても、逐次更新を行なう。
【０１０２】
図６は、図５の状態（第１の状態）の後のある局面におけるデータテーブル５００を説明するための図である。図６を参照して、図６の状態（第２の状態）は、図５の状態を基準とすると、要素（α），（β）の要素優先度（つまり、ＧＵＩによる設定内容および利用回数）に変更がなく、要素（γ）のディスカバリ信号の受信回数と、要素（δ）のディスカバリ信号の未送信回数が変更となった状態を表している。
【０１０３】
この場合、優先度設定部１５２３は、各要素（α）〜（δ）について、各アプリ＃１，＃２，＃３の要素点数（上述した比の値）を算出する。さらに、優先度設定部１５２３は、算出された要素点数に基づき、各アプリ＃１，＃２，＃３毎に、合計点数を再度算出する。優先度設定部１５２３は、当該算出された合計点数が高いものから順に、優先度を高く設定する。このように優先度（優先順位）が変更されると、次のディスカバリ用のサブフレームの送信タイミングでは、ＵＥ１１は、アプリ＃１のディスカバリ信号とアプリ＃２のディスカバリ信号とを送信する。
【０１０４】
上記のディスカバリ信号の送信が行われると、Ｄ２Ｄ管理部１５２は、優先度の次の更新のために、アプリ＃３の要素（δ）の値をインクリメントする。つまり、アプリ＃３におけるディスカバリ信号の未送信回数を、「０」から「１」に変更することにより、要素（δ）についての要素優先度を上げる。また、その後、一例として、次のディスカバリ用のサブフレームの送信タイミング迄に、新たなアプリ＃４がディスカバリ信号の送信要求をＤ２Ｄ管理部１５２に上げたものとする。
【０１０５】
図７は、アプリ＃４がディスカバリ信号の送信要求をＤ２Ｄ管理部１５２に上げた後のデータテーブル５００を説明するための図である。図７を参照して、アプリ＃３におけるディスカバリ信号の未送信回数が「０」から「１」に更新されている。また、要素（α）〜（δ）の各々について、アプリ＃４の要素点数として、初期値“０”が与えられる。
【０１０６】
優先度設定部１５２３は、上述した方法で、各アプリ＃１〜＃４の要素点数および合計点数を算出し、当該合計点数に基づき優先度を算出する。この場合、アプリ＃３の優先度が最も高く、次いで、アプリ＃１の優先度が高くなる。つまり、アプリ＃３の優先順位が１位となり、アプリ＃１の優先順位が２位となる。このように優先度（優先順位）が変更されると、ＵＥ１１は、次のディスカバリ用のサブフレームにおいて、アプリ＃３のディスカバリ信号と、アプリ＃１のディスカバリ信号とを送信する。
【０１０７】
上記のディスカバリ信号の送信が行われると、Ｄ２Ｄ管理部１５２は、優先度の次の更新のために、アプリ＃２，＃４の要素（δ）の値をインクリメントする。つまり、アプリ＃２，＃４におけるディスカバリ信号の未送信回数を、「０」から「１」に変更することにより、要素（δ）についての要素優先度を上げる。さらに、その後、一例として、次のディスカバリ用のサブフレームの送信タイミング迄に、アプリ＃４のディスカバリ信号の受信回数が１５回となっているものとする。
【０１０８】
図８は、アプリ＃４のディスカバリ信号の受信回数が１５回となった後のデータテーブル５００を説明するための図である。図８を参照して、アプリ＃２，＃４におけるディスカバリ信号の未送信回数が「０」から「１」に更新されている。
【０１０９】
優先度設定部１５２３は、上述した方法で、各アプリ＃１〜＃４の要素点数および合計点数を算出し、当該合計点数に基づき優先度を算出する。この場合、アプリ＃１の優先度が最も高く、次いで、アプリ＃４の優先度が高くなる。つまり、アプリ＃１の優先順位が１位となり、アプリ＃４の優先順位が２位となる。このように優先度（優先順位）が変更されると、ＵＥ１１は、次のディスカバリ用のサブフレームにおいて、アプリ＃１のディスカバリ信号と、アプリ＃４のディスカバリ信号とを送信する。
【０１１０】
以上、図５〜図８に基づいて説明したように、ＵＥ１１は、優先度を逐次更新する。
【０１１１】
＜Ｆ．通信システム１の利点＞
【０１１２】
ＵＥ１１は、ディスカバリ信号を送信するアプリとしてアプリ優先度の高いアプリが特定できる。さらに、ＵＥ１１は、当該特定されたアプリのディスカバリ信号を他のアプリのディスカバリ信号よりも優先して、相手のＵＥに送信可能となる。その結果、優先度の高いアプリのディスカバリ信号が他のＵＥ（通信相手）によって検出されないといった事態の発生を低減することができる。
【０１１３】
ディスカバリ信号用に割り当てられた無線リソースプールの利用度（混雑状況）が高い場合（トラフィックが増加した場合）には、ディスカバリ信号がぶつかる確率が高い。それゆえ、ＵＥ１１は、特に、このような状況においてアプリ優先度を用いた処理を行なうことにより、効率的に優先度の高いアプリのディスカバリ信号を通信相手に検出してもらうことができる。
【０１１４】
＜Ｇ．ハードウェア構成＞
【０１１５】
図９は、ＵＥ１１のハードウェア構成を説明するための図である。図９を参照して、ＵＥ１１は、アプリ＃１，＃２，＃３…等を含む各種プログラムを実行するＣＰＵ１０１と、ＲＯＭ（Read Only Memory）１０２と、ＲＡＭ（Random Access Memory）１０３と、フラッシュメモリ１０４と、操作キー１０５と、スピーカ１０６と、カメラ１０７と、タッチスクリーン１０８と、無線通信ＩＦ（Interface）１０９と、アンテナ１１０と、リーダライタ１１１とを、少なくとも含んで構成されている。タッチスクリーン１０８は、ディスプレイ１０８１と、タッチパネル１０８２とを含む。各構成要素１０１〜１０９，１１１は、相互にデータバスによって接続されている。
【０１１６】
リーダライタ１１１は、メモリカード９００が装着可能であって、メモリカード９００に情報を記録あるいはメモリカード９００から情報を読み出す。
【０１１７】
アンテナ１１０は、無線通信ＩＦ１０９に接続されている。アンテナ１１０および無線通信ＩＦ１０９は、たとえば、ｅＮＢを介した、他のＵＥ、固定電話、およびＰＣ（Personal Computer）との間における無線通信に用いられる。
【０１１８】
ＲＯＭ１０２は、不揮発性の半導体メモリである。ＲＯＭ１０２は、ＵＥ１１のブートプログラムが予め格納されている。フラッシュメモリ１０４は、不揮発性の半導体メモリである。フラッシュメモリ１０４は、一例としてＮＡＮＤ型で構成してもよい。フラッシュメモリ１０４は、ＵＥ１１のオペレーティングシステム、ＵＥ１１を制御するための各種のプログラム、並びに、ＵＥ１１が生成したデータ、ＵＥ１１の外部装置から取得したデータ等の各種データを揮発的に格納する。
【０１１９】
ＵＥ１１における処理は、各ハードウェアおよびＣＰＵ１０１により実行されるソフトウェアによって実現される。このようなソフトウェアは、フラッシュメモリ１０４に予め記憶されている場合がある。また、ソフトウェアは、メモリカード９００その他の記憶媒体に格納されて、プログラムプロダクトとして流通している場合もある。あるいは、ソフトウェアは、いわゆるインターネットに接続されている情報提供事業者によってダウンロード可能なプログラムプロダクトとして提供される場合もある。このようなソフトウェアは、アンテナ１１０および無線通信ＩＦ１０９を介してダウンロードされた後、フラッシュメモリ１０４に一旦格納される。そのソフトウェアは、ＣＰＵ１０１によってフラッシュメモリ１０４から読み出され、さらにフラッシュメモリ１０４に実行可能なプログラムの形式で格納される。ＣＰＵ１０１は、そのプログラムを実行する。
【０１２０】
本発明の本質的な部分は、フラッシュメモリ１０４その他の記憶媒体に格納されたソフトウェア、あるいはネットワークを介してダウンロード可能なソフトウェアであるともいえる。なお、記録媒体としては、ＤＶＤ-ＲＯＭ、ＣＤ−ＲＯＭ、ＦＤ、ハードディスク
に限られず、磁気テープ、カセットテープ、光ディスク、光カード、マスクＲＯＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、フラッシュＲＯＭなどの半導体メモリ等の固定的にプログラムを担持する媒体でもよい。また、記録媒体は、当該プログラム等をコンピュータが読取可能な一時的でない媒体である。また、ここでいうプログラムとは、ＣＰＵにより直接実行可能なプログラムだけでなく、ソースプログラム形式のプログラム、圧縮処理されたプログラム、暗号化されたプログラム等を含む。
【０１２１】
なお、ＵＥ１２のハードウェア構成は、ＵＥ１１と同じであるため、ここでは繰り返し説明はしない。
【０１２２】
今回開示された実施の形態は例示であって、上記内容のみに制限されるものではない。本発明の範囲は特許請求の範囲によって示され、特許請求の範囲と均等の意味および範囲内でのすべての変更が含まれることが意図される。
【符号の説明】
【０１２３】
１  通信システム、１０１  ＣＰＵ、１０４  フラッシュメモリ、１０５  操作キー、１０８  タッチスクリーン、１１１  リーダライタ、１５１  アプリ実行部、１５２  Ｄ２Ｄ管理部、１５３  ＧＵＩ部、１５４，１５２１  記憶部、１５５  受信部、１５６  送信部、５００  データテーブル、９００  メモリカード、１０８１  ディスプレイ、１０８２  タッチパネル、１５２２  ディスカバリ受信判定部、１５２３  優先度設定部、１５２４  ディスカバリ送信制御部、１５３１  表示部、１５３２  入力部、１５５１  ディスカバリ信号受信部、１５６１  ディスカバリ信号送信部。
【図１】
2016116160.tif 000003
【図２】
2016116160.tif 000004
【図３】
2016116160.tif 000005
【図４】
2016116160.tif 000006
【図５】
2016116160.tif 000007
【図６】
2016116160.tif 000008
【図７】
2016116160.tif 000009
【図８】
2016116160.tif 000010
【図９】
2016116160.tif 000011