JP2014223188A - 通信端末、プログラム、通信端末の制御方法及び通信システム - Google Patents

Abstract

【課題】通信端末間で移動させられる実行権限の変化を、ユーザに視覚的に把握させる。
【解決手段】ユーザ端末１０ａ，１０ｂは、キャラクタのレベルに応じてクリアすることのできるイベントが変化するゲームを進行させる。はじめ、ユーザ端末１０ａのキャラクタ１００のレベルが「２０」であり、ユーザ端末１０ｂのキャラクタ２００のレベルが「６」である。ユーザ端末１０ａは、キャラクタ１００を、レベルが「１０」のキャラクタ１１０，１２０に分割し、キャラクタ１２０をユーザ端末１０ｂに移動させる。ユーザ端末１０ｂは、ユーザ端末１０ａから移動してきたキャラクタ１１０と、キャラクタ２００とを合体させて、レベルが「１６」のキャラクタ２１０に変化させる。ユーザ端末１０ｂでは、キャラクタ同士を合体させることにより、イベントをクリアするようにゲームを進行させる処理の実行権限を得たことになる。
【選択図】図７

Description

本発明は、ライセンス等の特定の処理の実行権限を管理する技術に関する。

ライセンス等の特定の処理の実行権限を端末間で移動させる技術が、特許文献１，２に開示されている。特許文献１は、ライセンス管理システムでソフトウェアのライセンスが管理されている各機器間で、導入済のソフトウェアのライセンスを他の機器に移動するための仕組みを開示している。特許文献２は、鍵の交換により複数のデバイス間でセキュア認証チャネルが確立された場合に、これらのデバイス間でライセンスを移動させることを開示している。

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

通信端末間で実行権限を移動させる場合に、その移動により実行権限がどのように変化したかを通信端末のユーザが把握しやすい方法で表現できると都合が良い。
そこで、本発明の目的は、通信端末間で移動させられる実行権限の変化を、ユーザに視覚的に把握させることである。

上述した課題を解決するため、本発明の通信端末は、画像を表示する表示部と、自端末に与えられた特定の処理の実行権限に対応した権限データを記憶する権限データ記憶部と、前記権限データ記憶部に記憶された権限データに基づいて、前記実行権限を示すキャラクタを前記表示部に表示させる表示制御部と、前記キャラクタ又は前記実行権限を自端末と他端末との間で移動させる通信を行って、前記権限データを更新する移動制御部とを備え、前記表示制御部は、前記移動制御部により前記権限データが更新されると、前記表示部に表示させるキャラクタを変化させる。

本発明の通信端末において、前記表示制御部は、前記表示部に表示されているキャラクタを、各々が前記実行権限の一部に関連付けられた複数の第１のキャラクタに変化させ、前記移動制御部は、前記複数の第１のキャラクタの少なくとも一部を前記他端末に移動させる通信を行うようにしてもよい。
本発明の通信端末において、前記移動制御部は、所定の前記実行権限に関連付けられた第２のキャラクタを前記他端末から自端末に移動させる通信を行い、前記表示制御部は、前記表示部に表示されているキャラクタを、前記第２のキャラクタに基づいて第３のキャラクタに変化させるようにしてもよい。

本発明の通信端末において、前記権限データは、前記キャラクタを使用するゲームの進行状況を示すデータであり、前記ゲームを進行させる処理を行って、前記キャラクタの容姿に応じて実行権限が変化する前記特定の処理を実行する処理実行部を備え、前記表示制御部は、前記ゲームの進行に応じて前記キャラクタの容姿を変化させるようにしてもよい。
本発明の通信端末において、前記特定の処理は、ゲームを進行させる処理以外の処理であるようにしてもよい。

本発明の通信端末において、前記表示制御部は、前記権限データが更新されると、前記表示部に表示されるキャラクタの構成要素を変化させ、前記移動制御部は、前記構成要素に応じて変化する前記実行権限を移動させる通信を行うようにしてもよい。
本発明の通信端末において、前記表示制御部は、前記特定の処理の実行実績に応じて前記キャラクタを変化させるようにしてもよい。

本発明のプログラムは、自端末に与えられた特定の処理の実行権限に対応した権限データを記憶する権限データ記憶部を有する通信端末のコンピュータに、前記権限データ記憶部に記憶された権限データに基づいて、前記実行権限を示すキャラクタを、画像を表示する表示部に表示させる第１ステップと、前記キャラクタ又は前記実行権限を自端末と他端末との間で移動させる通信を行って、前記権限データを更新する第２ステップと、前記第２ステップで前記実行権限が変化させられると、前記第１ステップで表示した前記キャラクタを変化させる第３ステップとを実行させるためのプログラムである。

本発明の通信端末の制御方法は、前記通信端末に与えられた特定の処理の実行権限を示すキャラクタを表示する第１ステップと、前記キャラクタ又は前記実行権限を前記通信端末と他端末との間で移動させる通信を行って、前記実行権限を変化させる第２ステップと、前記第２ステップで前記実行権限が変化させられると、前記第１ステップで表示した前記キャラクタを変化させる第３ステップとを有する通信端末の制御方法である。

本発明の通信システムは、複数の通信端末とサーバ装置とを備える通信システムであって、前記複数の通信端末の各々が、画像を表示する表示部と、自端末に与えられた特定の処理の実行権限に対応した権限データを記憶する権限データ記憶部と、前記権限データ記憶部に記憶された権限データに基づいて、前記実行権限を示すキャラクタを前記表示部に表示させる表示制御部と、前記キャラクタ又は前記実行権限を自端末と他の前記通信端末との間で移動させる通信を、前記サーバ装置経由で行って、前記権限データを更新する移動制御部とを有し、前記表示制御部は、前記移動制御部により前記権限データが更新されると、前記表示部に表示させるキャラクタを変化させ、前記サーバ装置が、前記キャラクタと前記通信端末に実行権限を与える処理との関係を定めたデータベースと、前記データベースを参照して、前記複数の通信端末の各々に与える前記実行権限を管理する権限管理部と、前記複数の通信端末の各々と通信して、前記キャラクタ又は前記実行権限を移動させる通信を仲介する通信制御部とを有する。

本発明によれば、通信端末間で移動させられる実行権限の変化を、ユーザに視覚的に把握させることができる。

本発明の第１実施形態に係る通信システムの全体構成を示す図。 同実施形態に係るユーザ端末のハードウェア構成を示すブロック図。 同実施形態に係る管理サーバのハードウェア構成を示すブロック図。 同実施形態に係る端末情報管理ＤＢの構成例を示す図。 同実施形態に係る通信システムの機能構成を示す機能ブロック図。 同実施形態に係る通信システムにおける処理の流れを示すシーケンス図。 同実施形態に係るユーザ端末で表示される画面を説明する図。 同実施形態に係る通信システムにおける処理の流れを示すシーケンス図。 本発明の第２実施形態に係る端末情報管理ＤＢの構成例を示す図。 同実施形態に係る実行権限管理ＤＢの構成例を示す図。 同実施形態に係るユーザ端末で表示される画面を説明する図。 同実施形態に係る通信システムにおける処理の流れを示すシーケンス図。 同実施形態に係るユーザ端末で表示される画面を説明する図。 同実施形態に係る通信システムにおける処理の流れを示すシーケンス図。 同実施形態に係るユーザ端末で表示される画面を説明する図。 本発明の第３実施形態に係る端末情報管理ＤＢの構成例を示す図。 同実施形態に係る実行権限管理ＤＢの構成例を示す図。 同実施形態に係るユーザ端末で表示される画面を説明する図。 同実施形態に係るユーザ端末で表示される画面を説明する図。 同実施形態に係る通信システムにおける処理の流れを示すシーケンス図。 同実施形態に係るユーザ端末で表示される画面を説明する図。

以下、図面を参照しつつ本発明の実施形態を説明する。
［第１実施形態］
図１は、本発明の第１実施形態の通信システム１の全体構成を示す図である。図１に示すように、通信システム１は、複数のユーザ端末１０と、管理サーバ２０とを備える。複数のユーザ端末１０及び管理サーバ２０の各々は、ネットワーク１００に接続可能である。ネットワーク１００は、例えば、移動通信網、ゲートウェイ及びインターネットを含む通信網である。

ユーザ端末１０は、ユーザがゲーム（ビデオゲーム）をプレイする際に使用する通信端末である。ユーザ端末１０が進行させるゲームは、ここではロールプレイングゲームである。ロールプレイングゲームは、ゲームに登場するキャラクタが操作されることによって進行させられる。ユーザ端末１０は、ここではスマートフォンである。ただし、ユーザ端末１０は、携帯電話端末、タブレット端末、ノート型パソコン、ＰＤＡ（Personal Digital Assistant）、携帯型ゲーム機等の他の通信端末であってもよい。
図１には、通信システム１に含まれるユーザ端末１０として、ユーザ端末１０ａ，１０ｂ及び１０ｃの３つを図示している。ユーザ端末１０ａ，１０ｂ及び１０ｃは、それぞれ異なるユーザによって所有される。図１には、ユーザ端末１０のうち、ユーザ端末１０ａ，１０ｂ及び１０ｃの３つのみを示すが、ユーザ端末１０は実際にはより多数存在する。

管理サーバ２０は、通信事業者やコンテンツプロバイダ等のサービス提供者によって管理されるサーバ装置である。管理サーバ２０は、ユーザ端末１０が進行させるゲームに関するサービスを、ネットワーク１００経由でユーザ端末１０に提供する。管理サーバ２０は、互いに異なるユーザ端末１０間でゲームで使用されるキャラクタを移動させるためのサービスを提供する。

図２は、ユーザ端末１０のハードウェア構成を示すブロック図である。図２に示すように、ユーザ端末１０は、制御部１１と、操作部１２と、通信部１３と、表示部１４と、記憶部１５とを備える。
制御部１１は、ＣＰＵ（Central Processing Unit）、ＲＯＭ(Read Only Memory)及びＲＡＭ（Random Access Memory）を有するマイクロコンピュータを備える。ＣＰＵは、ＲＯＭや記憶部１５に記憶されたプログラムをＲＡＭに読み出して実行することにより、ユーザ端末１０の各部を制御する。操作部１２は、ユーザによって入力された操作を受け付ける操作装置であり、例えば、表示部１４の表示面に重ねて設けられたタッチスクリーンや物理キーを有する。ユーザ端末１０が、ユーザの発する声を認識して音声入力操作を受け付ける場合には、操作部１２は収音用のマイクロホンを備えてもよい。通信部１３は、ネットワーク１００に接続して通信するためのインタフェースである。

表示部１４は、ＶＲＡＭ１４１を備え、表示データがＶＲＡＭ１４１に記憶されると、その表示データを読み出して画像を表示する表示装置である。すなわち、ＶＲＡＭ１４１は、表示部１４で表示している画像を表示するための表示データを記憶する。

記憶部１５は、例えばＥＥＰＲＯＭ（Electronically Erasable and Programmable ROM）やフラッシュメモリ等の記憶装置を備え、制御部１１により実行されるプログラムを記憶する。また、記憶部１５は、キャラクタ表示アプリ１５１及び権限データ１５２を記憶する。キャラクタ表示アプリ１５１は、表示部１４にキャラクタを表示するためのアプリケーションプログラムであり、本実施形態では、ゲームを進行させるためのアプリケーションプログラムである。

権限データ１５２は、ゲームにおける特定の処理の実行権限に対応するデータであり、本実施形態では、ゲームの進行状況を示すデータである。権限データ１５２は、例えば、キャラクタのレベルや、ゲームをどこまで進行させたかを表すデータを含む。キャラクタのレベルは、そのキャラクタの成長度合いを示すパラメータである。本実施形態のゲームでは、キャラクタのレベルに応じて、ゲームにおける特定のイベントをクリアする処理の実行可否が異なったり、ゲームにおける特定のイベントを発生させる処理の実行可否が異なったりする。例えば、キャラクタレベルが「１０」以上であれば、ゲームにおける所定の扉を開けるイベントをクリアすることができるが、キャラクタレベルが「１０」で未満であれば、このイベントをクリアすることができない、という具合である。

図３は、管理サーバ２０のハードウェア構成を示すブロック図である。図３に示すように、管理サーバ２０は、制御部２１と、通信部２２と、記憶部２３とを備える。
制御部２１は、ＣＰＵ、ＲＯＭ及びＲＡＭを有するマイクロコンピュータを備える。ＣＰＵは、ＲＯＭや記憶部２３に記憶されたプログラムをＲＡＭに読み出して実行することにより、管理サーバ２０の各部を制御する。通信部２２は、ネットワーク１００に接続して通信するためのインタフェースである。記憶部２３は、例えばハードディスク装置を有する記憶装置であり、制御部２１により実行されるプログラム及び端末情報管理ＤＢ（Data Base）２３１を記憶する。端末情報管理ＤＢ２３１は、ユーザに所有されるユーザ端末１０に関する情報を格納したデータベースである。
なお、図３には、記憶部２３のブロックの破線枠内に「実行権限管理ＤＢ２３２」と付しているが、この実施形態には関係のないデータベースであり、ここではその説明を省略する。

図４は、端末情報管理ＤＢ２３１の構成例を示す図である。図４に示すように、端末情報管理ＤＢ２３１は、「端末ＩＤ」と、「キャラクタレベル」とを対応付けたデータベースである。
端末情報管理ＤＢ２３１の「端末ＩＤ」は、ユーザ端末１０の個体を識別する端末識別情報である。端末ＩＤは、１つのユーザ端末１０に対して１つだけ割り当てられる。ここでは、端末ＩＤ「ＭＩＤ−ａ」は、ユーザ端末１０ａを識別する端末ＩＤである。端末ＩＤ「ＭＩＤ−ｂ」は、ユーザ端末１０ｂを識別する端末ＩＤである。端末ＩＤ「ＭＩＤ−ｃ」は、ユーザ端末１０ｃを識別する端末ＩＤである。
なお、本実施形態の端末ＩＤは、ユーザ端末２０のユーザを識別するユーザ識別情報（ユーザＩＤ）に置き換えられ、又は、組み合わされてもよい。

端末情報管理ＤＢ２３１の「キャラクタレベル」は、各ユーザ端末１０で進行させられているゲームにおけるキャラクタのレベルである。図４に示す例では、ユーザ端末１０ａにおけるキャラクタのレベルが「２０」であり、ユーザ端末１０ｂにおけるキャラクタのレベルが「６」であり、ユーザ端末１０ｃにおけるキャラクタレベルが「１２」である。管理サーバ２０は、権限データ１５２に基づいてユーザ端末１０からキャラクタのレベルが通知されると、通知されたキャラクタのレベルを端末情報管理ＤＢ２３１に書き込む。

図５は、ユーザ端末１０の制御部１１及び管理サーバ２０の制御部２１における機能構成を示す機能ブロック図である。ユーザ端末１０の制御部１１は、キャラクタ表示アプリ１５１を実行することにより、受付部１１１と、表示制御部１１２と、処理実行部１１３と、移動制御部１１４とに相当する機能を実現する。
受付部１１１は、操作部１２に対してユーザにより行われた操作を示す操作信号を取得することにより、ユーザ端末１０のユーザにより行われた操作を受け付ける。

表示制御部１１２は、ＶＲＡＭ１４１に表示データを記憶させて、記憶させた表示データが表す画像を表示部１４に表示させる。例えば、表示制御部１１２は、権限データ１５２に対応する実行権限を示すキャラクタを、表示部１４に表示させる。このキャラクタは、いわば、権限データ１５２に対応する実行権限を象徴するキャラクタである。本実施形態のゲームにおいて、キャラクタは、レベルに応じて容姿が変化する。ここでいう容姿は、キャラクタの顔や装飾、大きさ、色等であるが、容姿が変化した場合に、ユーザがその変化を判別できる要素を含んでいればよい。
なお、全レベルでキャラクタの容姿がそれぞれ異ならなくてもよく、例えば、レベルが所定数（例えば２）上がる毎にキャラクタの容姿が変化してもよい。

処理実行部１１３は、権限データ１５２によって実行権限が与えられた特定の処理を実行する。キャラクタのレベルに応じて実行権限が変化するから、処理実行部１１３は、キャラクタの容姿に応じて実行権限が変化する特定の処理を実行する、といって差し支えない。キャラクタと実行権限との対応関係は予め決められていて、この対応関係は、例えば、キャラクタ表示アプリ１５１で規定されている。例えば、処理実行部１１３は、キャラクタのレベルが、ゲームにおける特定のイベントをクリアするための条件を満たす場合には、そのイベントをクリアする処理を実行し、キャラクタのレベルがこの条件を満たさない場合には、イベントをクリアする処理を実行しない。

移動制御部１１４は、キャラクタ又は実行権限を自端末と他のユーザ端末１０との間で移動させる通信を、通信部１３を用いて行って、権限データ１５２を更新する。表示制御部１１２は、移動制御部１１４により権限データ１５２が更新されると、表示部１４に表示させるキャラクタを変化させる。
第１に、表示制御部１１２は、表示部１４に表示されているキャラクタを、各々が実行権限の一部に関連付けられた複数のキャラクタ（第１のキャラクタ）に変化させる。例えば、表示制御部１１２は、１体のキャラクタを、複数体のキャラクタに分割するように改変する。そして、移動制御部１１４は、その変化後の複数のキャラクタの少なくとも一部を他端末に移動させる通信を行う。第２に、移動制御部１１４は、所定の実行権限に関連付けられたキャラクタ（第２のキャラクタ）を他のユーザ端末２０から自端末に移動させる通信を行う。そして、表示制御部１１２は、表示部１４に表示されているキャラクタを、自端末に移動してきたキャラクタに基づいて、他のキャラクタ（第３のキャラクタ）に変化させる。例えば、表示制御部１１２は、複数体のキャラクタを、１体のキャラクタに合体させるように改変する。キャラクタが変化させられた場合、その変化前のキャラクタとレベルが異なる新たなキャラクタが生成されることとなる。

管理サーバ２０の制御部２１は、権限管理部２１１と、通信制御部２１２とに相当する機能を実現する。
権限管理部２１１は、端末情報管理ＤＢ２３１に基づいて、ユーザ端末１０の各々に与える実行権限を管理する。例えば、権限管理部２１１は、通信部２２の通信により、ユーザ端末１０から権限データ１５２に含まれるデータが取得されると、このデータに応じて端末情報管理ＤＢ２３１を更新する。
通信制御部２１２は、通信部２２を介したユーザ端末１０との通信を制御する。通信制御部２１２は、例えば、複数のユーザ端末１０間でキャラクタ又は実行権限が移動させられる場合に、この移動に要する通信を仲介する。

図６は、ユーザ端末２０間でキャラクタが移動するときの通信システム１での処理の流れを示すシーケンス図である。図７は、ユーザ端末１０で表示されるキャラクタ及び端末情報管理ＤＢ２３１を説明する図である。以下、ユーザ端末１０ａからユーザ端末１０ｂにキャラクタを移動させる場合の通信システム１の動作を説明する。
キャラクタが移動させられる前は、図４に示したとおり、ユーザ端末１０ａのキャラクタのレベルは「２０」であり、ユーザ端末１０ｂのキャラクタのレベルは「６」である。よって、ユーザ端末１０ａでは、図７（ａ）に示すキャラクタ１００を含むゲーム画面を表示する。ユーザ端末１０ｂでは、図７（ｂ）に示すキャラクタ２００を含むゲーム画面を表示する。キャラクタ１００のレベルと、キャラクタ２００のレベルとは異なるので、キャラクタ１００の容姿とキャラクタ２００の容姿とは異なる。ここでは、レベルの高いキャラクタ１００の方が、キャラクタ２００よりもサイズが大きい。

まず、ユーザ端末１０ａは、自端末のキャラクタの他端末への移動を指示する操作を受け付ける（ステップＳ１）。ここでは、ユーザ端末１０ａは、キャラクタを２つに分割して、そのうちの一方を移動させることを指示する操作を受け付ける。この際、ユーザ端末１０ａは、分割したキャラクタの移動先（ここではユーザ端末１０ｂ）を指定する操作を少なくとも受け付ける。
ここでは、キャラクタのレベルを１／２ずつに分けて、２つのキャラクタ（ここでは、レベル１０）が生成されるものとするが、各キャラクタのレベルはどのように決められてもよい。例えば、分割後の各キャラクタのレベルをユーザが指定してもよい。

次に、ユーザ端末１０ａは、ステップＳ１の処理で操作を受け付けたことを示す通知を、管理サーバ２０に宛てて送信する（ステップＳ２）。管理サーバ２０は、この通知を受信すると、受信した通知に応じて端末情報管理ＤＢ２３１を更新する（ステップＳ３）。ここでは、管理サーバ２０は、端末情報管理ＤＢ２３１において端末ＩＤ「ＭＩＤ−ａ」に対応付けられたキャラクタレベルを、キャラクタ１００のレベルである「２０」から、その１／２である「１０」に更新する。また、管理サーバ２０は、端末情報管理ＤＢ２３１において端末ＩＤ「ＭＩＤ−ｂ」に対応付けられたキャラクタレベルを、キャラクタ２００のレベル「６」と、キャラクタ１００のレレベルの１／２である「１０」とを合算した「１６」に更新する。

次に、管理サーバ２０は、端末情報管理ＤＢ２３１に基づいて、更新通知をユーザ端末１０ａに宛てて送信する（ステップＳ４）。この更新通知は、キャラクタレベル「１０」を示すパラメータを少なくとも含む。ユーザ端末１０ａは、更新通知を受信すると、権限データ１５２を更新する（ステップＳ５）。ここでは、ユーザ端末１０ａは、キャラクタのレベルを「１０」とするように、権限データ１５２を更新する。

次に、ユーザ端末１０ａは、ＶＲＡＭ１４１に記憶される表示データを更新して、表示部１４にゲーム画面を表示する（ステップＳ６）。図７（ｃ）に示すように、ユーザ端末１０ａは、キャラクタ１００を、キャラクタ１１０とキャラクタ１２０（第１のキャラクタ）とに変化させたゲーム画面を表示する。キャラクタ１１０，１２０はともにレベルが「１０」であり、キャラクタ１１０，１２０の容姿は同一である。ただし、キャラクタ１１０，１２０のレベルは、キャラクタ１００のレベルよりも低いので、キャラクタ１１０，１２０はキャラクタ１００よりも小さいサイズで表示される。

次に、ユーザ端末１０ａは、ＶＲＡＭ１４１に記憶される表示データを更新して、ゲーム画面を表示部１４に表示する（ステップＳ７）。図７（ｄ）に示すように、ここでのゲーム画面は、図７（ｃ）に示すゲーム画面から、キャラクタ１１０を表示したままとする一方で、キャラクタ１２０を非表示とするように変化させた画面である。キャラクタ１２０を非表示とした理由は、キャラクタ１１０がユーザ端末１０ａの外へ移動したことを、ユーザが視覚的に把握できるようにするためである。このため、ステップＳ７の処理では、ユーザ端末１０ａは、キャラクタ１２０が歩いて表示部１４の表示領域外へ移動する様子を表したゲーム画面を表示してもよい。ステップＳ７の処理後においては、ユーザ端末１０ａでは、レベル「１０」のキャラクタ１２０を使用してゲームを進行させることとなる。キャラクタ１１０のレベルは、キャラクタ１００のレベルよりも低いから、キャラクタ１１０を用いてクリアすることのできるイベントは、キャラクタ１００がクリアすることのできるイベントよりも少なくなる。すなわち、ユーザ端末１０ｂは、キャラクタの変化（分割）及び移動によって、特定のイベントをクリアするようにゲームを進行させる処理の実行権限を失ったこととなる。

次に、管理サーバ２０は、端末情報管理ＤＢ２３１に基づいて、更新通知をユーザ端末１０ｂに宛てて送信する（ステップＳ８）。この更新通知は、キャラクタレベル「１６」を示すパラメータを少なくとも含む。ユーザ端末１０ｂは、更新通知を受信すると、権限データ１５２を更新する（ステップＳ９）。ここでは、ユーザ端末１０ｂは、キャラクタのレベルを「１６」とするように、権限データ１５２を更新する。

ユーザ端末１０ｂは、更新通知を受信すると、ＶＲＡＭ１４１に記憶される表示データを更新して、ゲーム画面を表示部１４に表示する（ステップＳ１０）。図７（ｅ）に示すように、ここでのゲーム画面は、元から表示されていたキャラクタ２００と、ユーザ端末１０ａから移動してきたキャラクタ１２０とを含む。ステップＳ８の処理では、ユーザ端末１０ｂは、キャラクタ１２０が歩いて表示部１４の表示領域内へ移動する様子を表したゲーム画面を表示してもよい。

次に、ユーザ端末１０ｂは、ＶＲＡＭ１４１に記憶される表示データを更新して、ゲーム画面を表示部１４に表示させる（ステップＳ１１）。図７（ｆ）に示すように、ここでのゲーム画面では、キャラクタ２００とキャラクタ１２０（第２のキャラクタ）とを合体して１体としたキャラクタ２１０（第３のキャラクタ）が表示される。このステップＳ１１の処理後においては、ユーザ端末１０ｂでは、レベル「１６」のキャラクタ２１０を使用してゲームを進行させることとなる。キャラクタ２１０のレベルは、キャラクタ２００のレベルよりも高いから、キャラクタ２１０を用いてクリアすることのできるイベントは、キャラクタ２００がクリアすることのできるイベントよりも多い。すなわち、ユーザ端末１０ｂは、キャラクタの移動及び変化（合体）によって、特定のイベントをクリアするようにゲームを進行させる処理の実行権限を得たこととなる。
以上が、キャラクタの分割及び合体が行われる一連の処理の流れの説明である。

その後、ユーザ端末１０ｂは、キャラクタ２１０をキャラクタ２００とキャラクタ１２０とに分割して、キャラクタ１２０をユーザ端末１０に移動させる（すなわち返却）することもできる。例えば、ユーザ端末１０ｂがキャラクタ１２０の返却を指示する操作を受け付けたことを契機に、キャラクタ１２０の返却が行われてもよい。この場合、前述の説明でユーザ端末１０ａが行っていた処理を、ユーザ端末１０ｂが行い、ユーザ端末１０ｂが行っていた処理を、ユーザ端末１０ａが行えばよい。ただし、キャラクタを返却する場合には、キャラクタの分割方法を指定する操作（レベルを指定する操作）や、移動したキャラクタの移動先のユーザ端末１０を指定する操作については不要である。
なお、ユーザ端末１０ｂは、キャラクタ１２０を返却する操作を受け付けたことを契機とするのではなく、キャラクタの合体があったときから所定期間が経過したことや特定のイベントをクリアしたこと等の特定条件を満たしたことを契機に、キャラクタを返却してもよい。

また、ユーザ端末１０ａがステップＳ１の処理でキャラクタの移動を指示する操作を受け付けたことを契機に、ユーザ端末１０ａからユーザ端末１０ｂにキャラクタを移動させるだけでなく、ユーザ端末１０ｂ側から、ユーザ端末１０ａからユーザ端末１０ｂへのキャラクタの移動を要請することも可能である。

図８は、通信システム１でキャラクタを他端末に移動させるときの処理の流れを示すシーケンス図である。まず、ユーザ端末１０ｂは、自端末へのキャラクタの移動を要請する操作を受け付ける（ステップＳ１２）。ここでは、ユーザ端末１０ｂは、キャラクタの移動を要請するユーザ端末１０を指定する操作を少なくとも受け付ける。また、ユーザ端末１０ｂは、ユーザ端末１０ａに対してキャラクタの移動を要請する旨の操作を受け付けたものとする。この際、管理サーバ２０は、各ユーザ端末１０におけるキャラクタのレベルをユーザ端末１０ｂのユーザが参照できるように、各キャラクタのレベルを通知してもよい。

次に、ユーザ端末１０ｂは、ステップＳ１２の処理で操作を受け付けたことを示す通知を、管理サーバ２０に宛てて送信する（ステップＳ１３）。管理サーバ２０は、この通知に従って、ユーザ端末１０ｂにおいて要請先に指定されたユーザ端末１０ａに対し、キャラクタの移動の要請があったこと通知する（ステップＳ１４）。ユーザ端末１０ａはこの通知を受信すると、この要請に応じるかどうかをユーザに問い合わせる（ステップＳ１５）。ここにおいて、ユーザ端末１０ａは、例えば、キャラクタの分割及び移動に応じるかどうかをユーザに問い合わせるための画面を表示する。ユーザ端末１０ａのユーザは、この画面に従って、キャラクタの分割及び移動に応じるかどうかを、操作部１２を操作することによって応答する。

ユーザ端末１０ａは、ユーザの応答内容を管理サーバ２０に宛てて送信する（ステップＳ１６）。ユーザがキャラクタの移動に応じると応答した場合には、通信システム１では、以降、前述したステップＳ３〜Ｓ１１の処理が実行される。一方で、ユーザがキャラクタの移動に応じないと応答した場合には、通信システム１では、キャラクタの分割及び移動を行うことなく、図８に示す処理を終了する。
この実施形態では、ユーザ端末１０ａがユーザ端末１０ｂにキャラクタを移動させる場合を説明したが、ユーザ端末１０ａ，１０ｂ，１０ｃのどの組み合わせでキャラクタが移動させられてもよい。

以上説明したとおり、キャラクタを他端末に移動させるユーザ端末１０は、ゲームに使用されるキャラクタを複数に分割してから、他端末に移動させる。また、キャラクタを自端末に移動させるユーザ端末１０は、他端末から移動してきたキャラクタと、自端末に元から居たキャラクタとを合体させる。ゲームにおいて、キャラクタのレベルに応じてイベントをクリアする条件が異なる場合、ユーザ端末１０は、自端末でのプレイでキャラクタを成長させてゲームを進行させるだけでなく、他端末からのキャラクタと合体させてゲームを進行させることができる。また、分割前後や合体前後でキャラクタの容姿は異なるので、ユーザは、キャラクタの容姿から視覚的に、ゲームをクリアするために必要なキャラクタのレベルを把握できたり、所定のイベントをクリアする権限があるかどうかを把握できたりすることがある。また、キャラクタの容姿は分割や合体によって様々に変化するから、ユーザ端末１０によるキャラクタの表示の方法により、ユーザに対して視覚的な面白みを与えることが可能である。

＜第１実施形態の変形例＞
上述した第１実施形態の通信システム１では、キャラクタの移動先のユーザ端末１０において、移動してきたキャラクタと元から居たキャラクタとを合体させていたが、この合体が行われないようにしてもよい。例えば、ゲームにおいて、キャラクタの数によってクリアできるイベントが異なるゲームに、本構成を適用することができる。

また、他端末からのキャラクタが移動してきたユーザ端末１０では、合体させた複数のキャラクタの組み合わせ、又は、合体させた複数のキャラクタの属性の組み合わせに応じて、ゲームを進行させる処理を異ならせてもよい。例えば、ユーザ端末１０は、合体させたキャラクタの組み合わせが所定の条件を満たした場合には、特定のイベントを発生させるようにゲームを進行させる処理を実行する。
また、ユーザ端末１０は、複数のキャラクタを合体させた場合には、合体前のキャラクタのレベルを合算するとともに、更に、追加のレベルを加算してもよい（例えば、レベルに更に「１」を加算する）。

また、キャラクタの移動によって加減算されるパラメータは、キャラクタのレベルに限るものではなく、経験値等のキャラクタの成長度合いを示す他のパラメータであってもよい。また、通信システム１では、キャラクタの成長度合い以外の属性（例えば、血統や得意分野等）を示すパラメータを加減算して、キャラクタの分割及び合体が行われてもよい。また、この属性は、キャラクタを分割していって所定の代のキャラクタまでは伝達するが、それ以降の代のキャラクタには伝達しない属性であってもよい。
また、キャラクタが複数に分割させられて、各キャラクタが異なるユーザ端末１０にある場合、いずれかのユーザ端末１０でのキャラクタの成長が他のキャラクタの成長に影響してもよい。すなわち、或るキャラクタを変化させて生成された複数のキャラクタは、互いに異なるユーザ端末１０にある場合であっても、相互に影響しあって容姿が変化してもよい。この場合、管理サーバ２０が、複数のユーザ端末１０で表示されているキャラクタの属性と成長度合いとを管理して、各ユーザ端末１０に対して他端末でのキャラクタの成長を通知する等すればよい。

また、ユーザ端末１０は、キャラクタを２つに分割してそのうちの一方を移動させていたが、３つ以上に分割してもよい。また、ユーザ端末１０は、分割したキャラクタのすべてを他端末に移動させてもよく、この際に、移動先の端末をそれぞれ異ならせてもよい。
また、ユーザ端末１０は、２つのキャラクタを合体させていたが、３つ以上のキャラクタを自端末に移動させて合体させてもよい。この際、ユーザ端末１０は、移動元の端末が異なる複数のキャラクタを合体させてもよい。

また、ゲームで発生するイベントの内容は特に問わず、例えば、キャラクタを多くユーザ端末１０に集めた場合ほど、珍しいアイテムが取得しやすくなるようにしてもよい。他端末からのキャラクタが移動してきたユーザ端末１０では、その移動前に比べてゲームを有利に進行できるようにゲームを進行させるとよい。

また、通信システム１では、同じレベルのキャラクタであっても、分割させられたことのあるキャラクタと、分割させられたことのないキャラクタとで容姿を異ならせてもよい。また、通信システム１では、分割させられた回数に応じてキャラクタの容姿を異ならせてもよい。また、同じレベルのキャラクタであっても、合体により生成されたキャラクタと、合体したことのないキャラクタとの容姿を異ならせてもよい。また、通信システム１では、合体した回数に応じてキャラクタの容姿を異ならせてもよい。この場合に、合体したキャラクタの数に応じた追加のレベル（ボーナスポイント）が加算されてもよい。
また、複数のユーザ端末１０のキャラクタを合体させた後、分割前とは異なるキャラクタとなるように再分割して、再分割したキャラクタをこれら複数のユーザ端末１０に再配布してもよい。
管理サーバ２０により提供されるゲームは、ロールプレイングゲームでなくてもよく、スポーツゲームやアクションゲーム等の、キャラクタが登場する他のジャンルのゲームであってもよい。

［第２実施形態］
上述した第１実施形態では、ユーザ端末１０は、ゲームを進行させる処理の実行権限を示すキャラクタを表示させていた。この第２実施形態では、ユーザ端末１０は、ゲームを進行させる処理でない処理の実行権限を示すキャラクタを表示させる。この実施形態の通信システム１では、管理サーバ２０が記憶する図示せぬデータベースに格納されたファイルのセキュリティを確保する目的で、ユーザ端末１０によるデータベースへのアクセスを、権限データ１５２に応じて制限する。

この実施形態の通信システム１を構成する各装置のハードウェア構成や機能ブロックの構成は、上述した第１実施形態と同じでよいから、その説明を省略する。ただし、ユーザ端末１０及び管理サーバ２０は、ゲームを進行させる処理に必要な構成を有さなくてよい。例えば、この実施形態のキャラクタ表示アプリ１５１は、キャラクタを表示する機能を実現するものの、ゲームを進行させる機能を実現しなくてよい。権限データ１５２は、ユーザ端末１０又はそのユーザに与えられたデータベースへアクセスする際の権限レベルを表すデータである。また、この実施形態の管理サーバ２０の記憶部２３は、端末情報管理ＤＢ２３１ａ及び実行権限管理ＤＢ２３２を記憶している。以下の説明において、上述した第１実施形態と同じ構成要素及び処理ステップについては同一の符号を付して表し、その説明を省略する。

図９は、端末情報管理ＤＢ２３１ａの構成例を示す図である。図９に示すように端末情報管理ＤＢ２３１ａは、「端末ＩＤ」と、「権限レベル」とを対応付けたデータベースである。
「端末ＩＤ」は、上述した第１実施形態で説明した同じ情報と同じである。「権限レベル」は、権限データ１５２が表す権限レベルと同じ情報であり、ユーザ端末１０又はそのユーザに与えられたデータベースへのアクセス権限に対応する。この権限レベルは「０」から「６」までの７段階の数値によって表され、この数値が大きいほど権限レベルが高いことを意味する。例えば企業において、部長であれば権限レベルとして「３」が割り当てられ、課長であれば権限レベルとして「２」が割り当てられ、平社員であれば権限レベルとして「１」が割り当てられる。この権限レベルは、例えば、管理サーバ２０の管理者によって設定され、ユーザ端末１０では自由に変更することができないパラメータであるものとする。

図１０は、実行権限管理ＤＢ２３２の構成例を示す図である。実行権限管理ＤＢ２３２では、権限レベル毎に実行権限が与えられる処理の内容が対応付けられている。例えば、権限レベル「１」であれば、機密度が低い文書の閲覧が許可されている。権限レベル「２」であれば、機密度が低い文書の閲覧とともに、機密度が低い文書の更新が許可されている。権限レベル「３」であれば、機密度が低い文書の閲覧・更新とともに、機密度が中程度の文書の閲覧が許可されている。権限レベル「４」であれば、機密度が低い文書の閲覧・更新、及び機密度が中程度の文書の閲覧とともに、機密度が高い文書の閲覧が許可されている。権限レベル「５」及び「６」についても、図１０に示す実行権限が対応付けられている。
すなわち、権限レベルが高い場合ほど、ユーザ端末１０が実行可能な処理の数が増えたり、実行可能な処理の重要度が高くなったりする。

図１１は、この実施形態のユーザ端末１０で表示されるキャラクタを示す図である。ユーザ端末１０ａには権限レベルが「３」が割り当てられ、キャラクタ３１０が表示されている。ユーザ端末１０ｂには権限レベルが「１」が割り当てられ、キャラクタ３２０が標示されている。ユーザ端末１０ｃには権限レベルが「２」が割り当てられ、キャラクタ３３０が表示されている。ユーザ端末１０ａ〜１０ｃのそれぞれで権限レベルが異なるから、キャラクタ３１０，３２０，３３０の容姿も権限レベルに応じてそれぞれ異なっている。このキャラクタは、いつ表示されてもよいが、例えばホーム画面（待ち受け画面）やデータベースへのアクセスを試みる処理の実行時等の所定画面で表示される。

図１２は、通信システム１で、実行権限に関連付けられたキャラクタを他端末に移動させるときの処理の流れを示すシーケンス図である。図１３は、ユーザ端末１０で表示されるキャラクタ及び端末情報管理ＤＢ２３１ａを説明する図である。以下、ユーザ端末１０ａからユーザ端末１０ｂにキャラクタを移動させる場合の通信システム１の動作を説明する。上述した第１実施形態と同じ番号を付した処理ステップについては、適宜その説明を省略する。

まず、ユーザ端末１０ａは、キャラクタの他端末への移動を指示する操作を受け付ける（ステップＳ１）。ここでは、ユーザ端末１０ａは、キャラクタ３１０を分割せずに、キャラクタ３１０をそのままユーザ端末１０ｂに移動させることを指示する操作を受け付ける。次に、ユーザ端末１０ａは、ステップＳ１の処理で操作を受け付けたことを示す通知を、管理サーバ２０に宛てて送信する（ステップＳ２）。管理サーバ２０は、この通知を受信すると、受信した通知に応じて端末情報管理ＤＢ２３１ａを更新する（ステップＳ３）。ここでは、管理サーバ２０は、端末情報管理ＤＢ２３１ａにおいて端末ＩＤ「ＭＩＤ−ａ」に対応付けられた権限レベルを、キャラクタ３１０の権限レベルである「３」から「−」（権限レベル０に相当）に更新する。また、管理サーバ２０は、端末情報管理ＤＢ２３１ａにおいて端末ＩＤ「ＭＩＤ−ｂ」に対応付けられた権限レベルを、キャラクタ３２０の権限レベル「１」と、キャラクタ３１０の権限レベルである「３」とを合算した「４」に更新する。

管理サーバ２０は、端末情報管理ＤＢ２３１ａを更新すると、更新通知をユーザ端末１０ａに宛てて送信する（ステップＳ４）。この更新通知は、権限レベル「０」を示すパラメータを少なくとも含む。ユーザ端末１０ａは、更新通知に応じて権限データ１５２を更新する（ステップＳ５）。ここでは、ユーザ端末１０ａは、権限レベル「０」とするように、権限データ１５２を更新する。そして、ユーザ端末１０ａは、ＶＲＡＭ１４１に記憶される表示データを更新して、キャラクタを含む画面を表示部１４に表示させる（ステップＳ１７）。図１３に示すように、ここでは、キャラクタ３１０を移動させた後であるから、ユーザ端末１０ａにおいてキャラクタは表示されない。

次に、管理サーバ２０は、更新通知をユーザ端末１０ｂに宛てて送信する（ステップＳ７）。この更新通知は、権限レベル「４」を示すパラメータを少なくとも含む。ユーザ端末１０ｂは、更新通知を受信すると、権限データ１５２を更新する（ステップＳ９）。ここでは、ユーザ端末１０ｂは、権限レベル「４」とするように、権限データ１５２を更新する。そして、ユーザ端末１０ｂは、ＶＲＡＭ１４１に記憶される表示データを権限データ１５２に応じて更新して、キャラクタを含む画面を表示部１４に表示させる（ステップＳ１８）。図１３に示すように、ここでは、元から表示されていたキャラクタ３２０と、ユーザ端末１０ａから移動してきたキャラクタ３１０とを含む画面が表示される。すなわち、ユーザ端末１０ｂは、キャラクタが移動してきたことによって、元の権限レベルである「１」よりも高い「４」に対応する実行権限、すなわち、移動前にはなかった処理の実行権限を得たこととなる。また、ユーザは、ユーザ端末１０ｂに表示されたキャラクタ３１０及びキャラクタ３２０を見ることで、新たな実行権限が得られたことを視覚的に把握することができる。
以上が、キャラクタの移動を伴う一連の処理の流れの説明である。

図１４は、ユーザ端末１０により管理サーバ２０が有するデータベースへのアクセスが行われるときの通信システム１の動作の流れを示すシーケンス図である。ここでは、権限レベルが「４」となったユーザ端末１０ｂがアクセスするときの動作を説明する。
ユーザ端末１０ｂは、データベースにアクセスして所定の処理の実行を要求する場合には、処理要求を管理サーバ２０に宛てて送信する（ステップＳ１０１）。この処理要求は、送信元のユーザ端末１０の端末ＩＤが少なくとも含まれている。また、ここでは、機密度が高い文書の閲覧が要求されたとする。

次に、管理サーバ２０は、処理要求を受信すると、端末情報管理ＤＢ２３１ａを参照して、ユーザ端末１０ｂの権限レベルを特定する（ステップＳ１０２）。ここでは、管理サーバ２０は、ユーザ端末１０ｂに割り当てられた権限レベルとして「４」を特定する。次に、管理サーバ２０は、実行権限管理ＤＢ２３２を参照して、要求された処理の実行権限がユーザ端末１０ｂにあるかどうかを判断する（ステップＳ１０３）。管理サーバ２０は、要求された処理の実行権限がユーザ端末１０ｂにあると判断した場合には（ステップＳ１０３；ＹＥＳ）、処理要求に従った処理が通信システム１で実行される（ステップＳ１０４）。ここでは、ユーザ端末１０の権限レベルが「４」であり、処理要求が、機密度が高い文書の閲覧であるから、管理サーバ２０は、要求された処理の実行権限がユーザ端末１０にあると判断する。よって、ユーザ端末１０ｂでは、機密度が高い文書を表示し、ユーザに閲覧させることができる。
一方、管理サーバ２０は、実行権限を与えていない処理の処理要求があると判断した場合には（ステップＳ１０３；ＮＯ）、その処理要求に従った処理の実行を不許可とする。例えば、キャラクタ３１０がユーザ端末１０ｂに移動させられていない場合、ユーザ端末１０ｂの権限レベルが「１」であるから、処理要求で要求された処理は実行されなかったことになる。

以上説明した本実施形態の通信システム１では、複数のユーザ端末１０間で権限レベルを示すキャラクタを移動させる。ユーザは、ユーザ端末１０に表示されたキャラクタを見て、どのような処理の実行権限があるのかを視覚的に把握することが可能である。また、ユーザ端末２０間でキャラクタを移動させて、各ユーザ端末１０の権限レベルを変化させることができる。よって、通信システム１によれば、例えば、平社員だけではデータベースにアクセスできないものの、部長等の上司からの許可を受ければデータベースにアクセスできるといった利用が可能となる。

＜第２実施形態の変形例＞
上述した第２実施形態の通信システム１では、キャラクタを分割させないで移動させていたが、上述した第１実施形態と同じ方法でキャラクタを分割してから移動させてもよい。この場合、分割前のキャラクタの権限レベルを１／２ずつにする等して、分割後のキャラクタの権限レベルを、分割前のキャラクタのレベルよりも小さくするとよい。また、上述した第２実施形態では、ユーザ端末１０においてキャラクタを合体させていなかったが、上述した第１実施形態と同じ方法でキャラクタを合体させてもよい。この場合、合体により権限レベルとして「４」を得たユーザ端末１０ｂでは、例えば、図１５に示すような合体後のキャラクタ３４０を表示させる。

また、上述した第２実施形態では、データベースへのアクセスを権限レベルに応じて制限する場合の例を説明したが、通信システム１では、例えば、特定の部屋への入室の可否を権限レベルに応じて制限する等、セキュリティを確保するための処理の実行権限を権限レベルに応じて制限してもよい。また、通信システム１で権限レベルに応じて制限する処理は更に別の処理であってもよく、具体的な処理が何であるかは特に問わない。
また、上述した第１実施形態で説明したキャラクタを返却する構成や、自端末にキャラクタを移動させたいユーザ端末１０側から移動を要請する構成については、上述した第２実施形態の通信システム１にも適用することができる。

［第３実施形態］
ゲームを進行させる処理でない処理の実行権限を示すキャラクタを表示させる通信システム１を、例えば、以下のように構成することも可能である。この実施形態の通信システム１では、ユーザ端末１０が利用することのできる自端末の機能に関する処理の実行を、権限データ１５２に応じて制限する。
この実施形態の通信システム１を構成する各装置のハードウェア構成や機能ブロックの構成は、上述した第１実施形態と同じでよいから、その説明を省略する。ただし、ユーザ端末１０及び管理サーバ２０は、ゲームを進行させる処理に必要な構成を有さなくてよい。例えば、この実施形態のキャラクタ表示アプリ１５１は、キャラクタを表示する機能を実現するものの、ゲームを進行させる機能を実現しなくてよい。権限データ１５２は、ユーザのユーザ端末１０の操作の習熟度を表すデータである。また、この実施形態の管理サーバ２０の記憶部２３は、端末情報管理ＤＢ２３１ｂ及び実行権限管理ＤＢ２３２ｂを記憶している。以下の説明において、第１実施形態と同じ構成要素及び処理ステップについては同一の符号を付して表し、その説明を省略する。

図１６は、端末情報管理ＤＢ２３１ｂの構成例を示す図である。端末情報管理ＤＢ２３１ｂは、各ユーザのユーザ端末１０の習熟度を管理するデータベースである。図１７に示すように、端末情報管理ＤＢ２３１ｂは、「端末ＩＤ」と、「習熟度」とを対応付けたデータベースである。
「端末ＩＤ」は、上述した第１実施形態で説明した同じ情報と同じである。「習熟度」は、権限データ１５２が表す権限レベルと同じ情報であり、ユーザがどの程度ユーザ端末１０の操作を習熟しているかの指標となるパラメータである。この習熟度は「１」から「５」までの５段階の数値によって表され、この数値が大きいほど習熟度が高いことを意味する。また、この習熟度は、ユーザ端末１０で実現可能な機能毎に個別に設定されている。ここでは、カメラ機能及びメール機能の習熟度を示すが、この例に限らず、他の機能を含んでいてもよい。各機能の習熟度は、その機能を実現させるための操作にユーザが習熟している場合ほど高くなる。ユーザ端末１０は、自端末における各機能の処理の実行実績を収集し、所定のアルゴリズムによって習熟度を判定して、権限データ１５２を更新する。ユーザ端末１０は、例えば、各機能について特定の操作が行われた回数が多いほど権限レベルを高くする等すればよい。

図１７は、実行権限管理ＤＢ２３２ｂの構成例を示す図である。実行権限管理ＤＢ２３２ｂでは、習熟度毎に実行権限が与えられる処理が対応付けられている。例えば、カメラ機能の習熟度が「１」であれば、カメラ機能の静止画撮影を実行可能で、動画撮影や撮影条件の設定等の実行は許可されていない。カメラ機能の習熟度が「２」であれば、静止画の撮影に加えて動画撮影が許可される。権限レベルが「３」〜「５」についても、図１７に示す実行権限の内容が対応付けられている。図１７を見ても分かるように、習熟度が高い場合ほど、ユーザ端末１０が実行可能な処理の数が増えたり、実行可能な処理の難易度が高くなったりする。

図１８は、この実施形態のユーザ端末１０で表示されるキャラクタを示す図である。図１８には、カメラ機能の習熟度に応じてキャラクタの容姿がどのように変化するのかを示している。習熟度が「１」の場合、キャラクタ４１０が表示される。習熟度が「２」の場合、キャラクタ４１０の右手にカメラを模した付加画像Ｃ１を付したキャラクタ４２０が表示される。習熟度が「３」の場合、キャラクタ４１０の右手にカメラを模した付加画像Ｃ２を付したキャラクタ４３０が表示される。習熟度が「４」の場合、キャラクタ４１０の右手にカメラを模した付加画像Ｃ３を付したキャラクタ４２０が表示される。習熟度が「５」の場合、キャラクタ４１０の右手にカメラを模した付加画像Ｃ４を付したキャラクタ４５０が表示される。
以上のとおり、カメラ機能の習熟度によってキャラクタの容姿が異なり、習熟度が高いほどそれを明示する容姿のキャラクタが用いられる。ここでは、キャラクタ４１０に付加される構成要素（付加画像）によって実行権限が変化することとなる。このキャラクタは、いつ表示されてもよいが、例えばホーム画面（待ち受け画面）等の所定画面で表示される。

この実施形態では、キャラクタそのものを移動させることなく、各ユーザ端末１０の習熟度（言い換えると実行権限）を移動させる。ただし、この実施形態の通信システム１の動作は、図１２を用いて上述した第２実施形態で説明したものと同様であり、「権限レベル」を「習熟度」に読み替えることによって説明することができる。ただし、ステップＳ１の処理では、ユーザ端末１０ａはキャラクタの移動ではなく、習熟度の移動を指示する操作を受け付ける。また、ステップＳ１７，Ｓ１８の表示変更の方法が上述した第２実施形態とは相違する。

図１９は、ユーザ端末１０で表示されるキャラクタ及び端末情報管理ＤＢ２３１ｂを説明する図である。
ここで、習熟度の移動前には、図１９（ａ）に示すように、ユーザ端末１０ａは、カメラ機能の習熟度「５」を示すキャラクタ４５０を表示させ、ユーザ端末１０ｂは、カメラ機能の習熟度「１」を示すキャラクタ４１０を表示させる。この場合に、カメラ機能の習熟度を「２」だけユーザ端末１０ａからユーザ端末１０ｂに移動させると、ステップＳ１７の処理では、図１９（ｂ）に示すように、ユーザ端末１０ａは、カメラ機能の習熟度「３」を示すキャラクタ４３０に変化させる。ステップＳ１８の処理では、図１９（ｂ）に示すように、ユーザ端末１０ｂはカメラ機能の習熟度「３」を示すキャラクタ４３０に変化させる。このキャラクの表示変更後、ユーザ端末１０ａ，１０ｂの各々は、カメラ機能の権限レベル「３」に対応して実行権限が与えられる処理を行うことができる。
この実施形態の場合、キャラクタは移動していないが、各機能の処理の実行権限が移動させられたことにより、キャラクタの容姿が変化するから、ユーザ端末１０が有する実行権限も変化したことをユーザは把握することができる。

図２０は、ユーザ端末１０により実行可能な処理が制限されるときの通信システム１の動作の流れを示すシーケンス図である。ここでは、カメラ機能の習熟度が「３」となったユーザ端末１０ｂの動作を説明する。
まず、ユーザ端末１０ｂは、管理サーバ２０に習熟度を問い合わせる（ステップＳ２０１）。この問い合わせ要求は、ユーザ端末１０ｂの端末ＩＤを含む。管理サーバ２０は、問い合わせ要求を受信すると、端末情報管理ＤＢ２３１ｂを参照して、ユーザ端末１０ｂの習熟度を特定する（ステップＳ２０２）。そして、管理サーバ２０は、特定した習熟度をユーザ端末１０ｂに通知する（ステップＳ２０３）。ユーザ端末１０ｂは、習熟度に応じて実行可能な処理を制限する。ここでは、ユーザ端末１０ｂのカメラ機能の習熟度が「３」であるから、実行権限管理ＤＢ２３２ｂに基づいて、カメラ機能の習熟度「３」までの処理を実行可能にし、それ以外の処理を実行不可能にする。例えば、カメラ機能の習熟度「２」がユーザ端末１０ｂに移動させられていない場合、ユーザ端末１０ｂのカメラ機能の習熟度は「１」であるから、例えば、カメラ機能の静止画撮影を実行可能で、動画撮影や撮影条件の設定等は行えなかったことになる。

これにより、ユーザ端末１０ｂでは、習熟度が低く一部の処理しか実行できなかった状態から、即座に新たな処理を実行することができる。ただし、通信システム１において、習熟度を移動先のユーザ端末１０ｂに移動させたままにする場合には、習熟度の高いユーザが、習熟度が低いユーザに、ユーザ端末１０ｂの操作方法を教えることが望ましい。又は、習熟度が移動させられた側のユーザ端末１０ｂが、移動後の習熟度に応じた操作を行えるかどうかの試験をユーザに対して行ってから、習熟度を移動させる処理を許可するか又は移動してきた習熟度に応じた処理を実行可能にしてもよい。

また、図１９（ａ）に示すキャラクタ４５０を表示していたユーザ端末１０ａにおいて、メール機能の習熟度が「１」から「２」に上がった場合には、ユーザ端末１０ａは、図２１（ａ）に示すように、キャラクタ４６０に変化させる。キャラクタ４６０は、キャラクタ４１０に、カメラを模した付加画像Ｃ４及び手紙を模した付加画像Ｍを付したキャラクタであり、一体のキャラクタ４１０から複数機能の習熟度が把握できるようになっている。すなわち、習熟度を移動させる場合、機能毎に個別に習熟度を移動させることができる。例えば、メール機能についてユーザ端末１０ａからユーザ端末１０ｂに習熟度を移動させると、図２１（ｂ）に示すように、ユーザ端末１０ａではキャラクタ４５０が表示され、ユーザ端末１０ｂではキャラクタ４１０に付加画像Ｍを付したキャラクタ４７０が表示される。
なお、ユーザ端末１０は、機能毎にキャラクタを分けて表示してもよい。

以上説明した通信システム１によれば、ユーザ端末１０は、ユーザの操作の習熟度に応じて実行可能な処理を制限する場合に、通信端末間で習熟度を移動させて個々の習熟度を変化させることができる。これにより、本来、ユーザがユーザ端末１０を使い込んでいなければ実行できない処理であっても、速やかにその処理を実行可能にすることができる。例えば、法人用の端末や学習モードでユーザ端末１０を使用する場合には、例えばユーザの誤った操作等によって不利益を被らないように、実行可能な処理を制限したい場合がある。この場合に、ユーザ端末１０の操作に習熟しており習熟度が高くなったユーザや、習熟度の高いユーザから指導を受けたユーザについては、通信端末１０で実行可能な処理の量が増えるので、個々のユーザの習熟度に適した処理を実行可能にすることができる。
ここでは、カメラ機能やメール機能の例を説明したが、例えば、特定のアプリケーションの実行の可否を習熟度に応じて制限してもよく、制限する処理は特に問わない。

＜第３実施形態の変形例＞
通信システム１において、ユーザ端末１０は実行権限管理ＤＢ２３２ｂで実行権限が管理される処理が所定期間に実行されなかったり、その実行頻度が低かったりする等の特定条件を満たした場合には、その機能についての習熟度を低くしてもよい。
また、ユーザ端末１０は、管理サーバ２０に問い合わせるのではなく、権限データ１５２を参照して実行権限のある処理を特定してもよい。
また、上述した第１実施形態で説明したキャラクタを返却する構成や、自端末にキャラクタを移動させたいユーザ端末１０側から移動を要請する構成については、上述した第３実施形態の通信システム１にも適用することができる。

［変形例］
本発明は、上述した実施形態と異なる形態で実施することが可能である。本発明は、例えば、以下のような形態で実施することも可能である。また、以下に示す変形例は、各々を適宜に組み合わせてもよい。
（変形例１）
本発明で実行権限が移動させられる処理は、上述した第１〜第３実施形態で説明した処理に限られず、その具体的な処理は種々の変形が可能である。
本発明では、例えば、キャラクタ１体をクーポン１枚に対応させて、キャラクタの数に応じてクーポンの利用可能な数を制限してもよい。また、合体により新たなキャラクタが得られた場合には、価値の高いクーポンを利用可能にしてもよい。管理サーバ２０は、動画コンテンツや音楽コンテンツの視聴サービスを提供するものであってもよい。この場合、ユーザ端末１０は、１日当たりのコンテンツ視聴可能回数や視聴可能時間の上限等の視聴サービスに関する処理の実行権限を、キャラクタと関連付けて端末間で移動させる。

（変形例２）
上述した各実施形態では、ユーザ端末１０は、管理サーバ２０を介してキャラクタを移動させていたが、近距離無線通信等の通信を用いて、管理サーバ２０を介さずに直接に通信して、他端末との間でキャラクタを移動させてもよい。この場合、管理サーバ２０が記憶していたデータベースを、例えばユーザ端末１０が記憶すればよい。
また、ユーザ端末１０は、キャラクタ又は実行権限を他端末に移動させる場合に、管理サーバ２０に一旦移動させてもよい。キャラクタ又は実行権限を自端末に移動させるユーザ端末１０は、管理サーバ２０と通信して、キャラクタ又は実行権限を管理サーバ２０から自端末に移動させる。キャラクタ又は実行権限の移動の際に、ユーザ端末１０と管理サーバ２０との間で移動させられるデータは、上述した各実施形態と同じでよい。例えば、管理サーバ２０は、自サーバに移動させられたキャラクタを特定可能なデータやこのキャラクタに関連付けられた権限データを記憶していればよい。

（変形例３）
通信システム１において、複数のユーザ端末１０間でキャラクタ又は実行権限を移動させようとする場合に、移動元のユーザ端末１０（ここではユーザ端末１０ａとする。）のユーザの属性、又は、移動先のユーザ端末１０（ここではユーザ端末１０ｂとする。）のユーザの属性に基づいて、キャラクタ又は実行権限の移動を制限してもよい。
例えば、移動元のユーザ端末１０ａのユーザと、移動先のユーザ端末１０ｂのユーザとの関係を表すパラメータ（以下、「関係パラメータ」という。）に基づいて、キャラクタ又は実行権限の移動を制限してもよい。関係パラメータは、ここでは、ユーザ端末１０ａのユーザと、ユーザ端末１０ｂのユーザとの親密さの度合い（すなわち親密度）を表すパラメータである。この関係パラメータは、例えば、ユーザ端末１０ａとユーザ端末１０ｂとの間で行われた通信の履歴に基づいて、ユーザ端末１０ａにより算出される。そこで、ユーザ端末１０ａは、通信相手毎に、この通信相手と行った通信の通信履歴に基づいて、関係パラメータを算出する。この通信履歴としては、例えば、電子メールをやりとりした回数や音声通信での通話回数、ＳＮＳ（Social Networking Service）を用いて通信した回数のうちの、１つ以上用いることができる。この場合、やり取りされた電子メールの数が多いほど、音声通信での通話回数が多いほど、又は、ＳＮＳを用いて通信した回数（例えば、ＳＮＳを用いたコメントの回数）が多いほど、ユーザ端末１０ａのユーザとユーザ端末１０ｂのユーザとがより親密であると推測することができる。

以上の関係パラメータに基づき、ユーザ端末１０ａは、関係パラメータが閾値以上である場合には、ユーザ端末１０ｂへのキャラクタ又は実行権限の移動を許可し、関係パラメータが閾値未満である場合には不許可とする。又は、ユーザ端末１０ａは、関係パラメータの値が大きいほど、ユーザ端末１０ｂへ移動可能な実行権限のレベルを高くし、反対に、関係パラメータの値が小さいほど、ユーザ端末１０ｂへ移動可能な実行権限のレベルを低くするように制限してもよい。
上述した関係パラメータは、親密度を示すパラメータに限らず、例えば、友人や同僚、家族等のユーザとの人間関係そのものを表すパラメータであってもよい。また、関係パラメータは、通信履歴に基づいて算出されるとユーザ負担が少なくて済むが、ユーザ端末１０のユーザにより手動で設定されてもよい。
なお、管理サーバ２０が関係パラメータを算出し、算出した関係パラメータに基づいて、キャラクタ又は実行権限の移動を制限する制御を行ってもよい。

別の例として、ユーザ端末１０ａは、キャラクタ表示アプリ１５１を実行することにより実現される機能のユーザの習熟度を判定して、判定した習熟度に基づいて、キャラクタ又は実行権限の移動を制限してもよい。この場合、ユーザ端末１０ａは、判定した習熟度が高いほど移動可能な実行権限のレベルを高くし、その習熟度が低いほど移動可能な実行権限のレベルを低く制限する、ということが考えられる。以下、移動元のユーザ端末１０ａのユーザの属性に基づいてキャラクタ又は実行権限の移動を制限する場合を説明するが、移動先のユーザ端末１０ｂのユーザの属性に基づいて、キャラクタ又は実行権限の移動を制限してもよい。
例えば、ユーザ端末１０ａは、キャラクタ表示アプリ１５１の実行中における処理の実行実績を収集し、所定のアルゴリズムによって習熟度を判定する。ここにおいて、ユーザ端末１０は、例えば、キャラクタ表示アプリ１５１の実行中に特定の操作が行われた回数が多いほど習熟度を高くしたり、キャラクタ表示アプリ１５１を用いて実行した処理の種類が多いほど習熟度を高くしたりするとよい。すなわち、ユーザがキャラクタ表示アプリ１５１に関する機能を使い慣れている場合ほど、ユーザ端末１０ａは習熟度を高くし、移動可能な実行権限のレベルを高くする。
なお、上述した第３実施形態の通信システム１に、この変形例の構成を適用する場合、前述した習熟度を、上述した第３実施形態で説明した習熟度に置き換えてもよい。また、上述した第２実施形態の通信システム１に、この変形例の構成を適用する場合、この変形例の習熟度をユーザの役職に置き換えて、ユーザの役職が高い場合ほど移動可能な実行権限のレベルを高くしてもよい。
以上のとおり、通信システム１では、ユーザ属性に基づいて、キャラクタ又は実行権限を移動させる通信を制限することができる。なお、ユーザ属性は前述の例に限定されない。

（変形例４）
通信システム１において、複数のユーザ端末１０間でキャラクタ又は実行権限を移動させようとする場合に、移動元のユーザ端末１０（ここではユーザ端末１０ａとする。）の位置と、移動先のユーザ端末１０（ここではユーザ端末１０ｂとする。）の位置とに基づいて、キャラクタ又は実行権限の移動を制限してもよい。
この変形例の通信システム１において、例えば、ユーザ端末１０ａとユーザ端末１０ｂとの位置関係が特定条件を満たす場合には、この移動を許可し、同条件を満たさない場合には不許可としてもよい。例えば、ユーザ端末１０ａは、自端末の現在位置を示す位置情報を取得する。また、ユーザ端末１０ａは、ユーザ端末１０ｂの現在位置を示す位置情報を、ユーザ端末１０ｂから取得する。ユーザ端末１０ａが取得する位置情報は、例えば、基地局測位により得られる情報、ＧＰＳ（Global Positioning System）測位により得られる情報、Ｗｉ−Ｆｉ通信等の通信エリアを特定可能な情報（Ｗｉ−Ｆｉ通信であればＳＳＩＤ）である。
ユーザ端末１０ａは、ユーザ端末１０ａ及びユーザ端末１０ｂの現在位置を示す位置情報に基づいて、両者の位置関係が特定条件を満たすどうかを判断する。同条件は、例えば、ユーザ端末１０ａとユーザ端末１０ｂとが近い位置にあることを示す条件である。例えば、ユーザ端末１０ａは、ユーザ端末１０ｂとの距離が閾値以下である場合に、キャラクタ又は実行権限の移動を許可する。又は、ユーザ端末１０ａは、ユーザ端末１０ｂと同じ基地局に接続している場合や、ユーザ端末１０ｂと同じ通信エリアで通信している場合に、キャラクタ又は実行権限の移動を許可してもよい。

別の例として、ユーザ端末１０は、自端末が特定のエリアにある場合に、キャラクタ又は実行権限の移動を許可してもよい。例えば、キャラクタ又は実行権限を他端末に移動させる処理を実行可能なエリア（例えば、前述の通信エリア）が予め決められていて、ユーザ端末１０がこのエリアにある場合に限り、キャラクタ又は実行権限の移動を許可する。
また、この変形例において、ユーザ端末１０の位置に応じて、移動可能な実行権限のレベルが制限されてもよい。例えば、ユーザ端末１０ａとユーザ端末１０ｂとの間の距離が小さいほど、移動可能な移動可能な実行権限のレベルを高くする。また、ユーザ端末１０があるエリアに応じて、移動可能な実行権限のレベルが異なっていてもよい。
なお、この変形例において、管理サーバ２０が、ユーザ端末１０から位置情報を取得して、取得した位置情報に基づいて、キャラクタ又は実行権限の移動を制限する制御を行ってもよい。

（変形例５）
上述した各実施形態のキャラクタは、人を模したもののほか、動物等の人以外の生物を模したものであってもよい。また、キャラクタは、生体の全身を模したものでなくてもよく、上述した第２実施形態の顔を模したキャラクタのように、生体の一部分を模したものであってもよい。

（変形例６）
上述した実施形態において、ユーザ端末１０の制御部１１や管理サーバ２０の制御部２１が実現する各機能は、複数のプログラムの組み合わせによって実現され、又は、複数のハードウェア資源の連係によって実現されうる。ユーザ端末１０又は管理サーバ２０の機能がプログラムを用いて実現される場合、このプログラムは、磁気記録媒体（磁気テープ、磁気ディスク（ＨＤＤ（Hard Disk Drive）、ＦＤ（Flexible Disk））等）、光記録媒体（光ディスク等）、光磁気記録媒体、半導体メモリ等のコンピュータ読取り可能な記録媒体に記憶した状態で提供されてもよいし、ネットワークを介して配信されてもよい。
また、本発明は、制御部１１又は制御部２１が実行するプログラムや、通信端末の制御方法として把握することも可能である。

１…通信システム、１０，１０ａ，１０ｂ，１０ｃ…ユーザ端末、１１…制御部、１１１…受付部、１１２…表示制御部、１１３…処理実行部、１１４…移動制御部、１２…操作部、１３…通信部、１４…表示部、１４１…ＶＲＡＭ、１５…記憶部、１５１…キャラクタ表示アプリ、１５２…権限データ、２０…管理サーバ、２１…制御部、２１１…権限管理部、２１２…通信制御部、２２…通信部、２３…記憶部、２３１，２３１ａ，２３１ｂ…端末情報管理ＤＢ、２３２，２３２ｂ…実行権限管理ＤＢ、１００…ネットワーク。

Claims (10)

1. 画像を表示する表示部と、
   自端末に与えられた特定の処理の実行権限に対応した権限データを記憶する権限データ記憶部と、
   前記権限データ記憶部に記憶された権限データに基づいて、前記実行権限を示すキャラクタを前記表示部に表示させる表示制御部と、
   前記キャラクタ又は前記実行権限を自端末と他端末との間で移動させる通信を行って、前記権限データを更新する移動制御部と
   を備え、
   前記表示制御部は、
   前記移動制御部により前記権限データが更新されると、前記表示部に表示させるキャラクタを変化させる
   通信端末。
2. 前記表示制御部は、
   前記表示部に表示されているキャラクタを、各々が前記実行権限の一部に関連付けられた複数の第１のキャラクタに変化させ、
   前記移動制御部は、
   前記複数の第１のキャラクタの少なくとも一部を前記他端末に移動させる通信を行う
   請求項１に記載の通信端末。
3. 前記移動制御部は、
   所定の前記実行権限に関連付けられた第２のキャラクタを前記他端末から自端末に移動させる通信を行い、
   前記表示制御部は、
   前記表示部に表示されているキャラクタを、前記第２のキャラクタに基づいて第３のキャラクタに変化させる
   請求項１又は２に記載の通信端末。
4. 前記権限データは、前記キャラクタを使用するゲームの進行状況を示すデータであり、
   前記ゲームを進行させる処理を行って、前記キャラクタの容姿に応じて実行権限が変化する前記特定の処理を実行する処理実行部を備え、
   前記表示制御部は、
   前記ゲームの進行に応じて前記キャラクタの容姿を変化させる
   請求項１から３のいずれか１項に記載の通信端末。
5. 前記特定の処理は、ゲームを進行させる処理以外の処理である
   請求項１から４のいずれか１項に記載の通信端末。
6. 前記表示制御部は、
   前記権限データが更新されると、前記表示部に表示されるキャラクタの構成要素を変化させ、
   前記移動制御部は、
   前記構成要素に応じて変化する前記実行権限を移動させる通信を行う
   請求項１から５のいずれか１項に記載の通信端末。
7. 前記表示制御部は、
   前記特定の処理の実行実績に応じて前記キャラクタを変化させる
   請求項１から６のいずれか１項に記載の通信端末。
8. 自端末に与えられた特定の処理の実行権限に対応した権限データを記憶する権限データ記憶部を有する通信端末のコンピュータに、
   前記権限データ記憶部に記憶された権限データに基づいて、前記実行権限を示すキャラクタを、画像を表示する表示部に表示させる第１ステップと、
   前記キャラクタ又は前記実行権限を自端末と他端末との間で移動させる通信を行って、前記権限データを更新する第２ステップと、
   前記第２ステップで前記実行権限が変化させられると、前記第１ステップで表示した前記キャラクタを変化させる第３ステップと
   を実行させるためのプログラム。
9. 通信端末の制御方法であって、
   前記通信端末に与えられた特定の処理の実行権限を示すキャラクタを表示する第１ステップと、
   前記キャラクタ又は前記実行権限を前記通信端末と他端末との間で移動させる通信を行って、前記実行権限を変化させる第２ステップと、
   前記第２ステップで前記実行権限が変化させられると、前記第１ステップで表示した前記キャラクタを変化させる第３ステップと
   を有する通信端末の制御方法。
10. 複数の通信端末とサーバ装置とを備える通信システムであって、
    前記複数の通信端末の各々が、
    画像を表示する表示部と、
    自端末に与えられた特定の処理の実行権限に対応した権限データを記憶する権限データ記憶部と、
    前記権限データ記憶部に記憶された権限データに基づいて、前記実行権限を示すキャラクタを前記表示部に表示させる表示制御部と、
    前記キャラクタ又は前記実行権限を自端末と他の前記通信端末との間で移動させる通信を、前記サーバ装置経由で行って、前記権限データを更新する移動制御部と
    を有し、
    前記表示制御部は、
    前記移動制御部により前記権限データが更新されると、前記表示部に表示させるキャラクタを変化させ、
    前記サーバ装置が、
    前記キャラクタと前記通信端末に実行権限を与える処理との関係を定めたデータベースと、
    前記データベースを参照して、前記複数の通信端末の各々に与える前記実行権限を管理する権限管理部と、
    前記複数の通信端末の各々と通信して、前記キャラクタ又は前記実行権限を移動させる通信を仲介する通信制御部と
    を有する通信システム。

Images