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

Description

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

近年、複数の機能（スキャン及びプリント及びメール配信等）を組み合わせた機能を提供するサービス等が存在する。例えば、スキャンにより生成した電子ファイル（画像ファイル）に所定の処理を行った上で、メール配信するサービス等が存在する。また、このような一連の処理を実行するアプリケーションをプログラミング等の専門的な知識なしで作成できる技術（以降、アプリ作成ツール）が既に存在する。

しかしながら、従来のアプリ作成ツールは、アプリケーションの変更を行った場合に、パラメータの設定値を維持することが困難な場合がある。

例えば、従来のアプリ作成ツールは、作成したアプリケーションを、既にユーザが利用している場合に、アプリケーションに対する変更を行うと、そのアプリケーションにおけるユーザの設定値をデフォルト値にリセットする。そのような場合、従来のアプリ作成ツールは、アプリケーションに対する変更を行う前の状態に、ユーザの設定値を戻すためには、ユーザが再度設定し直すか、又は設定値を復元するための専用のプログラムを作成し、ユーザに配布する必要があった。

本発明に係る情報処理システム及び情報処理装置及び情報処理方法及びプログラムは、上述の課題を解決することを目的とする。すなわち、本発明に係る情報処理システム及び情報処理装置及び情報処理方法及びプログラムは、アプリケーションを変更した場合に、パラメータの設定値を維持することで、上述の課題を解決する。

上述した課題を解決し、目的を達成するために、本発明は、デバイスとサーバとを備えた情報処理システムであって、アプリケーションを変更すると、前記サーバは、前記アプリケーションの変更前のパラメータと変更後のパラメータの対応付けの指定を受け付ける対応付け受け付け部と、前記対応付け受け付け部によって受け付けた前記対応付けに応じて、前記アプリケーションの変更前の第１のパラメータのユーザごとの設定値を、前記アプリケーションの変更後のパラメータであって、前記第１のパラメータに対応付けた第２のパラメータの設定値に設定する設定部と、を備える。

本発明によれば、アプリケーションを変更した場合でも、パラメータの設定値を維持することができる。

図１は、第１の実施形態の情報処理システムの構成例を示す図である。 図２は、第１の実施形態のサーバ及びＰＣのハードウェア構成の例を示す図である。 図３は、第１の実施形態のＭＦＰのハードウェア構成の例を示す図である。 図４は、第１の実施形態のサーバの機能構成の例を示す図である。 図５は、第１の実施形態のパラメータの設定値を変更するシーケンスを示す図である。 図６は、変更前のパラメータの設定値の一例を示す図である。 図７は、パラメータ対応付けの作成画面の一例を示す図である。 図８は、変更後のパラメータの設定値の一例を示す図である。 図９は、ユーザが設定値を維持する必要がないと判断したパラメータの一例を示す図である。 図１０は、第２の実施形態のパラメータの設定値を変更するシーケンスを示す図である。 図１１は、パラメータ対応付けの作成画面の一例を示す図である。 図１２は、パラメータの対応付けのためのＵＩの一例を示す図である。 図１３は、パラメータの対応付けのためのＵＩの一例を示す図である。 図１４は、パラメータの対応付けのためのＵＩの一例を示す図である。 図１５は、パラメータの対応付けのためのＵＩの一例を示す図である。 図１６は、パラメータの対応付けのためのＵＩの一例を示す図である。 図１７は、パラメータの対応付けのためのＵＩの一例を示す図である。 図１８は、アプリケーションを統合する画面の一例を示す図である。 図１９は、第４の実施形態のアプリケーションを統合するシーケンスを示す図である。 図２０は、第４の実施形態の統合後のアプリケーションを利用するシーケンスを示す図である。 図２１は、設定値の対応付けの一例を示す図である。 図２２は、統合前後のパラメータの設定値の一例を示す図である。 図２３は、第４の実施形態の情報処理システムにおける、設定値を維持しない統合前後のパラメータの一例を示す図である。 図２４は、アプリケーションを分割する画面の一例を示す図である。 図２５は、第５の実施形態のアプリケーションを分割するシーケンスを示す図である。 図２６は、第５の実施形態の情報処理システムにおける、分割後のアプリケーションを利用するシーケンスを示す図である。 図２７は、第５の実施形態の情報処理システムにおける、設定値の対応付けの一例を示す図である。 図２８は、第５の実施形態の情報処理システムにおける、設定値を維持しない分割前後のパラメータの一例を示す図である。 図２９は、第５の実施形態の情報処理システムにおける、アプリケーションを多対多で変更する画面の一例を示す図である。 図３０は、実施形態の情報処理システムの機能ブロック図である。

以下に添付図面を参照して、情報処理システム及び情報処理装置及び情報処理方法及びプログラムの実施の形態を詳細に説明する。

（第１の実施の形態）
図１は、第１の実施形態の情報処理システムの構成例を示す図である。図１に示すように、情報処理システム１は、サーバ１０及びサーバ１０と通信ネットワークで接続したデバイス２０を有する。デバイス２０は、ＭＦＰ(Ｍultifunction Peripheral)２０ａ、ＰＣ２０ｂを含む。以降の説明では、ＭＦＰ２０ａ及びＰＣ２０ｂを区別せずにデバイス２０と表記する場合がある。

図２は、第１の実施形態のサーバ及びＰＣのハードウェア構成の例を示す図である。ここでは、サーバ１０のハードウェア構成について説明する。ＰＣ２０ｂは、サーバ１０と同様のハードウェア構成を有するものであってもよい。図２に示すように、サーバ１０は、コンピュータを用いることができる。図２に示すように、サーバ１０は、ＣＰＵ１００１及びＲＯＭ１００２及びＲＡＭ１００３及びＨＤ１００４及びＨＤＤ(Hard Disk Drive)コントローラ１００５及びディスプレイ１００６及び外部機器接続インターフェース(Interface)１００８を備えている。また、サーバ１０は、ネットワークインターフェース１００９及びデータバス１０１０及びキーボード１０１１及びポインティングデバイス１０１２及びＤＶＤ－ＲＷ(Digital Versatile Disk Rewritable)ドライブ１０１４及びメディアインターフェース１０１６を備えている。

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

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

図３は、第１の実施形態のＭＦＰのハードウェア構成の例を示す図である。図３に示すように、ＭＦＰ２０ａは、コントローラ、近距離通信回路２０２０、エンジン制御部２０３０、操作パネル２０４０、ネットワークインターフェース２０５０を備えている。

これらのうち、コントローラは、コンピュータの主要部であるＣＰＵ２００１、システムメモリ（ＭＥＭ－Ｐ）２００２、ノースブリッジ（ＮＢ）２００３、サウスブリッジ（ＳＢ）２００４を有する。また、コントローラは、ＡＳＩＣ(Application Specific Integrated Circuit)２００６、記憶部であるローカルメモリ（ＭＥＭ－Ｃ）２００７、ＨＤＤコントローラ２００８、及び、記憶部であるＨＤ２００９を有する。そして、コントローラは、ＮＢ２００３とＡＳＩＣ２００６との間をＡＧＰ(Accelerated Graphics Port)バス２０２１で接続した構成となっている。

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

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

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

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

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

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

なお、ＭＦＰ２０ａは、操作パネル２０４０のアプリケーション切り替えキーにより、ドキュメントボックス機能、コピー機能、プリンタ機能、及びファクシミリ機能を順次に切り替えて選択することが可能となる。ＭＦＰ２０ａは、ドキュメントボックス機能の選択時にはドキュメントボックスモードとなり、コピー機能の選択時にはコピーモードとなる。また、ＭＦＰ２０ａは、プリンタ機能の選択時にはプリンタモードとなり、ファクシミリモードの選択時にはファクシミリモードとなる。

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

図４は、第１の実施形態のサーバの機能構成の例を示す図である。ここで、サーバ１０は、情報処理装置の一例である。図４に示すように、サーバ１０は、Ｗｅｂサービス処理部１１、ポータルサービス部１２、アプリデータ管理部１３及び入出力サービス処理部１４を有する。

Ｗｅｂサービス処理部１１は、入出力サービス処理部１４が記憶しているデータを基に、Ｗｅｂアプリケーションの画面を構成し、また、処理実行を入出力サービス処理部１４へ依頼するモジュールである。なお、以降の説明では、アプリケーションを省略してアプリと表記する場合がある。

Ｗｅｂサービス処理部１１は、画面構成部１１１及びアプリ実行部１１２を有する。画面構成部１１１は、入出力サービス処理部１４から取得した情報に基づき、Ｗｅｂアプリケーションの画面を構成する。アプリ実行部１１２は、ユーザからのリクエストに応じて処理を実行する。

ポータルサービス部１２は、アプリケーションの開発のためのＵＩを、デバイス２０のブラウザ２１を介して表示することでユーザに提供し、ユーザの操作に応じてアプリケーションの新規登録及び変更等を行う。ここでのアプリケーションは、例えば様々な処理（コンポーネント）をつなぎ合わせ、１つのフローを実行するアプリケーションである。

ポータルサービス部１２は、ＵＩ提供部１２１及びアプリ登録部１２２を有する。ＵＩ提供部１２１は、ポータル画面情報１６の画面内容に基づき、所定のＵＩをデバイス２０のブラウザを介してユーザに提供する。アプリ登録部１２２は、ユーザからのリクエストを受け取って、ＵＩを介して生成したアプリケーションを入出力サービス処理部１４に登録する。入出力サービス処理部１４に登録するアプリケーションとしては、Ｗｅｂ上で実行するＷｅｂアプリケーションを登録してもよい。

アプリデータ管理部１３は、アプリケーションに関するデータを管理する。アプリケーションに関するデータには、パラメータ及びパラメータごとの設定値が含まれる。アプリデータ管理部１３は、ＵＩ提供部１３１及びアプリデータ登録部１３２を有する。パラメータ及び設定値の管理方法については後述する。

入出力サービス処理部１４は、アプリ管理部１４１及び入出力ロジック処理部１４２を有する。アプリ管理部１４１は、アプリケーションの処理内容をアプリ情報１５として保存し管理する。入出力ロジック処理部１４２は、アプリケーションの実行リクエストを受け取って、フローを実行する。入出力ロジック処理部１４２は、コンポーネント１７のＯＣＲ１７１及びファイル変換１７２等を組み合わせてフローを実行する。

図５は、第１の実施形態のパラメータの設定値を変更するシーケンス図である。図５に示すように、まず、デバイス２０は、ブラウザ２１を介して行われるユーザからのアプリ管理画面の表示要求を取得する（ステップＳ１０１）。デバイス２０は、ブラウザ２１を介して、ポータルサービス部１２のＵＩ提供部１２１に、アプリ管理画面の取得を要求する（ステップＳ１０２）。

ＵＩ提供部１２１は、アプリ管理画面を生成する（ステップＳ１０３）。そして、ＵＩ提供部１２１は、生成したアプリ管理画面をブラウザ２１に提供する（ステップＳ１０４）。デバイス２０は、ブラウザ２１を介してアプリ管理画面を表示する（ステップＳ１０５）。

次に、デバイス２０は、ユーザからブラウザ２１を介して行われる、リリース済みアプリの変更要求を取得する（ステップＳ１０６）。このとき、デバイス２０は、ユーザの操作に基づいて、変更元のアプリの情報及び変更後のアプリの情報を取得するする。デバイス２０は、ブラウザ２１を介してＵＩ提供部１２１に、リリース済みアプリの変更を要求する（ステップＳ１０７）。ＵＩ提供部１２１は、アプリ登録部１２２に、リリース済みアプリの変更を要求する（ステップＳ１０８）。

アプリ登録部１２２は、入出力サービス処理部１４のアプリ管理部１４１に、アプリ情報の取得を要求する（ステップＳ１０９）。アプリ管理部１４１は、アプリの情報を取得し（ステップＳ１１０）、取得結果をアプリ登録部１２２に返す（ステップＳ１１１）。さらに、アプリ登録部１２２は、取得結果をＵＩ提供部１２１に返す（ステップＳ１１２）。そして、ＵＩ提供部１２１は、デバイス２０に取得結果を返す（ステップＳ１１３）。デバイス２０は、ブラウザ２１を介して、パラメータ対応付けの作成画面を表示する（ステップＳ１１４）。

デバイス２０は、パラメータ対応付けの作成画面に基づいて、ユーザにより作成されたアプリの変更前のパラメータと変更後のパラメータを取得すると共に（ステップＳ１１５）、パラメータ対応付けの登録要求を取得する（ステップＳ１１６）。ブラウザ２１は、ＵＩ提供部１２１に、パラメータ対応付けの登録を要求する（ステップＳ１１７）。ＵＩ提供部１２１は、アプリ登録部１２２に、パラメータ対応付けの登録を要求する（ステップＳ１１８）。さらに、アプリ登録部１２２は、アプリデータ管理部１３のアプリデータ登録部１３２に、パラメータ対応付けの登録を要求する（ステップＳ１１９）。

アプリデータ登録部１３２は、ステップＳ１１６でユーザにより作成されたた対応付けに応じて、アプリを使用する各ユーザのパラメータの設定値を変更する（ステップＳ１２０）。アプリデータ登録部１３２は、変更結果をアプリ登録部１２２に返す（ステップＳ１２１）。アプリ登録部１２２は、変更結果をＵＩ提供部１２１に返す（ステップＳ１２２）。ＵＩ提供部１２１は、変更結果をブラウザ２１に返す（ステップＳ１２３）。デバイス２０は、ブラウザ２１を介して変更結果を表示する（ステップＳ１２４）。

ここで、ユーザによる変更前後のアプリケーションのパラメータが以下の通りであったものとする。
・変更前
FlowControl.CustomParameters2.TextParameters (type: string, default: "")
FlowControl.CustomParameters3.NumberParameters (type: number, default: 0)
OCR.ExecuteOCR.OutputFileFormat (type: string, default: "PDF")
GoDrive.UploadFile.FolderId (type: string, default: "Root")
・変更後
FlowControl.CustomParameters2.BooleanParameters (type: boolean, default: true)
FlowControl.CustomParameters3.TextParameters (type: string, default: "")
OCR.ExecuteOCR.OutputFileFormat (type: string, default: "PDF")
GoDriveV2.UploadFile.FolderId (type: string, default: "Root")

図６は、変更前のパラメータの一例を示す図である。変更前のパラメータの設定値が、この図６の通りであったとする。このとき、デバイス２０は、図７に示す通り、ブラウザ２１に表示されるパラメータ対応付けの作成画面を介してユーザが設定したパラメータの対応付けの設定を受け付ける。そして、ポータルサービス部１２は、この対応付けに従ってアプリを使用する各ユーザのパラメータをそれぞれ変更する。図８は、変更後のパラメータの一例を示す図である。変更後のパラメータの設定値は、この図８のようになる。

ここで、図７に示すように、変更前後のパラメータの対応付けは、JSON形式で表すことができる。当該JSON形式のデータにおけるキーは変更前のパラメータの識別子であり、キーに対応する値は変更後のパラメータの識別子である。

図７の例では、変更前のパラメータ「FlowControl.CustomParameters3.NumberParameters」、及び、変更後のパラメータ「FlowControl.CustomParameters2.BooleanParameters」は対応付けしない。第１の実施形態の情報処理システムは、このように、ユーザが設定値を維持する必要がないと判断したパラメータについては、対応付けを作成しない場合がある。

図９は、ユーザが設定値を維持する必要がないと判断したパラメータの一例を示す図である。本実施形態を利用した変更前後でパラメータの設定値を維持しない場合、変更後のパラメータの設定値は、この図９のようになる。つまり、ポータルサービス部１２は、変更前後でキーが完全一致するパラメータ「OCR.ExecuteOCR.OutputFileFormat」以外のパラメータの設定値を破棄する。破棄したポータルサービス部１２は、図９に示すように設定値は明記せず、アプリケーション実行時に所定の初期値に置き換える。

このように、第１の実施形態の情報処理システムは、アプリケーションを変更した際に、ポータルサービス部１２が、アプリケーションの変更前のパラメータと変更後のパラメータの対応付けの指定を、デバイス２０から受け付ける。アプリデータ管理部１３は、ポータルサービス部１２によって受け付けた対応付けに応じて、アプリケーションの変更前の第１のパラメータに設定したユーザごとの設定値を、アプリケーションの変更後のパラメータであって、第１のパラメータに対応付けた第２のパラメータの設定値に設定する。第１の実施形態では、ポータルサービス部１２が対応付け受け付け部として機能する。また、アプリデータ管理部１３が設定部として機能する。これにより、第１の実施形態の情報処理システムは、作成したアプリケーションのパラメータの名称又は選択可能なパラメータを変更する場合に、変更前のアプリケーションと変更後のアプリケーションのパラメータの対応関係を受け付けるための画面をアプリ開発者に提供できる。従って、第１の実施形態の情報処理システムは、ユーザごとの設定値を適切に引き継ぐことが可能なアプリケーションの開発を支援することができる。

（第２の実施の形態）
第２の実施形態について説明する。以降の説明において、特に説明がない場合、各実施形態の基本的な構成及び機能は第１の実施形態と共通であるものとする。各実施形態についての説明は、主に第１の実施形態との相違点について行う。

第２の実施形態では、アプリ登録部１２２が、パラメータの対応付けを自動的に行う。また、デバイス２０は、自動的に行う対応付けを確認し、手動で修正を行うためのＵＩを、ブラウザ２１に表示してユーザに提供する。

アプリ登録部１２２は、レーベンシュタイン距離等に基づき、変更前後で名前が類似するパラメータを対応付けることができる。アプリ登録部１２２で、変更前のパラメータ「GoDrive.UploadFile.FolderId (type: string, default: "Root")」に類似するパラメータを探索することを考える。このとき、変更後のパラメータ「OCR.ExecuteOCR.OutputFileFormat (type: string, default: "PDF")」は、探索元のパラメータと一致している部分がほとんどなく、レーベンシュタイン距離が大きくなることが予測できる。このため、変更前のパラメータと、探索したパラメータは、類似しているとはいえない。

一方、変更後のパラメータ「GoDriveV2.UploadFile.FolderId (type: string, default: "Root")」は、探索対象のパラメータに「V2」という文字列を付加しただけのものであるため、レーベンシュタイン距離が小さくなることが予測でき、類似しているといえる。

例えば、アプリ登録部１２２は、以下のようなロジックで変更後のパラメータＰに変更前のパラメータを対応付ける。
（１）アプリ登録部１２２は、変更前のアプリに存在するパラメータの一覧を、対応付けの候補とする。
（２）アプリ登録部１２２は、変更後のアプリに存在するパラメータ（Ｐ以外）と既に対応付けを行ったパラメータを候補から除外する。
（３）アプリ登録部１２２は、Ｐと型の一致するパラメータが候補に存在するとき、Ｐと型の一致しないパラメータを候補から除外する。
（４）アプリ登録部１２２は、候補のうちＰとのパラメータ名のレーベンシュタイン距離が最小のものを、Ｐと対応付ける。

アプリ登録部１２２による対応付けの後、ＵＩ提供部１２１は、自動的に対応付けを行った旨のメッセージを掲載した図１１のような画面をデバイス２０のブラウザ２１に表示する。図１１は、パラメータ対応付けの作成画面の一例を示す図である。

図１０は、第２の実施形態のパラメータの設定値を変更するシーケンス図である。図１０に示すように、まず、デバイス２０は、ユーザからの、ブラウザ２１に対するアプリ管理画面の表示要求を取得する（ステップＳ２０１）。デバイス２０は、ブラウザ２１を介して、ポータルサービス部１２のＵＩ提供部１２１に、アプリ管理画面の取得を要求する（ステップＳ２０２）。

ＵＩ提供部１２１は、アプリ管理画面を生成する（ステップＳ２０３）。そして、ＵＩ提供部１２１は、生成したアプリ管理画面をブラウザ２１に提供する（ステップＳ２０４）。デバイス２０は、アプリ管理画面を表示する（ステップＳ２０５）。

次に、デバイス２０は、ブラウザ２１を介して行われる、ユーザからのリリース済みアプリの変更要求を取得する（ステップＳ２０６）。このとき、ユーザは、変更元のアプリの情報と変更後のアプリの情報を入力する。デバイス２０は、ＵＩ提供部１２１に、リリース済みアプリの変更を要求する（ステップＳ２０７）。ＵＩ提供部１２１は、アプリ登録部１２２に、リリース済みアプリの変更を要求する（ステップＳ２０８）。

アプリ登録部１２２は、入出力サービス処理部１４のアプリ管理部１４１に、アプリ情報の取得を要求する（ステップＳ２０９）。アプリ管理部１４１は、アプリの情報を取得し（ステップＳ２１０）、取得結果をアプリ登録部１２２に返す（ステップＳ２１１）。

アプリ登録部１２２は、取得結果を基に、パラメータの対応付けを生成する（ステップＳ２１２）。例えば、アプリ登録部１２２は、上記のロジックにしたがい対応付けを行う。アプリ登録部１２２は、対応付けの結果をＵＩ提供部１２１に返す（ステップＳ２１３）。そして、ＵＩ提供部１２１は、ブラウザ２１に対応付けの結果を返す（ステップＳ２１４）。デバイス２０は、対応付けたパラメータの確認及び修正を行う画面を、ブラウザ２１を介して表示する（ステップＳ２１５）。

デバイス２０は、必要に応じてブラウザ２１を介してユーザにより行われたアプリの変更前のパラメータと変更後のパラメータの対応付けの確認及び修正（ステップＳ２１６）、及び、パラメータ対応付けの登録要求を取得する（ステップＳ２１７）。デバイス２０は、ブラウザ２１を介してＵＩ提供部１２１に、パラメータ対応付けの登録を要求する（ステップＳ２１８）。ＵＩ提供部１２１は、アプリ登録部１２２に、パラメータ対応付けの登録を要求する（ステップＳ２１９）。さらに、アプリ登録部１２２は、アプリデータ管理部１３のアプリデータ登録部１３２に、設定値の変更を要求する（ステップＳ２２０）。

アプリデータ登録部１３２は、要求に応じて、ステップＳ２１７で登録した対応付けに応じて、パラメータの設定値を変更する（ステップＳ２２１）。アプリデータ登録部１３２は、変更結果をアプリ登録部１２２に返す（ステップＳ２２２）。アプリ登録部１２２は、変更結果をＵＩ提供部１２１に返す（ステップＳ２２３）。ＵＩ提供部１２１は、変更結果をブラウザ２１に返す（ステップＳ２２４）。ブラウザ２１は、変更結果を表示する（ステップＳ２２５）。

このように、アプリデータ管理部１３は、第１のパラメータの設定値を、第１のパラメータと型が一致するアプリケーションの変更後のパラメータのうち、第１のパラメータとの間でパラメータの名のレーベンシュタイン距離が最小である第２のパラメータの設定値に設定する。

（第３の実施形態）
第３の実施形態では、ＵＩ提供部１２１は、ユーザが直感的な操作により変更前後のパラメータの対応付けを行うためのＵＩを提供する。図１２から図１７は、パラメータの対応付けのためのＵＩの一例を示す図である。

まず、第２の実施形態の方法により、自動的にパラメータの対応付けした後、ＵＩ提供部１２１は、図１２のようなＵＩを提供する。ＵＩ提供部１２１は、図１３及び図１４に示すように、ユーザにより、各パラメータに対応したオブジェクトを結ぶ辺の端部（頂点）がドラッグアンドドロップされると、パラメータ間の対応関係を変更する。図１３の例では、テーブルのセルがオブジェクトに相当する。

さらに、図１５に示すように、ユーザが、辺の一方の端部をいずれのパラメータのオブジェクトも存在しない領域にドラッグアンドドロップすると、ＵＩ提供部１２１は、当該辺が示す対応関係を削除する。

このように、ＵＩ提供部１２１は、各パラメータに対応した画面上のオブジェクトを手動で動かすことにより、第１のパラメータと第２のパラメータを対応付けることができるＵＩを提供する。

ＵＩ提供部１２１は、各パラメータに対応したオブジェクト及びオブジェクト間の辺を、オブジェクト間の対応付けのもっともらしさに応じた態様で表示するＵＩを提供することができる。図１６に示すように、ＵＩ提供部１２１は、パラメータ間の類似度に応じて、辺の太さ及び端部の大きさを変更してもよい。例えば、ＵＩ提供部１２１は、パラメータ名間のレーベンシュタイン距離が小さいほど、辺を太くし、端部の面積を大きくする。

なお、レーベンシュタイン距離が小さいほどもっともらしさは大きくなる。このため、レーベンシュタイン距離をＤとすると、もっともらしさは１／Ｄ又は－Ｄとして表すことができる。

さらに、ＵＩ提供部１２１は、各パラメータに対応したオブジェクトをカーソルでポイントすると、当該カーソルでポイントしたオブジェクトに関する情報を表示するＵＩを提供する。図１７の例は、パラメータ「GoDriveV2.UploadFile.FolderId (type: string, default: "Root")」の説明の表示例である。また、ＵＩ提供部１２１は、変更前のパラメータの設定値、又は、変更後のパラメータの設定値の候補を表示してもよい。

（第４の実施形態）
第４の実施形態として、複数のアプリケーションを１つのアプリケーションに統合する場合の例を説明する。例えば、第４の実施形態によれば、「Scan to Go Drive」又は「Scan to Box」といった、ストレージサービスだけが異なるだけで同じ機能を持った複数のアプリを、ストレージ選択機能を持つ「Scan to Storage」という新しい１個のアプリに変更することができる。

図１８は、アプリケーションを統合する画面の一例を示す図である。図１８に示すように、アプリケーションを統合する画面には、アプリの変更（移行）元を複数個指定するためのチェックボックスと、チェックしたアプリのそれぞれに対してパラメータの対応付けを作成するポップアップを表示する。

図１８の例は、デバイス２０が、ユーザの操作におうじて、が既に利用中の「Scan to Go Drive」アプリ及び「Scan to Box」アプリを、作成中の「Scan to Storage」アプリに置き換えようとしている例である。また、図１８の例は、この置き換えの際にユーザの設定値を維持するために、デバイス２０が、「Scan to Go Drive」アプリのパラメータを、「Scan to Storage」のうち、いずれかのパラメータに紐付ける設定を行っている例である。また、デバイス２０は、「Scan to Mail」アプリについては、「Scan to Storage」アプリで置き換えないようにしている。

図１９は、第４の実施形態のアプリケーションを統合するシーケンスを示す図である。図１９に示すように、まず、デバイス２０は、ユーザからのブラウザ２１に対するアプリ管理画面の表示要求を取得する（ステップＳ３０１）。デバイス２０は、ブラウザ２１を介して、ポータルサービス部１２のＵＩ提供部１２１に、アプリ管理画面の取得を要求する（ステップＳ３０２）。

ＵＩ提供部１２１は、アプリ管理画面を生成する（ステップＳ３０３）。そして、ＵＩ提供部１２１は、生成したアプリ管理画面をブラウザ２１に提供する（ステップＳ３０４）。デバイス２０は、アプリ管理画面を表示する（ステップＳ３０５）。

ここで、情報処理システム１は、以下のステップＳ３０６からステップＳ３２４を変更元のアプリの数だけ繰り返す。デバイス２０は、ユーザがブラウザ２１を介して指定したパラメータ対応付けの作成画面の表示要求を取得する（ステップＳ３０６）。ブラウザ２１は、ＵＩ提供部１２１に、アプリ情報の取得を要求する（ステップＳ３０７）。ＵＩ提供部１２１は、アプリ登録部１２２に、アプリ情報の取得を要求する（ステップＳ３０８）。アプリ登録部１２２は、アプリ管理部１４１に、アプリ情報の取得を要求する（ステップＳ３０９）。アプリ管理部１４１は、アプリ情報を取得し（ステップＳ３１０）、取得結果をアプリ登録部１２２に返す（ステップＳ３１１）。

アプリ登録部１２２は、取得結果をＵＩ提供部１２１に返す（ステップＳ３１２）。ＵＩ提供部１２１は、取得結果をブラウザ２１に返す（ステップＳ３１３）。ブラウザ２１は、パラメータ対応付けの作成画面を表示する（ステップＳ３１４）。デバイス２０は、ユーザからパラメータ対応付けの作成画面を介して対応付けが作成されたアプリの変更前のパラメータと変更後のパラメータを取得する（ステップＳ３１５）。

デバイス２０は、パラメータの対応付け登録をブラウザ２１を介してＵＩ提供部１２１に要求する（ステップＳ３１６、ステップＳ３１７）。ＵＩ提供部１２１は、パラメータの対応付け登録をアプリ登録部１２２に要求する（ステップＳ３１８）。アプリ登録部１２２は、パラメータの対応付け登録をアプリ管理部１４１に要求する（ステップＳ３１９）。アプリ管理部１４１は、パラメータの対応付けを登録する（ステップＳ３２０）。

アプリ管理部１４１は、登録結果をアプリ登録部１２２に返す（ステップＳ３２１）。アプリ登録部１２２は、登録結果をＵＩ提供部１２１に返す（ステップＳ３２２）。ＵＩ提供部１２１は、登録結果をブラウザ２１に返す（ステップＳ３２３）。ブラウザ２１は、登録結果を表示する（ステップＳ３２４）。

図２０は、第４の実施形態の統合後のアプリケーションを利用するシーケンスを示す図である。図２０に示すように、ユーザにより、ブラウザ２１を介してアプリ起動が要求されると（ステップＳ４０１）、デバイス２０は、ブラウザ２１を介してアプリデータ登録部１３２に、アプリ画面及び設定の取得を要求する（ステップＳ４０２）。

アプリデータ登録部１３２は、参照するアプリＩＤを取得する（ステップＳ４０３）。さらに、アプリデータ登録部１３２は、アプリ設定を取得する（ステップＳ４０４）。そして、アプリデータ登録部１３２は、アプリ画面の情報の取得をアプリ管理部１４１に要求する（ステップＳ４０５）。

アプリ管理部１４１は、アプリの管理情報を取得し（ステップＳ４０６）、アプリの変更をアプリデータ登録部１３２に通知する（ステップＳ４０７）。このとき、アプリ管理部１４１は、アプリが移動したことを示す「301 Moved」を返す。

さらに、アプリ管理部１４１は、新しいアプリＩＤで、アプリ画面情報の取得を要求する（ステップＳ４０８）。アプリ管理部１４１は、アプリの管理情報を取得し（ステップＳ４０９）、取得したアプリの画面情報をアプリデータ登録部１３２に通知する（ステップＳ４１０）。

アプリデータ登録部１３２は、パラメータの対応付けを取得する（ステップＳ４１１）。アプリ管理部１４１は、パラメータの対応付けを取得し（ステップＳ４１２）、取得した対応付けを返す（ステップＳ４１３）。

アプリデータ登録部１３２は、パラメータの対応付けにアプリを対応するように設定値を設定する（ステップＳ４１４）。さらに、アプリデータ登録部１３２は、次回以降のパラメータの対応付けが発生しないようにするため、参照するアプリＩＤを更新する（ステップＳ４１５）。アプリデータ登録部１３２は、アプリ画面及び設定をブラウザ２１に返す（ステップＳ４１６）。ブラウザ２１は、アプリ画面を表示する（ステップＳ４１７）。

図２１は、設定値の対応付けの一例を示す図である。また、図２２は、統合前後のパラメータの設定値の一例を示す図である。図２１のようなパラメータの対応付けを与えることで、統合前後のパラメータの設定値は、図２２のようになり、統合前後でパラメータ「storage.service」の設定値を維持できる。

一方、図２３は、設定値を維持しない場合の統合前後のパラメータの一例を示す図である。図２１のようなパラメータの対応付けを与えていない場合、統合前後のパラメータの設定値は、この図２３のようになり、統合前後でパラメータ「storage.service」の設定値は維持しない。

このように、複数のアプリケーションを１つのアプリケーションに統合する変更を行った際に、ポータルサービス部１２は、１つのアプリケーションの変更前のパラメータと変更後のパラメータの対応付けの指定を受け付ける。入出力サービス処理部１４は、ポータルサービス部１２によって受け付けた対応付けに応じて、複数のアプリケーションのそれぞれの第１のパラメータに設定したユーザごとの設定値を、１つのアプリケーションの第２のパラメータの設定値に設定する。

（第５の実施形態）
第５の実施形態の情報処理システムは、１つのアプリケーションを複数のアプリケーションに分割する場合の例である。第５の実施形態の情報処理システムは、ストレージ選択機能を持つ「Scan to Storage」という１個のアプリを、それぞれのストレージ固有のサービスに特化した「Scan to Go Drive with Go Keep」又は「Scan to Box with Box Notes」といった複数のアプリに変更することができる。

図２４は、アプリケーションを分割する画面の一例を示す図である。ＵＩ提供部１２１は、図２４に示すように、アプリケーションを分割する画面に、アプリの変更（移行）元を指定するためのチェックボックスと、複数の変更先のアプリを設定できるポップアップを表示する。

図２４の例は、ユーザが既に利用中の「Scan to Storage」アプリを、作成中の「Scan to Storage」アプリに置き換える例である。ここで、設定は、「Scan to Storage」アプリを、既に作成済みの「Scan to Box」アプリにも置き換え可能な設定となっている。そのため、ＵＩ提供部１２１は、「Scan to Storage」アプリの変更条件を設定できるポップアップを用いて、ユーザが選択中のストレージサービスを、作成中の「Scan to Go Drive」アプリ、又は、作成中の「Scan to Go Drive」アプリのどちらに置き換えるかを定義している。

第５の実施形態の情報処理システムは、ユーザが、これら以外のストレージサービスを選択している場合、又は、ユーザがまだ選択していない場合、次回起動時又は次回設定時に置き換え先の選択が可能となっている。

図２５は、第５の実施形態のアプリケーションを分割するシーケンス図である。図２５に示すように、まず、デバイス２０は、ユーザからのアプリ管理画面の表示要求を取得する（ステップＳ５０１）。デバイス２０は、ポータルサービス部１２のＵＩ提供部１２１に、アプリ管理画面の取得を要求する（ステップＳ５０２）。

ＵＩ提供部１２１は、アプリ管理画面を生成する（ステップＳ５０３）。そして、ＵＩ提供部１２１は、生成したアプリ管理画面をデバイス２０に提供する（ステップＳ５０４）。デバイス２０は、ブラウザ２１を介してアプリ管理画面を表示する（ステップＳ５０５）。

ここで、デバイス２０は、ユーザからの、パラメータ対応付けの作成画面の表示要求を取得する（ステップＳ５０６）。デバイス２０は、ブラウザ２１を介してＵＩ提供部１２１に、アプリ情報の取得を要求する（ステップＳ５０７）。ＵＩ提供部１２１は、アプリ登録部１２２に、アプリ情報の取得を要求する（ステップＳ５０８）。アプリ登録部１２２は、アプリ管理部１４１に、アプリ情報の取得を要求する（ステップＳ５０９）。アプリ管理部１４１は、アプリ情報を取得し（ステップＳ５１０）、さらに、アプリ管理部１４１は、変更元のアプリが他のアプリの変更元としての登録の有無を確認する（ステップＳ５１１）。アプリ管理部１４１は、取得結果及び確認結果をアプリ登録部１２２に返す（ステップＳ５１２）。

アプリ登録部１２２は、取得結果及び確認結果をＵＩ提供部１２１に返す（ステップＳ５１３）。ＵＩ提供部１２１は、取得結果をデバイス２０に返す（ステップＳ５１４）。デバイス２０は、パラメータ対応付けの作成画面及び変更条件の設定画面を、ブラウザ２１を介して表示する（ステップＳ５１５）。デバイス２０は、ユーザにより対応付けられた、アプリの変更前のパラメータと変更後のパラメータ（ステップＳ５１６）及び変更条件の設定（ステップＳ５１７）を取得する。

また、デバイス２０は、ユーザからの、パラメータの対応付け及び変更条件の登録要求を取得する（ステップＳ５１８）。デバイス２０は、ブラウザ２１を介して、パラメータの対応付け及び変更条件の登録をＵＩ提供部１２１に要求する（ステップＳ５１９）。ＵＩ提供部１２１は、パラメータの対応付け及び変更条件の登録をアプリ登録部１２２に要求する（ステップＳ５２０）。アプリ登録部１２２は、パラメータの対応付け及び変更条件の登録をアプリ管理部１４１に要求する（ステップＳ５２１）。アプリ管理部１４１は、登録パラメータの対応付け及び変更条件を登録する（ステップＳ５２２）。

アプリ管理部１４１は、登録結果をアプリ登録部１２２に返す（ステップＳ５２３）。アプリ登録部１２２は、登録結果をＵＩ提供部１２１に返す（ステップＳ５２４）。ＵＩ提供部１２１は、登録結果をブラウザ２１に返す（ステップＳ５２５）。ブラウザ２１は、登録結果を表示する（ステップＳ５２６）。

図２６は、第５の実施形態の分割後のアプリケーションを利用するシーケンス図である。図２６に示すように、デバイス２０は、ユーザからブラウザ２１を介して要求されたアプリ起動要求を取得する（ステップＳ６０１）。デバイス２０は、ブラウザ２１を介して、アプリデータ登録部１３２に、アプリ画面及び設定の取得を要求する（ステップＳ６０２）。

アプリデータ登録部１３２は、参照するアプリＩＤを取得する（ステップＳ６０３）。さらに、アプリデータ登録部１３２は、アプリ設定を取得する（ステップＳ６０４）。そして、アプリデータ登録部１３２は、アプリ画面の情報の取得をアプリ管理部１４１に要求する（ステップＳ６０５）。

アプリ管理部１４１は、アプリの管理情報を取得し（ステップＳ６０６）、アプリの変更及び変更条件をアプリデータ登録部１３２に通知する（ステップＳ６０７）。ここで、アプリデータ登録部１４３は、アプリの設定と変更条件から、新しいアプリのＩＤを計算する（ステップＳ６０８）。

さらに、アプリデータ登録部１３２は、新しいアプリＩＤで、アプリ画面情報の取得を要求する（ステップＳ６０９）。アプリ管理部１４１は、アプリの管理情報を取得し（ステップＳ６１０）、取得したアプリの画面情報をアプリデータ登録部１３２に通知する（ステップＳ６１１）。

アプリデータ登録部１３２は、パラメータの対応付けの取得要求を行う（ステップＳ６１２）。アプリ管理部１４１は、要求によるパラメータの対応付けを取得し（ステップＳ６１３）、取得した対応付けを返す（ステップＳ６１４）。

アプリデータ登録部１３２は、パラメータの対応付けにアプリを対応するように設定値を設定する（ステップＳ６１５）。さらに、アプリデータ登録部１３２は、次回以降のパラメータの対応付けが発生しないようにするため、参照するアプリＩＤを更新する（ステップＳ６１６）。アプリデータ登録部１３２は、アプリ画面及び設定をデバイス２０に返す（ステップＳ６１７）。デバイス２０は、ブラウザ２１を介して、アプリ画面を表示する（ステップＳ６１８）。

図２７は、設定値の対応付けの一例を示す図である。ここで、ポータルサービス部１２が、図２７のようなパラメータの対応付けを与えることで、分割前後でパラメータ「storage.service」の設定値を維持できる。一方、図２８は、設定値を維持しない場合の分割前後のパラメータの一例を示す図である。ポータルサービス部１２は、図２１のようなパラメータの対応付けを与えていない場合、図２８に示すように、分割前後のパラメータ「storage.service」の設定値は維持しない。

このように、１つのアプリケーションを複数のアプリケーションに分割する変更を行った際に、ポータルサービス部１２は、複数のアプリケーションの変更前のパラメータと変更後のパラメータの対応付けの指定を受け付ける。入出力サービス処理部１４は、ポータルサービス部１２によって受け付けた対応付けに応じて、１つのアプリケーションの第１のパラメータのユーザごとの設定値を、複数のアプリケーションのそれぞれの第２のパラメータの設定値として設定する。

第４の実施形態ではアプリケーションの統合について説明し、第５の実施形態ではアプリケーションの分割について説明したが、変更前後のアプリケーションは多対多（many-to-many）であってもよい。図２９は、アプリケーションを多対多で変更する画面の一例を示す図である。この図２９のような画面を利用し、第５の実施形態と同様のシーケンスにより設定値を維持することができる。

図３０は、第１の実施形態の情報処理システムの機能ブロック図である。図３０は、図４で説明した各機能から特定の機能を取り出して機能ブロック図としたものである。

図３０に示すように、対応付け受け付け部１２ａは、アプリケーションを変更すると、アプリケーションの変更前のパラメータと変更後のパラメータの対応付けの指定を、デバイス２０から受け付ける。そして、設定部１３ａは、対応付け受け付け部１２ａによって受け付けた対応付けに応じて、アプリケーションの変更前の第１のパラメータのユーザごとの設定値を、アプリケーションの変更後のパラメータであって、第１のパラメータに対応付けた第２のパラメータの設定値に設定する。

実施形態では、ポータルサービス部１２が対応付け受け付け部として機能する。また、アプリデータ管理部１３が設定部として機能する。また、パラメータ情報１３ｂは、サーバ１０等が備えた所定の記憶領域で保持する。

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

実施例に記載の装置群は、本明細書に開示した実施形態を実施するための複数のコンピューティング環境のうちの１つを示すものにすぎない。このため、サーバ１０は、サーバクラスタ等の複数のコンピューティングデバイスを備えていてもよい。複数のコンピューティングデバイスは、ネットワーク又は共有メモリ等を含む任意のタイプの通信リンクを介して互いに通信し、本明細書に開示した処理を実施する。同様に、デバイス２０は、互いに通信する複数のコンピューティングデバイスを含むことができる。

さらに、サーバ１０及びデバイス２０は、開示した処理ステップ、例えば図１を様々な組み合わせで共有するように構成できる。例えば、所定のユニットによって実行するプロセスは、デバイス２０によって実行できる。同様に、所定のユニットの機能は、デバイス２０によって実行できる。また、サーバ１０とデバイス２０の各要素は、１つのサーバ装置にまとめてもよいし、複数の装置に分けてもよい。

なお、デバイス２０は、通信機能を備えた装置であれば、ＭＦＰ及びＰＣ以外でも。デバイス２０は、例えば、ＰＪ（Projector：プロジェクタ）又はＩＷＢ（Interactive White Board：相互通信が可能な電子式の黒板機能を有する白板）又はデジタルサイネージ等の出力装置又はＨＵＤ（Head Up Display）装置又は産業機械又は撮像装置又は集音装置又は医療機器又はネットワーク家電又は自動車（Connected Car）又はノートＰＣ（Personal Computer）又は携帯電話又はスマートフォン又はタブレット端末又はゲーム機又はＰＤＡ（Personal Digital Assistant）又はデジタルカメラ又はウェアラブルＰＣ又はデスクトップＰＣ等でもよい。

１ 情報処理システム
１０ サーバ
１１ Ｗｅｂサービス処理部
１２ ポータルサービス部
１３ アプリデータ管理部
１４ 入出力サービス処理部
１５ アプリ情報
１６ ポータル画面情報
１７ コンポーネント
１１１ 画面構成部
１１２ アプリ実行部
１２１ ＵＩ提供部
１２２ アプリ登録部
１３１ ＵＩ提供部
１３２ アプリデータ登録部
１４１ アプリ管理部
１４２ 入出力ロジック処理部
１７１ ＯＣＲ
１７２ ファイル変換

特開２０１８－０１４０７９号公報

Claims (10)

1. デバイスとサーバとを備えた情報処理システムであって、
   前記サーバは、
   アプリケーションを変更したときに、前記アプリケーションの変更前のパラメータと変更後のパラメータの対応付けの指定を受け付ける対応付け受け付け部と、
   前記対応付け受け付け部によって受け付けた前記対応付けに応じて、前記アプリケーションの変更前の第１のパラメータのユーザごとの設定値を、前記アプリケーションの変更後のパラメータであって、前記第１のパラメータに対応付けた第２のパラメータの設定値に設定する設定部と、
   を備えた情報処理システム。
2. 前記設定部は、前記対応付け受け付け部によって受け付けた前記対応付けに応じて、前記第１のパラメータの設定値を、前記第１のパラメータと型が一致する前記アプリケーションの変更後のパラメータのうち、前記第１のパラメータとの間でパラメータの名のレーベンシュタイン距離が最小である第２のパラメータの設定値に設定することを特徴とする請求項１に記載の情報処理システム。
3. 各パラメータに対応した画面上のオブジェクトを手動で動かすことにより、前記第１のパラメータと前記第２のパラメータを対応付けることができるＵＩを提供するＵＩ提供部をさらに有することを特徴とする請求項１に記載の情報処理システム。
4. 各パラメータに対応したオブジェクト及び前記オブジェクト間の辺を、オブジェクト間の対応付けのもっともらしさに応じた態様で表示するＵＩを提供するＵＩ提供部をさらに有することを特徴とする請求項１に記載の情報処理システム。
5. 各パラメータに対応したオブジェクトにカーソルをポイントすると、当該カーソルをポイントしたオブジェクトに関する情報を表示するＵＩを提供するＵＩ提供部をさらに有することを特徴とする請求項１に記載の情報処理システム。
6. 前記対応付け受け付け部は、複数のアプリケーションを１つのアプリケーションに統合する変更が行った際に、前記１つのアプリケーションの変更前のパラメータと変更後のパラメータの対応付けの指定を受け付け、
   前記設定部は、前記対応付け受け付け部によって受け付けた前記対応付けに応じて、前記複数のアプリケーションのそれぞれの第１のパラメータのユーザごとの設定値を、前記１つのアプリケーションの第２のパラメータの設定値に設定することを特徴とする請求項１に記載の情報処理システム。
7. 前記対応付け受け付け部は、１つのアプリケーションを複数のアプリケーションに分割する変更を行った際に、前記複数のアプリケーションの変更前のパラメータと変更後のパラメータの対応付けの指定を受け付け、
   前記設定部は、前記対応付け受け付け部によって受け付けた前記対応付けに応じて、前記１つのアプリケーションの第１のパラメータのユーザごとの設定値を、前記複数のアプリケーションのそれぞれの第２のパラメータの設定値に設定することを特徴とする請求項１に記載の情報処理システム。
8. アプリケーションを変更したときに、前記アプリケーションの変更前のパラメータと変更後のパラメータの対応付けの指定を、デバイスから受け付ける対応付け受け付け部と、
   前記対応付け受け付け部によって受け付けた前記対応付けに応じて、前記アプリケーションの変更前の第１のパラメータのユーザごとの設定値を、前記アプリケーションの変更後のパラメータであって、前記第１のパラメータに対応付けた第２のパラメータの設定値に設定する設定部と、
   を備える情報処理装置。
9. 情報処理装置で実行する情報処理方法であって、
   アプリケーションを変更したときに、前記アプリケーションの変更前のパラメータと変更後のパラメータの対応付けの指定を、デバイスから受け付ける対応付け受け付け工程と、
   前記対応付け受け付け工程によって受け付けた前記対応付けに応じて、前記アプリケーションの変更前の第１のパラメータのユーザごとの設定値を、前記アプリケーションの変更後のパラメータであって、前記第１のパラメータに対応付けた第２のパラメータの設定値に設定する設定工程と、
   を含むことを特徴とする情報処理方法。
10. 情報処理装置で実行するプログラムであって、
    アプリケーションを変更したときに、前記アプリケーションの変更前のパラメータと変更後のパラメータの対応付けの指定を、デバイスから受け付ける対応付け受け付けステップと、
    前記対応付け受け付けステップによって受け付けた前記対応付けに応じて、前記アプリケーションの変更前の第１のパラメータのユーザごとの設定値を、前記アプリケーションの変更後のパラメータであって、前記第１のパラメータに対応付けた第２のパラメータの設定値に設定する設定ステップと、
    をコンピュータに実行させるためのプログラム。

Images