以下、本発明の実施形態について、図面を参照しながら詳細に説明する。
[第一の実施形態]
<システム構成>
まず、本実施形態に係る情報処理システム1のシステム構成について、図1を参照しながら説明する。図1は、本実施形態に係る情報処理システム1の一例のシステム構成を示す図である。
図1に示す情報処理システム1は、サービス提供システム10と、機器20とを含み、インターネット等の広域的なネットワークN1を介して通信可能に接続されている。
サービス提供システム10は、一台以上の情報処理装置で実現され、ネットワークN1を介して、種々の機能をそれぞれ実現する複数の処理のうちの1以上の処理を組み合わせた一連の処理により実現される各種のサービスを提供する。
ここで、機能とは、文書ファイルや画像ファイル等の電子ファイルに関する機能である。機能には、例えば、プリント、スキャン、ファクシミリ送信、データ形式の変換、メール配信、OCR(Optical character recognition)処理、加工や圧縮・解凍、リポジトリへの格納等が挙げられる。
本実施形態に係るサービス提供システム10が提供するサービスの具体例については後述する。なお、以降では、一連の処理を「処理フロー」とも表す。
機器20は、ユーザが使用する各種の電子機器である。すなわち、機器20は、例えば、MFP(Multifunction Peripheral)等の画像形成装置、PC(パーソナルコンピュータ)、プロジェクタ、電子黒板、デジタルカメラ等である。ユーザは、機器20を用いて、サービス提供システム10が提供する各種のサービスを利用することができる。
なお、以降では、複数の機器20について、各々を区別するときは、「機器201」、「機器202」等と添え字を用いて記載する。
また、図1に示す情報処理システム1の構成は一例であって、他の構成であっても良い。例えば、本実施形態に係る情報処理システム1には、電子データの入力及び出力の少なくとも一方を行う各種機器が含まれ、これらの機器がサービス提供システム10により提供されるサービスを利用しても良い。
<ハードウェア構成>
次に、本実施形態に係る情報処理システム1に含まれるサービス提供システム10のハードウェア構成について、図2を参照しながら説明する。図2は、本実施形態に係るサービス提供システム10の一例のハードウェア構成を示す図である。
図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で接続されている。
入力装置11は、キーボードやマウス、タッチパネル等を含み、ユーザが各操作信号を入力するのに用いられる。表示装置12は、ディスプレイ等を含み、サービス提供システム10による処理結果を表示する。なお、入力装置11及び表示装置12の少なくとも一方は、必要なときにサービス提供システム10に接続して利用する形態であっても良い。
通信I/F17は、サービス提供システム10をネットワークN1に接続するインタフェースである。これにより、サービス提供システム10は、通信I/F17を介して通信を行うことができる。
HDD18は、プログラムやデータを格納している不揮発性の記憶装置である。HDD18に格納されるプログラムやデータには、サービス提供システム10全体を制御する基本ソフトウェアであるOS(Operating System)、OS上において各種機能を提供するアプリケーションソフトウェア等がある。
なお、サービス提供システム10は、HDD18に代え、記憶媒体としてフラッシュメモリを用いるドライブ装置(例えばソリッドステートドライブ:SSD)を利用するものであっても良い。また、HDD18は、格納しているプログラムやデータを所定のファイルシステム及び/又はDBにより管理している。
外部I/F13は、外部装置とのインタフェースである。外部装置には、記録媒体13a等がある。これにより、サービス提供システム10は、外部I/F13を介して記録媒体13aの読み取りや書き込みを行うことができる。記録媒体13aには、フレキシブルディスク、CD、DVD、SDメモリカード、USBメモリ等がある。
ROM15は、電源を切ってもプログラムやデータを保持することができる不揮発性の半導体メモリである。ROM15には、サービス提供システム10の起動時に実行されるBIOS(Basic Input/Output System)、OS設定、及びネットワーク設定等のプログラムやデータが格納されている。RAM14は、プログラムやデータを一時保持する揮発性の半導体メモリである。
CPU16は、ROM15やHDD18等の記憶装置からプログラムやデータをRAM14上に読み出し、処理を実行することで、サービス提供システム10全体の制御や機能を実現する演算装置である。
本実施形態に係るサービス提供システム10は、図2に示すハードウェア構成を有することにより、後述するような各種処理を実現できる。
次に、本実施形態に係る情報処理システム1に含まれる機器20が画像形成装置である場合のハードウェア構成について、図3を参照しながら説明する。図3は、本実施形態に係る機器20の一例のハードウェア構成を示す図である。
図3に示す機器20は、コントローラ21と、操作パネル22と、外部I/F23と、通信I/F24と、プリンタ25と、スキャナ26とを有する。また、コントローラ21は、CPU31と、RAM32と、ROM33と、NVRAM34と、HDD35とを有する。
ROM33は、各種プログラムやデータを格納している不揮発性の半導体メモリである。RAM32は、プログラムやデータを一時保持する揮発性の半導体メモリである。NVRAM34は、例えば設定情報等を格納している。また、HDD35は、各種プログラムやデータを格納している不揮発性の記憶装置である。
CPU31は、ROM33やNVRAM34、HDD35等からプログラムやデータ、設定情報等をRAM32上に読み出し、処理を実行することで、機器20全体の制御や機能を実現する演算装置である。
操作パネル22は、ユーザからの入力を受け付ける入力部と、表示を行う表示部とを備えている。外部I/F23は、外部装置とのインタフェースである。外部装置には、記録媒体23a等がある。これにより、機器20は、外部I/F23を介して記録媒体23aの読み取り及び/又は書き込みを行うことができる。なお、記録媒体23aには、例えば、ICカード、フレキシブルディスク、CD、DVD、SDメモリカード、USBメモリ等がある。
通信I/F24は、機器20をネットワークに接続するインタフェースである。これにより、機器20は、通信I/F24を介して通信を行うことができる。プリンタ25は、印刷データを印刷する印刷装置である。スキャナ26は、原稿を読み取って電子ファイル(画像ファイル)を生成する読取装置である。
本実施形態に係る機器20は、図3に示すハードウェア構成を有することにより、後述するような各種処理を実現できる。
<サービス提供システムが提供するサービス>
ここで、本実施形態に係るサービス提供システム10が提供するサービスについて説明する。なお、以降では、機器20が画像形成装置であるものとして説明する。
本実施形態に係るサービス提供システム10は、機器20において原稿をスキャンして生成された電子ファイル(画像ファイル)をOCR処理して、ユーザにより指定されたメールアドレス宛にメール配信するサービスを提供する。
以降では、本実施形態に係るサービス提供システム10は、上述したサービス(「スキャン To メール配信」サービス)を提供するものとして説明する。
ただし、サービス提供システム10が提供するサービスは、これに限られない。サービス提供システム10は、例えば、機器20において原稿をスキャンして生成された電子ファイルを圧縮して、リポジトリへ格納するサービスを提供しても良い。また、サービス提供システム10は、例えば、機器20において原稿をスキャンして生成された電子ファイルを加工(例えば、当該電子ファイルに所定の文言を付加)して、ファクシミリ送信するサービスを提供しても良い。
また、例えば、機器20が電子黒板等である場合には、本実施形態に係るサービス提供システム10は、電子黒板である機器20により生成された電子ファイルを加工して、メール配信するサービス等を提供しても良い。
<機能構成>
次に、本実施形態に係る情報処理システム1の機能構成について、図4を参照しながら説明する。図4は、本実施形態に係る情報処理システムの一例の機能構成を示す図である。
図4に示す機器20は、例えばCPU31等により実行されるウェブブラウザ210(以降では、単に「ブラウザ210」と表す。)を有する。機器20のユーザは、ブラウザ210を用いて、サービス提供システム10が提供するサービスを利用することができる。
このように、本実施形態に係る機器20には、ブラウザ210が搭載されていれば良い。したがって、本実施形態に係る機器20では、例えば、サービス提供システム10が提供するサービスを利用するための専用のアプリケーションプログラム等を搭載する必要がない。
図4に示すサービス提供システム10は、入出力サービス処理部110と、Webサービス処理部120と、ドキュメントサービス部130とを有する。これら各機能部は、サービス提供システム10にインストールされた1以上のプログラムが、CPU16に実行させる処理により実現される。
また、サービス提供システム10は、アプリ情報記憶部140と、画面情報記憶部150とを有する。これら各記憶部は、HDD18により実現可能である。なお、アプリ情報記憶部140及び画面情報記憶部150の少なくとも一方が、サービス提供システム10とネットワークを介して接続される記憶装置等により実現されていても良い。
入出力サービス処理部110は、サービス提供システム10が提供するサービスに関する処理を行う。ここで、入出力サービス処理部110は、アプリ管理部111と、ロジック処理部112とを有する。
アプリ管理部111は、アプリ情報記憶部140に記憶されているアプリ情報1000を管理する。なお、アプリ情報1000とは、一連の処理により実現されるサービスを提供するためのアプリケーションである。すなわち、サービス提供システム10が提供する各種のサービスは、アプリ情報1000により提供される。
また、アプリ管理部111は、ロジック処理部112からの要求に応じて、アプリ情報1000に含まれる処理フロー情報1100を返信する。なお、処理フロー情報1100とは、アプリ情報1000により提供されるサービスを実現する一連の処理が定義された情報である。
ロジック処理部112は、Webサービス処理部120からの要求に応じて、アプリ情報1000に含まれる処理フロー情報1100をアプリ管理部111から取得する。そして、ロジック処理部112は、アプリ管理部111から取得した処理フロー情報1100に基づいて、当該アプリ情報1000が提供するサービスを実現する一連の処理(処理フロー)を実行する。これにより、本実施形態に係るサービス提供システム10は、各種のサービスを提供することができる。なお、ロジック処理部112の詳細については後述する。
Webサービス処理部120は、サービス提供システム10が提供するサービスを、ユーザがブラウザ210を用いて利用するための処理を行う。すなわち、Webサービス処理部120は、ブラウザ210に対してWebアプリケーション(アプリ情報1000)を提供するアプリケーションサーバとして機能する。ここで、Webサービス処理部120は、画面構成部121と、アプリ実行部122とを有する。
画面構成部121は、ブラウザ210からの要求に応じて、画面情報記憶部150に記憶されている画面情報2000を返信する。なお、画面情報2000とは、アプリ情報1000により提供されるサービスを利用するための画面(アプリ画面)が定義された情報である。画面情報2000は、例えば、HTML(HyperText Markup Language)、XHTML(Extensible HyperText Markup Language)、CSS(Cascading Style Sheets)、JavaScript(登録商標)等のブラウザ210が解釈可能な形式でアプリ画面が定義されている。
これにより、機器20の操作パネル22には、ブラウザ210により、サービス提供システム10が提供するサービスを利用するためのアプリ画面が表示される。
アプリ実行部122は、ブラウザ210からの要求に応じて、入出力サービス処理部110に対して、アプリケーション(アプリ情報1000)の実行要求を送信する。
ドキュメントサービス部130は、処理フロー情報1100に基づく一連の処理(処理フロー)に含まれる各処理を実行する。ここで、ドキュメントサービス部130は、OCR処理部131と、メール配信部132とを有する。
OCR処理部131は、電子ファイル(画像ファイル)に対してOCR処理を行う。メール配信部132は、電子ファイルを添付したメールを作成して、当該メールを指定されたメールアドレス宛に配信する。
なお、ドキュメントサービス部130は、例えば、電子ファイルのデータ形式を所定のデータに変換するデータ変換部、電子ファイルを圧縮又は解凍する圧縮・解凍部等を有していても良い。
このように、ドキュメントサービス部130には、一連の処理(処理フロー)に含まれる各処理を実行する種々の機能部が含まれる。したがって、ドキュメントサービス部130は、これら種々の機能を提供するプログラム(モジュール)群により実現される。
アプリ情報記憶部140は、アプリ情報1000を記憶する。アプリ情報1000は、当該アプリ情報1000を一意に識別するアプリIDと関連付けてアプリ情報記憶部140に記憶されている。なお、アプリ情報1000には、さらに、当該アプリ情報1000のアプリケーション名(アプリ名)が関連付けられていても良い。
ここで、アプリ情報1000には、処理フロー情報1100が含まれる。例えば、「スキャン To メール配信」サービスを提供するアプリ情報1000には、当該サービスを実現する一連の処理が定義された処理フロー情報1100が含まれる。すなわち、「スキャン To メール配信」サービスを提供するアプリ情報1000には、スキャンにより生成された電子ファイルをOCR処理した後、指定されたメールアドレス宛にメール配信する処理が定義された処理フロー情報1100が含まれる。
なお、アプリ情報1000には、2以上の処理フロー情報1100が含まれていても良い。例えば、「スキャン To メール配信」を提供するアプリ情報1000には、英語でOCR処理した後、メール配信する処理が定義された処理フロー情報1100Aと、日本語でOCR処理した後、メール配信する処理が定義された処理フロー情報1100Bとが含まれていても良い。
処理フロー情報1100は、上述したように、アプリ情報1000により提供されるサービスを実現する一連の処理(処理フロー)が定義された情報である。なお、処理フロー情報1100の詳細については後述する。
画面情報記憶部150は、画面情報2000を記憶する。画面情報2000は、アプリIDと関連付けて画面情報記憶部150に記憶されている。なお、画面情報2000の詳細については後述する。
なお、入出力サービス処理部110、Webサービス処理部120、ドキュメントサービス部130、アプリ情報記憶部140、及び画面情報記憶部150は、それぞれが異なる情報処理装置により実現されていても良い。特に、Webサービス処理部120及び画面情報記憶部150をアプリケーションサーバとして、一台の情報処理装置で実現しても良い。
ここで、ロジック処理部112の詳細な機能構成について、図5を参照しながら説明する。図5は、本実施形態に係るロジック処理部112の一例の機能構成図である。
図5に示すロジック処理部112は、フロー実行部301と、コンポーネント管理部302と、コンポーネント群303と、型変換管理部304と、型変換群305とを有する。また、ロジック処理部112は、型変換情報テーブル3000を有する。
フロー実行部301は、アプリ実行部122からアプリケーションの実行要求を受信すると、当該実行要求に対応するアプリ情報1000に含まれる処理フロー情報1100をアプリ管理部111から取得する。そして、フロー実行部301は、アプリ管理部111から取得した処理フロー情報1100に基づく一連の処理(処理フロー)を実行する。
ここで、処理フロー情報1100に基づく一連の処理は、当該一連の処理に含まれる各処理を実行するためのコンポーネントを組み合わせることにより実行される。なお、コンポーネントは、所定の機能を実現する処理を実行するためのプログラムやモジュール等により実現され、例えばクラスや関数等で定義される。
コンポーネント管理部302は、コンポーネントを管理する。コンポーネント管理部302は、フロー実行部301からの要求に応じて、コンポーネントを生成すると共に、生成したコンポーネントをフロー実行部301に返信する。なお、コンポーネントの生成とは、例えばクラスや関数等で定義されたコンポーネントを、メモリ(例えばRAM14)上に展開することである。
コンポーネント群303は、コンポーネントの集合である。コンポーネント群303には、OCRコンポーネント1310と、メール配信コンポーネント1320とが含まれる。
OCRコンポーネント1310は、電子ファイルをOCR処理するためのコンポーネントである。OCRコンポーネント1310は、ドキュメントサービス部130のOCR処理部131にOCR処理を要求することにより、電子ファイルのOCR処理を行う。
メール配信コンポーネント1320は、指定されたメールアドレス宛にメール配信するためのコンポーネントである。メール配信コンポーネント1320は、ドキュメントサービス部130のメール配信部132にメール配信処理を要求することにより、指定されたメールアドレス宛にメールを配信する。
このように、各コンポーネントは、ドキュメントサービス部130を利用して、所定の機能を実現する処理を実行する。なお、コンポーネント群303には、上記のコンポーネント以外にも、例えば、電子ファイルのデータ形式を所定のデータ形式に変換するための変換コンポーネント、電子ファイルを圧縮するための圧縮コンポーネント等の各種のコンポーネントが含まれる。
また、コンポーネント群303に含まれる各コンポーネントは、コンポーネント共通I/F1300を有する。コンポーネント共通I/F1300は、各コンポーネントに対して共通に定義されたAPI(Application Programming Interface)であり、コンポーネントを生成するためのAPIと、コンポーネントの処理を実行するためのAPIとが含まれる。
このように、各コンポーネントがコンポーネント共通I/F1300を有することで、コンポーネントの追加等に伴う影響を局所化することができる。すなわち、例えば、フロー実行部301やコンポーネント管理部302等に影響を与えることなく、コンポーネントの追加等を行うことができる。これにより、本実施形態に係るサービス提供システム10では、所定の機能の追加等(すなわち、当該機能を実現する処理を実行するためのコンポーネントの追加等)に伴う開発工数を削減することができる。
型変換管理部304は、データ型の型変換を管理する。ここで、各コンポーネントは、自身が扱えるデータ型が予め決まっている。したがって、型変換管理部304は、コンポーネントからの要求に応じて、例えば図6に示す型変換情報テーブル3000を参照して、型変換群305に含まれる型変換を生成する。
そして、型変換管理部304は、生成された型変換に型変換処理の実行を要求する。なお、型変換は、データ型の型変換処理を実行するプログラムやモジュール等により実現され、例えばクラスや関数等で定義される。また、型変換の生成とは、例えばクラスや関数等で定義された型変換を、メモリ(例えばRAM14上)に展開することである。
なお、データ型には、例えば、ストリームデータを示すデータ型「InputStream」、記憶装置等に格納されている電子ファイルのパス(アドレス)を示す「LocalFilePath」、及び電子ファイルの実体を示す「File」等が挙げられる。
ここで、型変換情報テーブル3000について、図6を参照しながら説明する。図6は、型変換情報テーブルの一例を示す図である。
図6に示す型変換情報テーブル3000は、データ項目として、変換前のデータ型と、変換後のデータ型と、生成する型変換とを有する。すなわち、型変換情報テーブル3000に格納されている型変換情報は、変換前のデータ型及び変換後のデータ型毎に、当該変換前のデータ型を、当該変換後のデータ型に変換するための型変換が関連付けられた情報である。
型変換群305は、型変換の集合である。型変換群305には、データ型「InputStream」を「LocalFilePath」に変換するための第1の型変換1410が含まれる。なお、型変換群305には、これ以外にも、例えば、データ型「LocalFilePath」を「File」に変換するための第2の型変換等が含まれる。
また、型変換群305に含まれる各型変換は、型変換共通I/F1400を有する。型変換共通I/F1400は、各型変換に対して共通に定義されたAPIであり、型変換を生成するためのAPIと、型変換の型変換処理を実行するためのAPIとが含まれる。
このように、各型変換が型変換共通I/F1400を有することで、型変換の追加等に伴う影響を局所化することができる。すなわち、例えば、型変換管理部304等に影響を与えることなく、型変換の追加等を行うことができる。これにより、本実施形態に係るサービス提供システム10では、型変換の追加等に伴う開発工数を削減することができる。
ここで、「スキャン To メール配信」サービスを提供するアプリ情報1000に含まれる処理フロー情報1100について、図7を参照しながら説明する。図7は、処理フロー情報の一例を示す図である。
図7に示す処理フロー情報1100は、「スキャン To メール配信」サービスを実現する一連の処理(処理フロー)が定義された情報である。すなわち、図7に示す処理フロー情報1100は、「スキャン To メール配信」サービスを実現する一連の処理を構成する各処理をそれぞれ示す処理定義1101及び処理定義1102が定義されている。
ここで、処理定義1101及び処理定義1102は、「コンポーネント名:処理内容?オプションパラメータ」の形式で定義される。なお、オプションパラメータは、例えば、コンポーネント名及び処理内容で示されるコンポーネントが処理を行うのに必要である場合に限り、定義されていれば良い(すなわち、オプションパラメータの定義は任意である。)。また、複数のオプションパラメータを定義する場合には、オプションパラメータ同士を「&」で結合することにより定義する。
処理定義1101には、「ocr:ocr_process」が定義されている。これは、OCRコンポーネント1310によりOCR処理を行うこと意味している。なお、処理定義1101には、オプションパラメータは定義されていない。
処理定義1102には、「mail:send」が定義されている。これは、メール配信コンポーネント1320によりメール配信処理を行うことを意味している。
また、処理定義1102には、「?mail_address=null&filename=null」が定義されている。これは、「mail_address」に指定されたメールアドレス宛に、「filename」に指定されたファイル名の電子ファイルをメール配信することを意味している。なお、図7に示す例では、「mail_address」及び「filename」には値が指定されていない(すなわち、nullである。)。
このように、処理フロー情報1100には、一連の処理(処理フロー)を構成する各処理の処理定義が定義されている。これにより、本実施形態に係るサービス提供システム10は、処理フロー情報1100に含まれる各処理定義に従って、各コンポーネントによる処理を行うことで、アプリ情報1000により提供されるサービスを実現する一連の処理を実行することができる。
なお、図7に示す処理フロー情報1100に含まれる各処理定義に定義された処理は、上から順に実行される。すなわち、図7に示す処理フロー情報1100に基づく一連の処理では、処理定義1101に定義された処理、処理定義1102に定義された処理の順で実行される。ただし、これに限られず、処理フロー情報1100には、例えば、各処理定義に定義された処理の実行順を示す情報が定義されていても良い。
<処理の詳細>
次に、本実施形態に係る情報処理システム1の処理の詳細について説明する。以降では、機器20のユーザが、「スキャン To メール配信」サービスを利用する場合の全体的な処理について、図8を参照しながら説明する。図8は、本実施形態に係る「スキャン To メール配信」サービスの全体処理の一例を示すシーケンス図である。
まず、機器20のブラウザ210は、「スキャン To メール配信」サービスのアプリ画面を表示させるための操作(表示操作)を受け付ける(ステップS801)。
機器20のブラウザ210は、当該表示操作を受け付けると、「スキャン To メール配信」サービスのアプリ画面を表示するための画面情報の取得要求を、Webサービス処理部120の画面構成部121に送信する(ステップS802)。なお、当該取得要求は、例えば、HTTP(Hypertext Transfer Protocol)リクエストであり、「スキャン To メール配信」サービスを提供するアプリ情報1000のURL(Uniform Resource Locator)が指定される。このとき、当該取得要求には、「スキャン To メール配信」サービスを提供するアプリ情報1000のアプリIDが含まれていても良い。
Webサービス処理部120の画面構成部121は、画面情報の取得要求を受信すると、当該取得要求に指定されているURLに対応するアプリIDと関連付けられている画面情報2000を画面情報記憶部150から取得する(ステップS803)。そして、Webサービス処理部120の画面構成部121は、画面情報記憶部150から取得した画面情報2000をブラウザ210に返信する。すなわち、画面構成部121は、画面情報記憶部150から取得した画面情報2000を含むHTTPレスポンスをブラウザ210に返信する。なお、このとき、画面構成部121は、当該URLに対応するアプリIDもブラウザ210に返信する。
ここで、「スキャン To メール配信」サービスのアプリ画面を表示するための画面情報2000について、図9を参照しながら説明する。図9は、画面情報の一例を示す図である。
図9に示す画面情報2000は、HTML形式で定義された情報であり、見出し定義2001と、ファイル名入力欄定義2002と、メールアドレス入力欄定義2003と、スキャン実行ボタン定義2004とが含まれる。このように、画面情報2000は、HTMLタグ等のブラウザ210が解釈可能な形式によりアプリ画面が定義されている。これにより、ブラウザ210は、図9に示す画面情報2000に基づいて、後述するアプリ画面2100を表示することができる。
次に、機器20のブラウザ210は、画面構成部121から画面情報2000を受信すると、当該画面情報2000に基づいて、例えば図10に示すアプリ画面2100を表示する(ステップS804)。
図10に示すアプリ画面2100は、図9に示す画面情報2000に基づいて、ブラウザ210により表示された画面である。図10に示すアプリ画面2100には、タイトル2101と、ファイル名入力欄2102と、メールアドレス入力欄2103と、スキャン実行ボタン2104とが含まれる。
ここで、タイトル2101は、例えば、「スキャン To メール配信」サービスを提供するアプリ情報1000のアプリ名である。ファイル名入力欄2102は、メールに添付する電子ファイル(すなわち、スキャンにより生成された電子ファイルをOCR処理した電子ファイル)のファイル名をユーザが指定する入力エリアである。メールアドレス入力欄2103は、メールの配信先となるメールアドレスをユーザが指定する入力エリアである。
なお、タイトル2101及びファイル名入力欄2102は、見出し定義2001及びファイル名入力欄定義2002をブラウザ210がそれぞれ解釈することにより表示される。また、同様に、メールアドレス入力欄2103及びスキャン実行ボタン2104は、メールアドレス入力欄定義2003及びスキャン実行ボタン定義2004をブラウザ210がそれぞれ解釈することにより表示される。
このように、本実施形態に係るサービス提供システム10は、機器20のブラウザ210からの要求に応じて、HTML形式等のブラウザ210が解釈可能な形式で定義された画面情報2000を返信する。そして、機器20は、サービス提供システム10から返信された画面情報2000に基づいて、サービスを利用するためのアプリ画面を表示する。したがって、ユーザは、一般的なブラウザ210が搭載された機器20を用いて、サービス提供システム10が提供するサービスを利用することができる。
なお、上記のステップS803において、画面構成部121は、画面情報記憶部150から画面情報2000を取得するものとしたが、これに限られない。画面構成部121は、例えば、アプリ情報1000に基づいて、画面情報2000を生成しても良い。
すなわち、画面構成部121は、例えば、アプリ管理部111を介して、画面情報の取得要求に含まれるアプリIDに関連付けられているアプリ情報1000をアプリ情報記憶部140から取得する。そして、画面構成部121は、アプリ情報1000に含まれる情報(例えば、アプリ名、処理フロー情報1200に定義されているオプションパラメータ等)を、予め記憶されている画面情報の雛形に対して定義することで、画面情報2000を生成しても良い。
ここで、図10に示すアプリ画面2100において、ユーザにより、ファイル名入力欄2102及びメールアドレス入力欄2103にファイル名及びメールアドレスが指定された上で、スキャン実行ボタン2104を押下してスキャン実行操作がなされたものとする。
すると、機器20のブラウザ210は、ユーザ指定情報及びスキャン実行操作を受け付ける(ステップS805)。なお、ユーザ指定情報とは、ファイル名入力欄2102及びメールアドレス入力欄2103にそれぞれ指定されたファイル名及びメールアドレスである。例えば、ファイル名入力欄2102に「test.pdf」、メールアドレス入力欄2103に「hoge@hogehoge.co.jp」が指定されたとする。この場合、ユーザ指定情報は、「mail_address=hoge@hogehoge.co.jp」と、「filename=test.pdf」とを含む情報である。
次に、機器20のブラウザ210は、スキャン実行操作を受け付けると、スキャナ26により原稿を読み取って、電子ファイル(画像ファイル)を生成する(ステップS806)。
次に、機器20のブラウザ210は、電子ファイルが生成されると、アプリケーションの実行要求を、Webサービス処理部120のアプリ実行部122に送信する(ステップS807)。なお、当該実行要求は、例えば、HTTPリクエストであり、「スキャン To メール配信」サービスを提供するアプリ情報1000のアプリIDと、上記のステップS806で生成された電子ファイルと、ユーザ指定情報とが含まれる。
ただし、アプリケーションの実行要求には、アプリIDに代えて、例えば、アプリ情報1000のURL、上記のステップS804で表示したアプリ画面2100の画面ID、スキャン実行ボタン2104のボタンID等が含まれていても良い。すなわち、アプリケーションの実行要求には、アプリIDに代えて、後述するステップS808で「スキャン To メール配信」サービスを提供するアプリ情報1000のアプリIDに変換することができる種々の識別情報が含まれていても良い。
Webサービス処理部120のアプリ実行部122は、アプリケーションの実行要求を受信すると、当該要求を、入出力サービス処理部110のロジック処理部112に送信する(ステップS808)。なお、アプリ実行部122は、例えば、アプリ情報1000のURL、アプリ画面2100の画面ID、スキャン実行ボタン2104のボタンID等がアプリケーションの実行要求に含まれている場合には、これらの識別情報をアプリIDに変換する。
次に、入出力サービス処理部110のロジック処理部112は、アプリケーションの実行要求を受信すると、処理フローの実行処理を行う(ステップS809)。すなわち、ロジック処理部112は、当該要求に含まれるアプリIDのアプリ情報1000に含まれる処理フロー情報1100に基づく一連の処理を実行する。なお、処理フローの実行処理の詳細については後述する。
そして、ロジック処理部112は、処理フローの実行処理の処理結果を、Webサービス処理部120を介して、ブラウザ210に返信する。これにより、本実施形態に係るサービス提供システム10は、処理フロー情報1100に基づく一連の処理(処理フロー)により実現される各種のサービスを提供することができる。
なお、図8に示す「スキャン To メール配信」サービスの全体処理では、ブラウザ210は、Webサービス処理部120を介して、ロジック処理部112にアプリケーションの実行要求を送信しているが、これに限られない。ブラウザ210は、例えば、画面情報2000に定義されたJavaScript等に基づいてWebAPIを呼び出すことにより、直接、ロジック処理部112にアプリケーションの実行要求を送信しても良い。
以降では、処理フローの実行処理(図8のステップS809の処理)の詳細について、図11を参照しながら説明する。図11は、本実施形態に係る処理フローの実行処理の一例を示すシーケンス図である。
フロー実行部301は、アプリケーションの実行要求を受信すると、当該実行要求からアプリIDを取得する。そして、フロー実行部301は、当該アプリIDを含む処理フロー情報の取得要求をアプリ管理部111に送信する(ステップS1101)。
アプリ管理部111は、処理フローの取得要求を受信すると、当該取得要求に含まれるアプリIDに関連付けられているアプリ情報1000に含まれる処理フロー情報1100をアプリ情報記憶部140から取得する(ステップS1102)。そして、アプリ管理部111は、アプリ情報記憶部140から取得した処理フロー情報1100をフロー実行部301に返信する。ここで、以降では、アプリ管理部111は、図7に示す処理フロー情報1100をフロー実行部301に返信したものとして説明する。
なお、アプリ情報1000が複数の処理フロー情報1100を含む場合には、フロー実行部301は、上記のステップS1101において、アプリIDと、処理フロー情報1100を一意に識別するフローIDとを含む処理フロー情報の取得要求を送信すれば良い。
フロー実行部301は、処理フロー情報1100をアプリ管理部111から受信すると、当該処理フロー情報1100を解析する(ステップS1103)。すなわち、フロー実行部301は、処理フローの実行に必要なコンポーネントの特定等を行う。
次に、フロー実行部301は、解析した処理フロー情報1100に基づいて、コンポーネントの取得要求をコンポーネント管理部302に送信する(ステップS1104)。すなわち、フロー実行部301は、図7に示す処理フロー情報1100の処理定義1101に定義されている「ocr:ocr_process」を含むコンポーネントの取得要求をコンポーネント管理部302に送信する。
コンポーネント管理部302は、コンポーネントの取得要求を受信すると、当該取得要求に含まれる「ocr:ocr_process」に対応するOCRコンポーネント1310を生成する(ステップS1105)。なお、OCRコンポーネント1310の生成は、コンポーネント共通I/F1300を用いて行うことができる。
そして、コンポーネント管理部302は、生成したOCRコンポーネント1310をフロー実行部301に返信する。すなわち、コンポーネント管理部302は、例えば、OCRコンポーネント1310が展開されたメモリ(例えばRAM14)上のアドレスをフロー実行部301に返信する。
フロー実行部301は、OCRコンポーネント1310が返信されると、コンポーネントの処理実行要求を、当該OCRコンポーネント1310に送信する(ステップS1106)。なお、コンポーネントの処理実行要求には、データと、パラメータとが含まれる。
ここで、ステップS1106において、データとは、データ型「InputStream」として、アプリ実行部122から受信した電子ファイル(アプリケーションの実行要求に含まれる電子ファイル)である。すなわち、フロー実行部301は、アプリ実行部122から受信した電子ファイルを、単に「データ」として(データ型を意識することなく)、OCRコンポーネント1310に送信する。以降では、このようにデータ型を意識しない電子ファイル等を、単に「データ」と表す。
また、処理定義1101にはオプションパラメータが定義されていないため、ステップS1106において、パラメータには、nullが指定される。
OCRコンポーネント1310は、コンポーネントの処理実行要求を受信すると、型変換要求を型変換管理部304に送信する(ステップS1107)。なお、当該型変換要求には、データと、OCRコンポーネント1310が扱うことができるデータ型を示す「LocalFilePath」の指定とが含まれる。
型変換管理部304は、型変換要求を受信すると、当該型変換要求に含まれるデータのデータ型と、指定されたデータ型とが一致するか否かをチェックする(ステップS1108)。
ここで、型変換要求に含まれるデータのデータ型は「InputStream」である一方、指定されたデータ型は「LocalFilePath」である。したがって、型変換管理部304は、型変換要求に含まれるデータのデータ型と、指定されたデータ型とが一致しないものと判断する。
すると、型変換管理部304は、型変換情報テーブル3000を参照して、データ型「InputStream」を「LocalFilePath」に変換するための型変換を特定する(ここでは、第1の型変換1410が特定される。)。そして、型変換管理部304は、特定した第1の型変換1410を生成する(ステップS1109)。なお、第1の型変換1410の生成は、型変換共通I/F1400を用いて行うことができる。
次に、型変換管理部304は、型変換処理の実行要求を第1の型変換1410に送信する(ステップS1110)。なお、当該実行要求には、データが含まれる。
第1の型変換1410は、型変換の実行要求を受信すると、当該実行要求に含まれるデータのデータ型を「InputStream」から「LocalFilePath」に変換する型変換処理を行う(ステップS1111)。そして、第1の型変換1410は、データ型が変換されたデータを型変換管理部304に返信する。
そして、型変換管理部304は、第1の型変換1410からデータを受信すると、当該データをOCRコンポーネント1310に送信する(ステップS1112)。
OCRコンポーネント1310は、型変換管理部304からデータを受信すると、当該データに対して処理を実行する(ステップS1113)。すなわち、OCRコンポーネント1310は、ドキュメントサービス部130のOCR処理部131により、当該データ(データ型「LocalFilePath」)により示される電子ファイルのOCR処理を行う。
そして、OCRコンポーネント1310は、処理結果を示すデータをフロー実行部301に返信する。なお、ここで返信されるデータは、OCRコンポーネント1310によりOCR処理された電子ファイルを示すデータ(データ型「LocalFilePath」)である。
次に、フロー実行部301は、ステップS1103で解析した処理フロー情報1100に基づいて、コンポーネントの取得要求をコンポーネント管理部302に送信する(ステップS1114)。すなわち、フロー実行部301は、図7に示す処理フロー情報1100の処理定義1102に定義されている「mail:send」を含むコンポーネントの取得要求をコンポーネント管理部302に送信する。
コンポーネント管理部302は、コンポーネントの取得要求を受信すると、当該取得要求に含まれる「mail:send」に対応するメール配信コンポーネント1320を生成する(ステップS1115)。なお、メール配信コンポーネント1320の生成は、コンポーネント共通I/F1300を用いて行うことができる。
そして、コンポーネント管理部302は、生成したメール配信コンポーネント1320をフロー実行部301に返信する。すなわち、コンポーネント管理部302は、例えば、メール配信コンポーネント1320が展開されたメモリ(例えばRAM14)上のアドレスをフロー実行部301に返信する。
フロー実行部301は、メール配信コンポーネント1320が返信されると、コンポーネントの処理実行要求を、当該メール配信コンポーネント1320に送信する(ステップS1116)。なお、コンポーネントの処理実行要求には、データと、パラメータとが含まれる。
ここで、ステップS1116において、パラメータには、処理定義1102のオプションパラメータ「mail_address=null&filename=null」と、ユーザ指定情報とが含まれる。
メール配信コンポーネント1320は、コンポーネントの処理実行要求を受信すると、型変換要求を型変換管理部304に送信する(ステップS1117)。なお、当該型変換要求には、データと、メール配信コンポーネント1320が扱うことができるデータ型を示す「LocalFilePath」の指定とが含まれる。
型変換管理部304は、型変換要求を受信すると、当該型変換要求に含まれるデータのデータ型と、指定されたデータ型とが一致するか否かをチェックする(ステップS1118)。
ここで、型変換要求に含まれるデータのデータ型は「LocalFilePath」であり、指定されたデータ型も「LocalFilePath」である。したがって、型変換管理部304は、型変換要求に含まれるデータのデータ型と、指定されたデータ型とが一致するものと判断する。
すると、型変換管理部304は、型変換要求に含まれるデータをメール配信コンポーネント1320に送信する(ステップS1119)。このように、データ型のチェック(ステップS1118の処理)において、データのデータ型と、指定されたデータ型とが一致すると判断された場合には、型変換管理部304は、型変換の生成を行わない。
メール配信コンポーネント1320は、型変換管理部304からデータを受信すると、パラメータに基づいて、当該データに対して処理を実行する(ステップS1120)。すなわち、メール配信コンポーネント1320は、ドキュメントサービス部130のメール配信部132により、当該データにより示される電子ファイルを、パラメータに基づいて、メール配信する。
より具体的には、メール配信コンポーネント1320は、まず、パラメータに含まれるオプションパラメータにユーザ指定情報を定義して「mail_address=hoge@hogehoge.co.jp&filename=test.pdf」とする。次に、メール配信コンポーネント1320は、メール配信部132により、当該データにより示される電子ファイルのファイル名を「test.pdf」とした電子ファイルを添付したメールを作成する。最後に、メール配信コンポーネント1320は、メール配信部132により、作成したメールを「hoge@hogehoge.co.jp」宛に配信(送信)する。
そして、メール配信コンポーネント1320は、処理結果を示すデータをフロー実行部301に返信する。なお、ここで返信されるデータは、例えば、メール配信コンポーネント1320により正常にメールが配信されたことを示す情報等である。
以上のように、本実施形態に係るサービス提供システム10は、処理フロー情報1100に基づいて、各コンポーネントによる処理をそれぞれ行うことで、一連の処理(処理フロー)を実行する。これにより、本実施形態に係るサービス提供システム10は、当該一連の処理により実現されるサービスを提供することができる。
[第二の実施形態]
次に、第二の実施形態について説明する。第二の実施形態は、ブラウザ210からロジック処理部112に対して、直接、アプリケーションの実行要求を行うものである。なお、第二の実施形態の説明では、主に、第一の実施形態との相違点について説明し、第一の実施形態と実質的に同様の機能構成を有する箇所及び実質的に同様の処理を実行する箇所は、適宜、その説明を省略する。
<機能構成>
まず、本実施形態に係る情報処理システム1の機能構成について、図12を参照しながら説明する。図12は、本実施形態に係る情報処理システム1の一例の機能構成図である。
図12に示すサービス提供システム10のWebサービス処理部120は、第一の実施形態と異なり、アプリ実行部122を有しない。
また、図12に示す機器20のブラウザ210は、アプリ実行部211を有する。アプリ実行部211は、例えば、画面情報2000に含まれるJavaScript等がブラウザ210により実行されることで生成され、入出力サービス処理部110のロジック処理部112に対して、アプリケーションの実行要求を送信する。
<処理の詳細>
次に、本実施形態に係る情報処理システム1の処理の詳細について説明する。以降では、機器20のユーザが、「スキャン To メール配信」サービスを利用する場合の全体的な処理について、図13を参照しながら説明する。図13は、本実施形態に係る「スキャン To メール配信」サービスの全体処理の一例を示すシーケンス図である。なお、ステップS801〜ステップS802、ステップS804〜ステップS806、及びステップS809の処理は、第一の実施形態と同様であるため、その説明を省略する。
Webサービス処理部120の画面構成部121は、画面情報の取得要求を受信すると、当該取得要求に指定されているURLに対応するアプリIDと関連付けられている画面情報2000を画面情報記憶部150から取得する(ステップS1301)。
ここで、画面構成部121により取得された画面情報2000には、ブラウザ210により実行されることでアプリ実行部211として機能するJavaScript等のスクリプトが含まれるものとする。
そして、Webサービス処理部120の画面構成部121は、画面情報記憶部150から取得した画面情報2000をブラウザ210に返信する。なお、このとき、画面構成部121は、当該URLに対応するアプリIDもブラウザ210に返信する。
ステップS806に続いて、機器20のブラウザ210は、画面情報2000に含まれるJavaScript等のスクリプトを実行することで、アプリ実行部211を生成する(ステップS1302)。
そして、アプリ実行部211は、ブラウザ210により生成されると、アプリケーションの実行要求を、入出力サービス処理部110のロジック処理部112に送信する(ステップS1303)なお、当該実行要求には、「スキャン To メール配信」サービスを提供するアプリ情報1000のアプリIDと、ステップS806で生成された電子ファイルと、ユーザ指定情報とが含まれる。
このように、本実施形態に係る情報処理システム1では、画面情報2000に含まれるJavaScript等をブラウザ210が実行することで、ブラウザ210からロジック処理部112に対して、直接、アプリケーションの実行要求を行うことができる。
[第三の実施形態]
次に、第三の実施形態について説明する。第三の実施形態は、アプリ情報1000の利用状況をサービス提供システム10が管理するものある。なお、第三の実施形態の説明では、主に、第一の実施形態との相違点について説明し、第一の実施形態と実質的に同様の機能構成を有する箇所及び実質的に同様の処理を実行する箇所は、適宜、その説明を省略する。
<機能構成>
まず、本実施形態に係る情報処理システム1の機能構成について、図14を参照しながら説明する。図14は、本実施形態に係る情報処理システム1の一例の機能構成を示す図である。
図14に示すサービス提供システム10のWebサービス処理部120は、更に、利用状況管理部123を有する。また、図14に示すサービス提供システム10は、利用状況情報記憶部160を有する。
利用状況管理部123は、アプリ情報1000の利用状況を示す利用状況情報をアプリ実行部122から取得して、利用状況情報記憶部160に記憶させる。また、利用状況管理部123は、利用状況管理クライアント30からの要求に応じて、利用状況情報記憶部160に記憶されている利用状況情報を返信する。なお、利用状況管理部123は、Webサービス処理部120に含まれている必要はなく、例えば、Webサービス処理部120とは異なるモジュール等で実現されていても良い。
ここで、利用状況管理クライアント30とは、サービス提供システム10が管理する利用状況の閲覧等を行うための情報処理装置(コンピュータ)であり、サービス提供システム10とネットワークN1を介して接続されている。
利用状況情報記憶部160は、利用状況情報を記憶する。利用状況情報の詳細については後述する。
<処理の詳細>
次に、本実施形態に係る情報処理システム1の処理の詳細について説明する。以降では、機器20のユーザが、「スキャン To メール配信」サービスを利用する場合の全体的な処理について、図15を参照しながら説明する。図15は、本実施形態に係る「スキャン To メール配信」サービスの全体処理の一例を示すシーケンス図である。なお、ステップS801〜ステップS807及びステップS809の処理は、第一の実施形態と同様であるため、その説明を省略する。
アプリ実行部122は、アプリケーションの実行要求を受信すると、当該実行要求に含まれるアプリIDのアプリ情報1000(すなわち、ユーザにより利用されるアプリ情報1000)が利用状況の登録対象であるか否かを確認する(ステップS1501)。利用状況の登録対象であるアプリ情報1000のアプリIDは、例えば、サービス提供システム10の管理者等により予め設定される。
次に、アプリ実行部122は、アプリケーションの実行要求を、入出力サービス処理部110のロジック処理部112に送信する(ステップS1502)。なお、当該実行要求には、更に、上記のステップS1501における確認結果が含まれる。
ユーザにより利用されたアプリ情報1000が利用状況の登録対象である場合(上記のステップS1501の確認結果が利用状況の登録対象であることを示す場合)、ステップS809に続いて、ステップS1504〜ステップS1506の処理が実行される。
すなわち、アプリ実行部122は、処理結果を受信すると、処理情報の取得要求をロジック処理部112に送信する(ステップS1503)。なお、アプリ実行部122は、例えば、受信した処理結果に含まれる確認結果を参照することで、ユーザにより利用されたアプリ情報1000が利用状況の登録対象であるか否かを確認すれば良い。
処理情報とは、ロジック処理部112で実行された処理フローに関する情報である。処理情報には、後述する利用状況情報と同様のデータ項目が含まれる。なお、当該取得要求には、例えば、アプリ実行部122が受信した処理結果に含まれるジョブID等が含まれる。
ロジック処理部112は、処理情報の取得要求を受信すると、処理情報を生成する(ステップS1504)。そして、ロジック処理部112は、生成した処理情報をアプリ実行部122に返信する。
アプリ実行部122は、処理情報を受信すると、利用状況の登録要求を利用状況管理部123に送信する(ステップS1505)。なお、当該登録要求には、処理情報が含まれる。
利用状況管理部123は、利用状況の登録要求を受信すると、当該登録要求に含まれる処理情報を、利用状況情報として利用状況情報記憶部160に記憶させる(ステップS1506)。これにより、アプリ情報1000の利用状況がサービス提供システム10に登録される。
ここで、利用状況情報記憶部160に記憶されている利用状況情報について、図16を参照しながら説明する。図16は、利用状況情報の一例を示す図である。
図16に示す利用状況情報は、データ項目として、固有IDと、アプリIDと、アプリ名と、ジョブ状態と、入力ページ数と、出力ページ数と、日時とを有する。これらは、上記のステップS1502で生成された処理情報に含まれるデータ項目である。
固有IDは、ロジック処理部112により実行された処理フローを識別する情報である。固有IDには、例えば、ジョブID等が挙げられる。
アプリIDは、ロジック処理部112により実行された処理フローに対応するアプリ情報1000のアプリIDである。アプリ名は、当該アプリ情報1000のアプリケーション名である。ジョブ状態は、ロジック処理部112により実行された処理フローの状態である。処理フローの状態には、処理フローが正常に終了したことを示す「completed」、処理フローでエラー発生したことを示す「error」等がある。
入力ページ数は、処理フローに入力されたファイルのページ数である。出力ページ数は、処理フローから出力されたファイルのページ数である。日時は、処理フローが実行された日時である。
このように、利用状況情報記憶部160には、ユーザにより利用されたアプリ情報1000のうち、登録対象のアプリ情報1000の利用状況を示す利用状況情報が記憶される。
ここで、上記のステップS1504で生成される処理情報には、処理フローを実行したユーザに関する情報(例えば、ユーザIDやテナントID等)が含まれていても良い。この場合、利用状況情報記憶部160には、図17に示す利用状況情報が記憶される。
図17に示す利用状況情報には、更に、テナントIDと、ユーザIDとが含まれる。テナントIDは、例えば、ユーザが属する企業やグループ等(これら企業やグループ等を「テナント」と総称する。)を識別する情報である。ユーザIDは、当該テナント内においてユーザを識別する情報である。
このように、利用状況情報記憶部160に記憶されている利用状況情報には、テナントIDやユーザID等のユーザに関する情報が含まれていても良い。これにより、後述する利用状況レポートにおいて、例えば、テナント単位で利用状況を表示したり、ユーザ単位で利用状況を表示したりすることができる。
次に、ユーザが利用状況管理クライアント30を用いて、利用状況レポートを表示させる処理について、図18を参照しながら説明する。図18は、本実施形態に係る利用状況レポートの表示処理の一例を示すシーケンス図である。
まず、利用状況管理クライアント30は、利用状況の取得要求を、Webサービス処理部120の利用状況管理部123に送信する(ステップS1801)。なお、利用状況管理クライアント30は、例えば、ユーザにより、利用状況レポートの表示操作が行われることで、利用状況の取得要求を利用状況管理部123に送信する。
Webサービス処理部120の利用状況管理部123は、利用状況情報記憶部160から利用状況情報を取得する(ステップS1802)。そして、利用状況管理部123は、取得した利用状況情報を利用状況管理クライアント30に返信する。
利用状況管理クライアント30は、利用状況情報を受信すると、利用状況レポートを表示する(ステップS1803)。
ここで、図17に示す利用状況情報(すなわち、ユーザに関する情報が含まれない利用状況情報)が返信された場合における利用状況レポート3100を図19に示す。図19は、利用状況レポート3100の一例を示す図である。
図19に示す利用状況レポート3100には、利用状況に関するレポートである、利用状況レポート3100には、例えば、利用状況一覧3101と、利用件数グラフ3102と、検索欄3103とが含まれる。
利用状況一覧3101には、登録対象のアプリ情報1000の利用状況が一覧で表示される。利用状況一覧3101は、利用状況管理部123から返信された利用状況情報に基づき表示される。
利用件数グラフ3102は、日毎の利用件数がグラフで表示される。検索欄3103には、利用状況一覧3101に表示される利用状況をフィルタリングするための条件を入力する。例えば、所望の期間を検索欄3103に入力した上で、「検索」ボタンを押下することで、利用状況一覧3101は、当該期間内の利用状況が表示される。
ここで、図18に示す利用状況情報(すなわち、ユーザに関する情報が含まれる利用状況情報)が返信された場合における利用状況レポート3200を図20に示す。図20は、利用状況レポート3200の他の例を示す図である。
図20に示す利用状況レポート3200には、例えば、利用状況一覧3201と、利用件数グラフ3202と、検索欄3203と、テナント/ユーザ切替欄3204とが含まれる。
利用状況一覧3201には、登録対象のアプリ情報1000の利用状況が一覧で表示される。利用状況一覧3201は、利用状況管理部123から返信された利用状況情報に基づき表示される。
利用件数グラフ3202は、日毎の利用件数がグラフで表示される。検索欄3203には、利用状況一覧3201に表示される利用状況をフィルタリングするための条件を入力する。例えば、所望のユーザ名と、所望の期間とを検索欄3203に入力した上で、「検索」ボタンを押下することで、利用状況一覧3201は、当該期間内における当該ユーザの利用状況が表示される。
テナント/ユーザ切替欄3204は、利用状況一覧3201に表示される利用状況をテナント毎又はユーザ毎に切り替える選択欄である。例えば、テナント/ユーザ切替欄3204を「テナント」に切り替えることで、テナント名を検索欄3203に設定することができるようになる。
このように、利用状況管理クライアント30には、登録対象のアプリ情報1000の利用状況が表示される。これにより、ユーザは、アプリ情報1000毎の利用状況(例えば、利用回数が多いか、利用回数が多い時間帯は何時頃か等)、サービス提供システム10全体におけるアプリ情報1000の利用状況等を知ることができる。また、ユーザに関する情報が利用状況情報に含まれる場合には、ユーザは、ユーザ毎やテナント毎の利用状況を知ることもできる。
[第四の実施形態]
次に、第四の実施形態について説明する。第四の実施形態では、アプリ実行部122が利用状況の管理を行う場合について説明する。なお、第四の実施形態の説明では、主に、第三の実施形態との相違点について説明し、第三の実施形態と実質的に同様の機能構成を有する箇所及び実質的に同様の処理を実行する箇所は、適宜、その説明を省略する。
<機能構成>
まず、本実施形態に係る情報処理システム1の機能構成について、図21を参照しながら説明する。図21は、本実施形態に係る情報処理システム1の一例の機能構成を示す図である。
図21に示すサービス提供システム10のWebサービス処理部120は、第三の実施形態と異なり、利用状況管理部123を有しない。本実施形態では、アプリ実行部122がロジック処理部112から取得した処理情報を、利用状況情報として利用状況情報記憶部160に記憶させる。
<処理の詳細>
次に、本実施形態に係る情報処理システム1の処理の詳細について説明する。以降では、機器20のユーザが、「スキャン To メール配信」サービスを利用する場合の全体的な処理について、図22を参照しながら説明する。図22は、本実施形態に係る「スキャン To メール配信」サービスの全体処理の一例を示すシーケンス図である。なお、ステップS801〜ステップS807及びステップS808並びにステップS1501〜ステップS1504の処理は、第三の実施形態と同様であるため、その説明を省略する。
アプリ実行部122は、処理情報を受信すると、当該処理情報を利用状況情報として利用状況情報記憶部160に記憶させる(ステップS2201)。これにより、アプリ情報1000の利用状況がサービス提供システム10に登録される。
このように、本実施形態に係るアプリ実行部122は、ロジック処理部112から受信した処理情報を利用状況情報として、直接、利用状況情報記憶部160に記憶させる。
次に、ユーザが利用状況管理クライアント30を用いて、利用状況レポートを表示させる処理について、図23を参照しながら説明する。図23は、本実施形態に係る利用状況レポートの表示処理の一例を示すシーケンス図である。
まず、利用状況管理クライアント30は、利用状況の取得要求を、Webサービス処理部120のアプリ実行部122に送信する(ステップS2301)。なお、利用状況管理クライアント30は、例えば、ユーザにより、利用状況レポートの表示操作が行われることで、利用状況の取得要求をアプリ実行部122に送信する。
Webサービス処理部120のアプリ実行部122は、利用状況情報記憶部160から利用状況情報を取得する(ステップS2302)。そして、アプリ実行部122は、取得した利用状況情報を利用状況管理クライアント30に返信する。
利用状況管理クライアント30は、利用状況情報を受信すると、利用状況レポートを表示する(ステップS2303)。これにより、利用状況管理クライアント30には、利用状況レポートが表示される。
<まとめ>
以上のように、第一の実施形態に係る情報処理システム1では、ユーザは、一般的なブラウザ210が搭載された機器20を用いて、サービス提供システム10が提供するサービスを利用することができる。すなわち、本実施形態に係る情報処理システム1では、例えば、サービス提供システム10が提供するサービスを利用するための専用のアプリケーションプログラム等を機器20に搭載する必要がない。
また、第一の実施形態に係る情報処理システム1では、例えばサードベンダー等のアプリケーション開発者は、アプリ情報1000及び画面情報2000を作成することで、サービス提供システム10が提供するサービスを追加することができる。しかも、アプリケーション開発者は、サービスを実現する一連の処理のそれぞれの処理を行うコンポーネントを順に定義することで、アプリ情報1000に含まれる処理フロー情報1100を容易に作成することができる。
したがって、第一の実施形態に係る情報処理システム1によれば、一連の処理により実現されるサービスを提供するアプリケーションの開発を容易に行うことができると共に、開発に要する工数等を削減することができる。
また、第二の実施形態に係る情報処理システム1では、画面情報2000に含まれるJavaScript等をブラウザ210が実行することで、ブラウザ210からロジック処理部112に対して、直接、アプリケーションの実行要求を行うことができる。このため、第二の実施形態に係る情報処理システム1によれば、汎用的なウェブブラウザが搭載された様々な機器から、直接、各種のサービスを実現する処理フローを実行させることができる。
また、第三の実施形態及び第四の実施形態に係る情報処理システム1では、所定のアプリ情報1000の利用状況のレポートを利用状況管理クライアント30に表示させることができる。これにより、利用状況管理クライアント30のユーザは、所定のアプリ情報1000の利用状況を知ることができる。このため、例えば、処理フローやアプリケーションの開発者等は、利用状況を参照することで、アプリケーションや処理フローの機能改善、品質向上等を検討することができるようになる。
本発明は、具体的に開示された上記の各実施形態に限定されるものではなく、特許請求の範囲から逸脱することなく、種々の変形や変更が可能である。