JP2016100712A - データ通信装置、データ通信方法、及びデータ通信プログラム - Google Patents

Abstract

【課題】無線通信に用いるプロファイルに対するサービスの追加や変更を容易にする。
【解決手段】データ通信装置は、近距離無線通信の規格に従って通信を行う通信部と、近距離無線通信の規格に従った、プロトコルの利用手法が定義されたプロファイルのうち、複数のサービスを設定可能であり且つ当該サービスに対して識別情報を対応付けている第１のプロファイルを記憶する記憶部と、アプリケーションがインストールされる場合に、前記第１のプロファイルに対して、当該アプリケーションが利用するサービスを、当該サービスに対応付けられた識別情報に基づいて追加又は更新を行う調停部と、を備える。
【選択図】図４

Description

本発明は、データ通信装置、データ通信方法、及びデータ通信プログラムに関する。

従来から、無線通信を用いてデバイス間を接続する技術が用いられている。デバイス間を接続する無線通信の規格として、Bluetooth(登録商標)が提案されている。

Bluetooth(登録商標)を用いてデバイス間を接続する際には、ペリフェラル（周辺機器：例えばキーボード等）と、セントラル（周辺機器を利用するデバイス：例えばスマートフォン等）と、が同じプロファイルが設定されている場合に接続可能としている。ところで、従来のデバイスでは、予め定められたプロファイルをファームウェアに格納した上で、製品として提供されている。

プロファイルは、機器の種類ごとに策定されたプロトコルの利用方法が定められたものである。このため、ペリフェラル側のデバイスで複数のプロファイルが設定されているものはあまり多くなかった。また、デバイスに、途中で機能を追加するためにはファームウェアを更新する必要があると共に、プロファイルを途中で追加することは難しかった。

近年、Bluetooth 4.0には、ＬＥ(Low Energy)という通信方式が提案されている。ＬＥでは、ＧＡＴＴ(Generic Attribute Profile)というプロファイルが組み込まれている。これにより、デバイスとの通信を定義するプログラムを後から追加することが可能となった。

しかしながら、ＧＡＴＴ(Generic Attribute Profile)というプロファイルで複数のサービスを提供している場合に、デバイスとの通信を定義するプログラムを用いて、サービスの追加や変更等を行う際に、整合性を取るのが難しく、自由にカスタマイズするのが難しいという問題が生じていた。

本発明は、上記に鑑みてなされたものであって、サービスの追加や変更を容易にするデータ通信装置、データ通信方法、及びデータ通信プログラムを提供することを目的とする。

上述した課題を解決し、目的を達成するために、本発明のデータ通信装置は、近距離無線通信の規格に従って通信を行う通信部と、近距離無線通信の規格に従った、プロトコルの利用手法が定義されたプロファイルのうち、複数のサービスを設定可能であり且つ当該サービスに対して識別情報を対応付けている第１のプロファイルを記憶する記憶部と、アプリケーションがインストールされる場合に、前記第１のプロファイルに対して、当該アプリケーションが利用するサービスを、当該サービスに対応付けられた識別情報に基づいて追加又は更新を行う調停部と、を備える。

本発明によれば、プロトコルの利用手法が定義されたプロファイルを用いた複数の機器間のための無線通信規格に従った無線通信で、サービスの追加や変更を容易にするという効果を奏する。

図１は、実施形態のデータ通信システムの構成の例を示す図である。 図２は、実施形態のＭＦＰのハードウェア構成を例示した図である。 図３は、実施形態のＭＦＰのソフトウェア構成を例示した図である。 図４は、実施形態の操作部の機能構成を例示した図である。 図５は、実施形態のＭＦＰのBluetooth(登録商標)で利用するプロファイル及びサービスの構成例を示した図である。 図６は、実施形態のＧＡＴＴプロファイルを構成するサービスのデータフォーマットを例示した図である。 図７は、実施形態の操作部内の調停モジュールが行う制御の例を示した図である。 図８は、実施形態のＧＡＴＴプロファイルに登録されたサービスが有する各項目を例示した図である。 図９は、実施形態のＧＡＴＴプロファイルに登録されたサービスをＸＭＬ形式で例示した図である。 図１０は、実施形態の操作部で行われるデータフローを例示した図である。 図１１は、実施形態のＭＦＰとスマートフォンとの間で行われる処理を示したシーケンス図である。 図１２は、実施形態のアドバタイズメント・パケットのデータ構造例を示した図である。 図１３は、実施形態のＭＦＰにアプリケーションをインストールする際に行われる登録を示したシーケンス図である。 図１４は、実施形態の操作部にアプリケーションが追加される際に行われる処理を示した図である。 図１５は、キャラクタリスティックの登録処理を示した図である。 図１６は、実施形態のＭＦＰでアプリケーションのアンインストールで、サービスの削除の際に行われる通信を示したシーケンス図である。 図１７は、実施形態のＭＦＰでアプリケーションのアンインストールで、キャラクタリスティックの削除の際に行われる通信を示したシーケンス図である。 図１８は、実施形態の操作部における、プログラムのアンインストールに伴うサービスの削除処理の手順を示すフローチャートである。 図１９は、キャラクタリスティックの削除処理を示した図である。

以下に添付図面を参照して、データ通信装置、データ通信方法、及びデータ通信プログラムの実施形態を詳細に説明する。

図１は、実施形態のデータ通信システム１００の構成の例を示す図である。図１に示されるように、データ通信システム１００は、ＭＦＰ１と、スマートフォン５と、で構成されている。ＭＦＰ１、及びスマートフォン５は、それぞれ無線通信インターフェースを備えている。当該無線通信インターフェースは、用途に応じてプロトコルの利用手法が定義されたプロファイルが複数の機器で対応している場合に当該複数の機器間の通信が可能な近距離無線通信の規格に従ったものであり、本実施形態ではBluetooth（登録商標）に従ったものとする。

図１に示す例では、ＭＦＰ１がペリフェラル（周辺機器）側とし、スマートフォン５がセントラル（周辺機器を利用するデバイス）側とする。

本実施形態のＭＦＰ１は、アプリケーションをインストールすることで、インストールされたアプリケーションに基づく機能によるサービスを提供することが可能となる。例えば、新しいスキャナアプリケーションをインストールすることで、当該アプリケーションが有する新しいスキャナモードの情報や、カウンタ情報や、ジョブ履歴など、従来参照できなかったデータの提供が可能となる。当該データを提供するためのサービスは、Bluetooth（登録商標）のプロファイルに対して、新しいサービスとして追加しても良いし、従来のサービスの一部として追加拡張を行っても良い。

本実施形態は、新しいサービスの追加や、従来のサービスの一部として追加拡張を行うためのプロファイルとして、ＧＡＴＴプロファイルを用いる例とする。

ＧＡＴＴ(Generic Attribute Profile)プロファイルは、デバイスとの通信定義するプログラムを後から追加可能なプロファイルであって、サービス、キャラクタリスティック、ディスクリプタと称される３つの要素で構成されている。当該ＧＡＴＴプロファイルは、一つ又は複数のサービスを設定可能とする。そして、ＧＡＴＴプロファイルのサービスの追加や一部拡張を行うことで、新しい機能の追加や機能の変更を実現できる。

ＧＡＴＴプロファイルにおいて、サービスはプロファイルの一機能を表している。本実施形態では、ＸＭＬ形式のファイルを用いることで、サービスは、複数の入れ子になっているサービスと複数のキャラクタリスティックから構成される。

また、キャラクタリスティックは、単一の値を持った属性情報を表している。キャラクタリスティックは、キャラクタリスティック自体の値、値へのアクセス方法を定義するプロパティ、複数のディスクリプタで構成されている。

ディスクリプタはキャラクタリスティックに付加情報が必要な際に用いられる属性情報を表している。なお、キャラクタリスティックによってはディスクリプタは定義されていない場合がある。

本実施形態において、サービス及びディスクリプタを特定するために、サービス及びディスクリプタの各々に対してユニークな識別情報であるＵＵＩＤ（Universally Unique Identifier）を付与している。

次に、ＭＦＰ１のハードウェア構成の例について説明する。図２は、実施形態のＭＦＰ１のハードウェア構成を例示した図である。図２に示すように、ＭＦＰ１は、本体部１０と操作部２０とを備える。本体部１０は、コピー機能、スキャナ機能、ファクス機能、プリンタ機能等の各種の機能を実現する。操作部２０は、ユーザの操作に応じた情報を受け付ける。なお、ユーザの操作に応じた情報とは、例えば画面の座標値を示す信号等とする。

本体部１０及び操作部２０は、接続Ｉ／Ｆ１６、専用の通信路３０、及び接続Ｉ／Ｆ２６を介して相互に通信可能に接続されている。通信路３０は、例えばＵＳＢ（Universal Serial Bus）規格を用いることができるが、有線か無線かを問わず任意の規格でよい。

本体部１０は、操作部２０で受け付けた操作に応じた動作を行う。また、本体部１０は、図示されていないクライアントＰＣ（パーソナルコンピュータ）等の外部装置とも通信可能であり、外部装置から受信した指示（印刷指示等）に応じた動作を行うこともできる。

本体部１０のハードウェア構成について説明する。図２に示されるように、本体部１０は、ＣＰＵ１１、ＲＯＭ１２、ＲＡＭ１３、ＨＤＤ（ハードディスクドライブ）１４、通信Ｉ／Ｆ１５、接続Ｉ／Ｆ１６、及びエンジン部１７を備える。ＣＰＵ１１、ＲＯＭ１２、ＲＡＭ１３、ＨＤＤ１４、通信ＩＦ１５、接続ＩＦ１６及びエンジン部１７はシステムバス１８を介して相互に接続されている。

ＣＰＵ１１は本体部１０の動作を統括的に制御する。ＣＰＵ１１はＲＡＭ１３をワークエリア（作業領域）としてＲＯＭ１２又はＨＤＤ１４等に格納されたプログラムを実行することで、本体部１０全体の動作を制御し、上述したコピー機能、スキャナ機能、ファクス機能、プリンタ機能等の各種機能を実現する。

通信Ｉ／Ｆ１５は、ネットワーク３５と接続するためのインターフェースとする。接続Ｉ／Ｆ１６は、通信路３０を介して操作部２０と通信するためのインターフェースとする。

エンジン部１７はコピー機能、スキャナ機能、ファクス機能及びプリンタ機能を実現させるための、汎用的な情報処理及び通信以外の処理を行うハードウェアである。例えば、原稿の画像をスキャンして読み取るスキャナ、用紙等のシート材への印刷を行うプロッタ、ファクス通信を行うＦＡＸ部等を備えている。エンジン部１７は、更に、印刷済みシート材を仕分けるフィニッシャや、原稿を自動給送するＡＤＦ（自動原稿給送装置）のような特定のオプションを実現するためのハードウェアを備えていてもよい。

次に操作部２０のハードウェア構成について説明する。図２に示すように、操作部２０は、ＣＰＵ２１、ＲＯＭ２２、ＲＡＭ２３、フラッシュメモリ２４、通信Ｉ／Ｆ２５、接続Ｉ／Ｆ２６、操作パネル２７、及び外部接続Ｉ／Ｆ２８を備える。ＣＰＵ２１、ＲＯＭ２２、ＲＡＭ２３、フラッシュメモリ２４、通信ＩＦ２５、接続ＩＦ２６、操作パネル２７及び外部接続Ｉ／Ｆ２８は、システムバス２９を介して相互に接続されている。

ＣＰＵ２１は、操作部２０の動作を統括的に制御する。ＣＰＵ２１はＲＡＭ２３をワークエリア（作業領域）としてＲＯＭ２２又はフラッシュメモリ２４等に格納されたプログラムを実行することで、操作部２０全体の動作を制御し、ユーザから受け付けた入力に応じた情報（画像）の表示等を実現する。

通信Ｉ／Ｆ２５は、ネットワーク３５と接続するためのインターフェースとする。また、通信Ｉ／Ｆ２５は、ＢＬＥモジュール２５Ａを備えている。ＢＬＥモジュール２５Ａは、ＢＬＥ（Bluetooth 4.0 low energy）規格準拠に対応したモジュールとする。通信Ｉ／Ｆ２５は、ＢＬＥモジュール２５Ａを搭載することで、近距離無線通信の規格に従って、ＢＬＥ規格準拠に対応した他のデバイスとの間で無線通信を行う通信部として機能する。本実施形態は、用途に応じてプロトコルの利用手法が定義されたプロファイルが複数の機器で対応している場合に当該複数の機器間の通信が可能な近距離無線通信の規格として、ＢＬＥ規格を用いた例について説明するが、他の通信規格を用いても良い。

接続Ｉ／Ｆ２６は、通信路３０を介して本体部１０と通信するためのインターフェースとする。

操作パネル２７は、ユーザの操作に応じた各種の入力を受け付けるとともに、各種の情報（例えば受け付けた操作に応じた情報、ＭＦＰ１の動作状況を示す情報、設定状態などを示す情報など）を表示する。本実施形態の操作パネル２７は、タッチパネル機能を搭載した液晶表示装置（ＬＣＤ）で構成されるが、これに制限するものではない。例えばタッチパネル機能が搭載された有機ＥＬ表示装置で構成してもよい。さらに、これに加えて又はこれに代えて、ハードウェアキー等の操作部やランプ等の表示部を設けてもよい。

外部接続Ｉ／Ｆ２８は、ＩＣカードリーダー３と接続するためのインターフェースとする。

次に、ＭＦＰ１のソフトウェア構成について説明する。図３は、本実施形態のＭＦＰ１のソフトウェア構成を例示した図である。図３に示されるように、本体部１０は、アプリ層１０１と、サービス層１０２と、ＯＳ層１０３と、を備えている。アプリ層１０１、サービス層１０２及びＯＳ層１０３の実体は、ＲＯＭ１２やＨＤＤ１４等（図２参照）に格納されている各種ソフトウェアである。ＣＰＵ１１が、これらのソフトウェアを実行することにより、各種の機能が提供される。

アプリ層１０１のソフトウェアは、ハードウェア資源を動作させて所定の機能を提供するためのアプリケーションソフトウェア（以下の説明では、単に「アプリ」と称する場合がある）である。例えばアプリとしては、コピー機能を提供するためのコピーアプリ、スキャナ機能を提供するためのスキャナアプリ、ファクス機能を提供するためのファクスアプリ、プリンタ機能を提供するためのプリンタアプリなどが挙げられる。

サービス層１０２のソフトウェアは、アプリ層１０１とＯＳ層１０３との間に介在し、アプリに対し、本体部１０が備えるハードウェア資源を利用するためのインターフェースを提供するためのソフトウェアである。より具体的には、ハードウェア資源に対する動作要求の受付、動作要求の調停を行う機能を提供するためのソフトウェアである。サービス層１０２が受け付ける動作要求としては、スキャナによる読み取りやプロッタによる印刷等の要求が考えられる。

なお、サービス層１０２によるインターフェースの機能は、本体部１０のアプリ層１０１だけではなく、操作部２０のアプリ層２０１に対しても提供される。すなわち操作部２０のアプリ層２０１（アプリ）も、サービス層１０２のインターフェース機能を介して、本体部１０のハードウェア資源（例えば図２のエンジン部１７）を利用した機能を実現することができる。

ＯＳ層１０３のソフトウェアは、本体部１０が備えるハードウェアを制御する基本機能を提供するための基本ソフトウェア（オペレーティングシステム）である。サービス層１０２のソフトウェアは、各種アプリからのハードウェア資源の利用要求を、ＯＳ層１０３が解釈可能なコマンドに変換してＯＳ層１０３に渡す。そして、ＯＳ層１０３のソフトウェアによりコマンドが実行されることで、ハードウェア資源は、アプリの要求に従った動作を行う。

同様に、操作部２０は、アプリ層２０１と、サービス層２０２と、ＯＳ層２０３とを有する。操作部２０が備えるアプリ層２０１、サービス層２０２、及びＯＳ層２０３も、階層構造については本体部１０と同様である。ただし、アプリ層２０１のアプリにより提供される機能や、サービス層２０２が受け付け可能な動作要求の種類は、本体部１０とは異なる。アプリ層２０１のアプリは、操作部２０が備えるハードウェア資源を動作させて所定の機能を提供するためのソフトウェアであってもよいが、主として本体部１０が備える機能（コピー機能、スキャナ機能、ファクス機能及びプリンタ機能）に関する操作や表示を行うためのＵＩ（ユーザインターフェース）の機能を提供するためのソフトウェアである。

なお、本実施形態では、機能の独立性を保つために、本体部１０のＯＳ層１０３のソフトウェアと、操作部２０のＯＳ層２０３のソフトウェアが互いに異なる。つまり、本体部１０と操作部２０は、別々のオペレーティングシステムで互いに独立して動作する。例えば、本体部１０のＯＳ層１０３のソフトウェアとしてＬｉｎｕｘ（登録商標）を用い、操作部２０のＯＳ層２０３のソフトウェアとしてＡｎｄｒｏｉｄ（登録商標）を用いることを可能とする。

以上のように、実施形態のＭＦＰ１において、本体部１０と操作部２０は別々のオペレーティングシステムで動作するため、本体部１０と操作部２０との間の通信は、共通の装置内のプロセス間通信ではなく、異なる装置間の通信として行われる。異なる装置間の通信として例えば、操作部２０が受け付けた情報（ユーザからの指示内容）を本体部１０へ伝達する動作（コマンド通信）や、本体部１０が操作部２０へイベントを通知する動作等がある。ここでは操作部２０が本体部１０へコマンド通信を行うことにより、本体部１０の機能を使用できる。また、本体部１０から操作部２０に通知するイベントには、本体部１０における動作の実行状況や、本体部１０で設定された情報等が挙げられる。

また、本実施形態では、操作部２０に対する電力供給は、本体部１０から通信路３０を経由して行われている。このため、操作部２０の電源制御を、本体部１０の電源制御とは別に（独立して）行うことができる。

次に、操作部２０の機能構成について説明する。図４は、操作部２０の機能構成を例示した図である。図４に示される例では、操作部２０は、上層から順に、アプリ層２０１と、サービス層２０２と、ＯＳ層２０３と、ハードウェア層２０４と、により構成されている。

アプリ層２０１には、インストーラ４０１と、第１のアプリケーション４０２と、第２のアプリケーション４０３と、第３のアプリケーション４０４と、第５のアプリケーション４０５と、を備えている。

インストーラ４０１は、ＵＩを介して、ユーザからのアプリケーションのインストール（追加）を制御する。

新しいアプリケーションがアプリ層２０１にインストールされる際に、当該アプリケーションは、サービス層２０２の調停モジュール４１２に対して、ＧＡＴＴプロファイルに対するサービスの登録を要求する。

本実施形態の調停モジュール４１２は、このような登録要求に従って、Bluetooth(登録商標)の無線通信を行うために、ＧＡＴＴプロファイルにサービスを追加する。そして、調停モジュール４１２に対してサービスの登録要求したアプリケーションは、ＧＡＴＴプロファイルに登録されたサービスを用いて無線通信が可能となる。さらには、調停モジュール４１２からの様々な通知を受け取ることが可能となる。

サービス層２０２は、アプリケーション管理部４１１と、調停モジュール４１２と、を備えている。

アプリケーション管理部４１１は、アプリ層２０１にインストールされた各アプリケーションの起動状態又は停止状態であるかを管理する。そして、アプリケーション管理部４１１は、各アプリケーションの状態を、調停モジュール４１２に通知する。つまり、アプリケーション管理部４１１は、インストールされたプログラムが起動しているかを検出する検出部として機能する。

調停モジュール４１２は、ＵＵＩＤ重複チェック機能４２１と、ＧＡＴＴサービス制御部４２２と、ＧＡＴＴデータ制御部４２３と、ＧＡＴＴサービス停止／再開機能４２４と、ＧＡＴＴデータ停止／再開機能４２５と、保存機能４２６と、通知機能４２７と、ＧＡＴＴデータ送受信機能４２８と、を備えている。

本実施形態の調停モジュール４１２は、インストールされたアプリケーションからの要求に従って、ＧＡＴＴプロファイルに対してサービスやキャラクタリスティック等の追加を行う。

ところで、本実施形態では、ＭＦＰ１のアプリ層２０１にインストールされるアプリケーションが使用するサービス及びキャラクタリスティック毎にＵＵＩＤを対応付けている。

図５は、本実施形態のＭＦＰ１のBluetooth(登録商標)で利用するプロファイル及びサービスの構成例を示した図である。ＭＦＰ１は、複数のプロファイルを備えることができるものとする。そして、図５に示される例では、第１のプロファイル５０１、第２のプロファイル５０２、及び第３のプロファイル５０３が備えられている。プロファイルとしては、例えば、ＨＩＤ、ＨＦＰ、ＨＳＰ，Ａ２ＤＰ、ＳＰＰ、ＧＡＴＴ等とする。

図５に示される例では、第２のプロファイル５０２が、ＧＡＴＴプロファイルであって複数のサービスを構成可能な例とする。そして、サービスより下層にはキャラクタリスティック（以下、データとも称する）が一つ又は複数個定義可能としている。

調停モジュール４１２は、アプリケーションのインストールに伴って、サービス（例えば、第３のサービス５２１）の追加や、サービスの一部拡張、換言すればデータ（例えば、第３のキャラクタリスティック５３１）の追加を可能としている。

図６は、ＧＡＴＴプロファイルを構成するサービスのデータフォーマットを例示した図である。図６に示されるように、サービスの定義(“Service Definition”)として、“Service Declaration”６０１と、キャラクタリスティックの定義（“Characteristic Definition”）６０２と、を含んでいる。

サービスには、“Attribute Handle”、“Attribute Type”、“Attribute Value”６１１、“Attribute Permissions”が定義されている。“Attribute Value”６１１には、サービスに割り当てられたＵＵＩＤ(Universally Unique Identifier)が設定されている。

キャラクタリスティックには、“Attribute Handle”、“Attribute Type”、“Attribute Value”、“Attribute Permission”が定義されている。“Attribute Type”６１２には、キャラクタリスティックに割り当てられたＵＵＩＤ(Universally Unique Identifier)が設定されている。

例えば、“Characteristic Value Definition”６１３を追加することで、既存のサービスに対して、キャラクタリスティックを追加できる。また、追加された“Characteristic Value Definition”６１３も、“Attribute Type”６１４に、キャラクタリスティックに割り当てられたＵＵＩＤ(Universally Unique Identifier)が設定されている。

本実施形態では、各アプリケーションが利用するサービス及びキャラクタリスティック毎に、ＵＵＩＤが予め定められている。このため、アプリケーションをインストールする際に、他のアプリケーションのサービスやキャラクタリスティックと重複することなく、サービスやキャラクタリスティックの追加を実現している。次に、図４に戻り、調停モジュール４１２の各構成について説明する。

図４に戻り、調停モジュール４１２が、ＧＡＴＴプロファイルに対して、インストールされるアプリケーションが利用するサービスを、当該サービスに対応付けられたＵＵＩＤに基づいて追加又は更新を行う調停部として機能する。

本実施形態では、調停モジュール４１２がサービスの追加又は更新を行う際に、ＵＵＩＤ重複チェック機能４２１が、ＧＡＴＴプロファイルに格納されているサービスに付与されているＵＵＩＤと重複しているか否かを判定する。

そして、ＵＵＩＤ重複チェック機能４２１が、インストールされるアプリケーションが利用する第１のサービスと同じＵＵＩＤが割り当てられた他のサービスがＧＡＴＴプロファイルに格納されてないと判定した（重複していないと判定された）場合に、調停モジュール４１２のＧＡＴＴサービス制御部４２２は、当該第１のサービスを、ＧＡＴＴプロファイルに追加する。

本実施形態では、異なるアプリケーションが利用する異なるサービスについて同じＵＵＩＤが割り当てられないようにしているが、機能が同じアプリケーションが複数インストールされる場合や、既にインストール済みのアプリケーションをバージョンアップする場合に、同じＵＵＩＤのサービスが追加されることも考えられる。このような場合には、当該サービスの更新するのが望ましい。

そこで、ＵＵＩＤ重複チェック機能４２１が、インストールされるアプリケーションが利用する第１のサービスと同じＵＵＩＤが割り当てられた他のサービスがＧＡＴＴプロファイルに格納されていると判定した（重複していると判定された）場合に、調停モジュール４１２のＧＡＴＴサービス制御部４２２は、当該第１のサービスを用いて、ＧＡＴＴプロファイルに格納されている他のサービスを更新する。ただし、本実施形態では、追加許可が設定されている場合に限り、更新可能としている。

このように、本実施形態は、ＵＵＩＤ重複チェック機能４２１が、アプリケーションがインストールされる際に、当該アプリケーションが利用するサービスのＵＵＩＤとキャラクタリスティックのＵＵＩＤとが、すでにＧＡＴＴプロファイルに登録されているサービスのＵＵＩＤとキャラクタリスティックのＵＵＩＤとが、重複するか否かを判定している。

ＧＡＴＴサービス制御部４２２は、アプリケーションに従って、ＧＡＴＴプロファイルのサービスを制御する。例えば、アプリケーションがインストールされる場合に、ＧＡＴＴプロファイルに対して、当該サービスの追加や既存サービスの更新（拡張）等を行う。

ＧＡＴＴデータ制御部４２３は、アプリケーションに従って、当該アプリケーションが利用するキャラクタリスティックを制御する。例えば、アプリケーションがインストールされる場合に、ＧＡＴＴプロファイルに対して、当該キャラクタリスティックの追加等を行う。

保存機能４２６は、フラッシュメモリ２４に対する保存を行う。例えば、保存機能４２６は、アプリケーションと、当該アプリケーションが利用するサービス及びキャラクタリスティックのＵＵＩＤと、を対応付けて保存する。

ハードウェアであるフラッシュメモリ２４は、プロファイルを記憶する記憶部として機能する。本実施形態では、少なくともＧＡＴＴプロファイルが格納されているが、他のプロファイルが格納されていても良い。さらには、フラッシュメモリ２４は、後述する管理テーブルを記憶する。

インストールされたアプリケーションには、プロセス名（プロセスＩＤ）が割り当てられており、インストールする際に、当該プロセス名（プロセスＩＤ）も登録される。そして、調停モジュール４１２の保存機能４２６は、当該プロセス名（プロセスＩＤ）と共に、プロセス名（プロセスＩＤ）とＵＵＩＤとを対応付けて（図示しない）管理テーブルに登録することで、どのようなサービスが存在するのかを把握できると共に、ＵＵＩＤの重複確認が可能となる。このように、本実施形態では、管理テーブルにおいて、アプリケーションと、サービスと、の対応関係を管理している。さらに、管理テーブルは、アプリケーションと、キャラクタリスティックとの対応関係を管理しても良い。

本実施形態では、管理テーブルに、アプリケーション（プロセスＩＤ）と、サービス（ＵＵＩＤ）及びキャラクタリスティックと、の対応関係を保持することで、セントラルからデータ（キャラクタリスティック）の書き込み要求がきた場合に起動すべきアプリケーションを特定できる。そして、通知機能４２７は、特定されたアプリケーションが起動した後、当該アプリケーションに対して、書き込み要求があったことを通知する。その際に、書き込まれたデータ等を送信しても良い。

さらには、アプリケーションをアンインストールする際に、削除対象となるサービス及びキャラクタリスティックを特定できる。さらに、アプリケーションの起動状態に応じて、当該サービスの停止／起動を制御できる。

ＧＡＴＴサービス停止／再開機能４２４は、アプリケーション管理部４１１が検出したアプリケーションの状態に応じて、当該アプリケーションが使用するサービスの停止又は再開を制御する。

ＧＡＴＴデータ停止／再開機能４２５は、アプリケーション管理部４１１が検出したアプリケーションの状態に応じて、当該アプリケーションが使用するキャラクタリスティックの停止又は起動を制御する。

このように、本実施形態のＧＡＴＴサービス停止／再開機能４２４及びＧＡＴＴデータ停止／再開機能４２５は、アプリケーションが起動している間に限り、当該アプリケーションに関連するサービス及びキャラクタリスティックが利用できるように制御する。

さらに、ＭＦＰ１本体が省エネ移行、復帰やプロセスの起動、停止を行うタイミングにおいて、ＧＡＴＴサービス停止／再開機能４２４は、各サービスの起動、停止制御を行う。同様に、ＭＦＰ１本体が省エネ移行、復帰やプロセスの起動、停止を行うタイミングにおいて、ＧＡＴＴデータ停止／再開機能４２５は、各キャラクタリスティックの起動、停止制御を行う。

本実施形態では、セントラル側（例えば、スマートフォン５）から、ＧＡＴＴプロファイルのデータ（キャラクタリスティック）に対して書き込み（Write権限ありデータの場合）要求が発生した場合には、通信Ｉ／Ｆ２５及びBluetoothスタック４３１を介して調停モジュール４１２にその旨が通知される。

そして、調停モジュール４１２は、書き込み要求があったＧＡＴＴプロファイルのデータ（キャラクタリスティック）から、当該キャラクタリスティックを有するサービスを特定する。そして、調停モジュール４１２は、サービスと、アプリケーションと、の対応関係を管理している管理テーブルから、どのアプリケーションが利用するかを特定する。そして、調停モジュール４１２が、当該アプリケーションの起動制御を行った上で、当該データの書き込みを制御する。

当該書き込み制御は、ＧＡＴＴプロファイルに設定されたキャラクタリスティックのタイプが、Read属性だけではなく、Write属性を持つものが対象とされる。Write属性を有する場合に、ペリフェラル側からセントラル側にデータを書き込みできる。

通知機能４２７は、アプリ層２０１に格納されている各アプリケーションに対して通知を行う。

例えば、通知機能４２７は、調停モジュール４１２が、セントラル側からアクセスがあったことを、Bluetoothスタック４３１を介して検出した場合に、通知機能４２７は、当該アクセスの対象であるアプリケーションに対して起動するように通知を行う。

ＧＡＴＴデータ送受信機能４２８は、Bluetoothスタック４３１を介して、外部機器との間でデータの送受信を可能とする。

ＯＳ層２０３には、Bluetoothスタック４３１が格納されている。Bluetoothスタック４３１は、操作部２０においてBluetooth(登録商標)を利用するためのドライバであって、ＧＡＴＴプロファイルを含む複数のプロファイルに対応している。例えば、Bluetoothスタック４３１は、当該ＧＡＴＴプロファイルを利用することで、ＧＡＴＴプロファイルに登録された各種サービスを提供できる。以降、Bluetoothスタック４３１がＧＡＴＴプロファイルを利用した際に、呼び出し可能なライブラリを、BluetoothGattとも称する。

例えば、Bluetoothスタック４３１は、ＧＡＴＴデータ送受信機能４２８からの要求に従って、通信Ｉ／Ｆ２５を介して送信制御を行う送信制御部として機能する。例えば、Bluetoothスタック４３１は、ＧＡＴＴデータ送受信機能４２８からの要求に従って、通信Ｉ／Ｆ２５を介して、外部の機器に対してアドバタイジング・パケットの送信制御を行う。

また、Bluetoothスタック４３１は、ＧＡＴＴデータ送受信機能４２８からの要求に従って、ＧＡＴＴデータ送受信機能４２８からの要求に従って、通信Ｉ／Ｆ２５を介して外部の機器からの情報の受信制御を行う受信制御部として機能しても良い。

図７は、操作部２０内の調停モジュール４１２が行う制御の例を示した図である。図７に示されるように、調停モジュール４１２が、ＭＦＰ１の省エネ移行、及び復帰を行うタイミングに合わせて、各アプリケーション（例えば、キーボードアプリ）や、各サービス（例えば、スマホ向けＭＦＰサービス、その他ペリフェラルサービス）の起動、停止を行う。この制御に、調停モジュール４１２の通知機能４２７を用いても良い。また、省エネ移行拒否などの処理は、調停モジュール４１２が代表して行うことで、各サービスの省エネ復帰処理のタイミングをあわせることができる。また、各サービスの負荷を低減できる。

また、操作部２０が、セントラルとペリフェラルの２つの機能を持つ場合には、セントラル及びペリフェラルの同時動作ができない。このため、調停モジュール４１２は、操作部２０全体を停止させてから切り替えることで、動作モードの不整合が発生しないようにする。さらに、調停モジュール４１２は、実行中のサービスがある場合に、当該サービス停止拒否をしたり、モード切替（例えば、ペリフェラルからセントラルに切り替え）を拒絶したりする。

図８は、本実施形態のＧＡＴＴプロファイルに登録されたサービスが有する各項目（キャラクタリスティック）を例示した図である。図８に示される例では、ＭＦＰ１のＩＰアドレスや無線ＬＡＮの接続情報を渡せるため、Bluetooth(登録商標)からWi-Fi Directにハンドオーバーする機能に必要な項目（キャラクタリスティック）の一部が示されている。また、図８に示されるように、本実施形態では、項目毎にＵＵＩＤが対応付けられている。さらに、本実施形態では、項目毎にtype(変数の型)、properties、permissions（例えばWrite権限、Read権限、実行権限）、Value(固定値)が対応付けられている。

図９は、ＧＡＴＴプロファイルに登録されたサービスをＸＭＬ形式で例示した図である。図９に示される例のうち、領域９０１には、図８で示されたサービスが登録されている。図９に示されるＸＭＬ形式を用いることで、キャラクタリスティックのValueやTypeを指定できる。さらには、アプリケーションが、調停モジュール４１２に登録するデータとして、ＸＭＬ形式を用いることで、カスタマイズしやすいフォーマットで提供可能となる。

図１０は、本実施形態の操作部２０で行われるデータフローを例示した図である。図１０に示される例では、アプリケーション等で利用されるサービス１０００が、BluetoothGattを用いて、スマートフォン５との間でデータの送受信をする例とする。

まず、（１）サービス１０００が、BluetoothGatt１００１に対して、“startBroadcast”を出力し、ブロードキャストの開始を指示する。そして、（２）BluetoothGatt１００１は、指示に従って、アドバタイズメント・パケットを設定する。次に、（３）BluetoothGatt１００１は、ブロードキャストの開始を指示する。そして、（４）ＢＬＥモジュール２５Ａは、デバイスを発見するためのアドバタイズメント・パケットをブロードキャストする。

そして、（５）アドバタイズメント・パケットを受信したスマートフォン５は、接続リクエストを送信する。

次に、（６）BluetoothGatt１００１は、ＢＬＥモジュール２５Ａから、接続イベントを受け付ける。（７）BluetoothGatt１００１は、サービス１０００に対して、“onConnectionStateChange”を受け渡す。これにより、（８）サービス１０００は、BluetoothGatt１００１に“connect”を出力する。これにより、サービス１０００と、スマートフォン５と、の間に接続がなされたことになる。

そして、（９）BluetoothGatt１００１は、ＢＬＥモジュール２５Ａに対して、“CommandComplete”を受け渡す。これにより、（１０）ＢＬＥモジュール２５Ａは、スマートフォン５に対して、接続完了を通知する。

その後、（１１）スマートフォン５は、サービス及びキャラクタリスティック（Service／Characteristic）を要求する。そして、（１２）ＢＬＥモジュール２５Ａは、BluetoothGatt１００１に、サービスのイベントを受け渡す。（１３）BluetoothGatt１００１は、サービス１０００に対して、“onCharacteristicReadRequest”を受け渡す。これにより、当該サービスのキャラクタリスティックが読み込まれる。

そして、（１４）サービス１０００は、BluetoothGatt１００１に対して、“sendResponse”を受け渡す。これにより、読み込まれたキャラクタリスティックが受け渡される。

そして、（１５）BluetoothGatt１００１は、サービスの応答をＢＬＥモジュール２５Ａに出力する。次に、（１６）ＢＬＥモジュール２５Ａは、スマートフォン５に、サービス及びキャラクタリスティック（Service／Characteristic）の応答を送信する。

上述したデータフローにより、通信を確立した上で、キャラクタリスティック（データ）の受け渡しを可能とする。

次に、ＭＦＰ１のデータを取得する際に行われる処理について説明する。図１１は、本実施形態のＭＦＰ１とスマートフォン５との間で行われる処理を示したシーケンス図である。図１１に示される例では、スマートフォン５がセントラル側となり、ＭＦＰ１がペリフェラル側となる。

まず、スマートフォン５は、ＧＡＴＴプロファイルの“Primary Service Discovery”機能である“Discovery Service By UUID”サブプロシージャーを利用して、ＭＦＰ１が提供するサービス（例えば、ジョブ状態、カウンタ情報、センサー情報など）として規定されたＵＵＩＤを用いてサービスの検索を要求する（ステップＳ１１０１）。

次に、ＭＦＰ１は、要求されたサービスと、提供しているサービスとが一致した場合に、当該サービスのハンドルを、スマートフォン５に受け渡す（ステップＳ１１０２）。

そして、スマートフォン５は、ＧＡＴＴプロファイルの“Discovery Characteristic by UUID”サブプロシージャーを利用して、キャラクタリスティックの検索を要求する（ステップＳ１１０３）。

次に、ＭＦＰ１は、要求されたキャラクタリスティックと、提供しているキャラクタリスティックとが一致した場合に、当該キャラクタリスティックのハンドルを、スマートフォン５に受け渡す（ステップＳ１１０４）。

そして、スマートフォン５は、ＧＡＴＴプロファイルの“Characteristic Value Read”機能の“Read Characteristic Value”サブプロシージャーを利用して、取得したＭＦＰ１のキャラクタリスティックのハンドルから、ＭＦＰ１のデータの取得を要求する（ステップＳ１１０５）。

そして、ＭＦＰ１は、要求されたデータを、スマートフォン５に受け渡す（ステップＳ１１０６）。そして、上述した処理を、キャラクタリスティックのＵＵＩＤ毎に繰り返して、必要なデータを取得する。

上述したように、セントラル側からアクセスがあった場合、調停モジュール４１２は、受け渡されたＵＵＩＤを基づいて、管理テーブルで対応付けられているアプリケーション（プロセスＩＤ）を特定する。当該アプリケーションが起動していない場合、調停モジュール４１２は、当該アプリケーションを起動させ、サービスハンドルを受け渡す。同じサービスでもキャラクタリスティックごとに異なるアプリケーションがデータ管理をしている場合、調停モジュール４１２は、次に受け渡されるキャラクタリスティックのＵＵＩＤに基づいて、対応付けられているアプリケーションを特定する。

調停モジュール４１２は、アプリケーション管理部４１１から、各アプリケーションが起動しているかを示す情報を取得できる。セントラル側から、ＧＡＴＴプロファイルで定義されたデータ（キャラクタリスティック）の書き込み要求があった際に、取得した情報に基づいて、通知すべきアプリケーションが起動していないと判断した場合に、通知機能４２７が、当該アプリケーションを起動するように通知を行う。その後に、通知機能４２７は、起動したアプリケーションに対して、データの書き込み要求を通知する。

調停モジュール４１２は、アプリケーションのインストールに伴って、サービスやキャラクタリスティックが変更された場合、Bluetooth(登録商標)のアドバタイズメント・パケットで、セントラル（クライアント側）に通知する。

図１２は、本実施形態のアドバタイズメント・パケットのデータ構造例を示した図である。図１２に示されるデータ構造のうち、majorバージョン欄１９０１又はminorバージョン欄１９０２を、サービスやキャラクタリスティックの変更に用いる。例えば、１bit目が１の場合には、ＭＦＰ１が電源ＯＮしてから変更があったことを示している。また、変更されるごとに数値を１つインクリメントし、変更履歴がクライアント側で管理できるようにしてもよい。

次に、ＭＦＰ１にアプリケーションをインストールする際に行われる処理について説明する。図１３は、本実施形態のＭＦＰ１にアプリケーションをインストールする際に行われる登録を示したシーケンス図である。

まず、インストールされるアプリケーションが、調停モジュール４１２に対して、当該アプリケーションのサービス登録を要求する（ステップＳ１２０１）。その際に、サービスを示すＵＵＩＤの他に、プロセス名（プロセスＩＤ）も受け渡される。これにより、サービス及びキャラクタリスティックと、プロセスと、の対応付けが可能となる。

その後、調停モジュール４１２が、アプリケーションに対して、サービスのＵＵＩＤが重複されているか否かに基づく登録可否を通知する（ステップＳ１２０２）。図１３に示す例では登録可能と判断された例とする。

そして、アプリケーションは調停モジュール４１２に対して、サービスを構成するキャラクタリスティックの登録を要求する（ステップＳ１２０３）。その際に、キャラクタリスティックを示すＵＵＩＤの他に、当該キャラクタリスティックを示すＸＭＬ形式のデータも受け渡される。これにより、ＧＡＴＴプロファイルに、アプリケーションが利用するサービスを構成するキャラクタリスティックが追加される。なお、登録可能か否か判断する処理手順については後述する。

その後、調停モジュール４１２が、アプリケーションに対して、キャラクタリスティックのＵＵＩＤが重複されているか否かに基づく登録可否を通知する（ステップＳ１２０４）。

上述した処理手順により、調停モジュール４１２にアプリケーションに関するデータが登録される。

次に、操作部２０にアプリケーションが追加される際に行われる処理について説明する。図１４は、本実施形態の操作部２０に上述した処理を示した図である。

まず、インストーラ４０１が、アプリ層２０１に対するアプリケーションのインストール要求を受け付ける（ステップＳ１３０１）。

次に、調停モジュール４１２が、インストールされるアプリケーションから、サービスの登録要求を受け付けたか否かを判定する（ステップＳ１３０２）。受け付けていない場合（ステップＳ１３０２：Ｎｏ）、再びステップＳ１３０２の処理を行う。

一方、調停モジュール４１２が、インストールされるアプリケーションから、サービスの登録要求を受け付けたと判定した場合（ステップＳ１３０２：Ｙｅｓ）、ＵＵＩＤ重複チェック機能４２１が、登録要求を受け付けたサービスのＵＵＩＤと、既存サービスのＵＵＩＤとが、一致しているか否かを判定する（ステップＳ１３０３）。

ＵＵＩＤ重複チェック機能４２１が、一致していると判定した場合（ステップＳ１３０３：Ｎｏ）、通知機能４２７が、インストールされるアプリケーションに、サービスの登録通知を行う（ステップＳ１３０４）。そして、ＧＡＴＴサービス制御部４２２が、ＧＡＴＴプロファイルに対して、保存機能４２６を介して、アプリケーションから受け取った新規サービス用のＸＭＬファイルに基づいて、新しいサービスの追加処理を行う（ステップＳ１３０５）。

次に、調停モジュール４１２は、インストールされるアプリケーションから、キャラクタリスティックの登録要求があるか否かを判定する（ステップＳ１３０６）。キャラクタリスティックの登録要求を受け付けたと判定した場合（ステップＳ１３０６：Ｙｅｓ）、キャラクタリスティックの登録処理を行う（ステップＳ１３０７）。キャラクタリスティックの登録要求を受け付けなかったと判定した場合（ステップＳ１３０６：Ｎｏ）、又はステップＳ１３０７の処理を行った後、ステップＳ１３１４の処理に遷移する。

一方、ステップＳ１３０３において、ＵＵＩＤ重複チェック機能４２１が、登録要求を受け付けたサービスのＵＵＩＤと、既存サービスのＵＵＩＤとが、一致していると判定した場合（ステップＳ１３０３：Ｙｅｓ）、ＵＵＩＤ重複チェック機能４２１は、当該既存のサービスに、追加許可が設定されているか否かを判定する（ステップＳ１３０８）。追加許可が設定されていない場合（ステップＳ１３０８：Ｎｏ）、インストールされるアプリケーションに対してエラー通知を行う（ステップＳ１３０９）。

一方、ＵＵＩＤ重複チェック機能４２１が、当該既存のサービスに、追加許可が設定されていると判定した場合（ステップＳ１３０８：Ｙｅｓ）、通知機能４２７が、インストールされるアプリケーションに対して、サービスの登録通知を行う（ステップＳ１３１０）。

その後、調停モジュール４１２は、インストールされるアプリケーションから、キャラクタリスティックの登録要求があるか否かを判定する（ステップＳ１３１１）。キャラクタリスティックの登録要求を受け付けたと判定した場合（ステップＳ１３１１：Ｙｅｓ）、キャラクタリスティックの登録処理を行う（ステップＳ１３１２）。キャラクタリスティックの登録要求を受け付けなかったと判定した場合（ステップＳ１３１１：Ｎｏ）、又はステップＳ１３１２の処理を行った後、ＧＡＴＴサービス制御部４２２が、ＧＡＴＴプロファイルに対して、保存機能４２６を介して、既存サービスに対し、アプリケーションから受け取った新規サービス用のＸＭＬファイルに基づいてサービスの追加拡張処理を行う（ステップＳ１３１３）。

その後、ＧＡＴＴデータ送受信機能４２８が、サービスに変更があったことをアドバタイズメント・パケットに追加する（ステップＳ１３１４）。

その後、Bluetoothスタック４３１が、通信Ｉ／Ｆ２５を介して、アドバタイズメント・パケットをセントラル側の機器に送信する（ステップＳ１３１５）。なお、アドバタイズメント・パケットの送信先を制限するものではなく、例えば、ブロードキャストしても良い。

次に、ステップＳ１３０７及びＳ１３１２のキャラクタリスティックの登録処理について説明する。図１５は、キャラクタリスティックの登録処理を示した図である。なお、図１５で示される例では、図１４で示したように、キャラクタリスティックの登録要求があった場合に行われる処理とする。

まず、ＵＵＩＤ重複チェック機能４２１が、登録要求を受け付けたキャラクタリスティックのＵＵＩＤと、既存サービスのキャラクタリスティックのＵＵＩＤとが、一致しているか否かを判定する（ステップＳ１４０１）。一致していないと判定した場合（ステップＳ１４０１：Ｎｏ）、ステップＳ１４０４に遷移する。

一方、ＵＵＩＤ重複チェック機能４２１が、一致していると判定した場合（ステップＳ１４０１：Ｙｅｓ）、ＵＵＩＤ重複チェック機能４２１は、当該既存のサービスのキャラクタリスティックに、追加許可が設定されているか否かを判定する（ステップＳ１４０２）。追加許可が設定されていない場合（ステップＳ１４０２：Ｎｏ）、インストールされるアプリケーションに対してエラー通知を行う（ステップＳ１４０３）。

一方、ＵＵＩＤ重複チェック機能４２１が、当該既存のサービスのキャラクタリスティックに、追加許可が設定されていると判定した場合（ステップＳ１４０２：Ｙｅｓ）、ステップＳ１４０４に遷移する。

そして、通知機能４２７が、インストールされるアプリケーションに対して、キャラクタリスティックの登録通知を行う（ステップＳ１４０４）。

そして、ＧＡＴＴデータ制御部４２３が、ＧＡＴＴプロファイルに対して、保存機能４２６を介して、キャラクタリスティックの追加処理を行う（ステップＳ１４０５）。

その後、ＧＡＴＴデータ送受信機能４２８が、キャラクタリスティックに変更があったことをアドバタイズメント・パケットに追加する（ステップＳ１４０６）。

本実施形態では、アプリケーションのアンインストールが行われる際に、ＧＡＴＴプロファイルから、当該アプリケーションのサービス及びキャラクタリスティックの削除を行う。

次に、アプリケーションのアンインストールでサービスの削除の際に行われる通信について説明する。本実施形態では、調停モジュール４１２は、アプリケーション管理部４１１からアプリケーションのアンインストール情報を取得できる。取得手法としては、例えば、アンインストール時にイベント通知を受け取る等が考えられる。

図１６は、本実施形態のＭＦＰ１でアプリケーションのアンインストールで、サービスの削除の際に行われる通信を示したシーケンス図である。

まず、アンインストールされるアプリケーションが、調停モジュール４１２に対して、当該アプリケーションのサービス削除を要求する（ステップＳ１５０１）。その際に、サービスを示すＵＵＩＤが受け渡される。これにより、調停モジュール４１２はサービスの削除を実現できる。

その後、調停モジュール４１２が、アプリケーションに対して、ＵＵＩＤに基づいたサービスの削除の完了通知を出力する（ステップＳ１５０２）。

図１７は、本実施形態のＭＦＰ１でアプリケーションのアンインストールで、キャラクタリスティックの削除の際に行われる通信を示したシーケンス図である。

まず、アンインストールされるアプリケーションが、調停モジュール４１２に対して、当該アプリケーションのサービスが有するキャラクタリスティックの削除を要求する（ステップＳ１６０１）。その際に、キャラクタリスティックを示すＵＵＩＤが受け渡される。これにより、調停モジュール４１２はサービスの削除を実現できる。

その後、調停モジュール４１２が、アプリケーションに対して、ＵＵＩＤに基づいたキャラクタリスティックの削除の完了通知を出力する（ステップＳ１６０２）。

そして、当該処理は、アプリケーションのサービスが有するキャラクタリスティックの数だけ繰り返される（例えば、ステップＳ１６０３，Ｓ１６０４）。

次に、本実施形態の操作部２０における、プログラムのアンインストールに伴うサービスの削除処理について説明する。図１８は、本実施形態の操作部２０における上述した処理の手順を示すフローチャートである。

まず、調停モジュール４１２が、アンインストールされるアプリケーションから、サービスの削除要求を受け付けたか否かを判定する（ステップＳ１７０１）。受け付けていない場合（ステップＳ１７０１：Ｎｏ）、再びステップＳ１７０１の処理を行う。

一方、調停モジュール４１２が、インストールされるアプリケーションから、サービスの削除要求を受け付けたと判定した場合（ステップＳ１７０１：Ｙｅｓ）、ＧＡＴＴサービス制御部４２２は、サービス停止かサービス削除かのどちらを行うのかを設定したパラメータを参照する（ステップＳ１７０２）。

そして、ＧＡＴＴサービス制御部４２２は、当該パラメータに従って、サービス削除するか否かを判定する（ステップＳ１７０３）。サービスを削除すると判定した場合（ステップＳ１７０３：Ｙｅｓ）、ステップＳ１７０５に遷移する。

一方、ＧＡＴＴサービス制御部４２２は、サービス停止と判定した場合、換言すればサービス削除ではない場合（ステップＳ１７０３：Ｎｏ）、アプリケーションからサービスの削除要求と共に受け取ったＵＵＩＤで示されるサービスのデータを一時的に保存する（ステップＳ１７０４）。保存先としてはフラッシュメモリ２４等とする。本実施形態のように保存しておくことで、当該サービスの再開時に利用することが可能となる。

さらに、調停モジュール４１２は、インストールされるアプリケーションから、キャラクタリスティックの削除要求を受け付けたか否かを判定する（ステップＳ１７０５）。受け付けていない場合（ステップＳ１７０５：Ｎｏ）、ステップＳ１７０７に遷移する。

一方、調停モジュールが、インストールされるアプリケーションから、キャラクタリスティックの削除要求を受け付けたと判定した場合（ステップＳ１７０５：Ｙｅｓ）、キャラクタリスティックの削除処理を行う（ステップＳ１７０６）。

その後、ＧＡＴＴサービス制御部４２２は、ＧＡＴＴプロファイルから、受け取ったＵＵＩＤで示されるサービスの削除処理を行う（ステップＳ１７０７）。

次に、通知機能４２７が、アンインストールされるアプリケーションに対して、サービスの削除通知を行う（ステップＳ１７０８）。

その後、ＧＡＴＴデータ送受信機能４２８が、サービスに変更があったことをアドバタイズメント・パケットに追加する（ステップＳ１７０９）。このように、サービスが削除された場合に、アドバタイズメント・パケットに変化があったことを示すフラグを設定する。これにより、セントラル側は、この通知が送信された際に、データを再取得すべきか否かを判断できる。

そして、Bluetoothスタック４３１が、通信Ｉ／Ｆ２５を介して、アドバタイズメント・パケットをセントラル側の機器に送信する（ステップＳ１７１０）。なお、アドバタイズメント・パケットの送信先を制限するものではなく、例えば、ブロードキャストしても良い。

次に，図１８のステップＳ１７０６のキャラクタリスティックの削除処理について説明する。図１９は、キャラクタリスティックの削除処理を示した図である。なお、図１９で示される例では、図１８で示したように、キャラクタリスティックの削除要求があった場合に行われる処理とする。

まず、ＵＵＩＤ重複チェック機能４２１が、削除要求を受け付けたキャラクタリスティックのＵＵＩＤと、既存サービスのキャラクタリスティックのＵＵＩＤとが、一致しているか否かを判定する（ステップＳ１８０１）。一致していないと判定した場合（ステップＳ１８０１：Ｎｏ）、ステップＳ１８０７に遷移する。

一方、ＵＵＩＤ重複チェック機能４２１が、一致していると判定した場合（ステップＳ１８０１：Ｙｅｓ）、ＵＵＩＤ重複チェック機能４２１は、当該既存のサービスのキャラクタリスティックに、削除許可が設定されているか否かを判定する（ステップＳ１８０２）。削除許可が設定されていない場合（ステップＳ１８０２：Ｎｏ）、アンインストールされるアプリケーションに対してエラー通知を行う（ステップＳ１８０３）。

一方、ＵＵＩＤ重複チェック機能４２１が、当該既存のサービスのキャラクタリスティックに、削除許可が設定されていると判定した場合（ステップＳ１８０２：Ｙｅｓ）、ＧＡＴＴデータ制御部４２３は、キャラクタリスティック停止かキャラクタリスティック削除かのどちらを行うのかを設定したパラメータを参照する（ステップＳ１８０４）。

そして、ＧＡＴＴデータ制御部４２３は、当該パラメータに従って、キャラクタリスティックを削除するか否かを判定する（ステップＳ１８０５）。キャラクタリスティックを削除すると判定した場合（ステップＳ１８０５：Ｙｅｓ）、ステップＳ１８０７に遷移する。

一方、ＧＡＴＴデータ制御部４２３は、キャラクタリスティック停止と判定した場合、換言すればキャラクタリスティック削除ではない場合（ステップＳ１８０５：Ｎｏ）、アプリケーションからキャラクタリスティックの削除要求と共に受け取ったＵＵＩＤで示されるキャラクタリスティックのデータを一時的に保存する（ステップＳ１８０６）。保存先としてはフラッシュメモリ２４等とする。本実施形態のように保存しておくことで、当該キャラクタリスティックの再開時に利用することが可能となる。

その後、ＧＡＴＴデータ制御部４２３は、ＧＡＴＴプロファイルから、受け取ったＵＵＩＤで示されるキャラクタリスティックの削除処理を行う（ステップＳ１８０７）。

その後、ＧＡＴＴデータ送受信機能４２８が、キャラクタリスティックに変更があったことをアドバタイズメント・パケットに追加する（ステップＳ１８０８）。このように、キャラクタリスティックが削除された場合に、アドバタイズメント・パケットに変化があったことを示すフラグを設定する。これにより、セントラル側は、この通知が送信された際に、データを再取得すべきか否かを判断できる。

本実施形態は、アンインストールされたアプリケーションが利用するサービス及びキャラクタリスティックをフラッシュメモリ２４に保存した後、アプリケーションの再インストール等が行われた際に、調停モジュール４１２が、フラッシュメモリ２４に保存されていたサービスやキャラクタリスティックのデータを、ＧＡＴＴプロファイルに追加する。

例えば、調停モジュール４１２は、再インストールするアプリケーションから受け渡されたＵＵＩＤに基づいて、フラッシュメモリ２４に一時保存されているか否かを確認する。そして、一時保存されていたことを確認した場合に、一時保存されていたサービスや、キャラクタリスティックをＧＡＴＴプロファイルに追加する。

本実施形態の操作部２０においては、上述した構成を備えることで、ファーム（OS）を変更することなく、サービスの追加や更新を可能とする。さらには、サービス及びキャラクタリスティックに対してユニークな識別情報（ＵＵＩＤ）を付与した上で、重複しないように管理することとした。これにより、データ構造の変更等のカスタマイズを容易にすると共に、機能拡張を容易にできる。

本実施形態では、アプリケーションが利用するサービス毎に、ユニークなＵＵＩＤを割り当てている。これにより、本実施形態のＭＦＰ１の操作部２０に、インストールされるアプリケーションと、当該アプリケーションを利用するサービスとの対応関係を管理できる。これにより、アプリケーションをインストールする際に、当該アプリケーションが利用する機能に対応したサービスの追加が容易になる。

さらには、アプリケーションが利用するサービスをＵＵＩＤで管理することで、既に格納されたサービスの機能拡張（一部分の追加拡張）が容易になる。これにより、例えば、新スキャナアプリをインストールすることで、当該アプリケーションが有する新しいスキャナモードの情報や、スキャンのカウンタ情報や、ジョブ履歴など、新たなサービスを、従来のサービスに追加できる。

そのため、ＭＦＰ１のファーム（ＯＳ）を更新しなくても、Bluetooth（登録商標）のＧＡＴＴプロファイルに対して、任意のデータを追加、変更できる。従って、データ送信の機能拡張が容易となるため、後からの機能の拡張性を向上させることができる。

本実施形態の操作部２０では、サービス間の調停を行うことができる。調停とは、追加したいサービスと同じＵＵＩＤを持つ既存のサービスがある場合に行われる制御とする。本実施形態においては、調停モジュール４１２は、調停として、新サービスへの置換、既存サービスの保持、差分データの追加等を行う。

以上に説明したＭＦＰ１の各部の機能 は、ＣＰＵ（１１または２１）が、記憶装置（例えばＲＯＭ１２、ＨＤＤ１４、ＲＯＭ２２、フラッシュメモリ２４等）に格納されたプログラムを実行することにより実現されるが、これに限らず、例えば上記ＭＦＰ１の各部の機能のうちの少なくとも一部が専用のハードウェア回路（例えば半導体集積回路等）で実現されてもよい。

また、上述の実施形態では、本体部１０と操作部２０は、別々のオペレーティングシステムで互いに独立して動作しているが、これに限らず、例えば本体部１０と操作部２０が同じオペレーティングシステムで動作する形態であってもよい。

また、上述した実施形態のＭＦＰ１で実行されるプログラムは、インストール可能な形式または実行可能な形式のファイルでＣＤ−ＲＯＭ、フレキシブルディスク（ＦＤ）、ＣＤ−Ｒ、ＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｋ）、ＵＳＢ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）等のコンピュータで読み取り可能な記録媒体に記録して提供するように構成してもよいし、インターネット等のネットワーク経由で提供または配布するように構成してもよい。また、各種プログラムを、ＲＯＭ等の不揮発性の記録媒体に予め組み込んで提供するように構成してもよい。

なお、上記実施形態では、本発明のＭＦＰを、コピー機能、プリンタ機能、スキャナ機能およびファクシミリ機能のうち少なくとも２つの機能を有する複合機に適用した例を挙げて説明するが、複写機、プリンタ、スキャナ装置、ファクシミリ装置等の画像形成装置であればいずれにも適用することができる。

１…ＭＦＰ
３…ＩＣカードリーダー
５…スマートフォン
１０１…アプリ層
１０２…サービス層
１０３…ＯＳ層
２０１…アプリ層
２０２…サービス層
２０３…ＯＳ層
２０４…ハードウェア層
４０１…インストーラ
４０２…第１のアプリケーション
４０３…第２のアプリケーション
４０４…第３のアプリケーション
４０５…第４のアプリケーション
４１１…アプリケーション管理部
４１２…調停モジュール
４２１…ＵＵＩＤ重複チェック機能
４２２…ＧＡＴＴサービス制御部
４２３…ＧＡＴＴデータ制御部
４２４…ＧＡＴＴサービス停止／再開機能
４２５…ＧＡＴＴデータ停止／再開機能
４２６…保存機能
４２７…通知機能
４２８…ＧＡＴＴデータ送受信機能
４３１…Bluetoothスタック

特開２０１３−１２６００３号公報

Claims (10)

1. 近距離無線通信の規格に従って通信を行う通信部と、
   前記近距離無線通信の規格に従った、プロトコルの利用手法が定義されたプロファイルのうち、複数のサービスを設定可能であり且つ当該サービスに対して識別情報を対応付けている第１のプロファイルを記憶する記憶部と、
   アプリケーションがインストールされる場合に、前記第１のプロファイルに対して、当該アプリケーションが利用するサービスを、当該サービスに対応付けられた識別情報に基づいて追加又は更新を行う調停部と、
   を備えるデータ通信装置。
2. 前記調停部は、さらに、インストールされる前記アプリケーションが利用する第１のサービスと同じ識別情報が割り当てられた他のサービスが、前記第１のプロファイルに格納されてない場合に、当該第１のサービスを、前記第１のプロファイルに追加する、
   請求項１に記載のデータ通信装置。
3. 前記調停部は、さらに、前記アプリケーションが利用する第１のサービスと同じ識別情
   報が割り当てられた他のサービスが、前記第１のプロファイルに格納されている場合に、当該第１のサービスを用いて、前記第１のプロファイルに格納されている他のサービスを更新する、
   請求項１又は２に記載のデータ通信装置。
4. インストールされたプログラムが起動しているかを検出する検出部を、さらに備え、
   前記調停部は、さらに、前記検出部が検出した前記プログラムの起動状態に従って、当該プログラムに対応する、前記第１のプロファイルに格納されているサービスを制御する、
   請求項１乃至３のいずれか一つに記載のデータ通信装置。
5. 前記調停部は、さらに、前記第１のプロファイルで定義されている、属性情報の書き込み要求がなされた場合に、当該属性情報を利用するプログラムに対して、通知を行う、
   請求項１乃至４のいずれか一つに記載のデータ通信装置。
6. 前記調停部により、当該アプリケーションが利用するサービスの追加又は更新が行われた場合に、前記通信部を介して、外部の機器に対してサービスが変更されたことを送信する制御を行う送信制御部を、さらに備える、
   請求項１乃至５のいずれか一つに記載のデータ通信装置。
7. 前記調停部は、さらに、アプリケーションがアンインストールされる際に、当該アプリケーションが利用するサービスを、前記第１のプロファイルから削除する、
   請求項１乃至６のいずれか一つに記載のデータ通信装置。
8. 前記調停部は、さらに、アプリケーションがアンインストールされる際に、当該アプリケーションが利用するサービスのデータを、記憶部に保存する、
   請求項７に記載のデータ通信装置。
9. データ通信装置で行われるデータ通信方法であって、
   前記データ通信装置が、近距離無線通信の規格に従った、プロトコルの利用手法が定義されたプロファイルのうち、複数のサービスを設定可能であり且つ当該サービスに対して識別情報を対応付けている第１のプロファイルを記憶する記憶部を、備え、
   前記近距離無線通信の規格に従って通信を行い、
   アプリケーションがインストールされる場合に、前記第１のプロファイルに対して、当該アプリケーションが利用するサービスを、当該サービスに対応付けられた識別情報に基づいて追加又は更新を行う、
   データ通信方法。
10. 近距離無線通信の規格に従って通信を行う通信ステップと、
    前記近距離無線通信の規格に従った、プロトコルの利用手法が定義されたプロファイルのうち、複数のサービスを設定可能であり且つ当該サービスに対して識別情報を対応付けている第１のプロファイルを記憶部に記憶する記憶ステップと、
    アプリケーションがインストールされる場合に、前記第１のプロファイルに対して、当該アプリケーションが利用するサービスを、当該サービスに対応付けられた識別情報に基づいて追加又は更新を行う調停ステップと、
    をコンピュータに実行させるためのデータ通信プログラム。

Images