(57)【特許請求の範囲】
【請求項１】
１以上の情報処理装置を含み、所定の処理をそれぞれ実行する複数のプログラムを有する情報処理システムであって、
電子データを用いた一連の処理を外部サービスと連携して実行するアプリケーション毎に、該アプリケーションを識別する識別情報と、該一連の処理を前記プログラムを組み合わせて実行するための一連の処理に関する情報とを関連付けて記憶する記憶手段と、
前記情報処理システムに接続される１以上の機器のうちの一の機器から前記識別情報を含む第１の要求を受信すると、前記第１の要求の送信元がブラウザ又はクライアントアプリケーションのいずれであるかを判定する判定手段と、
前記判定手段により前記第１の要求の送信元がブラウザであると判定された場合は前記一の機器に搭載された前記ブラウザが前記識別情報に対応する画面を表示するためのＨＴＭＬ形式の画面情報を前記一の機器に送信し、前記判定手段により前記第１の要求の送信元がクライアントアプリケーションであると判定された場合は前記一の機器に搭載された前記クライアントアプリケーションが前記識別情報に対応する画面を表示するための情報を汎用的な形式で前記一の機器に送信する送信手段と、
前記一の機器上に表示された前記画面上での操作に応じて前記一の機器から前記識別情報と、前記一連の処理に用いる電子データに関する情報とを含む第２の要求を受け付ける受付手段と、
前記受付手段により受け付けた前記第２の要求に含まれる前記電子データに関する情報に基づく電子データを用いた前記一連の処理を、前記第２の要求に含まれる前記識別情報に関連付けて前記記憶手段に記憶されている前記一連の処理に関する情報に基づいて、前記複数のプログラムのうちの１以上のプログラムを組み合わせて実行する処理実行手段と
を有する情報処理システム。
【請求項２】
前記処理実行手段は、
さらに、前記電子データのデータ型を所定のデータ型に変換する型変換手段を１以上有し、
前記電子データを用いた前記一連の処理を、前記一連の処理に関する情報に基づいて、前記１以上のプログラムと、前記型変換手段とを組み合わせて、前記型変換手段により前記電子データのデータ型を前記プログラムが処理可能な所定のデータ型に変換した後、該プログラムが処理を実行することにより実行する、請求項１記載の情報処理システム。
【請求項３】
前記複数のプログラムは、外部サービスに関する処理を実行するプログラムを含み、
前記外部サービスに関する処理を実行するプログラムは、
外部サービスに対して電子データをアップロードする処理を実行するプログラム及び外部サービスから電子データをダウンロードする処理を実行するプログラムを少なくとも含む、請求項１又は２記載の情報処理システム。
【請求項４】
前記外部サービス毎に、複数の前記外部サービスに対して共通に定義された共通ＡＰＩと、前記外部サービス毎に固有に定義された固有ＡＰＩとを含む外部サービス連携手段を有し、
前記外部サービスに関する処理を実行するプログラムは、
前記共通ＡＰＩ又は前記固有ＡＰＩを用いて、前記外部サービスに関する処理を実行する、請求項３に記載の情報処理システム。
【請求項５】
前記共通ＡＰＩは、複数の前記外部サービスのいずれもが共通に提供する機能を利用するためのＡＰＩであり、
前記固有ＡＰＩは、複数の前記外部サービスのうちのいずれかの外部サービスが提供する機能を利用するためのＡＰＩである、請求項４記載の情報処理システム。
【請求項６】
前記外部サービスに関する処理を実行するプログラムは、
前記共通ＡＰＩ又は前記固有ＡＰＩの可変部分に、外部サービスの識別情報を指定することにより該指定された識別情報に対応する外部サービスに対して前記外部サービスに関する処理を実行する、請求項４又は５記載の情報処理システム。
【請求項７】
前記情報処理システムは、所定の処理をそれぞれ実行する複数の外部プログラムを有する外部システムと接続され、
前記処理実行手段は、
前記電子データを用いた前記一連の処理を、前記一連の処理に関する情報に基づいて、前記１以上のプログラムと、前記外部プログラムとを組み合わせて実行し、
前記プログラムは前記情報処理システムに予め組み込まれているプログラムであり、前記外部プログラムは前記情報処理システムと通信ネットワークを介して接続される外部装置で管理されているプログラムである、請求項１ないし６のいずれか１項に記載の情報処理システム。
【請求項８】
前記処理実行手段は、
前記一連の処理に含まれる一の処理が前記外部プログラムにより実行される処理か否かを判定する判定手段を有し、
前記判定手段により前記一の処理が前記外部プログラムにより実行される処理であると判定された場合、該外部プログラムによる処理を前記外部システムに要求する、請求項７に記載の情報処理システム。
【請求項９】
前記処理実行手段により実行された前記一連の処理の結果を、前記一の機器に送信する送信手段を有する、請求項１ないし８のいずれか１項に記載の情報処理システム。
【請求項１０】
前記アプリケーションは、前記一の機器から送信された電子データを前記外部サービスに対してアップロードするアプリケーションを少なくとも含む、請求項１ないし９のいずれか１項に記載の情報処理システム。
【請求項１１】
前記アプリケーションは、前記外部サービスに蓄積されている電子データをダウンロードして前記一の機器に送信するアプリケーションを少なくとも含む、請求項９に記載の情報処理システム。
【請求項１２】
前記送信手段は、前記外部サービスからダウンロードした電子データを、前記一連の処理の結果として前記一の機器に送信する、請求項１１に記載の情報処理システム。
【請求項１３】
所定の処理をそれぞれ実行する複数のプログラムを有する情報処理装置であって、
電子データを用いた一連の処理を外部サービスと連携して実行するアプリケーション毎に、該アプリケーションを識別する識別情報と、該一連の処理を前記プログラムを組み合わせて実行するための一連の処理に関する情報とを関連付けて記憶する記憶手段と、
前記情報処理装置に接続される１以上の機器のうちの一の機器から前記識別情報を含む第１の要求を受信すると、前記第１の要求の送信元がブラウザ又はクライアントアプリケーションのいずれであるかを判定する判定手段と、
前記判定手段により前記第１の要求の送信元がブラウザであると判定された場合は前記一の機器に搭載された前記ブラウザが前記識別情報に対応する画面を表示するためのＨＴＭＬ形式の画面情報を前記一の機器に送信し、前記判定手段により前記第１の要求の送信元がクライアントアプリケーションであると判定された場合は前記一の機器に搭載された前記クライアントアプリケーションが前記識別情報に対応する画面を表示するための情報を汎用的な形式で前記一の機器に送信する送信手段と、
前記一の機器上に表示された前記画面上での操作に応じて前記一の機器から前記識別情報と、前記一連の処理に用いる電子データに関する情報とを含む第２の要求を受け付ける受付手段と、
前記受付手段により受け付けた前記第２の要求に含まれる前記電子データに関する情報に基づく電子データを用いた前記一連の処理を、前記第２の要求に含まれる前記識別情報に関連付けて前記記憶手段に記憶されている前記一連の処理に関する情報に基づいて、前記複数のプログラムのうちの１以上のプログラムを組み合わせて実行する処理実行手段と
を有する情報処理装置。
【請求項１４】
１以上の情報処理装置を含み、所定の処理をそれぞれ実行する複数のプログラムを有する情報処理システムであって、電子データを用いた一連の処理を外部サービスと連携して実行するアプリケーション毎に、該アプリケーションを識別する識別情報と、該一連の処理を前記プログラムを組み合わせて実行するための一連の処理に関する情報とを関連付けて記憶する記憶手段を有する情報処理システムに用いられる情報処理方法において、
前記情報処理システムに接続される１以上の機器のうちの一の機器から前記識別情報を含む第１の要求を受信すると、前記第１の要求の送信元がブラウザ又はクライアントアプリケーションのいずれであるかを判定する判定手順と、
前記判定手順により前記第１の要求の送信元がブラウザであると判定された場合は前記一の機器に搭載された前記ブラウザが前記識別情報に対応する画面を表示するためのＨＴＭＬ形式の画面情報を前記一の機器に送信し、前記判定手順により前記第１の要求の送信元がクライアントアプリケーションであると判定された場合は前記一の機器に搭載された前記クライアントアプリケーションが前記識別情報に対応する画面を表示するための情報を汎用的な形式で前記一の機器に送信する送信手順と、
前記一の機器上に表示された前記画面上での操作に応じて前記一の機器から前記識別情報と、前記一連の処理に用いる電子データに関する情報とを含む第２の要求を受け付ける受付手順と、
前記受付手順により受け付けた前記第２の要求に含まれる前記電子データに関する情報に基づく電子データを用いた前記一連の処理を、前記第２の要求に含まれる前記識別情報に関連付けて前記記憶手段に記憶されている前記一連の処理に関する情報に基づいて、前記複数のプログラムのうちの１以上のプログラムを組み合わせて実行する処理実行手順と
を有する情報処理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理システム、情報処理装置、及び情報処理方法に関する。
【背景技術】
【０００２】
近年、クラウドコンピューティング等により多種多様な外部サービスが提供されるようになった。例えば、ユーザにより指定された電子データを外部ストレージに保管する外部サービス等が知られている。
【０００３】
また、例えば画像形成装置で原稿をスキャンして取得した画像データを外部ストレージに保管する技術が知られている（例えば特許文献１参照）。このように、画像形成装置と外部サービスとが連携して処理を行う技術が従来より知られている。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかしながら、上記の従来技術においては、外部サービスと連携して処理を行うためには画像形成装置に搭載されるアプリケーションの開発が必要となる。また、ある外部サービスが固有の機能（他の外部サービスが提供していない機能）を提供するようになった場合には、この固有の機能を利用するためのモジュールやプラグイン等を開発する必要がある。したがって、画像形成装置に搭載されるアプリケーションの追加や修正等の開発に要する工数が大きくなる場合があった。
【０００５】
本発明の一実施形態は、上記の点に鑑みてなされたもので、外部サービスと連携した処理を行うためのアプリケーションの開発を支援することを目的とする。
【課題を解決するための手段】
【０００６】
上記目的を達成するため、本発明の一実施形態は、１以上の情報処理装置を含み、所定の処理をそれぞれ実行する複数のプログラムを有する情報処理システムであって、電子データを用いた一連の処理を外部サービスと連携して実行するアプリケーション毎に、該アプリケーションを識別する識別情報と、該一連の処理を前記プログラムを組み合わせて実行するための一連の処理に関する情報とを関連付けて記憶する記憶手段と、前記情報処理システムに接続される１以上の機器のうちの一の機器から前記識別情報と、前記一連の処理に用いる電子データに関する情報とを含む要求を受け付ける受付手段と、前記受付手段により受け付けた前記要求に含まれる前記電子データに関する情報に基づく電子データを用いた前記一連の処理を、前記要求に含まれる前記識別情報に関連付けて前記記憶手段に記憶されている前記一連の処理に関する情報に基づいて、前記複数のプログラムのうちの１以上のプログラムを組み合わせて実行する処理実行手段とを有することを特徴とする。
【発明の効果】
【０００７】
本発明の一実施形態によれば、外部サービスと連携した処理を行うためのアプリケーションの開発を支援することができる。
【図面の簡単な説明】
【０００８】
【図１】第１の実施形態に係る情報処理システムの一例の構成図である。
【図２】第１の実施形態に係るサービス提供システムの一例のハードウェア構成図である。
【図３】第１の実施形態に係る画像形成装置の一例のハードウェア構成図である。
【図４】第１の実施形態に係る情報処理システムの一例の処理ブロック図である。
【図５】共通Ｉ／Ｆ及び固有Ｉ／Ｆの一例を説明するための図である。
【図６】データ定義の一例を説明するための図である。
【図７】レイアウト情報の一例を説明するための図である。
【図８】処理内容の一例を説明するための図である。
【図９】第１の実施形態に係るスキャン配信サービスの全体処理の一例のシーケンス図である。
【図１０】スキャン配信サービスを利用するためのアプリ画面の一例を説明するための図である。
【図１１】第１の実施形態に係るロジック処理部の一例の処理ブロック図である。
【図１２】型変換テーブルの一例を説明するための図である。
【図１３】第１の実施形態に係るＯＣＲから配信実行までの処理の一例のシーケンス図である。
【図１４】第１の実施形態に係るクラウドプリントサービスの全体処理の一例のシーケンス図である。
【図１５】クラウドプリントサービスを利用するためのアプリ画面の一例を説明するための図である。
【図１６】第１の実施形態に係るファイル取得実行から印刷変換までの処理の一例のシーケンス図である。
【図１７】第２の実施形態に係る情報処理システムの一例の処理ブロック図である。
【図１８】第２の実施形態に係るアプリ画面の表示処理の一例のシーケンス図である。
【図１９】第３の実施形態に係る情報処理システムの一例の構成図である。
【図２０】第３の実施形態に係る情報処理システムの一例の処理ブロック図である。
【図２１】第３の実施形態に係るロジック処理部の一例の処理ブロック図である。
【図２２】コンポーネント管理テーブルの一例を説明するための図である。
【図２３】第３の実施形態に係る外部コンポーネント処理部の一例の処理ブロック図である。
【図２４】型変換テーブルの一例を説明するための図である。
【図２５】第３の実施形態に係るＯＣＲから配信実行までの処理の一例のシーケンス図である。
【図２６】処理内容の他の例を説明するための図である。
【図２７】第３の実施形態に係る外部コンポーネント処理の一例のシーケンス図である。
【図２８】第３の実施形態に係る処理内容の作成処理の一例のシーケンス図である。
【図２９】処理内容の作成の一例を説明するための図である。
【発明を実施するための形態】
【０００９】
以下、本発明の実施形態について図面を参照しながら詳細に説明する。
【００１０】
［第１の実施形態］
＜システム構成＞
図１は、第１の実施形態に係る情報処理システムの一例の構成図である。図１に示される情報処理システム１は、サービス提供環境Ｅ１、ユーザ環境Ｅ２、及び外部ストレージシステム３０を含み、インターネット等の広域的なネットワークＮ１を介して通信可能に接続されている。
【００１１】
サービス提供環境Ｅ１は、ネットワークを介してクラウドサービス等の外部サービスを提供するシステム環境である。なお、本実施形態では、外部サービスの具体例としてクラウドサービスを採用して説明するが、ＡＳＰ（Application Service Provider）によって提供されるサービスやＷｅｂサービス等、ネットワークを介して提供されるサービスに関して本実施の形態が適用されてもよい。
【００１２】
サービス提供環境Ｅ１は、一台以上の情報処理装置で実現されるサービス提供システム１０を有する。サービス提供システム１０は、ネットワークを介して所定のサービスを提供する。例えば、サービス提供システム１０は、ユーザ環境Ｅ２の画像形成装置２０において原稿をスキャンして生成された電子ファイルを、ＯＣＲ（Optical Character Reader）処理して、外部ストレージシステム３０に保存するサービス（スキャン配信サービス）を提供する。また、例えば、サービス提供システム１０は、外部ストレージシステム３０に保存されている電子ファイルを、ユーザ環境Ｅ２の画像形成装置２０で印刷するサービス（クラウドプリントサービス）を提供する。本実施形態では、サービス提供システム１０は、このようなスキャン配信サービス及びクラウドプリントサービスを提供するものとして説明する。
【００１３】
ただし、サービス提供システム１０により提供されるサービスは、これらに限られず、例えば、外部ストレージシステム３０に保存されている電子ファイルを、ユーザ環境Ｅ２のプロジェクタで投影するサービス等であってもよい。また、画像形成装置２０において原稿をスキャンして生成された電子ファイルを、ＯＣＲ処理した後、所定の言語に翻訳（例えば、英語から日本語に翻訳）して、外部ストレージシステム３０に保存するサービス等であってもよい。
【００１４】
なお、サービス提供システム１０の全部又は一部は、ユーザ環境Ｅ２に設置されていてもよい。すなわち、サービス提供システム１０を構成する情報処理装置の全部又は一部は、ユーザ環境Ｅ２に包含されていてもよい。
【００１５】
ユーザ環境Ｅ２は、例えば画像形成装置２０を使用するユーザである企業等におけるシステム環境である。ユーザ環境Ｅ２は、一台以上の画像形成装置２０が例えばＬＡＮ（Local Area Network）等のネットワークを介して接続されている。
【００１６】
本実施形態に係る画像形成装置２０は、プリント機能及びスキャン機能を有する画像形成装置である。なお、画像形成装置２０は、プリント機能及びスキャン機能以外に、コピー機能やファックス（ＦＡＸ）通信機能等を備える複合機等でもよい。
【００１７】
外部ストレージシステム３０は、ネットワークを介してストレージサービス（又はオンラインストレージ）と呼ばれるクラウドサービスを提供するコンピュータシステムである。ストレージサービスとは、外部ストレージシステム３０のストレージの記憶領域を貸し出すサービスである。本実施形態では、スキャン配信サービスにおいて、外部ストレージシステム３０によって貸し出される記憶領域に、ＯＣＲ処理された電子ファイルを保存（アップロード）する。また、本実施形態では、クラウドプリントサービスにおいて、外部ストレージシステム３０によって貸し出される記憶領域から印刷対象となる電子ファイルを取得（ダウンロード）する。なお、以降では、複数の外部ストレージシステム３０について、各々を区別するときは、「外部ストレージシステム３０１」、「外部ストレージシステム３０２」等と添え字を用いて記載する。また、外部ストレージシステム３０１によって提供されるサービスの名称を「ストレージサービスＡ」、ストレージシステム３０２によって提供されるサービスの名称を「ストレージサービスＢ」等とする。
【００１８】
なお、外部ストレージシステム３０は、複数台の情報処理装置によって実現されるシステムであってもよい。また、図１に示される情報処理システム１の構成は一例であって、他の構成であってもよい。例えば、上述したように、ユーザ環境Ｅ２は、画像形成装置２０に加えて又は画像形成装置２０に代えて、プロジェクタ、電子黒板等の各種機器を有していてもよい。
【００１９】
＜ハードウェア構成＞
≪サービス提供システム≫
図１に示されるサービス提供システム１０は、例えば図２に示されるようなハードウェア構成を有する。図２は、第１の実施形態に係るサービス提供システムの一例のハードウェア構成図である。図２に示すサービス提供システム１０は、入力装置１１と、表示装置１２と、外部Ｉ／Ｆ１３と、ＲＡＭ（Random Access Memory）１４とを有する。また、サービス提供システム１０は、ＲＯＭ（Read Only Memory）１５と、ＣＰＵ（Central Processing Unit）１６と、通信Ｉ／Ｆ１７と、ＨＤＤ（Hard Disk Drive）１８とを有する。これらの各ハードウェアは、それぞれがバスＢで接続されている。
【００２０】
入力装置１１は、キーボードやマウス、タッチパネル等を含み、ユーザが各操作信号を入力するのに用いられる。表示装置１２は、ディスプレイ等を含み、サービス提供システム１０による処理結果を表示する。なお、入力装置１１及び／又は表示装置１２は、必要なときにサービス提供システム１０に接続して利用する形態であってもよい。
【００２１】
通信Ｉ／Ｆ１７は、サービス提供システム１０をネットワークＮ１に接続するインタフェースである。これにより、サービス提供システム１０は、通信Ｉ／Ｆ１７を介してデータ通信を行うことができる。
【００２２】
ＨＤＤ１８は、プログラムやデータを格納している不揮発性の記憶装置の一例である。格納されるプログラムやデータには、サービス提供システム１０全体を制御する基本ソフトウェアであるＯＳ（Operating System）、及びＯＳ上において各種機能を提供するアプリケーションソフトウェア等がある。なお、サービス提供システム１０は、ＨＤＤ１８に代え、記憶媒体としてフラッシュメモリを用いるドライブ装置（例えばソリッドステートドライブ：ＳＳＤ）を利用するものであってもよい。また、ＨＤＤ１８は、格納しているプログラムやデータを所定のファイルシステム及び／又はＤＢにより管理している。
【００２３】
外部Ｉ／Ｆ１３は、外部装置とのインタフェースである。外部装置には、記録媒体１３ａ等がある。これにより、サービス提供システム１０は、外部Ｉ／Ｆ１３を介して記録媒体１３ａの読み取り及び／又は書き込みを行うことができる。記録媒体１３ａには、フレキシブルディスク、ＣＤ、ＤＶＤ、ＳＤメモリカード、ＵＳＢメモリ等がある。
【００２４】
ＲＯＭ１５は、電源を切ってもプログラムやデータを保持することができる不揮発性の半導体メモリ（記憶装置）である。ＲＯＭ１５には、サービス提供システム１０の起動時に実行されるＢＩＯＳ（Basic Input/Output System）、ＯＳ設定、及びネットワーク設定等のプログラムやデータが格納されている。ＲＡＭ１４は、プログラムやデータを一時保持する揮発性の半導体メモリ（記憶装置）である。
【００２５】
ＣＰＵ１６は、ＲＯＭ１５やＨＤＤ１８等の記憶装置からプログラムやデータをＲＡＭ１４上に読み出し、処理を実行することで、サービス提供システム１０全体の制御や機能を実現する演算装置である。
【００２６】
本実施形態に係るサービス提供システム１０は、上記のハードウェア構成を有することにより、後述するような各種処理を実現できる。
【００２７】
≪画像形成装置≫
図１に示される画像形成装置２０は、例えば図３に示されるようなハードウェア構成を有する。図３は、第１の実施形態に係る画像形成装置の一例のハードウェア構成図である。図３に示す画像形成装置２０は、コントローラ２１と、操作パネル２２と、外部Ｉ／Ｆ２３と、通信Ｉ／Ｆ２４と、プリンタ２５と、スキャナ２６とを有する。また、コントローラ２１は、ＣＰＵ２１１と、ＲＡＭ２１２と、ＲＯＭ２１３と、ＮＶＲＡＭ２１４と、ＨＤＤ２１５とを有する。ＲＯＭ２１３は、各種プログラムやデータが格納されている。ＲＡＭ２１２はプログラムやデータを一時保持する。ＮＶＲＡＭ２１４は、例えば設定情報等が格納されている。また、ＨＤＤ２１５は各種プログラムやデータが格納されている。
【００２８】
ＣＰＵ２１１は、ＲＯＭ２１３やＮＶＲＡＭ２１４、ＨＤＤ２１５等からプログラムやデータ、設定情報等をＲＡＭ２１２上に読み出し、処理を実行することで、画像形成装置２０全体の制御や機能を実現する。
【００２９】
操作パネル２２は、ユーザからの入力を受け付ける入力部と、表示を行う表示部とを備えている。外部Ｉ／Ｆ２３は、外部装置とのインタフェースである。外部装置には、記録媒体２３ａ等がある。これにより、画像形成装置２０は、外部Ｉ／Ｆ２３を介して記録媒体２３ａの読み取り及び／又は書き込みを行うことができる。記録媒体２３ａにはＩＣカード、フレキシブルディスク、ＣＤ、ＤＶＤ、ＳＤメモリカード、ＵＳＢメモリ等がある。
【００３０】
通信Ｉ／Ｆ２４は、画像形成装置２０をネットワークＮ１に接続するインタフェースである。これにより、画像形成装置２０は通信Ｉ／Ｆ２４を介してデータ通信を行うことができる。プリンタ２５は、印刷データを印刷するための印刷装置である。スキャナ２６は原稿を読み取り画像ファイル（電子ファイル）を生成するための読取装置である。
【００３１】
本実施形態に係る画像形成装置２０は、上記のハードウェア構成を有することにより、後述するような各種処理を実現できる。
【００３２】
＜ソフトウェア構成＞
第１の実施形態に係る情報処理システム１は、例えば図４に示されるような処理ブロックにより実現することができる。図４は、第１の実施形態に係る情報処理システムの一例の処理ブロック図である。
【００３３】
画像形成装置２０は、例えばＣＰＵ２１１等により実現されるブラウザ２１０を有する。画像形成装置２０のユーザは、ブラウザ２１０を介して、サービス提供システム１０により提供されるサービスを利用することができる。このように、本実施形態に係る画像形成装置２０では、ブラウザ２１０が搭載されていればよく、サービスを利用するための専用のアプリケーションを開発等する必要がない。
【００３４】
サービス提供システム１０は、サービス処理部１１０と、ドキュメントサービス部１５０と、ストレージサービス連携部１６０とを有する。これら各部は、例えばＣＰＵ１６等により実現される。
【００３５】
また、サービス提供システム１０は、アプリ情報記憶部１９０を有する。このアプリ情報記憶部１９０は、ＨＤＤ１８により実現される。なお、アプリ情報記憶部１９０は、サービス提供システム１０とネットワークを介して接続される記憶装置等により実現されてもよい。
【００３６】
サービス処理部１１０は、アプリ管理部１２０と、ロジック処理部１３０と、データＩ／Ｆ部１４０とを有する。
【００３７】
アプリ管理部１２０は、アプリ情報記憶部１９０に記憶されているアプリ情報１０００を管理する。アプリ管理部１２０は、ブラウザ２１０からの要求に応じて、アプリ情報１０００に含まれる画面定義に基づくアプリ画面を返信する。これにより、画像形成装置２０のブラウザ２１０には、サービス提供システム１０により提供されるサービスを利用するためのアプリ画面が表示される。ここで、アプリ情報１０００は、詳細は後述するが、上述したアプリ画面を画像形成装置２０に表示させるための画面定義と、当該アプリ情報１０００により実現されるサービスの処理内容とが記述された情報である。
【００３８】
また、アプリ管理部１２０は、ロジック処理部１３０からの要求に応じて、アプリ情報１０００に含まれる処理内容を返信する。処理内容は、詳細は後述するが、スキャン配信サービスやクラウドプリントサービス等を実現するための一連の処理が記述されている。なお、一連の処理は、「処理フロー」又は「フロー」とも称される。
【００３９】
ロジック処理部１３０は、ブラウザ２１０からの要求に応じて、アプリ管理部１２０から処理内容を取得する。そして、ロジック処理部１３０は、取得した処理内容に従ってドキュメントサービス部１５０又は／及びストレージサービス連携部１６０のファイル処理部１７０に対して、処理の実行を要求する。これにより、サービス提供システム１０による各種サービスが、画像形成装置２０に提供される。なお、ロジック処理部１３０の詳細な処理ブロックについては、後述の＜処理の詳細＞の中で説明する。
【００４０】
データＩ／Ｆ部１４０は、ブラウザ２１０からの要求に応じて、ストレージサービス連携部１６０のデータ処理部１８０に対して、例えばフォルダ一覧の取得等を要求する。
【００４１】
ドキュメントサービス部１５０は、サービス提供システム１０により提供されるサービスを実現するためのプログラム（モジュール）群である。ドキュメントサービス部１５０には、例えば、電子ファイルに対してＯＣＲ処理を実行するＯＣＲ処理１５１や電子ファイルを画像形成装置２０が印刷可能なデータ形式（印刷データ）に変換する印刷変換処理１５２等が含まれる。ドキュメントサービス部１５０には、これら以外にも、例えば、電子ファイルの圧縮又は解凍するためのプログラム、電子ファイルのデータ形式を変換（例えばＰＤＦ形式に変換）するためのプログラム等、各種の処理を実行するプログラムが含まれていてもよい。
【００４２】
ストレージサービス連携部１６０は、ロジック処理部１３０及びデータＩ／Ｆ部１４０からの要求に応じて、外部ストレージシステム３０に対して、各種処理の実行を要求する。ここで、サービス提供システム１０は、外部ストレージシステム３０毎に、ストレージサービス連携部１６０をそれぞれ有する。すなわち、サービス提供システム１０は、外部ストレージシステム３０１に対して処理を要求するためのストレージサービスＡ連携部１６０１、外部ストレージシステム３０２に対して処理を要求するためのストレージサービスＢ連携部１６０２等を有する。このように、サービス提供システム１０は、連携して処理を行う外部ストレージシステム３０毎に、それぞれ対応するストレージサービス連携部１６０を有する。なお、以降では、複数のストレージサービス連携部１６０について、各々を区別するときは、上記のように「ストレージサービスＡ連携部１６０１」、「ストレージサービスＢ連携部１６０２」等と添え字を用いて記載する。
【００４３】
ストレージサービス連携部１６０は、上述したように、ロジック処理部１３０からの要求を受け付けるファイル処理部１７０と、データＩ／Ｆ部１４０からの要求を受け付けるデータ処理部１８０とを有する。
【００４４】
ファイル処理部１７０は、外部ストレージシステム３０に保存されている電子ファイルに対する操作（例えば、取得、保存、編集等）を行うためのＡＰＩ（Application Programming Interface）が定義された共通Ｉ／Ｆ１７１及び固有Ｉ／Ｆ１７２を有する。共通Ｉ／Ｆ１７１は、複数の外部ストレージシステム３０間で共通に利用できるＡＰＩであり、例えば図５（ａ）に示すようなＡＰＩが挙げられる。換言すれば、ファイル処理部１７０の共通Ｉ／Ｆ１７１は、すべての外部ストレージシステム３０が利用できるファイル操作に関する機能（例えば、ファイルの取得、保存等）を利用するためのＡＰＩ群である。一方、固有Ｉ／Ｆ１７２は、特定の外部ストレージシステム３０において利用できるＡＰＩであり、例えば図５（ｂ）に示すようなＡＰＩが挙げられる。換言すれば、ファイル処理部１７０の固有Ｉ／Ｆ１７２は、ある特定の外部ストレージシステム３０において利用できるファイル操作に関する機能（例えば、ファイルの編集等）を利用するためのＡＰＩ群である。したがって、共通Ｉ／Ｆ１７１は、すべてのストレージサービス連携部１６０に対して同様に定義される一方、固有Ｉ／Ｆ１７２は、当該固有Ｉ／Ｆ１７２で定義されるＡＰＩが利用可能な特定のストレージサービス連携部１６０に対して定義される。
【００４５】
一方、データ処理部１８０は、外部ストレージシステム３０に保存されている電子ファイルの書誌情報等のメタデータ（例えば、ファイル一覧、フォルダ一覧等）を取得等するためのＡＰＩが定義された共通Ｉ／Ｆ１８１及び固有Ｉ／Ｆ１８２を有する。共通Ｉ／Ｆ１８１は、複数の外部ストレージシステム３０間で共通に利用できるＡＰＩであり、例えば図５（ｃ）に示すようなＡＰＩが挙げられる。換言すれば、データ処理部１８０の共通Ｉ／Ｆ１８１は、すべての外部ストレージシステム３０で利用できるメタデータ取得等の機能を利用するためのＡＰＩ群である。一方、固有Ｉ／Ｆ１８２は、ある特定の外部ストレージシステム３０において利用できるＡＰＩであり、例えば図５（ｄ）に示すようなＡＰＩが挙げられる。換言すれば、データ処理部１８０の固有Ｉ／Ｆ１８２は、ある特定の外部ストレージシステム３０において利用できるメタデータ取得等の機能（例えば、画像ファイル一覧の取得等）を利用するためのＡＰＩ群である。したがって、共通Ｉ／Ｆ１８１は、すべてのストレージサービス連携部１６０に対して同様に定義される一方、固有Ｉ／Ｆ１８２は、当該固有Ｉ／Ｆ１８２で定義されるＡＰＩが利用可能な特定のストレージサービス連携部１６０に対して定義される。
【００４６】
以上のように、本実施形態に係るサービス提供システム１０は、連携して処理を行う外部ストレージシステム３０毎に、それぞれストレージサービス連携部１６０を有する。このため、連携先となる外部ストレージシステム３０が追加等する場合には、対応するストレージサービス連携部１６０をサービス提供システム１０に追加等すればよい。したがって、連携先となる外部ストレージシステム３０の追加等に伴う影響を局所化することができる。換言すれば、他の処理ブロック（サービス処理部１１０やドキュメントサービス部１５０等）に影響を与えることなく（すなわち、他の処理ブロックを修正等する必要なく）、連携先となる外部ストレージシステム３０の追加等を行うことができる。これにより、連携先の外部ストレージシステム３０の追加等の開発に要する工数を削減することができる。なお、ストレージサービス連携部１６０の追加等は、ＳＤＫ（Software Development Kit）を用いて行うことができる。
【００４７】
また、ストレージサービス連携部１６０は、共通Ｉ／Ｆ１７１と固有Ｉ／Ｆ１７２とを異なるモジュール等で定義している。また、共通Ｉ／Ｆ１７１及び固有Ｉ／Ｆ１７２で定義されるＡＰＩは、「ストレージサービス名」を指定することで利用することができる（すなわち、「ストレージサービス名」が可変部分となっている）。したがって、連携先の外部ストレージシステム３０を追加する場合には、他のストレージサービス連携部１６０に定義されている共通Ｉ／Ｆ１７１を再利用することができる。換言すれば、連携先の外部ストレージシステム３０を追加する場合には、当該追加する外部ストレージシステム３０の固有Ｉ／Ｆ１７２のみ開発すればよい。これにより、連携先の外部ストレージシステム３０の追加等の開発に要する工数をさらに削減することができる。なお、このことは共通Ｉ／Ｆ１８１と固有Ｉ／Ｆ１８２に関しても同様である。
【００４８】
アプリ情報記憶部１９０は、アプリ情報１０００を記憶する。アプリ情報１０００は、アプリ画面を画像形成装置２０に表示させるための画面定義と、サービスを実現するため一連の処理を示す処理内容とが記述された情報であり、アプリ情報１０００を一意に識別するためのアプリＩＤ毎に、アプリ情報記憶部１９０に記憶されている。本実施形態では、クラウドサービスＡと連携したスキャン配信サービスを実現するためのアプリ情報を「アプリ情報１０００１」とし、このアプリ情報１０００１のアプリＩＤ「app001」とする。また、本実施形態では、クラウドサービスＡと連携したクラウドプリントサービスを実現するためのアプリ情報を「アプリ情報１０００２」、このアプリ情報１０００２のアプリＩＤを「app002」とする。
【００４９】
ここで、アプリ情報１０００１の画面定義に含まれるデータ定義及びアプリ情報１０００２の画面定義に含まれるデータ定義を、それぞれ図６（ａ）及び図６（ｂ）に示す。データ定義は、画像形成装置２０のブラウザ２１０により操作パネル２２等に表示されるアプリ画面の入力欄（入力ボックス）や選択欄（選択ボックス）等を構成するための情報が記述されている。例えば、図６（ａ）におけるデータ定義部１１０１では、ユーザがスキャンにより生成される電子ファイルのファイル名を入力するための入力欄を構成するための情報が記述されている。また、データ定義部１１０２では、ストレージサービスＡにおける保存先フォルダを選択するための選択欄を構成するための情報が記述されている。なお、データ定義部１１０２の「data_source」には選択欄の各選択要素（ここでは、保存先候補のフォルダ名及びフォルダＩＤ）の取得先のＵＲＬ（Uniform Resource Locator）が記述されている。
【００５０】
次に、アプリ情報１０００１の画面定義に含まれるレイアウト情報及びアプリ情報１０００２の画面定義に含まれるレイアウト情報を、それぞれ図７（ａ）及び図７（ｂ）に示す。レイアウト情報は、画像形成装置２０のブラウザ２１０により操作パネル２２等に表示されるアプリ画面に表示される文字（入力欄の表示名称等）、入力欄や選択欄の表示位置等の情報が記述されている。例えば、図７（ａ）におけるレイアウト定義部１３０１では、データ定義における「"data_id":1」（すなわち、データ定義部１１０１）の表示位置及び表示名称の情報が記述されている。これにより、具体例は後に示すが、アプリ画面には、表示名称が「ファイル名」である入力欄が、１番目の位置に表示される。また、レイアウト定義部１３０２では、データ定義における「"data_id":2」（すなわち、データ定義部１１０２）の表示位置及び表示名称の情報が記述されている。これにより、具体例は後に示すが、アプリ画面には、表示名称が「保存先フォルダ選択」である選択欄が、２番目の位置に表示される。
【００５１】
次に、アプリ情報１０００１の処理内容及びアプリ情報１０００２の処理内容を、それぞれ図８（ａ）及び図８（ｂ）に示す。処理内容は、サービス提供システム１０により提供されるサービスを実現するために、ドキュメントサービス部１５０やストレージサービス連携部１６０に要求する一連の処理が記述されている。例えば、図８（ａ）に示す処理内容には、本実施形態に係るスキャン配信サービスを実現するための一連の処理（すなわち、スキャンされた電子ファイルをＯＣＲ処理した後、ストレージサービスＡの指定されたフォルダに配信する一連の処理）が記述されている。また、図８（ｂ）に示す処理内容には、本実施形態に係るクラウドプリントサービスを実現するための一連の処理（すなわち、ストレージサービスＡから取得した電子ファイルを印刷データに変換した後、画像形成装置２０に送信する一連の処理）が記述されている。これらの処理内容についての詳細については、後述する。
【００５２】
以上のように、本実施形態に係るサービス提供システム１０は、画像形成装置２０にアプリ画面を表示させるための画面定義と、サービスを実現するための一連の処理内容とが記述されたアプリ情報１０００を利用してサービスを提供する。このため、サービス提供システム１０により提供されるサービスを追加等する場合には、アプリ情報記憶部１９０にアプリ情報１０００を追加等すればよい。また、アプリ情報１０００を追加するには、上述したように、画面定義と処理内容とを記述すればよいため、簡易に開発することができる。したがって、サービスの追加・変更等に伴う開発工数を削減させることができるとともに、例えばサードベンダー等によるサービスの追加・変更等を容易に行うことができる。
【００５３】
＜処理の詳細＞
次に、本実施形態に係る情報処理システム１の処理の詳細について説明する。
【００５４】
≪スキャン配信サービスの全体処理≫
まず、画像形成装置２０のユーザが本実施形態に係るスキャン配信サービスを利用する場合の全体的な処理について説明する。図９は、第１の実施形態に係るスキャン配信サービスの全体処理の一例のシーケンス図である。
【００５５】
まず、画像形成装置２０のユーザは、ブラウザ２１０を用いて、サービス提供システム１０により提供されるサービスの一覧を取得するための操作を行う。すると、画像形成装置２０は、サービスの一覧の取得要求をサービス提供システム１０のサービス処理部１１０に送信する（ステップＳ９０１）。そして、サービス処理部１１０のアプリ管理部１２０は、当該取得要求を受信すると、サービス提供システム１０により提供されるサービスの一覧を画像形成装置２０に送信する。これにより、画像形成装置２０のブラウザ２１０により、画像形成装置２０の操作パネル２２にサービス提供システム１０により提供されるサービスの一覧が表示される。なお、サービスの一覧には、サービス提供システム１０により提供されるサービスのサービス名と、このサービスを実現するためのアプリ情報１０００のアプリＩＤとが含まれる。
【００５６】
ユーザは、画像形成装置２０の操作パネル２２に表示されたサービスの一覧から、自身が利用を所望するサービスを選択する。すると、ブラウザ２１０は、選択されたサービスを実現するためのアプリ情報１０００のアプリＩＤをアプリ管理部１２０に送信する（ステップＳ９０２）。ここでは、ユーザによりサービス名「スキャン配信サービス」の利用が選択されたものとする。したがって、ブラウザ２１０は、アプリ情報１０００１のアプリＩＤ「app001」をアプリ管理部１２０に送信する。
【００５７】
そして、アプリ管理部１２０は、ブラウザ２１０から受け取ったアプリＩＤ「app001」のアプリ情報１０００１に含まれる画面定義に基づきＨＴＭＬ（HyperText Markup Language）形式のアプリ画面を生成し、ブラウザ２１０に送信する。
【００５８】
ブラウザ２１０は、アプリ管理部１２０からアプリ画面を受け取ると、表示用情報の取得をデータＩ／Ｆ部１４０に要求する（ステップＳ９０３）。ここで表示用情報とは、例えばアプリ画面の選択欄の各選択要素のことである。すなわち、本実施形態では、ブラウザ２１０は、スキャン配信の配信先（保存先）となるストレージサービスＡのフォルダの一覧の取得を、データＩ／Ｆ部１４０に要求する。このような要求は、図６（ａ）のデータ定義部１１０２に記述されている「"data_source"」に定義されているＵＲＬ「http://sample.xxx.co.jp/service-a/data/folders」にＨＴＴＰリクエストを送信することで行うことができる。なお、当該ＵＲＬのうち、「http://sample.xxx.co.jp」の部分がサービス提供システム１０のホスト名、「/service-a/data/folders」の部分がストレージサービス連携部１６０におけるＡＰＩ（すなわち、図５に示すＡＰＩ）の指定となる。
【００５９】
次に、データＩ／Ｆ部１４０は、ブラウザ２１０から表示用情報の取得要求を受け付けると、当該要求を対応するストレージサービス連携部１６０のデータ処理部１８０に送信する（ステップＳ９０４）。本実施形態では、データＩ／Ｆ部１４０は、上記のＵＲＬに含まれる「service-a」（ストレージサービス名）に基づき、当該要求を、ストレージサービスＡ連携部１６０１のデータ処理部１８０１に送信する。
【００６０】
データ処理部１８０は、データＩ／Ｆ部１４０から要求を受け付けると、当該要求に含まれるＵＲＬに基づき、対応する処理要求を外部ストレージシステム３０に送信する（ステップＳ９０５）。すなわち、データ処理部１８０は、データＩ／Ｆ部１４０から受け付けた要求に含まれるＵＲＬに基づき、共通Ｉ／Ｆ１８１又は固有Ｉ／Ｆ１８２に定義されているＡＰＩを利用して、該当の外部ストレージシステム３０に処理を要求する。本実施形態では、上記のＵＲＬに含まれる「/service-a/data/folders」に基づき、データ処理部１８０は、共通Ｉ／Ｆ１８１に定義されているＡＰＩを用いて、ストレージサービスＡにフォルダ一覧の取得を要求する。すると、ブラウザ２１０は、ストレージサービスＡ連携部１６０１を介して、フォルダ一覧を受信する。フォルダ一覧は、本実施形態のスキャン配信サービスにおいて、電子ファイルの保存先の候補となるストレージサービスＡのフォルダ名及びフォルダＩＤ等の情報である。
【００６１】
次に、ブラウザ２１０は、ステップＳ９０２でアプリ管理部１２０から受け取ったアプリ画面及びフォルダ一覧に基づき、例えば図１０（ａ）に示すようなアプリ画面２０００を、操作パネル２２に表示させる（ステップＳ９０６）。
【００６２】
ここで、図１０（ａ）で示すスキャン配信サービスを利用するためのアプリ画面２０００は、ファイル名入力欄２００１と、保存先フォルダ選択欄２００２と、スキャン実行ボタン２００３とから構成されている。このうち、ファイル名入力欄２００１及び保存先フォルダ選択欄２００２は、図１０（ｂ）に示すように、それぞれＨＴＭＬソースコード２１０１及び２１０２で記述されている。このようなＨＴＭＬソースコード２１０１及び２１０２は、アプリ管理部１２０により、図６（ａ）に示すデータ定義部１１０１及び１１０２並びに図７（ｂ）に示すレイアウト定義部１３０１及び１３０２に基づいて生成される。ただし、ＨＴＭＬソースコード２１０２に指定されている「option」の設定値は、外部ストレージシステム３０から取得したフォルダ一覧に基づき、ブラウザ２１０で設定される。このように、アプリ画面２０００は、アプリ情報１０００１の画面定義に基づきアプリ管理部１２０で生成されたＨＴＭＬに対して、外部ストレージシステム３０１から取得したフォルダ一覧の情報を設定することで生成される。
【００６３】
次に、ユーザは、図１０（ａ）のアプリ画面２０００において、ファイル名入力欄２００１に所望のファイル名を入力して、保存先フォルダ選択欄２００２から所望の保存先フォルダを選択する。そして、画像形成装置２０のスキャナ２６に原稿をセットして、スキャン実行ボタン２００３を押下する（ステップＳ９０７）。ここで、ユーザはファイル名入力欄２００１にファイル名「test」を入力し、保存先フォルダ選択欄２００２から「FolderB」を選択して、スキャン実行ボタン２００３を押下したものとする。これにより、画像形成装置２０のスキャナ２６により原稿が読み取られ、ファイル名「test」の電子ファイルが生成される（ステップＳ９０８）。
【００６４】
すると、ブラウザ２１０は、スキャン配信サービスの処理の実行要求をロジック処理部１３０に送信する（ステップＳ９０９）。ここで、当該実行要求には、アプリＩＤ「app001」と、上記のステップＳ９０８で生成された電子ファイルと、選択された保存先フォルダ「FolderB」のフォルダＩＤ「folder_id_b」とが含まれる。
【００６５】
そして、ロジック処理部１３０は、処理の実行要求を受け付けると、アプリ管理部１２０を介して、当該処理の実行要求に含まれるアプリＩＤのアプリ情報１０００から処理内容を取得し、当該処理内容に従って処理を実行する（ステップＳ９１０）。すなわち、本実施形態に係るスキャン配信サービスでは、当該処理の実行要求に含まれる電子ファイルに対してＯＣＲ処理を行った後、ストレージサービスＡのフォルダ「FolderB」に対して当該ＯＣＲ処理後の電子ファイルを配信（アップロード）する。このステップＳ９１０の処理の詳細については、後述する。ここでは、ロジック処理部１３０は、ＯＣＲ処理後の電子ファイルと、フォルダ「FolderB」のフォルダＩＤ「folder_id_b」とを含む配信実行の要求を、ストレージサービスＡ連携部１６０１のファイル処理部１７０１に送信したものとして説明を続ける。
【００６６】
ファイル処理部１７０は、ロジック処理部１３０から配信実行の要求を受け付けると、共通Ｉ／Ｆ１７１又は固有Ｉ／Ｆ１７２に定義されているＡＰＩを利用して、該当の外部ストレージシステム３０に処理を要求する（ステップＳ９１１）。具体的には、本実施形態では、ファイル処理部１７０１の共通Ｉ／Ｆ１７１１に定義されているストレージサービスＡにファイルを保存するためのＡＰＩ「/service-a/process/folder」を用いて、当該電子ファイルをフォルダ「FolderB」に配信（アップロード）する。そして、電子ファイルのアップロードが完了すると、処理結果がブラウザ２１０に表示される。これにより、本実施形態に係るスキャン配信サービスが完了する。
【００６７】
≪ＯＣＲから配信実行までの処理≫
次に、図９のステップＳ９１０の処理の詳細について説明する。この処理は、主に、ロジック処理部１３０により実行される。したがって、図９のステップＳ９１０の処理の詳細について説明するに前に、ロジック処理部１３０の詳細な処理ブロックについて説明する。図１１は、第１の実施形態に係るロジック処理部の一例の処理ブロック図である。ロジック処理部１３０は、フロー実行部１３１と、コンポーネント管理部１３２と、コンポーネント群１３３と、型変換管理部１３４と、型変換群１３５とを有する。また、ロジック処理部１３０は、型変換テーブル３０００を利用する。
【００６８】
フロー実行部１３１は、ブラウザ２１０からスキャン配信サービスの処理の実行要求を受け付けると、アプリ管理部１２０を介して、アプリ情報１０００から処理内容を取得する。そして、フロー実行部１３１は、取得した処理内容に従ってコンポーネントに対して処理の実行を要求する。なお、ここで、コンポーネントとは、各種処理を実行するためのプログラム（モジュール）であり、例えばクラスや関数等で定義される。
【００６９】
コンポーネント管理部１３２は、フロー実行部１３１からの要求に応じて、コンポーネントの生成を行う。なお、コンポーネントの生成とは、例えばクラスで定義されたコンポーネントを、メモリ（例えばＲＡＭ１４）上に展開することを意味する。
【００７０】
コンポーネント群１３３は、コンポーネントの集合である。コンポーネント群１３３には、外部ストレージシステム３０に電子ファイルを配信するための配信コンポーネント１３３１、外部ストレージシステム３０から電子ファイルを取得するための取得コンポーネント１３３２が含まれる。また、コンポーネント群１３３には、電子ファイルにＯＣＲ処理を行うためのＯＣＲコンポーネント１３３３、電子ファイルを印刷データに変換するための印刷変換コンポーネント１３３４が含まれる。
【００７１】
さらに、これらの各コンポーネントは、コンポーネント共通Ｉ／Ｆ１３３０を有する。コンポーネント共通Ｉ／Ｆ１３３０は、各コンポーネントに対して共通に定義されたＡＰＩであり、コンポーネントを生成するためのＡＰＩと、コンポーネントに対して処理の実行を要求するためのＡＰＩとが含まれる。このように、各コンポーネントがコンポーネント共通Ｉ／Ｆ１３３０を有するようにすることで、コンポーネントの追加等に伴う影響を局所化することができる。換言すれば、フロー実行部１３１及びコンポーネント管理部１３２に影響を与えることなく、コンポーネントの追加等を行うことができる。これにより、コンポーネントの追加等の開発に要する工数を削減することができる。
【００７２】
型変換管理部１３４は、データ型の型変換を管理する。ここで、各コンポーネントは、自身が扱えるデータ型が予め定まっている。したがって、型変換管理部１３４は、コンポーネントからの要求に応じて、図１２に示すような型変換テーブル３０００を参照して、型変換群１３５に定義されている型変換を生成する。そして、型変換管理部１３４は、生成された型変換に対して型変換処理の実行を要求する。ここで、型変換とは、データ型の型変換処理を実行するためのプログラム（モジュール）であり、例えばクラスや関数等で定義される。
【００７３】
なお、型変換の生成とは、例えばクラスで定義された型変換を、メモリ（例えばＲＡＭ１４）上に展開することを意味する。また、データ型には、例えば、ストリームデータを示すデータ型「InputStream」、記憶装置等に格納されている電子ファイルのパス（アドレス）を示す「LocalFilePath」、電子ファイルの実体を示す「File」等が挙げられる。
【００７４】
型変換群１３５は、型変換の集合である。型変換群１３５には、データ型「InputStream」を「LocalFilePath」に変換する第１の型変換１３５１、「LocalFilePath」を「File」に変換する第２の型変換１３５２等が含まれる。
【００７５】
さらに、これらの各型変換は、型変換共通Ｉ／Ｆ１３５０を有する。型変換共通Ｉ／Ｆ１３５０は、各型変換に対して共通に定義されたＡＰＩであり、型変換を生成するためのＡＰＩと、型変換に対して処理の実行を要求するためのＡＰＩとが含まれる。このように、各型変換が型変換共通Ｉ／Ｆ１３５０を有するようにすることで、型変換の追加等に伴う影響を局所化することができる。換言すれば、型変換管理部１３４に影響を与えることなく、コンポーネントの追加等を行うことができる。これにより、型変換の追加等の開発に要する工数を削減することができる。
【００７６】
続いて、図９のステップＳ９１０の処理の詳細について、図１３を用いて説明する。図１３は、第１の実施形態に係るＯＣＲから配信実行までの処理の一例のシーケンス図である。
【００７７】
まず、フロー実行部１３１は、ブラウザ２１０からスキャン配信サービスの処理の実行要求を受け付ける（ステップＳ１３０１）。ここで、当該実行要求には、アプリＩＤ「app001」と、図９のステップＳ９０８で生成された電子ファイルと、選択された保存先フォルダ「FolderB」のフォルダＩＤ（保存先）とが含まれる。ここで、当該電子ファイルは、データ型が「InputStream」（すなわち、ストリームデータ）としてブラウザ２１０から渡されるものとする。
【００７８】
フロー実行部１３１は、当該実行要求を受け付けると、アプリ管理部１２０に処理内容の取得を要求する（ステップＳ１３０２）。ここで、当該処理内容の取得要求には、アプリＩＤ「app001」が含まれる。そして、フロー実行部１３１は、アプリ管理部１２０からアプリＩＤ「app001」に対応するアプリ情報１０００１に含まれる処理内容を取得する。すなわち、フロー実行部１３１は、図８（ａ）に示す処理内容を取得する。
【００７９】
フロー実行部１３１は、取得した処理内容に従ってコンポーネントの取得を、コンポーネント管理部１３２に要求する（ステップＳ１３０３）。より具体的には、フロー実行部１３１は、図８（ａ）に示す処理内容の「From("file:input")」の次に指定されている「.to("process:ocr")」に基づき、ＯＣＲコンポーネント１３３３の取得を、コンポーネント管理部１３２に要求する。
【００８０】
コンポーネント管理部１３２は、ＯＣＲコンポーネント１３３３の取得要求を受け付けると、ＯＣＲコンポーネント１３３３を生成する（ステップＳ１３０４）。ＯＣＲコンポーネント１３３３の生成は、コンポーネント共通Ｉ／Ｆ１３３０に定義されたコンポーネントを生成するためのＡＰＩを用いて行うことができる。そして、ＯＣＲコンポーネント１３３３が生成されると、コンポーネント管理部１３２は、ＯＣＲコンポーネント１３３３をフロー実行部１３１に返却する。これは、例えば、コンポーネント管理部１３２は、ＯＣＲコンポーネント１３３３が展開されたメモリ（例えばＲＡＭ１４）上のアドレスを、フロー実行部１３１に返却する。
【００８１】
フロー実行部１３１は、生成されたＯＣＲコンポーネント１３３３に対して、データを指定して処理の実行を要求する（ステップＳ１３０５）。なお、ここで指定されるデータは、データ型が「InputStream」としてブラウザ２１０から渡される電子ファイルである。すなわち、フロー実行部１３１は、ブラウザ２１０からデータ型「InputStream」として渡される電子ファイルを、単に「データ」として（データ型を意識することなく）、ＯＣＲコンポーネント１３３３に渡して処理の実行を要求する。図１３では、このようにデータ型を意識することなく渡される電子ファイル等を、単に「データ」と表す。
【００８２】
ＯＣＲコンポーネント１３３３は、型変換管理部１３４に対して、型変換を要求する（ステップＳ１３０６）。ここで、当該型変換要求には、データと、ＯＣＲコンポーネント１３３３が扱うことができるデータ型を示す「LocalFilePath」の指定とが含まれる。
【００８３】
型変換管理部１３４は、受け取った型変換要求に含まれるデータのデータ型と、指定されたデータ型とが一致するか否かをチェックする（ステップＳ１３０７）。ここでは、受け取った型変換要求に含まれるデータのデータ型は「InputStream」である一方、指定されたデータ型は「LocalFilePath」であるから、一致しないものと判断される。
【００８４】
すると、型変換管理部１３４は、型変換テーブル３０００を参照して、「InputStream」を「LocalFilePath」に変換するための型変換を特定して（ここでは、第１の型変換１３５１が特定される）、当該特定された型変換を生成する（ステップＳ１３０８）。
【００８５】
そして、型変換管理部１３４は、生成された第１の型変換１３５１に対して、データを指定して型変換処理の実行を要求する（ステップＳ１３０９）。そして、第１の型変換１３５１は、指定されたデータのデータ型を「InputStream」から「LocalFilePath」に変換して（ステップＳ１３１０）、当該変換後のデータを型変換管理部１３４に返信する。その後、型変換管理部１３４は、型変換後のデータをＯＣＲコンポーネント１３３３に送信する（ステップＳ１３１１）。
【００８６】
ＯＣＲコンポーネント１３３３は、型変換後のデータを受け取ると、処理を実行する（ステップＳ１３１２）。すなわち、データ型「LocalFilePath」のデータ（すなわち、パス又はアドレス）により示される電子ファイルに対して、ＯＣＲ処理を実行する。ここで、より具体的には、ＯＣＲコンポーネント１３３３は、ドキュメントサービス部１５０のＯＣＲ処理１５１に処理を要求し、ＯＣＲ処理１５１が当該電子ファイルに対して処理を実行する。そして、ＯＣＲコンポーネント１３３３は、データをフロー実行部１３１に返信する。なお、ここで、返信されるデータは、ＯＣＲ処理後の電子ファイルを示すパス又はアドレスである（すなわち、返信されるデータのデータ型は「LocalFilePath」である。）。
【００８７】
次に、フロー実行部１３１は、取得した処理内容に従ってコンポーネントの取得を、コンポーネント管理部１３２に要求する（ステップＳ１３１３）。より具体的には、フロー実行部１３１は、図８（ａ）に示す処理内容の「.to("process:ocr")」の次に指定されている「.to("storage:send_to_folder?type=service-a")」に基づき、配信コンポーネント１３３１の取得を、コンポーネント管理部１３２に要求する。なお、ここで、指定されている処理内容のうち「?type=service-a」の部分はオプションパラメータであり、配信コンポーネント１３３１の処理によるデータのアップロード先のストレージサービスが「ストレージサービスＡ」であることを示している。また、ここで、上記の指定されている処理内容に、上記のステップＳ１３０１の実行要求に含まれる保存先（保存先フォルダのフォルダＩＤ）をオプションパラメータとして付加して「.to("storage:send_to_folder? type=service-a&targetfolder=folder_id_b")」としてもよい。同様に、ファイル名をオプションパラメータとしてさらに付加して「.to("storage:send_to_folder? type=service-a&targetfolder=folder_id_b&filename=test.pdf")」としてもよい。
【００８８】
コンポーネント管理部１３２は、配信コンポーネント１３３１の取得要求を受け付けると、配信コンポーネント１３３１を生成する（ステップＳ１３１４）。配信コンポーネント１３３１の生成は、コンポーネント共通Ｉ／Ｆ１３３０に定義されたコンポーネントを生成するためのＡＰＩを用いて行うことができる。そして、配信コンポーネント１３３１が生成されると、コンポーネント管理部１３２は、配信コンポーネント１３３１をフロー実行部１３１に返却する。これは、例えば、コンポーネント管理部１３２は、配信コンポーネント１３３１が展開されたメモリ（例えばＲＡＭ１４）上のアドレスを、フロー実行部１３１に返却する。
【００８９】
フロー実行部１３１は、生成された配信コンポーネント１３３１に対して、データを指定して処理の実行を要求する（ステップＳ１３１５）。なお、ここで指定されたデータのデータ型は「LocalFilePath」である。
【００９０】
配信コンポーネント１３３１は、型変換管理部１３４に対して、型変換を要求する（ステップＳ１３１６）。ここで、当該型変換要求には、データと、配信コンポーネント１３３１が扱うことができるデータ型を示す「LocalFilePath」の指定とが含まれる。
【００９１】
型変換管理部１３４は、受け取った型変換要求に含まれるデータのデータ型と、指定されたデータ型とが一致するか否かをチェックする（ステップＳ１３１７）。ここでは、受け取った型変換要求に含まれるデータのデータ型は「LocalFilePath」であり、指定されたデータ型も「LocalFilePath」であるから、一致するものと判断される。そして、型変換管理部１３４は、型変換要求に含まれていたデータを、そのまま配信コンポーネント１３３１に送信する（ステップＳ１３１８）。このように、データ型チェック（ステップＳ１３１７の処理）で両者のデータ型が一致する場合には、型変換管理部１３４は型変換の生成を行わない。
【００９２】
配信コンポーネント１３３１は、型変換管理部１３４からデータを受け取ると、処理を実行する（ステップＳ１３１９）。すなわち、本実施形態では、配信コンポーネント１３３１は、ストレージサービスＡ連携部１６０１のファイル処理部１７０１に対して、共通Ｉ／Ｆ１７１１として定義されているファイル保存のＡＰＩを用いて、データの配信実行を要求する。より具体的には、配信コンポーネント１３３１は、ストレージサービスＡ連携部１６０１のファイル処理部１７０１に対して、図５（ａ）に示されるようにＡＰＩとして「service-a/process/folder」を用いてデータの配信実行を要求する。これにより、ストレージサービスＡのフォルダ「FolderB」に、ファイル名「test」の電子ファイル（スキャンにより生成された電子ファイルに対してＯＣＲ処理した電子ファイル）が保存される。そして、処理結果がフロー実行部１３１を介して、ブラウザ２１０に送信される。
【００９３】
≪クラウドプリントサービスの全体処理≫
次に、画像形成装置２０のユーザが本実施形態に係るクラウドプリントサービスを利用する場合の全体的な処理について説明する。図１４は、第１の実施形態に係るクラウドプリントサービスの全体処理の一例のシーケンス図である。
【００９４】
まず、画像形成装置２０のユーザは、ブラウザ２１０を用いて、サービス提供システム１０により提供されるサービスの一覧を取得するための操作を行う。すると、画像形成装置２０は、サービスの一覧の取得要求をサービス提供システム１０のサービス処理部１１０に送信する（ステップＳ１４０１）。そして、サービス処理部１１０のアプリ管理部１２０は、当該取得要求を受信すると、サービス提供システム１０により提供されるサービスの一覧を画像形成装置２０に送信する。
【００９５】
ユーザは、画像形成装置２０の操作パネル２２に表示されたサービスの一覧から、自身が利用を所望するサービスを選択する。すると、ブラウザ２１０は、選択されたサービスを実現するためのアプリ情報１０００のアプリＩＤをアプリ管理部１２０に送信する（ステップＳ１４０２）。ここでは、ユーザによりサービス名「クラウドプリントサービス」の利用が選択されたものとする。したがって、ブラウザ２１０は、アプリ情報１０００２のアプリＩＤ「app002」をアプリ管理部１２０に送信する。
【００９６】
そして、アプリ管理部１２０は、ブラウザ２１０から受け取ったアプリＩＤ「app002」のアプリ情報１０００２に含まれる画面定義に基づきＨＴＭＬ形式のアプリ画面を生成し、ブラウザ２１０に送信する。
【００９７】
ブラウザ２１０は、アプリ管理部１２０からアプリ画面を受け取ると、表示用情報の取得をデータＩ／Ｆ部１４０に要求する（ステップＳ１４０３）。本実施形態では、ブラウザ２１０は、クラウドプリントサービスを用いた印刷対象の候補となるストレージサービスＡの電子ファイルの一覧の取得を、データＩ／Ｆ部１４０に要求する。このような要求は、図６（ｂ）のデータ定義部１２０１に記述されている「"data_source"」に定義されているＵＲＬ「http://sample.xxx.co.jp/service-a/data/files」にＨＴＴＰリクエストを送信することで行うことができる。
【００９８】
次に、データＩ／Ｆ部１４０は、ブラウザ２１０から表示用情報の取得要求を受け付けると、当該要求を対応するストレージサービス連携部１６０のデータ処理部１８０に送信する（ステップＳ１４０４）。
【００９９】
データ処理部１８０は、データＩ／Ｆ部１４０から要求を受け付けると、当該要求に含まれるＵＲＬに基づき、対応する処理要求を外部ストレージシステム３０に送信する（ステップＳ１４０５）。本実施形態では、データ処理部１８０は、上記のＵＲＬに含まれる「/service-a/data/files」に基づき、ストレージサービスＡにファイル一覧の取得を要求する。すると、ブラウザ２１０は、ストレージサービスＡ連携部１６０１を介して、ファイル一覧を受信する。ファイル一覧は、本実施形態のクラウドプリントサービスにおいて、印刷対象の候補となるストレージサービスＡに保存されている電子ファイルのファイル名及びファイルＩＤ等の情報である。
【０１００】
次に、ブラウザ２１０は、ステップＳ１４０２でアプリ管理部１２０から受け取ったアプリ画面及びファイル一覧に基づき、例えば図１５（ａ）に示すようなアプリ画面４０００を、操作パネル２２に表示させる（ステップＳ１４０６）。
【０１０１】
ここで、図１５（ａ）で示すクラウドプリントサービスを利用するためのアプリ画面４０００は、印刷対象のファイルを選択するためのファイル選択欄４００１と、プリント実行ボタン４００２とから構成されている。このうち、ファイル選択欄４００１は、図１５（ｂ）に示すように、ＨＴＭＬソースコード４１０１で記述されている。このようなＨＴＭＬソースコード４１０１は、アプリ管理部１２０により、図６（ｂ）に示すデータ定義部１２０１及び図７（ｂ）に示すレイアウト定義部１４０１に基づいて生成される。ただし、ＨＴＭＬソースコード４１０１に指定されている「option」の設定値は、外部ストレージシステム３０から取得したファイル一覧に基づき、ブラウザ２１０で設定される。
【０１０２】
次に、ユーザは、図１５（ａ）のアプリ画面４０００のファイル選択欄４００１から所望のファイルを選択して、プリント実行ボタン４００２を押下する（ステップＳ１４０７）。ここで、ユーザはファイル選択欄４００１から「FileA」を選択して、プリント実行ボタン４００２を押下したものとする。
【０１０３】
すると、ブラウザ２１０は、クラウドプリントサービスの処理の実行要求をロジック処理部１３０に送信する（ステップＳ１４０８）。ここで、当該実行要求には、アプリＩＤ「app002」と、ファイル選択欄４００１から選択されたファイル「FileA」のファイルＩＤ「file_id_a」とが含まれる。
【０１０４】
そして、ロジック処理部１３０は、処理の実行要求を受け付けると、アプリ管理部１２０を介して、当該処理の実行要求に含まれるアプリＩＤのアプリ情報１０００から処理内容を取得し、当該処理内容に従って処理を実行する（ステップＳ１４０９）。すなわち、本実施形態に係るクラウドプリントサービスでは、ストレージサービスＡから印刷対象の電子ファイルを取得（ダウンロード）した後、当該電子ファイルを画像形成装置２０が印刷可能な印刷データに変換（印刷変換）する。このステップＳ１４０９の処理の詳細については、後述する。ここでは、ロジック処理部１３０は、ファイル「FileA」のファイルＩＤ「file_id_a」を含むファイル取得実行の要求を、ストレージサービスＡ連携部１６０１のファイル処理部１７０１に送信したものとして説明を続ける。
【０１０５】
ファイル処理部１７０は、ロジック処理部１３０からファイル取得実行の要求を受け付けると、共通Ｉ／Ｆ１７１又は固有Ｉ／Ｆ１７２に定義されているＡＰＩを利用して、該当の外部ストレージシステム３０に処理を要求する（ステップＳ１４１０）。具体的には、本実施形態では、ファイル処理部１７０１の共通Ｉ／Ｆ１７１１に定義されているストレージサービスＡにファイルを取得するためのＡＰＩ「/service-a/process/file」を用いて、ファイル「FileA」を取得（ダウンロード）する。そして、ロジック処理部１３０は、取得したファイル「FileA」を、画像形成装置２０で印刷可能なデータ形式である印刷データに変換した後、画像形成装置２０に送信する。
【０１０６】
画像形成装置２０のプリンタ２５は、ロジック処理部１３０から印刷データを受け取ると、当該印刷データを印刷する（ステップS１４１１）。これにより、本実施形態に係るクラウドプリントサービスが完了する。
【０１０７】
≪ファイル取得実行から印刷変換までの処理≫
次に、図１４のステップＳ１４０９の処理の詳細について説明する。図１６は、第１の実施形態に係るファイル取得から印刷変換までの処理の一例のシーケンス図である。
【０１０８】
まず、フロー実行部１３１は、ブラウザ２１０からクラウドプリントサービスの処理の実行要求を受け付ける（ステップＳ１６０１）。ここで、当該実行要求には、アプリＩＤ「app002」と、選択された印刷対象のファイルのファイルＩＤ「file_id_a」とが含まれる。ここで、当該ファイルＩＤは、データ型が「InputStream」（すなわち、ストリームデータ）としてブラウザ２１０から渡されるものとする。
【０１０９】
フロー実行部１３１は、当該実行要求を受け付けると、アプリ管理部１２０に処理内容の取得を要求する（ステップＳ１６０２）。ここで、当該処理内容の取得要求には、アプリＩＤ「app002」が含まれる。そして、フロー実行部１３１は、アプリ管理部１２０からアプリＩＤ「app002」に対応するアプリ情報１０００２に含まれる処理内容を取得する。すなわち、フロー実行部１３１は、図８（ｂ）に示す処理内容を取得する。
【０１１０】
フロー実行部１３１は、取得した処理内容に従ってコンポーネントの取得を、コンポーネント管理部１３２に要求する（ステップＳ１６０３）。より具体的には、フロー実行部１３１は、図８（ｂ）に示す処理内容の「From("file:input")」の次に指定されている「.to("storage:receive_file?type=service-a")」に基づき、取得コンポーネント１３３２の取得を、コンポーネント管理部１３２に要求する。なお、ここで、指定されている処理内容のうち「?type=service-a」の部分はオプションパラメータであり、取得コンポーネント１３３２の処理の電子ファイルの取得（ダウンロード）先ストレージサービスが「ストレージサービスＡ」であることを示している。また、ここで、上記の指定されている処理内容に、上記のステップＳ１６０１の実行要求に含まれる印刷対象のファイルである「FileA」のファイルＩＤをオプションパラメータとして付加して「.to("storage:receive_file?type=service-a&targetfile=file_id_a")」としてもよい。
【０１１１】
コンポーネント管理部１３２は、取得コンポーネント１３３２の取得要求を受け付けると、取得コンポーネント１３３２を生成する（ステップＳ１６０４）。取得コンポーネント１３３２の生成は、コンポーネント共通Ｉ／Ｆ１３３０に定義されたコンポーネントを生成するためのＡＰＩを用いて行うことができる。そして、取得コンポーネント１３３２が生成されると、コンポーネント管理部１３２は、取得コンポーネント１３３２をフロー実行部１３１に返却する。これは、例えば、コンポーネント管理部１３２は、ＯＣＲコンポーネント１３３３が展開されたメモリ（例えばＲＡＭ１４）上のアドレスを、フロー実行部１３１に返却する。
【０１１２】
フロー実行部１３１は、生成された取得コンポーネント１３３２に対して、データを指定して処理の実行を要求する（ステップＳ１６０５）。なお、ここで指定されるデータは、データ型が「InputStream」としてブラウザ２１０から渡された、印刷対象のファイルのファイルＩＤである。すなわち、フロー実行部１３１は、ブラウザ２１０からデータ型「InputStream」として渡されるファイルＩＤを、単に「データ」として（データ型を意識することなく）、取得コンポーネント１３３２に渡して処理の実行を要求する。図１６では、このようにデータ型を意識することなく渡されるファイルＩＤや電子ファイル等を、単に「データ」と表す。
【０１１３】
取得コンポーネント１３３２は、型変換管理部１３４に対して、型変換を要求する（ステップＳ１６０６）。ここで、当該型変換要求には、データと、取得コンポーネント１３３２が扱うことができるデータ型を示す「LocalFilePath」の指定とが含まれる。
【０１１４】
型変換管理部１３４は、受け取った型変換要求に含まれるデータのデータ型と、指定されたデータ型とが一致するか否かをチェックする（ステップＳ１６０７）。ここでは、受け取った型変換要求に含まれるデータのデータ型は「InputStream」である一方、指定されたデータ型は「LocalFilePath」であるから、一致しないものと判断される。
【０１１５】
すると、型変換管理部１３４は、型変換テーブル３０００を参照して、「InputStream」を「LocalFilePath」に変換するための型変換を特定して（ここでは、第１の型変換１３５１が特定される）、当該特定された型変換を生成する（ステップＳ１６０８）。
【０１１６】
そして、型変換管理部１３４は、生成された第１の型変換１３５１に対して、データを指定して型変換処理の実行を要求する（ステップＳ１６０９）。そして、第１の型変換１３５１は、指定されたデータのデータ型を「InputStream」から「LocalFilePath」に変換して（ステップＳ１６１０）、当該変換後のデータを型変換管理部１３４に返信する。その後、型変換管理部１３４は、型変換後のデータを取得コンポーネント１３３２に送信する（ステップＳ１６１１）。
【０１１７】
取得コンポーネント１３３２は、型変換後のデータを受け取ると、処理を実行する（ステップＳ１６１２）。すなわち、本実施形態では、取得コンポーネント１３３２は、ストレージサービスＡ連携部１６０１のファイル処理部１７０１に対して、共通Ｉ／Ｆ１７１１として定義されているファイル取得のＡＰＩを用いて、ファイル取得実行を要求する。より具体的には、取得コンポーネント１３３２は、ストレージサービスＡ連携部１６０１のファイル処理部１７０１に対して、図５（ａ）に示されるようにＡＰＩとして「service-a/process/file」を用いてファイル取得の実行を要求する。これにより、ストレージサービスＡからファイルＩＤ「file_id_a」の電子ファイルが取得（ダウンロード）される。取得コンポーネント１３３２により取得された電子ファイルは、データとしてフロー実行部１３１に送信される。
【０１１８】
次に、フロー実行部１３１は、取得した処理内容に従ってコンポーネントの取得を、コンポーネント管理部１３２に要求する（ステップＳ１６１３）。より具体的には、フロー実行部１３１は、図８（ｂ）に示す処理内容の「.to("storage:receive_file? type=service-a")」の次に指定されている「.to("process:conv")」に基づき、印刷変換コンポーネント１３３４の取得を、コンポーネント管理部１３２に要求する。
【０１１９】
コンポーネント管理部１３２は、印刷変換コンポーネント１３３４の取得要求を受け付けると、印刷変換コンポーネント１３３４を生成する（ステップＳ１６１４）。印刷変換コンポーネント１３３４の生成は、コンポーネント共通Ｉ／Ｆ１３３０に定義されたコンポーネントを生成するためのＡＰＩを用いて行うことができる。そして、印刷変換コンポーネント１３３４が生成されると、コンポーネント管理部１３２は、印刷変換コンポーネント１３３４をフロー実行部１３１に返却する。これは、例えば、コンポーネント管理部１３２は、印刷変換コンポーネント１３３４が展開されたメモリ（例えばＲＡＭ１４）上のアドレスを、フロー実行部１３１に返却する。
【０１２０】
フロー実行部１３１は、生成された印刷変換コンポーネント１３３４に対して、データを指定して処理の実行を要求する（ステップＳ１６１５）。なお、ここで指定されたデータのデータ型は「LocalFilePath」である。
【０１２１】
印刷変換コンポーネント１３３４は、型変換管理部１３４に対して、型変換を要求する（ステップＳ１６１６）。ここで、当該型変換要求には、データと、印刷変換コンポーネント１３３４が扱うことができるデータ型を示す「File」の指定とが含まれる。
【０１２２】
型変換管理部１３４は、受け取った型変換要求に含まれるデータのデータ型と、指定されたデータ型とが一致するか否かをチェックする（ステップＳ１６１７）。ここでは、受け取った型変換要求に含まれるデータのデータ型は「LocalFilePath」である一方、指定されたデータ型は「File」であるから、一致しないものと判断される。
【０１２３】
すると、型変換管理部１３４は、型変換テーブル３０００を参照して、「LocalFilePath」を「File」に変換するための型変換を特定して（ここでは、第２の型変換１３５２が特定される）、当該特定された型変換を生成する（ステップＳ１６１８）。
【０１２４】
そして、型変換管理部１３４は、生成された第２の型変換１３５２に対して、データを指定して型変換処理の実行を要求する（ステップＳ１６１９）。そして、第２の型変換１３５２は、指定されたデータのデータ型を「LocalFilePath」から「File」に変換して（ステップＳ１６２０）、当該変換後のデータを型変換管理部１３４に返信する。その後、型変換管理部１３４は、型変換後のデータを印刷変換コンポーネント１３３４に送信する（ステップＳ１６２１）。
【０１２５】
印刷変換コンポーネント１３３４は、型変換後のデータを受け取ると、処理を実行する（ステップＳ１６２２）。すなわち、データ型「File」のデータ（すなわち、電子ファイル）を、画像形成装置２０が印刷可能なデータ形式である印刷データに変換する処理を実行する。ここで、より具体的には、印刷変換コンポーネント１３３４は、ドキュメントサービス部１５０の印刷変換処理１５２に処理を要求し、印刷変換処理１５２がデータ（電子ファイル）に対して処理を実行する。そして、印刷変換コンポーネント１３３４は、フロー実行部１３１を介して、印刷データを画像形成装置２０に返信する。
【０１２６】
［第２の実施形態］
次に、第２の実施形態に係る情報処理システム１について説明する。第２の実施形態に係る情報処理システム１に含まれるサービス提供システム１０は、ブラウザ２１０が搭載されていない画像形成装置２０からの要求も受け付ける点が第１の実施形態と異なる。なお、以降では、第１の実施形態と実質的に同一の機能を有する箇所及び同一の処理を行う箇所については、第１の実施形態と同一の符号を用いて、その説明を省略する。
【０１２７】
＜ソフトウェア構成＞
第２の実施形態に係る情報処理システム１は、例えば図１７に示されるような処理ブロックにより実現することができる。図１７は、第２の実施形態に係る情報処理システムの一例の処理ブロック図である。
【０１２８】
画像形成装置２０は、例えばＣＰＵ２１１等により実現されるブラウザ２１０又はクライアントアプリケーション２２０を有する。ここで、ブラウザ２１０はＨＴＭＬを解釈できる一方で、クライアントアプリケーション２２０はＨＴＭＬを解釈することができないものとする。したがって、本実施形態に係るクライアントアプリケーション２２０は、サービス提供システム１０から受け取ったデータ定義に基づきアプリ画面を生成して、表示させる。
【０１２９】
サービス提供システム１０は、アプリ管理部１２０Ａの機能が異なる点、及び、さらに要求判断部１２１を有する点が第１の実施形態と異なる。
【０１３０】
要求判断部１２１は、画像形成装置２０から受け取った情報に基づき、送信元がブラウザ２１０か又はクライアントアプリケーション２２０かを判断する。
【０１３１】
アプリ管理部１２０Ａは、要求判断部１２１の判断結果に応じて、画像形成装置２０に対してアプリ画面又はデータ定義を返信する。すなわち、アプリ管理部１２０Ａは、要求判断部１２１により送信元がクライアントアプリケーション２２０であると判断された場合は、当該画像形成装置２０に対して、データ定義を返信する。
【０１３２】
＜処理の詳細＞
次に、第２の実施形態に係る情報処理システム１の処理の詳細について説明する。第２の実施形態では、図９を用いて説明したスキャン配信サービスの全体処理及び図１４を用いて説明したクラウドプリントサービスの全体処理において、画像形成装置２０にアプリ画面を表示させるまでの処理が異なる。したがって、第２の実施形態では、サービス一覧の取得からアプリ画面の表示までの処理について説明する。図１８は、第２の実施形態に係るアプリ画面の表示処理の一例のシーケンス図である。
【０１３３】
まず、画像形成装置２０のユーザは、ブラウザ２１０又はクライアントアプリケーション２２０を用いて、サービス提供システム１０により提供されるサービスの一覧を取得するための操作を行う（ステップＳ１８０１）。すると、サービス処理部１１０の要求判断部１２１は、サービス提供システム１０により提供されるサービスの一覧を、アプリ管理部１２０Ａから取得して（ステップＳ１８０２）、画像形成装置２０に送信する。これにより、画像形成装置２０の操作パネル２２には、サービス提供システム１０により提供されるサービスの一覧が表示される。
【０１３４】
ユーザは、画像形成装置２０の操作パネル２２に表示されたサービスの一覧から自身が利用を所望するサービスを選択する。すると、ブラウザ２１０又はクライアントアプリケーション２２０は、選択されたサービスを実現するためのアプリ情報１０００のアプリＩＤを要求判断部１２１に送信する（ステップＳ１８０３）。
【０１３５】
すると、要求判断部１２１は、送信元がブラウザ２１０か又はクライアントアプリケーション２２０かを判断する（ステップＳ１８０４）。これは、要求判断部１２１は、例えば、Ｕｓｅｒ  Ａｇｅｎｔに基づき判断することができる。以降では、要求判断部１２１により送信元がブラウザ２１０であると判断された場合、ステップＳ１８０５の処理が実行される一方、送信元がクライアントアプリケーション２２０であると判断された場合、ステップＳ１８０６及びＳ１８０７の処理が実行される。
【０１３６】
要求判断部１２１により送信元がブラウザ２１０であると判断された場合、要求判断部１２１は、アプリ管理部１２０Ａに対してＨＴＭＬのアプリ画面の取得を要求する（ステップＳ１８０５）。なお、当該要求には、上記のステップＳ１８０３で選択されたサービスを実現するためのアプリ情報１０００のアプリＩＤが含まれる。すると、アプリ管理部１２１Ａは、当該要求に含まれるアプリＩＤのアプリ情報１０００に含まれる画面定義に基づきＨＴＭＬ形式のアプリ画面を生成し、要求判断部１２１を介して、ブラウザ２１０に送信する。
【０１３７】
一方、送信元がクライアントアプリケーション２２０であると判断された場合、要求判断部１２１は、アプリ管理部１２０Ａに対してＪＳＯＮ（JavaScript Object Notation）形式等の汎用的なデータ形式でデータ定義の取得を要求する（ステップＳ１８０６）。なお、当該要求には、上記のステップＳ１８０３で選択されたサービスを実現するためのアプリ情報１０００のアプリＩＤが含まれる。すると、アプリ管理部１２１Ａは、当該要求に含まれるアプリＩＤのアプリ情報１０００に含まれるデータ定義を、要求判断部１２１を介して、ＪＳＯＮ形式でクライアントアプリケーション２２０に送信する。このように、画像形成装置２０にＨＴＭＬを解釈することができないクライアントアプリケーション２２０が搭載されている場合、サービス提供システム１０は、画面定義に含まれるデータ定義のみを返信する。そして、画像形成装置２０のクライアントアプリケーション２２０は、受け取ったＪＳＯＮ形式のデータ定義に基づき、アプリ画面を生成する（ステップＳ１８０７）。
【０１３８】
そして、画像形成装置２０は、操作パネル２２にアプリ画面を表示させる（ステップＳ１８０８）。ここで、画像形成装置２０にブラウザ２１０が搭載されている場合は、上記のステップＳ１８０５で受け取ったＨＴＭＬ形式のアプリ画面を表示させる。一方、画像形成装置２０にクライアントアプリケーション２２０が搭載されている場合は、上記のステップＳ１８０７で生成したアプリ画面を表示させる。このようにすることで、画像形成装置２０には必ずしもブラウザ２１０が搭載されている必要はなくなる。したがって、ユーザは、画像形成装置２０に、サービス提供システム１０により提供されるサービスを利用するための任意のクライアントアプリケーション２２０を搭載させることができる。
【０１３９】
［第３の実施形態］
次に、第３の実施形態に係る情報処理システム１について説明する。第３の実施形態に係る情報処理システム１は、サードベンダー等により開発されたコンポーネントを用いた処理内容により実現されるサービスを提供できる点が第１の実施形態と異なる。また、第３の実施形態に係る情報処理システム１は、画像形成装置２０のブラウザ２１０を用いて、ユーザが処理内容を作成することができる点が第１の実施形態と異なる。
【０１４０】
なお、以降では、サードベンダー等により開発されたコンポーネントを「外部コンポーネント」、サービス提供システム１０に予め組み込まれているコンポーネント（すなわち、第１の実施形態及び第２の実施形態で説明したコンポーネント）を「内部コンポーネント」と表して区別する。さらに、内部コンポーネントと外部コンポーネントとを区別しないときは、単に、「コンポーネント」と表す。
【０１４１】
また、以降では、第１の実施形態と実質的に同一の機能を有する箇所及び同一の処理を行う箇所については、第１の実施形態と同一の符号を用いて、その説明を省略する。
【０１４２】
＜システム構成＞
図１９は、第３の実施形態に係る情報処理システムの一例の構成図である。図１９に示される情報処理システム１のサービス提供環境Ｅ１は、外部コンポーネント管理装置４０を含む。
【０１４３】
外部コンポーネント管理装置４０は、一台以上の情報処理装置で実現され、外部コンポーネントを管理する。このように、本実施形態に係る情報処理システム１では、サービス提供システム１０とは異なる装置である外部コンポーネント管理装置４０において外部コンポーネントを管理する。このため、例えば、外部コンポーネントが重大なバグを有していた場合等における影響を外部コンポーネント管理装置４０に局所化させることができる。
【０１４４】
なお、図１９では、サービス提供環境Ｅ１に一の外部コンポーネント管理装置４０が含まれる例を示したが、これに限られない。サービス提供環境Ｅ１には、複数の外部コンポーネント管理装置４０が含まれていてもよい。例えば、サービス提供環境Ｅ１には、Ａ社が開発した外部コンポーネントを管理する外部コンポーネント管理装置４０１、Ｂ社が開発した外部コンポーネントを管理する外部コンポーネント管理装置４０２等が含まれていてもよい。
【０１４５】
＜ソフトウェア構成＞
第１の実施形態に係る情報処理システム１は、例えば図２０に示されるような処理ブロックにより実現することができる。図２０は、第３の実施形態に係る情報処理システムの一例の処理ブロック図である。
【０１４６】
サービス提供システム１０のサービス処理部１１０は、アプリ管理部１２０Ａと、ロジック処理部１３０Ａと、処理内容作成部１２２とを有する。
【０１４７】
処理内容作成部１２２は、ブラウザ２１０からの要求に応じて、処理内容を作成するための画面（処理内容の作成画面）を作成する。
【０１４８】
アプリ管理部１２０Ａは、処理内容作成部１２２からの要求に応じて、処理内容の作成画面において作成された処理内容をアプリ情報記憶部１９０に記憶させる。これにより、ユーザが作成した処理内容により示される一連の処理で実現されるサービスが追加される。
【０１４９】
ロジック処理部１３０Ａは、アプリ管理部１２０Ａから取得した処理内容により示される一連の処理において、外部コンポーネントにより実行される処理がある場合、当該処理の実行を外部コンポーネント処理部４１０に要求する。なお、ロジック処理部１３０Ａの詳細な処理ブロックについては後述する。
【０１５０】
外部コンポーネント管理装置４０は、外部コンポーネント処理部４１０を有する。外部コンポーネント処理部４１は、例えば、外部コンポーネント管理装置４０が備えるＣＰＵにより実現される。
【０１５１】
外部コンポーネント処理部４１０は、ロジック処理部１３０Ａからの要求に応じて、外部コンポーネントを実行する。なお、外部コンポーネント処理部４１０の詳細な処理ブロックについては後述する。
【０１５２】
次に、本実施形態に係るロジック処理部１３０Ａの詳細な処理ブロックについて説明する。図２１は、第３の実施形態に係るロジック処理部の一例の処理ブロック図である。
【０１５３】
本実施形態に係るロジック処理部１３０Ａは、フロー実行部１３１Ａと、コンポーネント管理部１３２Ａとを有する。また、本実施形態に係るロジック処理部１３０Ａのコンポーネント群１３３には、外部コンポ連携コンポーネント１３３５が含まれる。さらに、本実施形態に係るロジック処理部１３０Ａは、コンポーネント管理テーブル５０００を利用する。
【０１５４】
フロー実行部１３１Ａは、アプリ管理部１２０Ａから取得した処理内容に従ってコンポーネントの取得をコンポーネント管理部１３２Ａに要求する。このとき、フロー実行部１３１Ａは、処理内容に基づいて、後述するコンポーネント名を指定して、コンポーネントの取得を要求する。
【０１５５】
コンポーネント管理部１３２Ａは、フロー実行部１３１Ａからの要求に応じて、コンポーネント管理テーブル５０００を参照し、当該要求に係るコンポーネントが内部コンポーネント又は外部コンポーネントのいずれであるかを判定する。そして、コンポーネント管理部１３２Ａは、当該要求に係るコンポーネントが外部コンポーネントである場合、外部コンポ連携コンポーネント１３３５を生成する。
【０１５６】
コンポーネント群１３３に含まれる外部コンポ連携コンポーネント１３３５は、外部コンポーネント管理装置４０の外部コンポーネント処理部４１０と処理の連携を行うためのコンポーネントである。外部コンポ連携コンポーネント１３３５は、外部コンポーネント処理部４１０に対して、外部コンポーネントの処理の実行を要求する。なお、外部コンポ連携コンポーネント１３３５は、コンポーネント共通Ｉ／Ｆ１３３０を有する。
【０１５７】
ここで、コンポーネント管理テーブル５０００は、図２２に示すようなデータ項目を有している。図２２は、コンポーネント管理テーブルの一例を説明するための図である。
【０１５８】
図２２に示すコンポーネント管理テーブル５０００は、データ項目として、コンポーネントＩＤと、コンポーネント名と、ホスト名とを有する。コンポーネントＩＤは、コンポーネントを一意に識別する識別情報である。コンポーネント名は、コンポーネントの名称である。なお、本実施形態では、コンポーネント名は、コンポーネントに対して一意に付与されているものとする。
【０１５９】
ホスト名は、コンポーネントを管理している装置を識別する情報である。すなわち、例えば、内部コンポーネントには、ホスト名「localhost」が関連付けられており、サービス提供システム１０で管理されていることが示されている。一方、例えば、外部コンポーネントには、ホスト名「server2.com」が関連付けられており、当該ホスト名の外部コンポーネント管理装置４０で管理されていることが示されている。
【０１６０】
このように、コンポーネント管理テーブル５０００では、コンポーネント毎に、当該コンポーネントが管理されている装置のホスト名が関連付けられている。なお、処理内容作成部１２２は、コンポーネント管理テーブル５０００からコンポーネントの一覧を取得することで、処理内容の作成画面を作成する。
【０１６１】
次に、外部コンポーネント処理部４１０の詳細な処理ブロックについて説明する。図２３は、第３の実施形態に係る外部コンポーネント処理部の一例の処理ブロック図である。
【０１６２】
外部コンポーネント処理部４１０は、要求受付部４１１と、コンポーネント管理部４１２と、外部コンポーネント群４１３と、型変換管理部４１４と、型変換群４１５とを有する。また、外部コンポーネント処理部４１０は、型変換テーブル６０００を利用する。
【０１６３】
要求受付部４１１は、ロジック処理部１３０Ａからの要求を受け付けると、コンポーネント管理部４１２に対して、外部コンポーネントの生成を要求する。そして、要求受付部４１１は、外部コンポーネントが生成されると、当該外部コンポーネントに対して処理の実行を要求する。
【０１６４】
コンポーネント管理部４１２は、要求受付部４１１からの要求に応じて、外部コンポーネントの生成を行う。
【０１６５】
外部コンポーネント群４１３は、外部コンポーネントの集合である。外部コンポーネント群４１３には、サードベンダー等により開発された各種の外部コンポーネントが含まれる。例えば、外部コンポーネント群４１３には、外部ストレージシステム３０に電子ファイルを配信するための配信αコンポーネント４１３１、電子ファイルを印刷データに変換するための印刷変換βコンポーネント４１３２が含まれる。
【０１６６】
また、これらの各外部コンポーネントは、コンポーネント共通Ｉ／Ｆ４１３０を有する。コンポーネント共通Ｉ／Ｆ４１３０は、各外部コンポーネントに対して共通に定義されたＡＰＩであり、外部コンポーネントを生成するためのＡＰＩと、外部コンポーネントに対して処理の実行を要求するためのＡＰＩとが含まれる。
【０１６７】
型変換管理部４１４は、データ型の型変換を管理する。ここで、外部コンポーネントは、自身が扱えるデータ型が予め定まっている。したがって、型変換管理部４１４は、外部コンポーネントからの要求に応じて、図２４に示すような型変換テーブル６０００を参照して、型変換群４１５に定義されている型変換を生成する。そして、型変換管理部４１４は、生成された型変換に対して型変換処理の実行を要求する。
【０１６８】
型変換群４１５は、型変換の集合である。型変換群４１５には、データ型「InputStream」を「LocalFilePath」に変換する第１の型変換４１５１、「LocalFilePath」を「File」に変換する第２の型変換４１４２等が含まれる。
【０１６９】
また、これらの各型変換は、型変換共通Ｉ／Ｆ４１５０を有する。型変換共通Ｉ／Ｆ４１５０は、各型変換に対して共通に定義されたＡＰＩであり、型変換を生成するためのＡＰＩと、型変換に対して処理の実行を要求するためのＡＰＩとが含まれる。
【０１７０】
＜処理の詳細＞
次に、本実施形態に係る情報処理システム１の処理の詳細について説明する。本実施形態では、スキャン配信サービスを実現する一連の処理に、外部コンポーネントにより実行される処理が含まれる場合について説明する。すなわち、本実施形態に係るスキャン配信サービスは、内部コンポーネントにより実行される処理と、外部コンポーネントにより実行される処理とで構成される一連の処理により実現されるものとする。
【０１７１】
≪ＯＣＲから配信実行までの処理≫
図２５は、第３の実施形態に係るＯＣＲから配信実行までの処理の一例のシーケンス図である。まず、ステップＳ２５０１の処理は、図１３を用いて説明したステップＳ１３０１の処理と同様であるため、その説明を省略する。
【０１７２】
フロー実行部１３１Ａは、ブラウザ２１０からスキャン配信サービスの実行要求を受け付けると、アプリ管理部１２０Ａに処理内容の取得を要求する（ステップＳ２５０２）。ここで、本実施形態では、フロー実行部１３１Ａにより、図２６に示す処理内容が取得されたものとする。
【０１７３】
フロー実行部１３１Ａは、取得した処理内容に従ってコンポーネントの取得を、コンポーネント管理部１３２Ａに要求する（ステップＳ２５０３）。より具体的には、フロー実行部１３１は、図２６に示す処理内容の「From("file:input")」の次に指定されている「.to("process:ocr")」に基づき、コンポーネント名が「ocr」であるコンポーネントの取得を、コンポーネント管理部１３２Ａに要求する。
【０１７４】
コンポーネント管理部１３２Ａは、コンポーネントの取得要求を受け付けると、コンポーネント管理テーブル５０００を参照して、当該取得要求に係るコンポーネントが内部コンポーネント又は外部コンポーネントのいずれであるかを判定する（ステップＳ２５０４）。
【０１７５】
すなわち、コンポーネント管理部１３２Ａは、コンポーネント管理テーブル５０００において、当該取得要求に含まれるコンポーネント名に関連付けられているホスト名が「localhost」であるか否かを判定する。そして、コンポーネント管理部１３２Ａは、当該ホスト名が「localhost」である場合、当該取得要求に係るコンポーネントは内部コンポーネントであると判定する。一方、コンポーネント管理部１３２Ａは、当該ホスト名が「localhost」でない場合、当該取得要求に係るコンポーネントは外部コンポーネントであると判定する。
【０１７６】
ここで、コンポーネント管理テーブル５０００において、コンポーネント名「ocr」に関連付けられているホスト名は「localhost」である。したがって、コンポーネント管理部１３２Ａは、当該取得要求に係るコンポーネントは内部コンポーネントであると判定する。
【０１７７】
コンポーネント管理部１３２Ａは、コンポーネントの取得要求に係るコンポーネントが内部コンポーネントであると判定された場合、当該取得要求に含まれるコンポーネント名に対応する内部コンポーネントを生成する（ステップＳ２５０５）。すなわち、コンポーネント管理部１３２Ａは、当該取得要求に含まれるコンポーネント名「ocr」に対応するＯＣＲコンポーネント１３３３を生成する。
【０１７８】
そして、コンポーネント管理部１３２Ａは、生成されたＯＣＲコンポーネント１３３３をフロー実行部１３１Ａに返却する。
【０１７９】
続くステップＳ２５０６〜ステップＳ２５１３の処理は、図１３を用いて説明したステップＳ１３０５〜ステップＳ１３１２の処理と同様であるため、その説明を省略する。
【０１８０】
次に、フロー実行部１３１Ａは、取得した処理内容に従ってコンポーネントの取得を、コンポーネント管理部１３２Ａに要求する（ステップＳ２５１４）。より具体的には、フロー実行部１３１Ａは、図２６に示す処理内容の「.to("process:ocr")」の次に指定されている「.to("storage:send_to_folderα?type=service-b")」に基づき、コンポーネント名が「send_to_folderα」であるコンポーネントの取得を、コンポーネント管理部１３２Ａに要求する。なお、ここで指定されている処理内容のうち「?type=service-b」の部分は、オプションパラメータであり、コンポーネント名「send_to_folderα」のコンポーネントの処理によるデータのアップロード先が「ストレージサービスＢ」であることを示している。
【０１８１】
コンポーネント管理部１３２Ａは、コンポーネントの取得要求を受け付けると、コンポーネント管理テーブル５０００を参照して、当該取得要求に係るコンポーネントが内部コンポーネント又は外部コンポーネントのいずれであるかを判定する（ステップＳ２５１５）。
【０１８２】
すなわち、コンポーネント管理部１３２Ａは、コンポーネント管理テーブル５０００において、当該取得要求に含まれるコンポーネント名に関連付けられているホスト名が「localhost」であるか否かを判定する。そして、コンポーネント管理部１３２Ａは、当該ホスト名が「localhost」である場合、当該取得要求に係るコンポーネントは内部コンポーネントであると判定する。一方、コンポーネント管理部１３２Ａは、当該ホスト名が「localhost」でない場合、当該取得要求に係るコンポーネントは外部コンポーネントであると判定する。
【０１８３】
ここで、コンポーネント管理テーブル５０００において、コンポーネント名「send_to_folderα」に関連付けられているホスト名は「server2.com」である。したがって、コンポーネント管理部１３２Ａは、当該取得要求に係るコンポーネントは外部コンポーネントであると判定する。
【０１８４】
コンポーネント管理部１３２Ａは、コンポーネントの取得要求に係るコンポーネントが外部コンポーネントであると判定された場合、外部コンポ連携コンポーネント１３３５を生成する（ステップＳ２５１６）。
【０１８５】
このように、本実施形態に係るサービス提供システム１０は、コンポーネントの取得要求に係るコンポーネントが外部コンポーネントである場合、外部コンポ連携コンポーネント１３３５を生成する。
【０１８６】
そして、コンポーネント管理部１３２Ａは、生成された外部コンポ連携コンポーネント１３３５をフロー実行部１３１Ａに返却する。
【０１８７】
フロー実行部１３１Ａは、生成された外部コンポ連携コンポーネント１３３５に対して、データを指定して処理の実行を要求する（ステップＳ２５１７）。なお、ここで指定されたデータのデータ型は「LocalFilePath」である。
【０１８８】
外部コンポ連携コンポーネント１３３５は、型変換管理部１３４に対して、型変換を要求する（ステップＳ２５１８）。ここで、当該型変換要求には、データと、外部コンポ連携コンポーネント１３３５が扱うことができるデータ型を示す「LocalFilePath」の指定とが含まれる。
【０１８９】
型変換管理部１３４は、受け取った型変換要求に含まれるデータのデータ型と、指定されたデータ型とが一致するか否かをチェックする（ステップＳ２５１９）。ここでは、受け取った型変換要求に含まれるデータのデータ型は「LocalFilePath」であり、指定されたデータ型も「LocalFilePath」であるから、一致するものと判断される。そして、型変換管理部１３４は、型変換要求に含まれていたデータを、そのまま外部コンポ連携コンポーネント１３３５に送信する（ステップＳ２５２０）。
【０１９０】
外部コンポ連携コンポーネント１３３５は、型変換管理部１３４からデータを受け取ると、処理を実行する（ステップＳ２５２１）。すなわち、外部コンポ連携コンポーネント１３３５は、コンポーネント名「send_to_folderα」と、データとを含む処理の実行を、ホスト名「server2.com」で示される外部コンポーネント管理装置４０の外部コンポーネント処理部４１０に要求する。なお、当該実行要求には、上記で説明したアップロード先のストレージサービスを示すオプションパラメータ「?type=service-b」も含まれる。
【０１９１】
次に、外部コンポーネント処理部４１０は、外部コンポ連携コンポーネント１３３５から処理の実行要求を受け取ると、当該実行要求に応じて、外部コンポーネント処理を実行する（ステップＳ２５２２）。そして、外部コンポーネント処理部４１０は、処理結果を示すデータを返信する。
【０１９２】
ここで、上記のステップＳ２５２２の処理の詳細について説明する。図２７は、第３の実施形態に係る外部コンポーネント処理の一例のシーケンス図である。
【０１９３】
まず、要求受付部４１１は、ロジック処理部１３０Ａ（より詳細には、外部コンポ連携コンポーネント１３３５）から処理の実行要求を受け付ける（ステップＳ２７０１）。なお、当該実行要求には、外部コンポーネントのコンポーネント名「send_to_folderα」と、データと、オプションパラメータ「?type=service-b」とが含まれる。
【０１９４】
なお、処理内容にオプションパラメータが指定されていない場合は、処理の実行要求にオプションパラメータは含まれない。また、当該実行要求に含まれるデータは、データ型が「InputStream」として渡されるものとする。
【０１９５】
要求受付部４１１は、処理の実行要求を受け付けると、当該実行要求に含まれるコンポーネント名「send_to_folderα」の外部コンポーネントの取得を、コンポーネント管理部４１２に要求する（ステップＳ２７０２）。
【０１９６】
コンポーネント管理部４１２は、外部コンポーネントの取得要求を受け付けると、当該取得要求に含まれるコンポーネント名「send_to_folderα」に対応する配信αコンポーネント４１３１を生成する（ステップＳ２７０３）。配信αコンポーネント４１３１の生成は、コンポーネント共通Ｉ／Ｆ４１３０に定義されたコンポーネントを生成するためのＡＰＩを用いて行うことができる。
【０１９７】
そして、コンポーネント管理部４１２は、生成された配信αコンポーネント４１３１を要求受付部４１１に返却する。これは、例えば、コンポーネント管理部４１２は、配信αコンポーネント４１３１が展開されたメモリ上（例えばＲＡＭ）上のアドレスを、要求受付部４１１に返却する。
【０１９８】
要求受付部４１１は、生成された配信αコンポーネント４１３１に対して、データを指定して処理の実行を要求する（ステップＳ２７０４）。
【０１９９】
配信αコンポーネント４１３１は、処理の実行要求を受け取ると、型変換管理部４１４に対して、型変換を要求する（ステップＳ２７０５）。ここで、当該型変換要求には、データと、配信αコンポーネント４１３１が扱うことができるデータ型を示す「LocalFilePath」の指定とが含まれる。
【０２００】
型変換管理部４１４は、受け取った型変換要求に含まれるデータのデータ型と、指定されたデータ型とが一致するか否かをチェックする（ステップＳ２７０６）。受け取った型変換要求に含まれるデータのデータ型は「InputStream」である一方、指定されたデータ型は「LocalFilePath」であるから、一致しないものと判断される。
【０２０１】
すると、型変換管理部４１４は、型変換テーブル６０００を参照して、「InputStream」を「LocalFilePath」に変換するための型変換を特定して（ここでは、第１の型変換４１５１が特定される）、当該特定された型変換を生成する（ステップＳ２７０７）。
【０２０２】
そして、型変換管理部４１４は、生成された第１の型変換４１５１に対して、データを指定して型変換処理の実行を要求する（ステップＳ２７０８）。すると、第１の型変換４１５１は、指定されたデータのデータ型を「InputStream」から「LocalFilePath」に変換して（ステップＳ２７０９）、当該変換後のデータを型変換管理部４１４に返信する。
【０２０３】
その後、型変換管理部４１４は、型変換後のデータを配信αコンポーネント４１３１に送信する（ステップＳ２７１０）。
【０２０４】
配信αコンポーネント４１３１は、型変換管理部４１４からデータを受け取ると、処理を実行する（ステップＳ２７１１）。すなわち、本実施形態では、配信αコンポーネント４１３１は、ストレージサービスＢに対して、データの配信を実行する。
【０２０５】
なお、配信αコンポーネント４１３１は、ストレージサービスＢ連携部１６０２を介さずに、ストレージサービスＢに対してデータを配信する。このように、外部コンポーネントは、内部コンポーネントと異なり、ストレージサービス連携部１６０やドキュメントサービス部１５０を用いずに、例えば配信処理やＯＣＲ処理等の各種の処理を実行する。ただし、これに限られず、外部コンポーネントは、内部コンポーネントと同様に、ストレージサービス連携部１６０やドキュメントサービス部１５０に処理要求を行うことで、各種の処理を実行しても良い。
【０２０６】
そして、配信αコンポーネント４１３１は、処理結果を示すデータ返信する。これにより、本実施形態に係るスキャン配信サービスが提供される。
【０２０７】
このように、本実施形態に係るサービス提供システム１０は、処理内容に外部コンポーネントにより実行される処理が含まれる場合、当該外部コンポーネントを管理する外部コンポーネント管理装置４０に処理の実行を要求する。そして、サービス提供システム１０とは異なる装置である外部コンポーネント管理装置４０において外部コンポーネントが実行される。
【０２０８】
したがって、例えば、サードベンダー等により開発された外部コンポーネントに重大なバグや不具合等が存在していた場合でも、当該バグや不具合等による影響を外部コンポーネント管理装置４０内に局所化させることができる。換言すれば、サービス提供システム１０は、外部コンポーネントのバグや不具合等に伴う影響を受けることなく、サービスの提供を継続することができるようになる。
【０２０９】
なお、本実施形態では、外部コンポーネント管理装置４０において外部コンポーネントが管理されるものとしたが、例えば、外部コンポーネントの品質が確保された後は、当該外部コンポーネントをサービス提供システム１０で管理するようにしてもよい。
【０２１０】
≪処理内容の作成処理≫
次に、例えば、アプリ情報１０００の開発者等のユーザが、当該アプリ情報１０００に含まれる処理内容を作成する処理について説明する。図２８は、第３の実施形態に係る処理内容の作成処理の一例のシーケンス図である。
【０２１１】
まず、画像形成装置２０のユーザは、ブラウザ２１０を用いて、処理内容の作成画面を表示するための操作を行う。すると、画像形成装置２０のブラウザ２１０は、処理内容の作成画面の取得を、処理内容作成部１２２に要求する（ステップＳ２８０１）。
【０２１２】
処理内容作成部１２２は、コンポーネント管理テーブル５０００からコンポーネントの一覧（例えば、コンポーネント名の一覧）を取得して、図２９（ａ）に示すような処理内容の作成画面７０００を作成する（ステップＳ２８０２）。そして、処理内容作成部１２２は、作成した処理内容の作成画面７０００をブラウザ２１０に返信する。
【０２１３】
ここで、図２９（ａ）に示す処理内容の作成画面７０００は、アプリＩＤ表示欄７０１０と、コンポーネント表示欄７０２０と、処理内容作成欄７０３０とが含まれる。
【０２１４】
アプリＩＤ表示欄７０１０は、作成する処理内容が含まれるアプリ情報１０００のアプリＩＤが表示される。このアプリＩＤは、例えば、上記のステップＳ２８０１でユーザにより指定されてもよい。
【０２１５】
コンポーネント表示欄７０２０は、それぞれのコンポーネントを示すアイコン（表示部品）が一覧で表示されている。このようなコンポーネントを示すアイコンの一覧は、コンポーネント管理テーブル５０００から取得されたコンポーネント名に基づいて作成される。処理内容作成欄７０３０は、ユーザが処理内容を作成するための領域であり、例えば、コンポーネント表示欄７０２０に含まれるコンポーネントを示すアイコンをドラッグアンドドロップすることで、処理内容を作成することができる。
【０２１６】
ここで、ユーザは、ブラウザ２１０を用いて、コンポーネント表示欄７０２０に含まれる取得コンポーネントと、印刷変換βコンポーネントとを、この順で、処理内容作成欄７０３０にドラッグアンドドロップしたものとする。すると、図２９（ｂ）に示すように処理内容の作成画面７１００の処理内容作成欄７１１０には、処理内容を模式的に示すフロー図７１２０が作成される。フロー図７１２０は、内部コンポーネントである取得コンポーネントを実行した後、外部コンポーネントである印刷変換βコンポーネントを実行する処理内容を示している。
【０２１７】
これにより、ユーザにより処理内容が作成される。しかも、このとき、ユーザは、処理内容に含まれる一連の処理を実行するコンポーネントが、内部コンポーネントであるか外部コンポーネントであるかを意識することなく、処理内容を作成することができる。したがって、ユーザは、容易に処理内容を作成することができる。
【０２１８】
画像形成装置２０のブラウザ２１０は、ユーザにより処理内容が作成されると、作成された処理内容を受け付ける（ステップＳ２８０３）。そして、画像形成装置２０のブラウザ２１０は、作成された処理内容の保存を処理内容作成部１２２に要求する（ステップＳ２８０４）。なお、当該保存要求には、アプリＩＤと、ユーザにより作成された処理内容とが含まれる。
【０２１９】
サービス処理部１１０の処理内容作成部１２２は、処理内容の保存要求を受け取ると、当該保存要求をアプリ管理部１２０Ａに転送する（ステップＳ２８０５）。次に、アプリ管理部１２０Ａは、処理内容の保存要求を受け取ると、当該保存要求に含まれる処理内容をアプリＩＤと関連付けてアプリ情報記憶部１９０に保存する（ステップＳ２８０６）。そして、アプリ管理部１２０Ａは、保存結果を返信する。これにより、ユーザにより作成された処理内容がアプリ情報記憶部１９０に記憶される。
【０２２０】
＜まとめ＞
以上のように、第１の実施形態に係る情報処理システム１によれば、サービス提供システム１０は外部サービスと連携したサービスを画像形成装置２０に提供することができる。また、サービス提供システム１０は、連携先の外部サービスの追加・変更等を容易に行うことができる。さらに、サービス提供システム１０は、画像形成装置２０に提供するサービスの追加・変更等（すなわち、アプリ情報１０００の追加・変更等）を容易に行うことができる。これらにより、第１の実施形態に係るサービス提供システム１０は、サービスの追加・変更等に伴う開発・維持に要する工数を削減することができる。
【０２２１】
さらに、第２の実施形態に係る情報処理システム１によれば、サービス提供システム１０は、ブラウザ２１０が搭載されていない画像形成装置２０に対してもサービスを提供することができる。したがって、第２の実施形態に係るサービス提供システム１０によれば、一般にブラウザが搭載されていない多様な電子機器に対してサービスを提供することができる。
【０２２２】
また、第３の実施形態に係る情報処理システム１によれば、サードベンダー等により開発された外部コンポーネントを、サービス提供システム１０とは異なる装置である外部コンポーネント管理装置４０で管理及び実行させることができる。これにより、例えば、外部コンポーネントにバグや不具合が存在する等、外部コンポーネントの品質が十分でない場合においても、バグや不具合等に伴う影響を外部コンポーネント管理装置４０に局所化させることができる。
【０２２３】
したがって、第３の実施形態に係る情報処理システム１によれば、例えば、外部コンポーネントのバグや不具合等に伴いサービス提供システム１０の処理能力が低下、又はサービス提供システム１０が停止するような事態等を防止することができる。
【０２２４】
なお、アプリ情報記憶部１９０は、記憶手段の一例である。アプリ管理部１２０は、第１の送信手段の一例である。ロジック処理部１３０は、処理実行手段の一例である。
【０２２５】
本発明は、具体的に開示された上記の実施形態に限定されるものではなく、特許請求の範囲から逸脱することなく、種々の変形や変更が可能である。
【符号の説明】
【０２２６】
１        情報処理システム
１０      サービス提供システム
２０      画像形成装置
３０      外部ストレージシステム
１１０    サービス処理部
１２０    アプリ管理部
１３０    ロジック処理部
１３１    フロー実行部
１３２    コンポーネント管理部
１３３    コンポーネント群
１３４    型変換管理部
１３５    型変換群
１４０    データＩ／Ｆ部
１５０    ドキュメントサービス部
１５１    ＯＣＲ処理
１５２    印刷変換処理
１６０    ストレージサービス連携部
１７０    ファイル処理部
１８０    データ処理部
１９０    アプリ情報記憶部
１０００  アプリ情報
３０００  型変換テーブル
【先行技術文献】
【特許文献】
【０２２７】
【特許文献１】特開２０１４−０３２６５９号公報
【図１】
0006690196.tif 000002
【図２】
0006690196.tif 000003
【図３】
0006690196.tif 000004
【図４】
0006690196.tif 000005
【図５】
0006690196.tif 000006
【図６】
0006690196.tif 000007
【図７】
0006690196.tif 000008
【図８】
0006690196.tif 000009
【図９】
0006690196.tif 000010
【図１０】
0006690196.tif 000011
【図１１】
0006690196.tif 000012
【図１２】
0006690196.tif 000013
【図１３】
0006690196.tif 000014
【図１４】
0006690196.tif 000015
【図１５】
0006690196.tif 000016
【図１６】
0006690196.tif 000017
【図１７】
0006690196.tif 000018
【図１８】
0006690196.tif 000019
【図１９】
0006690196.tif 000020
【図２０】
0006690196.tif 000021
【図２１】
0006690196.tif 000022
【図２２】
0006690196.tif 000023
【図２３】
0006690196.tif 000024
【図２４】
0006690196.tif 000025
【図２５】
0006690196.tif 000026
【図２６】
0006690196.tif 000027
【図２７】
0006690196.tif 000028
【図２８】
0006690196.tif 000029
【図２９】
0006690196.tif 000030