JP2021016147A - 情報処理システム、情報処理方法、機器 - Google Patents

Abstract

【課題】処理の拡張が容易な情報処理システムを提供すること。【解決手段】サービス提供システム１０は、機器２０が出力する出力データの識別情報に対応付けて処理方法が登録された処理方法記憶部１３と、出力データの識別情報を付加した出力データを機器に送信する第一の通信部１６と、を有し、機器は、サービス提供システムから受信した出力データを出力データの識別情報と共に出力する出力部２３と、出力部が出力した出力データに基づく入力データの入力を出力データの識別情報と共に受け付ける入力部２４と、入力部により入力された出力データの識別情報が付加されている入力データをサービス提供システムに送信する第二の通信部２５と、を有し、サービス提供システムは、入力データに付加されている出力データの識別情報に対応付けられている処理方法で前記入力データを処理することを特徴とする。【選択図】図１

Description

本発明は、情報処理システム、情報処理方法、及び、機器に関する。

機器のスキャナ機能又はファクス受信機能で入力された画像データに対し１つ以上の処理を行い配信する情報処理システムが知られている。情報処理システムは予め決まっている一連の処理（ワークフロー）を画像データに対し順に施すためワークフローシステムと呼ばれる場合がある。

情報処理システムが行う処理を自動で切り替える技術が知られている（例えば、特許文献１参照。）。特許文献１には、機器が読み取る原稿に画像コードを形成しておき、情報処理システムは読み取られた画像データの画像コードを解析して解析結果に基づき処理を切り替えるシステムが開示されている。

しかしながら、従来の技術では、処理の拡張が容易でないという問題があった。例えば、ワークフローの処理結果の配信先を変更する場合、管理者等は新しいワークフローを作成し、このワークフローに対応した新規の識別子を形成した原稿を機器で印刷する。そして、機器が原稿を読み取って識別子に対応した新規のワークフローを実行する。したがって、従来はワークフローに拡張を施す場合でも、印刷時と読取時それぞれに対応が必要であった。

本発明は、上記課題に鑑み、処理の拡張が容易な情報処理システムを提供することを目的とする。

上記課題に鑑み、本発明は、サービス提供システムと機器とがネットワークを介して通信する情報処理システムであって、前記サービス提供システムは、前記機器が出力する出力データの識別情報に対応付けて処理方法が登録された処理方法記憶部と、前記出力データの識別情報を付加した前記出力データを前記機器に送信する第一の通信部と、を有し、前記機器は、前記サービス提供システムから受信した前記出力データを前記出力データの識別情報と共に出力する出力部と、前記出力部が出力した前記出力データに基づく入力データの入力を前記出力データの識別情報と共に受け付ける入力部と、前記入力部により入力された前記出力データの識別情報が付加されている前記入力データを前記サービス提供システムに送信する第二の通信部と、を有し、前記サービス提供システムは、前記入力データに付加されている前記出力データの識別情報に対応付けられている前記処理方法で前記入力データを処理することを特徴とする。

処理の拡張が容易な情報処理システムを提供することができる。

情報処理システムの動作の概略を説明する一例の図である。 情報処理システムの一例の構成図である。 サービス提供システムの一例のハードウェア構成図である。 機器の一例のハードウェア構成図である。 サービス提供システムと機器の機能をブロック状に示す機能ブロック図の一例である。 ワークフローの一例を説明する図である。 印刷のワークフローの設定画面の一例である。 読取のワークフローの設定画面の一例である。 印刷のワークフロー、読取のワークフローの設定、読取のワークフローの実行、及び、申請書の確認の処理の流れを説明するシーケンス図の一例である。 基本となる印刷と読取の全体の流れを示す一例のシーケンス図である。 印刷のワークフローにおいて、情報処理システムが実行する処理を説明するシーケンス図の一例である。 ホーム画面の一例を示す図である。 印刷用画面の一例を示す図である。 印刷設定画面の一例を示す図である。 機器が印刷した原稿の一例を示す図である。 読取のワークフローにおいて、情報処理システムが実行する処理を説明する一例のシーケンス図である。 読取用画面の一例を示す図である。 読取設定・実行画面の一例を示す図である。 読取・処理結果画面の一例を示す図である。 ＦＡＸ送信を含む一例の読取のワークフローを示す図である。 ＦＡＸ送信を含むワークフローに対応した一例の処理方法情報を示す図である。 読取のワークフローにおいて、情報処理システムが実行する処理を説明する一例のシーケンス図である。 印刷のワークフローにおいて、情報処理システムが実行する処理を説明する一例のシーケンス図である。 認証画面の一例を示す図である。 読取のワークフローにおいて、情報処理システムが実行する処理を説明する一例のシーケンス図である。 読取のワークフローにおいて、情報処理システムが実行する処理を説明する一例のシーケンス図である。 読取用画面の一例を示す図である。 読取のワークフローにおいて、情報処理システムが実行する処理を説明する一例のシーケンス図である。 読取用画面の一例を示す図である。 読取のワークフローにおいて、情報処理システムが実行する処理を説明する一例のシーケンス図である。 読取・処理結果画面の一例を示す図である。 情報処理システムの別の構成図の一例である。 情報処理システムの全体的な処理の流れを示す一例のフローチャート図である。 実施例７に係る情報処理システムの一例の構成図である。 実施例７に係る情報処理システムの一例の処理ブロック図である。 共通Ｉ／Ｆ及び固有Ｉ／Ｆの一例を説明するための図である。 データ定義の一例を説明するための図である。 レイアウト情報の一例を説明するための図である。 処理内容の一例を説明するための図である。 ロジック処理部の一例の処理ブロック図である。 型変換テーブルの一例を説明するための図である。 コンポーネント管理テーブルの一例を説明するための図である。 外部コンポーネント処理部の一例の処理ブロック図である。 スキャン配信サービスの全体処理の一例のシーケンス図である。 スキャン配信サービスを利用するためのアプリ画面の一例を説明するための図である。 ＯＣＲから配信実行までの処理の一例のシーケンス図である。 処理内容の他の例を説明するための図である。 外部コンポーネント処理の一例のシーケンス図である。 処理内容の作成処理の一例のシーケンス図である。 処理内容の作成の一例を説明するための図である。

以下、本発明を実施するための形態の一例として、情報処理システム１と情報処理システム１が行う情報処理方法について図面を参照しながら説明する。

＜動作の概略＞
図１は、本実施形態の情報処理システム１の動作の概略を説明する図である。本実施形態では印刷のワークフローと読取のワークフローを処理方法情報により連携させる。処理方法情報は管理者が編集できるため、ワークフローを容易に拡張することができる。

まず、図１（ａ）に基づいて、印刷のワークフロー（第一のワークフローの一例）について説明する。

(1) ユーザはまず、印刷のワークフローを選択する。これにより、サービス提供システム１０が印刷データ記憶部１１から取得した原稿種別を機器２０が表示する。ユーザは自分がワークフローで印刷したい原稿種別を選択する。

(2) 機器２０は原稿種別をサービス提供システムに送信し、サービス提供システム１０が原稿種別に対応付けられているＩＤを処理方法記憶部１３から取得する。処理方法記憶部１３には処理方法情報（ＩＤ：原稿種別：処理方法）が登録されている。ＩＤは原稿を識別する識別情報であると共に、印刷のワークフローと読取のワークフローを連携させる情報である。原稿種別は申請書など各種の原稿の書類名等、原稿を特定する情報である。処理方法は読取のワークフローにおいて原稿の画像データをどのように処理するかを示す。

また、サービス提供システム１０は印刷データ記憶部１１から原稿種別が示す原稿の印刷データを取得する。

(3) サービス提供システム１０はＩＤを画像コード（例えば、ＱＲコード（登録商標））９に変換して原稿の印刷データに形成し、機器２０に送信する。これにより、機器２０は画像コード９が形成された原稿を印刷できる。

(4) ユーザは読取のワークフローのために原稿に必要事項を記入する。必ずしも記入しなくてもよい。

次に、図１（ｂ）に基づいて、読取のワークフロー（第二のワークフローの一例）について説明する。

(1) ユーザは必要事項を記入した原稿を機器２０で読み取る。

(2) 機器２０は原稿の画像データをサービス提供システムに送信し、サービス提供システム１０が画像コード９を解析してＩＤを取り出す。サービス提供システム１０はこのＩＤに対応付けられている処理方法を処理方法記憶部１３から取得する。

(3) サービス提供システム１０は、原稿の画像データを処理方法に基づいて処理する。例えば、処理方法で指定されたフォルダに配信したり、電子メールで通知したりする。

このように、印刷時と読取時に共通の処理方法記憶部１３を参照して、印刷のワークフローと読取のワークフローを連携させるので、ワークフローを拡張したい場合も処理方法を修正するだけで対応できる。管理者が処理方法を設定することで、ワークフローを変更できる。処理方法記憶部１３には「ＩＤ：原稿種別：処理方法」を設定すればよいので、ワークフローを容易に拡張できる。

ユーザが原稿を選択すれば、原稿種別に応じた処理方法で画像データを処理できる。印刷のワークフロー及び読取のワークフローそのものを変更しなくても、ユーザが選んだ原稿に応じてワークフローを拡張できる。

＜用語について＞
出力データとは機器が出力するデータであり、出力の形態は単なる表示でも印刷でもよい。印刷した場合、出力データを画像データといい、表示した場合は表示データという。

処理方法は、入力データをどのように処理するかに関する情報である。例えば、配信先、通知先、送信先、などが指定されうる。

出力データの種別は、個別の出力データであり、出力データは同じでも異なる種別が付されていてよい。本実施形態では原稿種別という用語で説明される。

出力データに基づく入力データは、出力データが含まれていると認識可能なデータであればよい。例えば、出力データをそのまま含むデータ、出力データに文字等が追加されているデータ、出力データが加工されているデータなどがある。

ワークフローの拡張とは既存のワークフローと異なる処理を行うことであり、ワークフローの変更と称してもよいし、異なる処理を行うワークフローを追加すると称してもよい。

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

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

サービス提供環境Ｅ１は、一台以上の情報処理装置で実現されるサービス提供システム１０を有する。サービス提供システム１０は、ネットワークを介して所定のサービスを提供する。例えば、サービス提供システム１０は、ユーザ環境Ｅ２の機器２０において原稿をスキャンして生成された電子ファイルを、ＯＣＲ（Optical Character Reader）処理して、外部システム３０に保存するサービス（スキャン配信サービス）を提供する。また、例えば、サービス提供システム１０は、外部システム３０に保存されている電子ファイルを、ユーザ環境Ｅ２の機器２０で印刷するサービス（クラウドプリントサービス）を提供する。本実施形態では、サービス提供システム１０は、このようなスキャン配信サービス及びクラウドプリントサービスを提供するものとして説明する。

ただし、サービス提供システム１０により提供されるサービスは、これらに限られず、例えば、外部システム３０に保存されている電子ファイルを、ユーザ環境Ｅ２のプロジェクタで投影するサービス等であってもよい。また、機器２０において原稿をスキャンして生成された電子ファイルを、ＯＣＲ処理した後、所定の言語に翻訳（例えば、英語から日本語に翻訳）して、外部システム３０に保存するサービス等であってもよい。

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

ユーザ環境Ｅ２は、例えば機器２０を使用するユーザである企業等におけるシステム環境である。ユーザ環境Ｅ２では、一台以上の機器２０、第一の端末装置５０及び第二の端末装置６０が例えばＬＡＮ（Local Area Network）等のネットワークを介して接続されている。

本実施形態に係る機器２０は、プリンタ機能及びスキャナ機能を有する画像形成装置である。なお、機器２０は、プリンタ機能及びスキャナ機能以外に、コピー機能やファクス（ＦＡＸ）通信機能等を備える複合機等でもよい。なお、以降では、複数の機器２０について、各々を区別するときは、「機器２０_１」、「機器２０_２」等と添え字を用いて記載する。

機器２０は、プリンタ機能を有する装置と、スキャナ機能を有する装置とが別体でもよい。機器２０がプリンタ機能及びスキャナ機能を有しているとしても、印刷する機器２０とスキャンする機器２０が異なっていてよい。また機器２０は後述のようにブラウザを備え、ブラウザはサービス提供システム１０等の提供する各種サービスのワークフローを構成する、Ｗｅｂアプリケーションの表示や処理、処理の実行指示等を行うことができる。なお、機器２０は専用アプリケーションがインストールされ、専用アプリケーションとＷｅｂアプリケーションとが連携することによって同様の処理を実行してもよい。その場合、専用アプリケーションで、Ｗｅｂアプリケーションの処理の一部を分担して行ってもよい。

第一の端末装置５０は管理者が操作するスマートフォンや携帯電話、タブレットＰＣ、デスクトップＰＣ、ノートＰＣ、等の情報処理装置である。第一の端末装置５０には、Ｗｅｂブラウザなどの画面表示機能を有するプログラムが搭載されている。このプログラムはサービス提供システム１０から受信した画面情報を画面として表示する機能を有していればよくＷｅｂブラウザに限られない。サービス提供システム１０に専用のプログラムでもよい。なお複数人の管理者が異なる第一の端末装置５０を用いて、それぞれで操作を行ってもよい。

第二の端末装置６０は、一般ユーザが利用するスマートフォンや携帯電話、タブレットＰＣ、デスクトップＰＣ、ノートＰＣ、等の情報処理装置である。第二の端末装置６０には、Ｗｅｂブラウザなどの画面表示機能を有するプログラムが搭載されている。このプログラムはサービス提供システム１０から受信した画面情報を画面として表示する機能を有していればよくＷｅｂブラウザに限られない。サービス提供システム１０に専用のプログラムでもよい。なお複数人のユーザが異なる第二の端末装置６０を用いて、それぞれで操作を行ってもよい。

外部システム３０は、企業の基幹システム、又は、外部の会社が提供するシステムなどである。外部システム３０は、一例として、ネットワークを介してストレージサービス（又はオンラインストレージ）と呼ばれるクラウドサービスを提供するコンピュータシステムである。ストレージサービスとは、外部システム３０のストレージの記憶領域を貸し出すサービスである。本実施形態では、スキャン配信サービスにおいて、外部システム３０によって貸し出される記憶領域に、ＯＣＲ処理された電子ファイルを保存（アップロード）する。また、本実施形態では、クラウドプリントサービスにおいて、外部システム３０によって貸し出される記憶領域から印刷対象となる電子ファイルを取得（ダウンロード）する。なお、以降では、複数の外部システム３０について、各々を区別するときは、「外部システム３０_１」、「外部システム３０_２」等と添え字を用いて記載する。また、外部システム３０_１によって提供されるサービスの名称を「ストレージサービスＡ」、外部システム３０_２によって提供されるサービスの名称を「ストレージサービスＢ」等とする。

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

＜ハードウェア構成＞
<<サービス提供システム>>
図３は、サービス提供システムのハードウェア構成図である。図３に示されているように、サービス提供システムは、コンピュータによって構築されており、図３に示されているように、ＣＰＵ５０１、ＲＯＭ５０２、ＲＡＭ５０３、ＨＤ５０４、ＨＤＤ(Hard Disk Drive)コントローラ５０５、ディスプレイ５０６、外部機器接続Ｉ／Ｆ(Interface)５０８、ネットワークＩ／Ｆ５０９、バスライン５１０、キーボード５１１、ポインティングデバイス５１２、ＤＶＤ−ＲＷ(Digital Versatile Disk Rewritable)ドライブ５１４、メディアＩ／Ｆ５１６を備えている。

これらのうち、ＣＰＵ５０１は、サービス提供システム全体の動作を制御する。ＲＯＭ５０２は、ＩＰＬ等のＣＰＵ５０１の駆動に用いられるプログラムを記憶する。ＲＡＭ５０３は、ＣＰＵ５０１のワークエリアとして使用される。ＨＤ５０４は、プログラム等の各種データを記憶する。ＨＤＤコントローラ５０５は、ＣＰＵ５０１の制御にしたがってＨＤ５０４に対する各種データの読み出し又は書き込みを制御する。ディスプレイ５０６は、カーソル、メニュー、ウィンドウ、文字、又は画像などの各種情報を表示する。外部機器接続Ｉ／Ｆ５０８は、各種の外部機器を接続するためのインターフェースである。この場合の外部機器は、例えば、ＵＳＢ(Universal Serial Bus)メモリやプリンタ等である。ネットワークＩ／Ｆ５０９は、通信ネットワーク１００を利用してデータ通信をするためのインターフェースである。バスライン５１０は、図３に示されているＣＰＵ５０１等の各構成要素を電気的に接続するためのアドレスバスやデータバス等である。

また、キーボード５１１は、文字、数値、各種指示などの入力のための複数のキーを備えた入力手段の一種である。ポインティングデバイス５１２は、各種指示の選択や実行、処理対象の選択、カーソルの移動などを行う入力手段の一種である。ＤＶＤ−ＲＷドライブ５１４は、着脱可能な記録媒体の一例としてのＤＶＤ−ＲＷ５１３に対する各種データの読み出し又は書き込みを制御する。なお、ＤＶＤ−ＲＷに限らず、ＤＶＤ−Ｒ等であってもよい。メディアＩ／Ｆ５１６は、フラッシュメモリ等の記録メディア５１５に対するデータの読み出し又は書き込み（記憶）を制御する。

<<機器>>
図４は、機器のハードウェア構成図である。図４に示されているように、機器は、コントローラ９１０、近距離通信回路９２０、エンジン制御部９３０、操作パネル９４０、ネットワークＩ／Ｆ９５０を備えている。なお、機器２０のハードウェア構成は、図４に示す構成に限定されない。例えば、操作パネル９４０はＡＳＩＣ９０６ではなく、ＳＢ１０４に接続される構成であってもよい。

これらのうち、コントローラ９１０は、コンピュータの主要部であるＣＰＵ９０１、システムメモリ（ＭＥＭ−Ｐ）９０２、ノースブリッジ（ＮＢ）９０３、サウスブリッジ（ＳＢ）９０４、ＡＳＩＣ(Application Specific Integrated Circuit)９０６、記憶部であるローカルメモリ（ＭＥＭ−Ｃ）９０７、ＨＤＤコントローラ９０８、及び、記憶部であるＨＤ９０９を有し、ＮＢ９０３とＡＳＩＣ９０６との間をＡＧＰ(Accelerated Graphics Port)バス９２１で接続した構成となっている。ただし、コントローラ９１０の構成はこれに限定されない。例えば、ＣＰＵ９０１、ＮＢ９０３、ＳＢ９０４などの２以上の構成要素をＳｏＣ（System on Chip）によって実現してもよい。この場合、ＳｏＣとＡＳＩＣ９０６との間をPCI−express（登録商標） バスで接続してもよい。

これらのうち、ＣＰＵ９０１は、機器２０の全体制御を行う制御部である。ＮＢ９０３は、ＣＰＵ９０１と、ＭＥＭ−Ｐ９０２、ＳＢ９０４、及びＡＧＰバス９２１とを接続するためのブリッジであり、ＭＥＭ−Ｐ９０２に対する読み書きなどを制御するメモリコントローラと、ＰＣＩ(Peripheral Component Interconnect)マスタ及びＡＧＰターゲットとを有する。

ＭＥＭ−Ｐ９０２は、コントローラ９１０の各機能を実現させるプログラムやデータの格納用メモリであるＲＯＭ９０２ａ、プログラムやデータの展開、及びメモリ印刷時の描画用メモリなどとして用いるＲＡＭ９０２ｂとからなる。なお、ＲＡＭ９０２ｂに記憶されているプログラムは、インストール可能な形式又は実行可能な形式のファイルでＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＤＶＤ等のコンピュータで読み取り可能な記録媒体に記録して提供するように構成してもよい。

ＳＢ９０４は、ＮＢ９０３とＰＣＩデバイス、周辺デバイスとを接続するためのブリッジである。ＡＳＩＣ９０６は、画像処理用のハードウェア要素を有する画像処理用途向けのＩＣ(Integrated Circuit)であり、ＡＧＰバス９２１、ＰＣＩバス９２２、ＨＤＤコントローラ９０８及びＭＥＭ−Ｃ９０７をそれぞれ接続するブリッジの役割を有する。このＡＳＩＣ９０６は、ＰＣＩターゲット及びＡＧＰマスタ、ＡＳＩＣ９０６の中核をなすアービタ（ＡＲＢ）、ＭＥＭ−Ｃ９０７を制御するメモリコントローラ、ハードウェアロジックなどにより画像データの回転などを行う複数のＤＭＡＣ(Direct Memory Access Controller)、並びに、スキャナ部９３１及びプリンタ部９３２との間でＰＣＩバス９２２を介したデータ転送を行うＰＣＩユニットとからなる。なお、ＡＳＩＣ９０６には、ＵＳＢ(Universal Serial Bus)のインターフェースや、ＩＥＥＥ１３９４(Institute of Electrical and Electronics Engineers 1394）のインターフェースを接続するようにしてもよい。

ＭＥＭ−Ｃ９０７は、コピー用画像バッファ及び符号バッファとして用いるローカルメモリである。ＨＤ９０９は、画像データの蓄積、印刷時に用いるフォントデータの蓄積、フォームの蓄積を行うためのストレージである。ＨＤ９０９は、ＣＰＵ９０１の制御にしたがってＨＤ９０９に対するデータの読出又は書込を制御する。ＡＧＰバス９２１は、グラフィック処理を高速化するために提案されたグラフィックスアクセラレータカード用のバスインタフェースであり、ＭＥＭ−Ｐ９０２に高スループットで直接アクセスすることにより、グラフィックスアクセラレータカードを高速にすることができる。ただし、ＭＥＭ−Ｃ１０７は搭載されていなくても良い。

また、近距離通信回路９２０には、近距離通信回路９２０ａが備わっている。近距離通信回路９２０は、ＮＦＣ、Ｂｌｕｅｔｏｏｔｈ（登録商標）等の通信回路である。

更に、エンジン制御部９３０は、スキャナ部９３１及びプリンタ部９３２によって構成されている。また、操作パネル９４０は、現在の設定値や選択画面等を表示させ、操作者からの入力を受け付けるタッチパネル等のパネル表示処理部２１９４０ａ、並びに、濃度の設定条件などの画像形成に関する条件の設定値を受け付けるテンキー及びコピー開始指示を受け付けるスタートキー等からなるハードキー９４０ｂを備えている。コントローラ９１０は、機器２０全体の制御を行い、例えば、描画、通信、操作パネル９４０からの入力等を制御する。スキャナ部９３１又はプリンタ部９３２には、誤差拡散やガンマ変換などの画像処理部分が含まれている。

なお、機器２０は、操作パネル９４０のアプリケーション切り替えキーにより、ドキュメントボックス機能、コピー機能、プリンタ機能、及び、ファクシミリ機能を順次に切り替えて選択することが可能となる。ドキュメントボックス機能の選択時にはドキュメントボックスモードとなり、コピー機能の選択時にはコピーモードとなり、プリンタ機能の選択時にはプリンタモードとなり、ファクシミリモードの選択時にはファクシミリモードとなる。操作パネル９４０は、各種情報を表示するＬＣＤや動作状態を点灯／消灯により表示するＬＥＤといった表示処理部２１及びタッチパネルやハードキースイッチを有する入力部等を備えている。なお、操作パネル９４０はタッチパネルを備える場合にはハードキースイッチはなくてもよい。

また、ネットワークＩ／Ｆ９５０は、通信ネットワーク１００を利用してデータ通信をするためのインターフェースである。近距離通信回路９２０及びネットワークＩ／Ｆ９５０は、ＰＣＩバス９２２を介して、ＡＳＩＣ９０６に電気的に接続されている。

＜機能について＞
図５は、サービス提供システム１０と機器２０の機能をブロック状に示す機能ブロック図の一例である。

<<機器>>
機器２０は、表示処理部２１、操作受付部２２、出力部２３、入力部２４、通信部２５、及び、認証部２６を有している。機器２０が有するこれら各機能は、図４に示されている各構成要素のいずれかが、ＨＤ９０９からＲＡＭ９０２ｂ上に展開されたプログラムに従ったＣＰＵ９０１からの命令によって動作することで実現される機能又は手段である。このプログラムは所定のサーバからダウンロードされ、機器２０にインストールされている。

表示処理部２１は、ユーザが操作する画面を操作パネル９４０に表示する。例えば、ワークフローを起動するボタン、原稿種別のリスト、操作を案内するメッセージ、印刷設定、及び、読取設定などを表示する。

操作受付部２２は、機器２０に対する操作を受け付ける。例えば、起動するワークフローの選択、ワークフローに使用する原稿種別などを受け付ける。

出力部２３は、サービス提供システム１０から送信された印刷データを印刷する。印刷することを出力するという場合がある。印刷データはサービス提供システム１０でＰＤＬ（Printer Description Language）に変換されてもよいし、機器２０が変換してもよい。

入力部２４は、用紙などのシート材である原稿を光学的に読み取って画像データを作成する。読み取ることをスキャンともいい、画像データをスキャンデータという場合がある。原稿は２ページ以上でもよい。

通信部２５（第二の通信部の一例）は、機器２０をネットワークに接続して、各種の情報を送受信する。例えば、印刷データをサービス提供システム１０から受信し、原稿を読み取って生成した画像データをサービス提供システム１０に送信する。

認証部２６は、ユーザを認証する。認証とはユーザが正当な権限者か否かを判断することをいう。本実施例の場合は、サービス提供システム１０を使用する権限があるかどうかである。なお、認証が成功するとユーザは機器２０にログインする。ログインとは、コンピュータやインターネット上の様々なサービスを利用する際に、予め登録しておいたアカウント情報を用いてシステムのリソースにアクセスする認証行為をいう。アカウント情報は、ユーザＩＤとパスワード、ＩＣカードの番号、生体認証情報などである。

<<第一の端末装置>>
第一の端末装置５０は第一通信部５１、第一表示制御部５２、及び、第一操作受付部５３を有している。第一の端末装置５０はプログラム（例えばＷｅｂブラウザ）を実行することで、図５に示すような機能ブロックを実現する。

第一通信部５１はサービス提供システム１０と通信して、設定画面などの画面を第一の端末装置５０が表示するための画面情報を受信する。また、管理者が各画面に入力した情報をサービス提供システム１０に送信する。

第一表示制御部５２はサービス提供システム１０から受信した画面の画面情報を解析してディスプレイ５０６に表示する。第一操作受付部５３は第一の端末装置５０に対する管理者の操作（例えば各画面への入力）を受け付ける。

<<第二の端末装置>>
第二の端末装置６０は第二通信部６１、第二表示制御部６２、及び、第二操作受付部６３を有している。第二の端末装置６０はプログラム（例えばＷｅｂブラウザ）を実行することで、図５に示すような機能ブロックを実現する。

第二通信部６１はサービス提供システム１０と通信して、申請書などの画像データを表示するための画面情報を受信する。また、処理担当が各画面に入力した情報をサービス提供システム１０に送信する。

第二表示制御部６２はサービス提供システム１０から受信した画面の画面情報を解析してディスプレイ５０６に表示する。第二操作受付部６３は第二の端末装置６０に対する取引担当の操作（例えば各画面への入力）を受け付ける。

<<サービス提供システム>>
サービス提供システム１０は、印刷ワークフロー処理部１４、読取ワークフロー処理部１５、通信部１６、認証管理部１７、及び、設定部１８を有している。サービス提供システム１０が有する各機能は、図３に示されている各構成要素のいずれかが、ＨＤ５０４からＲＡＭ５０３上に展開されたプログラムに従ったＣＰＵ５０１からの命令によって動作することで実現される機能又は手段である。

印刷ワークフロー処理部１４は、印刷のワークフローの実行を制御する。例えば、原稿の印刷データに画像コードを形成して機器２０に送信する。読取ワークフロー処理部１５は、読取のワークフローの実行を制御する。例えば、機器２０が送信した画像データを解析して画像コードを復号し、読取のワークフローの処理方法を決定する。

なお、印刷ワークフロー処理部１４及び読取ワークフロー処理部１５は企業の基幹システムと連携してワークフローを実行したり、外部（他社など）が提供するシステムと連携してワークフローを実行したりしてもよい。

通信部１６（第一の通信部の一例）は、サービス提供システム１０をネットワークに接続して、各種の情報を送受信する。例えば、ユーザが選択した原稿の印刷データを機器２０に送信し、画像データを機器２０から受信する。また、外部システムに画像データを送信して処理を依頼する。また、第一の端末装置５０からアプリの設定に関する情報を受信し、第二の端末装置６０から申請書の処理に関する情報を送受信する。

認証管理部１７は、認証に関する制御を行う。例えば、企業ごとに、
・登録済みのユーザ、管理者、機器の情報
・契約（利用）しているアプリ
・契約アプリのライセンス情報
等を管理している。これらと機器２０、第一の端末装置５０又は第二の端末装置６０から送信された情報を元に利用権限の有無を認証する。認証管理部１７は各種ワークフローを構成するＷｅｂアプリケーションや次の設定部１８を、各機器や端末装置から利用する際に、認証や利用権限判定、情報管理等のサービスを提供する、認証管理基盤として機能する。

設定部１８は後述する申請書類印刷サービス６０１（印刷のワークフローに相当）、及び、簡単申請サービス６０２（読取のワークフローに相当）に関する設定を第一の端末装置５０から受け付ける。設定部１８は、第一の端末装置５０又は第二の端末装置６０がＷｅｂブラウザでアクセスできるＷｅｂサーバ（設定サイト）である。設定部１８は外部システム３０のアカウント情報の入力と、印刷のワークフロー及び読取のワークフローが実行される際に参照する参照先として処理方法記憶部、印刷データ記憶部、読取データ記憶部を指定する設定と、を受け付ける。設定部１８は各種ワークフローを構成するＷｅｂアプリケーションの一部を形成していてもよい。企業で各種ワークフローのＷｅｂアプリを契約して利用開始すれば、対応する設定部１８（設定サイト）も利用可能となる。

また、サービス提供システム１０は、図３に示されているＨＤ５０４、ＲＡＭ５０３又はＲＯＭ５０２の１つ以上により実現される記憶部１９を有している。記憶部１９には、印刷データ記憶部１１、読取データ記憶部１２、及び、処理方法記憶部１３が構築されている。

記憶部１９にある印刷データ記憶部１１、読取データ記憶部１２、及び、処理方法記憶部１３は、サービス提供システム１０が保持していなくてもよい。例えば、クラウド上にあればよく、図２に示した外部システム３０にあってもよい。民間又は公的なストレージサービス（例えば、Google Drive（登録商標）、One Drive（登録商標）等のクラウドストレージサービス）を利用できる。また、記憶部１９にある印刷データ記憶部１１、読取データ記憶部１２、及び、処理方法記憶部１３は、クラウド上でなくオンプレミスに存在してもよい。また、印刷データ記憶部１１、読取データ記憶部１２、処理方法記憶部１３は全て同じクラウドストレージサービスの、それぞれ別のフォルダにもうけられてもよいし、同じフォルダ内に設けられてもよい。また、異なる複数のクラウドストレージサービス（外部システム３０_１、３０_１・・）に設けられてもよい。

印刷データ記憶部１１には、機器２０が印刷する印刷データが記憶されている。印刷データは、ＰＤＦ（Portable Document Format）や各種のアプリケーションソフトが作成したファイルである。

読取データ記憶部１２は配信先のフォルダに相当し、機器２０で読み取って生成した画像データ（読取データ）が記憶される。

処理方法記憶部１３には、上記のように「ＩＤ：原稿種別：処理方法」が対応付けられている。ＩＤは上記の通り原稿種別又は原稿を識別する識別情報である。なお、処理方法記憶部１３はファイルを記憶するフォルダなどでもよいし、データベースでもよい。処理方法記憶部１３に記憶されている処理方法情報の一例を表１に示す。

表１は処理方法記憶部１３に記憶されている処理方法情報の一例を示す。処理方法情報は、原稿種別ごとの処理方法（送り先フォルダ、通知先等）を指定する。例えば、請求書の場合は、スキャンしたデータの送り先フォルダは「/seikyuuフォルダ以下」であり、同時に「aaa@bb.cc」に電子メールで通知するということを表している。表１に示す以外に処理方法があってもよく、処理方法は１つでもよく、処理方法は２つに限られない。例えば、ＦＡＸ（電話回線タイプでもインターネットファクスでもよい）の送り先などの項目があってもよい。

同じ原稿種別でも用途や使用時期によって、異なる処理方法が対応付けられていてよい。例えば申請月によって保存先フォルダを切り替えることができる。このような処理に対応するためには、処理方法記憶部１３上で同じ原稿種別であっても管理者が異なるＩＤを登録することで、原稿種別が同じでも原稿によって異なるＩＤにそれぞれの処理方法を定義することで実現できる。

原稿種別の項目は印刷のワークフローで使用され、処理方法は読取のワークフローで使用され、ＩＤは両方で使用される。したがって、ＩＤにより印刷のワークフローと読取のワークフローを連携できる。

管理者は印刷データ記憶部１１に新しい処理方法情報を追加したり、古い処理方法情報を削除したり編集したりする。管理者はＩＤ、原稿を識別する情報（例えばファイル名）、そして、処理方法を任意に設定できる。処理方法情報の態様としては、例えば表計算ファイルでもよいし、ＣＳＶ（comma−separated values）、ＸＭＬ、ＪＳＯＮでもよい。単純に、「ＩＤ、 原稿種別、処理方法」が記載されたテキストファイルでもよい。また、管理者がデータベース形式で登録する場合、ＰＣ（Personal Computer）で動作するデータベースクライアントを操作して「ＩＤ、 原稿種別、処理方法」を登録する。

処理方法記憶部１３のＵＲＬは、印刷ワークフロー処理部１４と読取ワークフロー処理部１５にとって既知である。必要なら、管理者が印刷ワークフロー処理部１４と読取ワークフロー処理部１５に該ＵＲＬを設定する。これにより、印刷ワークフロー処理部１４と読取ワークフロー処理部１５は処理方法記憶部１３を参照して、それぞれワークフローを実行できる。

＜ワークフローの一例＞
図６は、ワークフローの一例を説明する図である。図６（ａ）は印刷のワークフローの一例を示し、図６（ｂ）は読取のワークフローの一例を示す。

印刷のワークフローは、「原稿をクラウドＢからダウンロード」「画像コードを付与」「印刷」の一連の処理を順番に実行するものである。読取のワークフローは「画像にＯＣＲをかける」「画像をクラウドＡに送る」「メールを送る」の一連の処理を順番に実行するものである。

ワークフローの設定方法については後述する（実施例７参照）。管理者は事前にワークフローを設定することができる。本実施形態ではプログラムレスかつユーザサイドで構築できる。例えば、図６の各処理をＧＵＩ（Graphical User Interface）で組み合わせる(つなげる)ことでワークフローを設定できる。図６（ｂ）の例では、「画像にＯＣＲをかける機能」「画像をクラウドＡに送る機能」「メールを送る機能」を事前に用意しておいて、図６（ｂ）のようにつなげることで、プログラムレスで１つのワークフローを設定できる。

なお、ワークフローの各処理はサービス提供システム１０内で完結する処理だけでなく、外部システムへ処理を委譲するケースがあってもよい。この場合は、サービス提供システム１０は、外部システムのＷｅｂ ＡＰＩ（Application Programming Interface）を介して処理を委譲する。Ｗｅｂ ＡＰＩには厳格な定義はないが、ＨＴＴＰなどのプロトコルを用いてネットワーク越しに呼び出すアプリケーション間、システム間のインターフェースである。

＜印刷のワークフロー、読取のワークフローの設定＞
図７は、印刷のワークフローの設定画面３００の一例である。管理者は第一の端末装置５０を操作してサービス提供システム１０に接続させ、第一の端末装置５０に図７の画面を表示させる。

印刷のワークフローの設定画面３００は、ストレージアカウント設定欄３０１、印刷データ保管先設定欄３０２、処理方法保管先設定欄３０３、印刷設定欄３０４、及び、画像コード付加方法設定欄３０６、を有している。
・ストレージアカウント設定欄３０１…サービス提供システム１０がストレージ（クラウドストレージサービス）にアクセスするためのユーザのアカウント情報を管理者が選択する欄である。アカウント情報は例えば、ユーザＩＤ(メールアドレス)及びパスワードである。図７ではユーザのリストがプルダウン表示され、管理者がユーザを選択するとアカウント情報も設定される。
・印刷データ保管先設定欄３０２…印刷データの保管先（例えば印刷データ記憶部１１）のフォルダのパス情報を管理者が設定する欄である。例えば、「/storage/print_data/」などが設定される。後述する図１１のステップS14のファイル名一覧の取得、及び、ステップS20の印刷データ取得、の取得先等となる。
・処理方法保管先設定欄３０３…処理方法の保管先（例えば処理方法記憶部１３）のフォルダのパス情報を管理者が設定する欄である。例えば「/storage/process_data/」などが設定される。後述の図１１のステップS21のＩＤ取得、及び、図１６のステップS42のＩＤに対応する処理方法、の取得先等となる。

なお、利用するストレージによってＡＰＩや接続方法が異なるため、Ｗｅｂアプリ（ワークフローアプリ）やパッケージごとに１つが固定で設定されている。ただし、複数のストレージを切り替え可能であってもよい。
・印刷設定欄３０４…全ての印刷データの出力時の、機器２０（例えば画像形成装置）における設定値が入力される。設定値は管理者が固定できる。＋ボタン３０５で設定項目が追加されるため、複数入力可能である。設定項目には以下のようなものがある。

サイズ：A4/A3
カラー：モノクロ/カラー/二色
後処理：パンチ/ステープル 等
処理方法の情報を付加して印刷する（送付先・処理担当・原稿の取り扱い）
・画像コード付加方法設定欄３０６…利用する処理方法（コード化する情報）の選択として、管理者が利用できる。＋ボタン３０７の押下で以下の設定項目からいずれかを選択できる。

原稿の識別情報を画像コードとして付加
ログインしているユーザの識別情報を画像コードとして付加
原稿の識別情報と、ユーザの識別情報の両方を画像コードとして付加
画像コードを付加しない
図８は、読取のワークフローの設定画面３１０の一例である。管理者は第一の端末装置５０を操作してサービス提供システムに接続させ、第一の端末装置５０に図８の画面を表示させる。

読取のワークフローの設定画面３１０は、ストレージアカウント設定欄３１１、処理方法保管先設定欄３１２、読取データ保管先設定欄３１３、読取設定欄３１４、及び、処理方法の選択欄３１６、を有している。
・ストレージアカウント設定欄３１１…図７の印刷のワークフローの設定画面３００のストレージアカウント設定欄３０１と同様である。
・処理方法保管先設定欄３１２…処理方法の保管先（例えば処理方法記憶部１３）のフォルダのパス情報を管理者が設定する欄である。例えば、「/storage/process_data/」が設定される。ここに印刷のワークフロー（申請書類印刷サービス６０１）の設定が入っていればサービス提供システムが参照して設定内容に従う。
・読取データ保管先設定欄３１３…機器２０（例えば画像形成装置）が申請書を読み取って生成した画像データの保管先（例えば読取データ記憶部１２）のフォルダのパス情報を管理者が設定する欄である。例えば「/storage/scan_data/seikyuu」などが設定される。処理方法保管先設定欄３１２が設定されていれば読取データ保管先設定欄３１３は設定されていなくてもよい。

なお、「読取データ保管先設定欄が設定されない場合、処理方法保管先設定欄に設定された保管先又は送付先が参照される」「処理方法に加えて、全ての画像データが１つの保管先にも保管される。」「処理方法は適用せずに、強制的に全ての画像データを１つの保管先にも保管する」、などを管理者が選択できてもよい。
・読取設定欄３１４…申請書の読取り時における機器２０（例えば画像形成装置）の設定値を管理者が設定する欄である。管理者が固定できる。＋ボタン３１５の押下が設定項目を追加できるので、管理者は複数の設定項目を入力できる。

サイズ：A4/A3
カラー：モノクロ/カラー/二色
解像度：200dpi/300dpi/400dpi 等
・処理方法の選択欄３１６…＋ボタン３１７の押下でいずれかを管理者が選択する。
「原稿の識別情報に対応する処理を行う」
「ログインしているユーザの識別情報に対応する処理を行う」
「原稿の識別情報と、ユーザの識別情報の両方に対応する処理をともに行う。」
「印刷時（申請書類印刷サービス）の設定が入っていれば従う。」
「処理（送付）しない」
図９は、印刷のワークフロー、読取のワークフローの設定、読取のワークフローの実行、及び、申請書の確認の処理の流れを説明するシーケンス図の一例である。

S101：管理者が第一の端末装置５０を操作してサービス提供システム１０に接続させる。第一の端末装置５０の第一表示制御部５２がログイン画面を表示するので、管理者が認証情報を入力する。第一の端末装置５０の第一操作受付部５３は入力を受け付ける。

S102：第一の端末装置５０の第一通信部５１は認証情報をサービス提供システムに送信する。サービス提供システムの認証管理部１７は認証情報で管理者を認証する。すなわち、管理者の権限があることを認証する。

S103：サービス提供システムの通信部１６は認証チケットを第一の端末装置５０に送信する。認証チケットはログインしたユーザと対応づけられており、誰がログインしたか、このユーザはどのような処理が可能かを示す。

S104：管理者は印刷のワークフロー又は読取のワークフローに関する設定を行うため、ワークフローを選択する。第一の端末装置５０の第一操作受付部５３は選択を受け付ける。

S105：第一の端末装置５０の第一通信部５１は選択したアプリの設定画面（図７、図８の画面）をサービス提供システムに要求する。

S106：サービス提供システムの通信部１６はアプリの設定画面の要求を受信し、設定部１８が設定画面の画面情報を第一の端末装置５０に送信する。

S107：第一の端末装置５０の第一通信部５１が設定画面の画面情報を受信する。第一表示制御部５２が印刷のワークフローの設定画面３００又は読取のワークフローの設定画面３１０を表示するので、管理者が設定値を入力する。第一の端末装置５０の第一操作受付部５３は入力を受け付ける。

S108：第一の端末装置５０の第一通信部５１は設定値をサービス提供システム１０に送信する。サービス提供システム１０の通信部１６は設定値を受信し、設定部１８が設定値を記憶する。

S109：設定値を保存した旨（ＯＫ）が第一の端末装置５０に送信される。

S110：管理者は処理方法を編集できる。管理者は、例えば、表計算ファイル又は処理方法が記載されているファイルなどを第一の端末装置５０に表示させ、ＩＤごとに処理方法を編集する。第一の端末装置５０の第一操作受付部５３は編集を受け付ける。編集された処理方法は外部システム３０に保存される。

S111：処理方法を保存した旨（ＯＫ）が第一の端末装置５０に送信される。

続いて、ユーザが機器２０に赴いて読取のワークフローを実行する。印刷のワークフローについてはすでに実行されたものとする。

S112：機器２０の通信部２５は起動後、認証要求をサービス提供システム１０に送信する。ユーザ又はデバイス識別情報が送信される。

S113：サービス提供システム１０の認証管理部１７はユーザ又は機器２０を認証し、認証が成功した場合、利用権限ありを示す認証チケットを機器２０に送信する。

S114：機器２０の通信部２５はユーザが選択したワークフローの実行要求をサービス提供システム１０に送信する。例えば、機器２０が申請書を読み取って生成した画像データが送信される。

S115：サービス提供システム１０の通信部１６はワークフローの実行要求を受信し、読取ワークフロー処理部１５が読取のワークフローの設定値を設定部１８から取得する。

S116：読取ワークフロー処理部１５は設定値に基づいて処理方法の保管先（外部システム３０）を特定し、編集後の処理方法情報を外部システム３０から取得する。

S117：読取ワークフロー処理部１５は処理方法情報に基づいて、通知先アドレスに画像データを送信する。例えば、取引担当宛に電子メールを送信する。

S118：また、読取ワークフロー処理部１５は処理方法情報に基づいて、送信先フォルダに画像データを送信する（保存する）。

次に、申請書の処理担当が申請書を確認する。

S119：処理担当が第二の端末装置６０を操作してサービス提供システム１０に接続させる。第二の端末装置６０には電子メール等で保存先（外部システム３０のフォルダ）が通知されているので、処理担当は送信先のフォルダを開く操作を入力する。第二の端末装置６０の第二操作受付部６３は入力を受け付ける。

S120：第二の端末装置６０の第二通信部６１は送り先フォルダに接続する。

S121：これにより、第二の端末装置６０の第二通信部６１は送り先フォルダに保存されている画像データ（申請書等）の一覧を受信し、第二表示制御部６２が表示できる。

S122：処理担当は所望の申請書等を選択すると、第二の端末装置６０の第二通信部６１が申請書の画像データを受信する。第二表示制御部６２が画像データを表示することで処理担当は申請書等を確認できる。

＜動作手順＞
続いて、図１０を用いて情報処理システム１の動作について説明する。まず、図１０は、基本となる印刷と読取の全体の流れを示すシーケンス図である。

S1：ユーザは機器２０に対し印刷指示を入力する。機器２０の操作受付部２２は印刷指示を受け付ける。

S2：機器２０の通信部２５は、サービス提供システム１０から原稿の印刷データを取得する。

S3：機器２０の出力部２３は印刷データを印刷する。

S4：ユーザは印刷された原稿に必要事項を記入する。

S5：ユーザは、機器２０に記入済みの原稿の読取指示を入力する。機器２０の操作受付部２２は読取指示を受け付ける。

S6：機器２０の入力部２４は原稿を光学的に読み取って画像データを生成する。

S7：機器２０の通信部２５は画像データをサービス提供システム１０に送信する。

S8：サービス提供システム１０の読取ワークフロー処理部１５は、送信された画像データを解析して後述する原稿のＩＤを取得する。

S9：サービス提供システム１０の読取ワークフロー処理部１５は、解析したワークフローに基づいて画像データに図６（ｂ）で説明したような一連の処理を施す。

以下では、図１０のうち、印刷のワークフローと読取のワークフローの詳細をそれぞれ説明する。

＜印刷のワークフローの処理＞
図１１は、印刷のワークフローにおいて、情報処理システム１が実行する処理を説明するシーケンス図の一例である。

S11：機器２０は、例えばいくつかのアプリのリストが表示されたホーム画面を表示しており、ユーザは印刷のワークフローに対応したアプリを選択する。ホーム画面の一例を図１２に示す。ユーザが印刷用画面を表示する操作を入力すると（アプリを選択すると）操作受付部２２が受け付けて表示処理部２１に通知する。このアプリが表示する画面を印刷用画面という。

S12：表示処理部２１は、通信部２５に印刷用画面の取得要求を送信する。

S13：通信部２５は、印刷用画面の取得要求をサービス提供システム１０に送信する。サービス提供システム１０の通信部１６は印刷用画面の取得要求を受信する。

S14：印刷ワークフロー処理部１４は印刷用画面の画面情報を生成するため、原稿のファイル名を印刷データ記憶部１１に要求する。ファイル名に限らず、原稿を特定できる情報であればよい。処理方法記憶部１３から原稿を特定できる情報を取得してよい。印刷ワークフロー処理部１４は印刷データ記憶部１１に記憶されている原稿のリストを取得する。

印刷ワークフロー処理部１４は通信部１６を介して、原稿のファイル名を機器２０に送信する。なお、印刷ワークフロー処理部１４は単に原稿のファイル名を機器２０に送信してもよいし、Ｗｅｂサーバとして原稿のファイル名（又は原稿名などのユーザが認知している名称）を表示する画面情報を機器２０に送信してもよい。画面情報とは、ＨＴＭＬ、ＸＭＬ、スクリプト言語、及びＣＳＳ（cascading style sheet）等で記述されており、主にブラウザソフトが解析して表示する情報である。

S15：機器２０の通信部２５は原稿のファイル名又は画面情報を受信し、表示処理部２１に印刷用画面取得結果（原稿のファイル名又は画面情報）を送信する。

S16：表示処理部２１は原稿のファイル名又は画面情報に基づいて、印刷用画面を操作パネル９４０に表示する。印刷用画面の一例を図１３に示す。印刷用画面では、どの原稿を印刷するかをユーザが選択する。その際、図１３（ａ）のように印刷データ記憶部１１の中身を直接表示して選択させる印刷用画面でもよいし、図１３（ｂ）のように原稿を選択式に選択させる印刷用画面でもよい。どちらを画面であっても以後のシーケンスで選択した原稿に応じた原稿種別が指定される。

S17：ユーザは印刷用画面において印刷する原稿を選択する。操作受付部２２は選択に応じて原稿種別を受け付けて表示処理部２１に原稿種別を通知する。原稿種別は印刷データを特定する情報であればよい。例えば、ファイル名、印刷データ記憶部１１内の識別番号などでよい。ファイル名や印刷データ記憶部１１内の識別番号は、ステップS14で取得されている。

なお、ユーザが原稿を選択すると印刷用画面は印刷設定画面に遷移する。ユーザは印刷設定画面で原稿の印刷設定を行うことができる。印刷設定画面の一例を図１４に示す。

S18：表示処理部２１は、原稿種別を指定して通信部２５に印刷データ取得要求を送信する。

S19：機器２０の通信部２５は、原稿種別を指定しサービス提供システム１０に印刷データ取得要求を送信する。

S20：サービス提供システム１０の通信部１６は印刷データ取得要求を受信し、サービス提供システム１０の印刷ワークフロー処理部１４は、原稿種別を指定して原稿の印刷データを印刷データ記憶部１１から取得する。

S21：サービス提供システム１０の印刷ワークフロー処理部１４は、原稿種別を指定してＩＤを処理方法記憶部１３から取得する。表１の例だと、原稿種別が休暇届けの場合は「paper_id_003」というＩＤを取得する。

S22：印刷ワークフロー処理部１４は印刷データを加工する。すなわち、ＩＤを印刷データに付加する。付加の方法としては、直接文字列を付加してもいいし、画像コード（ＱＲコード、二次元コード、バーコード等、特定の情報が埋め込まれた画像情報）を付加してもよいし、電子透かし・地紋などで付加してもよい。本実施形態では画像コードであるとして説明する。

S23：印刷ワークフロー処理部１４は通信部１６を介して、機器２０に印刷データを送信する。

S24：機器２０の通信部２５は印刷データを受信し、表示処理部２１に印刷データを返す。確認のために印刷データの文面を表示してもよい。

S25：表示処理部２１は、印刷データを指定して出力部２３に印刷要求を送信する。

S26：出力部２３は、印刷を実行する。

以上により、印刷のワークフローが実行され、原稿種別のＩＤを含む画像コードが形成された所望の原稿の雛形が印刷される。

＜印刷時の画面例＞
図１２はホーム画面６００の一例を示す。ホーム画面６００は、ユーザ操作の起点となる画面であり、起動後やログイン後に最初に表示される画面である。いくつかのアプリのリストが表示されており、その中の１つに印刷のワークフローに相当するアプリ、及び、読取のワークフローに相当するアプリがある。

例えば、申請書類印刷サービス６０１が印刷のワークフローに相当するアプリ（第一のアプリの一例）であり、簡単申請サービス６０２が読取のワークフローに相当するアプリ（第二のアプリの一例）である。申請書類印刷サービス６０１が選択されると、図１３（ａ）又は図１３（ｂ）に示す印刷用画面６１０が表示される。

これらのワークフローのアプリは、操作パネル９４０にアプリマーケットサイトからユーザが入手できる。追加されたアプリはＷｅｂアプリへのリンクを有しており、ワークフロー作成手段によってクラウド上に作成構築されたＷｅｂアプリに、アクセスする。

図１３は印刷用画面６１０の一例である。図１３（ａ）は印刷データ記憶部１１の中身を直接表示する印刷用画面６１０である。このため原稿のファイル名６１１がリストアップされている。ユーザはこの中から所望の原稿を選択できる。ユーザはファイル名６１１を押下することで原稿を選択できる。

図１３（ｂ）は原稿を選択式に選択させる印刷用画面６１０である。この印刷用画面６１０は、印刷ワークフロー処理部１４又は機器２０の表示処理部２１が印刷データ記憶部１１の情報から作成したものである。印刷用画面６１０は原稿のリスト６１２を表示している。図１３（ｂ）では原稿のリスト６１２がファイル名と同じであるが、ユーザに認知されている原稿の名称を表示できる。印刷データ記憶部１１において、例えば、各原稿に識別番号を付加してファイル名と対応付けておけば、原稿のリスト６１２で表示する原稿の名称は任意でよい。ユーザはラジオボタン６１３を押下することで原稿を選択できる。

図１３（ａ）又は図１３（ｂ）で印刷ボタン６１４が押下されると、表示処理部２１は印刷設定画面を表示する。

図１４は印刷設定画面６２０の一例を示す。印刷設定画面６２０はカラー/モノクロ６２１、倍率６２２、部数６２３、用紙６２４、両面/片面６２５、集約６２６などを設定するための画面である。ユーザがスタートボタン６２７を押下すると、選択した原稿の印刷が開始される（ステップS18以降が処理される）。

＜原稿への記入例＞
図１５は、機器２０が印刷した原稿の一例を示す。図１５の原稿は休暇届を例にしたが原稿はどのようなものでもよい。図１５（ａ）は原稿種別のＩＤを付加する前の休暇届であり、図１５（ｂ）は原稿種別のＩＤを含む画像コード９が形成された休暇届である。図１５（ｂ）では休暇届の右上に画像コード９が形成されている。画像コード９には原稿種別のＩＤ（例えば、paper_id=003）がエンコードされている。なお、画像コード９の形成位置はワークフローの設定の中で管理者が設定できる。ユーザは必要事項を記入して、読取のワークフローを実行する。

＜読取のワークフローの処理＞
図１６は、読取のワークフローにおいて、情報処理システム１が実行する処理を説明するシーケンス図の一例である。

S31：同様に、ユーザはホーム画面６００を表示させており、ユーザは読取のワークフローに対応したアプリ（簡単申請サービス６０２）を選択する。このアプリが表示する画面が読取用画面である。ユーザが読取用画面を表示する操作（簡単申請サービス６０２の押下）を入力すると操作受付部２２が受け付けて表示処理部２１に通知する。

S32：表示処理部２１は、通信部２５に読取用画面の取得要求を送信する。

S33：通信部２５は、読取用画面の取得要求をサービス提供システム１０に送信する。サービス提供システム１０の通信部１６は読取用画面の取得要求を受信する。読取ワークフロー処理部１５は読取用画面の画面情報を機器２０に送信する。読取用画面は所定のメッセージを表示する固定の画面でよい。

S34：機器２０の通信部２５は受信した読取用画面の画面情報を表示処理部２１に送信する。

S35：表示処理部２１は読取用画面の画面情報に基づいて、読取用画面を操作パネル９４０に表示する。読取用画面の一例を図１７に示す。

S36：ユーザは読取用画面を参照して、原稿をＡＤＦ等にセットして、記入した原稿の読取指示を機器２０に入力する。操作受付部２２は読取指示を受け付ける。

なお、ユーザが読取指示を入力すると読取用画面は読取設定・実行画面に遷移する。ユーザは読取設定・実行画面で読取条件を設定することができる。読取設定・実行画面の一例を図１８に示す。

S37：表示処理部２１は、読取条件を指定して入力部２４に読取要求を送信する。

S38：入力部２４は読取条件にしたがって原稿の読み取りを実行する。これにより原稿の画像データを生成する。

S39：入力部２４は画像データの送信要求を通信部２５に送信する。

S40：機器２０の通信部２５は画像データをサービス提供システム１０に送信する。

S41：サービス提供システム１０の通信部１６は画像データを受信し、読取ワークフロー処理部１５が画像コードの検出と、画像コードがあればその解析（デコード）を行う。これにより、原稿種別のＩＤが復元される。

S42：読取ワークフロー処理部１５は原稿種別のＩＤを指定して、処理方法記憶部１３から処理方法情報を取得する。ここでは処理方法を取得すればよい。画像コードから読み取った原稿種別のＩＤが「paper_id 003」の場合、処理方法は、データの保存先が「/kyuukaフォルダ以下」、通知先が「ccc@bb.cc」となる。

S43：読取ワークフロー処理部１５は処理方法記憶部１３に設定されているフォルダに画像データを保存する。図１６ではフォルダが読取データ記憶部１２にあるものとする。

S44：同様に、読取ワークフロー処理部１５は処理方法記憶部１３に設定されている外部システムに画像データを送信し、外部システムに応じた処理を要求する。表１の処理方法記憶部１３の場合、「ccc@bb.cc」にメール通知をする処理である。この他、他の外部システムへ連携処理を要求してもよい。

S45：読取ワークフロー処理部１５は処理結果を機器２０に送信する。

S46：機器２０の通信部２５は処理結果を受信し、入力部２４に処理結果を送信する。

S47：入力部２４は処理結果を表示処理部２１に送信する。

S48：表示処理部２１は処理結果を含む読取・処理結果画面を操作パネル９４０に表示する。読取・処理結果画面の一例を図１９に示す。

以上により、読取のワークフローが実行され、原稿が原稿種別に応じて決まったフォルダに送信されたり、外部システムで処理されたりする。

＜読取時の画面例＞
図１７は読取用画面６３０の一例である。図１７の読取用画面６３０へは、図１２のホーム画面で簡単申請サービス６０２が選択されると遷移する。読取用画面６３０は「ＡＤＦに読取原稿をセットして読取ボタンを押下してください」というメッセージ６３１、及び、読取ボタン６３２を有している。読取ボタン６３２の押下により、読取用画面６３０は読取設定・実行画面６４０に遷移する。

図１８は読取設定・実行画面６４０の一例である。読取設定・実行画面６４０では、白黒６４１、ファイル形式６４２、解像度６４３、原稿面６４４、読取サイズ６４５、ファイル名６４６、濃度６４７、原稿セット方向６４８、及び、送信者６４９を設定できる。スタートボタン６４０ａが押下されると読取が開始される（ステップS37以降が処理される）。読取が完了すると読取・処理結果画面６５０に遷移する。

図１９は読取・処理結果画面６５０の一例である。読取・処理結果画面６５０は「読み取ったデータの処理が完了しました」というメッセージ６５１と、原稿種別のＩＤと処理方法情報に基づいて画像データを処理した処理方法６５２が表示されている。処理方法６５２は例えば「001 請求書を読取ったため、経理課（/seikyuuフォルダ 及びaaa@bb.cc）に送信しました」である。「001」が原稿種別のＩＤである。また、「経理課」のような情報は処理方法記憶部１３に予め設定してあるものとする。

＜ＦＡＸ送信が含まれる読取のワークフロー＞
読取のワークフローにおいてＦＡＸ送信する処理が含まれている場合を補足する。なお、印刷のワークフローについては変更がない。

図２０は、ＦＡＸ送信を含む読取のワークフローの一例である。読取のワークフローは「画像にＯＣＲをかける」「画像をクラウドＡに送る」「メールを送る」「ＦＡＸ送信」の一連の処理を順番に実行するものである。このようなワークフローも事前にプログラムレスに構築されている。

図２１は、ＦＡＸ送信を含むワークフローに対応した処理方法情報の一例である。ＩＤに対応付けてＦＡＸ送信先が設定されている。ＦＡＸ送信先は「なし」でもよい。

図２２は、読取のワークフローにおいて、情報処理システム１が実行する処理を説明するシーケンス図の一例である。なお、図２２の説明では主に図１６との相違を説明する。図２２のシーケンス図のステップS31〜S44は図１６と同様でよい。

S44−2：読取ワークフロー処理部１５はワークフローに基づいて、ＦＡＸ送信を機器２０に要求する。この場合、ステップS42で処理方法記憶部１３から取得したＦＡＸ番号と画像データを機器２０に送信する。

S44−3：機器２０は電話回線に接続しＦＡＸ番号を指定して、画像データをＦＡＸで送信する。なお、シーケンス図は簡略化して示した。以降の処理は図１６と同様でよい。したがって、ＦＡＸ送信においては原稿種別に応じてＦＡＸの送信先を変更できる。なお、インターネットＦＡＸの場合、ＦＡＸ番号でなくメールアドレスで宛先が指定され、電子メールと同様に外部システムが送信する。

＜まとめ＞
以上説明したように、印刷時と読取時に共通の処理方法記憶部１３を参照して、印刷のワークフローと読取のワークフローを連携させるので、ワークフローを拡張したい場合も処理方法を修正するだけで対応できる。管理者が処理方法を設定することで、ワークフローを変更できる。処理方法記憶部１３には「ＩＤ：原稿種別：処理方法」を設定すればよいので、ワークフローを容易に拡張できる。

ユーザが原稿を選択すれば、原稿種別に応じた処理方法で画像データを処理できる。印刷のワークフロー及び読取のワークフローそのものを変更しなくても、ユーザが選んだ原稿に応じてワークフローを拡張できる。

なお、本実施例では、機器２０がいったん原稿を出力したが、原稿を出力しなくてもよい。例えば、機器２０が操作パネル９４０に表示した印刷データにユーザがハードキー９４０ｂで入力し、出力せずにサービス提供システム１０に送信することができる。同じ操作は機器２０がＰＣなどの情報処理装置であっても可能である。また、機器２０（又はタブレットなど）に手書き入力が可能であれば、ユーザは原稿に手書きして出力せずにサービス提供システム１０に送信することができる。

また、本実施例では、サービス提供システム１０が記憶している原稿の印刷データを機器２０が印刷したが、機器２０が受信したＦＡＸを印刷してもよい。ＦＡＸには原稿種別のＩＤが付加されており、ＦＡＸが読み取られると、ＩＤに応じた処理方法でサービス提供システム１０が処理できる。

本実施例では、印刷時にログインしたユーザに応じたワークフローを実行できる情報処理システム１について説明する。ログインしたユーザ別にワークフローを拡張できる。

本実施例においては、上記の実施例１にて説明した図３、図４のハードウェア構成図、及び、図５に示した機能ブロック図を援用できるものとし、主に相違点についてのみ説明する場合がある。

本実施例では処理方法記憶部１３にユーザごとの処理方法情報が記憶されている。表２にユーザごとの処理方法情報を示す。

表２はユーザに関する処理方法情報の一例である。ユーザに関する処理方法情報には、印刷時にログインしたユーザに応じたワークフローの処理方法が設定されている。例えば、ユーザＩＤ「User_001」はＡさんで、Ａさんは上司「Dさん(ddd@bb.cc)」と庶務「Gさん(ggg@bb.cc)」に画像データを送信する。このような処理方法情報は管理者が個別に作成してもよいし、すでに存在している人事データベースなどを使用してもよい。

＜印刷のワークフローの処理＞
図２３は、印刷のワークフローにおいて、情報処理システム１が実行する処理を説明するシーケンス図の一例である。なお、図２３の説明では主に図１１との相違を説明する。

S10：まず、本実施例ではユーザＩＤを特定するため、ユーザが機器２０にログインする。認証画面の一例を図２４に示す。ユーザはアカウント情報を機器２０に入力し、操作受付部２２が受け付けたアカウント情報に基づいて認証部２６がユーザを認証する。認証部２６は認証成功又は失敗を表示処理部２１に通知する。ここでは認証が成功したものとし、ユーザ名が特定されたものとする。ユーザ名に限らずユーザを特定又は識別する情報であって処理方法記憶部１３に登録されている情報が特定されればよい。以降のステップS11〜S17の処理は図１１と同様でよい。

S18：表示処理部２１は原稿種別とログインしたユーザのユーザ名を指定して、通信部２５に印刷データ取得要求を送信する。

S19：通信部２５は、原稿種別とユーザ名を指定しサービス提供システム１０に印刷データ取得要求を送信する。

S20：サービス提供システム１０の通信部１６は原稿種別とユーザ名を受信し、サービス提供システム１０の印刷ワークフロー処理部１４は、原稿種別を指定して印刷データを印刷データ記憶部１１から取得する。

S21：サービス提供システム１０の印刷ワークフロー処理部１４は、原稿種別を指定してＩＤを処理方法記憶部１３から取得する。表１の例だと、原稿種別が休暇届けの場合は「paper_id 003」というＩＤを取得する。

S21−2：サービス提供システム１０の印刷ワークフロー処理部１４は、ユーザ名を指定してユーザＩＤを処理方法記憶部１３から取得する。表２の例だと、ユーザ名が「Ａさん」の場合は「User_001」というユーザＩＤを取得する。

S22：印刷ワークフロー処理部１４は印刷データを加工する。すなわち、ＩＤとユーザＩＤを印刷データに付加する。付加の方法は、図１１と同様でよい。以降の処理は図１１と同様になる。

以上により、印刷のワークフローが実行され、原稿種別のＩＤとユーザＩＤを含む画像コード９が形成された所望の原稿の雛形が印刷される。

＜認証画面の一例＞
図２４は、認証画面６６０の一例を示す。図２４（ａ）に示すように、認証画面６６０は、メールアドレス欄６６１、パスワード欄６６２、及び、ログインボタン６６３を有する。ホーム画面６００で、申請書類印刷サービス６０１、又は、簡単申請サービス６０２が押下されると認証画面６６０に遷移する。

ユーザはメールアドレス欄６６１にメールアドレスを、パスワード欄６６２にパスワードを入力し、ログインボタン６６３を押下する。メールアドレスはユーザの識別情報の１つである。これにより、認証部２６がアカウント情報（メールアドレスとパスワード）に基づいて認証成功又は失敗を判断する。認証が成功した場合、印刷用画面６１０又は読取用画面６３０が表示される。認証が失敗した場合、図２４（ｂ）に示すエラーメッセージ６６４が表示される。この場合、ユーザは再度、メールアドレスとパスワードを入力する。

＜読取のワークフローの処理＞
図２５は、読取のワークフローにおいて、情報処理システム１が実行する処理を説明するシーケンス図の一例である。なお、図２５の説明では主に図１６との相違を説明する。まず、ステップS31〜S40の処理は図１６と同様でよい。

S41：サービス提供システム１０の通信部１６は画像データを受信し、読取ワークフロー処理部１５が画像コードの検出と、画像コードがあればその解析（デコード）を行う。これにより、原稿種別のＩＤとユーザＩＤが復元される。

S42：読取ワークフロー処理部１５は原稿種別のＩＤとユーザＩＤを指定して、処理方法記憶部１３から処理方法情報を取得する。ここでは処理方法を取得すればよい。画像コードから読み取った原稿種別のＩＤが「paper_id 003」の場合、処理方法は、データの保存先が「/kyuukaフォルダ以下」、通知先が「ccc@bb.cc」となる。ユーザＩＤが「User_001」の場合、処理方法は、通知先が「ddd@bb.cc」と「ggg@bb.cc」となる。

S43：読取ワークフロー処理部１５は処理方法記憶部１３に設定されているフォルダに画像データを保存する。図２５ではフォルダが読取データ記憶部１２にあるものとする。

S44：同様に、読取ワークフロー処理部１５は処理方法記憶部１３に設定されている外部システムに画像データを送信し、外部システムに応じた処理を要求する。表１の処理方法情報の場合、「ccc@bb.cc」「ddd@bb.cc」と「ggg@bb.cc」にメール通知をする処理である。この他、他の外部サービスへ連携処理を要求してもよい。以降の処理は図１６と同様でよい。

以上により、読取のワークフローが実行され、原稿が原稿種別に応じて決まったフォルダに送信されたり、外部システムで処理されたりする。

＜まとめ＞
本実施例によれば、ログインしたユーザ別にワークフローを拡張できる。例えばユーザ別、ユーザに対応する上司別あるいは所属部署別に提出先を変えることができる。更に、実施例１の原稿種別のＩＤ毎の処理方法に加えてユーザ毎に上司や部署毎の処理方法を追加で実行することができ、例えば、書類の提出先を本社の管理部門（例：表１の送り先・通知先）に加えて、支社や事業所毎の提出先（例：表２の上司・庶務情報）を、提出先として追加することもできる。また、原稿種別のＩＤ毎の処理方法か、ユーザ毎やユーザ上司・所属部門毎の処理方法かの何れかをユーザや管理者に選択させて、処理を行ってもよい。

本実施例では、読取時にログインしたユーザに応じたワークフローを実行できる情報処理システム１について説明する。実施例２と同様に、ログインしたユーザ別にワークフローを拡張できるが、実施例２とログインするタイミングが異なっている。本実施例では読取時にユーザがログインをして、その時のユーザ情報を使って読取ワークフロー処理部１５がワークフローを実行する。別の人が印刷しておいた原稿を任意のユーザが使用して、ユーザ別にワークフローを拡張できる。

本実施例においては、上記の実施例１にて説明した図３、図４のハードウェア構成図、及び、図５に示した機能ブロック図を援用できるものとし、主に相違点についてのみ説明する場合がある。本実施例の印刷のワークフローのシーケンス図は実施例１の図１１と同様でよいため必要に応じて図１１を参照する。また、ユーザごとの処理方法情報は表２と同じものとする。

＜読取のワークフローの処理＞
図２６は、読取のワークフローにおいて、情報処理システム１が実行する処理を説明するシーケンス図の一例である。なお、図２６の説明では主に図１６との相違を説明する。

S30：読取時にユーザが機器２０にログインする。ログインによりユーザ名が特定された。ユーザＩＤが特定されてもよい。ステップS31〜S36の処理は図１６と同様でよい。

S37：表示処理部２１は、読取条件とユーザ名を指定して入力部２４に読取要求を送信する。

S38：入力部２４は読取条件にしたがって原稿の読み取りを実行する。これにより原稿の画像データを生成する。

S39：入力部２４は画像データとユーザ名の送信要求を通信部２５に送信する。

S40：機器２０の通信部２５は画像データとユーザ名をサービス提供システム１０に送信する。

S41：サービス提供システム１０の通信部１６は画像データを受信し、読取ワークフロー処理部１５が画像コードの検出と、画像コードがあればその解析（デコード）を行う。これにより、原稿種別のＩＤが復元される。

S42：読取ワークフロー処理部１５は原稿種別のＩＤとユーザ名を指定して、処理方法記憶部１３から処理方法情報を取得する。ここでは処理方法を取得すればよい。画像コードから読み取った原稿種別のＩＤが「paper_id 003」の場合、処理方法は、データの保存先が「/kyuukaフォルダ以下」、通知先が「ccc@bb.cc」となる。ユーザ名が「Ａさん」の場合、処理方法は、通知先が「ddd@bb.cc」と「ggg@bb.cc」となる。

S43：読取ワークフロー処理部１５は処理方法記憶部１３に設定されているフォルダに画像データを保存する。図２６ではフォルダが読取データ記憶部１２にあるものとする。

S44：同様に、読取ワークフロー処理部１５は処理方法記憶部１３に設定されている外部システムに画像データを送信し、外部システムに応じた処理を要求する。表１の処理方法記憶部１３の場合、「ccc@bb.cc」「ddd@bb.cc」と「ggg@bb.cc」にメール通知をする処理である。この他、他の外部サービスへ連携処理を要求してもよい。以降の処理は図１６と同様でよい。

以上により、読取のワークフローが実行され、原稿が原稿種別に応じて決まったフォルダに送信されたり、外部システムで処理されたりする。

＜まとめ＞
本実施例によれば、実施例１の効果に加えて、ログインしたユーザ別にワークフローを拡張できる。別の人が印刷しておいた原稿を任意のユーザが使用して、ユーザ別にワークフローを拡張できる。

＜原稿にユーザＩＤが含まれ、更に読取時にユーザがログインする場合＞
実施例２では印刷時に、実施例３では読取時にそれぞれログインしたが、印刷時と読取時の両方でユーザがログインしてもよい。この場合、読取時には、印刷時に原稿に形成されたユーザＩＤと読取時にログインで特定されたユーザ名により、それぞれワークフローの処理方法を特定できる。したがって、それぞれで異なるフォルダ名や通知先が得られ、サービス提供システム１０はそれぞれに送信できる。

印刷時に原稿に形成されたユーザＩＤと読取時にログインで特定されたユーザ名のどちらか一方に対応付けられた処理方法をユーザが採用したい場合には、読取用画面６３０でユーザが設定するとよい。この場合、読取ワークフロー処理部１５は、読取用画面６３０に印刷時のユーザとログインユーザのどちらを優先するかの選択を受け付けるラジオボタン等を表示する。

図２７は、読取用画面６３０の一例である。図２７の読取用画面６３０は、図１２のホーム画面６００で簡単申請サービスが選択されると遷移する。図２７の読取用画面６３０には、図１７のメッセージ６３１に加えて、「どちらかのユーザに対応付けられている処理方法を選択してください」というメッセージ６３３と共に、「原稿に埋め込まれたユーザ」６３４、「現在のユーザ」６３５、「両方」６３６が選択可能に表示されている。

したがって、ログインしたユーザは処理方法記憶部１３においてどのユーザに対応付けられている処理方法を採用するかを読取時に選択できる。選択結果はサービス提供システム１０に送信され、サービス提供システム１０は選択結果に応じて処理方法を採用する。

本実施例では、読取時にワークフローの処理方法をユーザが選択できる情報処理システム１に付いて説明する。

本実施例においては、上記の実施例１にて説明した図３、図４のハードウェア構成図、及び、図５に示した機能ブロック図を援用できるものとし、主に相違点についてのみ説明する場合がある。本実施例の印刷のワークフローのシーケンス図は実施例１の図１１と同様でよいため必要に応じて図１１を参照する。

＜ユーザごとの処理方法＞
本実施例ではログインしたユーザごとに処理方法が登録されている。表３は本実施例の処理方法情報の一例である。

表３の処理方法情報には、ユーザＩＤとユーザ名に対応付けて送り先候補が登録されている。ログインしたユーザは送り先候補の中から送り先を選択できる。なお、送り先候補には画像データの配信先フォルダが設定されていてもよい。

＜読取のワークフロー＞
図２８は、読取のワークフローにおいて、情報処理システム１が実行する処理を説明するシーケンス図の一例である。なお、図２８の説明では主に図１６との相違を説明する。

S30：読取時にユーザが機器２０にログインする。ログインによりユーザ名が特定された。ユーザＩＤが特定されてもよい。

S31：ホーム画面６００が表示されるので、ユーザは読取のワークフローに対応したアプリ（簡単申請サービス６０２）を選択する。

S32：表示処理部２１は、ユーザ名と共に通信部２５に読取用画面の取得要求を送信する。

S33：通信部２５は、読取用画面６３０の取得要求をユーザ名と共にサービス提供システム１０に送信する。サービス提供システム１０の通信部１６は読取用画面６３０の取得要求を受信する。

S33−2：読取ワークフロー処理部１５はユーザ名に対応付けられた送り先候補を処理方法記憶部１３から取得する。読取ワークフロー処理部１５は通信部１６を介して、読取用画面６３０の画面情報を機器２０に送信する。本実施例では読取用画面６３０に送り先候補が表示されるため、読取ワークフロー処理部１５は画面情報を作成する。

S34：機器２０の通信部２５は受信した読取用画面６３０の画面情報を表示処理部２１に送信する。

S35：表示処理部２１は読取用画面６３０の画面情報に基づいて、読取用画面６３０を操作パネル９４０に表示する。読取用画面６３０の一例を図２９に示す。

S36：ユーザは読取用画面６３０を参照して、原稿をＡＤＦ等にセットする。また、送り先候補から画像データを送信する宛先となる送り先を選択する。そして、記入した原稿の読取指示を機器２０に入力する。操作受付部２２は読取指示を受け付ける。この後、ユーザは図１８に示した読取設定・実行画面で読取条件を設定する。

S37：表示処理部２１は、読取条件と送り先選択結果を指定して入力部２４に読取要求を送信する。

S38：入力部２４は読取条件にしたがって原稿の読み取りを実行する。これにより原稿の画像データを生成する。

S39：入力部２４は送り先選択結果と画像データの送信要求を通信部２５に送信する。

S40：通信部２５は送り先選択結果と画像データをサービス提供システム１０に送信する。

S41：サービス提供システム１０の通信部１６は送り先選択結果と画像データを受信し、読取ワークフロー処理部１５が画像コードの検出と、画像コードがあればその解析（デコード）を行う。これにより、原稿種別のＩＤが復元される。

S42：読取ワークフロー処理部１５は原稿種別のＩＤを指定して、処理方法記憶部１３から処理方法情報を取得する。ここでは処理方法を取得すればよい。画像コードから読み取った原稿種別のＩＤが「paper_id 003」の場合は、データの保存先が「/kyuukaフォルダ以下」、通知先が「ccc@bb.cc」となる。また、送り先選択結果が「Ａさん」であれば、通知先は「aaa@b.cc」が取得される。

S43：読取ワークフロー処理部１５は処理方法記憶部１３に設定されているフォルダに画像データを保存する。図２８ではフォルダが読取データ記憶部１２にあるものとする。

S44：同様に、読取ワークフロー処理部１５は、処理方法記憶部１３に設定されている外部システムに画像データを送信し、外部システムに応じた処理を要求する。表１の処理方法記憶部１３の場合、「ccc@bb.cc」にメール通知をする処理である。また、送り先選択結果に応じて「aaa@b.cc」にメールを通知する処理である。以降の処理は図１６と同様でよい。

＜読取用画面の一例＞
図２９は読取用画面６３０の一例である。図２９の読取用画面６３０は、図１７の読取用画面６３０のメッセージ６３１に加え、「メールを送るユーザを選択してください」というメッセージ６３７、及び、送り先候補６３８が表示されている。送り先候補６３８はログインしたユーザに応じて処理方法記憶部１３から取得されたものである。したがって、ユーザは読取時に画像データの送り先を選択できる。

＜まとめ＞
本実施例によれば、実施例１の効果に加えて、読取時にログインしたユーザが読取時に画像データの送り先を選択できるので、読取時にワークフローを拡張できる。

本実施例ではワークフローの終了時に原稿種別に応じたメッセージを表示できる情報処理システム１について説明する。原稿によっては保管方法が決まっているものがあり、ユーザが読み取った原稿をどのように保管すべきかわかるようになる。

本実施例においては、上記の実施例１にて説明した図３、図４のハードウェア構成図、及び、図５に示した機能ブロック図を援用できるものとし、主に相違点についてのみ説明する場合がある。本実施例の印刷のワークフローのシーケンス図は実施例１の図１１と同様でよいため必要に応じて図１１を参照する。

＜メッセージを保持する処理方法＞
本実施例では原稿種別ごとにメッセージが登録されている。表４は本実施例の処理方法情報の一例である。

表４の処理方法情報には、表１の処理方法に加えて、後処理メッセージが設定されている。後処理メッセージは読取・処理結果画面６５０に表示されるメッセージであり、原稿種別によって種々のメッセージを表示することができる。例えば、請求書の場合は６か月保管する、交通費申請書の場合は本部に郵送する、休暇届けの場合は即時削除する、というメッセージを機器２０が表示できる。

＜読取のワークフロー＞
図３０は、読取のワークフローにおいて、情報処理システム１が実行する処理を説明するシーケンス図の一例である。なお、図３０の説明では主に図１６との相違を説明する。まず、ステップS31〜S41の処理は図１６と同様でよい。

S42：読取ワークフロー処理部１５は原稿種別のＩＤを指定して、処理方法記憶部１３から処理方法情報を取得する。ここでは処理方法の中に後処理メッセージが含まれる。画像コード９から読み取った原稿種別のＩＤが「paper_id 003」の場合は、「即時削除してください。」という後処理メッセージが取得される。

S43：読取ワークフロー処理部１５は処理方法記憶部１３に設定されているフォルダに画像データを保存する。図３０ではフォルダが読取データ記憶部１２にあるものとする。

S44：同様に、読取ワークフロー処理部１５は処理方法記憶部１３に設定されている外部システムに画像データを送信し、外部システムに応じた処理を要求する。表４の処理方法情報の場合、「ccc@bb.cc」にメール通知をする処理である。この他、他の外部サービスへ連携処理を要求してもよい。

S45：読取ワークフロー処理部１５は通信部１６を介して、処理結果に後処理メッセージを加えて機器２０に送信する。

S46：機器２０の通信部２５は処理結果と後処理メッセージを受信し、入力部２４に処理結果と後処理メッセージを送信する。

S47：入力部２４は処理結果と後処理メッセージを表示処理部２１に送信する。

S48：表示処理部２１は処理結果と後処理メッセージを含む読取・処理結果画面６５０を操作パネル９４０に表示する。読取・処理結果画面６５０の一例を図３１に示す。

以上により、読取のワークフローが実行され、原稿が原稿種別に応じて決まったフォルダに送信されたり、外部システムで処理されたりする。

＜読取・処理結果画面＞
図３１は読取・処理結果画面６５０の一例である。図３１の読取・処理結果画面６５０は、図１９の読取・処理結果画面６５０のメッセージ６５１に加え、後処理メッセージを表示している。図３１（ａ）は原稿種別が請求書の場合の後処理メッセージ６５３を示し、図３１（ｂ）は原稿種別が交通費申請書の場合の後処理メッセージ６５４を示し、図３１（ｃ）は原稿種別が休暇届の場合の後処理メッセージ６５５を示す。このように原稿種別ごとにメッセージを表示できる。

＜まとめ＞
本実施例によれば、実施例１の効果に加えて、ワークフローの完了時に原稿をどのように保管すべきかに関して原稿種別ごとにメッセージを表示できる。なお、本実施例では原稿の保管方法をメッセージで表示したが、メッセージの内容はどのようなものでもよい。例えば、記入内容の注意事項、付帯して提出すべき原稿（身分証など）を読み取らせるべき旨などを表示できる。

図３２は、情報処理システム１の別の構成図の一例である。

＜事前準備＞
１．申請下書きドキュメント（PDF)の登録
２．人事情報との連携
３．文書マスタの登録
−提出先情報
−保存先情報など
＜処理の流れ＞
１．出力
−認証等を実施
−文書の選択をして出力指示
−内部にて申請書に画像コードを付加
−社員番号
−提出先情報
−文書情報
−印刷実施
２．処理（記載、印鑑）
３．スキャン
−認証等を実施
−ワンタッチスキャン
−画像コードに応じて処理
−社員番号から付帯情報の取得
−文書情報から付帯情報の取得
−文書のタグ付け
−配信（メール、クラウドストレージ）
＜処理フローと使用されるデータ＞
図３３は、情報処理システム１の全体的な処理の流れを示すフローチャート図の一例である。まず、文書マスタ７０１は実施例１〜５の処理方法情報に相当する。図示するように、文書マスタ７０１には文書名、文書ＩＤ、 処理区分、宛先が登録されており、文書ＩＤが原稿種別のＩＤ、処理区分と宛先が処理方法に相当する。人事マスタ７０２はユーザ情報であり、主に認証に使用される。テンプレート文書７０３は実施例１〜５の印刷データに相当する。

Ｓ１００１：機器２０がユーザ認証する。

Ｓ１００２：機器２０がテンプレート（原稿）の選択を受け付ける。

Ｓ１００３：機器２０が印刷設定を受け付ける。

Ｓ１００４：情報処理システム１が文書ＩＤの画像コードを生成する。

Ｓ１００５：機器２０がＰＤＬデータを生成する。

Ｓ１００６：機器２０が印刷する。

本実施例では各ワークフローの作成方法について説明する。

＜システム構成＞
図３４は、実施例７に係る情報処理システム１の一例の構成図である。なお、図３４の説明において、図２において同一の符号を付した構成要素は同様の機能を果たすので、主に本実施例の主要な構成要素についてのみ説明する場合がある。図３４に示される情報処理システム１のサービス提供環境Ｅ１は、外部コンポーネント管理装置４０を含む。

外部コンポーネント管理装置４０は、一台以上の情報処理装置で実現され、外部コンポーネントを管理する。このように、本実施形態に係る情報処理システム１では、サービス提供システム１０とは異なる装置である外部コンポーネント管理装置４０において外部コンポーネントを管理する。このため、例えば、外部コンポーネントが重大なバグを有していた場合等における影響を外部コンポーネント管理装置４０に局所化させることができる。

なお、図３４では、サービス提供環境Ｅ１に一の外部コンポーネント管理装置４０が含まれる例を示したが、これに限られない。サービス提供環境Ｅ１には、複数の外部コンポーネント管理装置４０が含まれていてもよい。例えば、サービス提供環境Ｅ１には、Ａ社が開発した外部コンポーネントを管理する外部コンポーネント管理装置４０、Ｂ社が開発した外部コンポーネントを管理する外部コンポーネント管理装置４０等が含まれていてもよい。

＜ソフトウェア構成＞
第１の実施形態に係る情報処理システム１は、例えば図３５に示されるような処理ブロックにより実現することができる。図３５は、実施例７に係る情報処理システム１の一例の処理ブロック図である。

機器２０は、例えばＣＰＵ２１１等により実現されるブラウザ２１０を有する。機器２０のユーザは、ブラウザ２１０を介して、サービス提供システム１０により提供されるサービスを利用することができる。このように、本実施形態に係る機器２０では、ブラウザ２１０が搭載されていればよく、サービスを利用するための専用のアプリケーションを開発等する必要がない。

サービス提供システム１０は、サービス処理部１１０と、ドキュメントサービス部１５０と、ストレージサービス連携部１６０とを有する。これら各部は、例えばＣＰＵ５０１等により実現される。

また、サービス提供システム１０は、アプリ情報記憶部１９０を有する。このアプリ情報記憶部１９０は、ＨＤ５０４等により実現される。なお、アプリ情報記憶部１９０は、サービス提供システム１０とネットワークを介して接続される記憶装置等により実現されてもよい。

サービス処理部１１０は、アプリ管理部１２０と、ロジック処理部１３０と、データＩ／Ｆ部１４０と、処理内容作成部１２２とを有する。

アプリ管理部１２０は、アプリ情報記憶部１９０に記憶されているアプリ情報１０００を管理する。アプリ管理部１２０は、ブラウザ２１０からの要求に応じて、アプリ情報１０００に含まれる画面定義に基づくアプリ画面を返信する。これにより、機器２０のブラウザ２１０には、サービス提供システム１０により提供されるサービスを利用するためのアプリ画面が表示される。ここで、アプリ情報１０００は、詳細は後述するが、上記したアプリ画面を機器２０に表示させるための画面定義と、当該アプリ情報１０００により実現されるサービスの処理内容とが記述された情報である。

また、アプリ管理部１２０は、ロジック処理部１３０からの要求に応じて、アプリ情報１０００に含まれる処理内容を返信する。処理内容は、詳細は後述するが、スキャン配信サービスやクラウドプリントサービス等を実現するための一連の処理が記述されている。なお、一連の処理は、「処理フロー」又は「フロー」とも称される。また、実施例１から実施例６に記載した印刷のワークフロー（印刷ワークフロー処理部１４）と読取のワークフロー（読取ワークフロー処理部１５）も、アプリ情報１０００の一例である。

ロジック処理部１３０は、ブラウザ２１０からの要求に応じて、アプリ管理部１２０から処理内容を取得する。そして、ロジック処理部１３０は、取得した処理内容にしたがってドキュメントサービス部１５０又は／及びストレージサービス連携部１６０のファイル処理部１７０に対して、処理の実行を要求する。これにより、サービス提供システム１０による各種サービスが、機器２０に提供される。なお、ロジック処理部１３０の詳細な処理ブロックについては、後述の＜処理の詳細＞の中で説明する。

データＩ／Ｆ部１４０は、ブラウザ２１０からの要求に応じて、ストレージサービス連携部１６０のデータ処理部１８０に対して、例えばフォルダ一覧の取得等を要求する。

処理内容作成部１２２は、ブラウザ２１０からの要求に応じて、処理内容を作成するための画面（処理内容の作成画面）を作成する。

アプリ管理部１２０は、処理内容作成部１２２からの要求に応じて、処理内容の作成画面において作成された処理内容をアプリ情報記憶部１９０に記憶させる。これにより、ユーザが作成した処理内容により示される一連の処理で実現されるサービスが追加される。

ロジック処理部１３０は、アプリ管理部１２０から取得した処理内容により示される一連の処理において、外部コンポーネントにより実行される処理がある場合、当該処理の実行を外部コンポーネント処理部４１０に要求する。なお、ロジック処理部１３０の詳細な処理ブロックについては後述する。

ドキュメントサービス部１５０は、サービス提供システム１０により提供されるサービスを実現するためのプログラム（モジュール）群である。ドキュメントサービス部１５０には、例えば、電子ファイルに対してＯＣＲ処理を実行するＯＣＲ処理１５１や電子ファイルを機器２０が印刷可能なデータ形式（印刷データ）に変換する印刷変換処理１５２等が含まれる。ドキュメントサービス部１５０には、これら以外にも、例えば、電子ファイルの圧縮又は解凍するためのプログラム、電子ファイルのデータ形式を変換（例えばＰＤＦ形式に変換）するためのプログラム等、各種の処理を実行するプログラムが含まれていてもよい。

ストレージサービス連携部１６０は、ロジック処理部１３０及びデータＩ／Ｆ部１４０からの要求に応じて、外部システム３０に対して、各種処理の実行を要求する。ここで、サービス提供システム１０は、外部システム３０毎に、ストレージサービス連携部１６０をそれぞれ有する。すなわち、サービス提供システム１０は、外部システム３０_１に対して処理を要求するためのストレージサービスＡ連携部１６０_１、外部システム３０_２に対して処理を要求するためのストレージサービスＢ連携部１６０_２等を有する。このように、サービス提供システム１０は、連携して処理を行う外部システム３０毎に、それぞれ対応するストレージサービス連携部１６０を有する。なお、以降では、複数のストレージサービス連携部１６０について、各々を区別するときは、上記のように「ストレージサービスＡ連携部１６０_１」、「ストレージサービスＢ連携部１６０_２」等と添え字を用いて記載する。

ストレージサービス連携部１６０は、上記したように、ロジック処理部１３０からの要求を受け付けるファイル処理部１７０と、データＩ／Ｆ部１４０からの要求を受け付けるデータ処理部１８０とを有する。

ファイル処理部１７０は、外部システム３０に保存されている電子ファイルに対する操作（例えば、取得、保存、編集等）を行うためのＡＰＩ（Application Programming Interface）が定義された共通Ｉ／Ｆ１７１及び固有Ｉ／Ｆ１７２を有する。共通Ｉ／Ｆ１７１は、複数の外部システム３０間で共通に利用できるＡＰＩであり、例えば図３６（ａ）に示すようなＡＰＩが挙げられる。換言すれば、ファイル処理部１７０の共通Ｉ／Ｆ１７１は、すべての外部システム３０が利用できるファイル操作に関する機能（例えば、ファイルの取得、保存等）を利用するためのＡＰＩ群である。一方、固有Ｉ／Ｆ１７２は、特定の外部システム３０において利用できるＡＰＩであり、例えば図３６（ｂ）に示すようなＡＰＩが挙げられる。換言すれば、ファイル処理部１７０の固有Ｉ／Ｆ１７２は、ある特定の外部システム３０において利用できるファイル操作に関する機能（例えば、ファイルの編集等）を利用するためのＡＰＩ群である。したがって、共通Ｉ／Ｆ１７１は、すべてのストレージサービス連携部１６０に対して同様に定義される一方、固有Ｉ／Ｆ１７２は、当該固有Ｉ／Ｆ１７２で定義されるＡＰＩが利用可能な特定のストレージサービス連携部１６０に対して定義される。

一方、データ処理部１８０は、外部システム３０に保存されている電子ファイルの書誌情報等のメタデータ（例えば、ファイル一覧、フォルダ一覧等）を取得等するためのＡＰＩが定義された共通Ｉ／Ｆ１８１及び固有Ｉ／Ｆ１８２を有する。共通Ｉ／Ｆ１８１は、複数の外部システム３０間で共通に利用できるＡＰＩであり、例えば図３６（ｃ）に示すようなＡＰＩが挙げられる。換言すれば、データ処理部１８０の共通Ｉ／Ｆ１８１は、すべての外部システム３０で利用できるメタデータ取得等の機能を利用するためのＡＰＩ群である。一方、固有Ｉ／Ｆ１８２は、ある特定の外部システム３０において利用できるＡＰＩであり、例えば図３６（ｄ）に示すようなＡＰＩが挙げられる。換言すれば、データ処理部１８０の固有Ｉ／Ｆ１８２は、ある特定の外部システム３０において利用できるメタデータ取得等の機能（例えば、画像ファイル一覧の取得等）を利用するためのＡＰＩ群である。したがって、共通Ｉ／Ｆ１８１は、すべてのストレージサービス連携部１６０に対して同様に定義される一方、固有Ｉ／Ｆ１８２は、当該固有Ｉ／Ｆ１８２で定義されるＡＰＩが利用可能な特定のストレージサービス連携部１６０に対して定義される。

以上のように、本実施形態に係るサービス提供システム１０は、連携して処理を行う外部システム３０毎に、それぞれストレージサービス連携部１６０を有する。このため、連携先となる外部システム３０が追加等する場合には、対応するストレージサービス連携部１６０をサービス提供システム１０に追加等すればよい。したがって、連携先となる外部システム３０の追加等に伴う影響を局所化することができる。換言すれば、他の処理ブロック（サービス処理部１１０やドキュメントサービス部１５０等）に影響を与えることなく（すなわち、他の処理ブロックを修正等する必要なく）、連携先となる外部システム３０の追加等を行うことができる。これにより、連携先の外部システム３０の追加等の開発に要する工数を削減することができる。なお、ストレージサービス連携部１６０の追加等は、ＳＤＫ（Software Development Kit）を用いて行うことができる。

また、ストレージサービス連携部１６０は、共通Ｉ／Ｆ１７１と固有Ｉ／Ｆ１７２とを異なるモジュール等で定義している。また、共通Ｉ／Ｆ１７１及び固有Ｉ／Ｆ１７２で定義されるＡＰＩは、「ストレージサービス名」を指定することで利用することができる（すなわち、「ストレージサービス名」が可変部分となっている）。したがって、連携先の外部システム３０を追加する場合には、他のストレージサービス連携部１６０に定義されている共通Ｉ／Ｆ１７１を再利用することができる。換言すれば、連携先の外部システム３０を追加する場合には、当該追加する外部システム３０の固有Ｉ／Ｆ１７２のみ開発すればよい。これにより、連携先の外部システム３０の追加等の開発に要する工数を更に削減することができる。なお、このことは共通Ｉ／Ｆ１８１と固有Ｉ／Ｆ１８２に関しても同様である。

アプリ情報記憶部１９０は、アプリ情報１０００を記憶する。アプリ情報１０００は、アプリ画面を機器２０に表示させるための画面定義と、サービスを実現するため一連の処理を示す処理内容とが記述された情報であり、アプリ情報１０００を一意に識別するためのアプリＩＤ毎に、アプリ情報記憶部１９０に記憶されている。本実施形態では、クラウドサービスＡと連携したスキャン配信サービスを実現するためのアプリ情報を「アプリ情報１０００_１」とし、このアプリ情報１０００_１のアプリＩＤ「app001」とする。また、本実施形態では、クラウドサービスＡと連携したクラウドプリントサービスを実現するためのアプリ情報を「アプリ情報１０００_２」、このアプリ情報１０００_２のアプリＩＤを「app002」とする。

ここで、アプリ情報１０００_１の画面定義に含まれるデータ定義及びアプリ情報１０００_２の画面定義に含まれるデータ定義を、それぞれ図３７（ａ）及び図３７（ｂ）に示す。データ定義は、機器２０のブラウザ２１０により操作パネル９４０等に表示されるアプリ画面の入力欄（入力ボックス）や選択欄（選択ボックス）等を構成するための情報が記述されている。例えば、図３７（ａ）におけるデータ定義部１１０１では、ユーザがスキャンにより生成される電子ファイルのファイル名を入力するための入力欄を構成するための情報が記述されている。また、データ定義部１１０２では、ストレージサービスＡにおける保存先フォルダを選択するための選択欄を構成するための情報が記述されている。なお、データ定義部１１０２の「data_source」には選択欄の各選択要素（ここでは、保存先候補のフォルダ名及びフォルダＩＤ）の取得先のＵＲＬ（Uniform Resource Locator）が記述されている。

次に、アプリ情報１０００１の画面定義に含まれるレイアウト情報及びアプリ情報１０００２の画面定義に含まれるレイアウト情報を、それぞれ図３８（ａ）及び図３８（ｂ）に示す。レイアウト情報は、機器２０のブラウザ２１０により操作パネル９４０等に表示されるアプリ画面に表示される文字（入力欄の表示名称等）、入力欄や選択欄の表示位置等の情報が記述されている。例えば、図３８（ａ）におけるレイアウト定義部１３０１では、データ定義における「"data_id":1」（すなわち、データ定義部１１０１）の表示位置及び表示名称の情報が記述されている。これにより、具体例は後に示すが、アプリ画面には、表示名称が「ファイル名」である入力欄が、１番目の位置に表示される。また、レイアウト定義部１３０２では、データ定義における「"data_id":2」（すなわち、データ定義部１１０２）の表示位置及び表示名称の情報が記述されている。これにより、具体例は後に示すが、アプリ画面には、表示名称が「保存先フォルダ選択」である選択欄が、２番目の位置に表示される。

次に、アプリ情報１０００_１の処理内容及びアプリ情報１０００_２の処理内容を、それぞれ図３９（ａ）及び図３９（ｂ）に示す。処理内容は、サービス提供システム１０により提供されるサービスを実現するために、ドキュメントサービス部１５０やストレージサービス連携部１６０に要求する一連の処理が記述されている。例えば、図３９（ａ）に示す処理内容には、本実施形態に係るスキャン配信サービスを実現するための一連の処理（すなわち、スキャンされた電子ファイルをＯＣＲ処理した後、ストレージサービスＡの指定されたフォルダに配信する一連の処理）が記述されている。また、図３９（ｂ）に示す処理内容には、本実施形態に係るクラウドプリントサービスを実現するための一連の処理（すなわち、ストレージサービスＡから取得した電子ファイルを印刷データに変換した後、機器２０に送信する一連の処理）が記述されている。これらの処理内容についての詳細については、後述する。

図３５に戻り、外部コンポーネント管理装置４０は、外部コンポーネント処理部４１０を有する。外部コンポーネント処理部４１０は、例えば、外部コンポーネント管理装置４０が備えるＣＰＵにより実現される。

外部コンポーネント処理部４１０は、ロジック処理部１３０からの要求に応じて、外部コンポーネントを実行する。なお、外部コンポーネント処理部４１０の詳細な処理ブロックについては後述する。

以上のように、本実施形態に係るサービス提供システム１０は、機器２０にアプリ画面を表示させるための画面定義と、サービスを実現するための一連の処理内容とが記述されたアプリ情報１０００を利用してサービスを提供する。このため、サービス提供システム１０により提供されるサービスを追加等する場合には、アプリ情報記憶部１９０にアプリ情報１０００を追加等すればよい。また、アプリ情報１０００を追加するには、上記したように、画面定義と処理内容とを記述すればよいため、簡易に開発することができる。したがって、サービスの追加・変更等に伴う開発工数を削減させることができると共に、例えばサードベンダー等によるサービスの追加・変更等を容易に行うことができる。

図４０は、ロジック処理部１３０の一例の処理ブロック図である。ロジック処理部１３０は、フロー実行部１３１と、コンポーネント管理部１３２と、コンポーネント群１３３と、型変換管理部１３４と、型変換群１３５、コンポーネント管理テーブル５０００とを有する。また、ロジック処理部１３０は、型変換テーブル３０００を利用する。

フロー実行部１３１は、ブラウザ２１０からスキャン配信サービスの処理の実行要求を受け付けると、アプリ管理部１２０を介して、アプリ情報１０００から処理内容を取得する。そして、フロー実行部１３１は、取得した処理内容にしたがってコンポーネントに対して処理の実行を要求する。なお、ここで、コンポーネントとは、各種処理を実行するためのプログラム（モジュール）であり、例えばクラスや関数等で定義される。

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

コンポーネント群１３３は、コンポーネントの集合である。コンポーネント群１３３には、外部システム３０に電子ファイルを配信するための配信コンポーネント１３３１、外部システム３０から電子ファイルを取得するための取得コンポーネント１３３２が含まれる。また、コンポーネント群１３３には、電子ファイルにＯＣＲ処理を行うためのＯＣＲコンポーネント１３３３、電子ファイルを印刷データに変換するための印刷変換コンポーネント１３３４、そして、外部コンポーネントと連携する外部コンポ連携コンポーネント１３３５が含まれる。また、実施例１から実施例６に記載した印刷のワークフロー（印刷ワークフロー処理部１４）のコンポーネントとしては、印刷データ記憶部１１から原稿のファイル名の一覧を取得するコンポーネント、原稿のファイル名の一覧を含む画面情報を生成するコンポーネント、処理方法記憶部１３に記憶された処理方法の情報（原稿種別のＩＤや、ユーザのＩＤと処理方法とが関連づいた表）を処理方法記憶部１３から取得するコンポーネント、指定した原稿種別に対応する印刷データ（申請書の画像ファイル）を取得するコンポーネント、取得した原稿種別のＩＤ又は（及び）ユーザのＩＤを画像コードに変換するコンポーネント、印刷データ（申請書の画像ファイル）に画像コードを付加して、機器２０に送付する印刷データを生成するコンポーネント、等がある。また読取のワークフロー（読取ワークフロー処理部１５）のコンポーネントとしては、読取った機器２０から受信した申請書の画像データの所定位置にある画像コードを解析するコンポーネント、画像コードに含まれる原稿種別のＩＤ又は（及び）ユーザのＩＤに応じた、処理方法の情報を処理方法記憶部１３から取得するコンポーネント、取得した処理方法に応じて、所定の処理（所定の格納先、送信先に送信する処理等）を行うコンポーネント等がある。これらのコンポーネントを組み合わせて構成した各アプリケーションは、各種ワークフローのＷｅｂアプリケーションとしてサービス提供システム１０で記憶、管理される。

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

型変換管理部１３４は、データ型の型変換を管理する。ここで、各コンポーネントは、自身が扱えるデータ型が予め定まっている。したがって、型変換管理部１３４は、コンポーネントからの要求に応じて、図４１に示すような型変換テーブル３０００を参照して、型変換群１３５に定義されている型変換を生成する。そして、型変換管理部１３４は、生成された型変換に対して型変換処理の実行を要求する。ここで、型変換とは、データ型の型変換処理を実行するためのプログラム（モジュール）であり、例えばクラスや関数等で定義される。

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

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

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

フロー実行部１３１は、アプリ管理部１２０から取得した処理内容にしたがってコンポーネントの取得をコンポーネント管理部１３２に要求する。このとき、フロー実行部１３１は、処理内容に基づいて、後述するコンポーネント名を指定して、コンポーネントの取得を要求する。

コンポーネント管理部１３２は、フロー実行部１３１からの要求に応じて、コンポーネント管理テーブル５０００を参照し、当該要求に係るコンポーネントが内部コンポーネント又は外部コンポーネントのいずれであるかを判断する。そして、コンポーネント管理部１３２Ａは、当該要求に係るコンポーネントが外部コンポーネントである場合、外部コンポ連携コンポーネント１３３５を生成する。

コンポーネント群１３３に含まれる外部コンポ連携コンポーネント１３３５は、外部コンポーネント管理装置４０の外部コンポーネント処理部４１０と処理の連携を行うためのコンポーネントである。外部コンポ連携コンポーネント１３３５は、外部コンポーネント処理部４１０に対して、外部コンポーネントの処理の実行を要求する。なお、外部コンポ連携コンポーネント１３３５は、コンポーネント共通Ｉ／Ｆ１３３０を有する。

ここで、コンポーネント管理テーブル５０００は、図４２に示すようなデータ項目を有している。図４２は、コンポーネント管理テーブルの一例を説明するための図である。

図４２に示すコンポーネント管理テーブル５０００は、データ項目として、コンポーネントＩＤと、コンポーネント名と、ホスト名とを有する。コンポーネントＩＤは、コンポーネントを一意に識別する識別情報である。コンポーネント名は、コンポーネントの名称である。なお、本実施形態では、コンポーネント名は、コンポーネントに対して一意に付与されているものとする。

ホスト名は、コンポーネントを管理している装置を識別する情報である。すなわち、例えば、内部コンポーネントには、ホスト名「localhost」が関連付けられており、サービス提供システム１０で管理されていることが示されている。一方、例えば、外部コンポーネントには、ホスト名「server2.com」が関連付けられており、当該ホスト名の外部コンポーネント管理装置４０で管理されていることが示されている。

このように、コンポーネント管理テーブル５０００では、コンポーネント毎に、当該コンポーネントが管理されている装置のホスト名が関連付けられている。なお、処理内容作成部１２２は、コンポーネント管理テーブル５０００からコンポーネントの一覧を取得することで、処理内容の作成画面を作成する。

次に、外部コンポーネント処理部４１０の詳細な処理ブロックについて説明する。図４３は、実施例７に係る外部コンポーネント処理部４１０の一例の処理ブロック図である。

外部コンポーネント処理部４１０は、要求受付部４１１と、コンポーネント管理部４１２と、外部コンポーネント群４１３と、型変換管理部４１４と、型変換群４１５とを有する。また、外部コンポーネント処理部４１０は、型変換テーブル６０００を利用する。

要求受付部４１１は、ロジック処理部１３０からの要求を受け付けると、コンポーネント管理部４１２に対して、外部コンポーネントの生成を要求する。そして、要求受付部４１１は、外部コンポーネントが生成されると、当該外部コンポーネントに対して処理の実行を要求する。

コンポーネント管理部４１２は、要求受付部４１１からの要求に応じて、外部コンポーネントの生成を行う。

外部コンポーネント群４１３は、外部コンポーネントの集合である。外部コンポーネント群４１３には、サードベンダー等により開発された各種の外部コンポーネントが含まれる。例えば、外部コンポーネント群４１３には、外部システム３０に電子ファイルを配信するための配信αコンポーネント４１３１、電子ファイルを印刷データに変換するための印刷変換βコンポーネント４１３２が含まれる。

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

型変換管理部４１４は、データ型の型変換を管理する。ここで、外部コンポーネントは、自身が扱えるデータ型が予め定まっている。したがって、型変換管理部４１４は、外部コンポーネントからの要求に応じて、図４１に示すような型変換テーブル３０００を参照して、型変換群４１５に定義されている型変換を生成する。そして、型変換管理部４１４は、生成された型変換に対して型変換処理の実行を要求する。

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

また、これらの各型変換は、型変換共通Ｉ／Ｆ４１５０を有する。型変換共通Ｉ／Ｆ４１５０は、各型変換に対して共通に定義されたＡＰＩであり、型変換を生成するためのＡＰＩと、型変換に対して処理の実行を要求するためのＡＰＩとが含まれる。

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

≪スキャン配信サービスの全体処理≫
まず、機器２０のユーザが本実施形態に係るスキャン配信サービスを利用する場合の全体的な処理について説明する。図４４は、第１の実施形態に係るスキャン配信サービスの全体処理の一例のシーケンス図である。

まず、機器２０のユーザは、ブラウザ２１０を用いて、サービス提供システム１０により提供されるサービスの一覧を取得するための操作を行う。すると、機器２０は、サービスの一覧の取得要求をサービス提供システム１０のサービス処理部１１０に送信する（ステップＳ９０１）。そして、サービス処理部１１０のアプリ管理部１２０は、当該取得要求を受信すると、サービス提供システム１０により提供されるサービスの一覧を機器２０に送信する。これにより、機器２０のブラウザ２１０により、機器２０の操作パネル９４０にサービス提供システム１０により提供されるサービスの一覧が表示される。なお、サービスの一覧には、サービス提供システム１０により提供されるサービスのサービス名と、このサービスを実現するためのアプリ情報１０００のアプリＩＤとが含まれる。

ユーザは、機器２０の操作パネル９４０に表示されたサービスの一覧から、自身が利用を所望するサービスを選択する。すると、ブラウザ２１０は、選択されたサービスを実現するためのアプリ情報１０００のアプリＩＤをアプリ管理部１２０に送信する（ステップＳ９０２）。ここでは、ユーザによりサービス名「スキャン配信サービス」の利用が選択されたものとする。したがって、ブラウザ２１０は、アプリ情報１０００１のアプリＩＤ「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」に配信（アップロード）する。そして、電子ファイルのアップロードが完了すると、処理結果がブラウザ２１０に表示される。これにより、本実施形態に係るスキャン配信サービスが完了する。

次に、本実施形態に係る情報処理システム１の処理の詳細について説明する。本実施形態では、スキャン配信サービスを実現する一連の処理に、外部コンポーネントにより実行される処理が含まれる場合について説明する。すなわち、本実施形態に係るスキャン配信サービスは、内部コンポーネントにより実行される処理と、外部コンポーネントにより実行される処理とで構成される一連の処理により実現されるものとする。

≪ＯＣＲから配信実行までの処理≫
図４６は、実施例７に係るＯＣＲから配信実行までの処理の一例のシーケンス図である。まず、フロー実行部１３１は、ブラウザ２１０からスキャン配信サービスの処理の実行要求を受け付ける（ステップＳ２５０１）。ここで、当該実行要求には、アプリＩＤ「app001」と、図４４のステップＳ９０８で生成された電子ファイルと、選択された保存先フォルダ「FolderB」のフォルダＩＤ（保存先）とが含まれる。ここで、当該電子ファイルは、データ型が「InputStream」（すなわち、ストリームデータ）としてブラウザ２１０から渡されるものとする。

フロー実行部１３１は、ブラウザ２１０からスキャン配信サービスの実行要求を受け付けると、アプリ管理部１２０に処理内容の取得を要求する（ステップＳ２５０２）。ここで、本実施形態では、フロー実行部１３１により、図４７に示す処理内容が取得されたものとする。

フロー実行部１３１は、取得した処理内容にしたがってコンポーネントの取得を、コンポーネント管理部１３２Ａに要求する（ステップＳ２５０３）。より具体的には、フロー実行部１３１は、図４７に示す処理内容の「From("file:input")」の次に指定されている「.to("process:ocr")」に基づき、コンポーネント名が「ocr」であるコンポーネントの取得を、コンポーネント管理部１３２Ａに要求する。

コンポーネント管理部１３２Ａは、コンポーネントの取得要求を受け付けると、コンポーネント管理テーブル５０００を参照して、当該取得要求に係るコンポーネントが内部コンポーネント又は外部コンポーネントのいずれであるかを判断する（ステップＳ２５０４）。

すなわち、コンポーネント管理部１３２Ａは、コンポーネント管理テーブル５０００において、当該取得要求に含まれるコンポーネント名に関連付けられているホスト名が「localhost」であるか否かを判断する。そして、コンポーネント管理部１３２Ａは、当該ホスト名が「localhost」である場合、当該取得要求に係るコンポーネントは内部コンポーネントであると判断する。一方、コンポーネント管理部１３２Ａは、当該ホスト名が「localhost」でない場合、当該取得要求に係るコンポーネントは外部コンポーネントであると判断する。

ここで、コンポーネント管理テーブル５０００において、コンポーネント名「ocr」に関連付けられているホスト名は「localhost」である。したがって、コンポーネント管理部１３２Ａは、当該取得要求に係るコンポーネントは内部コンポーネントであると判断する。

コンポーネント管理部１３２Ａは、コンポーネントの取得要求に係るコンポーネントが内部コンポーネントであると判断された場合、当該取得要求に含まれるコンポーネント名に対応する内部コンポーネントを生成する（ステップＳ２５０５）。すなわち、コンポーネント管理部１３２Ａは、当該取得要求に含まれるコンポーネント名「ocr」に対応するＯＣＲコンポーネント１３３３を生成する。

そして、コンポーネント管理部１３２Ａは、生成されたＯＣＲコンポーネント１３３３をフロー実行部１３１に返却する。

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

ＯＣＲコンポーネント１３３３は、型変換管理部１３４に対して、型変換を要求する（ステップＳ２５０７）。ここで、当該型変換要求には、データと、ＯＣＲコンポーネント１３３３が扱うことができるデータ型を示す「LocalFilePath」の指定とが含まれる。

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

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

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

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

次に、フロー実行部１３１は、取得した処理内容にしたがってコンポーネントの取得を、コンポーネント管理部１３２Ａに要求する（ステップＳ２５１４）。より具体的には、フロー実行部１３１は、図４７に示す処理内容の「.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」に変換して（ステップＳ２７０９）、当該変換後のデータを型変換管理部４１４に返信する。

その後、型変換管理部４１４は、型変換後のデータを配信αコンポーネント４１３１に送信する（ステップＳ２７１０）。

配信αコンポーネント４１３１は、型変換管理部４１４からデータを受け取ると、処理を実行する（ステップＳ２７１１）。すなわち、本実施形態では、配信αコンポーネント４１３１は、ストレージサービスＢに対して、データの配信を実行する。

なお、配信αコンポーネント４１３１は、ストレージサービスＢ連携部１６０２を介さずに、ストレージサービスＢに対してデータを配信する。このように、外部コンポーネントは、内部コンポーネントと異なり、ストレージサービス連携部１６０やドキュメントサービス部１５０を用いずに、例えば配信処理やＯＣＲ処理等の各種の処理を実行する。ただし、これに限られず、外部コンポーネントは、内部コンポーネントと同様に、ストレージサービス連携部１６０やドキュメントサービス部１５０に処理要求を行うことで、各種の処理を実行しても良い。

そして、配信αコンポーネント４１３１は、処理結果を示すデータ返信する。これにより、本実施形態に係るスキャン配信サービスが提供される。

このように、本実施形態に係るサービス提供システム１０は、処理内容に外部コンポーネントにより実行される処理が含まれる場合、当該外部コンポーネントを管理する外部コンポーネント管理装置４０に処理の実行を要求する。そして、サービス提供システム１０とは異なる装置である外部コンポーネント管理装置４０において外部コンポーネントが実行される。

したがって、例えば、サードベンダー等により開発された外部コンポーネントに重大なバグや不具合等が存在していた場合でも、当該バグや不具合等による影響を外部コンポーネント管理装置４０内に局所化させることができる。換言すれば、サービス提供システム１０は、外部コンポーネントのバグや不具合等に伴う影響を受けることなく、サービスの提供を継続することができるようになる。

なお、本実施形態では、外部コンポーネント管理装置４０において外部コンポーネントが管理されるものとしたが、例えば、外部コンポーネントの品質が確保された後は、当該外部コンポーネントをサービス提供システム１０で管理するようにしてもよい。

≪処理内容の作成処理≫
次に、例えば、アプリ情報１０００の開発者等のユーザが、当該アプリ情報１０００に含まれる処理内容を作成する処理について説明する。図４９は、実施例７に係る処理内容の作成処理の一例のシーケンス図である。

まず、機器２０のユーザは、ブラウザ２１０を用いて、処理内容の作成画面を表示するための操作を行う。すると、機器２０のブラウザ２１０は、処理内容の作成画面の取得を、処理内容作成部１２２に要求する（ステップＳ２８０１）。

処理内容作成部１２２は、コンポーネント管理テーブル５０００からコンポーネントの一覧（例えば、コンポーネント名の一覧）を取得して、図５０（ａ）に示すような処理内容の作成画面７０００を作成する（ステップＳ２８０２）。そして、処理内容作成部１２２は、作成した処理内容の作成画面７０００をブラウザ２１０に返信する。

ここで、図５０（ａ）に示す処理内容の作成画面７０００は、アプリＩＤ表示欄７０１０と、コンポーネント表示欄７０２０と、処理内容作成欄７０３０とが含まれる。

アプリＩＤ表示欄７０１０は、作成する処理内容が含まれるアプリ情報１０００のアプリＩＤが表示される。このアプリＩＤは、例えば、上記のステップＳ２８０１でユーザにより指定されてもよい。

コンポーネント表示欄７０２０は、それぞれのコンポーネントを示すアイコン（表示処理部２１品）が一覧で表示されている。このようなコンポーネントを示すアイコンの一覧は、コンポーネント管理テーブル５０００から取得されたコンポーネント名に基づいて作成される。処理内容作成欄７０３０は、ユーザが処理内容を作成するための領域であり、例えば、コンポーネント表示欄７０２０に含まれるコンポーネントを示すアイコンをドラッグアンドドロップすることで、処理内容を作成することができる。

ここで、ユーザは、ブラウザ２１０を用いて、コンポーネント表示欄７０２０に含まれる取得コンポーネントと、印刷変換βコンポーネントとを、この順で、処理内容作成欄７０３０にドラッグアンドドロップしたものとする。すると、図５０（ｂ）に示すように処理内容の作成画面７１００の処理内容作成欄７１１０には、処理内容を模式的に示すフロー１２０が作成される。フロー１２０は、内部コンポーネントである取得コンポーネントを実行した後、外部コンポーネントである印刷変換βコンポーネントを実行する処理内容を示している。

これにより、ユーザにより処理内容が作成される。しかも、このとき、ユーザは、処理内容に含まれる一連の処理を実行するコンポーネントが、内部コンポーネントであるか外部コンポーネントであるかを意識することなく、処理内容を作成することができる。したがって、ユーザは、容易に処理内容を作成することができる。

機器２０のブラウザ２１０は、ユーザにより処理内容が作成されると、作成された処理内容を受け付ける（ステップＳ２８０３）。そして、機器２０のブラウザ２１０は、作成された処理内容の保存を処理内容作成部１２２に要求する（ステップＳ２８０４）。なお、当該保存要求には、アプリＩＤと、ユーザにより作成された処理内容とが含まれる。

サービス処理部１１０の処理内容作成部１２２は、処理内容の保存要求を受け取ると、当該保存要求をアプリ管理部１２０に転送する（ステップＳ２８０５）。次に、アプリ管理部１２０は、処理内容の保存要求を受け取ると、当該保存要求に含まれる処理内容をアプリＩＤと関連付けてアプリ情報記憶部１９０に保存する（ステップＳ２８０６）。そして、アプリ管理部１２０は、保存結果を返信する。これにより、ユーザにより作成された処理内容がアプリ情報記憶部１９０に記憶される。

＜まとめ＞
以上のように、情報処理システム１によれば、サービス提供システム１０は外部サービスと連携したサービスを機器２０に提供することができる。また、サービス提供システム１０は、連携先の外部サービスの追加・変更等を容易に行うことができる。更に、サービス提供システム１０は、機器２０に提供するサービスの追加・変更等（すなわち、アプリ情報１０００の追加・変更等）を容易に行うことができる。これらにより、第１の実施形態に係るサービス提供システム１０は、サービスの追加・変更等に伴う開発・維持に要する工数を削減することができる。

また、サードベンダー等により開発された外部コンポーネントを、サービス提供システム１０とは異なる装置である外部コンポーネント管理装置４０で管理及び実行させることができる。これにより、例えば、外部コンポーネントにバグや不具合が存在する等、外部コンポーネントの品質が十分でない場合においても、バグや不具合等に伴う影響を外部コンポーネント管理装置４０に局所化させることができる。

したがって、実施例７に係る情報処理システム１によれば、例えば、外部コンポーネントのバグや不具合等に伴いサービス提供システム１０の処理能力が低下、又はサービス提供システム１０が停止するような事態等を防止することができる。

＜その他の適用例＞
以上、本発明を実施するための最良の形態について実施例を用いて説明したが、本発明はこうした実施例に何等限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々の変形及び置換を加えることができる。各実施例を組合せた処理を実行してもよい。

また、本実施形態では機器２０として主に画像形成装置を説明に使用したが、画像形成装置に限られない。機器２０は、例えば、ＰＪ（Projector：プロジェクタ）、ＩＷＢ（Interactive White Board：相互通信が可能な電子式の黒板機能を有する白板）、デジタルサイネージ等の出力装置、ＨＵＤ（Head Up Display）装置、産業機械、撮像装置、集音装置、医療機器、ネットワーク家電、自動車（Connected Car）、ノートＰＣ、携帯電話、スマートフォン、タブレット端末、ゲーム機、ＰＤＡ（Personal Digital Assistant）、デジタルカメラ、ウェアラブルＰＣ又はデスクトップＰＣ等であってもよい。

また、図５などの構成例は、サービス提供システム１０による処理の理解を容易にするために、主な機能に応じて分割したものである。処理単位の分割の仕方や名称によって本願発明が制限されることはない。サービス提供システム１０の処理は、処理内容に応じて更に多くの処理単位に分割することもできる。また、１つの処理単位が更に多くの処理を含むように分割することもできる。

また、実施例に記載された装置群は、本明細書に開示された実施形態を実施するための複数のコンピューティング環境のうちの１つを示すものにすぎない。ある実施形態では、サービス提供システム１０は、サーバクラスタといった複数のコンピューティングデバイスを含む。複数のコンピューティングデバイスは、ネットワークや共有メモリなどを含む任意のタイプの通信リンクを介して互いに通信するように構成されており、本明細書に開示された処理を実施する。

更に、サービス提供システム１０は、開示された処理ステップ、例えば図１１，図１６等を様々な組み合わせで共有するように構成できる。例えば、所定のユニットによって実行されるプロセスは、サービス提供システム１０が有する複数の情報処理装置によって実行され得る。また、サービス提供システム１０は、1つのサーバ装置にまとめられていても良いし、複数の装置に分けられていても良い。

上記で説明した実施形態の各機能は、一又は複数の処理回路によって実現することが可能である。ここで、本明細書における「処理回路」とは、電子回路により実装されるプロセッサのようにソフトウェアによって各機能を実行するようプログラミングされたプロセッサや、上記で説明した各機能を実行するよう設計されたASIC(Application Specific Integrated Circuit)、DSP（Digital Signal Processor）、FPGA（Field Programmable Gate Array）や従来の回路モジュール等のデバイスを含むものとする。

１ 情報処理システム
１０ サービス提供システム
２０ 機器
３０ 外部システム
４０ 外部コンポーネント管理装置

特開２０１８‐００７０８５号公報

Claims (14)

1. サービス提供システムと機器とがネットワークを介して通信する情報処理システムであって、
   前記サービス提供システムは、
   前記機器が出力する出力データの識別情報に対応付けて処理方法が登録された処理方法記憶部と、
   前記出力データの識別情報を付加した前記出力データを前記機器に送信する第一の通信部と、を有し、
   前記機器は、
   前記サービス提供システムから受信した前記出力データを前記出力データの識別情報と共に出力する出力部と、
   前記出力部が出力した前記出力データに基づく入力データの入力を前記出力データの識別情報と共に受け付ける入力部と、
   前記入力部により入力された前記出力データの識別情報が付加されている前記入力データを前記サービス提供システムに送信する第二の通信部と、を有し、
   前記サービス提供システムは、前記入力データに付加されている前記出力データの識別情報に対応付けられている前記処理方法で前記入力データを処理することを特徴とする情報処理システム。
2. 前記機器が、前記サービス提供システムから受信した前記出力データを出力する第一のアプリの選択を受け付けた場合、前記サービス提供システムに前記出力データのリストを要求し、
   前記サービス提供システムから取得した前記出力データのリストを表示し、前記リストから受け付けた前記出力データを前記サービス提供システムに通知して、前記サービス提供システムから受信した前記出力データを出力し、
   前記機器が、前記出力部が出力した前記出力データに基づく入力データの入力を受け付ける第二のアプリの選択を受け付けた場合、前記入力データの入力を前記出力データの識別情報と共に受け付けて前記サービス提供システムに送信し、
   前記サービス提供システムは、前記入力データに付加されている前記出力データの識別情報に対応付けられている前記処理方法で前記入力データを処理することを特徴とする請求項１に記載の情報処理システム。
3. 前記機器は、
   前記サービス提供システムにおいて記憶されている前記出力データのファイル名、又は、前記出力データの名称を表示することを特徴とする請求項２に記載の情報処理システム。
4. 前記処理方法記憶部には、ユーザの識別情報に対応付けて前記処理方法が登録されており、
   前記機器は、
   認証が成功した前記ユーザの識別情報を前記サービス提供システムに送信し、
   前記サービス提供システムは、
   前記ユーザの識別情報と前記出力データの識別情報を付加した前記出力データを前記機器に送信し、
   前記機器から前記入力データを受信すると、前記入力データに付加されている前記出力データの識別情報に対応付けられている前記処理方法、及び、前記ユーザの識別情報に対応付けられている前記処理方法で前記入力データを処理することを特徴とする請求項１〜３のいずれか１項に記載の情報処理システム。
5. 前記処理方法記憶部には、ユーザの識別情報に対応付けて前記処理方法が登録されており、
   前記機器は、前記入力部が入力を受け付けた前記入力データと認証が成功した前記ユーザの識別情報を前記サービス提供システムに送信し、
   前記サービス提供システムは、
   前記入力データと前記ユーザの識別情報を受信すると、前記入力データに付加されている前記出力データの識別情報に対応付けられている前記処理方法、及び、前記ユーザの識別情報に対応付けられている前記処理方法で前記入力データを処理することを特徴とする請求項４に記載の情報処理システム。
6. 前記サービス提供システムが、前記出力データに付加された前記ユーザの識別情報、又は、認証が成功した前記ユーザの識別情報のどちらに対応付けられている前記処理方法で前記入力データを処理するかの選択を受け付ける画面を前記機器が表示することを特徴とする請求項５に記載の情報処理システム。
7. 前記処理方法記憶部には、ユーザの識別情報に対応付けて前記処理方法が登録されており、
   前記サービス提供システムは、
   前記機器から送信された前記ユーザの識別情報に対応付けられている前記処理方法を前記機器に送信し、
   前記機器は、
   前記サービス提供システムから送信された前記処理方法を表示し、
   選択を受け付けた前記処理方法の選択結果と、前記入力部が入力を受け付けた前記入力データを前記サービス提供システムに送信し、
   前記サービス提供システムは、前記入力データに付加されている前記出力データの識別情報に対応付けられている前記処理方法、及び、前記処理方法の選択結果で特定される前記処理方法で前記入力データを処理することを特徴とする請求項１〜６のいずれか１項に記載の情報処理システム。
8. 前記処理方法記憶部には、前記出力データの識別情報に対応付けて処理方法と前記出力データの後処理メッセージが登録されており、
   前記サービス提供システムは、
   前記機器から前記入力データを受信した場合、前記入力データに付加されている前記出力データの識別情報に対応付けられている前記処理方法で前記入力データを処理し、
   前記出力データの識別情報に対応付けられている前記後処理メッセージを前記機器に送信し、
   前記機器は、
   前記サービス提供システムから受信した前記後処理メッセージを表示することを特徴とする請求項１〜７のいずれか１項に記載の情報処理システム。
9. 前記サービス提供システムは、
   前記入力データに付加されている前記出力データの識別情報に対応付けられている前記処理方法で前記入力データを処理した後、前記入力データを処理した前記処理方法を前記機器に送信し、
   前記機器は、前記サービス提供システムから受信した前記処理方法を表示することを特徴とする請求項１〜８のいずれか１項に記載の情報処理システム。
10. 前記第一のアプリは、複数の処理が組み合わせされた一連の処理を実行する第一のワークフローに対応しており、
    前記第二のアプリは、複数の処理が組み合わせされた一連の処理を実行する第二のワークフローに対応しており、
    前記機器において前記第一のアプリが選択された場合、前記機器は
    前記出力データを選択する選択画面を表示して前記出力データの選択を受け付け、選択を受け付けた前記出力データの識別情報を前記サービス提供システムに送信し、
    前記サービス提供システムは、前記機器からの前記識別情報の受信に応じて、識別情報に対応する印刷データを取得し、前記処理方法記憶部の前記出力データの識別情報を含む画像コードを付加した前記出力データを前記機器に送信して印刷させる前記第一のワークフローを実行し、
    前記機器において前記第二のアプリが選択された場合、前記機器は、
    前記第一のワークフローの実行によって、前記画像コードを付加した前記出力データが印刷された原稿を読み取り、前記原稿を読み取って生成された前記入力データを前記サービス提供システムに送信し、
    前記サービス提供システムは、前記入力データに含まれる前記画像コードを解析して、前記出力データの前記識別情報を取得し、取得した識別情報に基づき前記処理方法記憶部に登録されている前記処理方法のうち、前記識別情報に対応づいた処理方法に基づいて、前記識別情報に関連づいた送信先に、前記入力データを送信する前記第二のワークフローを実行することを特徴とする請求項２に記載の情報処理システム。
11. 前記処理方法記憶部、前記印刷データを記憶する印刷データ記憶部、及び、原稿が読み取られて生成された画像データを記憶する読取データ記憶部は、前記サービス提供システムとネットワークを介して接続するクラウドストレージに設けられ、
    前記サービス提供システムは、
    前記クラウドストレージのアカウント情報の入力と、前記第一のワークフロー及び第二のワークフローが実行される際に参照する参照先として前記クラウドストレージの前記処理方法記憶部、前記印刷データ記憶部、及び、前記読取データ記憶部を指定する設定を受け付けることが可能な設定部を有し、
    前記第一のワークフローが実行された際には、前記設定部が設定を受け付けた前記処理方法記憶部を参照して、前記機器から送付された前記識別情報に対応する出力データを、前記設定部が設定を受け付けた前記印刷データ記憶部から取得すると共に、前記出力データに前記画像コードを付加して前記機器に送信し、
    前記第二のワークフローが実行された際には、前記設定部が設定を受け付けた前記処理方法記憶部を参照して、前記画像コードから取得した前記識別情報に対応する処理方法に基づいて、前記識別情報に対応する送信先として、前記設定部が設定を受け付けた前記読取データ記憶部に送信して記憶することを特徴とする請求項１０に記載の情報処理システム。
12. 前記処理方法記憶部に記憶される前記処理方法を、端末装置がネットワークを介して取得し、前記端末装置が表示した前記処理方法に対し、原稿の識別情報ごとの送付先の変更、又はユーザの識別情報ごとの送付先の変更を含む編集を受け付け、
    前記サービス提供システムは、
    編集後の前記処理方法を、前記第一のワークフロー又は前記第二のワークフローを実行する場合に参照して、処理を実行することを特徴とする請求項１１に記載の情報処理システム。
13. サービス提供システムと機器とがネットワークを介して通信する情報処理システムが行う情報処理方法であって、
    前記サービス提供システムは、
    前記機器が出力する出力データの識別情報を付加した前記出力データを前記機器に送信し、
    前記機器は、
    出力部が、前記サービス提供システムから受信した前記出力データを前記出力データの識別情報と共に出力するステップと、
    入力部が、前記出力部が出力した前記出力データに基づく入力データの入力を前記出力データの識別情報と共に受け付けるステップと、
    第二の通信部が、前記入力部により入力された前記出力データの識別情報が付加されている前記入力データを前記サービス提供システムに送信するステップと、を有し
    前記サービス提供システムは、前記入力データに付加されている前記出力データの識別情報に対応付けられている処理方法で前記入力データを処理することを特徴とする情報処理方法。
14. サービス提供システムとネットワークを介して通信する機器であって、
    前記サービス提供システムから受信した、出力データの識別情報が付加された出力データを前記出力データの識別情報と共に出力する出力部と、
    前記出力部が出力した前記出力データに基づく入力データの入力を前記出力データの識別情報と共に受け付ける入力部と、
    前記入力部により入力された前記出力データの識別情報が付加されている前記入力データを前記サービス提供システムに送信する第二の通信部と、を有し、
    前記サービス提供システムは、前記入力データに付加されている前記出力データの識別情報に対応付けられている処理方法で前記入力データを処理することを特徴とする機器。

Images