JP6456028B2 - 情報処理装置、情報処理方法、およびプログラム - Google Patents

Description

本発明は、例えばWebブラウザを有し、また、複数のアプリケーション間の機能連携を実行できる情報処理装置、情報処理装置の制御方法、およびプログラムに関する。

画像処理装置は、一般的に、スキャナやプリンタなどの各種処理をアプリケーション(以下、「アプリ」)単位で動作させるアプリプラットフォーム(以下、「PF」)環境を有しており、操作部の表示には、Webブラウザが用いられている。ユーザは、Webブラウザに表示される画面を操作することで、アプリPF上で起動するアプリを介した、画像処理装置の各種処理を利用可能となっている。また、近年、複数のアプリ間の連携を行う機能として、Android(登録商標)におけるインテントやChrome(登録商標)におけるWeb Intentsが知られている。このようなシステムにおけるアプリ連携機能では、連携元のアプリから、テキストデータやバイナリデータなどを、連携先のアプリに受け渡し、連携先のアプリを実行する動作が行われる。まず事前に、ユーザまたはアプリ開発者が、連携先のアプリに関する、アプリ連携を行うメッセージの役割を果たすIntent情報が記載されたマニフェストファイルを作成しておく。そのマニフェストファイルは、Android(登録商標)においてはOS、Chrome(登録商標)においてはブラウザによって解析され、Intent情報として登録される。その後、連携元のアプリをOS/ブラウザが実行する。そして、連携元のアプリが、例えば選択中の画像データの編集処理を実行する操作を行うと、編集操作を実行可能な連携先のアプリを、登録されたIntent情報から抽出してリスト表示する。リスト表示されたアプリのうち何れかが選択されると、連携元のアプリが、選択された連携先のアプリに、選択中の画像データを渡した状態で、OS/ブラウザが連携先のアプリを起動する。このような機能を画像処理装置に搭載することで、ユーザが、画像処理装置のアプリPF上で起動するアプリの連携動作をシームレスに実行可能となる。

特開2013-137612号公報

従来の技術(特許文献1)では、端末装置が、ユーザ操作、または特定の事象発生に応じてPF上にインストールされた全アプリに関するIntent情報を登録し、実行可能なアプリとして自動的に起動する処理を行っている。しかし画像処理装置の場合、提供する機能の管理や運用などは、画像処理装置を提供するベンダなどの管理者によって行われるケースがある。この場合、画像処理装置上のアプリを使用するユーザと、同PF上でアプリのライフサイクルなどの管理をする管理者とが別々に存在する。その際、上記操作や事象発生により管理者によって停止されているアプリであっても、Intent情報が登録され強制的に実行可能な状態とされてしまうことがあり得る。このことは、管理者にとってアプリの管理運用に不都合なケースとなる場合があり、ユーザにとっても管理者が意図的に停止しているアプリを使用してしまう恐れがある。

そこで、本発明は、一例であるWeb Intentsに代表されるような（ウェブ）アプリケーションの連携の技術を利用しつつ、上述の課題、すなわち画像処理装置上のアプリ起動状態に応じたIntent情報の登録を行うことで、運用上でも実行可能なアプリのみを選択可能とする仕組みを提供することを目的とする。

上記課題を解決するため、本発明は以下の構成を有する。すなわち、
複数のアプリケーションが稼働できるプラットフォームを有する情報処理装置であって、
前記プラットフォームが、
アプリケーションのインストール、起動、停止、アンインストールの要求に応じた稼働状況を取得する取得手段と、
前記アプリケーションを用いて提供されるサービスに関する機能情報を、前記取得手段により取得された稼働状況に従い管理する管理手段とを有し、
前記情報処理装置内の起動中のアプリケーションと、ウェブアプリケーションを有する外部システムと、が連携することで提供されるサービスに関する機能情報は、該外部システムとのネットワークを介した通信に従い稼働中であるか否かが決定される稼働状況に従い、前記管理手段により管理され、
前記情報処理装置で実行されるサービスの呼び出し元となるウェブブラウザによる前記機能情報を用いたサービスの呼び出しの受け付けに応じて、前記管理手段により管理されている、前記稼働状況が稼働中を示すサービスが実行される。

本発明によれば、（ウェブ）アプリケーションの連携の技術を利用しつつ、上述の課題を解決し得る仕組みを提供できる。

具体的には、管理者とユーザが別々に存在する画像処理装置のアプリ管理方法に見合った、実行可能なアプリのみのIntent情報の登録が可能となる。加えて、ユーザにとっても安全なアプリ連携機能を実現することができる。

実施形態1に係るシステム構成図 実施形態1に係る外部装置と画像処理装置のハードウェア構成図 実施形態1に係る外部装置と画像処理装置のソフトウェア構成図 実施形態1に係る画像処理装置のアプリPFのアプリライフサイクル管理を示すフローチャート図 実施形態1に係るアプリPFのアプリ管理テーブル図 実施形態1に係るIntent情報ファイルの図 実施形態1に係るWebブラウザのIntent登録処理手順を示すシーケンス図 実施形態1に係るWebブラウザ内のIntentテーブル構成図 実施形態1に係るWebブラウザ上で実行されるクライアントアプリの例図 実施形態2に係るWebブラウザのIntent登録更新処理手順を示すシーケンス図 実施形態2に係るWebブラウザ内のIntentテーブル構成図 実施形態2に係るWebブラウザ上で実行されるクライアントアプリの例図 実施形態3に係るWebブラウザのIntent登録処理手順を示すシーケンス図 実施形態3に係るWebブラウザ内のIntentテーブル構成図 実施形態3に係るWebブラウザ上で実行されるクライアントアプリの例図 実施形態3に係るWebブラウザのIntent登録更新(Webアプリ起動時)処理シーケンス図 実施形態3に係るWebブラウザ内の更新後Intentテーブル構成図 実施形態3に係るWebブラウザのIntent登録更新(Webアプリ停止時)処理シーケンス図 実施形態4に係る画像処理装置のソフトウェア構成図 実施形態4に係るアプリPFのアプリ管理テーブル図 実施形態4に係るログインアプリを用いたユーザ権限の遷移を示すフローチャート図 実施形態4に係るIntent情報ファイルの図 実施形態4に係るWebブラウザのIntent登録処理(未ログイン時)手順を示すシーケンス図 実施形態4に係るWebブラウザ内のIntentテーブル構成図 実施形態4に係るWebブラウザ上で実行されるクライアントアプリの例図 実施形態4に係るWebブラウザのIntent登録更新処理(ユーザログイン時)手順を示すシーケンス図 実施形態4に係るユーザログイン時Webブラウザ内のIntentテーブル構成図

以下、本発明を実施するための形態について図面を用いて説明する。ここでまず、本実施形態で使用する用語の定義を行う。
Intent情報とは、WebブラウザがWebアプリにアクセスした時、当該WebアプリがIntent処理可能なアプリであることを認識し、Webブラウザ内に連携先アプリとして登録するための情報である。またIntent情報は、Web Intentsを用いたアプリ連携を行う際、連携先のWebアプリを構成するHTMLデータに記載される、＜intent＞タグデータを有するものとする。Intent情報はアプリが提供するサービスに関する機能情報ということもでき、後述のアプリプラットフォーム（PF）によりIntent情報ファイル格納部に格納され管理される。
Webアプリとは、Webブラウザ上で動作する、インターネットやイントラネットなどのネットワークを介して使用するアプリケーションソフトウェアである。本実施形態では、Webアプリは、Webブラウザを介して画像処理装置を操作するUI表示画面機能を備え、ユーザからの入力に応じて、表示画面の変更や画像処理装置のデバイス機能を実行するアプリとする。また、Webアプリは、Intent処理可能なアプリであり、Web Intentsを用いたアプリ連携を行う時の、連携先（すなわち呼び出される側）のWebアプリとする。
クライアントアプリとは、Webブラウザを介して画像処理装置を操作するUI表示画面機能を備えるWebアプリである。また、Webブラウザに登録されたIntent情報から、ユーザ操作により指定された機能に該当する実行可能なアプリを表示し、当該一覧からユーザが選択したアプリを実行する、Intent実行機能を有する。すなわち上述した提携元（換言すれば呼び出す側）のアプリに相当する。

なお、本実施例においては、（ウェブ）アプリケーションの連携の技術として、Web Intentsを利用した場合の説明を行っている。しかしながら、同様な中継機能を介したクライアントとサービスを連携するための他の仕組みを利用してもよい。例えば、Web Activitiesと呼ばれる技術を利用してもよいし、同様の独自仕様を用いて本発明を実現することが可能である。その場合には、Web Intentsのプロトコルを用いた手順あるいはデータを、当該類似技術で規定するプロトコルを用いた手順あるいはデータで置換すればよい。

［実施形態１］
＜情報処理システムの構成＞
本実施形態をシステム構成について、図1から図3を用いて説明する。図1は、本実施形態の情報処理システム全体の構成例である。本システムは、ネットワーク102を介して、情報処理装置100と外部装置101から構成される。
画像処理装置100は、画像形成装置、画像読取装置、画像送信機能などの各種画像処理機能と、ネットワークを介してHTTP通信を行うWebブラウザ機能とを有する装置である。なお画像処理装置100は、プリンタ、コピー、ファクス及びスキャナや、それら複数の機能を一台の筐体で実現するMFP(Multi Functional Peripheral)でもよい。
外部装置101は、Webサーバ機能、及び、画像処理装置100に画面情報としてGUIデータを提供する機能を備えたWebアプリが実装された、コンピュータなどの情報処理装置である。
なお、画像処理装置100と外部装置101を別々の装置として記載しているが、外部装置101の機能を有する画像処理装置100であってもよい。

図2は、本実施形態の外部装置と画像処理装置のハードウェア構成例である。
画像処理装置100は、外部装置101などと通信を行うネットワーク装置201、キーボードなどユーザ操作を受け付けるユーザ入力装置202、液晶ディスプレイなど操作画面を表示するUI表示装置203を有する。更に画像処理装置100は、装置全体を制御するCPU204、CPU204のワークスペースを提供するRAM205、画像原稿を読み取る読取装置206、画像データを印刷する印刷装置207、各種制御プログラムなどを記憶する記憶装置208を有する。なお、画像処理装置100を構成する各装置は、メインバス200で接続され、相互にデータの送受信が可能となる。なお、ユーザ入力装置202とUI表示装置203とを別々の装置として記載しているが、これらの装置が一体となった操作部となっていてもよい。
次に外部装置101は、画像処理装置100などと通信を行うネットワーク装置211、装置全体を制御するCPU212、CPU212のワークスペースを提供するRAM213、各種制御プログラムなどを記録する記憶装置214から構成される。また外部装置101を構成する各装置は、メインバス210で接続され、相互にデータの送受信が可能となる。

図3は、本実施形態の外部装置101と画像処理装置100のソフトウェア構成例である。図3に示す各機能部は、画像処理装置100/外部装置101それぞれが有するCPU204/CPU212が、記憶装置208/記憶装置214に記憶される制御プログラムをRAM205/RAM213上に読み出して実行することで実現される。
まず、外部装置101が備えるソフトウェアについて説明する。外部装置101は、通信部300、Webアプリ310を有する。更に、Webアプリ310には、プレゼンテーション部311及びロジック部312が含まれる。通信部300は、ネットワーク装置211を制御してHTTP通信を行うソフトウェアである。プレゼンテーション部311は、通信部300を介して、画像処理装置100からのリクエストに応じて画像形成装置100のWebブラウザ380で表示すべき操作画面を画像処理装置100にレスポンスとして送信する。また、Webブラウザ380に表示された操作画面を通じて入力されたユーザからの入力情報を、通信部300を介して画像処理装置100から受け取る。
ロジック部312は、プレゼンテーション部311から渡された画像処理装置100からの入力情報に対して処理を行う。例えば、ユーザからの入力に応じて、表示画面の変更や、画像処理装置100のデバイス機能実行のための処理要求を生成する。なお、本実施形態では、当該処理要求にはSOAPを用いるが、他の装置に存在するデータやサービスを呼び出すためのプロトコルであれば実現構成に制限はない。

次に、画像処理装置100が備えるソフトウェアについて説明する。画像処理装置100は、アプリケーションプラットフォーム（アプリPF）320、Webブラウザ380、Webサーバ390を有する。
アプリPF320は、制御APIを介して画像処理装置100を制御する、１以上のアプリを実行可能な実行基盤である。また、アプリPF320は、実行基盤としてアプリ記憶領域330、アプリ管理部331、また、Intent情報ファイル格納部333を有する。なお、本実施形態では、アプリPF320の構成には、Java(登録商標)アプリを実行可能なJava(登録商標)仮想マシンを用いる。
アプリ記憶領域330は、記憶装置208に保存される、アプリ管理部331を介してインストールされたアプリを有する。本実施形態では、Webサーバアプリ340、アプリA350、アプリB360、サービスプロバイダ370、などがインストールされているものとする。
アプリ管理部331は、アプリ記憶領域330内にアプリをインストール、アンインストールし、また、同領域のアプリの起動、停止、更新といったライフサイクル管理を行う。更に、アプリ管理部331は、アプリ記憶領域330内のアプリのアプリ情報と、ライフサイクルの管理を行う起動状態（あるいは稼働状態とも呼ぶ）を記憶する、アプリ管理テーブル332を有する。
なお、本実施形態では、アプリ管理部331には、OSGi(登録商標)フレームワークを含む。即ち、アプリ記憶領域330上のアプリは、OSGi(登録商標)フレームワーク上で稼働するアプリである。

OSGi(登録商標)フレームワークは、モジュールシステムと、Java(登録商標)のサービスPFと、アプリのインストール、開始、停止などを、Java(登録商標)仮想マシンを再起動せず実行可能な環境を提供するものである。また、OSGi(登録商標)フレームワークは、アプリをバンドル単位で管理する。バンドルは、アプリを構成するJarファイルに加え、アプリ名、バージョン情報、バンドル起動時実行クラスなどのメタデータを記述したマニフェストファイル(不図示)を有する。前述のアプリ管理テーブル332で管理されるアプリ情報としては、このマニフェストファイル内のメタデータ情報が保存される。
なお、アプリPF320には、Java(登録商標)アプリを実行可能なJava(登録商標)仮想マシンを用いる。このため、アプリ管理部331には、OSGi(登録商標)を用いたライフサイクル管理を行っている。但し、アプリの起動、停止を明示的に行うライフサイクル管理を実行可能なアプリPFであれば、実現構成に制限はない。
なお、アプリ管理部331における、アプリのライフサイクル管理方法については、図4に、アプリ管理テーブル332構成は、図5に後述する。
アプリ管理部331は加えて、Inetnt処理部384との間で、Intent情報ファイル格納部333及びIntentテーブル385の更新に関する制御要求を送受信する。また、前記制御要求に応じて、アプリ記憶領域330内のアプリに含まれるIntent情報ファイルを、Intent情報ファイル格納部333に保存する。
Intent情報ファイル格納部333は、アプリ管理部331によってアプリ記憶領域330内に保管されたアプリが備える、Intent情報ファイルを有する。Intent情報ファイルの構成は、図6にて後述する。

次に、アプリ記憶領域330内のアプリの構成について説明する。なお、アプリは、OSGi(登録商標)フレームワークを利用しているため、アプリのメタデータを記述したマニフェストファイル(不図示)を有するバンドルであるものとする。
Webサーバアプリ340は、通信部341で構成され、ネットワーク装置201を制御してHTTP通信を行うアプリである。
アプリ記憶領域330内に存在するWebアプリは、Webサーバアプリ340を介することで、他の装置からのリクエストの受信、レスポンスの送信が可能となる。
アプリA350、アプリB360は、Intent情報ファイル351、361を有する、画像処理装置100を制御するアプリである。なお、本実施形態では、アプリA350、アプリB360は、印刷装置207を制御するアプリとする。また、Java(登録商標) Servletにより構成されたWebアプリとし、Webサーバアプリ340を介してHTTP通信を行う。

サービスプロバイダ370は、通信部371、ジョブ生成部372、およびIntent情報ファイル373を有し、UI画面と処理要求を生成するWebアプリ310と通信するアプリである。
通信部371は、通信部300/通信部381を介して通信される、Webアプリ310のロジック部で生成された、SOAPによる処理要求依頼を受け取る。
ジョブ生成部372は、通信部371が受け付けた処理依頼を受け取り、要求された処理を実行するためのジョブを生成する。なお、本実施形態では、印刷装置207を用いるプリンタ機能を実行するジョブを生成する。
本実施形態では、Intent情報ファイルを有するWebアプリとして、Java(登録商標) ServletによるWebアプリ、及びSOAP通信によりWebアプリと連携を行うアプリを用いている。更に、前記連携を行うアプリの利用形態として、Webサーバアプリ340、Webアプリ310を用いている。但し、Webブラウザから実行可能なアプリ構成を有していれば、実施形態に制限はない。

Webブラウザ（ウェブブラウザ）380は、通信部381、解析部382、画面表示部383、Intent処理部384、Intentテーブル385で構成される。
通信部381は、ネットワーク装置201を介したHTTP通信を行うソフトウェアである。
解析部382は、通信部381を介して取得したデータを解釈する。
画面表示部383は、解析部382によって解釈されたデータを用いて、UI表示放置203を介し、表示画面の表示を行う。
Intent処理部384は、解析部382によって解釈されたデータ内に存在するIntent情報を処理し、Intentテーブル385に登録する。また、解析部382の解釈データに、Intent情報の要求処理が含まれていた場合、Intentテーブル385に存在するIntent情報を取得し解析部382に送信する。Intent処理部384は加えて、Intent情報ファイル格納部333に存在するIntent情報ファイル内のIntent情報を処理し、Intentテーブル385に登録する。更に、アプリ管理部331と、Intent情報ファイル格納部333及びIntentテーブル385の更新に関する制御要求を送受信する。
Intentテーブル385は、Intent処理部384によって記憶装置208に保存される、WebアプリのIntent情報を有するテーブルの集合体である。Intentテーブル385の構成は、図8に後述する。

Webサーバ390は、通信部391、クライアントアプリ392を有する。
通信部391は、ネットワーク装置201を制御してHTTP通信を行うソフトウェアである。
クライアントアプリ392は、UI表示装置203に、Webブラウザ380を介して画像処理装置100を操作する画面表示機能を備えるWebアプリである。また、ユーザ操作により指定された機能を実行可能なアプリを、Intentテーブル385に登録されたIntent情報のテーブルから取得、表示し、当該表示からユーザが選択したアプリを実行する、Intent実行機能を有する。また、クライアントアプリ392は、HTMLデータ、及びIntent情報のメッセージを作成、送受信可能なAPIを有するJavaScript(登録商標)で構成される。
なお、クライアントアプリ392は、少なくとも前記構成を有するWebアプリであれば、実現構成に制限はない。また、Webサーバ390が有するWebアプリに限定されるものではなく、外部装置101が有するものであってもよい。

＜アプリPF320によるアプリのライフサイクル管理＞
本実施形態におけるアプリPF320のライフサイクル管理方法、及びアプリの管理情報を、図4、図5で説明する。図4は、アプリPF320のライフサイクル管理を示すフローチャート図である。

まず、図4(a)における、アプリインストール処理(ステップS410-S413)を説明する。
ステップS410では、画像処理装置100の管理者400が、アプリPF320に対する指定したアプリのインストールの要求指示を入力する。なお、アプリ管理部331はOSGi(登録商標)フレームワークを用いていることから、管理者400の要求指示は、例えばアプリ管理部331による当該要求コマンドの実行処理で実現される。但し、管理者400がアプリPF320に対し要求指示を出す構成を有していれば、用いるインターフェースに制限はない。
ステップS411では、アプリ管理部331が、当該要求指示により指定されたアプリをアプリ記憶領域330上にインストールする。なお、指定されたアプリは、アプリ記憶領域330下の、アプリ名やアプリIDなどメタデータ情報にひもづくディレクトリに格納される。
ステップS412では、アプリ管理部331が、アプリ情報をアプリ管理テーブル332に追加する。なお、アプリ情報とは、アプリ名や、マニフェストファイルに記載されるメタデータ情報である。
ステップS413では、アプリ管理部331が、アプリ管理テーブル332内の当該アプリ起動状態を「INSTALLED」に更新する。

次に、図4(b)における、アプリ起動処理(ステップS420-S422)を説明する。
ステップS420では、画像処理装置100の管理者400が、アプリPF320に対し、指定したアプリの起動要求指示を送信する。
ステップS421では、アプリ管理部331が、当該要求指示により指定されたアプリ記憶領域330上アプリを起動する処理を実行する。
ステップS422では、アプリ管理部331が、アプリ管理テーブル332内の当該アプリ起動状態を「ACTIVE」に更新する。

次に、図4(c)における、アプリ停止処理(ステップS430-S432)を説明する。
ステップS430では、画像処理装置100の管理者400が、アプリPF320に対し、指定したアプリの停止要求指示を送信する。
ステップS431では、アプリ管理部331が、当該要求指示により指定されたアプリ記憶領域330上アプリを停止する処理を実行する。
ステップS432では、アプリ管理部331が、アプリ管理テーブル332内の当該アプリ起動状態を「RESOLVED」に更新する。

また、アプリ管理部331は、画像処理装置100の管理者400が同様に更新、アンインストールの要求指示を送信することで、それぞれ更新、アンインストールの処理を実行する(不図示)。以下、概要を説明する。
アプリ管理部331は、画像処理装置100の管理者400からの指定アプリ更新要求を受信した場合、アプリ記憶領域330上の当該アプリファイルを上書きする処理を行う。
アプリ管理部331は、管理者400からの指定アプリアンインストール要求を受信した場合、アプリ記憶領域330上の当該アプリファイルの削除処理を行う。その後、アプリ管理部331は、アプリ管理テーブル332内の当該アプリ起動状態を「UNINSTALLED」状態に更新する。

＜アプリ管理テーブル＞
図5は、本実施形態におけるアプリ管理テーブル332の構成図である。アプリ管理テーブル332は、bundle501、state502、アプリ情報503を管理するテーブルである。
bundle501は、アプリ記憶領域330上に存在するアプリ名を示す。本実施形態では、アプリ名を、Webサーバアプリ340は「WebServerApplication」として登録している。同様に、アプリA350は「ApplicationA」、アプリB360は「ApplicationB」、また、サービスプロバイダ370は、「ServiceProvider」として登録している。
state502は、bundle501に記載されたアプリの起動状態を示す。本実施形態では、Webサーバアプリ340、アプリA350、サービスプロバイダ370が起動された状態(ACTIVE)となっている。また、アプリB360は、インストールされているが起動はされていない状態(INSTALLED)となっている。
アプリ情報503は、bundle501に記載されたアプリが有するマニフェストファイル内に記載される、メタデータ情報を示す。本実施形態では、アプリのバージョン情報などが記載されているものとする。

＜Intent情報ファイル＞
アプリ記憶領域330上のアプリが有する、Intent情報ファイルの構成について、図6で説明する。
図6(a)は、本実施形態のアプリA350が有するIntent情報ファイル351の構成の例である。
Intent情報ファイル351は、前述の＜intent＞タグデータ600を有するファイルである。
＜intent＞タグデータ600は、データ項目として、action601、type602、title603、href604、disposition605を有する。
action601は、アプリA350が提供する動作を示す、URLスキーマである。クライアントアプリ392は、データの編集や保存処理などユーザが選択した動作要求時に、action601をキーとして、選択動作が実行可能なアプリかどうかの判定を行う。本実施形態では、print機能のアクションを指定している。
type602は、アプリA350が扱えるデータ形式を示す。Type602により、クライアントアプリ392を介してアプリA350が実行される時に、クライアントアプリ392とやり取り可能なデータが決定する。本実施形態では、"image/*"とし、MIMEタイプを用いたあらゆるフォーマット形式の画像を扱うことを指定している。
title603は、アプリA350のタイトルを示す。クライアントアプリ392が、ユーザが選択した動作要求時に実行可能なアプリを一覧表示する際、アプリA350はtitle603に記載された文字列をタイトルとするアプリとして表示される。
href604は、アプリA350のURLを示す。クライアントアプリ392を介してアプリA350が選択された時、クライアントアプリ392は、href604に記載されたURLのアプリを実行する。
disposition605は、アプリA350の表示形態を示す。disposition605により、クライアントアプリ392を介してアプリA350が選択された時、アプリA350のWebブラウザ320上での表示方法が決定される。本実施形態では、"inline"すなわちクライアントアプリ392を実行中の画面上に、アプリA350を表示すること指定している。

図6(b)は、本実施形態のアプリB360が有するIntent情報ファイル361の構成例である。なお、Intent情報ファイル361は、Intent情報ファイル351と同じ機能を提供し、title613、href614のみ、アプリB360を示すものとする。

図6(c)は、本実施形態のサービスプロバイダ370が有するIntent情報ファイル373の構成例である。なお、Intent情報ファイル373は、Intent情報ファイル351と同じ機能を提供し、title623、href624の指定のみ、サービスプロバイダ370と連携するWebアプリ310を示すものとする。

＜Intent登録処理＞
次に、本実施形態におけるWebブラウザ380へのIntent登録処理について図7から図9を用いて説明する。図7は、Webブラウザ380のIntent登録処理手順を示すシーケンス図である。
ステップS701では、ユーザ700が、ユーザ入力装置202から、Webブラウザ380を起動するボタン(不図示)を押下すると、画像処理装置100は、Webブラウザ380を起動するプログラムを実行する。画像処理装置100は、Webブラウザ380の起動処理プログラム内で、Intent処理部384に関する処理を実行する。
ステップS702では、Webブラウザ380が、Intent処理部384を介してアプリPF320に、起動中のアプリを確認する要求を送信する。すなわちアプリの稼働状況を要求する。また、アプリPF320が、アプリ管理部331を介して、前記確認要求を受信する。
ステップS703では、アプリ管理部331が、アプリ記憶領域330上に存在し、かつ起動状態であるアプリの情報を取得する。すなわちアプリの稼働状況を取得する。具体的には、アプリ管理部331は、アプリ管理テーブル332においてstate502の状態を確認し、「ACTIVE」状態のアプリのbundle501、アプリ情報503を取得する。
ステップS704では、アプリ管理部331が、前記登録情報を元に起動中の全アプリに対し、Intent情報ファイルの確認作業を行い、確認できた場合は、ステップS705-S706を実行する。
ステップS705-S706では、アプリ管理部331が、アプリ記憶領域330上に存在するアプリに対し、アプリに含まれるIntent情報ファイルの取得処理を行う。すなわち、稼働中のアプリに含まれるIntent情報ファイルを取得する。
ステップS707では、アプリ管理部331が、Intent情報ファイルを取得できた場合は、ステップS708-S709を実行する。
ステップS708-S709では、取得したIntent情報ファイルをIntent情報ファイル格納部333に格納する。具体的には、アプリ管理部331は、state502が「ACTIVE」状態であるアプリのbundle501、アプリ情報503を元に、前記情報にひもづく当該アプリのディレクトリを探索する処理を行う。
ステップS704で起動中の全アプリに対してIntent情報ファイルの確認と格納を終えたなら、ステップS710では、アプリPF320が、Webブラウザ380に対し、当該要求が終了した旨を返信する。また、Webブラウザ380が、Intent処理部384を介して、前記返信を受信する。
ステップS711では、Webブラウザ380が、Intent情報ファイル格納部333内に存在する全Intent情報ファイルに対し、Intent情報ファイルの登録処理を行う。ステップS711の処理は、具体的にはステップS712-S715で行われる処理を実行する。
ステップS712-S713では、Webブラウザ380が、Intent処理部384を介して、Intent情報ファイル格納部333内のIntent情報ファイルを取得する。
ステップS714では、Webブラウザ380が、Intent処理部384を介して、当該Intent情報ファイル内に記載された＜intent＞タグデータを解析する。また、ステップS715では、解析された各データ項目を、Intent処理部384内Intentテーブル385のテーブルに登録する。
画像処理装置100は、ステップS715の処理が完了し、かつ、Webブラウザ380のその他の起動処理プログラムの処理完了後、Webブラウザ380を起動し、UI表示装置203を介して画面表示する。

図8は、図7のシーケンスによる、Webブラウザ380へのIntent登録処理の実行後のIntentテーブル385の構成図である。
Intentテーブル385は、登録されたIntent情報を管理するテーブルであるIntent情報テーブル800を有する。Intent情報テーブル800は、＜intent＞タグデータに記載されるデータ項目である、action801、type802、title803、href804、disposition805を有する。
本実施形態では、Intentテーブル385は、図5のアプリ管理テーブルと、図7のシーケンス処理の実行結果により、Intent情報ファイルを持ち、かつ起動状態であるアプリのIntent情報を有する。即ち、アプリA350、サービスプロバイダ370などのIntent情報を有する。また、Intent情報ファイルを持つが、起動されていないアプリB360のIntent情報は、Intent情報ファイル格納部333に存在しないため、Intentテーブル385には登録されていない。同様に、起動されているが、Intent情報ファイルを持たないWebサーバアプリ340は、Intent情報ファイル格納部333に存在しないため、Intentテーブル385には登録されていない。

＜アプリ連携時の画面遷移例＞
図9は、本実施形態におけるWebブラウザ380がIntentを用いたアプリ連携を行う際、実行されるクライアントアプリ392の構成例、及び画面遷移例である。
図9の各画面は、Webブラウザ380が、UI表示装置203上に表示するクライアントアプリ392のUI画面である。ユーザが、Webブラウザ380の起動後、クライアントアプリ392への通信要求をWebブラウザ380から送信する。Webブラウザ380は、Webサーバ390からの応答のHTMLデータを受信し、当該受信データを解析部382により解釈することで、画面表示部383を介してUI表示装置203上に表示される画面である。以下、各画面について説明する。
メニュー画面901は、クライアントアプリ392がWebブラウザ380上で実行された時に表示される、画像処理装置100の利用機能を選択する画面である。この画面にて機能を選択すると、クライアントアプリ392は、Intentテーブル385のIntent情報テーブル800の登録情報を参照し、選択した機能に対応するaction801を有するアプリを表示する。
本実施形態では、クライアントアプリ392は、スキャン、コピー、ファクス、プリンタなどの機能選択画面を構成するHTMLデータを有する。加えて、選択機能に応じてIntentテーブル385のIntent情報テーブル800内登録情報から利用可能なアプリを表示し、連携先アプリとIntentを介したデータ送受信を実行可能なAPIを有するJavaScript(登録商標)を有する。

メニュー画面901から、例えば、ユーザによりプリンタ機能を選択するためのプリンタボタンが押下されると、Webブラウザ380は、プリントアプリ選択画面902へ遷移する。
プリントアプリ選択画面902は、プリンタ機能を実行可能なアプリの一覧をリスト表示する。本実施形態では、クライアントアプリ392が、Webブラウザ380に対し、Intent情報テーブル800内で"http://aaa.bbb.ccc.co.jp/print"としてaction登録されているアプリを問い合わせる。
Webブラウザ380は、当該actionに一致するアプリのIntent登録情報をクライアントアプリ392に返答する。
クライアントアプリ392は、当該actionに対応するIntent情報の各データ項目からプリントアプリ選択画面902を構成する。

以上により、実施形態1では、アプリ連携機能実行のためのIntent登録処理において、アプリPF320上で起動しているアプリのみをIntent登録することが可能になる。具体的には、アプリにIntent情報ファイルを持たせ、Webブラウザ380からアプリPF320に対し、起動中のアプリの確認とIntent情報ファイルの取得要求を行うことで実現される。このことから、画像処理装置100のアプリ管理方法に見合い、かつ、ユーザにとっても安全にアプリ連携機能を実行することが実現可能となる。
なお、Intent情報によるアプリ連携先として使用した、アプリPF320上の各アプリは、本実施形態における登録手段でIntent登録方法が限定されるものではない。即ち、Web Intentsを用いたアプリ連携と同様に、連携先のアプリは、構成するHTMLデータ内にIntent情報として＜intent＞タグデータを有していてもよい。その場合、当該アプリに対し、ユーザは、Intent情報を解釈可能なWebブラウザでアクセスし、＜intent＞タグデータに基づくIntent情報の登録を行うことも可能である。

［実施形態２］
次に、本発明の第2の実施形態を説明する。実施形態1の構成では、ユーザがWebブラウザ380を起動中に、管理者によってアプリの起動状態が変更される場合がある。その際、停止状態となったアプリはIntent登録から除外し、また、起動状態となったアプリは新たにIntent登録を行うといった、Webブラウザ380のIntent登録情報の更新が必要となる。そこで本実施形態2では、アプリPF320上のアプリの起動状態が変化した際、Webブラウザ380に対し更新要求を行う処理を追加する。以下、図10から図12を用いて説明する。

＜WebブラウザのIntent登録更新処理＞
図10は、本実施形態のWebブラウザ380のIntent登録更新処理手順を示すシーケンス図である。
ステップS1001では、図7におけるシーケンスの処理を実行する。即ち、ステップS1001により、実施形態1におけるWebブラウザ380起動時のIntent登録作業が行われ、Intentテーブル385のIntent情報テーブル800には、図8で示したIntent情報が登録される。
ステップS1002では、管理者1000が、アプリPF320に対しアプリのライフサイクル管理(インストール、起動、停止、更新、アンインストール)を行う。本実施形態では、管理者1000が、実施形態1で停止中であったアプリB360に対して、アプリ起動要求を行う。
ステップS1003-S1004では、アプリPF320が、アプリ管理部331を介してアプリB360の起動処理を行い、また、ステップS1005では、アプリ管理テーブル332の更新を行う。本処理により、図5におけるアプリ管理テーブル332の、ApplicationBのstate502が、「ACTIVE」に更新される。
ステップS1006-S1008では、アプリ管理部331が、Intent情報ファイル格納部333に存在している全Intent情報ファイルを削除する。
ステップS703-S709は、図7のステップS703-S709と同等である。これにより改めて状態がActiveなアプリについて、Intent情報ファイル格納部333へのIntent情報の登録が行われる。
ステップS1009では、アプリ管理部331が、Webブラウザ380にIntentテーブル385の更新要求を送信する。この要求は、Intent情報ファイル格納部333のIntent情報ファイルと、Intentテーブル385のIntent情報テーブル内登録情報とを同期するために送信される。
ステップS711-S714は、図7のステップS711-S714と同等である。これによりIntent情報ファイル格納部333のIntent情報ファイルが解析される。
ステップS1010では、Intent処理部384が、ステップS711-S714で解析したIntent情報を、Intentテーブル385のIntent情報テーブル800内のIntent情報と比較する。
ステップS715において、Intent処理部384は、解析したIntent情報がIntentテーブル385のIntent情報テーブル800に存在しなければ、Intentテーブル385に登録する。
またステップS1012において、Intentテーブル385のIntent情報テーブル800にも存在するIntent情報であれば、Intentテーブル385に登録されていた情報を上書きし更新する。
ステップS1012-S1013では、Intentテーブル385のIntent情報テーブル800にしか存在しなかったIntent情報データの削除処理を実行する。
以上の手順でIntent情報ファイル格納部333のIntent情報ファイルと、Intentテーブル385のIntent情報テーブル内登録情報との同期がとられる。

図11は、図10のシーケンスによる、Webブラウザ380へのIntent登録更新処理の実行後のIntentテーブル385の構成である。Intentテーブル385のIntent情報テーブル800は、アプリA350、サービスプロバイダ370のIntent情報に加え、アプリB360のIntent情報1100を有する。

＜アプリ連携時の画面遷移例＞
図12は、Webブラウザ380がIntentを用いたアプリ連携を行う際、実行されるクライアントアプリ392の構成、及び画面遷移の説明図である。なお、メニュー画面901、及びクライアントアプリ392を構成するデータは、実施形態1と同等である。メニュー画面901から、ユーザによりプリントボタンが押下されると、Webブラウザ380は、プリントアプリ選択画面1200へ遷移する。プリントアプリ選択画面1200は、プリントアプリ選択画面902と同様の機能を有している。但し、図11に示すIntentテーブル385のIntent情報テーブル800に、アプリB360のIntent情報1100が追加されていることより、選択可能なアプリとして「print appli B」が表示される。
以上により、実施形態2では、アプリPF320のアプリに起動状態の変化が行われた場合、Webブラウザ380は、前記変化と同期したIntent登録情報の更新が可能になる。なお本実施形態では、Webブラウザ380のIntent登録更新処理を行った後、Webブラウザ380がクライアントアプリ392を実行し、Intent登録情報を参照する例を提示している。しかしながら、本実施形態におけるIntent登録更新処理は、クライアントアプリ392の実行中においても行われてもよい。即ち、クライアントアプリ392実行中に図10のシーケンス処理が実行されると、Webブラウザ380は、Intent処理部384のIntentテーブル385を内部的に更新する。従って、クライアントアプリ392において、メニュー画面901からプリントアプリ選択画面1200への遷移時など、Intent登録情報を利用する時には、更新されたIntentテーブル385のIntent情報テーブル800が反映される。

［実施形態３］
次に、本発明の第3の実施形態を説明する。実施形態1の構成では、Webブラウザ380は、Webアプリ310に対して、指定されたURLにアクセスしWebアプリ310が起動中かどうかの確認を行わない。そのため、サービスプロバイダ370からIntent情報ファイルを取得し、Webブラウザ380にIntent登録を行っていても、Webアプリ310が起動していない状況が発生し得る。その場合、アプリが実行不可能な状態にもかかわらず、クライアントアプリ392が実行可能なアプリとして一覧表示してしまう。そこで、実施形態3では、Webアプリ310を、Intent情報ファイルを介してIntent登録する場合、Webアプリ310の起動状態を確認した上でIntent登録する処理を追加する。以下、図13から図18を用いて説明する。まず、本実施形態における、Webブラウザ380のIntent登録処理手順を図13から図15を用いて説明する。

＜WebブラウザのIntent登録更新処理＞
図13は、Webブラウザ380のIntent登録処理手順を示すシーケンス図である。
ステップS701からステップS714は、図7と同等であるため説明を省略する。この手順によりIntent情報ファイル格納部333に起動中のアプリに関するIntent情報が登録され、さらに、Intentテーブル385のIntent情報テーブル内登録情報の解析が行われる。
ステップS1300-S1305では、Webブラウザ380が、Intent処理部384から通信部381を介し、Intent情報ファイル内のhrefに記載されたURLに対してWebアプリの起動確認を行う。
ここでは、実施形態1の構成より、図13のシーケンス図におけるWebアプリの起動確認の送信先を、アプリ記憶領域330(S1300)/Webアプリ310(S1303)と明記している。しかし、Intent情報ファイル内のhrefの指定先が上記以外であれば、当該hrefの指定先に対し、同様の処理を行うものとする。
また、本実施形態では、ステップS1301-S1302でアプリ記憶領域内のアプリに対して、S1303-S1304で外部装置のアプリに対して起動確認を行う。そのWebアプリの起動確認方法として、Intent処理部384がhrefの指定先にHTTPでアクセスできるかの要求を送信する。そして、当該要求処理に対するHTTPステータスコードの応答より起動状態の判定を行うものとする。しかしながら、当該ステップの起動確認処理は、hrefの指定先URLの起動状態を確認できる手法であれば構成に制限はない。
ステップS1306-S1307では、Webブラウザ380が、Webアプリの起動確認の結果を判定する。アプリが起動中であれば(ステップS1306)、ステップS715として、Intentテーブル385のIntent情報テーブル800にIntent情報の登録を行う。アプリにアクセスできないなど、アプリが起動中以外であれば(ステップS1307)、ステップS1308として、Intentテーブル385の利用不可Intent情報テーブル1400に利用不可Intent情報として記憶する。
以上の手順でIntent情報ファイル格納部333のIntent情報ファイルと、Intentテーブル385のIntent情報テーブル内登録情報との同期がとられ、かつIntentテーブル385に登録したIntent情報は、アクセス可能のアプリとアクセス不可のアプリとに分けて登録される。
なお図13ではアプリの起動要求がWebアプリ310等の外部システムからあった場合について説明しているが、停止要求があった場合も同様にIntent情報ファイルが更新される。

ここで、本実施形態のIntentテーブル385の利用不可Intent情報テーブル1400について説明する。図14は、本実施形態のIntentテーブル385の構成図である。
Intentテーブル385は、Intent情報テーブル800と、利用不可Intent情報テーブル1400で構成される。
Intent情報テーブル800は、図8におけるIntentテーブル385と同等の構成を有するテーブルである。また、本テーブル内のIntent情報が、Intent処理部384により、Webブラウザ380に登録されたIntent情報として認識される。
利用不可Intent情報テーブル1400は、Intent情報ファイル内のhrefの指定先のアプリが利用不可能であるIntent情報を記憶する。また、＜intent＞タグデータに記載されるデータ項目である、action1401、type1402、title1403、href1404、disposition1405を対応付けて管理する。更に、利用不可Intent情報テーブル1400に記憶されたIntent情報は、Intent処理部384によって、Webブラウザ380に登録されたIntent情報として認識されない。

図13におけるシーケンス図の説明に戻る。画像処理装置100は、ステップS1308までの処理が完了し、かつ、Webブラウザ380のその他起動プログラムの処理完了後、Webブラウザ380を起動し、UI表示装置203を介して画面表示する。
図13のシーケンスによる、Webブラウザ380へのIntent登録処理の実行後のIntentテーブル385の構成図を、前述の図14で説明する。本実施形態では、実施形態1の構成に加え、Webアプリ310が起動していない状態でWebブラウザ380を起動し、図13に示すシーケンス処理が行われたものとする。即ち、Intentテーブル385は、Intent情報ファイルを持ち、かつ起動状態であるアプリA350などのIntent情報をIntent情報テーブル800に有する。また、Intent情報ファイルを持つが、起動されていないアプリB360のIntent情報は、Intent情報ファイル格納部333に存在しないため、Intentテーブル385には登録されていない。同様に、起動されているが、Intent情報ファイルを持たないWebサーバアプリ340は、Intent情報ファイル格納部333に存在しないため、Intentテーブル385には登録されていない。更に、Webアプリ310が停止していたサービスプロバイダ370のIntent情報は、利用不可Intent情報テーブル800に記憶される。

＜アプリ連携時の画面遷移例＞
図15は、Webブラウザ380がIntentを用いたアプリ連携を行う際、実行されるクライアントアプリ392の構成例、及び画面遷移例の説明図である。なお、メニュー画面901、及びクライアントアプリ392を構成するデータは、実施形態1と同等のものである。
メニュー画面901から、ユーザによりプリントボタンが押下されると、Webブラウザ380は、クライアントアプリ392をプリントアプリ選択画面1500へ遷移する。
プリントアプリ選択画面1500は、プリントアプリ選択画面902と同様の機能を有している。しかし、図14に示すIntentテーブル385において、Intent情報テーブル800にアプリA350のIntent情報が登録されていることより、選択可能なアプリとして「print appli A」だけが表示される。

＜アプリへの問い合わせに応じたIntent登録情報の更新処理＞
続いて、Intent登録処理完了後の、Intent登録情報の更新処理について図16から図18を用いて説明する。まず、Intentテーブル385の利用不可Intent情報テーブル1400に登録されたアプリに対する、Intent登録情報更新処理を、図16、図17で説明する。なお、本実施形態では、Webブラウザ380の起動完了後、図14のIntentテーブルを有しており、その後、Webアプリ310が利用可能な状態に更新された条件での処理を説明する。

図16は、Webブラウザ380のIntent登録更新処理として、停止中のWebアプリ310が起動した場合の、Intentテーブル385の更新手順を示すシーケンス図である。即ち、利用不可Intent情報テーブル1400にIntent情報が存在する場合の、Intentテーブル385の更新手順の説明である。
ステップS1600では、図13におけるシーケンスの処理を実行する。即ち、ステップS1600により、画像処理装置100は図13のシーケンスの処理実行後と同等の状態を有する。
ステップS1601では、Webブラウザ380が、Intent処理部384によりIntentテーブル385の利用不可Intent情報テーブル1400にIntent情報が存在しているかを周期的に確認する。
利用不可Intent情報テーブル1400にIntent情報が存在していた場合、ステップS1602において、Intent処理部384は、全ての利用不可Intent情報に対し更新確認を行う。
ステップS1603では、Intent処理部384が、Intentテーブル385内の利用不可Intent情報を取得する。
ステップS1304-S1305、及びステップS1306、S715は、図13のステップS1304-S1305、及びステップS1306、S715と同等である。すなわちステップS715においては、利用可であるIntent情報を登録する。
ステップS1604では、Intent処理部384が、ステップS1603で取得したIntentテーブル385の利用不可Intent情報テーブルの当該利用不可Intent情報を削除する。

図17は、図16のシーケンスによる、Webブラウザ380へのIntent登録更新処理の実行後のIntentテーブル385の構成である。図16のシーケンスの処理実行の結果、Intentテーブル385内Intent情報テーブル800は、起動されたWebアプリ310に対応するサービスプロバイダ370のIntent情報1700が追加される。一方で、Intentテーブル385内利用不可Intent情報テーブル1400は、サービスプロバイダ370のIntent情報1700が削除される。以上の処理から、本実施形態におけるWebブラウザ380がIntentによるアプリ連携を行う際、実行されるクライアントアプリ392の構成、及び画面遷移例は、図9と同等の構成を有することとなる。

＜アプリからの通知に応じたIntent登録情報更新処理＞
次に、Intentテーブル385内のIntent情報テーブル800で登録されたアプリに対する、Intent登録情報更新処理を図18で説明する。なお、本実施形態では、図16のシーケンス処理を行い、図17のIntentテーブル385を有している状態から、Webアプリ310が利用不可能な状態に更新された条件での処理を説明する。図18は、本実施形態のWebブラウザ380のIntent登録更新処理として、起動中のWebアプリ310が停止した場合のIntentテーブル385の更新手順を示すシーケンス図である。即ち、Intent情報テーブル800にIntent情報が存在する場合の、Intentテーブル385の更新手順の説明である。
ステップS1800では、図16におけるシーケンスの処理を実行する。即ち、ステップS1800により、画像処理装置100は図16のシーケンスの処理実行後と同等の状態を有する。なおステップS1800では、図16に代えて図13のシーケンスの処理を実行してもよい。
ステップS1801では、Webアプリ310が、アプリの起動を停止した場合、Webアプリ310と通信を行っていたWebブラウザ380に対してIntent情報利用不可の通知を行う。なお、本実施形態では、Webアプリ310は、停止処理時に連携元のWebブラウザ380に通知処理を行う機能を有し、また、Webブラウザ380のIntent処理部384は、当該通知を受信する機能を有する。この通知機能は、Webアプリ310からWebブラウザ380のIntent処理部384に対して通信可能なプロトコルで、かつWebアプリ310の停止通知であることを一意に特定できれば、構成に制限はない。例えば、Intent処理部384内にソケット通信サーバ処理機能を実装する。Webアプリ310側では、HTTP Requestにより接続要求を行った画像処理装置100のIPアドレスを保存し、停止処理実行時に当該IPアドレスに対して、ソケット通信データを送信する。その後、Intent処理部384が、当該通信データを受信する、といった構成でもよい。
ステップS1802では、Webブラウザ380は、Intent処理部384を介して通知元のWebアプリ310のURLと一致するhref804をIntentテーブル385のIntent情報テーブル800から探索する。そして、探索の結果、当該URLと一致するhref804を有するIntent情報を、Intent情報テーブル800から取得する。本実施形態の例では、Webアプリ310がソケット通信データとしてWebアプリ310のURL文字列を送信し、Intent処理部384が当該データを解析し、解析したURLからIntent情報テーブル800を探索する。
ステップS1803では、Intent処理部384が、ステップS1802で取得したIntent情報をIntentテーブル385の利用不可Intent情報テーブル1400に記憶する。
ステップS1804では、Intent処理部384が、ステップS1802で取得したIntent情報をIntentテーブル385のIntent情報テーブル800から削除する。

図18のシーケンスによる、Webブラウザ380へのIntent登録更新処理の実行後のIntentテーブル385の構成は、図14と等しいものになる。また図18のシーケンスの処理実行の結果、Intentテーブル385内Intent情報テーブル800は、新たに停止されたWebアプリ310に対応するサービスプロバイダ370のIntent情報1700が削除される。一方で、Intentテーブル385内利用不可Intent情報テーブル1400は、サービスプロバイダ370のIntent情報1700が追加される。
以上の処理から、本実施形態におけるWebブラウザ380がIntentによるアプリ連携を行う際、実行されるクライアントアプリ392の構成、及び画面遷移例は、図15と同様の構成を有することとなる。

以上が、本実施形態における、Webブラウザ380のIntent登録情報の更新処理手順の説明である。本実施形態3を用いることにより、Webアプリ310の起動状態の変化が行われた場合、Webブラウザ380は、前記変化と同期したIntent登録情報の登録、更新が可能になる。

［実施形態４］
次に、本発明の第4の実施形態を説明する。画像処理装置には、ユーザ名、パスワード入力や、認証カードなどを用いたユーザ認証機能を有するものがある。このような画像処理装置では、例えば、ユーザ認証機能で用いるユーザ名やパスワードを記憶する認証データベースに対し、役割や利用可能なデバイス機能の制限情報を加えて登録する。このことにより、当該ユーザログイン時に、ユーザが使用できるアプリを限定する、といった運用が行われる。前記画像処理装置に対し実施形態1の処理を追加する場合、アプリPF320上のアプリには、ユーザ権限情報により使用制限が行われるが、Intent情報ファイルの情報には、使用制限が考慮されていない。即ち、使用権限がないアプリであるにもかかわらず、Webブラウザ380が、Intent情報ファイルを介して当該アプリをIntent登録してしまう可能性がある。そこで実施形態4では、認証機能を有する画像処理装置100において、アプリPF320にインストールするアプリに認証情報ファイルを追加する。そして、Webブラウザ380へのIntent登録時に、ユーザ権限情報と認証情報ファイルを比較し、権限が一致する場合Intent登録する処理を追加する。以下、図19から図27を用いて説明する。まず、本実施形態における、Webブラウザ380へのIntent登録手順を図19から図25を用いて説明する。

＜ソフトウェア構成＞
図19は、本実施形態の外部装置と画像処理装置のソフトウェア構成例を示す図である。図19に示す各機能部は、画像処理装置100/外部装置101それぞれが有するCPU204/CPU212が、記憶装置208/記憶装置214に記憶される制御プログラムをRAM205/RAM213上に読み出して実行することで実現される。以下、図19においての差分機能のみ説明する。

ログインアプリ1900は、画像処理装置100において、ユーザ認証に関わる処理を行うアプリである。ログインアプリ1900は、認証DB1901を有する。
認証DB1901は、ユーザ名とパスワードなどの各ユーザの認証情報と、権限情報を有する。この権限情報とは、各ユーザの役割(一般ユーザ、管理者など)や利用可能なデバイス機能(コピー機能、プリンタ機能など)などが登録されたものである。
各ユーザは、権限情報により、自身が有する権限に応じて当該情報で制限される機能のみ使用可能となる。例えば、コピー機能を実現するアプリに対し権限情報に、ユーザの役割を「管理者」として指定した場合、「一般ユーザ」の役割を権限情報として有するユーザは、画像処理装置100にログインしても、当該アプリを使用することはできない。
ログインアプリ1900は、画像処理装置100のUI表示装置203に認証画面を表示し、ユーザ入力装置202を介した認証情報の受信を行う。また、受信した認証情報を認証DB1901内に登録された各ユーザの認証情報と照合し、認証を実施する。
認証が成功すると、ログインアプリ1900は、認証DB1901から権限情報を取得し、アプリ管理部331、権限情報管理部1910に当該情報を送信する。
権限情報管理部1910は、Webブラウザ380において、現在ログインしているユーザの権限情報を管理する機能を有する。また権限情報管理部1910は、ログインアプリ190から送信される権限情報を受信し、当該情報で制限される機能のみを有効にする。
Intent情報ファイル1920、1930、1940は、Intent情報ファイル351、361、373と同等の情報を有するファイルである。本実施形態では加えて、Intent情報ファイル1920、1930、1940は、ユーザ権限情報を有するものとする。当該ファイルの構成は、図22にて後述する。

＜アプリ管理テーブル＞
図20は、本実施形態におけるアプリ管理テーブル332の構成図である。アプリ管理テーブル332は、図5で示したものと同等の情報を管理する。本実施形態では、ログインアプリ1900が、bundle501に「LoginApplication」として登録されており、2000で示すテーブル列に、ログインアプリ1900の各情報が登録されている。また、アプリ管理テーブル332に登録されたアプリのstate502が全て「ACTIVE」状態となっており、全てのアプリが起動された状態であるものとする。

＜ログイン手順＞
図21は、本実施形態におけるログインアプリ1900を用いたユーザ権限の遷移を示すフローチャート図である。図21を用いて、ログインアプリ1900によるログイン手順と、アプリPF320、Webブラウザ380のユーザ権限状態の遷移について説明する。
画像処理装置100の起動後、ステップS2101として、アプリPF320が、アプリ管理部331内に存在する権限情報を初期化し、権限なしの状態にする。権限なしの状態とは、即ち、ユーザが未ログイン状態であることを表し、権限情報を一切有していない。従って、権限なしの状態では、ユーザ2100は、アプリPF320において、権限情報によって制限される機能を有するアプリ以外のアプリのみに使用を限定される。
ステップS2102では、Webブラウザ380が、権限情報管理部1910内に存在する権限情報を初期化し、権限なしの状態にする。権限なしの状態では、ユーザは、Webブラウザ380において権限情報によって制限される機能以外の機能のみに使用を限定される。
ステップS2104では、アプリPF320は、ログインアプリ1900を介したログイン要求の受信待機処理を行い、ステップS2103におけるユーザ2100からのログイン要求指示があるまで待機する。本実施形態では、ログインアプリ1900は、画像処理装置100のUI表示装置203にユーザ名、パスワード入力画面を表示し、ユーザ入力装置202を介したログイン要求による当該情報の受信を行う機能を提供するものとする(不図示)。但し、ログインアプリ1900は、ユーザを一意に特定できる認証機能を有するものであれば構成に制限はない。例えば、ユーザ入力装置202としてカードリーダを接続し、認証カードの情報を読み取り認証を行うアプリ機能でもよい。
ステップS2105では、アプリPF320が、ログインアプリ1900を介して受信した当該ログイン要求の認証判定を行う。具体的には、ログイン要求情報と認証DB1901内に登録された認証情報を照合し、当該要求が正しいものか判定することで実施される。
ログイン要求が正しいと判定されれば、ステップS2106において、ログインアプリ1900が、認証DB1901内に登録されたユーザ2100の権限情報を取得する。本実施形態においては、ユーザ2100は、権限情報として一般ユーザ(GeneralUser)の役割(role)を有し、roleをGeneralUserとして指定する制限機能、及び権限なし状態で使用可能な機能を利用できる。
ステップS2107では、アプリ管理部331が、ログインアプリ1900から取得されたログインユーザの権限情報を用いて、アプリ管理部331で保有する権限情報をユーザ2100の権限情報に更新する。
ステップS2108では、アプリPF320が、Webブラウザ380への更新通知として、アプリ管理部331で保有するログインユーザの権限情報を権限情報管理部1910へ送信する。
ステップS2109では、Webブラウザ380が、権限情報管理部1910の権限情報を、通知されたログインユーザの権限情報に更新する。本実施形態においては、ユーザ2100の権限情報に更新される。即ち、権限情報のroleが指定なしからGeneralUserとなり、roleをGeneralUserとして指定する制限機能、及び権限なし状態で使用可能な機能を利用できる。
また、ログインアプリ1900は、ログインユーザがログアウトした場合、同様にアプリ管理部331、権限情報管理部1910に対し権限情報の初期化要求を送信する(不図示)。以下、概要を説明する。

ユーザ2100がログイン後、ログインアプリ1900を介したログアウト要求を行う。
当該ログアウト要求をログインアプリ1900が受信すると、アプリ管理部331、権限情報管理部1910に対し権限情報の初期化要求を送信する。
当該初期化要求をアプリ管理部331、権限情報管理部1910が受信し、各々が有している権限情報を初期化し、権限なしの状態に更新する。

＜権限情報を含むIntent情報ファイル＞
図22は、本実施形態のアプリが有するIntent情報ファイルの構成例である。図22(a)は、アプリA350が有するIntent情報ファイル1920の構成例である。
Intent情報ファイル1920は、＜intent＞タグデータ600を有しており、このデータ項目は、図6(a)で示すIntent情報ファイル351と同等である。Intent情報ファイル1920は加えて、権限情報を表す＜permission＞タグデータ2200を有する。
＜permission＞タグデータ2200は、アプリA350が有する権限情報を記載したものである。この権限情報は、ログインアプリ1900で管理される権限情報と同一のものであり、各ユーザの役割や利用可能なデバイス機能などが指定される。本実施形態では、Intent情報ファイル1920は、＜permission＞タグデータ2200として、role2201が指定されている。role2201は、ユーザの役割を表す項目であり、指定なし(権限なし/未ログインユーザ)、GeneralUser(一般ユーザ)、Administrator(管理者)などを指定する。本実施形態では、アプリA350は、role2201にAdministratorが指定されており、管理者権限を有するユーザに使用が限定されているものとする。

図22(b)は、アプリB360が有するIntent情報ファイル1930の構成例である。
Intent情報ファイル1930は、＜intent＞タグデータ610を有しており、このデータ項目は、図6(b)で示すIntent情報ファイル361と同等である。また、Intent情報ファイル1930は、＜permission＞タグデータを有していない。これは、アプリB360は使用に権限が必要でなく、ユーザが未ログイン状態でも使用できることを意味する。

図22(c)は、サービスプロバイダ370が有するIntent情報ファイル1940の構成例である。
Intent情報ファイル1940は、＜intent＞タグデータ620を有しており、このデータ項目は、図6(c)で示すIntent情報ファイル373と同等である。Intent情報ファイル1940は加えて、＜permission＞タグデータ2210を有する。本実施形態では、Intent情報ファイル1940は、＜permission＞タグデータ2210として、role2211にGeneralUserの指定を有する。即ち、サービスプロバイダ370及びWebアプリ310は、一般ユーザ権限を有するユーザに使用が限定されている。

なお、本実施形態では、Intent情報ファイルに権限情報として＜permission＞タグデータを追記している。但し、Intent情報ファイルと対になり、同一アプリに関する権限情報であることが確認できれば構成に制限はない。例えば、権限情報ファイルとして作成する形式でもよいし、＜intent＞タグデータ内に権限情報タグデータを含める形式でもよい。

＜ログインユーザ不在時のIntent登録処理＞
図23は、本実施形態のWebブラウザ380のIntent登録処理として、ユーザが未ログイン時の場合の手順を示すシーケンス図である。以下、図23を用いて説明する。
ステップS701-S710の処理は、図7のステップS701-S710と同等である。これによりIntent情報ファイル333に起動中のアプリのIntent情報が登録される。
ステップS2300-S2301では、Webブラウザ380が、Intent処理部384を介して権限情報管理部1910に対しユーザの権限情報の取得処理を行う。具体的には、ユーザ2100が未ログインの状態であるため、Intent処理部384はユーザの権限情報として権限なしの情報が取得される。
ステップS711-S714の処理は、図7のステップS711-S714と同等である。これによりIntent情報ファイル333に登録された各アプリのIntent情報が解析される。
ステップS2302-S2303では、Intent処理部384が、権限情報管理部1910から取得したユーザの権限情報と、解析したIntent情報ファイルの各アプリの権限情報を比較する。比較した結果、権限情報が一致しなければ、Intentテーブル385の権限不一致Intent情報テーブル2410に記憶する。なお一致とは完全一致ではなく、ログインユーザに与えられた権限が、アプリの利用が許容される権限と同様か、あるいはそれよりも高い権限であることを含む。すなわち、ログインユーザがアプリを利用可能な権限を有していればここでは「権限の一致」と判定する。以下の説明においても同様である。なお本例のようにログインされていない場合には、ログインユーザの権限は「権限なし」である。

ここで、本実施形態のIntentテーブル385の権限不一致Intent情報テーブル2410について説明する。図24は、本実施形態のIntentテーブル385の構成図である。
Intentテーブル385は、Intent情報テーブル800と、利用不可Intent情報テーブル1400、及び権限不一致Intent情報テーブル2410で構成される。
Intent情報テーブル800は、図8のテーブル構成に加えて、Intent情報に対応する権限情報2400を有し、Intent処理部384により解析される＜permission＞タグデータに記載されたroleなどの権限情報を記憶する。Intent情報テーブル800は、ログインユーザの権限情報が、＜permission＞タグデータで制限される権限と一致しており、かつ、hrefの指定先アプリが起動中であるアプリのIntent情報を有する。また、本テーブル内のIntent情報が、Intent処理部384により、Webブラウザ380に登録されたIntent情報として認識される。
利用不可Intent情報テーブル1400は、図14の利用不可Intent情報テーブル1400に加えて、Intent情報テーブル800と同様にIntent情報に対応する権限情報2410を有する。利用不可Intent情報テーブル1400は、ログインユーザの権限情報が、＜permission＞タグデータで制限される権限と一致しているとしても、hrefの指定先のアプリにアクセス不可能であるアプリのIntent情報を有する。また、利用不可Intent情報テーブル1400に記憶されたIntent情報は、Intent処理部384により、Webブラウザ380に登録されたIntent情報として認識されない。利用不可Intent情報テーブル1400にrole2401を保持しておくことで、たとえば利用不可Intent情報テーブル1400からIntent情報テーブル800へとIntent情報を移すことができる。
権限不一致Intent情報テーブル2410は、ログインユーザ権限情報が、Intent情報に対応する＜permission＞タグデータに記載された権限に一致せず、利用不可能であるIntent情報を記憶する。権限不一致Intent情報テーブル2410は、＜intent＞タグデータに記載されるデータ項目である、action2411、type2412、title2413、href2414、disposition2415を対応付けて管理する。加えて、Intent情報に対応する権限情報2416を有し、Intent処理部384により解析される＜permission＞タグデータに記載されたroleなどの権限情報を記憶する。また、権限不一致Intent情報テーブル2410に記憶されたIntent情報は、Intent処理部384により、Webブラウザ380に登録されたIntent情報として認識されない。

図23におけるシーケンス図の処理の説明に戻る。ステップS2304は、Intent処理部384が、権限情報管理部1910から取得したユーザの権限情報と、解析したIntent情報ファイルの権限情報を比較し、権限情報が一致した場合の処理である。具体的な処理は、ステップS1300-S1308及びステップS715であり、当該処理は、図13のステップS1300-S1308及びステップS715と同等である。すなわち、権限が一致するアプリについて、その起動確認を行い、起動しているアプリについてはそのIntent情報をIntent情報テーブル800に登録し、起動していないアプリについてはそのIntent情報を利用不可Intent情報テーブル1400に登録する。

図23のシーケンスによる、Webブラウザ380へのIntent登録処理の実行後のIntentテーブル385の構成図を図24で説明する。本実施形態では、Intentテーブル385は、図23のシーケンス処理により、Intent情報ファイルを持ち、かつ権限情報が指定なしである（すなわち権限がないユーザによる利用が許可された）アプリB360のIntent情報を、Intent情報テーブル800に登録する。また、＜permission＞タグデータによりユーザ権限が指定されているアプリA350、サービスプロバイダ370のIntent情報は、未ログイン状態のため権限が一致せず、権限不一致Intent情報テーブル2410に記憶される。

＜アプリ連携時の画面遷移例＞
図25は、本実施形態におけるWebブラウザ380がIntentを用いたアプリ連携を行う際、実行されるクライアントアプリ392の構成例、及び画面遷移例の説明図である。なお、メニュー画面901、及びクライアントアプリ392を構成するデータは、実施形態1と同等である。
メニュー画面901から、ユーザによりプリントボタンが押下されると、Webブラウザ380は、プリントアプリ選択画面2500へ遷移する。
プリントアプリ選択画面2500は、プリントアプリ選択画面902と同様の機能を有している。しかし、図24に示すIntentテーブル385において、Intent情報テーブル800にアプリB360のIntent情報が登録されていることより、選択可能なアプリとして「print appli B」だけが表示される。

＜Intent登録情報更新処理＞
次に、ユーザが画像処理装置100に対し、ログインアプリ1900を介したログイン状態の変更を行った場合の、Webブラウザ380のIntent登録情報更新処理について、図26から図27を用いて説明する。

図26は、本実施形態のWebブラウザ380のIntent登録更新処理として、ユーザがログインした場合の更新処理手順を示すシーケンス図である。
ステップS2600では、図23におけるシーケンスの処理を実行する。即ち、ステップS2600により、画像処理装置100は図23のシーケンスの処理実行後と同等の状態を有し、Intentテーブル385は、図24で示すテーブル状態を有する。
ステップS2601では、図21におけるフローチャートの処理を実行する。即ち、ステップS2601により、画像処理装置100は図21におけるフローチャートの処理実行後と同等の状態を有する。従って、アプリ管理部331及び権限情報管理部1910は、ユーザの権限情報として、たとえばroleにGeneralUserが指定された状態を有する。
ステップS2602では、Webブラウザ380の権限情報管理部1910が、Intent処理部384に対し、ユーザの権限情報の更新通知を行う。
ステップS2300-S2301の処理は、図23のステップS2300-S2301と同等である。
ステップS2603では、Intent処理部384が、Intentテーブル385内のIntent情報テーブル800、権限不一致Intent情報テーブル2410の全てのIntent情報に対し、権限情報の確認を行う。具体的には、ステップS2604以降の処理の実行により確認を行う。
ステップS2604では、Intent処理部384が、Intent情報テーブル800、または権限不一致Intent情報テーブル2410内のIntent情報を取得する。このとき、Intent処理部384は、Intent情報とともに対となる権限情報も取得する。
ステップS2605では、Intent処理部384が、取得したIntent情報の取得元のテーブルに記憶されているIntent情報を削除する。このとき、Intent処理部384は、Intent情報とともに対となる権限情報も削除する。
ステップS2606は、Intent処理部384が、権限情報管理部1910から取得したユーザの権限情報と、ステップS2604で取得したIntent情報ファイルの権限情報を比較し、権限情報が一致しない場合の処理である。具体的な処理は、ステップS2303であり、当該処理は、図23のステップS2303と同等である。
ステップS2607は、Intent処理部384が、権限情報管理部1910から取得したユーザの権限情報と、ステップS2604で取得したIntent情報ファイルの権限情報を比較し、権限情報が一致した場合の処理である。具体的な処理は、ステップS1300-S1308及びステップS715であり、当該処理は、図13のステップS1300-S1308及びステップS715と同等である。

＜Intentテーブルの例＞
図27は、図26のシーケンスによる、Webブラウザ380へのIntent登録更新処理の実行後のIntentテーブル385の構成図である。Intentテーブル385は、図26のシーケンス処理により、Intent情報ファイルを持ち、かつ権限情報が指定なし、またはroleがGeneralUserであるアプリを、Intent情報テーブル800に登録される。即ち、アプリB360に加え、2700で示すサービスプロバイダ370のIntent情報及び権限情報が、Intent情報テーブル800に登録される。また、権限不一致Intent情報テーブル2410は、ユーザ2100のログインに伴い、2700で示すサービスプロバイダ370のIntent情報及び権限情報が削除される。

以上の処理から、Webブラウザ380がIntentによるアプリ連携を行う際、実行されるクライアントアプリ392の構成、及び画面遷移例は下記に示す状態となる(不図示)。
メニュー画面901からプリントアプリ選択画面(不図示)に遷移した際、Intent情報テーブル800より、選択可能なアプリとして、「print appli B」と「print appli SP」が表示される。

以上が、本実施形態における、ユーザがログインアプリを介してログインした場合の、Webブラウザ380のIntent登録情報更新処理についての説明である。実施形態4では、Webブラウザ380は、ユーザの権限情報を考慮した、Intent登録情報の登録、更新が可能になる。なお、本実施形態では、Intent情報ファイルに権限情報を加え、Webブラウザ380が、Intent情報を登録する際にユーザ権限の確認を行う構成を取っている。しかしながら、当該ユーザ権限確認の動作は、アプリ管理部331が行う構成でもよい。即ち、アプリ管理部331が、起動中アプリ確認処理(S703-S709)において、ログインアプリ1900より取得したユーザの権限情報と、Intent情報ファイル内の権限情報を比較する。比較の結果、権限が一致したIntent情報ファイルのみをIntent情報ファイル格納部333に格納する、といった形式でもよい。同様に、ログインアプリ1900の権限情報に、Intentを利用するアプリの機能制限情報を追加する構成でもよい。即ち、ログインアプリ1900の認証DB1901の権限情報に、Intent機能を介して利用可能なデバイス機能(コピー機能、プリンタ機能など)を追加する。加えて、アプリの権限情報にも、Intent機能を介して利用可能なデバイス機能の権限情報を付加する形式でもよい。この場合、例えば、コピー機能を実現するアプリの権限情報として、Intent機能の権限情報項目にコピー機能が宣言されているものとする。その場合、アプリ管理部331は、Intent機能の権限情報項目にコピー機能を有するユーザがログインしている時のみ、当該アプリのIntent情報ファイルをIntent情報ファイル格納部333に格納する。従って、ユーザの権限情報を確認した上で、Intent処理部384が、使用可能なアプリのIntent情報ファイルのみを取得し、かつ権限として許可されるIntent情報のみを登録できるようになる。

なお、本発明は、具体的に開示された実施形態に限定されるものではなく、特許請求の範囲から逸脱することなく、種々の変形や変更が可能である。

また上記実施形態において、Intent情報テーブル800や利用不可Intent情報テーブル1400、権限不一致Intent情報テーブル2410等は別々のテーブルとして用意されているが、一つのテーブルにまとめ、各アプリのIntent情報ごとに、利用可、利用不可、権限なし、といった状態を示す情報のフィールドを付加してもよい。

［その他の実施形態］
また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（または情報処理装置やＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。

Claims (11)

1. 複数のアプリケーションが稼働できるプラットフォームを有する情報処理装置であって、
   前記プラットフォームが、
   アプリケーションのインストール、起動、停止、アンインストールの要求に応じた稼働状況を取得する取得手段と、
   前記アプリケーションを用いて提供されるサービスに関する機能情報を、前記取得手段により取得された稼働状況に従い管理する管理手段とを有し、
   前記情報処理装置内の起動中のアプリケーションと、ウェブアプリケーションを有する外部システムと、が連携することで提供されるサービスに関する機能情報は、該外部システムとのネットワークを介した通信に従い稼働中であるか否かが決定される稼働状況に従い、前記管理手段により管理され、
   前記情報処理装置で実行されるサービスの呼び出し元となるウェブブラウザによる前記機能情報を用いたサービスの呼び出しの受け付けに応じて、前記管理手段により管理されている、前記稼働状況が稼働中を示すサービスが実行される
   ことを特徴とする情報処理装置。
2. 前記管理手段は、前記ウェブブラウザからの要求に応じて、前記機能情報の一覧を前記アプリケーションから取得し、管理することを特徴とする請求項１に記載の情報処理装置。
3. 前記機能情報は、Web Intentsに係るIntent情報であることを特徴とする請求項１または２に記載の情報処理装置。
4. 前記管理手段は、前記外部システムとの通信によりアプリケーションの稼働状況が変化した場合には、管理している前記機能情報を更新することを特徴とする請求項１に記載の情報処理装置。
5. 前記管理手段は、前記ウェブブラウザからの要求に応じて前記機能情報を前記ウェブブラウザに対して送信することを特徴とする請求項１乃至４のいずれか一項に記載の情報処理装置。
6. 前記管理手段はログインユーザの権限情報を更に管理し、
   前記アプリケーションの機能情報には、当該アプリケーションを実行できるユーザの権限情報が更に含まれることを特徴とする請求項１乃至５のいずれか一項に記載の情報処理装置。
7. 前記ウェブブラウザは、前記管理手段から前記機能情報を取得し、取得した前記機能情報をアプリケーションの稼働状況ごとに管理することを特徴とする請求項１乃至６のいずれか一項に記載の情報処理装置。
8. 前記管理手段は、前記機能情報の更新を前記ウェブブラウザに通知し、
   前記ウェブブラウザは、前記管理手段により管理された前記機能情報の更新に応じて、取得した前記機能情報を更新することを特徴とする請求項７に記載の情報処理装置。
9. 前記ウェブブラウザは、前記管理手段から前記機能情報と前記ログインユーザの権限情報とを取得し、取得した前記機能情報を、アプリケーションの稼働状況及び前記ログインユーザの権限で実行できるか否かに応じて管理することを特徴とする請求項６に記載の情報処理装置。
10. 請求項１乃至６のいずれか一項に記載の情報処理装置としてコンピュータを機能させるためのプログラム。
11. 複数のアプリケーションが稼働できるプラットフォームを有する情報処理装置において、
    アプリケーションのインストール、起動、停止、アンインストールの要求に応じた稼働状況を取得する取得工程と、
    前記アプリケーションを用いて提供されるサービスに関する機能情報を、前記取得工程により取得された稼働状況に従い管理する管理工程と
    を有し、
    前記情報処理装置内の起動中のアプリケーションと、ウェブアプリケーションを有する外部システムとが連携することで提供されるサービスに関する機能情報は、該外部システムとのネットワークを介した通信に従い稼働中であるか否かが決定される稼働状況に従い、前記管理工程により管理され、
    前記情報処理装置で実行されるサービスの呼び出し元となるウェブブラウザによる前記機能情報を用いたサービスの呼び出しの受け付けに応じて、前記管理工程により管理されている、前記稼働状況が稼働中を示すサービスが実行されることを特徴とする情報処理方法。

Images