図面 (/)

技術 データ通信装置、データ通信方法、及びデータ通信プログラム

出願人 株式会社リコー
発明者 篠宮聖彦
出願日 2014年11月20日 (6年7ヶ月経過) 出願番号 2014-235639
公開日 2016年5月30日 (5年1ヶ月経過) 公開番号 2016-100712
状態 特許登録済
技術分野 移動無線通信システム 電話機の機能 ファクシミリ一般 ストアードプログラム
主要キーワード 調停モジュール 通信定義 プロシージャー 重複確認 センサー情報 アドバタイジング 接続イベント 取得手法
関連する未来課題
重要な関連分野

この項目の情報は公開日時点(2016年5月30日)のものです。
また、この項目は機械的に抽出しているため、正しく解析できていない場合があります

図面 (20)

課題

無線通信に用いるプロファイルに対するサービスの追加や変更を容易にする。

解決手段

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

概要

背景

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

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

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

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

概要

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

目的

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

効果

実績

技術文献被引用数
0件
牽制数
1件

この技術が所属する分野

(分野番号表示ON)※整理標準化データをもとに当社作成

ライセンス契約や譲渡などの可能性がある特許掲載中! 開放特許随時追加・更新中 詳しくはこちら

請求項1

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

請求項2

前記調停部は、さらに、インストールされる前記アプリケーションが利用する第1のサービスと同じ識別情報が割り当てられた他のサービスが、前記第1のプロファイルに格納されてない場合に、当該第1のサービスを、前記第1のプロファイルに追加する、請求項1に記載のデータ通信装置。

請求項3

前記調停部は、さらに、前記アプリケーションが利用する第1のサービスと同じ識別情報が割り当てられた他のサービスが、前記第1のプロファイルに格納されている場合に、当該第1のサービスを用いて、前記第1のプロファイルに格納されている他のサービスを更新する、請求項1又は2に記載のデータ通信装置。

請求項4

インストールされたプログラム起動しているかを検出する検出部を、さらに備え、前記調停部は、さらに、前記検出部が検出した前記プログラムの起動状態に従って、当該プログラムに対応する、前記第1のプロファイルに格納されているサービスを制御する、請求項1乃至3のいずれか一つに記載のデータ通信装置。

請求項5

前記調停部は、さらに、前記第1のプロファイルで定義されている、属性情報書き込み要求がなされた場合に、当該属性情報を利用するプログラムに対して、通知を行う、請求項1乃至4のいずれか一つに記載のデータ通信装置。

請求項6

前記調停部により、当該アプリケーションが利用するサービスの追加又は更新が行われた場合に、前記通信部を介して、外部の機器に対してサービスが変更されたことを送信する制御を行う送信制御部を、さらに備える、請求項1乃至5のいずれか一つに記載のデータ通信装置。

請求項7

前記調停部は、さらに、アプリケーションがアンインストールされる際に、当該アプリケーションが利用するサービスを、前記第1のプロファイルから削除する、請求項1乃至6のいずれか一つに記載のデータ通信装置。

請求項8

前記調停部は、さらに、アプリケーションがアンインストールされる際に、当該アプリケーションが利用するサービスのデータを、記憶部に保存する、請求項7に記載のデータ通信装置。

請求項9

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

請求項10

近距離無線通信の規格に従って通信を行う通信ステップと、前記近距離無線通信の規格に従った、プロトコルの利用手法が定義されたプロファイルのうち、複数のサービスを設定可能であり且つ当該サービスに対して識別情報を対応付けている第1のプロファイルを記憶部に記憶する記憶ステップと、アプリケーションがインストールされる場合に、前記第1のプロファイルに対して、当該アプリケーションが利用するサービスを、当該サービスに対応付けられた識別情報に基づいて追加又は更新を行う調停ステップと、をコンピュータに実行させるためのデータ通信プログラム

技術分野

0001

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

背景技術

0002

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

0003

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

0004

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

0005

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

発明が解決しようとする課題

0006

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

0007

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

課題を解決するための手段

0008

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

発明の効果

0009

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

図面の簡単な説明

0010

図1は、実施形態のデータ通信システムの構成の例を示す図である。
図2は、実施形態のMFPのハードウェア構成を例示した図である。
図3は、実施形態のMFPのソフトウェア構成を例示した図である。
図4は、実施形態の操作部の機能構成を例示した図である。
図5は、実施形態のMFPのBluetooth(登録商標)で利用するプロファイル及びサービスの構成例を示した図である。
図6は、実施形態のGATTプロファイルを構成するサービスのデータフォーマットを例示した図である。
図7は、実施形態の操作部内調停モジュールが行う制御の例を示した図である。
図8は、実施形態のGATTプロファイルに登録されたサービスが有する各項目を例示した図である。
図9は、実施形態のGATTプロファイルに登録されたサービスをXML形式で例示した図である。
図10は、実施形態の操作部で行われるデータフローを例示した図である。
図11は、実施形態のMFPとスマートフォンとの間で行われる処理を示したシーケンス図である。
図12は、実施形態のアドバタイズメントパケットデータ構造例を示した図である。
図13は、実施形態のMFPにアプリケーションをインストールする際に行われる登録を示したシーケンス図である。
図14は、実施形態の操作部にアプリケーションが追加される際に行われる処理を示した図である。
図15は、キャラクタリスティック登録処理を示した図である。
図16は、実施形態のMFPでアプリケーションのアンインストールで、サービスの削除の際に行われる通信を示したシーケンス図である。
図17は、実施形態のMFPでアプリケーションのアンインストールで、キャラクタリスティックの削除の際に行われる通信を示したシーケンス図である。
図18は、実施形態の操作部における、プログラムのアンインストールに伴うサービスの削除処理の手順を示すフローチャートである。
図19は、キャラクタリスティックの削除処理を示した図である。

実施例

0011

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

0012

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

0013

図1に示す例では、MFP1がペリフェラル(周辺機器)側とし、スマートフォン5がセントラル(周辺機器を利用するデバイス)側とする。

0014

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

0015

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

0016

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

0017

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

0018

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

0019

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

0020

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

0021

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

0022

本体部10及び操作部20は、接続I/F16、専用の通信路30、及び接続I/F26を介して相互に通信可能に接続されている。通信路30は、例えばUSB(Universal Serial Bus)規格を用いることができるが、有線無線かを問わず任意の規格でよい。

0023

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

0024

本体部10のハードウェア構成について説明する。図2に示されるように、本体部10は、CPU11、ROM12、RAM13、HDDハードディスクドライブ)14、通信I/F15、接続I/F16、及びエンジン部17を備える。CPU11、ROM12、RAM13、HDD14、通信IF15、接続IF16及びエンジン部17はシステムバス18を介して相互に接続されている。

0025

CPU11は本体部10の動作を統括的に制御する。CPU11はRAM13をワークエリア(作業領域)としてROM12又はHDD14等に格納されたプログラムを実行することで、本体部10全体の動作を制御し、上述したコピー機能、スキャナ機能、ファクス機能、プリンタ機能等の各種機能を実現する。

0026

通信I/F15は、ネットワーク35と接続するためのインターフェースとする。接続I/F16は、通信路30を介して操作部20と通信するためのインターフェースとする。

0027

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

0028

次に操作部20のハードウェア構成について説明する。図2に示すように、操作部20は、CPU21、ROM22、RAM23、フラッシュメモリ24、通信I/F25、接続I/F26、操作パネル27、及び外部接続I/F28を備える。CPU21、ROM22、RAM23、フラッシュメモリ24、通信IF25、接続IF26、操作パネル27及び外部接続I/F28は、システムバス29を介して相互に接続されている。

0029

CPU21は、操作部20の動作を統括的に制御する。CPU21はRAM23をワークエリア(作業領域)としてROM22又はフラッシュメモリ24等に格納されたプログラムを実行することで、操作部20全体の動作を制御し、ユーザから受け付けた入力に応じた情報(画像)の表示等を実現する。

0030

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

0031

接続I/F26は、通信路30を介して本体部10と通信するためのインターフェースとする。

0032

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

0033

外部接続I/F28は、ICカードリーダー3と接続するためのインターフェースとする。

0034

次に、MFP1のソフトウェア構成について説明する。図3は、本実施形態のMFP1のソフトウェア構成を例示した図である。図3に示されるように、本体部10は、アプリ層101と、サービス層102と、OS層103と、を備えている。アプリ層101、サービス層102及びOS層103の実体は、ROM12やHDD14等(図2参照)に格納されている各種ソフトウェアである。CPU11が、これらのソフトウェアを実行することにより、各種の機能が提供される。

0035

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

0036

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

0037

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

0038

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

0039

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

0040

なお、本実施形態では、機能の独立性を保つために、本体部10のOS層103のソフトウェアと、操作部20のOS層203のソフトウェアが互いに異なる。つまり、本体部10と操作部20は、別々のオペレーティングシステムで互いに独立して動作する。例えば、本体部10のOS層103のソフトウェアとしてLinux(登録商標)を用い、操作部20のOS層203のソフトウェアとしてAndroid(登録商標)を用いることを可能とする。

0041

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

0042

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

0043

次に、操作部20の機能構成について説明する。図4は、操作部20の機能構成を例示した図である。図4に示される例では、操作部20は、上層から順に、アプリ層201と、サービス層202と、OS層203と、ハードウェア層204と、により構成されている。

0044

アプリ層201には、インストーラ401と、第1のアプリケーション402と、第2のアプリケーション403と、第3のアプリケーション404と、第5のアプリケーション405と、を備えている。

0045

インストーラ401は、UIを介して、ユーザからのアプリケーションのインストール(追加)を制御する。

0046

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

0047

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

0048

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

0049

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

0050

調停モジュール412は、UUID重複チェック機能421と、GATTサービス制御部422と、GATTデータ制御部423と、GATTサービス停止再開機能424と、GATTデータ停止/再開機能425と、保存機能426と、通知機能427と、GATTデータ送受信機能428と、を備えている。

0051

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

0052

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

0053

図5は、本実施形態のMFP1のBluetooth(登録商標)で利用するプロファイル及びサービスの構成例を示した図である。MFP1は、複数のプロファイルを備えることができるものとする。そして、図5に示される例では、第1のプロファイル501、第2のプロファイル502、及び第3のプロファイル503が備えられている。プロファイルとしては、例えば、HID、HFP、HSP,A2DP、SPP、GATT等とする。

0054

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

0055

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

0056

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

0057

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

0058

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

0059

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

0060

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

0061

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

0062

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

0063

そして、UUID重複チェック機能421が、インストールされるアプリケーションが利用する第1のサービスと同じUUIDが割り当てられた他のサービスがGATTプロファイルに格納されてないと判定した(重複していないと判定された)場合に、調停モジュール412のGATTサービス制御部422は、当該第1のサービスを、GATTプロファイルに追加する。

0064

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

0065

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

0066

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

0067

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

0068

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

0069

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

0070

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

0071

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

0072

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

0073

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

0074

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

0075

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

0076

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

0077

さらに、MFP1本体が省エネ移行復帰やプロセスの起動、停止を行うタイミングにおいて、GATTサービス停止/再開機能424は、各サービスの起動、停止制御を行う。同様に、MFP1本体が省エネ移行、復帰やプロセスの起動、停止を行うタイミングにおいて、GATTデータ停止/再開機能425は、各キャラクタリスティックの起動、停止制御を行う。

0078

本実施形態では、セントラル側(例えば、スマートフォン5)から、GATTプロファイルのデータ(キャラクタリスティック)に対して書き込み(Write権限ありデータの場合)要求が発生した場合には、通信I/F25及びBluetoothスタック431を介して調停モジュール412にその旨が通知される。

0079

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

0080

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

0081

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

0082

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

0083

GATTデータ送受信機能428は、Bluetoothスタック431を介して、外部機器との間でデータの送受信を可能とする。

0084

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

0085

例えば、Bluetoothスタック431は、GATTデータ送受信機能428からの要求に従って、通信I/F25を介して送信制御を行う送信制御部として機能する。例えば、Bluetoothスタック431は、GATTデータ送受信機能428からの要求に従って、通信I/F25を介して、外部の機器に対してアドバタイジング・パケットの送信制御を行う。

0086

また、Bluetoothスタック431は、GATTデータ送受信機能428からの要求に従って、GATTデータ送受信機能428からの要求に従って、通信I/F25を介して外部の機器からの情報の受信制御を行う受信制御部として機能しても良い。

0087

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

0088

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

0089

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

0090

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

0091

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

0092

まず、(1)サービス1000が、BluetoothGatt1001に対して、“startBroadcast”を出力し、ブロードキャストの開始を指示する。そして、(2)BluetoothGatt1001は、指示に従って、アドバタイズメント・パケットを設定する。次に、(3)BluetoothGatt1001は、ブロードキャストの開始を指示する。そして、(4)BLEモジュール25Aは、デバイスを発見するためのアドバタイズメント・パケットをブロードキャストする。

0093

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

0094

次に、(6)BluetoothGatt1001は、BLEモジュール25Aから、接続イベントを受け付ける。(7)BluetoothGatt1001は、サービス1000に対して、“onConnectionStateChange”を受け渡す。これにより、(8)サービス1000は、BluetoothGatt1001に“connect”を出力する。これにより、サービス1000と、スマートフォン5と、の間に接続がなされたことになる。

0095

そして、(9)BluetoothGatt1001は、BLEモジュール25Aに対して、“CommandComplete”を受け渡す。これにより、(10)BLEモジュール25Aは、スマートフォン5に対して、接続完了を通知する。

0096

その後、(11)スマートフォン5は、サービス及びキャラクタリスティック(Service/Characteristic)を要求する。そして、(12)BLEモジュール25Aは、BluetoothGatt1001に、サービスのイベントを受け渡す。(13)BluetoothGatt1001は、サービス1000に対して、“onCharacteristicReadRequest”を受け渡す。これにより、当該サービスのキャラクタリスティックが読み込まれる。

0097

そして、(14)サービス1000は、BluetoothGatt1001に対して、“sendResponse”を受け渡す。これにより、読み込まれたキャラクタリスティックが受け渡される。

0098

そして、(15)BluetoothGatt1001は、サービスの応答をBLEモジュール25Aに出力する。次に、(16)BLEモジュール25Aは、スマートフォン5に、サービス及びキャラクタリスティック(Service/Characteristic)の応答を送信する。

0099

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

0100

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

0101

まず、スマートフォン5は、GATTプロファイルの“Primary Service Discovery”機能である“Discovery Service By UUID”サブプロシージャーを利用して、MFP1が提供するサービス(例えば、ジョブ状態、カウンタ情報、センサー情報など)として規定されたUUIDを用いてサービスの検索を要求する(ステップS1101)。

0102

次に、MFP1は、要求されたサービスと、提供しているサービスとが一致した場合に、当該サービスのハンドルを、スマートフォン5に受け渡す(ステップS1102)。

0103

そして、スマートフォン5は、GATTプロファイルの“Discovery Characteristic by UUID”サブプロシージャーを利用して、キャラクタリスティックの検索を要求する(ステップS1103)。

0104

次に、MFP1は、要求されたキャラクタリスティックと、提供しているキャラクタリスティックとが一致した場合に、当該キャラクタリスティックのハンドルを、スマートフォン5に受け渡す(ステップS1104)。

0105

そして、スマートフォン5は、GATTプロファイルの“Characteristic Value Read”機能の“Read Characteristic Value”サブプロシージャーを利用して、取得したMFP1のキャラクタリスティックのハンドルから、MFP1のデータの取得を要求する(ステップS1105)。

0106

そして、MFP1は、要求されたデータを、スマートフォン5に受け渡す(ステップS1106)。そして、上述した処理を、キャラクタリスティックのUUID毎に繰り返して、必要なデータを取得する。

0107

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

0108

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

0109

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

0110

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

0111

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

0112

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

0113

その後、調停モジュール412が、アプリケーションに対して、サービスのUUIDが重複されているか否かに基づく登録可否を通知する(ステップS1202)。図13に示す例では登録可能と判断された例とする。

0114

そして、アプリケーションは調停モジュール412に対して、サービスを構成するキャラクタリスティックの登録を要求する(ステップS1203)。その際に、キャラクタリスティックを示すUUIDの他に、当該キャラクタリスティックを示すXML形式のデータも受け渡される。これにより、GATTプロファイルに、アプリケーションが利用するサービスを構成するキャラクタリスティックが追加される。なお、登録可能か否か判断する処理手順については後述する。

0115

その後、調停モジュール412が、アプリケーションに対して、キャラクタリスティックのUUIDが重複されているか否かに基づく登録可否を通知する(ステップS1204)。

0116

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

0117

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

0118

まず、インストーラ401が、アプリ層201に対するアプリケーションのインストール要求を受け付ける(ステップS1301)。

0119

次に、調停モジュール412が、インストールされるアプリケーションから、サービスの登録要求を受け付けたか否かを判定する(ステップS1302)。受け付けていない場合(ステップS1302:No)、再びステップS1302の処理を行う。

0120

一方、調停モジュール412が、インストールされるアプリケーションから、サービスの登録要求を受け付けたと判定した場合(ステップS1302:Yes)、UUID重複チェック機能421が、登録要求を受け付けたサービスのUUIDと、既存サービスのUUIDとが、一致しているか否かを判定する(ステップS1303)。

0121

UUID重複チェック機能421が、一致していると判定した場合(ステップS1303:No)、通知機能427が、インストールされるアプリケーションに、サービスの登録通知を行う(ステップS1304)。そして、GATTサービス制御部422が、GATTプロファイルに対して、保存機能426を介して、アプリケーションから受け取った新規サービス用のXMLファイルに基づいて、新しいサービスの追加処理を行う(ステップS1305)。

0122

次に、調停モジュール412は、インストールされるアプリケーションから、キャラクタリスティックの登録要求があるか否かを判定する(ステップS1306)。キャラクタリスティックの登録要求を受け付けたと判定した場合(ステップS1306:Yes)、キャラクタリスティックの登録処理を行う(ステップS1307)。キャラクタリスティックの登録要求を受け付けなかったと判定した場合(ステップS1306:No)、又はステップS1307の処理を行った後、ステップS1314の処理に遷移する。

0123

一方、ステップS1303において、UUID重複チェック機能421が、登録要求を受け付けたサービスのUUIDと、既存サービスのUUIDとが、一致していると判定した場合(ステップS1303:Yes)、UUID重複チェック機能421は、当該既存のサービスに、追加許可が設定されているか否かを判定する(ステップS1308)。追加許可が設定されていない場合(ステップS1308:No)、インストールされるアプリケーションに対してエラー通知を行う(ステップS1309)。

0124

一方、UUID重複チェック機能421が、当該既存のサービスに、追加許可が設定されていると判定した場合(ステップS1308:Yes)、通知機能427が、インストールされるアプリケーションに対して、サービスの登録通知を行う(ステップS1310)。

0125

その後、調停モジュール412は、インストールされるアプリケーションから、キャラクタリスティックの登録要求があるか否かを判定する(ステップS1311)。キャラクタリスティックの登録要求を受け付けたと判定した場合(ステップS1311:Yes)、キャラクタリスティックの登録処理を行う(ステップS1312)。キャラクタリスティックの登録要求を受け付けなかったと判定した場合(ステップS1311:No)、又はステップS1312の処理を行った後、GATTサービス制御部422が、GATTプロファイルに対して、保存機能426を介して、既存サービスに対し、アプリケーションから受け取った新規サービス用のXMLファイルに基づいてサービスの追加拡張処理を行う(ステップS1313)。

0126

その後、GATTデータ送受信機能428が、サービスに変更があったことをアドバタイズメント・パケットに追加する(ステップS1314)。

0127

その後、Bluetoothスタック431が、通信I/F25を介して、アドバタイズメント・パケットをセントラル側の機器に送信する(ステップS1315)。なお、アドバタイズメント・パケットの送信先を制限するものではなく、例えば、ブロードキャストしても良い。

0128

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

0129

まず、UUID重複チェック機能421が、登録要求を受け付けたキャラクタリスティックのUUIDと、既存サービスのキャラクタリスティックのUUIDとが、一致しているか否かを判定する(ステップS1401)。一致していないと判定した場合(ステップS1401:No)、ステップS1404に遷移する。

0130

一方、UUID重複チェック機能421が、一致していると判定した場合(ステップS1401:Yes)、UUID重複チェック機能421は、当該既存のサービスのキャラクタリスティックに、追加許可が設定されているか否かを判定する(ステップS1402)。追加許可が設定されていない場合(ステップS1402:No)、インストールされるアプリケーションに対してエラー通知を行う(ステップS1403)。

0131

一方、UUID重複チェック機能421が、当該既存のサービスのキャラクタリスティックに、追加許可が設定されていると判定した場合(ステップS1402:Yes)、ステップS1404に遷移する。

0132

そして、通知機能427が、インストールされるアプリケーションに対して、キャラクタリスティックの登録通知を行う(ステップS1404)。

0133

そして、GATTデータ制御部423が、GATTプロファイルに対して、保存機能426を介して、キャラクタリスティックの追加処理を行う(ステップS1405)。

0134

その後、GATTデータ送受信機能428が、キャラクタリスティックに変更があったことをアドバタイズメント・パケットに追加する(ステップS1406)。

0135

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

0136

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

0137

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

0138

まず、アンインストールされるアプリケーションが、調停モジュール412に対して、当該アプリケーションのサービス削除を要求する(ステップS1501)。その際に、サービスを示すUUIDが受け渡される。これにより、調停モジュール412はサービスの削除を実現できる。

0139

その後、調停モジュール412が、アプリケーションに対して、UUIDに基づいたサービスの削除の完了通知を出力する(ステップS1502)。

0140

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

0141

まず、アンインストールされるアプリケーションが、調停モジュール412に対して、当該アプリケーションのサービスが有するキャラクタリスティックの削除を要求する(ステップS1601)。その際に、キャラクタリスティックを示すUUIDが受け渡される。これにより、調停モジュール412はサービスの削除を実現できる。

0142

その後、調停モジュール412が、アプリケーションに対して、UUIDに基づいたキャラクタリスティックの削除の完了通知を出力する(ステップS1602)。

0143

そして、当該処理は、アプリケーションのサービスが有するキャラクタリスティックの数だけ繰り返される(例えば、ステップS1603,S1604)。

0144

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

0145

まず、調停モジュール412が、アンインストールされるアプリケーションから、サービスの削除要求を受け付けたか否かを判定する(ステップS1701)。受け付けていない場合(ステップS1701:No)、再びステップS1701の処理を行う。

0146

一方、調停モジュール412が、インストールされるアプリケーションから、サービスの削除要求を受け付けたと判定した場合(ステップS1701:Yes)、GATTサービス制御部422は、サービス停止かサービス削除かのどちらを行うのかを設定したパラメータを参照する(ステップS1702)。

0147

そして、GATTサービス制御部422は、当該パラメータに従って、サービス削除するか否かを判定する(ステップS1703)。サービスを削除すると判定した場合(ステップS1703:Yes)、ステップS1705に遷移する。

0148

一方、GATTサービス制御部422は、サービス停止と判定した場合、換言すればサービス削除ではない場合(ステップS1703:No)、アプリケーションからサービスの削除要求と共に受け取ったUUIDで示されるサービスのデータを一時的に保存する(ステップS1704)。保存先としてはフラッシュメモリ24等とする。本実施形態のように保存しておくことで、当該サービスの再開時に利用することが可能となる。

0149

さらに、調停モジュール412は、インストールされるアプリケーションから、キャラクタリスティックの削除要求を受け付けたか否かを判定する(ステップS1705)。受け付けていない場合(ステップS1705:No)、ステップS1707に遷移する。

0150

一方、調停モジュールが、インストールされるアプリケーションから、キャラクタリスティックの削除要求を受け付けたと判定した場合(ステップS1705:Yes)、キャラクタリスティックの削除処理を行う(ステップS1706)。

0151

その後、GATTサービス制御部422は、GATTプロファイルから、受け取ったUUIDで示されるサービスの削除処理を行う(ステップS1707)。

0152

次に、通知機能427が、アンインストールされるアプリケーションに対して、サービスの削除通知を行う(ステップS1708)。

0153

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

0154

そして、Bluetoothスタック431が、通信I/F25を介して、アドバタイズメント・パケットをセントラル側の機器に送信する(ステップS1710)。なお、アドバタイズメント・パケットの送信先を制限するものではなく、例えば、ブロードキャストしても良い。

0155

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

0156

まず、UUID重複チェック機能421が、削除要求を受け付けたキャラクタリスティックのUUIDと、既存サービスのキャラクタリスティックのUUIDとが、一致しているか否かを判定する(ステップS1801)。一致していないと判定した場合(ステップS1801:No)、ステップS1807に遷移する。

0157

一方、UUID重複チェック機能421が、一致していると判定した場合(ステップS1801:Yes)、UUID重複チェック機能421は、当該既存のサービスのキャラクタリスティックに、削除許可が設定されているか否かを判定する(ステップS1802)。削除許可が設定されていない場合(ステップS1802:No)、アンインストールされるアプリケーションに対してエラー通知を行う(ステップS1803)。

0158

一方、UUID重複チェック機能421が、当該既存のサービスのキャラクタリスティックに、削除許可が設定されていると判定した場合(ステップS1802:Yes)、GATTデータ制御部423は、キャラクタリスティック停止かキャラクタリスティック削除かのどちらを行うのかを設定したパラメータを参照する(ステップS1804)。

0159

そして、GATTデータ制御部423は、当該パラメータに従って、キャラクタリスティックを削除するか否かを判定する(ステップS1805)。キャラクタリスティックを削除すると判定した場合(ステップS1805:Yes)、ステップS1807に遷移する。

0160

一方、GATTデータ制御部423は、キャラクタリスティック停止と判定した場合、換言すればキャラクタリスティック削除ではない場合(ステップS1805:No)、アプリケーションからキャラクタリスティックの削除要求と共に受け取ったUUIDで示されるキャラクタリスティックのデータを一時的に保存する(ステップS1806)。保存先としてはフラッシュメモリ24等とする。本実施形態のように保存しておくことで、当該キャラクタリスティックの再開時に利用することが可能となる。

0161

その後、GATTデータ制御部423は、GATTプロファイルから、受け取ったUUIDで示されるキャラクタリスティックの削除処理を行う(ステップS1807)。

0162

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

0163

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

0164

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

0165

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

0166

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

0167

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

0168

そのため、MFP1のファーム(OS)を更新しなくても、Bluetooth(登録商標)のGATTプロファイルに対して、任意のデータを追加、変更できる。従って、データ送信の機能拡張が容易となるため、後からの機能の拡張性を向上させることができる。

0169

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

0170

以上に説明したMFP1の各部の機能 は、CPU(11または21)が、記憶装置(例えばROM12、HDD14、ROM22、フラッシュメモリ24等)に格納されたプログラムを実行することにより実現されるが、これに限らず、例えば上記MFP1の各部の機能のうちの少なくとも一部が専用のハードウェア回路(例えば半導体集積回路等)で実現されてもよい。

0171

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

0172

また、上述した実施形態のMFP1で実行されるプログラムは、インストール可能な形式または実行可能な形式のファイルでCD−ROMフレキシブルディスクFD)、CD−R、DVD(Digital Versatile Disk)、USB(Universal Serial Bus)等のコンピュータで読み取り可能な記録媒体に記録して提供するように構成してもよいし、インターネット等のネットワーク経由で提供または配布するように構成してもよい。また、各種プログラムを、ROM等の不揮発性の記録媒体に予め組み込んで提供するように構成してもよい。

0173

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

0174

1…MFP
3…ICカードリーダー
5…スマートフォン
101…アプリ層
102…サービス層
103…OS層
201…アプリ層
202…サービス層
203…OS層
204…ハードウェア層
401…インストーラ
402…第1のアプリケーション
403…第2のアプリケーション
404…第3のアプリケーション
405…第4のアプリケーション
411…アプリケーション管理部
412…調停モジュール
421…UUID重複チェック機能
422…GATTサービス制御部
423…GATTデータ制御部
424…GATTサービス停止/再開機能
425…GATTデータ停止/再開機能
426…保存機能
427…通知機能
428…GATTデータ送受信機能
431…Bluetoothスタック

先行技術

0175

特開2013−126003号公報

ページトップへ

この技術を出願した法人

この技術を発明した人物

ページトップへ

関連する挑戦したい社会課題

関連する公募課題

ページトップへ

技術視点だけで見ていませんか?

この技術の活用可能性がある分野

分野別動向を把握したい方- 事業化視点で見る -

(分野番号表示ON)※整理標準化データをもとに当社作成

ページトップへ

おススメ サービス

おススメ astavisionコンテンツ

新着 最近 公開された関連が強い技術

この 技術と関連性が強い人物

関連性が強い人物一覧

この 技術と関連する社会課題

関連する挑戦したい社会課題一覧

この 技術と関連する公募課題

関連する公募課題一覧

astavision 新着記事

サイト情報について

本サービスは、国が公開している情報(公開特許公報、特許整理標準化データ等)を元に構成されています。出典元のデータには一部間違いやノイズがあり、情報の正確さについては保証致しかねます。また一時的に、各データの収録範囲や更新周期によって、一部の情報が正しく表示されないことがございます。当サイトの情報を元にした諸問題、不利益等について当方は何ら責任を負いかねることを予めご承知おきのほど宜しくお願い申し上げます。

主たる情報の出典

特許情報…特許整理標準化データ(XML編)、公開特許公報、特許公報、審決公報、Patent Map Guidance System データ