図面 (/)

技術 情報処理システム、情報処理装置、及び情報処理方法

出願人 株式会社リコー
発明者 林雄一郎
出願日 2016年8月24日 (5年4ヶ月経過) 出願番号 2016-163493
公開日 2018年3月1日 (3年10ヶ月経過) 公開番号 2018-032193
状態 特許登録済
技術分野 エラー時の再試行
主要キーワード 処理フロー情報 圧縮コンポーネント エラーコード情報 型変換処理 クラウド型 変換コンポーネント OCR処理後 ロジック処理
関連する未来課題
重要な関連分野

この項目の情報は公開日時点(2018年3月1日)のものです。
また、この項目は機械的に抽出しているため、正しく解析できていない場合があります

図面 (20)

課題

一連の処理の実行をリトライする。

解決手段

所定の処理を実行するプログラムを有する情報処理システムであって、電子データを用いた一連の処理毎に、プログラム識別情報と、実行順とが定義されたフロー情報を、フロー識別情報と関連付けて記憶する記憶手段と、電子データに関する情報と、フロー識別情報とを受信する受信手段と、前記記憶手段に記憶されているフロー情報のうち、前記受信手段により受信された前記フロー識別情報と関連付けて記憶されているフロー情報を取得する取得手段と、取得された前記フロー情報に定義されている前記プログラム識別情報により識別される前記プログラムそれぞれを、前記実行順に従って実行させることで、前記電子データに関する情報に基づく電子データを用いた前記一連の処理を実行する実行手段と、を有し、前記実行手段は、前記一連の処理でエラーが発生した場合、該一連の処理の実行をリトライする。

概要

背景

近年、複数の機能(例えば、スキャンプリントメール配信等)を組み合わせた機能を提供するサービスが知られるようになった。例えば、スキャンにより生成された電子データをメール配信するサービス等が知られている。このようなサービスは、各機能を実現する1以上の処理が一連の処理として実行されることにより実現される。

また、1以上の処理を一連の処理として表した処理情報等が含まれる指示書に基づいて、当該一連の処理を実行する画像形成装置が知られている(例えば特許文献1参照)。

概要

一連の処理の実行をリトライする。所定の処理を実行するプログラムを有する情報処理システムであって、電子データを用いた一連の処理毎に、プログラム識別情報と、実行順とが定義されたフロー情報を、フロー識別情報と関連付けて記憶する記憶手段と、電子データに関する情報と、フロー識別情報とを受信する受信手段と、前記記憶手段に記憶されているフロー情報のうち、前記受信手段により受信された前記フロー識別情報と関連付けて記憶されているフロー情報を取得する取得手段と、取得された前記フロー情報に定義されている前記プログラム識別情報により識別される前記プログラムそれぞれを、前記実行順に従って実行させることで、前記電子データに関する情報に基づく電子データを用いた前記一連の処理を実行する実行手段と、を有し、前記実行手段は、前記一連の処理でエラーが発生した場合、該一連の処理の実行をリトライする。

目的

近年、複数の機能(例えば、スキャンやプリント、メール配信等)を組み合わせた機能を提供する

効果

実績

技術文献被引用数
0件
牽制数
0件

この技術が所属する分野

ライセンス契約や譲渡などの可能性がある特許掲載中! 開放特許随時追加・更新中 詳しくはこちら

請求項1

1以上の情報処理装置を含み、所定の処理をそれぞれ実行する複数のプログラムを有する情報処理システムであって、電子データを用いた一連の処理毎に、該一連の処理のそれぞれの処理を実行する1以上の前記プログラムを識別するプログラム識別情報と、1以上の前記プログラムの実行順とが定義されたフロー情報を、該フロー情報を識別するフロー識別情報と関連付けて記憶する第1の記憶手段と、前記情報処理システムに接続される1以上の機器のうちの一の機器から、電子データに関する情報と、フロー識別情報とを受信する受信手段と、前記第1の記憶手段に記憶されているフロー情報のうち、前記受信手段により受信された前記フロー識別情報と関連付けて前記第1の記憶手段に記憶されているフロー情報を取得する取得手段と、前記取得手段により取得された前記フロー情報に定義されている前記プログラム識別情報により識別される前記プログラムそれぞれを、前記フロー情報に定義されている前記実行順に従って実行させることで、前記受信手段により受信された前記電子データに関する情報に基づく電子データを用いた前記一連の処理を実行する実行手段と、を有し、前記実行手段は、前記一連の処理でエラーが発生した場合、該一連の処理の実行をリトライする、情報処理システム。

請求項2

前記実行手段は、前記一連の処理のそれぞれの処理を実行する前記プログラムのうちの一のプログラムにより実行される処理でエラーが発生した場合、前記プログラムそれぞれを、前記実行順に従って最初から実行させることで、前記一連の処理の実行をリトライする、請求項1に記載の情報処理システム。

請求項3

前記フロー情報に定義されている前記プログラム識別情報のちの一のプログラム識別情報と、該一のプログラム識別情報により識別される一のプログラムにより実行される処理でエラーが発生した場合に前記一連の処理の実行をリトライするか否かを示す第1のリトライ可否情報とが関連付けて記憶された第2の記憶手段を有し、前記実行手段は、前記一連の処理のそれぞれの処理を実行する前記プログラムのうちの一のプログラムにより実行される処理でエラーが発生した場合、該一のプログラムを識別するプログラム識別情報と関連付けて前記第2の記憶手段に記憶されている前記第1のリトライ可否情報が、前記一連の処理の実行をリトライすることを示すものである場合、前記一連の処理の実行をリトライする、請求項2に記載の情報処理システム。

請求項4

前記実行手段は、前記一連の処理でエラーが発生した場合、該一連の処理の実行をリトライした回数が所定の上限回数未満であるか否かを判定し、前記リトライした回数が前記上限回数未満である場合、前記一連の処理の実行をリトライする、請求項1乃至3の何れか一項に記載の情報処理システム。

請求項5

前記上限回数は、前記一の機器のユーザにより設定された値、又は前記フロー情報に定義された値である、請求項4に記載の情報処理システム。

請求項6

前記エラーを示すエラーコードと、該エラーが発生した場合に前記一連の処理の実行をリトライさせるか否かを示す第2のリトライ可否情報とが関連付けて記憶された第3の記憶手段を有し、前記実行手段は、前記一連の処理でエラーが発生した場合、該エラーを示すエラーコードと関連付けて前記第3の記憶手段に記憶されている前記第2のリトライ可否情報が、前記一連の処理の実行をリトライさせることを示すものである場合、前記一連の処理の実行をリトライする、請求項1乃至5の何れか一項に記載の情報処理システム。

請求項7

前記実行手段は、電子データに対して、該電子データのデータ型を所定のデータ型に変換する型変換手段を1以上有し、前記電子データのデータ型を、前記型変換手段により前記プログラムが処理可能なデータ型に変換した後、前記プログラムに処理を実行させることにより、前記電子データを用いた前記一連の処理を実行する、請求項1乃至6の何れか一項に記載の情報処理システム。

請求項8

前記実行順は、前記フロー情報において前記プログラム識別情報が定義されている順である、請求項1乃至7の何れか1項に記載の情報処理システム。

請求項9

所定の処理をそれぞれ実行する複数のプログラムを有する情報処理装置であって、電子データを用いた一連の処理毎に、該一連の処理のそれぞれの処理を実行する1以上の前記プログラムを識別するプログラム識別情報と、1以上の前記プログラムの実行順とが定義されたフロー情報を、該フロー情報を識別するフロー識別情報と関連付けて記憶する第1の記憶手段と、前記情報処理装置に接続される1以上の機器のうちの一の機器から、電子データに関する情報と、フロー識別情報とを受信する受信手段と、前記第1の記憶手段に記憶されているフロー情報のうち、前記受信手段により受信された前記フロー識別情報と関連付けて前記第1の記憶手段に記憶されているフロー情報を取得する取得手段と、前記取得手段により取得された前記フロー情報に定義されている前記プログラム識別情報により識別される前記プログラムそれぞれを、前記フロー情報に定義されている前記実行順に従って実行させることで、前記受信手段により受信された前記電子データに関する情報に基づく電子データを用いた前記一連の処理を実行する実行手段と、を有し、前記実行手段は、前記一連の処理でエラーが発生した場合、該一連の処理の実行をリトライする、情報処理装置。

請求項10

1以上の情報処理装置を含み、所定の処理をそれぞれ実行する複数のプログラムを有する情報処理システムであって、電子データを用いた一連の処理毎に、該一連の処理のそれぞれの処理を実行する1以上の前記プログラムを識別するプログラム識別情報と、1以上の前記プログラムの実行順とが定義されたフロー情報を、該フロー情報を識別するフロー識別情報と関連付けて記憶する第1の記憶手段を有する情報処理システムに用いられる情報処理方法において、前記情報処理システムに接続される1以上の機器のうちの一の機器から、電子データに関する情報と、フロー識別情報とを受信する受信手順と、前記第1の記憶手段に記憶されているフロー情報のうち、前記受信手順により受信された前記フロー識別情報と関連付けて前記第1の記憶手段に記憶されているフロー情報を取得する取得手順と、前記取得手順により取得された前記フロー情報に定義されている前記プログラム識別情報により識別される前記プログラムそれぞれを、前記フロー情報に定義されている前記実行順に従って実行させることで、前記受信手順により受信された前記電子データに関する情報に基づく電子データを用いた前記一連の処理を実行する実行手順と、を有し、前記実行手順は、前記一連の処理でエラーが発生した場合、該一連の処理の実行をリトライする、情報処理方法。

技術分野

0001

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

背景技術

0002

近年、複数の機能(例えば、スキャンプリントメール配信等)を組み合わせた機能を提供するサービスが知られるようになった。例えば、スキャンにより生成された電子データをメール配信するサービス等が知られている。このようなサービスは、各機能を実現する1以上の処理が一連の処理として実行されることにより実現される。

0003

また、1以上の処理を一連の処理として表した処理情報等が含まれる指示書に基づいて、当該一連の処理を実行する画像形成装置が知られている(例えば特許文献1参照)。

発明が解決しようとする課題

0004

しかしながら、上記の従来技術においては、例えば、一連の処理でエラー等が発生した場合、当該一連の処理の実行をリトライすることができなかった。したがって、例えば画像形成装置のユーザは、再度、当該一連の処理を実行させるための操作を行う必要があった。

0005

本発明の一実施形態は、上記の点に鑑みてなされたもので、一連の処理の実行をリトライすることを目的とする。

課題を解決するための手段

0006

上記目的を達成するため、本発明の一実施形態は、1以上の情報処理装置を含み、所定の処理をそれぞれ実行する複数のプログラムを有する情報処理システムであって、電子データを用いた一連の処理毎に、該一連の処理のそれぞれの処理を実行する1以上の前記プログラムを識別するプログラム識別情報と、1以上の前記プログラムの実行順とが定義されたフロー情報を、該フロー情報を識別するフロー識別情報と関連付けて記憶する第1の記憶手段と、前記情報処理システムに接続される1以上の機器のうちの一の機器から、電子データに関する情報と、フロー識別情報とを受信する受信手段と、前記第1の記憶手段に記憶されているフロー情報のうち、前記受信手段により受信された前記フロー識別情報と関連付けて前記第1の記憶手段に記憶されているフロー情報を取得する取得手段と、前記取得手段により取得された前記フロー情報に定義されている前記プログラム識別情報により識別される前記プログラムそれぞれを、前記フロー情報に定義されている前記実行順に従って実行させることで、前記受信手段により受信された前記電子データに関する情報に基づく電子データを用いた前記一連の処理を実行する実行手段と、を有し、前記実行手段は、前記一連の処理でエラーが発生した場合、該一連の処理の実行をリトライする。

発明の効果

0007

本発明の一実施形態によれば、一連の処理の実行をリトライすることができる。

図面の簡単な説明

0008

第一の実施形態に係る情報処理システムの一例のシステム構成を示す図である。
第一の実施形態に係るサービス提供システムの一例のハードウェア構成を示す図である。
第一の実施形態に係る機器の一例のハードウェア構成を示す図である。
第一の実施形態に係る情報処理システムの一例の機能構成を示す図である。
第一の実施形態に係るロジック処理部の一例の機能構成を示す図である。
型変換情報テーブルの一例を示す図である。
処理フロー情報の一例を示す図である。
第一の実施形態に係る「スキャンToメール配信」サービスの全体処理の一例を示すシーケンス図である。
画面情報の一例を示す図である。
アプリ画面の一例を示す図である。
第一の実施形態に係る処理フロー実行処理の一例を示すシーケンス図である。
第一の実施形態に係る処理フローの実行処理の他の例を示すシーケンス図である。
処理フロー情報の他の例を示す図である。
第二の実施形態に係るロジック処理部の一例の機能構成を示す図である。
エラーコード情報テーブルの一例を示す図である。
第二の実施形態に係る処理フローの実行処理の一例を示すシーケンス図である。
エラー情報の一例を示す図である。
エラーコード情報テーブルの他の例を示す図である。
第三の実施形態に係るロジック処理部の一例の機能構成を示す図である。
フロー進捗情報テーブルの一例を示す図である。
第三の実施形態に係る処理フローの実行処理の一例を示すシーケンス図である。

実施例

0009

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

0010

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

0011

図1に示す情報処理システム1は、サービス提供システム10と、機器20とを含み、インターネット等の広域的ネットワークN1を介して通信可能に接続されている。

0012

サービス提供システム10は、一台以上の情報処理装置で実現され、ネットワークN1を介して、種々の機能をそれぞれ実現する複数の処理のうちの1以上の処理を組み合わせた一連の処理により実現される各種のサービスを提供する。

0013

ここで、機能とは、文書ファイル画像ファイル等の電子ファイルに関する機能である。機能には、例えば、プリント、スキャン、ファクシミリ送信データ形式の変換、メール配信、OCR(Optical Character Recognition)処理、加工や圧縮解凍リポジトリへの格納等が挙げられる。

0014

本実施形態に係るサービス提供システム10が提供するサービスの具体例については後述する。なお、以降では、一連の処理を「処理フロー」とも表す。

0015

機器20は、ユーザが使用する各種の電子機器である。すなわち、機器20は、例えば、MFP(Multifunction Peripheral)等の画像形成装置、PC(パーソナルコンピュータ)、プロジェクタ電子黒板デジタルカメラ等である。ユーザは、機器20を用いて、サービス提供システム10が提供する各種のサービスを利用することができる。

0016

なお、以降では、複数の機器20について、各々を区別するときは、「機器201」、「機器202」等と添え字を用いて記載する。

0017

また、図1に示す情報処理システム1の構成は一例であって、他の構成であっても良い。例えば、本実施形態に係る情報処理システム1には、電子データの入力及び出力の少なくとも一方を行う各種機器が含まれ、これらの機器がサービス提供システム10により提供されるサービスを利用しても良い。

0018

<ハードウェア構成>
次に、本実施形態に係る情報処理システム1に含まれるサービス提供システム10のハードウェア構成について、図2を参照しながら説明する。図2は、本実施形態に係るサービス提供システム10の一例のハードウェア構成を示す図である。

0019

図2に示すサービス提供システム10は、入力装置11と、表示装置12と、外部I/F13と、RAM(Random Access Memory)14とを有する。また、サービス提供システム10は、ROM(Read Only Memory)15と、CPU(Central Processing Unit)16と、通信I/F17と、HDD(Hard Disk Drive)18とを有する。これらの各ハードウェアは、それぞれがバスBで接続されている。

0020

入力装置11は、キーボードマウスタッチパネル等を含み、ユーザが各操作信号を入力するのに用いられる。表示装置12は、ディスプレイ等を含み、サービス提供システム10による処理結果を表示する。なお、入力装置11及び表示装置12の少なくとも一方は、必要なときにサービス提供システム10に接続して利用する形態であっても良い。

0021

通信I/F17は、サービス提供システム10をネットワークN1に接続するインタフェースである。これにより、サービス提供システム10は、通信I/F17を介して通信を行うことができる。

0022

HDD18は、プログラムやデータを格納している不揮発性記憶装置である。HDD18に格納されるプログラムやデータには、サービス提供システム10全体を制御する基本ソフトウェアであるOS(Operating System)、OS上において各種機能を提供するアプリケーションソフトウェア等がある。

0023

なお、サービス提供システム10は、HDD18に代え、記憶媒体としてフラッシュメモリを用いるドライブ装置(例えばソリッドステートドライブSSD)を利用するものであっても良い。また、HDD18は、格納しているプログラムやデータを所定のファイルシステム及び/又はDBにより管理している。

0024

外部I/F13は、外部装置とのインタフェースである。外部装置には、記録媒体13a等がある。これにより、サービス提供システム10は、外部I/F13を介して記録媒体13aの読み取りや書き込みを行うことができる。記録媒体13aには、フレキシブルディスク、CD、DVD、SDメモリカードUSBメモリ等がある。

0025

ROM15は、電源を切ってもプログラムやデータを保持することができる不揮発性の半導体メモリである。ROM15には、サービス提供システム10の起動時に実行されるBIOS(Basic Input/Output System)、OS設定、及びネットワーク設定等のプログラムやデータが格納されている。RAM14は、プログラムやデータを一時保持する揮発性の半導体メモリである。

0026

CPU16は、ROM15やHDD18等の記憶装置からプログラムやデータをRAM14上に読み出し、処理を実行することで、サービス提供システム10全体の制御や機能を実現する演算装置である。

0027

本実施形態に係るサービス提供システム10は、図2に示すハードウェア構成を有することにより、後述するような各種処理を実現できる。

0028

次に、本実施形態に係る情報処理システム1に含まれる機器20が画像形成装置である場合のハードウェア構成について、図3を参照しながら説明する。図3は、本実施形態に係る機器20の一例のハードウェア構成を示す図である。

0029

図3に示す機器20は、コントローラ21と、操作パネル22と、外部I/F23と、通信I/F24と、プリンタ25と、スキャナ26とを有する。また、コントローラ21は、CPU31と、RAM32と、ROM33と、NVRAM34と、HDD35とを有する。

0030

ROM33は、各種プログラムやデータを格納している不揮発性の半導体メモリである。RAM32は、プログラムやデータを一時保持する揮発性の半導体メモリである。NVRAM34は、例えば設定情報等を格納している。また、HDD35は、各種プログラムやデータを格納している不揮発性の記憶装置である。

0031

CPU31は、ROM33やNVRAM34、HDD35等からプログラムやデータ、設定情報等をRAM32上に読み出し、処理を実行することで、機器20全体の制御や機能を実現する演算装置である。

0032

操作パネル22は、ユーザからの入力を受け付ける入力部と、表示を行う表示部とを備えている。外部I/F23は、外部装置とのインタフェースである。外部装置には、記録媒体23a等がある。これにより、機器20は、外部I/F23を介して記録媒体23aの読み取り及び/又は書き込みを行うことができる。なお、記録媒体23aには、例えば、ICカード、フレキシブルディスク、CD、DVD、SDメモリカード、USBメモリ等がある。

0033

通信I/F24は、機器20をネットワークに接続するインタフェースである。これにより、機器20は、通信I/F24を介して通信を行うことができる。プリンタ25は、印刷データを印刷する印刷装置である。スキャナ26は、原稿を読み取って電子ファイル(画像ファイル)を生成する読取装置である。

0034

本実施形態に係る機器20は、図3に示すハードウェア構成を有することにより、後述するような各種処理を実現できる。

0035

<サービス提供システムが提供するサービス>
ここで、本実施形態に係るサービス提供システム10が提供するサービスについて説明する。なお、以降では、機器20が画像形成装置であるものとして説明する。

0036

本実施形態に係るサービス提供システム10は、機器20において原稿をスキャンして生成された電子ファイル(画像ファイル)をOCR処理して、ユーザにより指定されたメールアドレス宛にメール配信するサービスを提供する。

0037

以降では、本実施形態に係るサービス提供システム10は、上述したサービス(「スキャンToメール配信」サービス)を提供するものとして説明する。

0038

ただし、サービス提供システム10が提供するサービスは、これに限られない。サービス提供システム10は、例えば、機器20において原稿をスキャンして生成された電子ファイルを圧縮して、リポジトリへ格納するサービスを提供しても良い。また、サービス提供システム10は、例えば、機器20において原稿をスキャンして生成された電子ファイルを加工(例えば、当該電子ファイルに所定の文言を付加)して、ファクシミリ送信するサービスを提供しても良い。

0039

また、例えば、機器20が電子黒板等である場合には、本実施形態に係るサービス提供システム10は、電子黒板である機器20により生成された電子ファイルを加工して、メール配信するサービス等を提供しても良い。

0040

<機能構成>
次に、本実施形態に係る情報処理システム1の機能構成について、図4を参照しながら説明する。図4は、本実施形態に係る情報処理システム1の一例の機能構成を示す図である。

0041

図4に示す機器20は、例えばCPU31等により実行されるウェブブラウザ210(以降では、単に「ブラウザ210」と表す。)を有する。機器20のユーザは、ブラウザ210を用いて、サービス提供システム10が提供するサービスを利用することができる。

0042

このように、本実施形態に係る機器20には、ブラウザ210が搭載されていれば良い。したがって、本実施形態に係る機器20では、例えば、サービス提供システム10が提供するサービスを利用するための専用のアプリケーションプログラム等を搭載する必要がない。

0043

図4に示すサービス提供システム10は、入出力サービス処理部110と、Webサービス処理部120と、ドキュメントサービス部130とを有する。これら各機能部は、サービス提供システム10にインストールされた1以上のプログラムが、CPU16に実行させる処理により実現される。

0044

また、サービス提供システム10は、アプリ情報記憶部140と、画面情報記憶部150とを有する。これら各記憶部は、HDD18により実現可能である。なお、アプリ情報記憶部140及び画面情報記憶部150の少なくとも一方が、サービス提供システム10とネットワークを介して接続される記憶装置等により実現されていても良い。

0045

入出力サービス処理部110は、サービス提供システム10が提供するサービスに関する処理を行う。ここで、入出力サービス処理部110は、アプリ管理部111と、ロジック処理部112とを有する。

0046

アプリ管理部111は、アプリ情報記憶部140に記憶されているアプリ情報1000を管理する。なお、アプリ情報1000とは、一連の処理により実現されるサービスを提供するためのアプリケーションである。すなわち、サービス提供システム10が提供する各種のサービスは、アプリ情報1000により提供される。

0047

また、アプリ管理部111は、ロジック処理部112からの要求に応じて、アプリ情報1000に含まれる処理フロー情報1100を返信する。なお、処理フロー情報1100とは、アプリ情報1000により提供されるサービスを実現する一連の処理が定義された情報である。

0048

ロジック処理部112は、Webサービス処理部120からの要求に応じて、アプリ情報1000に含まれる処理フロー情報1100をアプリ管理部111から取得する。そして、ロジック処理部112は、アプリ管理部111から取得した処理フロー情報1100に基づいて、当該アプリ情報1000が提供するサービスを実現する一連の処理(処理フロー)を実行する。これにより、本実施形態に係るサービス提供システム10は、各種のサービスを提供することができる。なお、ロジック処理部112の詳細については後述する。

0049

Webサービス処理部120は、サービス提供システム10が提供するサービスを、ユーザがブラウザ210を用いて利用するための処理を行う。すなわち、Webサービス処理部120は、ブラウザ210に対してWebアプリケーション(アプリ情報1000)を提供するアプリケーションサーバとして機能する。ここで、Webサービス処理部120は、画面構成部121と、アプリ実行部122とを有する。

0050

画面構成部121は、ブラウザ210からの要求に応じて、画面情報記憶部150に記憶されている画面情報2000を返信する。なお、画面情報2000とは、アプリ情報1000により提供されるサービスを利用するための画面(アプリ画面)が定義された情報である。画面情報2000は、例えば、HTML(HyperText Markup Language)、XHTML(Extensible HyperText Markup Language)、CSS(Cascading Style Sheets)、JavaScript(登録商標)等のブラウザ210が解釈可能な形式でアプリ画面が定義されている。

0051

これにより、機器20の操作パネル22には、ブラウザ210により、サービス提供システム10が提供するサービスを利用するためのアプリ画面が表示される。

0052

アプリ実行部122は、ブラウザ210からの要求に応じて、入出力サービス処理部110に対して、アプリケーション(アプリ情報1000)の実行要求を送信する。

0053

ドキュメントサービス部130は、処理フロー情報1100に基づく一連の処理(処理フロー)に含まれる所定の処理を実行する。ここで、ドキュメントサービス部130は、OCR処理部131と、メール配信部132とを有する。

0054

OCR処理部131は、電子ファイル(画像ファイル)に対してOCR処理を行う。メール配信部132は、電子ファイルを添付したメールを作成して、当該メールを指定されたメールアドレス宛に配信する。

0055

なお、ドキュメントサービス部130は、例えば、電子ファイルのデータ形式を所定のデータ形式に変換するデータ変換部、電子ファイルを圧縮又は解凍する圧縮・解凍部等を有していても良い。

0056

このように、ドキュメントサービス部130には、一連の処理(処理フロー)に含まれる所定の処理を実行する種々の機能部が含まれる。したがって、ドキュメントサービス部130は、これら種々の機能を提供するプログラム(モジュール)群により実現される。

0057

アプリ情報記憶部140は、アプリ情報1000を記憶する。アプリ情報1000は、当該アプリ情報1000を識別するアプリIDと関連付けてアプリ情報記憶部140に記憶されている。なお、アプリ情報1000には、更に、当該アプリ情報1000のアプリケーション名(アプリ名)が関連付けられていても良い。

0058

ここで、アプリ情報1000には、処理フロー情報1100が含まれる。例えば、「スキャンToメール配信」サービスを提供するアプリ情報1000には、当該サービスを実現する一連の処理が定義された処理フロー情報1100が含まれる。すなわち、「スキャン To メール配信」サービスを提供するアプリ情報1000には、スキャンにより生成された電子ファイルをOCR処理した後、指定されたメールアドレス宛にメール配信する処理が定義された処理フロー情報1100が含まれる。

0059

なお、アプリ情報1000には、2以上の処理フロー情報1100が含まれていても良い。例えば、「スキャンToメール配信」を提供するアプリ情報1000には、英語でOCR処理した後、メール配信する処理が定義された処理フロー情報1100と、日本語でOCR処理した後、メール配信する処理が定義された処理フロー情報1100とが含まれていても良い。

0060

処理フロー情報1100は、上述したように、アプリ情報1000により提供されるサービスを実現する一連の処理(処理フロー)が定義された情報である。なお、処理フロー情報1100の詳細については後述する。

0061

画面情報記憶部150は、画面情報2000を記憶する。画面情報2000は、アプリIDと関連付けて画面情報記憶部150に記憶されている。なお、画面情報2000の詳細については後述する。

0062

なお、入出力サービス処理部110、Webサービス処理部120、ドキュメントサービス部130、アプリ情報記憶部140、及び画面情報記憶部150は、それぞれが異なる情報処理装置により実現されていても良い。特に、Webサービス処理部120及び画面情報記憶部150をアプリケーションサーバとして、一台の情報処理装置で実現しても良い。

0063

ここで、ロジック処理部112の詳細な機能構成について、図5を参照しながら説明する。図5は、本実施形態に係るロジック処理部112の一例の機能構成図である。

0064

図5に示すロジック処理部112は、フロー実行部301と、コンポーネント管理部302と、コンポーネント群303と、型変換管理部304と、型変換群305とを有する。また、ロジック処理部112は、型変換情報テーブル3000を有する。

0065

フロー実行部301は、アプリ実行部122からアプリケーションの実行要求を受信すると、当該実行要求に対応する処理フロー情報1100をアプリ管理部111から取得する。そして、フロー実行部301は、アプリ管理部111から取得した処理フロー情報1100に基づく一連の処理(処理フロー)を実行する。

0066

また、フロー実行部301は、一連の処理(処理フロー)でエラー等が発生した場合、当該一連の処理(処理フロー)の実行をリトライするか否かを判定する。そして、フロー実行部301は、当該一連の処理(処理フロー)をリトライすると判定した場合、当該一連の処理(処理フロー)の実行をリトライする(すなわち、フロー実行部301は、再度、当該一連の処理を実行する。)。

0067

ここで、処理フロー情報1100に基づく一連の処理は、当該一連の処理に含まれる各処理を実行するためのコンポーネントを組み合わせることにより実行される。なお、コンポーネントは、所定の機能を実現する処理を実行するためのプログラムやモジュール等により実現され、例えばクラスや関数等で定義される。

0068

コンポーネント管理部302は、コンポーネントを管理する。コンポーネント管理部302は、フロー実行部301からの要求に応じて、コンポーネントを生成すると共に、生成したコンポーネントをフロー実行部301に返信する。なお、コンポーネントの生成とは、例えばクラスや関数等で定義されたコンポーネントを、メモリ(例えばRAM14)上に展開することである。

0069

コンポーネント群303は、コンポーネントの集合である。コンポーネント群303には、OCRコンポーネント1310と、メール配信コンポーネント1320とが含まれる。

0070

OCRコンポーネント1310は、電子ファイルをOCR処理するためのコンポーネントである。OCRコンポーネント1310は、ドキュメントサービス部130のOCR処理部131にOCR処理を要求することにより、電子ファイルのOCR処理を行う。

0071

メール配信コンポーネント1320は、指定されたメールアドレス宛にメール配信するためのコンポーネントである。メール配信コンポーネント1320は、ドキュメントサービス部130のメール配信部132にメール配信処理を要求することにより、指定されたメールアドレス宛にメールを配信する。

0072

なお、コンポーネント群303には、上記のコンポーネント以外にも、例えば、電子ファイルのデータ形式を所定のデータ形式に変換するための変換コンポーネント、電子ファイルを圧縮するための圧縮コンポーネント等の各種のコンポーネントが含まれる。

0073

また、コンポーネント群303には、外部サービスを利用する各種のコンポーネントが含まれていても良い。すなわち、コンポーネント群303には、例えば、外部サービス(例えばクラウド型ストレージサービス等)を利用するためのコンポーネント、外部サービスから認証情報を取得するためのコンポーネント等の各種のコンポーネントが含まれていても良い。

0074

更に、コンポーネント群303に含まれる各コンポーネントは、コンポーネント共通I/F1300を有する。コンポーネント共通I/F1300は、各コンポーネントに対して共通に定義されたAPI(Application Programming Interface)であり、コンポーネントを生成するためのAPIと、コンポーネントの処理を実行するためのAPIとが含まれる。

0075

このように、各コンポーネントがコンポーネント共通I/F1300を有することで、コンポーネントの追加等に伴う影響を局所化することができる。すなわち、例えば、フロー実行部301やコンポーネント管理部302等に影響を与えることなく、コンポーネントの追加等を行うことができる。これにより、本実施形態に係るサービス提供システム10では、所定の機能の追加等(すなわち、当該機能を実現する処理を実行するためのコンポーネントの追加等)に伴う開発工数を削減することができる。

0076

型変換管理部304は、データ型の型変換を管理する。ここで、各コンポーネントは、自身が扱えるデータ型が予め決まっている。したがって、型変換管理部304は、コンポーネントからの要求に応じて、例えば図6に示す型変換情報テーブル3000を参照して、型変換群305に含まれる型変換を生成する。

0077

そして、型変換管理部304は、生成された型変換に型変換処理の実行を要求する。なお、型変換は、データ型の型変換処理を実行するプログラムやモジュール等により実現され、例えばクラスや関数等で定義される。また、型変換の生成とは、例えばクラスや関数等で定義された型変換を、メモリ(例えばRAM14上)に展開することである。

0078

なお、データ型には、例えば、ストリームデータを示すデータ型「InputStream」、記憶装置等に格納されている電子ファイルのパスアドレス)を示す「LocalFilePath」、及び電子ファイルの実体を示す「File」等が挙げられる。

0079

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

0080

図6に示す型変換情報テーブル3000は、データ項目として、変換前のデータ型と、変換後のデータ型と、生成する型変換とを有する。すなわち、型変換情報テーブル3000に格納されている型変換情報は、変換前のデータ型及び変換後のデータ型毎に、当該変換前のデータ型を、当該変換後のデータ型に変換するための型変換が関連付けられた情報である。

0081

型変換群305は、型変換の集合である。型変換群305には、データ型「InputStream」を「LocalFilePath」に変換するための第1の型変換1410が含まれる。なお、型変換群305には、これ以外にも、例えば、データ型「LocalFilePath」を「File」に変換するための第2の型変換等が含まれる。

0082

また、型変換群305に含まれる各型変換は、型変換共通I/F1400を有する。型変換共通I/F1400は、各型変換に対して共通に定義されたAPIであり、型変換を生成するためのAPIと、型変換の型変換処理を実行するためのAPIとが含まれる。

0083

このように、各型変換が型変換共通I/F1400を有することで、型変換の追加等に伴う影響を局所化することができる。すなわち、例えば、型変換管理部304等に影響を与えることなく、型変換の追加等を行うことができる。これにより、本実施形態に係るサービス提供システム10では、型変換の追加等に伴う開発工数を削減することができる。

0084

ここで、「スキャンToメール配信」サービスを提供するアプリ情報1000に含まれる処理フロー情報1100について、図7を参照しながら説明する。図7は、「スキャン To メール配信」サービスを実現する一連の処理が定義された処理フロー情報1100の一例を示す図である。

0085

図7に示す処理フロー情報1100は、「スキャンToメール配信」サービスを実現する一連の処理(処理フロー)が定義された情報である。

0086

図7に示す処理フロー情報1100には、当該処理フロー情報1100を識別するフローID1101と、当該処理フロー情報1100に基づく一連の処理(処理フロー)の名称を示すフロー名1102とが含まれる。また、図7に示す処理フロー情報1100には、一連の処理(処理フロー)に含まれる各処理の処理内容が定義されたフロー詳細1103が含まれる。

0087

フロー詳細1103には、処理フローに含まれる各処理をそれぞれ定義した処理定義1104と、処理定義1105とが含まれる。また、処理定義1104及び処理定義1105には、処理を実行するコンポーネントのコンポーネント名を示す「"component"」と、当該コンポーネントに対するパラメータ情報が定義される「"parameters"」とが含まれる。

0088

具体的には、処理定義1104の「"component"」には、OCRコンポーネント1310のコンポーネント名「"ocr"」が定義されている。また、処理定義1104の「"parameters"」には、パラメータ名「"language"」のパラメータ情報と、パラメータ名「"outputType"」のパラメータ情報とが定義されている。

0089

更に、パラメータ名「"language"」のパラメータ情報には、OCR処理の言語が英語である事を示す「"English"」がパラメータ値として定義されている。同様に、パラメータ名「"outputType"」のパラメータ情報には、OCR処理後ファイル形式PDF形式であることを示す「"pdf"」がパラメータ値として定義されている。

0090

同様に、処理定義1105の「"component"」には、メール配信コンポーネント1320のコンポーネント名「"mail"」が定義されている。また、処理定義1105の「"parameters"」には、パラメータ名「"from"」のパラメータ情報と、パラメータ名「"to"」のパラメータ情報と、パラメータ名「"filename"」のパラメータ情報とが定義されている。

0091

更に、パラメータ名「"from"」のパラメータ情報には、送信元メールアドレスを示す「"hoge@huga.com"」がパラメータ値として定義されている。同様に、パラメータ名「"to"」のパラメータ情報には、送信先メールアドレスが設定されていないことを示す「null」がパラメータ値として定義されている。また、同様に、パラメータ名「"filename"」のパラメータ情報には、メールに添付するファイル添付ファイル)のファイル名が設定されていないことを示す「null」がパラメータ値として定義されている。

0092

このように、処理フロー情報1100には、一連の処理(処理フロー)を構成する各処理の処理定義が定義されている。これにより、本実施形態に係るサービス提供システム10は、処理フロー情報1100に含まれる各処理定義に従って、各コンポーネントによる処理を行うことで、アプリ情報1000により提供されるサービスを実現する一連の処理を実行することができる。

0093

なお、図7に示す処理フロー情報1100に含まれる各処理定義に定義された処理は、上から順に実行される。すなわち、図7に示す処理フロー情報1100に基づく一連の処理では、処理定義1104に定義された処理、処理定義1105に定義された処理の順で実行される。ただし、これに限られず、処理フロー情報1100には、例えば、各処理定義に定義された処理の実行順を示す情報が定義されていても良い
<処理の詳細>
次に、本実施形態に係る情報処理システム1の処理の詳細について説明する。以降では、機器20のユーザが、「スキャンToメール配信」サービスを利用する場合の全体的な処理について、図8を参照しながら説明する。図8は、本実施形態に係る「スキャン To メール配信」サービスの全体処理の一例を示すシーケンス図である。

0094

まず、機器20のブラウザ210は、「スキャンToメール配信」サービスのアプリ画面を表示させるための操作(表示操作)を受け付ける(ステップS801)。

0095

機器20のブラウザ210は、当該表示操作を受け付けると、「スキャンToメール配信」サービスのアプリ画面を表示するための画面情報の取得要求を、Webサービス処理部120の画面構成部121に送信する(ステップS802)。なお、当該取得要求は、例えば、HTTP(Hypertext Transfer Protocol)リクエストであり、「スキャン To メール配信」サービスを提供するアプリ情報1000のURL(Uniform Resource Locator)が指定される。このとき、当該取得要求には、「スキャン To メール配信」サービスを提供するアプリ情報1000のアプリIDが含まれていても良い。

0096

Webサービス処理部120の画面構成部121は、画面情報の取得要求を受信すると、当該取得要求に指定されているURLに対応するアプリIDと関連付けられている画面情報2000を画面情報記憶部150から取得する(ステップS803)。そして、Webサービス処理部120の画面構成部121は、画面情報記憶部150から取得した画面情報2000をブラウザ210に返信する。すなわち、画面構成部121は、画面情報記憶部150から取得した画面情報2000を含むHTTPレスポンスをブラウザ210に返信する。なお、このとき、画面構成部121は、当該URLに対応するアプリIDもブラウザ210に返信する。

0097

ここで、「スキャンToメール配信」サービスのアプリ画面を表示するための画面情報2000について、図9を参照しながら説明する。図9は、「スキャン To メール配信」サービスのアプリ画面を表示するための画面情報2000の一例を示す図である。

0098

図9に示す画面情報2000は、HTML形式で定義された情報であり、見出し定義2001と、ファイル名入力欄定義2002と、送信先メールアドレス入力欄定義2003と、上限リトライ回数入力欄定義2004と、スキャン実行ボタン定義2005とが含まれる。このように、画面情報2000は、HTMLタグ等のブラウザ210が解釈可能な形式によりアプリ画面が定義されている。これにより、ブラウザ210は、図9に示す画面情報2000に基づいて、後述するアプリ画面2100を表示することができる。

0099

次に、機器20のブラウザ210は、画面構成部121から画面情報2000を受信すると、当該画面情報2000に基づいて、例えば図10に示すアプリ画面2100を表示する(ステップS804)。

0100

図10に示すアプリ画面2100は、図9に示す画面情報2000に基づいて、ブラウザ210により表示された画面である。図10に示すアプリ画面2100には、タイトル2101と、ファイル名入力欄2102と、送信先メールアドレス入力欄2103と、上限リトライ回数入力欄2104と、スキャン実行ボタン2105とが含まれる。

0101

ここで、タイトル2101は、例えば、「スキャンToメール配信」サービスを提供するアプリ情報1000のアプリ名である。ファイル名入力欄2102は、メールに添付する電子ファイル(すなわち、スキャンにより生成された電子ファイルをOCR処理した電子ファイル)のファイル名をユーザが指定する入力エリアである。また、送信先メールアドレス入力欄2103は、メールの配信先となるメールアドレスをユーザが指定する入力エリアである。更に、上限リトライ回数入力欄2104は、一連の処理(処理フロー)でエラー等が発生した場合に、当該一連の処理(処理フロー)の実行をリトライする回数の上限(上限リトライ回数)をユーザが指定する入力エリアである。

0102

なお、タイトル2101及びファイル名入力欄2102は、見出し定義2001及びファイル名入力欄定義2002をブラウザ210がそれぞれ解釈することにより表示される。また、同様に、送信先メールアドレス入力欄2103及び上限リトライ回数入力欄2104は、送信先メールアドレス入力欄定義2003及び上限リトライ回数入力欄定義2004をブラウザ210がそれぞれ解釈することにより表示される。更に、スキャン実行ボタン2105は、スキャン実行ボタン定義2005をブラウザ210が解釈することにより表示される。

0103

このように、本実施形態に係るサービス提供システム10は、機器20のブラウザ210からの要求に応じて、HTML形式等のブラウザ210が解釈可能な形式で定義された画面情報2000を返信する。そして、機器20は、サービス提供システム10から返信された画面情報2000に基づいて、サービスを利用するためのアプリ画面2100を表示する。したがって、ユーザは、一般的なブラウザ210が搭載された機器20を用いて、サービス提供システム10が提供するサービスを利用することができる。

0104

なお、上記のステップS803において、画面構成部121は、画面情報記憶部150から画面情報2000を取得するものとしたが、これに限られない。画面構成部121は、例えば、アプリ情報1000に基づいて、画面情報2000を生成しても良い。

0105

すなわち、画面構成部121は、例えば、アプリ管理部111を介して、画面情報の取得要求に含まれるアプリIDに関連付けられているアプリ情報1000をアプリ情報記憶部140から取得する。そして、画面構成部121は、アプリ情報1000に含まれる情報(例えば、アプリ名、処理フロー情報1100に定義されているパラメータ情報等)を、予め記憶されている画面情報の雛形に対して定義することで、画面情報2000を生成しても良い。

0106

ここで、図10に示すアプリ画面2100において、ユーザにより、ファイル名入力欄2102、送信先メールアドレス入力欄2103、及び上限リトライ回数入力欄2104にそれぞれファイル名、メールアドレス、及び上限リトライ回数が指定されたものとする。そして、図10に示すアプリ画面2100において、ユーザにより、スキャン実行ボタン2105が押下され、スキャン実行操作がなされたものとする。

0107

すると、機器20のブラウザ210は、ユーザ指定情報及びスキャン実行操作を受け付ける(ステップS805)。なお、ユーザ指定情報とは、ファイル名入力欄2102、送信先メールアドレス入力欄2103、及び上限リトライ回数入力欄2104にそれぞれ指定されたファイル名、メールアドレス、及び上限リトライ回数である。

0108

例えば、ファイル名入力欄2102に「test.pdf」、送信先メールアドレス入力欄2103に「hoge@hogehoge.co.jp」、上限リトライ回数入力欄2104に「3」が指定されたとする。この場合、ユーザ指定情報には、例えば、「"to":"hoge@hogehoge.co.jp"」と、「"filename":"test.pdf"」と、「"retry":"3"」とが含まれる。

0109

次に、機器20のブラウザ210は、スキャン実行操作を受け付けると、スキャナ26により原稿を読み取って、電子ファイル(画像ファイル)を生成する(ステップS806)。

0110

次に、機器20のブラウザ210は、電子ファイルが生成されると、アプリケーションの実行要求を、Webサービス処理部120のアプリ実行部122に送信する(ステップS807)。

0111

なお、当該実行要求は、例えば、HTTPリクエストであり、「スキャンToメール配信」サービスを実現する一連の処理が定義された処理フロー情報1100のフローIDと、上記のステップS806で生成された電子ファイルと、ユーザ指定情報とが含まれる。

0112

ただし、アプリケーションの実行要求には、フローIDに代えて、例えば、アプリ情報1000のURL、上記のステップS804で表示したアプリ画面2100の画面ID、スキャン実行ボタン2105のボタンID等が含まれていても良い。すなわち、アプリケーションの実行要求には、フローIDに代えて、後述するステップS808でフローIDに変換することができる種々の識別情報が含まれていても良い。

0113

Webサービス処理部120のアプリ実行部122は、アプリケーションの実行要求を受信すると、当該要求を、入出力サービス処理部110のロジック処理部112に送信する(ステップS808)。なお、アプリ実行部122は、例えば、アプリ情報1000のURL、アプリ画面2100の画面ID、スキャン実行ボタン2105のボタンID等がアプリケーションの実行要求に含まれている場合には、これらの識別情報をフローIDに変換する。

0114

次に、入出力サービス処理部110のロジック処理部112は、アプリケーションの実行要求を受信すると、フロー実行部301により、処理フロー情報の取得要求をアプリ管理部111に送信する(ステップS809)。なお、当該取得要求には、フローIDが含まれる。

0115

アプリ管理部111は、処理フロー情報の取得要求を受信すると、当該取得要求に含まれるフローIDにより識別される処理フロー情報1100をアプリ情報記憶部140から取得する(ステップS810)。

0116

そして、アプリ管理部111は、アプリ情報記憶部140から取得した処理フロー情報1100をロジック処理部112に返信する。ここで、以降では、アプリ管理部111は、図7に示す処理フロー情報1100をロジック処理部112に返信したものとして説明する。

0117

次に、ロジック処理部112は、アプリ管理部111から処理フロー情報1100を受信すると、当該処理フロー情報1100に基づく処理フローの実行処理を行う(ステップS811)。すなわち、ロジック処理部112は、「スキャンToメール配信」サービスを実現する一連の処理(処理フロー)の実行処理を行う。なお、処理フローの実行処理の詳細については後述する。

0118

そして、ロジック処理部112は、処理フローの実行処理の処理結果を、Webサービス処理部120を介して、ブラウザ210に返信する。これにより、本実施形態に係るサービス提供システム10は、処理フロー情報1100に基づく一連の処理(処理フロー)により実現される各種のサービス(例えば、「スキャンToメール配信」サービス)を提供することができる。

0119

なお、図8に示す「スキャンToメール配信」サービスの全体処理では、ブラウザ210は、Webサービス処理部120を介して、アプリケーションの実行要求をロジック処理部112に送信しているが、これに限られない。ブラウザ210は、例えば、画面情報2000に定義されたJavaScript等に基づいてWebAPIを呼び出すことにより、Webサービス処理部120を介さずに、直接、アプリケーションの実行要求をロジック処理部112に送信しても良い。

0120

ここで、以降では、「スキャンToメール配信」サービスを実現する処理フローの実行処理(図8のステップS811の処理)の詳細について説明する。

0121

まず、「スキャンToメール配信」サービスを実現する処理フローが正常に終了に場合について、図11を参照しながら説明する。図11は、本実施形態に係る処理フローの実行処理の一例を示すシーケンス図である。

0122

まず、フロー実行部301は、図8のステップS809でアプリ管理部111から返信された処理フロー情報1100に基づいて、コンポーネントの取得要求をコンポーネント管理部302に送信する(ステップS1101)。すなわち、フロー実行部301は、図7に示す処理フロー情報1100の処理定義1104の「"component"」に定義されている「"ocr"」を含むコンポーネントの取得要求をコンポーネント管理部302に送信する。

0123

コンポーネント管理部302は、コンポーネントの取得要求を受信すると、当該取得要求に含まれる「"ocr"」に対応するOCRコンポーネント1310を生成する(ステップS1102)。なお、OCRコンポーネント1310の生成は、コンポーネント共通I/F1300を用いて行うことができる。

0124

そして、コンポーネント管理部302は、生成したOCRコンポーネント1310をフロー実行部301に返信する。すなわち、コンポーネント管理部302は、例えば、OCRコンポーネント1310が展開されたメモリ(例えばRAM14)上のアドレスをフロー実行部301に返信する。

0125

フロー実行部301は、OCRコンポーネント1310が返信されると、コンポーネントの処理実行要求を、当該OCRコンポーネント1310に送信する(ステップS1103)。なお、コンポーネントの処理実行要求には、データと、パラメータ情報とが含まれる。

0126

ここで、上記のステップS1103において、データとは、データ型「InputStream」として、アプリ実行部122から受信した電子ファイル(アプリケーションの実行要求に含まれる電子ファイル)である。すなわち、フロー実行部301は、アプリ実行部122から受信した電子ファイルを、単に「データ」として(データ型を意識することなく)、OCRコンポーネント1310に送信する。以降では、このようにデータ型を意識しない電子ファイル等を、単に「データ」と表す。

0127

また、上記のステップS1103において、パラメータ情報とは、図7に示す処理フロー情報1100の処理定義1104の「"parameters"」に定義されている各パラメータ情報である。すなわち、上記のステップS1103におけるコンポーネントの処理実行要求には、パラメータ情報「"language":"English"」と、パラメータ情報「"outputType":"pdf"」とが含まれる。

0128

OCRコンポーネント1310は、コンポーネントの処理実行要求を受信すると、型変換要求を型変換管理部304に送信する(ステップS1104)。なお、当該型変換要求には、データと、OCRコンポーネント1310が扱うことができるデータ型を示す「LocalFilePath」の指定とが含まれる。

0129

型変換管理部304は、型変換要求を受信すると、当該型変換要求に含まれるデータのデータ型と、指定されたデータ型とが一致するか否かをチェックする(ステップS1105)。

0130

ここで、型変換要求に含まれるデータのデータ型は「InputStream」である一方、指定されたデータ型は「LocalFilePath」である。したがって、型変換管理部304は、型変換要求に含まれるデータのデータ型と、指定されたデータ型とが一致しないものと判断する。

0131

すると、型変換管理部304は、図6に示す型変換情報テーブル3000を参照して、データ型「InputStream」を「LocalFilePath」に変換するための型変換を特定する(ここでは、第1の型変換1410が特定される。)。そして、型変換管理部304は、特定した第1の型変換1410を生成する(ステップS1106)。なお、第1の型変換1410の生成は、型変換共通I/F1400を用いて行うことができる。

0132

次に、型変換管理部304は、型変換処理の実行要求を第1の型変換1410に送信する(ステップS1107)。なお、当該実行要求には、データが含まれる。

0133

第1の型変換1410は、型変換の実行要求を受信すると、当該実行要求に含まれるデータのデータ型を「InputStream」から「LocalFilePath」に変換する型変換処理を行う(ステップS1108)。そして、第1の型変換1410は、データ型が変換されたデータを型変換管理部304に返信する。その後、型変換管理部304は、第1の型変換1410からデータを受信すると、当該データをOCRコンポーネント1310に送信する。

0134

OCRコンポーネント1310は、型変換管理部304からデータを受信すると、パラメータ情報を用いて、当該データに対して処理を実行する(ステップS1109)。

0135

すなわち、OCRコンポーネント1310は、ドキュメントサービス部130のOCR処理部131により、当該データ(データ型「LocalFilePath」)により示される電子ファイルに対してOCR処理を行う。このとき、OCRコンポーネント1310は、OCR言語を「英語」として、当該電子ファイルに対してOCR処理を行った上で、OCR処理後の電子ファイルのデータ形式を「PDF」とする。

0136

そして、OCRコンポーネント1310は、処理結果を示すデータをフロー実行部301に返信する。なお、ここで返信されるデータは、OCRコンポーネント1310によりOCR処理された電子ファイルを示すデータ(データ型「LocalFilePath」)である。

0137

次に、フロー実行部301は、図8のステップS809でアプリ管理部111から返信された処理フロー情報1100に基づいて、コンポーネントの取得要求をコンポーネント管理部302に送信する(ステップS1110)。すなわち、フロー実行部301は、図7に示す処理フロー情報1100の処理定義1105の「"component"」に定義されている「"mail"」を含むコンポーネントの取得要求をコンポーネント管理部302に送信する。

0138

コンポーネント管理部302は、コンポーネントの取得要求を受信すると、当該取得要求に含まれる「"mail"」に対応するメール配信コンポーネント1320を生成する(ステップS1111)。なお、メール配信コンポーネント1320の生成は、コンポーネント共通I/F1300を用いて行うことができる。

0139

そして、コンポーネント管理部302は、生成したメール配信コンポーネント1320をフロー実行部301に返信する。すなわち、コンポーネント管理部302は、例えば、メール配信コンポーネント1320が展開されたメモリ(例えばRAM14)上のアドレスをフロー実行部301に返信する。

0140

フロー実行部301は、メール配信コンポーネント1320が返信されると、コンポーネントの処理実行要求を、当該メール配信コンポーネント1320に送信する(ステップS1112)。なお、コンポーネントの処理実行要求には、データと、パラメータ情報とが含まれる。

0141

ここで、上記のステップS1112において、データとは、OCRコンポーネント1310から返信されたデータ(すなわち、OCR処理された電子ファイルを示すデータ(データ型「LocalFilePath」))である。

0142

また、上記のステップS1112において、パラメータ情報とは、図7に示す処理フロー情報1100の処理定義1105の「"parameters"」に定義されている各パラメータ情報である。

0143

すなわち、上記のステップS1112におけるコンポーネントの処理実行要求には、パラメータ情報「"from":"hoge@huga.com"」と、パラメータ情報「"to";null」と、パラメータ情報「"filename";null」とが含まれる。また、上記のステップS1112におけるコンポーネントの処理実行要求には、アプリ実行部122から受信したユーザ指定情報「"to":"hoge@hogehoge.co.jp"」と、ユーザ指定情報「"filename":"test.pdf"」とが含まれる。

0144

メール配信コンポーネント1320は、コンポーネントの処理実行要求を受信すると、型変換要求を型変換管理部304に送信する(ステップS1113)。なお、当該型変換要求には、データと、メール配信コンポーネント1320が扱うことができるデータ型を示す「LocalFilePath」の指定とが含まれる。

0145

型変換管理部304は、型変換要求を受信すると、当該型変換要求に含まれるデータのデータ型と、指定されたデータ型とが一致するか否かをチェックする(ステップS1114)。

0146

ここで、型変換要求に含まれるデータのデータ型は「LocalFilePath」であり、指定されたデータ型も「LocalFilePath」である。したがって、型変換管理部304は、型変換要求に含まれるデータのデータ型と、指定されたデータ型とが一致するものと判断する。

0147

すると、型変換管理部304は、型変換要求に含まれるデータをメール配信コンポーネント1320に返信する。このように、データ型のチェック(ステップS1114の処理)において、データのデータ型と、指定されたデータ型とが一致すると判断された場合には、型変換管理部304は、型変換の生成を行わない。

0148

メール配信コンポーネント1320は、型変換管理部304からデータを受信すると、パラメータ情報を用いて、当該データに対して処理を実行する(ステップS1115)。すなわち、メール配信コンポーネント1320は、ドキュメントサービス部130のメール配信部132により、パラメータ情報を用いて、当該データにより示される電子ファイルを添付したメールを配信する。

0149

より具体的には、メール配信コンポーネント1320は、まず、パラメータ情報にユーザ指定情報を定義して、「"to":"hoge@hogehoge.co.jp"」及び「"filename":"test.pdf"」とする。次に、メール配信コンポーネント1320は、メール配信部132により、送信元メールアドレスが「hoge@huga.com」であり、当該データにより示される電子ファイルのファイル名を「test.pdf」とした電子ファイルを添付したメールを作成する。最後に、メール配信コンポーネント1320は、メール配信部132により、作成したメールを「hoge@hogehoge.co.jp」宛に配信(送信)する。

0150

そして、メール配信コンポーネント1320は、処理結果を示すデータをフロー実行部301に返信する。なお、ここで返信されるデータは、例えば、メール配信コンポーネント1320により正常にメールが配信されたことを示す情報等である。

0151

以上のように、本実施形態に係るサービス提供システム10は、処理フロー情報1100に基づいて、各コンポーネントによる処理をそれぞれ行うことで、一連の処理(処理フロー)を実行する。これにより、本実施形態に係るサービス提供システム10は、当該一連の処理により実現される各種のサービスを提供することができる。

0152

次に、「スキャンToメール配信」サービスを実現する処理フローでエラー等が発生する場合について、図12を参照しながら説明する。図12は、本実施形態に係る処理フローの実行処理の他の例を示すシーケンス図である。以降では、OCRコンポーネント1310によるOCR処理でエラー等が発生する場合について説明する。なお、図12のステップS1101〜ステップS1108の処理は、図11のステップS1101〜ステップS1108の処理と同様であるため、その説明を省略する。

0153

ステップS1108に続いて、OCRコンポーネント1310は、型変換管理部304からデータを受信すると、パラメータ情報を用いて、当該データに対して処理を実行する(ステップS1201)。ここで、本ステップの処理の実行中に、例えば、一時的なメモリ不足等により、エラーが発生したものとする。

0154

この場合、OCRコンポーネント1310は、処理結果としてエラー情報をフロー実行部301に返信する。

0155

フロー実行部301は、エラー情報を受信すると、アプリ実行部122から受信した上限リトライ回数と、処理フロー情報1100に基づく一連の処理の実行をリトライした回数(リトライ回数)とに基づいて、リトライ可否を判定する(ステップS1202)。すなわち、フロー実行部301は、図7に示す処理フロー情報1100に基づく一連の処理(処理フロー)のリトライ回数が、上限リトライ回数に達しているか否かを判定する。

0156

フロー実行部301は、図7に示す処理フロー情報1100に基づく一連の処理(処理フロー)のリトライ回数が、上限リトライ回数に達していない場合、リトライ回数に「1」を加算する(ステップS1203)。

0157

そして、ステップS1203に続いて、フロー実行部301は、再度、図7に示す処理フロー情報1100に基づく一連の処理(処理フロー)の実行処理を行う(ステップS811)。すなわち、フロー実行部301は、図7に示す処理フロー情報1100に基づく一連の処理(処理フロー)の実行をリトライする。

0158

なお、フロー実行部301は、図7に示す処理フロー情報1100に基づく一連の処理(処理フロー)の実行をリトライする場合には、既に生成されているコンポーネント(すなわち、この場合、OCRコンポーネント1310)の生成は行わなくても良い。

0159

このように、本実施形態に係るサービス提供システム10は、サービスを実現する一連の処理でエラー等が発生した場合、当該一連の処理の実行をリトライする。これにより、本実施形態に係るサービス提供システム10では、例えば、一時的なメモリ不足やネットワークの一時的な瞬断等によるエラー等が発生した場合であっても、自動的に一連の処理(処理フロー)を再実行することができる。

0160

したがって、本実施形態に係る情報処理システム1によれば、機器20のユーザは、一連の処理(処理フロー)で上記のようなエラー等が発生した場合には、当該一連の処理の実行操作を再度行う必要がない。

0161

一方で、フロー実行部301は、図7に示す処理フロー情報1100に基づく一連の処理(処理フロー)のリトライ回数が、上限リトライ回数に達している場合、処理を終了する。

0162

ここで、図12のステップS1202において、フロー実行部301は、アプリ実行部122から受信した上限リトライ回数(すなわち、ユーザにより指定された上限リトライ回数)と、リトライ回数とに基づいて、リトライ可否を判定したが、これに限られない。上限リトライ回数は、例えば、処理フロー情報1100に定義されていても良い。

0163

すなわち、例えば、図13に示すように、処理フロー情報1100には、上限リトライ回数定義1301が定義されていても良い。

0164

この場合、上記のステップS1202において、フロー実行部301は、処理フロー情報1100の上限リトライ回数定義1301に定義されている上限リトライ回数と、リトライ回数とに基づいて、リトライ可否を判定しても良い。これにより、ユーザは、例えば図10に示すアプリ画面2100において、上限リトライ回数を指定してなくても良くなる。

0165

[第二の実施形態]
次に、第二の実施形態について説明する。第二の実施形態は、一連の処理(処理フロー)で発生したエラーを識別するエラーコードに基づいて、リトライ可否を判定するものである。これにより、第二の実施形態では、一連の処理(処理フロー)で発生したエラーに応じて、リトライ可否を判定することができるようになる。

0166

なお、第二の実施形態の説明では、主に、第一の実施形態との相違点について説明し、第一の実施形態と実質的に同様の機能構成を有する箇所及び実質的に同様の処理を実行する箇所は、適宜、その説明を省略する。

0167

<機能構成>
まず、本実施形態に係るサービス提供システム10のロジック処理部112の機能構成について、図14を参照しながら説明する。図14は、本実施形態に係るロジック処理部112の一例の機能構成を示す図である。

0168

本実施形態に係るロジック処理部112は、エラーコード情報テーブル4000を有する点が第一の実施形態と異なる。

0169

ここで、エラーコード情報テーブル4000について、図15を参照しながら説明する。図15は、エラーコード情報テーブル4000の一例を示す図である。

0170

図15に示すエラーコード情報テーブル4000は、データ項目として、エラーコードと、エラー内容と、リトライ可否とを有する。エラーコードは、コンポーネントで発生したエラーを識別する識別情報である。エラー内容は、エラーコードにより識別されるエラーの内容である。リトライ可否は、エラーコードにより識別されるエラーが発生した場合に、一連の処理(処理フロー)をリトライさせるか否かを示す情報である。

0171

例えば、エラーコード「invalid_input_parameter」により識別されるエラーは、エラー内容「入力されたパラメータ情報が不正」、リトライ可否「false」である。このため、フロー実行部301は、エラーコード「invalid_input_parameter」により識別されるエラーがコンポーネントで発生した場合、一連の処理の実行をリトライしない。

0172

一方で、例えば、エラーコード「network_timeout」により識別されるエラーは、エラー内容「外部サービスへの接続がタイムアウトした」、リトライ可否「true」である。このため、フロー実行部301は、エラーコード「network_timeout」により識別されるエラーがコンポーネントで発生した場合、一連の処理の実行をリトライする。

0173

このように、本実施形態に係るサービス提供システム10は、一連の処理でエラー等が発生した場合に、エラーコード情報テーブル4000を参照することで、当該一連の処理のリトライ可否を判定する。

0174

<処理の詳細>
次に、「スキャンToメール配信」サービスを実現する処理フローでエラー等が発生する場合について、図16を参照しながら説明する。図16は、本実施形態に係る処理フローの実行処理の一例を示すシーケンス図である。以降では、OCRコンポーネント1310によるOCR処理でエラー等が発生する場合について説明する。なお、図16のステップS1101〜ステップS1108及びステップS1201の処理は、図12のステップS1101〜ステップS1108及びステップS1201の処理と同様であるため、その説明を省略する。

0175

ステップS1201に続いて、フロー実行部301は、エラー情報を受信すると、図15に示すエラーコード情報テーブル4000を参照して、処理フロー情報1100に基づく一連の処理のリトライ可否を判定する(ステップS1601)。

0176

ここで、フロー実行部301は、例えば図17に示すようなエラー情報をOCRコンポーネント1310から受信する。図17は、エラー情報の一例を示す図である。

0177

図17に示すエラー情報には、エラーコードを示す「"errorCode"」と、発生したエラーのオプション情報を示す「"option"」と、エラーの発生原因を示す「"cause"」と、エラーの発生時刻を示す「"timestamp"」とが含まれる。

0178

したがって、フロー実行部301は、エラーコード情報テーブル4000において、受信したエラー情報に含まれる「"errorCode"」の値に対応するリトライ可否の値を参照することで、処理フロー情報1100に基づく一連の処理のリトライ可否を判定する。

0179

このように、本実施形態に係るサービス提供システム10は、サービスを実現する一連の処理でエラー等が発生した場合、コンポーネントから返信されたエラー情報に含まれるエラーコードからリトライ可否を判定することができる。したがって、本実施形態に係るサービス提供システム10によれば、一連の処理で発生したエラーに応じて、当該一連の処理の実行をリトライするか否かを判定することができるようになる。

0180

なお、上記のステップS1601において、フロー実行部301は、上限リトライ回数に基づいてリトライ可否を判定(図12のステップS1202の処理)した上で、エラーコードからリトライ可否を判定しても良い。すなわち、フロー実行部301は、例えば、リトライ回数が上限リトライ回数に達していない場合に、上記のステップS1601の判定を行うようにしても良い。

0181

ここで、図16のステップS1601において、フロー実行部301は、図15に示すエラーコード情報テーブル4000を参照して、処理フロー情報1100に基づく一連の処理のリトライ可否を判定した。しかし、「リトライ可」と判定された場合であっても、コンポーネントの処理に用いるパラメータ情報の更新が必要となる場合がある。

0182

例えば、外部サービスの認証情報を示すパラメータ情報がコンポーネントの処理に必要である場合において、当該認証情報の有効期限切れによりエラーが発生した場合である。このような場合、フロー実行部301は、当該パラメータ情報の更新をコンポーネントに要求した上で、一連の処理の実行をリトライする必要がある。

0183

そこで、フロー実行部301は、上記のステップS1601において、図18に示すエラーコード情報テーブル4000Aを参照して、処理フロー情報1100に基づく一連の処理のリトライ可否を判定しても良い。

0184

図18に示すエラーコード情報テーブル4000Aは、データ項目として、更に、パラメータ情報更新要否と、対象パラメータ情報とを有する。

0185

これにより、フロー実行部301は、上記のステップS1601において、「リトライ可」と判定した場合において、該当のパラメータ情報更新要否が「true」である場合には、対象パラメータ情報の更新をコンポーネントに要求する。そして、フロー実行部301は、対象パラメータ情報の更新が完了した場合に、一連の処理(処理フロー)の実行をリトライする。

0186

例えば、フロー実行部301は、エラーコードが「auth_ticket_expired」である場合、対象パラメータ情報「ticket」(すなわち、パラメータ名が「ticket」のパラメータ情報)の更新をコンポーネントに要求する。そして、フロー実行部301は、対象パラメータ情報「ticket」の更新が完了した場合に、一連の処理(処理フロー)の実行をリトライする。

0187

[第三の実施形態]
次に、第三の実施形態について説明する。第三の実施形態は、一連の処理(処理フロー)の進捗状況に基づいて、リトライ可否を判定するものである。

0188

なお、第三の実施形態の説明では、主に、第一の実施形態との相違点について説明し、第一の実施形態と実質的に同様の機能構成を有する箇所及び実質的に同様の処理を実行する箇所は、適宜、その説明を省略する。

0189

<機能構成>
まず、本実施形態に係るサービス提供システム10のロジック処理部112の機能構成について、図19を参照しながら説明する。図19は、本実施形態に係るロジック処理部112の一例の機能構成を示す図である。

0190

本実施形態に係るロジック処理部112は、フロー進捗情報テーブル5000を有する点が第一の実施形態と異なる。

0191

ここで、フロー進捗情報テーブル5000について、図20を参照しながら説明する。図20は、フロー進捗情報テーブル5000の一例を示す図である。

0192

図20に示すフロー進捗情報テーブル5000は、データ項目として、フローIDと、コンポーネント名と、リトライ可否とを有する。フローIDは、処理フロー情報1100を識別する識別情報である。コンポーネント名は、コンポーネントを識別する識別情報である。リトライ可否は、フローIDで識別される処理フロー情報1100に基づく一連の処理において、当該フローIDに対応付けられたコンポーネントの処理でエラーが発生した場合に、当該一連の処理をリトライさせるか否かを示す情報である。

0193

例えば、フローID「flow001」には、コンポーネント名「ocr」と、リトライ可否「true」とが対応付けられている。このため、フロー実行部301は、フローID「flow001」で識別される処理フロー情報1100に基づく一連の処理において、OCRコンポーネント1310の処理でエラーが発生した場合には、当該一連の処理の実行をリトライする。

0194

一方で、例えば、フローID「flow001」には、コンポーネント名「mail」と、リトライ可否「false」とが対応付けられている。このため、フロー実行部301は、フローID「flow001」で識別される処理フロー情報1100に基づく一連の処理において、メール配信コンポーネント1320の処理でエラーが発生した場合には、当該一連の処理の実行をリトライしない。

0195

このように、本実施形態に係るサービス提供システム10は、一連の処理でエラー等が発生した場合に、フロー進捗情報テーブル5000を参照することで、当該一連の処理のリトライ可否を判定する。

0196

<処理の詳細>
次に、「スキャンToメール配信」サービスを実現する処理フローでエラー等が発生する場合について、図21を参照しながら説明する。図21は、本実施形態に係る処理フローの実行処理の一例を示すシーケンス図である。以降では、OCRコンポーネント1310によるOCR処理でエラー等が発生する場合について説明する。なお、図21のステップS1101〜ステップS1108及びステップS1201の処理は、図12のステップS1101〜ステップS1108及びステップS1201の処理と同様であるため、その説明を省略する。

0197

ステップS1201に続いて、フロー実行部301は、エラー情報を受信すると、図20に示すフロー進捗情報テーブル5000を参照して、処理フロー情報1100に基づく一連の処理のリトライ可否を判定する(ステップS2101)。すなわち、フロー実行部301は、フロー進捗情報テーブル5000において、当該処理フロー情報1100のフローIDと、エラー情報の送信元のコンポーネントのコンポーネント名とに対応するリトライ可否の値を参照する。そして、フロー実行部301は、当該値(ture又はfalse)に応じて、当該処理フロー情報1100に基づく一連の処理のリトライ可否を判定する。

0198

このように、本実施形態に係るサービス提供システム10は、サービスを実現する一連の処理でエラー等が発生した場合、当該一連の処理が定義された処理フロー情報1100のフローIDと、エラー情報の送信元のコンポーネントのコンポーネント名とからリトライ可否を判定することができる。したがって、本実施形態に係るサービス提供システム10によれば、一連の処理(処理フロー)の進捗状況(どこまで処理が進んでいるか)に応じて、リトライ可否を判定することができる。

0199

<まとめ>
以上のように、第一の実施形態に係る情報処理システム1では、各種のサービスを実現する一連の処理でエラー等が発生した場合、当該一連の処理の実行をリトライする。このため、第一の実施形態に係る情報処理システム1によれば、機器20のユーザは、各種のサービスを実現する一連の処理でエラーが発生した場合でも、再実行操作等の行うことなく、当該一連の処理の再実行を行うことができるようになる。

0200

また、第二の実施形態に係る情報処理システム1では、各種のサービスを実現する一連の処理でエラー等が発生した場合、発生したエラーに応じて、当該一連の処理の実行をリトライする。このため、第二の実施形態に係る情報処理システム1では、例えば、リトライすべきでないエラー等が発生した場合には、当該一連の処理の実行をリトライしないようにすることができる。

0201

更に、第三の実施形態に係る情報処理システム1では、各種のサービスを実現する一連の処理でエラー等が発生した場合、当該一連の処理の進捗状況に応じて、当該一連の処理の実行をリトライする。このため、第三の実施形態に係る情報処理システム1では、例えば、リトライすべきない処理が実行された後にエラー等が発生した場合には、当該一連の処理の実行をリトライしないようにすることができる。

0202

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

0203

1情報処理システム
10サービス提供システム
20機器
110入出力サービス処理部
111アプリ管理部
112ロジック処理部
120Webサービス処理部
121画面構成部
122アプリ実行部
130ドキュメントサービス部
140アプリ情報記憶部
150 画面情報記憶部
301フロー実行部
302コンポーネント管理部
303コンポーネント群
304型変換管理部
305 型変換群
1000 アプリ情報
1100処理フロー情報
2000 画面情報
3000 型変換情報テーブル

先行技術

0204

特許第4039191号公報

ページトップへ

この技術を出願した法人

この技術を発明した人物

ページトップへ

関連する挑戦したい社会課題

該当するデータがありません

関連する公募課題

該当するデータがありません

ページトップへ

技術視点だけで見ていませんか?

この技術の活用可能性がある分野

分野別動向を把握したい方- 事業化視点で見る -

ページトップへ

おススメ サービス

おススメ astavisionコンテンツ

新着 最近 公開された関連が強い技術

この 技術と関連性が強い人物

関連性が強い人物一覧

この 技術と関連する社会課題

該当するデータがありません

この 技術と関連する公募課題

該当するデータがありません

astavision 新着記事

サイト情報について

本サービスは、国が公開している情報(公開特許公報、特許整理標準化データ等)を元に構成されています。出典元のデータには一部間違いやノイズがあり、情報の正確さについては保証致しかねます。また一時的に、各データの収録範囲や更新周期によって、一部の情報が正しく表示されないことがございます。当サイトの情報を元にした諸問題、不利益等について当方は何ら責任を負いかねることを予めご承知おきのほど宜しくお願い申し上げます。

主たる情報の出典

特許情報…特許整理標準化データ(XML編)、公開特許公報、特許公報、審決公報、Patent Map Guidance System データ