JP2017058791A - 情報処理システム、情報処理装置、情報処理方法、及びプログラム - Google Patents

Abstract

【課題】外部サービスと連携した処理を行うためのアプリケーションの開発を支援する。
【解決手段】電子データを用いた一連の処理を、該一連の処理それぞれを実行するコンポーネントを組み合わせて実行するアプリケーション毎に、アプリ識別情報と、前記一連の処理に関する情報と、前記電子データを指定させる画面の画面情報とを関連付けて記憶する第１の記憶手段と、前記コンポーネントに関する情報を記憶する第２の記憶手段と、機器から前記アプリ識別情報を含む第１の要求を受け付けると、該アプリ識別情報に関連付く前記画面情報を送信する送信手段と、前記画面情報に基づく画面を介して指定された電子データに関する情報を含む第２の要求を前記機器から受け付けると、前記アプリ識別情報に関連付く一連の処理を、前記電子データを用いて実行する処理実行手段とを有し、前記処理実行手段は、前記一連の処理に関する情報と前記コンポーネントに関する情報とに基づき生成されたコンポーネントを組み合わせて、前記一連の処理を実行する。
【選択図】図１１

Description

本発明は、情報処理システム、情報処理装置、情報処理方法、及びプログラムに関する。

近年、クラウドコンピューティング等により多種多様な外部サービスが提供されるようになった。例えば、ユーザにより指定された電子データを外部のストレージに保管する外部サービスが知られている。

また、例えば、画像形成装置で原稿をスキャンして取得した画像データを外部ストレージに保管する技術が知られている（例えば特許文献１参照）。このように、画像形成装置と外部サービスとが連携して処理を行う技術が従来から知られている。

しかしながら、上記の従来技術においては、外部サービスと連携して処理を行うためには画像形成装置に搭載されるアプリケーションの開発が必要となる。また、ある外部サービスが固有の機能（他の外部サービスが提供していない機能）を提供するようになった場合には、当該固有の機能を利用するためのモジュールやプラグイン等を開発する必要がある。したがって、画像形成装置に搭載されるアプリケーションの追加や修正等の開発に要する工数が大きくなる場合があった。

本発明の一実施形態は、上記の点に鑑みてなされたもので、外部サービスと連携した処理を行うためのアプリケーションの開発を支援することを目的とする。

上記目的を達成するため、本発明の一実施形態は、１以上の情報処理装置が含まれる情報処理システムであって、電子データを用いた一連の処理を、該一連の処理それぞれを実行するコンポーネントを組み合わせて実行するアプリケーション毎に、該アプリケーションを識別するアプリ識別情報と、前記一連の処理に関する情報と、前記一連の処理に用いる前記電子データを指定させる画面の画面情報と、を関連付けて記憶する第１の記憶手段と、前記コンポーネントに関する情報を記憶する第２の記憶手段と、前記情報処理システムに接続される１以上の機器のうちの一の機器から前記アプリ識別情報を含む第１の要求を受け付けると、該第１の要求に含まれる該アプリ識別情報に関連付けて前記第１の記憶手段に記憶されている前記画面情報を、要求元の前記一の機器に送信する送信手段と、前記送信手段により送信された前記画面情報に基づき前記一の機器に表示された画面を介してユーザにより指定された電子データに関する情報を含む第２の要求を前記一の機器から受け付けると、前記アプリ識別情報に関連付けて前記第１の記憶手段に記憶されている前記一連の処理に関する情報に基づく一連の処理を、前記第２の要求に含まれる前記電子データに関する情報により指定される電子データを用いて実行する処理実行手段とを有し、前記処理実行手段は、前記一連の処理に関する情報と前記コンポーネントに関する情報とに基づき生成されたコンポーネントを組み合わせて、前記電子データを用いた前記一連の処理を実行する。

本発明の一実施形態によれば、外部サービスと連携した処理を行うためのアプリケーションの開発を支援することができる。

第一の実施形態に係る情報処理システムの一例のシステム構成を示す図である。 第一の実施形態に係るサービス提供システム及びＰＣ端末の一例のハードウェア構成を示す図である。 第一の実施形態に係る画像形成装置の一例のハードウェア構成を示す図である。 第一の実施形態に係る情報処理システムの一例の処理ブロックを示す図である。 共通Ｉ／Ｆ及び固有Ｉ／Ｆの一例を示す図である。 データ定義の一例を示す図である。 レイアウト情報の一例を示す図である。 処理内容の一例を示す図である。 第一の実施形態に係るスキャン配信サービスの全体処理の一例を示すシーケンス図である。 スキャン配信サービスを利用するためのアプリ画面の一例を示す図である。 第一の実施形態に係るロジック処理部の一例の処理ブロックを示す図である。 第一の実施形態に係るコンポーネント情報テーブルの一例を示す図である。 型変換テーブルの一例を示す図である。 第一の実施形態に係るフロー実行処理の一例を示すシーケンス図である。 第一の実施形態に係るコンポーネントの追加、更新、及び削除処理の一例を示すシーケンス図である。 コンポーネント編集画面、コンポーネント追加画面、及びコンポーネント更新画面の一例を示す図である。 第二の実施形態に係るロジック処理部の一例の処理ブロックを示す図である。 第二の実施形態に係るコンポーネント情報テーブルの一例を示す図である。 第二の実施形態に係るフロー実行処理の一例を示すシーケンス図である。 第三の実施形態に係るロジック処理部の一例の処理ブロックを示す図である。 第三の実施形態に係るコンポーネント情報テーブルの一例を示す図である。 第三の実施形態に係るフロー実行処理の一例を示すシーケンス図である。

以下、本発明の実施形態について図面を参照しながら詳細に説明する。

［第一の実施形態］
＜システム構成＞
まず、本実施形態に係る情報処理システム１のシステム構成について、図１を参照しながら説明する。図１は、第一の実施形態に係る情報処理システムの一例のシステム構成を示す図である。

図１に示す情報処理システム１は、サービス提供環境Ｅ１、ユーザ環境Ｅ２、及び外部ストレージシステム４０を含み、インターネット等の広域的なネットワークＮ１を介して通信可能に接続されている。

サービス提供環境Ｅ１は、ネットワークＮ１を介してクラウドサービス等の外部サービスを提供するシステム環境である。なお、本実施形態では、外部サービスの具体例としてクラウドサービスを採用して説明するが、ＡＳＰ（Application Service Provider）によって提供されるサービスやＷｅｂサービス等、ネットワークを介して提供されるサービスに関して本実施形態が適用されても良い。

サービス提供環境Ｅ１は、一台以上の情報処理装置で実現されるサービス提供システム１０を有する。サービス提供システム１０は、ネットワークＮ１を介して所定のサービスを提供する。例えば、サービス提供システム１０は、ユーザ環境Ｅ２の画像形成装置２０において原稿をスキャンして生成された電子ファイルを、ＯＣＲ（Optical Character Reader）処理して、外部ストレージシステム４０に保存するサービス（スキャン配信サービス）を提供する。本実施形態に係るサービス提供システム１０は、このようなスキャン配信サービスを提供する。

ただし、サービス提供システム１０により提供されるサービスは、これに限られない。サービス提供システム１０は、例えば、外部ストレージシステム４０に保存されている電子ファイルを、ユーザ環境Ｅ２の画像形成装置２０で印刷するサービス（クラウドプリントサービス）を提供しても良い。

また、サービス提供システム１０は、例えば、外部ストレージシステム４０に保存されている電子ファイルを、ユーザ環境Ｅ２のプロジェクタで投影するサービスを提供しても良い。さらに、サービス提供システム１０は、画像形成装置２０において原稿をスキャンして生成された電子ファイルを、ＯＣＲ処理した後、所定の言語に翻訳（例えば、英語から日本語に翻訳）して、外部ストレージシステム４０に保存するサービスを提供しても良い。このように、本実施形態に係るサービス提供システム１０は、外部ストレージシステム４０と連携した一連の処理により実現される各種のサービスを提供する。

なお、サービス提供システム１０の全部又は一部は、ユーザ環境Ｅ２に設置されていても良い。すなわち、サービス提供システム１０を構成する情報処理装置の全部又は一部は、ユーザ環境Ｅ２に包含されていても良い。

ユーザ環境Ｅ２は、例えば、画像形成装置２０を使用するユーザである企業等におけるシステム環境である。ユーザ環境Ｅ２は、一台以上の画像形成装置２０、及び一台以上のＰＣ端末３０を含み、例えばＬＡＮ（Local Area Network）等のネットワークを介して接続されている。

本実施形態に係る画像形成装置２０は、スキャン機能を有するＭＦＰ（Multifunction Peripheral）等の複合機である。なお、画像形成装置２０は、スキャン機能以外に、プリント機能やコピー機能、ファクス（ＦＡＸ）通信機能等を有していても良い。

また、本実施形態に係るＰＣ端末３０は、サービス提供システム１０が各種のサービスを提供するためのプログラムの開発等に用いられる情報処理装置である。ユーザは、ＰＣ端末３０を用いて、所定の処理を実行するプログラムやモジュール等をサービス提供システム１０に追加等することができる。

外部ストレージシステム４０は、ネットワークＮ１を介してストレージサービス（又はオンラインストレージ）と呼ばれるクラウドサービスを提供するコンピュータシステムである。

ストレージサービスとは、外部ストレージシステム４０のストレージの記憶領域を貸し出すサービスである。本実施形態では、スキャン配信サービスにおいて、外部ストレージシステム４０によって貸し出される記憶領域に、ＯＣＲ処理された電子ファイルを保存（アップロード）する。

なお、以降では、複数の外部ストレージシステム４０について、各々を区別するときは、「外部ストレージシステム４０_１」、「外部ストレージシステム４０_２」等と添え字を用いて記載する。また、外部ストレージシステム４０_１によって提供されるサービスの名称を「ストレージサービスＡ」、外部ストレージシステム４０_２によって提供されるサービスの名称を「ストレージサービスＢ」等とする。

外部ストレージシステム４０は、複数台の情報処理装置によって実現されるシステムであっても良い。また、図１に示す情報処理システム１の構成は一例であって、他の構成であっても良い。例えば、ユーザ環境Ｅ２は、画像形成装置２０に加えて又は画像形成装置２０に代えて、プロジェクタ、電子黒板等の各種機器を有していても良い。

＜ハードウェア構成＞
≪サービス提供システム、ＰＣ端末≫
サービス提供システム１０及びＰＣ端末３０のハードウェア構成について、図２を参照しながら説明する。図２は、第一の実施形態に係るサービス提供システム及びＰＣ端末の一例のハードウェア構成を示す図である。なお、サービス提供システム１０及びＰＣ端末３０は、同様のハードウェア構成を有しているため、以降では、主に、サービス提供システム１０のハードウェア構成について説明する。

サービス提供システム１０は、入力装置１１、表示装置１２、外部Ｉ／Ｆ１３、及びＲＡＭ（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」とする。

ここで、ストレージサービスＡと連携したスキャン配信サービスを提供するためのアプリ情報１０００の画面定義に含まれるデータ定義について、図６を参照しながら説明する。図６は、データ定義の一例を示す図である。

図６に示すデータ定義１１００は、画像形成装置２０のブラウザ２１０により操作パネル２２等に表示されるアプリ画面の入力欄（入力ボックス）や選択欄（選択ボックス）等を構成するための情報が記述されている。

具体的には、図６に示すデータ定義１１００に含まれるデータ定義部１１０１には、スキャンにより生成される電子ファイルのファイル名を入力するための入力欄を構成するための情報が記述されている。また、図６に示すデータ定義に含まれるデータ定義部１１０２には、ストレージサービスＡにおける保存先フォルダを選択するための選択欄を構成するための情報が記述されている。

なお、データ定義部１１０２の「data_source」には、選択欄の各選択要素（ここでは、保存先候補のフォルダ名及びフォルダＩＤ）の取得先のＵＲＬ（Uniform Resource Locator）が記述されている。

次に、ストレージサービスＡと連携したスキャン配信サービスを提供するためのアプリ情報１０００の画面定義に含まれるレイアウト情報について、図７を参照しながら説明する。図７は、レイアウト情報の一例を示す図である。

図７に示すレイアウト情報１２００は、画像形成装置２０のブラウザ２１０により操作パネル２２等に表示されるアプリ画面における文字（入力欄の表示名称等）や入力欄、選択欄等の表示位置や表示名称等の情報が記述されている。

具体的には、図７に示すレイアウト情報１２００に含まれるレイアウト定義部１２０１には、データ定義１１００における「"data_id":1」（すなわち、データ定義部１１０１）の表示位置及び表示名称の情報が記述されている。これにより、アプリ画面には、表示名称が「ファイル名」である入力欄が、１番目の位置に表示される。また、レイアウト情報１２００に含まれるレイアウト定義部１２０２では、データ定義１１００における「"data_id":2」（すなわち、データ定義部１１０２）の表示位置及び表示名称の情報が記述されている。これにより、アプリ画面には、表示名称が「保存先フォルダ選択」である選択欄が、２番目の位置に表示される。

次に、ストレージサービスＡと連携したスキャン配信サービスを提供するためのアプリ情報１０００の処理内容について、図８を参照しながら説明する。図８は、処理内容の一例を示す図である。

図８に示す処理内容１３００は、ストレージサービスＡと連携したスキャン配信サービスを実現するための一連の処理の内容が記述されている。

具体的には、図８に示す処理内容１３００に含まれるフローＩＤ定義部１３０１には、当該処理内容１３００を一意に識別するための識別情報であるフローＩＤ「flow001」が記述されている。また、図８に示す処理定義部１３０２及び処理定義部１３０３には、ストレージサービスＡと連携したスキャン配信サービスを実現するための一連の処理の内容が定義されている。

すなわち、処理定義部１３０２には、スキャンして生成された電子ファイルをＯＣＲ処理するための処理の内容が記述されている。また、処理定義部１３０３には、ＯＣＲ処理後の電子ファイルをストレージサービスＡに配信するための処理の内容が記述されている。このように、アプリ情報１０００に含まれる処理内容には、外部ストレージシステム４０と連携した一連の処理を構成する一以上の処理の内容が記述されている。

以上のように、本実施形態に係るサービス提供システム１０は、画像形成装置２０にアプリ画面を表示させるための画面定義と、サービスを実現するための一連の処理（処理フロー）の内容が記述された処理内容とが含まれるアプリ情報１０００を有する。そして、本実施形態に係るサービス提供システム１０は、画像形成装置２０に対して、アプリ情報１０００を利用して各種のサービスを提供する。このため、サービス提供システム１０により提供されるサービスを追加等する場合には、アプリ情報記憶部１９０にアプリ情報１０００を追加等すれば良い。

また、本実施形態に係るサービス提供システム１０にアプリ情報１０００を追加するには、画面定義及び処理内容を記述すれば良いため、簡易に開発することができる。したがって、本実施形態に係るサービス提供システム１０では、サービスの追加・変更等に伴う開発工数を削減させることができるとともに、例えばサードベンダー等によるサービスの追加・変更等を容易に行うことができる。

＜処理の詳細＞
次に、本実施形態に係る情報処理システム１の処理の詳細について説明する。

≪スキャン配信サービスの全体処理≫
本実施形態に係るスキャン配信サービスを画像形成装置２０のユーザが利用する場合の全体的な処理について、図９を参照しながら説明する。図９は、第一の実施形態に係るスキャン配信サービスの全体処理の一例を示すシーケンス図である。

まず、画像形成装置２０のユーザは、ブラウザ２１０を用いて、サービス提供システム１０により提供されるサービスの一覧を取得するための操作を行う。すると、画像形成装置２０は、サービスの一覧の取得要求をサービス提供システム１０のサービス処理部１１０に送信する（ステップＳ９０１）。サービス処理部１１０のアプリ管理部１２０は、当該取得要求を受け取ると、サービス提供システム１０により提供されるサービスの一覧を画像形成装置２０に送信する。これにより、画像形成装置２０の操作パネル２２には、ブラウザ２１０により、サービス提供システム１０により提供されるサービスの一覧が表示される。

なお、サービスの一覧には、例えば、サービス提供システム１０により提供されるサービスのサービス名と、当該サービスを提供するためのアプリ情報１０００のアプリＩＤと、当該サービスを実現するための処理内容のフローＩＤとが含まれる。

ユーザは、画像形成装置２０の操作パネル２２に表示されたサービスの一覧から、自身が利用を所望するサービスを選択する。すると、ブラウザ２１０は、ユーザにより選択されたサービスに対応するアプリ情報１０００のアプリＩＤと、処理内容のフローＩＤとをアプリ管理部１２０に送信する（ステップＳ９０２）。

ここで、本実施形態では、ユーザにより「ストレージサービスＡと連携したスキャン配信サービス」の利用が選択されたものとする。したがって、ブラウザ２１０は、アプリＩＤ「app001」と、フローＩＤ「flow001」とをアプリ管理部１２０に送信する。

そして、アプリ管理部１２０は、ブラウザ２１０から受け取ったアプリＩＤ「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」と、当該アプリＩＤのアプリ情報１０００に含まれる処理内容１３００のフローＩＤ「flow001」と、生成された電子ファイルと、選択された保存先フォルダ「FolderB」のフォルダＩＤ「folder_id_b」とが含まれる。

ロジック処理部１３０は、ブラウザ２１０から処理実行要求を受け取ると、当該処理実行要求に含まれるアプリＩＤ及びフローＩＤに対応する処理内容に基づく一連の処理を実行するフロー実行処理を行う（ステップＳ９１０）。これにより、ストレージサービスＡと連携したスキャン配信サービスが実現される。なお、フロー実行処理の詳細については後述する。

そして、ロジック処理部１３０は、フロー実行処理の処理結果を、画像形成装置２０のブラウザ２１０に送信する（ステップＳ９１１）。これにより、本実施形態に係るスキャン配信サービスが完了する。

≪フロー実行処理≫
次に、図９のステップＳ９１０のフロー実行処理の詳細について説明する。フロー実行処理は、主に、ロジック処理部１３０により実行される。したがって、フロー実行処理の詳細について説明する前に、ロジック処理部１３０の詳細な処理ブロックについて、図１１を参照しながら説明する。図１１は、第一の実施形態に係るロジック処理部の一例の処理ブロックを示す図である。

ロジック処理部１３０は、フロー実行部１３１、コンポーネント管理部１３２、コンポーネント群１３３、型変換管理部１３４、及び型変換群１３５を有する。また、ロジック処理部１３０は、コンポーネント情報テーブル３０００、及び型変換テーブル４０００を利用する。

フロー実行部１３１は、画像形成装置２０のブラウザ２１０から処理実行要求を受け取ると、アプリ管理部１２０を介して、アプリ情報１０００から処理内容を取得する。そして、フロー実行部１３１は、取得した処理内容に記述された一連の処理の内容に従って、当該一連の処理に含まれる一の処理を実行するコンポーネントの取得を要求する。また、フロー実行部１３１は、取得したコンポーネントに対して処理の実行を要求する。

コンポーネント管理部１３２は、フロー実行部１３１からのコンポーネントの取得要求に応じて、コンポーネントの生成を行う。なお、コンポーネントの生成とは、例えばクラスで定義されたコンポーネントを、メモリ（例えばＲＡＭ１４）上に展開することを意味する。

コンポーネント管理部１３２は、コンポーネント判別部１３２１、既存コンポーネント生成部１３２２、追加コンポーネント生成部１３２３、及びコンポーネント登録部１３２４を有する。

コンポーネント判別部１３２１は、フロー実行部１３１からのコンポーネントの取得要求に応じて、コンポーネント情報テーブル３０００を参照し、当該取得要求に係るコンポーネントが、既存コンポーネント又は追加コンポーネントのいずれであるかを判別する。

ここで、既存コンポーネントとは、サービス提供システム１０に予め組み込まれているコンポーネントのことを言う。一方、追加コンポーネントとは、ユーザがＰＣ端末３０を介して、コンポーネント情報テーブル３０００に登録されたコンポーネントのことを言う。換言すれば、追加コンポーネントとは、ユーザにより開発等され、サービス提供システム１０に追加されたコンポーネントのことである。

このように、本実施形態に係るサービス提供システム１０では、ユーザにより開発等されたコンポーネントを追加することができる。このため、ユーザは、追加コンポーネントを用いて実現される一連の処理を処理内容として記述することができるため、様々なサービスを提供するアプリ情報１０００を開発することができるようになる。

既存コンポーネント生成部１３２２は、コンポーネント判別部１３２１によりコンポーネントの取得要求に係るコンポーネントが既存コンポーネントであると判別された場合、当該取得要求に係る既存コンポーネントを生成する。

追加コンポーネント生成部１３２３は、コンポーネント判別部１３２１によりコンポーネントの取得要求に係るコンポーネントが追加コンポーネントであると判別された場合、当該取得要求に係る追加コンポーネントを生成する。

コンポーネント登録部１３２４は、ＰＣ端末３０のブラウザ３１０からの要求に応じて、追加コンポーネントをコンポーネント情報テーブル３０００に登録する。また、コンポーネント登録部１３２４は、ＰＣ端末３０のブラウザ３１０からの要求に応じて、コンポーネント情報テーブル３０００に登録されている追加コンポーネントの更新や削除を行う。

ここで、コンポーネント情報テーブル３０００について、図１２を参照しながら説明する。図１２は、第一の実施形態に係るコンポーネント情報の一例を示す図である。

図１２に示すコンポーネント情報テーブル３０００は、コンポーネント毎に、コンポーネントに関する情報（コンポーネント情報）を管理する。コンポーネント情報は、データ項目として、コンポーネント名、バージョン、パラメータ、及びファイルを有する。

コンポーネント名は、コンポーネントの情報である。バージョンは、コンポーネントのバージョンである。各コンポーネントは、コンポーネント名及びバージョンにより一意に識別される。

パラメータは、コンポーネントに対する入力パラメータである。例えば、外部ストレージシステム４０に電子ファイルを配信するためのコンポーネント（後述する配信コンポーネント）のパラメータは、当該外部ストレージシステム４０における保存先のフォルダのフォルダＩＤ等である。

ファイルは、コンポーネントを生成するための電子ファイル（以降では、この電子ファイルを「生成ファイル」と表す。）が、例えばＪＡＲ（Java Archive）等のデータ形式で格納される。したがって、本実施形態では、追加コンポーネントのコンポーネント情報のデータ項目「ファイル」には、当該追加コンポーネントの生成ファイルが格納される。一方で、既存コンポーネントのコンポーネント情報のデータ項目「ファイル」には、生成ファイルが格納されない。

より具体的には、図１２に示すコンポーネント情報テーブル３０００において、コンポーネント名「ocrA」、バージョン「v1」のコンポーネント情報のデータ項目「ファイル」には、生成ファイルが格納されていない。一方で、コンポーネント名「ocrB」、バージョン「v2」のコンポーネント情報のデータ項目「ファイル」には、コンポーネントの生成ファイルが格納されている。

したがって、図１２に示すコンポーネント情報テーブル３０００において、コンポーネント名「ocrA」、バージョン「v1」のコンポーネント情報は、既存コンポーネントのコンポーネント情報である。一方で、コンポーネント名「ocrB」、バージョン「v2」のコンポーネント情報は、追加コンポーネントのコンポーネント情報である。

コンポーネント群１３３は、既存コンポーネントや追加コンポーネントの集合である。コンポーネント群１３３には、コンポーネント名「ocrA」、バージョン「v1」のコンポーネント情報に対応するＯＣＲＡコンポーネント１３３１が含まれる。また、コンポーネント群１３３には、コンポーネント名「ocrB」、バージョン「v2」のコンポーネント情報に対応するＯＣＲＢコンポーネント１３３２が含まれる。

同様に、コンポーネント群１３３には、コンポーネント名「uploadA」、バージョン「v1」のコンポーネント情報に対応する配信Ａコンポーネント１３３３が含まれる。また、コンポーネント群１３３には、コンポーネント名「uploadB」、バージョン「v1」のコンポーネント情報に対応する配信Ｂコンポーネント１３３４が含まれる。

このように、コンポーネント群１３３は、コンポーネント情報テーブル３０００で管理されているコンポーネント情報に対応するコンポーネントの集合である。

さらに、コンポーネント群１３３に含まれる各コンポーネントは、コンポーネント共通Ｉ／Ｆ１３３０を有する。コンポーネント共通Ｉ／Ｆ１３３０は、各コンポーネントに対して共通に定義されたＡＰＩであり、コンポーネントを生成するためのＡＰＩと、コンポーネントに対して処理の実行を要求するためのＡＰＩとが含まれる。

このように、各コンポーネントがコンポーネント共通Ｉ／Ｆ１３３０を有することで、コンポーネントの追加等に伴う影響を局所化することができる。換言すれば、フロー実行部１３１やコンポーネント管理部１３２、他のコンポーネント等に影響を与えることなく、コンポーネントの追加等を行うことができる。このため、コンポーネントの追加等の開発に要する工数を削減することができる。

型変換管理部１３４は、データ型の型変換を管理する。ここで、各コンポーネントは、自身が扱えるデータ型が予め定められている。したがって、型変換管理部１３４は、コンポーネントからの要求に応じて、型変換テーブル４０００を参照して、当該要求に応じた型変換を生成する。

ここで、型変換テーブル４０００について、図１３を参照しながら説明する。図１３は、型変換テーブルの一例を示す図である。

図１３に示す型変換テーブル４０００は、型変換に関する情報（型変換情報）を管理する。型変換情報は、データ項目として、変換前のデータ型、変換後のデータ型、及び生成する型変換を有する。これにより、例えば、コンポーネントから「InputStream」のデータ型を「LocalFilePath」のデータ型に変換する要求を受け取った場合、型変換管理部１３４は、後述する第１の型変換１３５１を生成する。

そして、型変換管理部１３４は、生成された型変換に対して型変換処理の実行を要求する。ここで、型変換とは、データ型の型変換処理を実行するためのモジュール等であり、例えばクラスや関数等で定義される。

なお、型変換の生成とは、例えばクラスで定義された型変換を、メモリ（例えばＲＡＭ１４）上に展開することを意味する。また、データ型には、例えば、ストリームデータを示すデータ型「InputStream」、記憶装置等に格納されている電子ファイルのパス（アドレス）を示す「LocalFilePath」、電子ファイルの実体を示す「File」等が挙げられる。

型変換群１３５は、型変換の集合である。型変換群１３５には、データ型「InputStream」を「LocalFilePath」に変換する第１の型変換１３５１が含まれる。型変換群１３５には、第１の型変換１３５１以外にも、例えば、「LocalFilePath」を「File」に変換する第２の型変換等が含まれる。

さらに、これらの各型変換は、型変換共通Ｉ／Ｆ１３５０を有する。型変換共通Ｉ／Ｆ１３５０は、各型変換に対して共通に定義されたＡＰＩであり、型変換を生成するためのＡＰＩと、型変換に対して処理の実行を要求するためのＡＰＩとが含まれる。このように、各型変換が型変換共通Ｉ／Ｆ１３５０を有するようにすることで、型変換の追加等に伴う影響を局所化することができる。換言すれば、型変換管理部１３４に影響を与えることなく、コンポーネントの追加等を行うことができる。これにより、型変換の追加等の開発に要する工数を削減することができる。

続いて、図９のステップＳ９１０のフロー実行処理の詳細について、図１４を参照しながら説明する。図１４は、第一の実施形態に係るフロー実行処理の一例を示すシーケンス図である。

まず、フロー実行部１３１は、ブラウザ２１０からスキャン配信サービスの処理実行要求を受け付けると、アプリ管理部１２０に処理内容の取得を要求する（ステップＳ１４０１）。ここで、当該処理内容の取得要求には、アプリＩＤ「app001」と、フローＩＤ「flow001」とが含まれる。

そして、フロー実行部１３１は、アプリ管理部１２０からアプリＩＤ「app001」に対応するアプリ情報１０００に含まれるフローＩＤ「flow001」処理内容を取得する。すなわち、フロー実行部１３１は、図８に示す処理内容１３００を取得する。

フロー実行部１３１は、取得した処理内容１３００に従ってコンポーネントの取得を、コンポーネント管理部１３２に要求する（ステップＳ１４０２）。より具体的には、フロー実行部１３１は、図８に示す処理内容１３００の処理定義部１３０２に記述に基づいて、コンポーネント名「ocrB」、バージョン「v2」のコンポーネントの取得を、コンポーネント管理部１３２に要求する。

コンポーネント管理部１３２は、コンポーネントの取得要求を受け取ると、コンポーネント判別部１３２１により、当該取得要求に係るコンポーネントが既存コンポーネント又は追加コンポーネントのいずれであるかを判別する（ステップＳ１４０３）。すなわち、コンポーネント判別部１３２１は、コンポーネント情報テーブル３０００を参照し、コンポーネント名「ocrB」、バージョン「v2」のコンポーネント情報のデータ項目「ファイル」に、コンポーネントの生成ファイルが格納されているか否かを判別する。

コンポーネント判別部１３２１は、コンポーネント情報のデータ項目「ファイル」に、コンポーネントの生成ファイルが格納されている場合、取得要求に係るコンポーネントは追加コンポーネントであると判別する。一方、コンポーネント判別部１３２１は、コンポーネント情報のデータ項目「ファイル」に、コンポーネントの生成ファイルが格納されていない場合、取得要求に係るコンポーネントは既存コンポーネントであると判別する。

本実施形態では、コンポーネント情報テーブル３０００において、コンポーネント名「ocrB」、バージョン「v2」のコンポーネント情報には、データ項目「ファイル」に、コンポーネントの生成ファイルが格納されている。したがって、コンポーネント判別部１３２１は、取得要求に係るコンポーネントが追加コンポーネントであると判別する。

コンポーネント判別部１３２１は、取得要求に係るコンポーネントが追加コンポーネントであると判別した場合、当該取得要求を追加コンポーネント生成部１３２３に送信する（ステップＳ１４０４）。

次に、追加コンポーネント生成部１３２３は、当該取得要求を受け取ると、コンポーネント名「ocrB」、バージョン「v2」に基づき、コンポーネント情報テーブル３０００からコンポーネントの生成ファイルを取得する（ステップＳ１４０５）。すなわち、追加コンポーネント生成部１３２３は、コンポーネント名「ocrB」、バージョン「v2」のコンポーネント情報のデータ項目「ファイル」に格納されている生成ファイルを取得する。

続いて、追加コンポーネント生成部１３２３は、取得した生成ファイルに基づいて追加コンポーネントを生成する（ステップＳ１４０６）。すなわち、追加コンポーネント生成部１３２３は、コンポーネント名「ocrB」、バージョン「v2」のコンポーネント情報から取得した生成ファイルに基づいて、ＯＣＲＢコンポーネント１３３２を生成する。なお、ＯＣＲＢコンポーネント１３３２の生成は、例えば、ＪＡＲ形式の生成ファイルを実行して、コンポーネント共通Ｉ／Ｆ１３３０に定義されたコンポーネントを生成するためのＡＰＩを用いて行うことができる。

そして、追加コンポーネント生成部１３２３は、ＯＣＲＢコンポーネント１３３２が生成されると、ＯＣＲＢコンポーネント１３３２をフロー実行部１３１に返信する。これは、例えば、追加コンポーネント生成部１３２３は、ＯＣＲＢコンポーネント１３３２が展開されたメモリ（例えばＲＡＭ１４）上のアドレスを、フロー実行部１３１に返信すれば良い。

次に、フロー実行部１３１は、データを指定して、生成されたＯＣＲＢコンポーネント１３３２に処理の実行を要求する（ステップＳ１４０７）。なお、ここで指定されるデータは、データ型が「InputStream」としてブラウザ２１０から渡される電子ファイルである。

すなわち、フロー実行部１３１は、ブラウザ２１０からデータ型「InputStream」として渡される電子ファイルを、単に「データ」として（データ型を意識することなく）、ＯＣＲＢコンポーネント１３３２に渡して処理の実行を要求する。図１４では、このようにデータ型を意識することなく渡される電子ファイル等を、単に「データ」と表す。

次に、ＯＣＲＢコンポーネント１３３２は、データが指定された処理の実行要求を受け取ると、データ型の型変換を型変換管理部１３４に要求する（ステップＳ１４０８）。ここで、当該型変換要求には、データと、ＯＣＲＢコンポーネント１３３２が扱うことができるデータ型を示す「LocalFilePath」の指定とが含まれる。

型変換管理部１３４は、型変換要求を受け取ると、当該型変換要求に含まれるデータのデータ型と、指定されたデータ型とが一致するか否かをチェックする（ステップＳ１４０９）。ここでは、受け取った型変換要求に含まれるデータのデータ型は「InputStream」である一方、指定されたデータ型は「LocalFilePath」であるから、一致しないものと判断される。

すると、型変換管理部１３４は、型変換テーブル４０００を参照し、「InputStream」を「LocalFilePath」に変換するための型変換を特定して（ここでは、第１の型変換１３５１が特定される）、当該特定された型変換を生成する（ステップＳ１４１０）。

次に、型変換管理部１３４は、生成された第１の型変換１３５１に対して、データを指定して型変換処理の実行を要求する（ステップＳ１４１１）。すると、第１の型変換１３５１は、指定されたデータのデータ型を「InputStream」から「LocalFilePath」に変換して（ステップＳ１４１２）、当該変換後のデータを型変換管理部１３４に返信する。そして、型変換管理部１３４は、型変換後のデータをＯＣＲＢコンポーネント１３３２に返信する（ステップＳ１４１３）。

ＯＣＲＢコンポーネント１３３２は、型変換後のデータを受け取ると、処理を実行する（ステップＳ１４１４）。すなわち、データ型「LocalFilePath」のデータ（つまり、パス又はアドレス）により示される電子ファイルに対して、ＯＣＲ処理を実行する。より具体的には、ＯＣＲＢコンポーネント１３３２は、ドキュメントサービス部１５０のＯＣＲ処理１５１に処理を要求し、ＯＣＲ処理１５１が当該電子ファイルに対して処理を実行する。

そして、ＯＣＲＢコンポーネント１３３２は、処理の実行が完了すると、データをフロー実行部１３１に返信する。なお、ここで返信されるデータは、ＯＣＲ処理後の電子ファイルを示すパス又はアドレスである（すなわち、返信されるデータのデータ型は「LocalFilePath」である。）。

次に、フロー実行部１３１は、取得した処理内容１３００に従ってコンポーネントの取得を、コンポーネント管理部１３２に要求する（ステップＳ１４１５）。より具体的には、フロー実行部１３１は、図８に示す処理内容１３００の処理定義部１３０２の次の処理定義部１３０３の記述に基づいて、コンポーネント名「uploadA」、バージョン「v1」のコンポーネントの取得を、コンポーネント管理部１３２に要求する。

コンポーネント管理部１３２は、コンポーネントの取得要求を受け取ると、コンポーネント判別部１３２１により、当該取得要求に係るコンポーネントが既存コンポーネント又は追加コンポーネントのいずれであるかを判別する（ステップＳ１４１６）。すなわち、コンポーネント判別部１３２１は、コンポーネント情報テーブル３０００を参照し、コンポーネント名「uploadA」、バージョン「v1」のコンポーネント情報のデータ項目「ファイル」に、コンポーネントの生成ファイルが格納されているか否かを判別する。

コンポーネント判別部１３２１は、コンポーネント情報のデータ項目「ファイル」に、コンポーネントの生成ファイルが格納されている場合、取得要求に係るコンポーネントは追加コンポーネントであると判別する。一方、コンポーネント判別部１３２１は、コンポーネント情報のデータ項目「ファイル」に、コンポーネントの生成ファイルが格納されていない場合、取得要求に係るコンポーネントは既存コンポーネントであると判別する。

本実施形態では、コンポーネント情報テーブル３０００において、コンポーネント名「uploadA」、バージョン「v1」のコンポーネント情報には、データ項目「ファイル」に、コンポーネントの生成ファイルが格納されていない。したがって、コンポーネント判別部１３２１は、取得要求に係るコンポーネントが既存コンポーネントであると判別する。

コンポーネント判別部１３２１は、取得要求に係るコンポーネントが既存コンポーネントであると判別した場合、当該取得要求を既存コンポーネント生成部１３２２に送信する（ステップＳ１４１７）。

次に、既存コンポーネント生成部１３２２は、コンポーネントの取得要求を受け取ると、当該取得要求に係る既存コンポーネントを生成する（ステップＳ１４１８）。すなわち、既存コンポーネント生成部１３２２は、コンポーネント名「uploadA」、バージョン「v1」に基づいて、配信Ａコンポーネント１３３３を生成する。なお、配信Ａコンポーネント１３３３の生成は、コンポーネント共通Ｉ／Ｆ１３３０に定義されたコンポーネントを生成するためのＡＰＩを用いて行うことができる。

そして、既存コンポーネント生成部１３２２は、配信Ａコンポーネント１３３３が生成されると、配信Ａコンポーネント１３３３をフロー実行部１３１に返信する。これは、例えば、既存コンポーネント生成部１３２２は、配信Ａコンポーネント１３３３が展開されたメモリ（例えばＲＡＭ１４）上のアドレスを、フロー実行部１３１に返信すれば良い。

次に、フロー実行部１３１は、データを指定して、生成された配信Ａコンポーネント１３３３に処理の実行を要求する（ステップＳ１４１９）。なお、ここで指定されるデータは、データ型が「LocalFilePath」としてＯＣＲＢコンポーネント１３３２から返信されたＯＣＲ処理後の電子ファイルである。

次に、配信Ａコンポーネント１３３３は、データが指定された処理の実行要求を受け取ると、データ型の型変換を型変換管理部１３４に要求する（ステップＳ１４２０）。ここで、当該型変換要求には、データと、配信Ａコンポーネント１３３３が扱うことができるデータ型を示す「LocalFilePath」の指定とが含まれる。

型変換管理部１３４は、型変換要求を受け取ると、当該型変換要求に含まれるデータのデータ型と、指定されたデータ型とが一致するか否かをチェックする（ステップＳ１４２１）。ここでは、受け取った型変換要求に含まれるデータのデータ型は「LocalFilePath」であり、指定されたデータ型も「LocalFilePath」であるから、一致するものと判断される。

そして、型変換管理部１３４は、型変換要求に含まれていたデータを、そのまま配信Ａコンポーネント１３３３に送信する（ステップＳ１４２２）。このように、データ型チェック（ステップＳ１４２１の処理）で両者のデータ型が一致する場合には、型変換管理部１３４は型変換の生成を行わない。

配信Ａコンポーネント１３３３は、型変換管理部１３４からデータを受け取ると、処理を実行する（ステップＳ１４２３）。

すなわち、配信Ａコンポーネント１３３３は、ストレージサービスＡ連携部１６０_１のファイル処理部１７０_１に対して、共通Ｉ／Ｆ１７１_１として定義されているファイル保存のＡＰＩを用いて、データの配信実行を要求する。より具体的には、配信Ａコンポーネント１３３３は、ストレージサービスＡ連携部１６０_１のファイル処理部１７０_１に対して、図５（ａ）に示すＡＰＩとして「service-a/process/folder」を用いてデータの配信実行を要求する。これにより、ストレージサービスＡのフォルダ「FolderB」に、ファイル名「test」の電子ファイル（スキャンにより生成された電子ファイルに対してＯＣＲ処理した電子ファイル）が保存される。

そして、配信Ａコンポーネント１３３３は、処理の実行が完了すると、データをフロー実行部１３１に返信する。なお、ここで返信されるデータは、例えば、ストレージサービスＡに対して電子ファイルの配信が正常に行われたことを示す処理結果である。これにより、本実施形態に係るサービス提供システム１０において、処理内容１３００に基づく、ストレージサービスＡと連携した一連の処理の実行が完了する。

以上のように、本実施形態に係るサービス提供システム１０では、サービスを実現するための一連の処理に含まれる一の処理を実行するコンポーネントが、既存コンポーネント又は追加コンポーネントのいずれであるかを判別する。そして、本実施形態に係るサービス提供システム１０では、判別結果に応じて、既存コンポーネント又は追加コンポーネントを生成する。

このように、本実施形態に係るサービス提供システム１０では、例えばＪＡＲ形式等で開発や配布等される様々なコンポーネントを利用することができる。このため、例えば、アプリ情報１０００の開発者等は、追加コンポーネントも含めた様々なコンポーネントにより実行される処理で構成される一連の処理の内容を処理内容として記述することができる。したがって、本実施形態に係るサービス提供システム１０では、追加コンポーネントにより実行される処理を含む一連の処理で実現される多様なサービスを提供することができるようになる。

≪コンポーネントの追加、更新、及び削除処理≫
次に、本実施形態に係るサービス提供システム１０に対して追加コンポーネントを追加する場合や追加コンポーネントを更新する場合、追加コンポーネントを削除する場合の処理について、図１５を参照しながら説明する。図１５は、第一の実施形態に係るコンポーネントの追加、更新、及び削除処理の一例を示すシーケンス図である。

まず、コンポーネントの開発者等のユーザは、ＰＣ端末３０のブラウザ３１０により、コンポーネント編集画面の表示操作を行う。すると、ブラウザ３１０は、当該表示操作を受け付けて、例えば図１６（ａ）に示すコンポーネント編集画面５０００を、表示装置１２に表示させる（ステップＳ１５０１）。

図１６（ａ）に示すコンポーネント編集画面５０００は、追加コンポーネントの追加（登録）、更新、及び削除を行うための画面である。コンポーネント編集画面５０００には、新たなコンポーネントをコンポーネント情報テーブル３０００に登録するための追加ボタン５０１０、登録されている追加コンポーネントを更新するための更新ボタン５０２０、削除するための削除ボタン５０３０が含まれる。

コンポーネント編集画面５０００において、ユーザにより追加ボタン５０１０が選択された場合、ブラウザ３１０は、当該操作を受け付けて、例えば図１６（ｂ）に示すコンポーネント追加画面５１００を表示させる（ステップＳ１５０２）。

図１６（ｂ）に示すコンポーネント追加画面５１００は、コンポーネントを追加（登録）するための画面であり、コンポーネント名欄５１１０、ファイル欄５１２０、参照ボタン５１３０、及び登録ボタン５１４０が含まれる。

ユーザは、コンポーネント名欄５１１０に登録する追加コンポーネントのコンポーネント名を入力し、ファイル欄５１２０に追加コンポーネントの生成ファイルを指定した上で、登録ボタン５１４０を押下して、追加コンポーネントの登録操作を行う。すると、ブラウザ３１０は、当該登録操作を受け付ける（ステップＳ１５０３）。なお、ユーザは、参照ボタン５１３０を押下して生成ファイルの格納先の一覧を表示した上で、当該一覧から所望の生成ファイルを選択することで、ファイル欄５１２０に生成ファイルを指定しても良い。

ブラウザ３１０は、追加コンポーネントの登録操作を受け付けると、コンポーネントの登録を、コンポーネント管理部１３２に要求する（ステップＳ１５０４）。なお、コンポーネントの登録要求には、コンポーネント名欄５１１０に指定されたコンポーネント名と、ファイル欄５１２０に指定された生成ファイルとが含まれる。

コンポーネント管理部１３２は、コンポーネントの登録要求を受け取ると、コンポーネント登録部１３２４により、当該登録要求に含まれるコンポーネント名及び生成ファイルに基づきコンポーネント情報を作成する。そして、コンポーネント登録部１３２４は、作成したコンポーネント情報をコンポーネント情報テーブル３０００に登録する（ステップＳ１５０４）。これにより、本実施形態に係るサービス提供システム１０に追加コンポーネントが登録される。

なお、コンポーネント登録部１３２４は、当該登録要求に含まれるコンポーネント名と同一のコンポーネント名がコンポーネント情報テーブル３０００に存在しない場合、データ項目「バージョン」に「v1」を設定してコンポーネント情報を作成する。一方、コンポーネント登録部１３２４は、当該登録要求に含まれるコンポーネント名と同一のコンポーネント名がコンポーネント情報テーブル３０００に存在する場合、データ項目「バージョン」に最新のバージョンを付与してコンポーネント情報を作成する。

また、コンポーネント登録部１３２４は、当該登録要求に含まれる生成ファイルから追加コンポーネントの入力パラメータに関する情報を取得して、当該入力パラメータに関する情報を、データ項目「パラメータ」に設定してコンポーネント情報を作成する。なお、コンポーネント登録部１３２４は、例えばデータ形式が異なる等により、生成ファイルから入力パラメータに関する情報を取得することができない場合は、ユーザに入力パラメータに関する情報を指定させるための画面をＰＣ端末３０に表示させても良い。

コンポーネント編集画面５０００において、ユーザにより、更新を所望する追加コンポーネントのコンポーネント名及びバージョンが対応付けられた更新ボタン５０２０が選択された場合、ブラウザ３１０は、当該操作を受け付ける。そして、ブラウザ３１０は、例えば図１６（ｃ）に示すコンポーネント更新画面５２００を表示させる（ステップＳ１５０６）。

図１６（ｃ）に示すコンポーネント更新画面５２００は、追加コンポーネントを更新するための画面であり、ファイル欄５２１０、参照ボタン５２２０、及び更新ボタン５２３０が含まれる。

ユーザは、ファイル欄５２１０に生成ファイルを指定した上で、更新ボタン５２３０を押下して、追加コンポーネントの更新操作を行う。すると、ブラウザ３１０は、当該更新操作を受け付ける（ステップＳ１５０７）。なお、ユーザは、参照ボタン５２２０を押下して、生成ファイルの格納先の一覧を表示した上で、当該一覧から所望の生成ファイルを選択することで、ファイル欄５２１０に生成ファイルを指定しても良い。

ブラウザ３１０は、追加コンポーネントの更新操作を受け付けると、コンポーネントの更新を、コンポーネント管理部１３２に要求する（ステップＳ１５０８）。なお、コンポーネントの更新要求には、ユーザにより選択された更新ボタン５０２０に対応付けられたコンポーネント名及びバージョンと、ファイル欄５２１０に指定された生成ファイルとが含まれる。

コンポーネント管理部１３２は、コンポーネントの更新要求を受け取ると、コンポーネント登録部１３２４により、コンポーネント情報テーブル３０００に登録されているコンポーネント情報を更新する（ステップＳ１５０９）。すなわち、コンポーネント登録部１３２４は、当該登録要求に含まれるコンポーネント名及びバージョンに対応するコンポーネント情報のデータ項目「ファイル」を、当該登録要求に含まれる生成ファイルで上書きして更新する。これにより、本実施形態に係るサービス提供システム１０に登録されている追加コンポーネントが更新される。

なお、本実施形態に係るサービス提供システム１０は、追加コンポーネントの更新により、アプリ情報１０００に含まれる処理内容に基づく一連の処理が正常に実行することができなくなる場合、当該更新を行わないようにしても良い。又は、この場合、更新前のコンポーネント情報を残しつつ、更新後のコンポーネント情報をコンポーネント情報テーブル３０００に登録するようにしても良い。

また、本実施形態に係るサービス提供システム１０は、更新対象の追加コンポーネントを利用した一連の処理が実行中である場合、当該一連の処理の実行が完了した後、更新対象の追加コンポーネントを更新すれば良い。

コンポーネント編集画面５０００において、ユーザにより、削除を所望する追加コンポーネントのコンポーネント名及びバージョンに対応付けられた削除ボタン５０３０が選択された場合、ブラウザ３１０は、当該操作を受け付ける（ステップＳ１５１０）。

ブラウザ３１０は、追加コンポーネントの削除操作を受け付けると、コンポーネントの削除を、コンポーネント管理部１３２に要求する（ステップＳ１５１１）。なお、コンポーネントの削除要求には、ユーザにより選択された削除ボタン５０３０に対応付けられたコンポーネント名及びバージョンが含まれる。

コンポーネント管理部１３２は、コンポーネントの削除要求を受け取ると、コンポーネント登録部１３２４により、コンポーネント情報テーブル３０００に登録されているコンポーネント情報を削除する（ステップＳ１５１２）。すなわち、コンポーネント登録部１３２４は、当該削除要求に含まれるコンポーネント名及びバージョンに対応するコンポーネント情報を、コンポーネント情報テーブル３０００から削除する。これにより、本実施形態に係るサービス提供システム１０に登録されている追加コンポーネントが削除される。

以上のように、本実施形態に係るサービス提供システム１０では、ＰＣ端末３０等から追加コンポーネントの登録を行うことができる。このため、アプリ情報１０００の開発者等のユーザは、自身が開発するアプリ情報１０００が利用する追加コンポーネントをサービス提供システム１０に登録することができる。したがって、本実施形態に係るサービス提供システム１０では、様々なサービスを提供することができるようになる。

また、本実施形態に係るサービス提供システム１０では、登録されている追加コンポーネントを、ＰＣ端末３０等から更新や削除を行うことができる。このため、アプリ情報１０００の開発者等のユーザは、例えば、アプリ情報１０００が利用する追加コンポーネントの更新を行うことができ、柔軟にアプリ情報１０００を開発することができるようになる。

さらに、本実施形態に係るサービス提供システム１０では、例えばＪＡＲ形式等で開発や配布等される生成ファイルを登録することで、追加コンポーネントを利用することができるようになる。このため、本実施形態に係るサービス提供システム１０では、既存コンポーネントに影響を与えることなく、追加コンポーネントの登録、更新、削除を行うことができる。すなわち、本実施形態に係るサービス提供システム１０では、当該サービス提供システム１０を停止等させる必要なく、動的に追加コンポーネントの登録、更新、削除を行うことができる。

［第二の実施形態］
次に、第二の実施形態に係る情報処理システム１について説明する。第二の実施形態では、フロー実行処理において、実行されるコンポーネントが既存コンポーネント又は追加コンポーネントのいずれであるかを、第一の実施形態と異なる方法で判別する。なお、以降では、第一の実施形態と実質的に同一の機能を有する箇所及び同一の処理を行う箇所については、第一の実施形態と同一の符号を用いて、その説明を省略する。

＜ソフトウェア構成＞
本実施形態に係る情報処理システム１に含まれるサービス提供システム１０のロジック処理部１３０の処理ブロックについて、図１７を参照しながら説明する。図１７は、第二の実施形態に係るロジック処理部の一例の処理ブロックを示す図である。

本実施形態に係るロジック処理部１３０のコンポーネント管理部１３２は、コンポーネント判別部１３２１Ａを有する。また、本実施形態に係るロジック処理部１３０は、コンポーネント情報テーブル３０００Ａを利用する。

コンポーネント判別部１３２１Ａは、コンポーネントの取得要求に応じて、コンポーネント情報テーブル３０００Ａを参照し、当該取得要求に係るコンポーネントが、既存コンポーネント又は追加コンポーネントのいずれであるかを判別する。

ここで、コンポーネント情報テーブル３０００Ａについて、図１８を参照しながら説明する。図１８は、第二の実施形態に係るコンポーネント情報テーブルの一例を示す図である。

図１８に示すコンポーネント情報テーブル３０００Ａは、データ項目として、さらに、コンポーネント区分を有する。コンポーネント区分は、コンポーネント情報が、既存コンポーネントのコンポーネント情報又は追加コンポーネントのコンポーネント情報のいずれであるかを示す区分である。したがって、本実施形態に係るコンポーネント判別部１３２１Ａは、コンポーネント情報のコンポーネント区分を参照することで、コンポーネントの取得要求に係るコンポーネントが、既存コンポーネント又は追加コンポーネントのいずれであるかを判別することができる。

＜処理の詳細＞
次に、本実施形態に係る情報処理システム１の処理の詳細について説明する。

≪フロー実行処理≫
以降では、本実施形態に係るフロー実行処理について、図１９を参照しながら説明する。図１９は、第二の実施形態に係るフロー実行処理の一例を示すシーケンス図である。なお、第一の実施形態に係るフロー実行処理と同様の処理を行う箇所については、その説明を省略する。

コンポーネント管理部１３２は、コンポーネントの取得要求を受け取ると、コンポーネント判別部１３２１Ａにより、当該取得要求に係るコンポーネントが既存コンポーネント又は追加コンポーネントのいずれであるかを判別する（ステップＳ１９０１）。すなわち、コンポーネント判別部１３２１Ａは、コンポーネント情報テーブル３０００Ａを参照し、コンポーネント名「ocrB」、バージョン「v2」のコンポーネント情報のデータ項目「コンポーネント区分」が、「既存」又は「追加」のいずれであるかを判別する。

コンポーネント判別部１３２１Ａは、コンポーネント情報のデータ項目「コンポーネント区分」が「追加」である場合、取得要求に係るコンポーネントは追加コンポーネントであると判別する。一方、コンポーネント判別部１３２１Ａは、コンポーネント情報のデータ項目「コンポーネント区分」が「既存」である場合、取得要求に係るコンポーネントは既存コンポーネントであると判別する。

本実施形態では、コンポーネント情報テーブル３０００Ａにおいて、コンポーネント名「ocrB」、バージョン「v2」のコンポーネント情報は、データ項目「コンポーネント区分」が「追加」である。したがって、コンポーネント判別部１３２１Ａは、取得要求に係るコンポーネントが追加コンポーネントであると判別する。

コンポーネント管理部１３２は、コンポーネントの取得要求を受け取ると、コンポーネント判別部１３２１Ａにより、当該取得要求に係るコンポーネントが既存コンポーネント又は追加コンポーネントのいずれであるかを判別する（ステップＳ１９０２）。すなわち、コンポーネント判別部１３２１Ａは、コンポーネント情報テーブル３０００Ａを参照し、コンポーネント名「uploadA」、バージョン「v1」のコンポーネント情報のデータ項目「コンポーネント区分」が、「既存」又は「追加」のいずれであるかを判別する。

本実施形態では、コンポーネント情報テーブル３０００Ａにおいて、コンポーネント名「uploadA」、バージョン「v1」のコンポーネント情報は、データ項目「コンポーネント区分」が「既存」である。したがって、コンポーネント判別部１３２１Ａは、取得要求に係るコンポーネントが既存コンポーネントであると判別する。

以上のように、本実施形態に係るサービス提供システム１０では、コンポーネント情報のデータ項目「コンポーネント区分」を参照することで、取得要求に係るコンポーネントが既存コンポーネント又は追加コンポーネントのいずれであるかを判別する。これにより、本実施形態に係るサービス提供システム１０では、既存コンポーネント又は追加コンポーネントのいずれであるかの判別を、より簡易に行うことができる。

［第三の実施形態］
次に、第三の実施形態に係る情報処理システム１について説明する。第三の実施形態では、フロー実行処理において、既存コンポーネントも生成ファイルに基づいて生成する。なお、以降では、第二の実施形態と実質的に同一の機能を有する箇所及び同一の処理を行う箇所については、第二の実施形態と同一の符号を用いて、その説明を省略する。

＜ソフトウェア構成＞
本実施形態に係る情報処理システム１に含まれるサービス提供システム１０のロジック処理部１３０の処理ブロックについて、図２０を参照しながら説明する。図２０は、第三の実施形態に係るロジック処理部の一例の処理ブロックを示す図である。

本実施形態に係るロジック処理部１３０のコンポーネント管理部１３２は、既存コンポーネント生成部１３２２Ａを有する。また、本実施形態に係るロジック処理部１３０は、コンポーネント情報テーブル３０００Ｂを利用する。

既存コンポーネント生成部１３２２Ａは、コンポーネント判別部１３２１Ａによりコンポーネントの取得要求に係るコンポーネントが既存コンポーネントであると判別された場合、当該取得要求に係る既存コンポーネントを生成する。このとき、既存コンポーネント生成部１３２２Ａは、コンポーネント情報テーブル３０００Ｂから既存コンポーネントの生成ファイルを取得し、当該取得した生成ファイルに基づいて既存コンポーネントを生成する。

ここで、コンポーネント情報テーブル３０００Ｂについて、図２１を参照しながら説明する。図２１は、第三の実施形態に係るコンポーネント情報テーブルの一例を示す図である。

図２１に示すコンポーネント情報テーブル３０００Ｂは、既存コンポーネントのコンポーネント情報のデータ項目「ファイル」に、生成ファイルが格納されている。このように、本実施形態に係るコンポーネント情報テーブル３０００Ｂは、既存コンポーネントの生成ファイルも管理している。

＜処理の詳細＞
次に、本実施形態に係る情報処理システム１の処理の詳細について説明する。

≪フロー実行処理≫
以降では、本実施形態に係るフロー実行処理について、図２２を参照しながら説明する。図２２は、第三の実施形態に係るフロー実行処理の一例を示すシーケンス図である。なお、第二の実施形態に係るフロー実行処理と同様の処理を行う箇所については、その説明を省略する。

既存コンポーネント生成部１３２２Ａは、コンポーネントの取得要求を受け取ると、コンポーネント名「uploadA」、バージョン「v1」に基づき、コンポーネント情報テーブル３０００Ｂからコンポーネントの生成ファイルを取得する（ステップＳ２２０１）。すなわち、既存コンポーネント生成部１３２２Ａは、コンポーネント名「uploadA」、バージョン「v1」のコンポーネント情報のデータ項目「ファイル」に格納されている生成ファイルを取得する。

次に、既存コンポーネント生成部１３２２Ａは、取得した生成ファイルに基づいて既存コンポーネントを生成する（ステップＳ２２０２）。すなわち、既存コンポーネント生成部１３２２Ａは、コンポーネント名「uploadA」、バージョン「v1」のコンポーネント情報から取得した生成ファイルに基づいて、配信Ａコンポーネント１３３３を生成する。なお、配信Ａコンポーネント１３３３の生成は、例えば、ＪＡＲ形式の生成ファイルを実行して、コンポーネント共通Ｉ／Ｆ１３３０に定義されたコンポーネントを生成するためのＡＰＩを用いて行うことができる。

そして、既存コンポーネント生成部１３２２Ａは、配信Ａコンポーネント１３３３が生成されると、配信Ａコンポーネント１３３３をフロー実行部１３１に返信する。これは、例えば、既存コンポーネント生成部１３２２Ａは、配信Ａコンポーネント１３３３が展開されたメモリ（例えばＲＡＭ１４）上のアドレスを、フロー実行部１３１に返信すれば良い。

以上のように、本実施形態に係るサービス提供システム１０では、コンポーネント情報テーブル３０００Ｂに格納された生成ファイルに基づいて、既存コンポーネントの生成を行う。これにより、本実施形態に係るサービス提供システム１０では、既存コンポーネントと追加コンポーネントを同様に管理することができる。

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

１ 情報処理システム
１０ サービス提供システム
２０ 画像形成装置
３０ ＰＣ端末
４０ 外部ストレージシステム
１１０ サービス処理部
１２０ アプリ管理部
１３０ ロジック処理部
１３１ フロー実行部
１３２ コンポーネント管理部
１３３ コンポーネント群
１３４ 型変換管理部
１３５ 型変換群
１４０ データＩ／Ｆ部
１５０ ドキュメントサービス部
１５１ ＯＣＲ処理
１６０ ストレージサービス連携部
１７０ ファイル処理部
１８０ データ処理部
１９０ アプリ情報記憶部
１０００ アプリ情報
１３２１ コンポーネント判別部
１３２２ 既存コンポーネント生成部
１３２３ 追加コンポーネント生成部
１３２４ コンポーネント登録部
３０００ コンポーネント情報テーブル
４０００ 型変換テーブル

特開２０１４−０３２６５９号公報

Claims (11)

1. １以上の情報処理装置が含まれる情報処理システムであって、
   電子データを用いた一連の処理を、該一連の処理それぞれを実行するコンポーネントを組み合わせて実行するアプリケーション毎に、該アプリケーションを識別するアプリ識別情報と、前記一連の処理に関する情報と、前記一連の処理に用いる前記電子データを指定させる画面の画面情報と、を関連付けて記憶する第１の記憶手段と、
   前記コンポーネントに関する情報を記憶する第２の記憶手段と、
   前記情報処理システムに接続される１以上の機器のうちの一の機器から前記アプリ識別情報を含む第１の要求を受け付けると、該第１の要求に含まれる該アプリ識別情報に関連付けて前記第１の記憶手段に記憶されている前記画面情報を、要求元の前記一の機器に送信する送信手段と、
   前記送信手段により送信された前記画面情報に基づき前記一の機器に表示された画面を介してユーザにより指定された電子データに関する情報を含む第２の要求を前記一の機器から受け付けると、前記アプリ識別情報に関連付けて前記第１の記憶手段に記憶されている前記一連の処理に関する情報に基づく一連の処理を、前記第２の要求に含まれる前記電子データに関する情報により指定される電子データを用いて実行する処理実行手段と
   を有し、
   前記処理実行手段は、
   前記一連の処理に関する情報と前記コンポーネントに関する情報とに基づき生成されたコンポーネントを組み合わせて、前記電子データを用いた前記一連の処理を実行する、情報処理システム。
2. 前記コンポーネントには、ユーザにより登録された第１のコンポーネントと、前記情報処理システムに予め組み込まれている第２のコンポーネントとが含まれ、
   前記処理実行手段は、
   前記一連の処理のそれぞれの処理毎に、該一連の処理に関する情報と前記コンポーネントに関する情報と基づき、前記第１のコンポーネント又は前記第２のコンポーネントのいずれを生成するかを判別する判別手段を有し、
   前記判別手段による判別結果に応じて生成された第１のコンポーネント又は第２のコンポーネントを組み合わせて、前記電子データを用いた前記一連の処理を実行する、請求項１に記載の情報処理システム。
3. 前記判別手段は、
   前記コンポーネントに関する情報に、該コンポーネントを生成するための生成ファイルが含まれる場合、前記第１のコンポーネントを生成すると判別する、請求項２に記載の情報処理システム。
4. 前記処理実行手段は、
   前記第１のコンポーネントを生成する第１の生成手段と、
   前記第２のコンポーネントを生成する第２の生成手段と、を有し、
   前記判別手段により前記第１のコンポーネントを生成すると判別された場合、前記第１の生成手段により前記第１のコンポーネントを生成し、
   前記判別手段により前記第２のコンポーネントを生成すると判別された場合、前記第２の生成手段により前記第２のコンポーネントを生成する、請求項３に記載の情報処理システム。
5. 前記第１の生成手段は、前記コンポーネントに関する情報に含まれる前記生成ファイルに基づいて、前記第１のコンポーネントを生成する、請求項４に記載の情報処理システム。
6. 前記処理実行手段は、
   前記機器に表示された画面を介してユーザにより指定された生成ファイルを含む第３の要求を受け付けると、該第３の要求に含まれる前記生成ファイルを含むコンポーネントに関する情報を前記第２の記憶手段に記憶させて、該生成ファイルにより生成される第１のコンポーネントを登録する登録手段を有する、請求項５に記載の情報処理システム。
7. 前記処理実行手段は、
   電子データに対して、該電子データのデータ型を所定のデータ型に変換する型変換手段を１以上有し、
   前記電子データのデータ型を前記型変換手段により該コンポーネントが処理可能なデータ型に変換した後、前記コンポーネントの処理を実行することにより、前記電子データを用いた前記一連の処理を実行する、請求項１ないし６のいずれか１項に記載の情報処理システム。
8. 前記コンポーネントは、外部サービスに関する処理を実行するコンポーネントを含み、
   前記外部サービスに関する処理を実行するコンポーネントは、
   外部サービスに対して電子データをアップロードする処理を実行するコンポーネントを少なくとも含む、請求項１ないし７のいずれか１項に記載の情報処理システム。
9. 情報処理装置であって、
   電子データを用いた一連の処理を、該一連の処理それぞれを実行するコンポーネントを組み合わせて実行するアプリケーション毎に、該アプリケーションを識別するアプリ識別情報と、前記一連の処理に関する情報と、前記一連の処理に用いる前記電子データを指定させる画面の画面情報と、を関連付けて記憶する第１の記憶手段と、
   前記コンポーネントに関する情報を記憶する第２の記憶手段と、
   前記情報処理装置に接続される１以上の機器のうちの一の機器から前記アプリ識別情報を含む第１の要求を受け付けると、該第１の要求に含まれる該アプリ識別情報に関連付けて前記第１の記憶手段に記憶されている前記画面情報を、要求元の前記一の機器に送信する送信手段と、
   前記送信手段により送信された前記画面情報に基づき前記一の機器に表示された画面を介してユーザにより指定された電子データに関する情報を含む第２の要求を前記一の機器から受け付けると、前記アプリ識別情報に関連付けて前記第１の記憶手段に記憶されている前記一連の処理に関する情報に基づく一連の処理を、前記第２の要求に含まれる前記電子データに関する情報により指定される電子データを用いて実行する処理実行手段と
   を有し、
   前記処理実行手段は、
   前記一連の処理に関する情報と前記コンポーネントに関する情報とに基づき生成されたコンポーネントを組み合わせて、前記電子データを用いた前記一連の処理を実行する、情報処理装置。
10. １以上の情報処理装置が含まれる情報処理システムであって、電子データを用いた一連の処理を、該一連の処理それぞれを実行するコンポーネントを組み合わせて実行するアプリケーション毎に、該アプリケーションを識別するアプリ識別情報と、前記一連の処理に関する情報と、前記一連の処理に用いる前記電子データを指定させる画面の画面情報と、を関連付けて記憶する第１の記憶手段と、前記コンポーネントに関する情報を記憶する第２の記憶手段とを有する情報処理システムに用いられる情報処理方法において、
    前記情報処理システムに接続される１以上の機器のうちの一の機器から前記アプリ識別情報を含む第１の要求を受け付けると、該第１の要求に含まれる該アプリ識別情報に関連付けて前記第１の記憶手段に記憶されている前記画面情報を、要求元の前記一の機器に送信する送信手順と、
    前記送信手順により送信された前記画面情報に基づき前記一の機器に表示された画面を介してユーザにより指定された電子データに関する情報を含む第２の要求を前記一の機器から受け付けると、前記アプリ識別情報に関連付けて前記第１の記憶手段に記憶されている前記一連の処理に関する情報に基づく一連の処理を、前記第２の要求に含まれる前記電子データに関する情報により指定される電子データを用いて実行する処理実行手順と
    を有し、
    前記処理実行手順は、
    前記一連の処理に関する情報と前記コンポーネントに関する情報とに基づき生成されたコンポーネントを組み合わせて、前記電子データを用いた前記一連の処理を実行する、情報処理方法。
11. 電子データを用いた一連の処理を、該一連の処理それぞれを実行するコンポーネントを組み合わせて実行するアプリケーション毎に、該アプリケーションを識別するアプリ識別情報と、前記一連の処理に関する情報と、前記一連の処理に用いる前記電子データを指定させる画面の画面情報と、を関連付けて記憶する第１の記憶手段と、前記コンポーネントに関する情報を記憶する第２の記憶手段とを有する情報処理装置に、
    前記情報処理装置に接続される１以上の機器のうちの一の機器から前記アプリ識別情報を含む第１の要求を受け付けると、該第１の要求に含まれる該アプリ識別情報に関連付けて前記第１の記憶手段に記憶されている前記画面情報を、要求元の前記一の機器に送信する送信手順、
    前記送信手順により送信された前記画面情報に基づき前記一の機器に表示された画面を介してユーザにより指定された電子データに関する情報を含む第２の要求を前記一の機器から受け付けると、前記アプリ識別情報に関連付けて前記第１の記憶手段に記憶されている前記一連の処理に関する情報に基づく一連の処理を、前記第２の要求に含まれる前記電子データに関する情報により指定される電子データを用いて実行する処理実行手順
    を実行させ、
    前記処理実行手順は、
    前記一連の処理に関する情報と前記コンポーネントに関する情報とに基づき生成されたコンポーネントを組み合わせて、前記電子データを用いた前記一連の処理を実行する、プログラム。

Images