(57)【要約】【課題】ユーザがサービスを自由に選択できるIntentPFにおいて、マルチユーザ未対応のアプリは安全に実行できないという課題があった。【解決手段】本発明では、IntentPFにおいて、どのアプリのサービスが実行されているかを管理し、実行中アプリが提供するサービスは、Intent選択リストで通常のサービスとは異なる表示を行う。これにより、マルチユーザ未対応アプリのサービスも安全に登録でき、ユーザの利用できるサービス数が増加し、ユーザの利便性が向上する。また、Intent選択リストで実行中アプリのサービスを異なる形式で表示し、さらにこのサービスを選択するとIntentPFが生成したエラー画面を表示することで、ユーザの操作性も向上する。【選択図】図３
2015148901.tif 000002
【特許請求の範囲】
【請求項１】
サービスの呼び出しに応じてアプリケーションによるサービスを提供するためのプラットフォームを有する情報処理装置であって、
前記プラットフォームが、
外部装置からのサービスの呼び出しを受け付ける受け付け手段と、
当該サービスが前記情報処理装置の操作部からの操作に従い実行中か否かを判定する判定手段と、
前記判定手段により実行中と判定されたサービスの提供の指示に応じて、当該サービスの実行不可を示す第１の画面を提供する第１の提供手段と、
前記判定手段により実行中でないと判定されたサービスの提供の指示に応じて、当該サービスの実行を制御する制御手段と
を有することを特徴とする情報処理装置。
【請求項２】
前記プラットフォームは、呼び出されたサービスのリストを含む第２の画面を提供する第２の提供手段を更に有し、前記リストにおいては前記判定手段により実行中と判定されたサービスと実行中でないと判定されたサービスとを識別可能であり、
前記サービスの提供の指示は、前記リストから選択されたサービスに対して行われることを特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記判定手段により実行中と判定されたサービスが複数ある場合に、該複数のサービスはひとまとめにされて前記リストに含まれることを特徴とする請求項１に記載の情報処理装置。
【請求項４】
前記プラットフォームは、呼び出されたサービスのリストを含む第２の画面を提供する第２の提供手段を更に有し、前記リストにおいては前記判定手段により実行中と判定されたサービスを含み、実行中でないと判定されたサービスを含まず、
前記サービスの提供の指示は、前記リストから選択されたサービスに対して行われることを特徴とする請求項１に記載の情報処理装置。
【請求項５】
前記判定手段は、前記リストの提供している間にもサービスが実行中であるか否かを判定し、
前記第２の提供手段は、前記判定手段による判定の結果に応じて、前記リストに含まれた実行中のサービスと実行中でないサービスとを変更することを特徴とする請求項２乃至４のいずれか一項に記載の情報処理装置。
【請求項６】
前記プラットフォームは、
前記サービスごとに関連付けて、前記情報処理装置とは異なる装置でサービスが実行可能か否かを示す情報を記憶する手段と、
前記サービスの呼び出し元が、前記情報処理装置か否かを判定する第２の判定手段とを更に有し、
前記サービスの呼び出し元が前記情報処理装置ではない場合、前記情報処理装置とは異なる装置で実行可能でないサービスについては、前記リストに含めないことを特徴とする請求項２乃至４のいずれか一項に記載の情報処理装置。
【請求項７】
前記サービスを提供するためのアプリケーションを有することを特徴とする請求項１乃至６のいずれか一項に記載の情報処理装置。
【請求項８】
請求項１乃至７のいずれか一項に記載の情報処理装置としてコンピュータを機能させるためのプログラム。
【請求項９】
サービスの呼び出しに応じてアプリケーションによるサービスを提供する情報処理装置において、
外部装置からのサービスの呼び出しを受け付ける受け付け工程と、
当該サービスが前記情報処理装置の操作部からの操作に従い実行中か否かを判定する判定工程と、
前記判定工程により実行中と判定されたサービスの提供の指示に応じて、当該サービスの実行不可を示す第１の画面を提供する第１の提供工程と、
前記判定工程により実行中でないと判定されたサービスの提供の指示に応じて、当該サービスの実行を制御する制御工程と
を有することを特徴とする情報処理方法。
【請求項１０】
請求項１乃至７のいずれか一項に記載の情報処理装置をコントローラユニットして有し、スキャナ及びプリンタを更に有することを特徴とする画像形成装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理装置及び方法と画像形成装置に関し、特に画像形成装置などの情報処理装置に組み込んだアプリケーションの連携に関する技術である。
【背景技術】
【０００２】
従来から、複数のアプリケーション(以降、アプリと記載)間でデータのやり取りを行うアプリ連携機能として、Web IntentsやAndroid Intentsが広く知られている。これらの機能では、アプリの一部機能をサービスとしてあらかじめ登録しておき、別のアプリからこれらのサービスを利用するものである。より詳細には、サービスを利用するアプリが、使用したいカテゴリ（タイプともいう）を指定すると、このカテゴリとして登録されているサービス一覧が表示され、ユーザは任意のサービスを選択して実行することができる機能である。以降、このような機能をIntent機能と呼ぶ。
【０００３】
Web IntentsやAndroid Intentsにおいて、登録されているサービスは、複数ユーザが同時に同じサービスを呼び出しても正常に動作することができる(以降、このようなサービスをマルチユーザ対応のサービスと呼ぶ)。しかし、マルチユーザ未対応の機能が存在していた場合、この機能を作り変えることなくサービスとしてIntent機能で利用したい場合もある。また、マルチユーザ対応のサービスはメモリ等のリソースの使用量が多いため、画像形成装置などの組み込み機器のようにメモリ等のリソースが限られた環境では、マルチユーザ対応のサービスを提供するのが難しい場合もある。このための解決手段として、特許文献１のように、サービスが実行中であるかをサーバで管理し、実行されていないサービスを提供する技術が知られている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開2010-220016号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
特許文献1の従来技術により、実行されていないサービスのみを提供することで、マルチユーザ未対応のサービスでも安全に利用することが可能となる。しかしながら従来の技術では、利用可能なサービスを自動的に一意に決めるものであり、Intent機能のようにユーザが利用可能なサービスを自由に選択できないという課題がある。
【０００６】
なお、実行できないサービスはユーザが選択できないように非表示にすることも考えられるが、この場合はサービスが実行できない理由をユーザは知ることができないため、ユーザの操作性が低下するという課題がある。
【０００７】
そこで、本発明は、一例であるWeb Intentsに代表されるような（ウェブ）アプリケーションの連携の技術を利用しつつ、上述の課題を解決し得る仕組みを提供することを目的とする。
【課題を解決するための手段】
【０００８】
上述した課題を解決するために、本発明は、
サービスの呼び出しに応じてアプリケーションによるサービスを提供するためのプラットフォームを有する情報処理装置であって、前記プラットフォームが、
外部装置からのサービスの呼び出しを受け付ける受け付け手段と、
当該サービスが前記情報処理装置の操作部からの操作に従い実行中か否かを判定する判定手段と、
前記判定手段により実行中と判定されたサービスの提供の指示に応じて、当該サービスの実行不可を示す第１の画面を提供する第１の提供手段と、
前記判定手段により実行中でないと判定されたサービスの提供の指示に応じて、当該サービスの実行を制御する制御手段と
を有する。
【発明の効果】
【０００９】
本発明により、（ウェブ）アプリケーションの連携の技術を利用しつつ、上述の課題を解決し得る仕組みを提供できる。
【００１０】
具体的には、マルチユーザ未対応の機能を作り変えることなく、Intent機能などのサービスとしてユーザが自由に選択可能なサービスを登録することが可能になる。このため、Intent機能などのサービス数が増えて、ユーザの利便性が向上する。また、実行できないサービスについては、実行できない理由をユーザに明示的に示すことで、ユーザの操作性が向上する。
【図面の簡単な説明】
【００１１】
【図１】本発明の各実施形態に共通する画像形成装置１００のコントローラユニット１２０を表すブロック図である。
【図２】本発明の第２の実施形態における外部装置４００の操作部４０６に表示される画面の一実施形態である。
【図３】本発明の各実施形態に共通する画像形成装置１００と外部装置４００のソフトウエアモジュール構成図の一部である。
【図４】本発明の各実施形態に共通する外部装置４００のコントローラユニット４１０を表すブロック図である。
【図５】本発明の各実施形態に共通する画像形成装置１００のソフトウエアモジュールの処理フローの一部を表すフロー図である。
【図６】本発明の第１の実施形態における画像形成装置１００の内部処理を表すフローチャート図である。
【図７】本発明の第１の実施形態における画像形成装置１００の操作部１０６に表示される一連の画面を示す画面フロー図である。
【図８】本発明の第１の実施形態における画像形成装置１００のHDD１０４に記憶されている制御プログラムの一部である。
【図９】本発明の第１の実施形態における画像形成装置１００のHDD１０４に関連付けて記憶されている情報のイメージ図である。
【図１０】本発明の第１の実施形態における画像形成装置１００のHDD１０４に関連付けて記憶されている情報のイメージ図である。
【図１１】本発明の第１の実施形態における画像形成装置１００のHDD１０４に関連付けて記憶されている情報のイメージ図である。
【図１２】本発明の第１の実施形態における画像形成装置１００のHDD１０４に関連付けて記憶されている情報のイメージ図である。
【図１３】本発明の第１の実施形態における外部装置４００の操作部４０６に表示される一連の画面を示す画面フロー図である。
【図１４】本発明の第１の実施形態における画像形成装置１００の操作部１０６に表示される画面の一実施形態である。
【図１５】本発明の第１の実施形態における画像形成装置１００の操作部１０６に表示される画面の一実施形態である。
【図１６】本発明の第２の実施形態における画像形成装置１００の内部処理を表すフローチャート図である。
【図１７】本発明の第２の実施形態における画像形成装置１００のHDD１０４に関連付けて記憶されている情報のイメージ図である。
【発明を実施するための形態】
【００１２】
以下、本発明を実施するための最良の形態について、図面を用いて説明する。
【００１３】
なお、本実施例においては、（ウェブ）アプリケーションの連携の技術として、Web Intentsを利用した場合の説明を行っている。しかしながら、同様な中継機能を介したクライアントとサービスを連携するための他の仕組みを利用してもよい。例えば、Web Activitiesと呼ばれる技術を利用してもよいし、同様の独自仕様を用いて本発明を実現することが可能である。
【００１４】
［第１の実施形態］
最初に、画像形成装置のコントローラユニットの説明を行う。
＜画像形成装置のコントローラユニットの構成＞
図1は、本発明の各実施形態に係る画像形成装置１００のコントローラユニットの内部構造を示すブロック図である。コントローラユニット１２０は、画像情報やデバイス情報の入出力を行うだけではなく、装置全体の制御や、ネットワークを介して外部から提供されるデータをプリント出力する制御を行う。また、ネットワークを介した電子メール送信機能を含む通信機能における制御も行う。コントローラユニット１２０は、各種制御プログラムを実行するCPU１０１を有する。
【００１５】
CPU１０１は、ROM１０３に格納されているブートプログラムに基づきシステムを起動し、このシステム上でHDD(ハードディスク装置)１０４に格納されている制御プログラムを読み出してRAM１０２をワークエリアとして制御プログラムに従って処理を実行する。この制御プログラムにより、HTMLなどのタグ情報を解析し、所定の制御を実行することが可能である。HDD１０４には、上記各種制御プログラムが格納されるとともに、画像データや後述するネットワーク部１０７が有するすべての通信手段に関する情報を格納する。CPU１０１には、RAM１０２、ROM１０３、HDD１０４がシステムバス１１０を介して接続されている。さらに操作部I/F１０５、ネットワーク部１０７、イメージバスI/F１０９、電源管理部１１０がシステムバス１１１を介して接続されている。
【００１６】
操作部I/F１０５は、操作部１０６との間のインターフェイス部であり、操作部１０６に表示する画像データの操作部１０６への転送、操作部１０６における操作入力により発生した信号のCPU１０１への転送などを行う。操作部１０６は、画像処理に関する各機能における現在の設定状態、各機能に関する設定情報を入力するための情報入力画面などを表示するための表示部、ユーザが各機能に対する設定情報を入力するキーなどを含む入力部を有する。
【００１７】
電源管理部１１０は、画像形成装置１００の電源OFFと電源ONの管理を行う。なお電源ONを検知した場合、上述のように、CPU１０１は、ROM１０３のブートプログラムに基づきシステムを起動し、このシステム上でHDD１０４に格納されている制御プログラムを実行する。
【００１８】
ネットワーク部１０７は、LAN１０８に接続され、LAN１０８を介した情報の入出力を行う。LAN回線に不図示のwebサーバや外部装置が接続されている場合は、そのサーバや外部装置からLAN１０８を介して情報を取得することが可能である。また、LAN回線内のプロキシサーバなどを介して、インターネットに接続し、インターネット上のwebサーバからwebコンテンツを取得することも可能である。
【００１９】
イメージバスI/F１０９は、システムバス１１１と画像バス１１２とを接続し、データ構造を変換するバスブリッジである。画像バス１１２は、画像データを高速で転送可能なPCIバスまたはIEEE１３９４規定に従うバスから構成される。画像バス１１２には、RIP(ラスタイメージプロセッサ)１１３、デバイスI/F１１４および画像処理部１１９が接続されている。
【００２０】
RIP１１３は、PDLコードをビットマップイメージに展開する。デバイスI/F１１４は、画像入出力デバイスであるスキャナ１１６やプリンタ１１８とコントローラユニット１２０とを接続し、画像データの同期系／非同期系の変換を行う。ここでは、デバイスI/F１１４とスキャナ１１６とがケーブル１１５を介して、デバイスI/F１１４とプリンタ１１８とがケーブル１１７を介してそれぞれ接続されている。
【００２１】
画像処理部１１９は、多値画像データに対して、またJPEG、二値画像データに対して、JBEG,MMR,MHなどの圧縮伸張処理を行う。また、入力画像データや出力画面に対して、プリンタの補正や解像度変換などの補正、加工、編集を行う。
【００２２】
このように、コントローラユニット１２０のCPU１０１は、各制御プログラムに基づき、システムバス１１１に接続される各種デバイスとのアクセスを総括的に制御するととともに、デバイスI/F１１４を介してスキャナ１１６から画像情報を読み込む。また、読み込んだ画像情報に対して所定の処理を施した後に該画像情報をデバイスI/F１１４を介してプリンタ１１８に出力するなどの制御を行う。さらに、ネットワーク部１０７を通じて取得したHTMLデータや画像データの解析・変換処理を行い、HDD１０４へ保存、あるいは操作部１０６での表示制御を行う。次に、画像形成装置１００と通信可能な外部装置のコントローラユニットの説明を行う。
【００２３】
＜外部装置のコントローラユニットの構成＞
図４は、本発明の各実施形態にかかる外部装置４００のコントローラユニットの内部構造を表すブロック図である。外部装置４００は、画像処理装置１００とLAN１０８を介して接続される例えばコンピュータである。図４において、コントローラユニット４１０は、画像形成装置１００と通信を行うための制御や、Webアプリを動作させるための制御や、装置全体の制御を行う。コントローラユニット４１０は、各種制御プログラムを実行するCPU４０１を有する。CPU４０１は、ROM４０３に格納されているブートプログラムに基づきシステムを起動し、このシステム上でHDD４０４に格納されている制御プログラムを読み出してRAM４０２をワークエリアとして所定の処理を実行する。HDD４０４には、上記各種制御プログラムが格納されるとともに、後述するネットワーク部４０７が有するすべての通信手段に関する情報を格納する。CPU４０１には、RAM４０２、ROM４０３、HDD４０４がシステムバス４１０を介して接続されている。さらに操作部I/F４０５、ネットワーク部４０７、電源管理部４０９がシステムバス４１０を介して接続されている。操作部I/F４０５は、操作部４０６との間のインターフェイス部であり、画像形成装置１００の操作部I/F１０５と同じ機能を実現する。電源管理部４０９は、外部装置４００の電源OFFと電源ONの管理を行い、画像形成装置１００の電源管理部１１０と同じ機能を実現する。ネットワーク部４０７は、LAN４０８に接続され、LAN４０８を介した情報の入出力を行う。LAN回線にwebサーバや画像形成装置１００が接続されている場合は、そのサーバや画像形成装置１００からLAN４０８を介して情報を取得することが可能である。
【００２４】
続いて、画像形成装置１００のHDD１０４の制御プログラムをCPU１０１が実行することで実現するIntentPlatformのモジュール構成を説明する。なおこのIntentPlatformの各モジュールは、全てCPU１０１がHDD１０４の制御プログラムを実行することで動作し、プログラム実行時に必要な情報は全てHDD１０４に記憶されていることとする。また、HDD１０４の制御プログラムを実行することにより生成された情報は、全てHDD１０４に記憶することとする。このような処理は、以降の説明でも全て共通であり、記載は省略する。
【００２５】
［Intentプラットフォームの説明］
＜Intent  Platformの説明＞
図３はIntent機能を実現するモジュール構成を表す図である。図３は、Intent Platform(以降、IntentPF)３００、IntentPF３００にサービスを提供するサービス提供アプリ、IntentPF３００のサービスを利用するサービス利用アプリからなる。図３では、サービス提供アプリの一例としてScanToSendアプリ３１０を、サービス利用アプリの一例としてMFPAppアプリ３２０とPCAppアプリ３３０とを示した。IntentPF３００とScanToSendアプリ３１０とMFPAappアプリ３２０は画像形成装置１００で動作し、PCAppアプリ３３０は外部装置４００で動作している。
【００２６】
PCAappアプリ３３０はネットワーク部４０７によりLAN４０８を経由して、画像形成装置１００のIntentPF３００と情報のやり取りが可能である。また同様に、IntentPF３００は、ネットワーク部１０７によりLAN１０８を経由して、外部装置４００のPCAppアプリ３３０と情報のやり取りが可能である。なお画像形成装置１００と外部装置４００で動作するアプリは全てWebベースのアプリであり、CPUでHTMLデータを解釈してHDDの画面リソースを利用してレンダリングすることで、操作部にユーザが操作可能な画面を表示することが可能である。このようなWebベースアプリの画面表示方法や画面遷移方法は一般的な方法と同じであるため、以降では説明を省略する。また、図３では、１つのサービス提供アプリと２つのサービス利用アプリしか記載していないが、それぞれ複数存在しても良い。
【００２７】
IntentPF３００の説明として、最初にサービスを登録するモジュールであるサービス登録部３０１の説明を行い、その後に登録したサービスを利用するためのモジュール３０２〜３０６の説明を行う。説明ではモジュール間の処理フローをフロー図５を用いて説明するが、各モジュールの具体例を用いた処理については後述のフローチャート図６で説明する。
【００２８】
□サービス登録部３０１
サービス登録部３０１は、Intent機能で利用可能なサービスを登録するためのモジュールである。Intent機能で利用可能なサービスは、画像形成装置１００起動時にサービス提供アプリから送信されたIntent登録情報を、このサービス登録部３０１で受信することで登録する（フロー５０１）。Intent登録情報は、アクション（サービスのカテゴリ）、サービス提供アプリのアプリ名称、実際に表示するサービスの名称(タイトル)、サービスポインタ、実行中フラグを含む。サービスポインタとは、サービス実行時にIntentPF３００が呼び出すサービス提供アプリのポインタ(アドレス)である。実行中フラグとは、サービスが実行中であるかを表すフラグで、０が未実行、１が実行中である。サービス登録部３０１は、これらの情報をお互いに関連付けてHDD１０４に保存する。なお、Intent機能で利用なサービスの登録タイミングは、画像形成装置１００起動時ではなく、別のタイミングでも良い。また、サービス提供アプリからのIntent登録情報の登録は、Intent登録情報をまとめて記載したファイルをサービス登録部３０１に送信する方法でも良いし、サービス登録部３０１が用意したAPIをサービス提供アプリがコールする方法でもよい。
【００２９】
□Intent呼出受信部３０２
Intent呼出受信部３０２は、Intent機能のサービスを利用するための呼出し(以降、Intent呼出し)をサービス利用アプリから受信する（あるいは受け付ける）ためのモジュールである。Intent呼出受信部３０２は、Intent呼出受信時に、サービス利用アプリからIntent呼出情報を受信する(フロー５０２)。このIntent呼出情報は、サービス利用アプリ名、利用したいサービスのカテゴリ、サービス利用後に実行するサービス利用アプリのポインタ（以降、呼出元コールバック）を含む。Intent呼出受信部３０２は、Intent呼出しを受信すると、Intent呼出情報をHDD１０４に記憶し、後述の実行中アプリ判定部３０３に実行中アプリ確認要求を送信する(フロー５０３)。実行中アプリの確認が完了すると、実行中アプリ判定部３０３からの確認結果が送信されるので、Intent呼出受信部３０２はこれを受信し(フロー５０８)、後述のサービス選択画面表示部３０５に表示要求を行う(フロー５０９)。サービス選択画面表示部３０５でユーザが選択したサービスの実行が完了すると、後述のサービス実行部３０６から実行結果が送信されるので、Intent呼出受信部３０２はこれを受信する(フロー５１５)。そしてIntent呼出受信部３０２は、Intent登録情報から実行したサービスに対応する呼出元コールバックを特定し、この呼出元コールバックに実行結果を送信する（フロー５１６）。なお、フロー５０９で送信する表示要求には、後述するサービス選択リストの表示要求と、リストすべきサービスのカテゴリを含む。さらに、実行中アプリ判定部３０３からフロー５０８で受信した確認結果により、呼び出されたサービスを提供するアプリの中に実行中アプリがあると判定された場合には、エラー画面生成部３０４で生成したエラー画面へのポインタを含む。受信した確認結果が、実行中アプリがないことを示す場合には、後述するサービス選択リストの表示要求のみが送信される。
【００３０】
□実行中アプリ判定部３０３
実行中アプリ判定部３０３は、IntentPF３００で実行されているサービスを特定し、このサービスを提供しているアプリを特定するためのモジュールである。実行中アプリ判定部３０３は、前述のIntent呼出受信部３０２からの実行中アプリ確認要求を受信すると(フロー５０３)、実行中のサービスを特定する。どのサービスが実行されているかは、後述のサービス実行部３０６で実行中のサービスを、実行中サービス確認メッセージを送信し、その確認応答を受信することで特定することができる（フロー５０４、フロー５０５）。そして、実行中アプリ判定部３０３は、Intent登録情報から実行中のサービスを提供しているアプリを特定する。なお以降では、このように実行中のサービスを提供しているアプリを、実行中アプリと呼ぶ。実行中アプリ判定部３０３は、実行中のサービスが存在する場合、後述のエラー画面生成部３０４に、このサービスに対するエラー画面の生成要求を送信する(フロー５０６)。エラー画面の生成が完了すると、エラー画面生成部３０４から生成完了が送信されるので、実行中アプリ判定部３０３で前記送信情報を受信し（フロー５０７）、Intent呼出受信部３０２に実行中アプリがあるかどうかの確認結果を送信する(フロー５０８)。
【００３１】
□エラー画面生成部３０４
エラー画面生成部３０４は、後述のサービス選択画面表示部３０５で実行中アプリが提供するサービスが選択されたときに表示する画面を生成するためのモジュールである。エラー画面生成部３０４は、前述の実行中アプリ判定部３０３から実行中サービスに対するエラー画面生成要求を受信すると、操作部１０６に表示する画面の内容を決めて、画面(HTMLデータ)を生成する。そして、エラー画面生成完了後、エラー画面生成部３０４は実行中アプリ判定部３０３に生成完了を、エラー画面へのポインタとともに送信する(フロー５０７)。なお、エラー画面生成部３０４が生成する画面には、サービスが実行できない理由だけではなく、Intent呼出を中止するか継続するかをユーザが指示するための内容も表示する。
【００３２】
□サービス選択画面表示部３０５
サービス選択画面表示部３０５は、Intent呼出受信部３０２で受信したカテゴリに対応するサービスを、ユーザが選択可能な形式で操作部１０６に一覧表示するためのモジュールである。サービス選択画面表示部３０５は、Intent呼出受信部３０２からサービス選択リストの表示要求を受信すると(フロー５０９)、受信した表示要求に係るサービスのカテゴリを特定する。そしてサービス選択画面表示部３０５は、サービス登録部３０１で登録したIntent登録情報の中からこのカテゴリに関連付けられたタイトルとサービスポインタとをサービス登録部３０１に要求し、それに対する応答を受信することで特定する（フロー５１０、フロー５１１）。そしてサービス選択画面表示部３０５は、特定したタイトルをリスト形式で操作部１０６に一覧表示する(このリストをサービス選択リストと呼ぶ)。
【００３３】
なおサービス選択画面表示部３０５は、サービスリスト選択表示前に、サービス選択リストに表示するタイトルと、このタイトルのサービスをユーザが選択したときに呼び出すサービスポインタのリンク付けも行う。具体的には、前述の実行中アプリ判定部３０３により実行中ではないと特定したアプリが提供するサービスのタイトルには、このタイトルに対応するサービスポインタをリンク付ける。一方、前述の実行中アプリ判定部３０３により実行中と特定したアプリが提供するサービスのタイトルには、前述のエラー画面生成部３０４で生成した画面へのポインタをリンク付ける。そして、サービス選択画面表示部３０５は、実行中アプリが提供するサービスと実行中ではないアプリのサービスを異なる形式で、サービス選択リストに表示する。これは、実行中アプリのサービスと実行中ではないアプリのサービスで、サービス選択リストのタイトル選択時の実行動作が異なることをユーザに明示するためである。
【００３４】
サービス選択画面表示部３０５は、ユーザによりサービス選択リスト中のタイトルが選択されたことを検知すると、選択されたタイトルにリンク付けられたポインタの実行要求を後述のサービス実行部３０６に送信する(フロー５１２)。
【００３５】
一方フロー５０９で受信した表示要求にエラー画面へのポインタが含まれる場合には、サービス実行部３０６に対してエラー画面のポインタを引き渡す。サービス実行部３０６から再実行の指示を受信した場合には、フロー５１０から再実行する。
【００３６】
□サービス実行部３０６
サービス実行部３０６は、ユーザが選択したサービスを実行するためのモジュールである。サービス実行部３０６は、前述のサービス選択画面表示部３０５からのポインタ実行要求を受信すると(フロー５１２)、このポインタがサービスを呼び出すためのサービスポインタであるかエラー画面へのポインタであるかによって異なる処理を行う。サービスを呼び出すためのサービスポインタの場合、サービス実行部３０６は、このサービスポインタの実行要求をサービス提供アプリのサービス提供部３１１に送信する（フロー５１３）。さらに、サービス実行部３０６は、このサービスのIntent登録情報における実行中フラグを１にすることで、このサービスの実行状態を実行中に変更する。そして、サービスの実行完了後、サービス提供アプリのサービス提供部３１１から実行結果が送信されると、サービス実行部３０６はこの実行結果を受信する（フロー５１４）。そして、サービス実行部３０６は、Intent呼出受信部３０２に実行結果を送信する（フロー５１５）と共に、Intent登録情報の実行中フラグを０にすることで、このサービスの実行状態を未実行に変更する。
【００３７】
一方、ポインタがエラー画面生成部３０４で生成した画面へのポインタの場合、サービス実行部３０６はこのポインタを呼び出して、操作部１０６にエラー画面生成部３０４で生成したエラー画面を表示する。そして、この画面でユーザがIntent機能の中止を選択したことを検知した場合、サービス実行部３０６は、ユーザが選択したサービスに対応する呼出元コールバックをIntent登録情報から特定し、この呼出元コールバックに実行結果(失敗)を送信する。また、エラー画面生成部３０４で生成されたエラー画面でユーザがIntent機能の継続(再実行)を選択した場合、サービス実行部３０６は、再度サービス選択画面表示部３０５にサービス選択リストを表示するための処理を要求する。そのため、実行中アプリが提供するサービスが終了してからユーザがIntent機能の再実行を選択すれば、サービス選択リストからサービスの実行が可能となる。
以上が、IntentPF３００のモジュールの説明である。なお実行中アプリが提供するサービスが終了したことはサービス実行部３０６自身により判定できる。
【００３８】
＜操作部４０６への表示方法＞
なお、各モジュールの説明では、ユーザに表示する画面は画像形成装置１００の操作部１０６に表示されるとしているが、表示する画面は全てHTML形式のデータであり、外部装置４００の操作部４０６で表示することも可能である。これを実現する方法の一例を説明する。画像形成装置１００と外部装置４００のIntent呼出は、SOAP形式で行うこととする。Intent呼出受信部３０２は、サービス利用アプリからのIntent呼出を含むSOAPメッセージをネットワーク部１０７経由で受信する。そしてIntent呼出受信部３０２は、受信したメッセージのプロトコルバインディングヘッダの"Host"等からSOAPメッセージの返信先を特定する。その後、サービス選択画面表示部３０５は、操作部に表示するサービス選択リストの画面データ（HTMLデータ）を作成後、このIntent呼出が外部装置４００からの実行されているかを判定する。外部装置４００からの実行の場合、サービス選択画面表示部３０５は、作成した画面データを操作部１０６で表示するのではなく、外部装置４００に送るようにIntent呼出受信部３０２に依頼する。これによりIntent呼出受信部３０２は、Intent呼出受信時に特定したSOAPメッセージの返信先に、この画面データの表示要求をSOAPメッセージで送信する。そして、このSOAPメッセージをネットワーク部４０８経由で受信した外部装置４００は、受信したHTMLデータをCPU４０１で解析とレンダリングを行い、操作部４０６に表示する。このような方法により、操作部４０６に画像形成装置１００で生成した画面を表示することもできる。
続いて、IntentPF３００と連携するアプリケーション(アプリ)のモジュールの説明を図３を用いて行う。
【００３９】
＜サービス提供アプリの説明＞
ScanToSendアプリ３１０はサービス提供アプリのひとつであり、サービス提供部３１１と、サービス実行部３１２と、UI制御部３１３などのモジュールを含む。サービス提供部３１１は、Intent機能にサービスを提供するためのモジュールである。サービス提供部３１１は、アプリ起動時に、Intent登録情報をIntentPF３００のサービス登録部３０１に送信することで、提供するサービスの登録を行う（フロー５０１）。また、サービス提供部３１１は、IntentPF３００のサービス実行部３０６からのサービスポインタの実行要求を受信すると（フロー５１３）、サービス実行部３１２やUI制御部３１３のモジュールにより、このサービスを実行する。そして、サービス提供部３１１は、このサービス実行後に、実行結果をIntentPF３００のサービス実行部３０６に送信する（フロー５１４）。
【００４０】
＜サービス利用アプリの説明＞
MFPAppアプリ３２０はサービス利用アプリであり、Intent呼出部３２１と、設定制御部３２２と、UI制御部３２３などのモジュールとを含む。Intent呼出部３２１は、Intent機能を呼び出すことでサービスを利用するためのモジュールである。Intent呼出部３２１は、Intent機能の呼出しを受信すると、IntentPF３００のIntent呼出受信部３０２に、Intent呼出しと共にIntent呼出情報を送信する（フロー５０２）。そして、Intent呼出しが完了すると、IntentPF３００のIntent呼出受信部３０２から送信される実行結果を受信する（フロー５１６）。なおPCAppアプリ３３０は、MFPAppアプリ３２０と同じモジュール構成であるため、説明は省略する。
以上が、IntentPF３００まわりのソフトウエアモジュール構成の説明である。
【００４１】
［具体例の説明］
続いて、これらのモジュールを用いてIntent呼出しを行う具体例を、フローチャート図６と、操作部１０６に表示される画面フロー図７を用いて説明する。なおここでは、画像形成装置１００のIPアドレスは、"172.24.10.10"とし、外部装置４００のIPアドレスを"172.24.10.20"とする。
【００４２】
＜本実施形における画像形成装置１００の内部処理＞
サービス提供アプリとして、ScanToSendアプリ３１０とAAAアプリとBBBアプリが画像形成装置１００で起動していることとする。そして、これらのアプリが起動時にIntentPF３００のサービス登録部３０１にIntent登録情報を送信することで、図９のIntent登録情報が登録されていることとする。また、サービス利用アプリとして、MFPAppアプリ３２０が画像形成装置１００で起動し、PCAppアプリ３３０が外部装置４００で起動していることとする。
【００４３】
□サービス利用アプリ(MFPAppアプリ３２０)の内部処理
画像形成装置１００の操作部１０６において、ユーザがサービス利用アプリであるMFPAppアプリ３２０の起動を指示すると、UI制御部３２３と設定制御部３２２により、操作部１０６に図７の画面７００を表示する。画面７００は、ユーザが希望する動作を選択するための画面で、この画面には３つの動作を表す３つのボタンが表示されている。この３つのボタンは、文書の送信ボタン７０１、文書のコピーボタン７０２、設定変更ボタン７０３である。ここではユーザが文書の送信を行うため、文書の送信ボタン７０１を押下したこととする。
【００４４】
MFPAppアプリ３２０のUI制御部３２３は、ユーザによる文書の送信ボタン７０１の押下を検知すると、操作部１０６に図７の画面７１０を表示する。画面７１０は、文書を送信する宛先を入力する画面であり、Intent機能を利用して宛先を入力するための宛先ボタン７１１と、宛先ボタン７１１で入力した宛先を表示する宛先表示エリア５１２が表示されている。宛先ボタン７１１はIntent機能の呼出し(Intent呼出し：フロー５０２)を行うボタンであり、このボタンにはIntent呼出情報が関連付けられて記憶されている。具体的には、この宛先ボタン７１１に、カテゴリは"address"、呼出元コールバックは"http://172.24.10.10/MFPApp_address_call.html"、アプリ名称は"MFPApp"が関連付けられている。
【００４５】
ユーザが宛先ボタン７１１を押下すると、MFPAppアプリ３２０のIntent呼出部３２１は、押下された宛先ボタン７１１に関連付けて記憶されているIntent呼出情報をIntent呼出しとしてIntentPF３００に送信する。IntentPF３００へのIntent呼出し要求方法としては様々な方法があるが、ここでは図８のようなソースコードによりIntent呼出し要求を行う。
【００４６】
□IntentPF３００の内部処理(実行中サービスがないとき)
Intent呼出しを受信してからサービス提供アプリにサービスの実行要求を行うまでのIntentPF３００の処理を、フローチャート図６を用いて説明する。Intent呼出受信部３０２は、サービス利用アプリからのIntent呼出しを受信するまで待機する(ステップ６０１)。そして、Intent呼出受信部３０２は、サービス利用アプリからのIntent呼出しを受信すると、このIntent呼出情報をHDD１０４に記憶する。ここでは前述のMFPAppアプリ３２０からのIntent呼出情報を受信するため、図１１のように記憶する。その後Intent呼出受信部３０２は、実行中アプリ判定部３０３に実行中アプリの確認要求を送る。実行中アプリ判定部３０３は、この実行中アプリの確認要求を受信すると、サービス実行部３０６を利用することでIntentPF３００のサービスを実行しているアプリ(実行中アプリ)が存在するかどうかを確認する（ステップ６０２）。ここでは、図９のIntent登録情報であるため、実行中フラグが全て０で実行中サービスは存在せず、実行中アプリも存在しないと判断する。そのため、実行中アプリ判定部３０３は、Intent呼出受信部３０２に実行中アプリは存在しないという結果を送信する。
【００４７】
Intent呼出受信部３０２は、実行中アプリ判定部３０３からの実行中アプリの確認結果を受信すると、Intent呼出しにより実行するサービスのカテゴリを特定する(ステップ６０４)。Intent呼出しには前述したように利用したいサービスのカテゴリが含まれている。そして、このカテゴリに対応するサービスがIntent登録情報に存在するかどうかを確認する(ステップ６０５)。この確認により、対応するサービスが存在しない場合、Intent呼出しを行うことができないため、Intent呼出受信部３０２は、Intent呼出部３２１に呼出失敗を送信し、このフローを終了する。ここでは、Intent呼出のカテゴリが"address"であり、図９のIntent登録情報から対応するサービスが３つ存在すると判断する。
【００４８】
対応するサービスが存在する場合（ステップ６０５がYESの場合）、Intent呼出受信部３０２は、特定したカテゴリのサービス選択リスト表示要求をサービス選択画面表示部３０５に行う。サービス選択画面表示部３０５は、Intent登録情報から特定したカテゴリに対応するタイトルとサービスポインタを特定する(ステップ６０６)。その後、サービス選択画面表示部３０５は、特定したカテゴリに対応するサービスの中で、実行中アプリが提供しているサービスがあるかどうかを判定する(ステップ６０７)。この判定は、実行中アプリ判定部３０３で特定した実行中アプリのアプリ名称を特定し、Intent登録情報の特定したカテゴリの中で、このアプリ名称が提供しているサービスが存在するかどうかを調べることで行う。ここでは、実行中アプリが存在しないため、実行中アプリが提供するサービスも存在しない（ステップ６０７がNO）。この後、サービス選択画面表示部３０５は、操作部１０６にサービス選択リストを表示する(ステップ６０９)。ここではカテゴリが"address"のIntent呼出しを行っているため、図７の画面７２０のように、サービス選択リスト７２１を表示する。なお、このサービス選択リスト７２１は、電子メールボタン７２２、FAXボタン７２３、AAAボタン７２４からなり、HTML形式のデータである。
【００４９】
サービス実行部３０６は、サービス選択リストにおいてユーザがサービスを選択したことを検知すると(ステップ６１０がYES)、選択したサービスの実行フラグをIntent登録情報から特定し、この実行フラグを（実行中）に変更する。その後、サービス実行部３０６は、このサービスポインタの実行をサービス提供部３１１に送信することでサービスポインタで特定されるアプリケーションを実行し、選択したサービスを実行する(ステップ６１１)。ここでは、ユーザがサービス選択リスト５７１で電子メールボタン７２２を選択したとする。この場合、図１０のように、電子メールというタイトルの実行中フラグが１になる。そして、サービスポインタである"http://localhost/intent_email.html"の実行要求を、サービス提供アプリであるScanToSendアプリ３１０のサービス提供部３１１に送信する。以上が、フローチャート図６を用いたIntent呼出しによるサービスを実行要求処理の説明である。
【００５０】
なおステップ６０９で表示すべきリストに含まれるサービスがただ一つの場合にはサービス選択リストを表示せずに、当該サービスが選択されたものとしてステップ６１１を実行してもよい。
【００５１】
□サービス提供アプリ(ScanToSendアプリ３１０)の内部処理
ScanToSendアプリ３１０のサービス提供部３１１は、サービスポインタの実行を受信すると、サービス実行部３１２やUI制御部３１３により図７の画面７３０を操作部１０６に表示する。図７の画面７３０は、ユーザが宛先アドレスを選択する画面であり、ここではaaa@xxx.co.jpボタン７３１とbbb@xxx.co.jpボタン７３２とccc@xxx.co.jpボタン７３３の３つが表示される。このボタン７３１〜ボタン７３３のどれかがユーザが押下すると、サービス実行部３１２はサービスの実行が完了したと判断し、押下したボタンに対応する宛先アドレスを実行結果としてIntentPF３００のサービス実行部３０６に送信する。
【００５２】
□サービス選択後の内部処理
サービス実行部３０６は、この実行結果を受信すると、実行したサービスの実行中フラグを０に変更し、実行結果をIntent呼出受信部３０２に送信する。その後、Intent呼出受信部３０２は、この結果をIntent呼出しを行ったサービス利用アプリのIntent呼出部３２１に送信する。なおここでは、図７の画面７３０において、ユーザがaaa@xxx.co.jpボタン７３１を選択する。これにより、実行結果としてこのボタン７３１に関連付けれた"aaa@xxx.co.jp"という宛先アドレスがIntentPF３００のIntent呼出受信部３０２を経由してサービス利用アプリであるMFPAppアプリ３２０に送信される。MFPAppアプリ３２０は、この実行結果をIntent呼出部３２１で受信し、ntent呼出の実行結果として宛先アドレスが送信されると実行成功とみなし、設定制御部３２２やUI制御部３２３を用いて画面７４０の宛先表示エリア７１２に表示する。一方、Intent呼出の実行結果として宛先アドレス以外のものが送信されると、MFPAppアプリ３２０は、実行失敗とみなし、実行失敗の場合は宛先表示エリア５１２には何も表示しない。ここでは実行結果として"aaa@xxx.co.jp"という宛先アドレスが送信されるため、この宛先アドレスを画面７４０の宛先表示エリア５１２に表示する。
以上が、Intent呼出し時の基本的な内部処理である。
【００５３】
［サービス実行中の別アプリによるIntent呼出し］
続いて、Intent呼出し中に、別のアプリから同じサービスを指定するIntent呼出が行われたときの具体例を、操作部４０６に表示される画面フロー図１３を用いて説明する。
【００５４】
画像形成装置１００のMFPAppアプリ３２０により電子メールというタイトルのサービス(ScanToSendアプリ３１０が提供するサービス)が実行中であり、操作部１０６に図７の画面７３０が表示されているとする。このとき、PCやモバイル端末などの外部装置４００のPCAppアプリ３３０から電子メールというタイトルのサービスを利用するIntent呼出しを行うこととする。
【００５５】
□サービス利用アプリ(PCAppアプリ３３０)の内部処理
外部装置４００の操作部４０６において、ユーザがサービス利用アプリであるPCAppアプリ３３０の起動を指示すると、UI制御部３３３と設定制御部３３２により、操作部４０６に図１３の画面１３００を表示する。ここでユーザが文書の送信ボタン１３０１を押下すると、UI制御部３３３と設定制御部３３２は、操作部４０６に画面１３１０を表示する。ここでユーザが宛先ボタン１３１１を押下すると、Intent呼出部３３１はこのボタンに対応するIntent呼出しを画像形成装置１００のIntentPF３００に送信する。画面１３００と画面１３１０での内部処理は画像形成装置１００のMFPAppアプリ３２０における画面７００と画面７１０と同じであるため、詳細は省略する。
【００５６】
□Intentプラットフォーム（IntentPF３００）による内部処理
Intent呼出受信部３２０は、PCAppアプリ３３０のIntent呼出部３３１からのIntent呼出を受信すると(ステップ６０１がYES)、Intent呼出情報をHDD104に記憶する。ここでは、PCAppアプリ３３０のアプリ名称は"PCApp"であり、Intent呼出しのカテゴリは"address"である。また、PCAppアプリ３３０のIntent呼出し後に実行するPCAppアプリ３３０の呼出元コールバックは、"http://172.24.10.20/PCApp_address_call.html"である。そのため、Intent呼出情報は図１２となる。その後Intent呼出受信部３２０は、実行中アプリ判定部３０３に実行中アプリの確認要求を送る。実行中アプリ判定部３０３は、この実行中アプリの確認要求を受信すると、サービス実行部３０６を利用することで実行中アプリが存在するかどうかを確認する（ステップ６０２）。ここでは、図１１のようにタイトルが電子メールのサービスが１（実行中）になっている。そのため、実行中アプリ判定部３０３は、実行中アプリに対するエラー画面生成要求をエラー画面生成部３０４に送信する。エラー画面生成部３０４は、エラー画面生成要求を受信すると、図１３の画面１３３０を生成する（ステップ６０３）。この生成したエラー画面１３３０は "http://172.24.10.10/intentPF_error_1.html"というHTML形式のデータであり、内容は後述する。エラー画面生成部３０４は、エラー画面の生成が完了すると、実行中アプリ判定部３０３に生成完了を送信し、これを受信した実行中アプリ判定部３０３は実行中アプリが存在するという確認結果を、実行中のアプリの例えばサービスのタイトルやサービスポインタとともにIntent呼出受信部３０２に送信する。
【００５７】
Intent呼出受信部３０２は、実行中アプリが存在するという確認結果を受信すると、ステップ６０１で受信したサービスのカテゴリを特定する(ステップ６０４)。そして、Intent呼出受信部３０２は、このカテゴリに対応するサービスがIntent登録情報に存在するかどうかを確認する(ステップ６０５)。ここでは"address"というカテゴリには図１０のように３つのサービスが存在すると判断する（ステップ６０５はYES）。
【００５８】
対応するサービスが存在する場合、Intent呼出受信部３０２は、サービス選択画面表示部３０５に特定したカテゴリのサービス選択リスト表示要求を行う。サービス選択画面表示部３０５は、Intent登録情報から対応するサービスのタイトルとサービスポインタを特定し、リンク付けを行う（ステップ６０６）。そして、サービス選択画面表示部３０５は、特定したカテゴリに対応するサービスの中で、実行中アプリが提供しているサービスがあるかどうかを判定する(ステップ６０７)。ここでは、タイトルが電子メールというサービスが実行中であり、このサービスを提供しているアプリがScanToSendアプリ３１０であると判断する。そのため、サービス選択画面表示部３０５は、実行中アプリであるScanToSendアプリ３１０が提供するタイトルが電子メールとFAXのサービスは実行中アプリが提供しているサービスであると判断する（ステップ６０７はYES）。
【００５９】
要求されたサービスのうちに実行中アプリが提供しているサービスが存在する場合、サービス選択画面表示部３０５は、このサービスのタイトルにリンク付けるサービスポインタを、ステップ６０３で生成したエラー画面へのポインタに一時的に変更する(ステップ６０８)。その後、サービス選択画面表示部３０５は、実行中アプリが提供しているサービスとそれ以外のサービスで異なる形式でサービス選択リストに表示するHTMLデータを生成し、表示要求を行う。これにより外部装置４００の操作部４０６に、図１３の画面１３２０が表示される(ステップ６０９)。ここで画面１３２０の説明を行う。
【００６０】
画面１３２０には、サービス選択リスト１３２１を表示している。このサービス選択リスト１３２１は、電子メールボタン１３２２、FAXボタン１３２３、AAAボタン１３２４からなる。ただし、電子メールボタン１３２２とFAXボタン１３２３は、実行中アプリが提供しているサービスのため、サービス選択リスト１３２１では異なる形式で表示する。ここでは、サービス選択リスト７２１の電子メールボタン１３２２とFAXボタン１３２３は、ボタン上に表示する文字のフォントを斜体にし、ボタンの色を変更して表示している。すなわち、実行中でなく選択が許されるアプリと、実行中であるために選択が許されないアプリとを識別可能にリスト表示する。以上が、画面１３２０の説明である。
【００６１】
ここでユーザが電子メールボタン１３２２を押下すると(ステップ６１０がYES)、この電子メールボタン１３２２に対応づけられたサービスポインタの実行を行い(ステップ６１１)、エラー画面１３３０を操作部７０６に表示する。ここで、この画面１３３０の説明を行う。
【００６２】
エラー画面１３３０は、エラーメッセージ領域１３３１、中止ボタン１３３２、再実行ボタン１３３３を含む。エラーメッセージ領域１３３１は、ユーザが選択したサービスが実行できない理由を明示する画面であり、ここでは"選択したサービスは別アプリで実行中..."という理由を示すメッセージを表示している。中止ボタン１３３２は、このサービスの利用を中止し、Intent利用アプリに実行失敗を返すためのボタンである。ここで中止ボタン１３３２を押下すると、Intent呼出部３３１に呼出失敗を返し、画面１３１０が表示される。再実行ボタン１３３３は、再度Intent呼出しを行うためのボタンである。この再実行ボタン１３３３を押下すると、画面１３１０の宛先ボタン１３１１を押下したときと同じ処理を行う。以上が、画面１３３０の説明である。
【００６３】
ここではユーザが実行中のサービスが完了するまで待ち、サービス完了後に再実行ボタン１３３３が押下したこととする。サービス実行部３０６は、再実行ボタン１３３３押下により、サービス選択リストの再作成を行う(ステップ６０６〜ステップ６０９を行う)。これにより、画面１３４０を操作部７０６に表示する。この画面１３４０でユーザが電子メールボタン１３４２を押下すると、Intent提供アプリの画面１３５０が操作部４０６に表示される。この画面１３５０でユーザが"bbb@xxx.co.jp"ボタン１３５２を押下すると、Intent呼出しの実行結果として宛先アドレス"bbb@xxx.co.jp"がIntent呼出受信部３０１からIntent呼出部３２１に送信する。これにより操作部７０６に画面１３６０を表示する。この結果、画面１３６０の宛先表示エリア７１２に宛先アドレス"bbb@xxx.co.jp"表示される。サービス選択リスト１３４１でユーザが電子メールボタン１３４２をユーザが押下した後の内部処理は、前述のMFPAppアプリ３２０の内部処理と同じであるため、説明は省略する。
以上が、Intent呼出しの具体例の説明である。
【００６４】
このように、サービス選択リストに表示するサービスが実行中のアプリが提供しているものかどうかで、サービス選択リストの表示と選択時の動作を変えることができる。サービス選択リストには登録されているサービスを全て表示するため、ユーザの操作性が向上する。また、実行中のアプリが提供するサービス選択時は、エラー画面を表示し、登録されているサービスを実際には実行しないため、マルチユーザ非対応のアプリが提供するサービスも安全に利用可能である。そのため、IntentPFで利用できるサービスが増え、ユーザの利便性が向上する。
以上が本実施形の説明である。
【００６５】
＜派生形１＞
なお本実施形態では、呼出元アプリがIntent呼出しを行うときに渡す呼出元コールバックは１つであり、Intent呼出結果の内容により呼出元アプリがIntent呼出が成功したかどうかを判定した。しかし、呼出元アプリがIntent呼出しを行うときに渡す呼出元コールバックを、成功の場合と失敗の場合で異なる呼出元コールバックにすることで、Intent呼出が成功したかどうかを判断することにしても良い。
【００６６】
＜派生形２＞
なお本実施形態では、フローチャート図４のステップ６０９でサービス選択リスト１３２１を表示し、実行中アプリが提供するサービスをこのリスト１３２１にボタン１３２２やボタン１３２３のように異なる形式で表示した。しかし、実行中アプリが提供するサービスは図１４のような形式で表示しても良い。図１４の説明を行う。図１４ではサービス選択リスト１４０１を表示し、このリスト１４０１に状況確認ボタン１４０２とAAAボタン１４０３を表示している。この状況確認ボタン１４０２は、図１３のボタン１３２２とボタン１３２３をまとめたものである。なお、このボタン１４０２を押下したときの動作はボタン１３２２やボタン１３２３を押下したときの動作と同じであり、エラー画面１３３０を表示する。つまり、実行中アプリが提供するサービスが１つ以上あるとき、これらのサービスをサービス選択リストには表示せず、替わりにIntentPF３００のエラー画面生成部３０４が生成するサービスをサービス選択リストに表示しても良い。このようにすることで、サービス選択リストに実行できないサービスが多数ある場合でも、ユーザに見やすいサービス選択リストを提示することが可能となる。
【００６７】
＜派生形３＞
なお本実施形態では、アプリが提供しているサービスがIntent呼出により実行中である場合は、このアプリを実行中アプリと判定していた。しかし、実行中アプリの判定は、Intent呼出だけではなく別の条件も考慮して判定してもよい。具体的には、サービス提供アプリがIntent呼出以外で実行中の場合、このアプリを実行中アプリと判定しても良い。サービス提供アプリが実行中であることを判定する方法は多数ある。例えば、IntentPF３００のサービス登録部３０１に実行中フラグを１にするAPIを用意し、サービス提供アプリがIntent呼出以外のジョブを実行するときにこのAPIを呼び出す方法がある。このAPIがアプリから呼び出されると、呼び出したアプリが提供する全サービスの実行中フラグを１にすることで、サービスを実行中に変える。また別の方法として、サービス選択リストを表示する前もしくは後で、サービス選択リストに表示する前もしくはサービス選択リスト表示中のサービスを提供しているアプリに対し、実行中であるかを定期的に問い合わせる方法もある。そして、問い合わせ結果により実行中の場合は、サービス選択リストの表示をサービス実行中の場合と同じように異なる形式に変更する。具体的には、図１５の画面１５００でサービス選択リスト１５０１表示中にScanToSendアプリが実行中になると、自動的に(ユーザが操作部を何も押下せずに)、画面１５１０にサービス選択リスト１５１１が表示される。このようにすることで、サービス選択リスト表示後でも正確に実行中アプリを判定できるようになり、より安全にIntent呼出を実行することが可能となる。逆に、実行中であったサービスの実行が終了した場合には、たとえばサービス選択リスト１５１１からサービス選択リスト１５０１へと表示が変更される。
【００６８】
［第２の実施形態］
第１の実施形態では、画像形成装置１００の操作部１０６と外部装置４００の操作部４０６で同じ画面を表示していた。しかし、同じIntent呼出でも異なる画面を表示してもよい。本実施形態では、どの装置でIntent呼出を行うかにより異なる画面(正確にはサービス選択リスト)を表示する実施形態を、フローチャート図１６を用いて説明する。なお、基本的な処理や制御は第１の実施形態と同じであるため、第１の実施形態と異なる点のみを説明する。
【００６９】
＜Intent登録情報＞
サービス提供アプリとして画像形成装置１００で動作するScanToSendアプリ３１０があり、ScanToSendアプリ３１０からのIntent登録情報には、他装置実行フラグ情報も含むこととする。この他装置実行フラグとは、サービス提供アプリと異なる装置で、サービスの実行が可能かどうかを表すフラグであり、０のときは実行不可、１のときは実行可能を表す。ここでは、Intent登録情報は図１７の状態であり、ScanToSendアプリ３１０の提供するサービスは全て１であり、サービス提供元アプリが存在する画像形成装置１００内でのみ実行可能になっているとする。このような状態で、外部装置４００で動作するPCAppアプリ３３０からカテゴリが"address"のサービスを利用することとする。
【００７０】
＜Intent呼出時の処理＞
画像形成装置１００のIntent呼出受信部３０２は、外部装置４００のIntent呼出部３３１からのIntent呼出を受信すると、このIntent呼出情報をHDD１０４に記憶する(ステップ６０１)。その後、Intent呼出受信部３０２は、受信したIntent呼出情報からIntent呼出装置を特定する(ステップ１６０１)。このIntent呼出装置の特定方法としては、Intent呼出受信時のSOAPメッセージのプロトコルバインディングヘッダの「Host」等から特定する方法がある。しかしここでは、Intent呼出情報の呼出元コールバックアドレスから判定する方法を用いる。具体的には、PCAppアプリ３３０のIntent呼出情報が図１２であるとすると、Intent呼出情報の呼出元コールバックのアドレスは"http://172.24.10.20/..."である。そのためIntent呼出装置は、それ自身のIPアドレス"http://172.24.10.10/..."とは異なるIPアドレス"172.24.10.20"から外部装置であると判断する。Intent呼出装置を特定後、Intent呼出受信部３０２は、実行中アプリ判定部３０３に実行中アプリの確認要求を送信し、実行中アプリ判定部３０３は実行中アプリが存在するかどうかを確認する（ステップ６０２）。このステップ６０２〜ステップ６０４の処理は第１の実施形態と同じであるため、省略する。
【００７１】
Intent呼出受信部３０２は、実行するサービスのカテゴリ特定後(ステップ６０４後)、このカテゴリに対応するサービスがIntent登録情報に存在するかどうかを確認する(ステップ１６０２)。この確認では、第１の実施形態ではカテゴリに対応するサービスを特定しているのに対して、本実施形態ではさらにこの特定したサービスに対して別の判定を行う。この別の判定を説明する。Intent呼出受信部３０２は、Intent登録情報を参照し、特定したサービスの他装置実行フラグを確認する。そして、他装置実行フラグが０の場合(サービス提供元の装置でしか動作させない場合)、Intent呼出受信部３０２は、ステップ１６０１で特定したIntent呼出装置が画像形成装置１００であるかも判定する。ここでは、PCAppアプリ３３０から"address"というカテゴリのIntent呼出があるとすると、まず、図１７のIntent登録情報から対応するサービスとして、タイトルが"電子メール"、"FAX"、"AAA"の３つのサービスを特定する。その後、図１７のように他装置実行フラグが０の"電子メール"、"FAX"というタイトルのサービスが、特定したサービスに含まれているため、Intent呼出装置が画像形成装置１００であるかを判定する。ここでは、Intent呼出装置は外部装置４００であるため、ステップ１６０２で特定した対応するサービスのうち"電子メール"、"FAX"の２つは提供できず、提供できるサービスはタイトルが"AAA"というサービスのみとなる。その後のステップ６０６〜ステップ６１１の処理は、第１の実施形態と同じであるため、説明は省略する。
【００７２】
この結果、外部装置４００の操作部４０６で図７の画面７１０で宛先ボタン７１１を押下すると、図２の画面２００のサービス選択リスト２０１にタイトルが"AAA"というサービスを表すボタン２０２のみを表示する。なお、第１の実施形態のように、操作部１０６で図７の画面７１０で宛先ボタン７１１を押下すると、Intent呼出装置が画像形成装置１００であるため、サービス選択リスト７２１に３つのサービスを表示する。
【００７３】
以上が、第２の実施形態の説明である。このように同じIntent呼出でも、Intent呼出元により異なるサービスを提供することが可能となる。これにより、提供するサービスを限定することによるセキュリティ強化や、提供するサービスを増加することによるユーザの利便性向上を図ることが可能となる。
【００７４】
＜派生形＞
本実施形態では、ステップ１６０２で他装置実行フラグが０かつIntent呼出装置がサービス提供装置ではない、すなわち画像形成装置ではないサービスは、対応するサービスではないと判断した。しかし、他装置実行フラグが０かつIntent呼出装置が画像形成装置ではないサービスであってもサービス選択リストに表示し、ユーザが当該サービスを選択することに応じてエラー画面を表示することとしても良い。
【００７５】
［その他の実施形態］
また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（または情報処理装置やＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。
【図１】
2015148901.tif 000003
【図２】
2015148901.tif 000004
【図３】
2015148901.tif 000005
【図４】
2015148901.tif 000006
【図５】
2015148901.tif 000007
【図６】
2015148901.tif 000008
【図７】
2015148901.tif 000009
【図８】
2015148901.tif 000010
【図９】
2015148901.tif 000011
【図１０】
2015148901.tif 000012
【図１１】
2015148901.tif 000013
【図１２】
2015148901.tif 000014
【図１３】
2015148901.tif 000015
【図１４】
2015148901.tif 000016
【図１５】
2015148901.tif 000017
【図１６】
2015148901.tif 000018
【図１７】
2015148901.tif 000019