JP7157010B2 - ポータル提供システムおよびポータル提供方法 - Google Patents

Description

本発明は、ポータル提供システムおよびポータル提供方法に関するものである。

企業において日々の業務を効率化することはコスト低減につながり、重要である。そこで、ネットワーク環境を介して種々の業務用ツールを手間無く導入し、効率良く利用する形態が増大しつつある。

このようなツール提供に関連する従来技術としては、例えば、コンピュータ－実行可能命令を保存する１つ以上の非一時的コンピュータ－読取可能媒体であって、前記コンピュータ－実行可能命令は、実行されると１つ以上のプロセッサが：エンドユーザの企業運営システムプラットフォーム上で実装される、分散型ツールの仮想市場によって配布される１つ以上のツールを決定する動作（前記企業運営システムプラットフォームは、前記分散型ツールの仮想市場の運営者によって前記エンドユーザに提供される）；前記企業運営システムプラットフォーム上で実装される前記１つ以上のツールによって処理されたり生成されるデータを確認する動作（前記１つ以上のツールは、エンティティの成果を評価するのに用いられるツールを含む）；前記企業運営システムプラットフォーム上で実装される前記１つ以上のツールによって使用されたり提供される機能を決定する動作；および前記企業運営システムプラットフォーム上で実装される前記１つ以上のツールと少なくとも１つの依存関係を有する、前記分散型ツールの仮想市場からの１つ以上の関連づけられたツールの推薦を提供する動作を含む動作を実行させる、１つ以上の非一時的コンピュータ－読取可能媒体（特許文献１参照）などが提案されている。

特表２０１９－５１２８１２号公報

確かに、従来技術のごときツールの提供環境が存在すれば、業務用ツールの導入が従来よりも容易になりやすい。ところが、そうしたツールの提供環境にアクセスし、自社に必要なものを選択的に導入するには、相応の基盤となるシステムが当該企業側にも整備され、安定的に継続運用されている必要がある。また、膨大な数のツールが世の中に存在する中で、自社ニーズに合致し必要なもの、企業規模や業種等にフィットするもの、を導入候補の母集団として予め絞り込む知見も必要になってくる。

一方で、上述のような要件を備えた企業は大企業などに限られるケースが多い。特に地域に存在する中小企業にとっては、ツール導入の必要性は理解しているものの、人員的にも経済的にも大きなハードルが存在した。

他方、そうした中小企業を顧客とする企業（例：地方金融機関）では、業務提携や資金融通などのサービスを通じ、事業の維持、拡大など種々の貢献を図ってきた。ただし、昨今の経済情勢等により、従来型サービスへのニーズ自体が減少気味で、新たなサービスの創出が急務となっている。しかしながら、上述のツールの提供環境を中小企業に提供する知見や運用基盤は保有しておらず、新たなサービスとして採用することも叶わない現状にある。

そこで本発明の目的は、エンドユーザ向けの業務用ツールの提供環境を、当該エンドユーザを顧客とする事業者が手間無く効率的に配信しうるサービス環境を提供する技術を提供することにある。

上記課題を解決する本発明のポータル提供システムは、各企業における顧客とアプリベンダとの間におけるアプリの利用契約の情報、および前記アプリの機能配信を行うアプリベンダの情報を格納する記憶装置と、各企業の顧客向けの専用サイトを各企業向けのサーバ機能を介して配信し、当該顧客が利用するアプリを前記利用契約の情報に基づいて特定し、当該顧客の端末からのリクエストに応じて、前記顧客による利用対象アプリの機能配信元たるアプリベンダを前記アプリベンダの情報で特定し、当該アプリベンダの各アプリの機能配信を担うサーバから前記利用対象アプリの機能配信を受けて前記専用サイトに提供させる演算装置と、を備えるサーバを含むことを特徴とする。

また、本発明のポータル提供方法は、情報処理装置が、記憶装置において、各企業における顧客とアプリベンダとの間におけるアプリの利用契約の情報、および前記アプリの機能配信を行うアプリベンダの情報を格納し、各企業の顧客向けの専用サイトを各企業向けのサーバ機能を介して配信し、当該顧客が利用するアプリを前記利用契約の情報に基づいて特定し、当該顧客の端末からのリクエストに応じて、前記顧客による利用対象アプリの機能配信元たるアプリベンダを前記アプリベンダの情報で特定し、当該アプリベンダの各アプリの機能配信を担うサーバから前記利用対象アプリの機能配信を受けて前記専用サイトに提供させる、ことを特徴とする。

本発明によれば、エンドユーザ向けの業務用ツールの提供環境を、当該エンドユーザを顧客とする事業者が、手間無く効率的に配信しうるサービス環境を提供できる。

本実施形態のポータル提供システムを含むネットワーク構成図である。 本実施形態におけるアプリケーション管理サーバのハードウェア構成例を示す図である。 本実施形態における分析サーバのハードウェア構成例を示す図である。 本実施形態におけるポータル提供サーバのハードウェア構成例を示す図である。 本実施形態の銀行ＤＢのデータ構成例を示す図である。 本実施形態のベンダＤＢのデータ構成例を示す図である。 本実施形態のアプリＤＢのデータ構成例を示す図である。 本実施形態の連携ＤＢのデータ構成例を示す図である。 本実施形態の利用履歴ＤＢのデータ構成例を示す図である。 本実施形態の分析ＤＢのデータ構成例を示す図である。 本実施形態の顧客ＤＢのデータ構成例を示す図である。 本実施形態におけるポータル提供方法のフロー例１を示す図である。 本実施形態におけるポータル提供方法のフロー例２を示す図である。 本実施形態における画面例１を示す図である。 本実施形態におけるポータル提供方法のフロー例３を示す図である。 本実施形態における画面例２を示す図である。 本実施形態におけるポータル提供方法のフロー例４を示す図である。 本実施形態における画面例３を示す図である。 本実施形態におけるポータル提供方法のフロー例５を示す図である。

＜発明の背景＞

地域経済の重要なエンジンとして、長年に亘り各地域の金融機関が活躍している。そうした金融機関は、主として地元企業に対する資金融通を通じて、地域経済の拡大や雇用創出など幅広い貢献を行ってきた。

しかしながら、人口減少や国内外における経済成長の鈍化、低金利の長期化は、企業レベルにおける慎重な経営マインドや厚い手元流動性に結びつき、地域金融機関が資金融通によって地元企業の役に立つことを困難にしている。

このことは、地域金融機関が貸出以外のビジネスを通じて地元企業に貢献する必要を示唆している。一方、地元企業が求める貸出以外のサービスとは、例えばコスト削減に結びつくサービスが該当する。売上の拡大が期待できぬ環境下では、まずは、多大なコストをかけて行っている日常的なオペレーションの効率化に大きなニーズがある。従来では、そうした双方のニーズを満たすサービスは存在していない。一方、本実施形態のポータル提供システムを適用することで、上述の各ニーズを満たし、ひいては、金融機関の顧客向けの業務用ツールの提供環境を、当該金融機関が手間無く効率的に提供しうるサービス環境を確立できる。
＜システム構成＞

以下に本発明の実施形態について図面を用いて詳細に説明する。図１は、本実施形態のポータル提供システム１０を含むネットワーク構成図である。図１に示すポータル提供システム１０は、エンドユーザ向けの業務用ツールの提供環境を、当該エンドユーザを顧客とする事業者が、手間無く効率的に配信しうるサービス環境を提供できるコンピュータシステムである。

図１で例示するネットワーク構成に限定はしないが、一例としてあげるならば、ポータル提供システム１０を中心に、インターネットなどの適宜なネットワーク１を介して、金融機関の顧客である企業Ｘ～Ｚの各端末４００、および当該企業らに業務用ツールとしてのアプリの機能配信を担うアプリ機能配信サーバ３００が接続されている。

一方、ポータル提供システム１０は、物理的か論理的かは問わないものの、アプリ管理サーバ１００、ポータル提供サーバ１５０、および分析サーバ２００、という３つのサーバから構成されている。これらポータル提供システム１０を構成する各サーバの詳細については後述する。
＜ハードウェア構成＞

また、本実施形態のポータル提供システム１０を構成する各装置のうち、例えば、アプリケーション管理サーバ１００のハードウェア構成は図２に示す如くとなる。

すなわちアプリケーション管理サーバ１００は、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）やハードディスクドライブなど適宜な不揮発性記憶素子で構成される記憶装置１０１、ＲＡＭなど揮発性記憶素子で構成されるメモリ１０３、記憶装置１０１に保持されるプログラム１０２をメモリ１０３に読み出すなどして実行し装置自体の統括制御を行なうとともに各種判定、演算及び制御処理を行なうＣＰＵなどの演算装置１０４、ネットワーク１と接続し他装置との通信処理を担う通信装置１０５、を備える。

なお、記憶装置１０１内には、本実施形態のポータル提供システム１０を構成するサーバ装置として必要な機能を実装する為のプログラム１０２に加えて、銀行ＤＢ１２５、ベ
ンダＤＢ１２６、アプリＤＢ１２７、および連携ＤＢ１２８が少なくとも記憶されている。これらデータベースの詳細は後述する。

また、本実施形態の分析サーバ２００のハードウェア構成は、図３に示す如くとなる。すなわち分析サーバ２００は、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）やハードディスクドライブなど適宜な不揮発性記憶素子で構成される記憶装置２０１、ＲＡＭなど揮発性記憶素子で構成されるメモリ２０３、記憶装置２０１に保持されるプログラム２０２をメモリ２０３に読み出すなどして実行し装置自体の統括制御を行なうとともに各種判定、演算及び制御処理を行なうＣＰＵなどの演算装置２０４、ネットワーク１と接続し他装置との通信処理を担う通信装置２０５、を備える。

なお、記憶装置２０１内には、本実施形態のポータル提供システム１０を構成するサーバ装置として必要な機能を実装する為のプログラム２０２に加えて、利用履歴ＤＢ２２５、および分析ＤＢ２２６が少なくとも記憶されている。これらデータベースの詳細は後述する。

また、本実施形態のポータル提供サーバ１５０のハードウェア構成は、図４に示す如くとなる。すなわちポータル提供サーバ１５０は、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）やハードディスクドライブなど適宜な不揮発性記憶素子で構成される記憶装置１５１、ＲＡＭなど揮発性記憶素子で構成されるメモリ１５３、記憶装置１５１に保持されるプログラム１５２をメモリ１５３に読み出すなどして実行し装置自体の統括制御を行なうとともに各種判定、演算及び制御処理を行なうＣＰＵなどの演算装置１５４、ネットワーク１と接続し他装置との通信処理を担う通信装置１５５、を備える。

なお、記憶装置１５１内には、本実施形態のポータル提供システム１０を構成するサーバ装置として必要な機能を実装する為のプログラム１５２に加えて、顧客ＤＢ１５６が少なくとも記憶されている。この顧客ＤＢ１５６の詳細は後述する。
＜データ構造例＞

続いて、本実施形態のポータル提供システム１０にて用いるデータベース類について説明する。図５に、本実施形態における銀行ＤＢ１２５の一例を示す。銀行ＤＢ１２５は、ポータル提供システム１０の運営者とポータル提供サービスの契約を結んでいる金融機関の各情報を蓄積したデータベースである。

そのデータ構造は、各金融機関を一意に識別するＩＤをキーとして、当該金融機関の名称、所在、顧客（企業Ｘ～Ｚ）、顧客ボリュームゾーン、および提供中アプリといったデータから成るレコードの集合体である。

このうち顧客ボリュームゾーンは、当該金融機関における顧客のうち多数を占める顧客グループの業種と規模について規定した値である。図５の例では、金融機関「Ａ」の顧客について「建設業」、「規模Ａ」といった値が設定されている。

また、図６に本実施形態のベンダＤＢ１２６のデータ構成例を示す。ベンダＤＢ１２６は、ポータル提供システム１０を介して、上述の金融機関の顧客に対してアプリ機能配信を行う各アプリベンダの情報を蓄積したデータベースである。

そのデータ構造は、アプリベンダを一意に識別するＩＤをキーとして、当該アプリベンダの名称、所在、アプリ、および利用者といったデータからなるレコードの集合体である。この「利用者」は、上述の銀行ＤＢ１２５で情報が格納されている金融機関を指している。

また、図７に本実施形態のアプリＤＢ１２７のデータ構成例を示す。アプリＤＢ１２７は、金融機関の顧客に対して機能配信される各アプリの情報を蓄積したデータベースである。
そのデータ構造は、アプリを一意に識別するＩＤをキーとして、当該アプリの名称、ベンダ、利用者、利用料といったデータからなるレコードの集合体である。

また、図８に本実施形態の連携ＤＢ１２８のデータ構成例を示す。連携ＤＢ１２８は、各アプリに関して、他アプリとの連携可否に関して規定する情報を蓄積したデータベースである。

そのデータ構造は、アプリを一意に識別するＩＤをキーとして、当該アプリの連携形態がＡＰＩかバッチのいずれの形式かを示す値、そのインターフェイス、利用料（例えば、１トランザクションあたり）、および連携許可アプリといったデータからなるレコードの集合体である。

また、図９に本実施形態の利用履歴ＤＢ２２５のデータ構成例を示す。利用履歴ＤＢ２２５は、例えば、金融機関の各顧客におけるアプリの利用履歴を蓄積したデータベースである。そのデータ構造は、当該顧客を一意に識別するＩＤをキーとして、当該顧客が利用したアプリ、利用日時、および連携処理の有無、連携先、連携料金、といったデータからなるレコードの集合体である。この連携処理の有無、連携先、連携料金は、当該アプリが他アプリとのアプリ連携やデータ連携を行ったか否か、およびその際に発生した連携料金を示す値となる。

また、図１０は本実施形態の分析ＤＢ２２６のデータ構成例を示す。分析ＤＢ２２６は、分析サーバ２００が実行した分析結果を蓄積したデータベースである。そのデータ構造は、分析対象となったアプリを一意に識別するＩＤをキーとして、顧客の属性である地域、業種、および規模と、当該属性の顧客グループにおいて最も利用されたアプリと、それらの利用頻度、データ量、および最も連携されたアプリ、といったデータからなるレコードの集合体である。

また、図１１は本実施形態の顧客ＤＢ１５６のデータ構成例を示す。顧客ＤＢ１５６は、ポータル提供サーバ１５０が、金融機関の立場において専用サイトを提供する顧客（金融機関の顧客である企業Ｘ～Ｚ）の情報を蓄積したデータベースである。

そのデータ構造は、当該顧客を一意に識別するＩＤをキーとして、当該顧客の名称、所在、業種・規模、その顧客の従業員でアプリを実際に操作する利用者、当該利用者が利用中のアプリ、および利用料といったデータからなるレコードの集合体である。
＜フロー例１＞

以下、本実施形態におけるポータル提供方法の実際手順について図に基づき説明する。以下で説明するポータル提供方法に対応する各種動作は、ポータル提供システム１０を構成する各サーバらがメモリ等に読み出して実行するプログラムによって実現される。そして、このプログラムは、以下に説明される各種の動作を行うためのコードから構成されている。

図１２は、本実施形態におけるポータル提供方法のフロー例１を示す図である。ここでは、例えば、あるアプリベンダが自社のアプリを、ポータル提供システム１０が提供するアプリの提供環境に登録しようと考えた状況を想定する。この「登録」は、未登録のアプリを、各金融機関の顧客が利用しうるようアプリＤＢ１２７や連携ＤＢ１２８に情報を登
録する場合や、ＡＰＩやバッチによるアプリ連携、データ連携を図りたい場合など種々の意味を含みうる。

そこでアプリ管理サーバ１００は、上述のアプリベンダが操作する所定の端末（図１２では“ベンダ端末”と称し、ネットワーク１に接続可能な端末である）から、アプリ登録要求を受信し、判定画面５０を返信する（ｓ１～ｓ２）。

そこで上述のベンダの担当者は、ベンダ端末で判定画面５０を閲覧し、自身の意図に沿った選択肢を指定する。ベンダ端末はこの指定を受け、回答としてアプリ管理サーバ１００に返信する（ｓ３）。

一方、上述の回答を取得し、当該アプリベンダの状況すなわち意図を判定する（ｓ４）。判定の結果、当該アプリベンダの意図が、他アプリベンダによる公開中アプリと自アプリとの連携を図るための要求であった場合（ｓ４：連携希望）、アプリ管理サーバ１００は、連携ＤＢ１２８を参照して、連携ＤＢ１２８に情報が含まれる各アプリのリスト（連携を既に受け入れているアプリのリスト）を、連携候補として返信する（ｓ５）。

ベンダ端末では、アプリベンダの担当者が上述の連携候補中から選択した連携希望対象のアプリの情報を、アプリ管理サーバ１００に返す。アプリ管理サーバ１００は、この情報を得て、当該情報が示す連携希望対象のアプリのアプリベンダの所定装置に対し、連携希望があった旨を通知し、その受諾可否に関する回答を取得する。また、この回答が連携可というものであれば、連携ＤＢ１２８における該当レコードの許可アプリの欄に、上述の自アプリのＩＤをセットし（ｓ６）、処理を終了する。

一方、上述の判定の結果、当該アプリベンダの意図が、対象アプリを金融機関の顧客向けに公開するための要求であった場合（ｓ４：公開希望）、アプリ管理サーバ１００は、公開用処理として、その対象アプリの情報を、アプリＤＢ１２７に登録し（ｓ７）、処理を終了する。この時、対象アプリが他アプリとの連携を許可するものであれば、その情報を連携ＤＢ１２８に登録する。

また、上述の判定の結果、当該アプリベンダの意図が、対象アプリを他アプリとの連携対象として公開するための要求であった場合（ｓ４：連携登録希望）、アプリ管理サーバ１００は、審査・登録処理として、例えば、ポータル提供システム１０の運営者やアプリベンダによる審査フローに、当該アプリの情報をセットし、その審査を経た上で、当該アプリの情報を連携ＤＢ１２８に登録し（ｓ８）、処理を終了する。
＜フロー例２＞

続いて、本実施形態のポータル提供システム１０による、各金融機関の顧客に対する専用サイトすなわち「Ｍｙｐａｇｅ」の、当該金融機関名義での配信と、そこでの操作に応じたアプリ機能配信に伴う処理について説明する。図１３は、本実施形態のポータル提供方法のフロー例２を示す図である。

この場合、或る金融機関の顧客である企業において、所定の担当者が企業端末４００を操作しログイン操作を行ったとする。企業端末４００では、その操作を受け付け、操作内容を含む認証要求をポータル提供サーバ１５０に送信する（ｓ１０）。

一方、ポータル提供サーバ１５０は、認証要求に応じて顧客ＤＢ１５６に基づく所定の認証処理を実行し、当該企業に関して契約中のアプリに関する配信要求をアプリ管理サーバ１００に送る（ｓ１１）。

アプリ管理サーバ１００は、配信要求を受信し、この配信要求が含む当該企業のＩＤをキーに、アプリＤＢ１２７で当該企業のＩＤが「利用者」欄に設定中のアプリを特定し、これをポータル提供サーバ１５０に通知する（ｓ１２）。

ポータル提供サーバ１５０は、上述の通知を受けて、予め保持するＭｙｐａｇｅのフォーマットに、当該企業の情報（顧客ＤＢ１５６で抽出）と、上述の通知が示すアプリのアイコン（予め記憶装置で保持するか、アプリ管理サーバ１００から配信を受けたもの）を配置して、Ｍｙｐａｇｅの表示データを生成し、これを上述の企業端末４００に配信する（ｓ１３）。

企業端末４００では、この表示データを受信して、図１４の画面１０００のごとく、ディスプレイ等で表示させる（ｓ１４）。また、企業端末４００は、Ｍｙｐａｇｅ内で、担当者によるアプリの選択指示を受け（ｓ１５）、その内容をポータル提供サーバ１５０に通知する。

ポータル提供サーバ１５０は、当該内容が示すアプリについての起動要求をアプリ管理サーバ１００に通知する（ｓ１６）。一方、アプリ管理サーバ１００は、上述の起動要求をアプリ機能配信サーバ３００に転送する（ｓ１７）。

アプリ機能配信サーバ３００は、当該アプリの機能配信（例：ＳａａＳ等の技術を適宜採用したもの）を実行する（ｓ１８）。この機能配信は、例えば、アプリ管理サーバ１００からポータル提供サーバ１５０を経由して（ｓ１９、ｓ２０）、上述の企業端末４００に行われる。この時、企業端末４００を操作する担当者は、あくまでも金融機関から提供されたＭｙｐａｇｅで所望のアプリを操作しているとの認識でいる。
続いて、企業端末４００は、上述の担当者によるアプリの操作を受け付けて、その内容をポータル提供サーバ１５０に送信する（ｓ２１）。

ポータル提供サーバ１５０では、上述の操作の内容を企業端末４００から受信し、これをアプリ管理サーバ１００に転送する（ｓ２２）。アプリ管理サーバ１００は、この操作内容をさらにアプリ機能配信サーバ４００に転送する（ｓ２３）。

一方、アプリ機能配信サーバ４００は、アプリ管理サーバ１００から転送されてきた操作内容を引数として、該当アプリに与えることで、処理結果を生成し、これをアプリ管理サーバ１００およびポータル提供サーバ１５０を経由して、Ｍｙｐａｇｅでの表示という形で企業端末４００に返信する（ｓ２４、ｓ２６、ｓ２８）。

この時、アプリ機能配信サーバ４００は、上述の企業（の担当者）による当該アプリの利用状況を、適宜な記憶装置に格納するとしてもよい。このことは、アプリ管理サーバ１００でも同様であり、分析サーバ２００に対して、上述の利用状況の情報を利用履歴ＤＢ２２５に格納させる。
企業端末４００では、上述のアプリでの処理結果をＭｙｐａｇｅにて受信し、ディスプレイ上で表示させ（ｓ２９）、処理を終了する。
＜フロー例３＞
続いて、分析サーバ２００における分析処理について説明する。図１５は、本実施形態のポータル提供方法のフロー例３を示す図である。

この場合、分析サーバ２００は、例えば、ある金融機関と取り決めたスケジュールに応じて、或いは、データ分析結果を所望する所定の事業者からのリクエストに応じて、利用履歴ＤＢ２２５を参照し、企業の属性情報と当該企業の利用履歴の情報を抽出する（ｓ３０）。

また、分析サーバ２００は、ｓ３０で得た情報に基づき、企業属性に応じたアプリの利用傾向について分析する（ｓ３１）。この分析は、例えば、地域、業種、規模といった属性が共通する企業群において、契約ないし利用が所定基準より多いアプリを特定するといった処理であり、一般的な統計処理を実行すればよい。

続いて、分析サーバ２００は、ｓ３１での分析の結果を、上述の金融機関の所定端末か、或いは上述のリクエストを行ってきた所定事業者の端末に対し配信し（ｓ３２）、処理を終了する。ここで配信する情報は、例えば、属性が共通する顧客グループにおいて契約ないし利用が所定基準より多いアプリの利用や契約を推奨する情報１１０２（図１６の画面１１００）、を想定できる。ここでは、最も利用されたアプリすなわち推奨しうるアプリの情報の他、最も利用されなかったアプリすなわち利用を推奨できないアプリの情報１１０１も提示する形態も想定できる。その際、利用頻度やデータ量といった事象について、レベル感を星印の数（多いほど高頻度、大データ量）で表示するといった制御を行うことも好適である。
＜フロー例４＞

続いて、アプリ連携の処理について説明する。図１７は、本実施形態のポータル提供方法のフロー例４を示す図である。この場合、企業端末４００は、Ｍｙｐａｇｅにて担当者によるアプリ操作を受け付けて、その内容を例えばポータル提供サーバ１５０、アプリ管理サーバ１００を経由して、アプリ機能配信サーバ４００に通知する（ｓ４０）。ここでは、「アプリ１」が連携元で、「アプリ２」が連携先であったとする。
「アプリ１」の機能配信を担うアプリ機能配信サーバ４００は、上述の通知を受けて、アプリ管理サーバ１００にアプリ間連携を要求する（ｓ４１、ｓ４２）。

一方、アプリ管理サーバ１００は、連携ＤＢ１２８を参照し、上述の「アプリ２」の許可アプリとして「アプリ１」が設定されているかチェックすることで、連携可否を判定する（ｓ４３）。

上述の判定の結果、連携不可であった場合（ｓ４４：Ｎ）、アプリ管理サーバ１００は、エラー通知を「アプリ１」のアプリ機能配信サーバ４００に行う（ｓ４５）。この場合、アプリ機能配信サーバ４００は、エラー通知を受けて、「アプリ２」との連携ができない状態での所定処理を実行し（ｓ４６）、これを処理結果として企業端末４００に返す。

一方、上述の判定の結果、連携可であった場合（ｓ４４：Ｙ）、アプリ管理サーバ１００は、「アプリ２」のアプリ機能配信サーバ４００に対して、「アプリ２」の呼び出し処理を実行する（ｓ４７）。「アプリ２」のアプリ機能配信サーバ４００は、これに応答して所定の処理（操作内容が含む所定値を引数として処理実行）を行い、処理結果を返す（ｓ４８）。

アプリ管理サーバ１００は、この処理結果を「アプリ１」のアプリ機能配信サーバ４００に提供する（ｓ４９）。この場合のアプリ機能配信サーバ４００は、「アプリ２」での処理結果を引数の１つとして処理を実行し、処理結果を生成し（ｓ４６）、これを企業端末４００に返す。

企業端末４００では、「アプリ１」での処理結果を取得して、図１８の画面１２００のごとく表示し（ｓ５０）、処理を終了する。この画面１２００では、処理結果とその連携ステータスの各情報１２０１を表示させている。図１８の例では、連携に成功した状態を示す。

＜フロー例５＞

続いて、データ連携について説明する。図１９は、本実施形態のポータル提供方法のフロー例５を示す図である。ここでは、アプリ間でのデータ連携について説明する。この場合、例えば、「アプリ２」のアプリ機能配信サーバ４００が、一定時間で処理した処理結果を事前連携要求としてアプリ管理サーバ１００に送信したとする（ｓ６０）。一方、アプリ管理サーバ１００は、これを受信して記憶装置１０１に格納する（ｓ６１）。

またその後、「アプリ１」のアプリ機能配信サーバ４００が、上述の「アプリ２」とのデータ連携要求を、アプリ管理サーバ１００に通知してきたとする（ｓ６２）。

この場合、アプリ管理サーバ１００は、「アプリ１」と「アプリ２」との連携について、上述の図１７のフローでの連携可否の判定と同様に判定し（ｓ６３）、その結果が連携不可である場合（ｓ６４：Ｎ）、エラー通知を「アプリ１」のアプリ機能配信サーバ４００に行う（ｓ６５）。その場合、「アプリ１」のアプリ機能配信サーバ４００は、連携できなかった際の所定処理を実行し（ｓ６６）、処理を終了する。

他方、上述の判定の結果、連携可である場合（ｓ６４：Ｙ）、ｓ６１で格納済みの「アプリ２」での処理結果を「アプリ１」のアプリ機能配信サーバ４００に提供する（ｓ６７）。
その場合、「アプリ１」のアプリ機能配信サーバ４００は、提供された処理結果を引数とした所定処理を実行し（ｓ６６）、処理を終了する。

以上、本発明を実施するための最良の形態などについて具体的に説明したが、本発明はこれに限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能である。

こうした本実施形態によれば、エンドユーザ向けの業務用ツールの提供環境を、当該エンドユーザを顧客とする事業者が、手間無く効率的に配信しうるサービス環境が提供できる。

本明細書の記載により、少なくとも次のことが明らかにされる。すなわち、本実施形態のポータル提供システムにおいて、前記演算装置は、前記専用サイトを介して、当該専用サイトを利用する顧客からのアプリの契約要求を受信し、当該契約要求に応じて、前記記憶装置のアプリベンダの情報に基づき、該当アプリのアプリベンダを特定し、当該アプリベンダとの利用契約に関する所定の仲介処理と、当該仲介処理により締結された契約内容の情報を、前記記憶装置の利用契約の情報として格納する処理とを更に実行するものである、としてもよい。

これによれば、各企業が、その顧客とアプリベンダとの間でのアプリの利用契約を仲介する形でサービス提供が可能となる。顧客からすれば、当該企業が利用契約の支援を行っているかのごとく受け取る一方、当該企業としてはそうした機能自体を、ポータル提供システムを介して提供しているため、管理、運営の手間やコストも抑制した形で新サービスの展開が可能となる。

また、本実施形態のポータル提供システムにおいて、前記記憶装置は、前記各企業における顧客の属性情報、および当該顧客による前記アプリの利用履歴の情報を更に格納しており、前記演算装置は、前記顧客の属性情報と当該顧客の前記利用履歴の情報とに基づき、顧客属性に応じたアプリの利用傾向について分析し、当該分析の結果を所定装置に配信する処理を更に実行するものである、としてもよい。

これによれば、例えば、同地域の同業種の事業者（本発明での“顧客”）らで良く利用されているアプリを、当該属性を備えた事業者らに対して推奨し、利用を促すことが可能となる。一方、そうした推奨を受ける事業者らは、膨大な数のアプリ中から自身にフィットするものを探索する手間が大幅に低減可能であり、業務効率も更に改善する。同様に、同地域の同業種の事業者らで敬遠されている、或いは全く利用されていない特異なアプリの利用解除を、当該属性を備えた事業者らに対して推奨することも可能である。そうした推奨を受ける事業者らは、自身が利用中のアプリ中から実は自身にフィットしないものを的確に判断・特定する手間が大幅に低減可能であり、業務効率も更に改善する。

また、本実施形態のポータル提供システムにおいて、前記演算装置は、前記分析の結果として、属性が共通する顧客グループにおいて契約ないし利用が所定基準より多いアプリの推奨情報を、所定装置に配信するものである、としてもよい。

これによれば、例えば、同地域の同業種の事業者（本発明での“顧客”）らで特に良く利用されている標準的なアプリを、当該属性を備えた事業者らに対して推奨し、利用を明示的に促すことが可能となる。一方、そうした推奨を受ける事業者らは、膨大な数のアプリ中から自身に特にフィットするものを探索する手間が大幅に低減可能であり、業務効率もより一層改善しやすい。

また、本実施形態のポータル提供システムにおいて、前記記憶装置は、各アプリにおける他アプリとの連携可否に関する情報を更に格納しており、前記演算装置は、所定企業の装置による、前記専用サイトを介した所定アプリに対する処理要求を受け、当該処理要求の示す処理が、前記所定アプリと他アプリとの連携処理を含む場合、前記所定アプリと前記他アプリとの間に関して、前記連携可否に関する情報に基づいて連携可否を判定する処理と、前記判定の結果、連携可能である場合、前記他アプリの機能配信を担うサーバに対して、前記処理要求の示す引数を含む呼び出しを実行し、前記呼び出しで得た前記他アプリでの処理結果を前記所定アプリの機能配信を担うサーバに提供し、前記所定アプリに前記処理要求に応じた処理を実行させる処理と、を更に実行するものである、としてもよい。
これによれば、アプリの利用契約とその連携可否に基づいて、アプリ間連携を効率的に図ることが可能となる。

また、本実施形態のポータル提供システムにおいて、前記記憶装置は、各アプリにおける他アプリとの連携可否に関する情報を更に格納しており、前記演算装置は、所定アプリの機能配信を担うサーバによる、当該アプリでの処理データの登録要求を受けて、当該処理データを記憶装置に格納する処理と、所定企業の装置による、前記処理データを用いた他アプリとの連携処理の要求を受けた場合、前記所定アプリと前記他アプリとの間に関して、前記連携可否に関する情報に基づいて連携可否を判定する処理と、前記判定の結果、連携可能である場合、前記他アプリの機能配信を担うサーバに対して、前記処理データを配信し、前記他アプリに前記処理データを用いた処理を実行させる処理を更に実行するものである、としてもよい。
これによれば、アプリの利用契約とその連携可否に基づいて、アプリ間のデータ連携を効率的に図ることが可能となる。

また、本実施形態のポータル提供システムにおいて、前記演算装置は、所定のアプリベンダの装置から所定の要求を受けた場合、前記アプリベンダの装置に対し、対象アプリを所定企業の顧客向けに公開するための要求、対象アプリを他アプリとの連携対象として公開するための要求、および他アプリベンダによる公開中アプリと自アプリとの連携を図るための要求、のいずれの要求に該当するか確認するインターフェイスを表示させ、当該イ
ンターフェイスでの回答結果に応じて、予め定めた所定の支援処理を更に実行するものである、としてもよい。

これによれば、アプリを公開し、連携対象としたいといった各種のアプリベンダ（本発明の“企業”が該当する場合も含みうる）の意向を踏まえて、その公開や連携の設定について効率的な処理を支援することが可能となる。

また、本実施形態のポータル提供方法において、前記情報処理装置が、前記専用サイトを介して、当該専用サイトを利用する顧客からのアプリの契約要求を受信し、当該契約要求に応じて、前記記憶装置のアプリベンダの情報に基づき、該当アプリのアプリベンダを特定し、当該アプリベンダとの利用契約に関する所定の仲介処理と、当該仲介処理により締結された契約内容の情報を、前記記憶装置の利用契約の情報として格納する処理とを更に実行する、としてもよい。

また、本実施形態のポータル提供方法において、前記情報処理装置が、前記記憶装置において、前記各企業における顧客の属性情報、および当該顧客による前記アプリの利用履歴の情報を更に格納し、前記顧客の属性情報と当該顧客の前記利用履歴の情報とに基づき、顧客属性に応じたアプリの利用傾向について分析し、当該分析の結果を所定装置に配信する処理を更に実行する、としてもよい。

また、本実施形態のポータル提供方法において、前記情報処理装置が、前記分析の結果として、属性が共通する顧客グループにおいて契約ないし利用が所定基準より多いアプリの推奨情報を、所定装置に配信する、としてもよい。

また、本実施形態のポータル提供方法において、前記情報処理装置が、前記記憶装置において、各アプリにおける他アプリとの連携可否に関する情報を更に格納し、所定企業の装置による、前記専用サイトを介した所定アプリに対する処理要求を受け、当該処理要求の示す処理が、前記所定アプリと他アプリとの連携処理を含む場合、前記所定アプリと前記他アプリとの間に関して、前記連携可否に関する情報に基づいて連携可否を判定する処理と、前記判定の結果、連携可能である場合、前記他アプリの機能配信を担うサーバに対して、前記処理要求の示す引数を含む呼び出しを実行し、前記呼び出しで得た前記他アプリでの処理結果を前記所定アプリの機能配信を担うサーバに提供し、前記所定アプリに前記処理要求に応じた処理を実行させる処理と、を更に実行する、としてもよい。

また、本実施形態のポータル提供方法において、前記情報処理装置が、前記記憶装置において、各アプリにおける他アプリとの連携可否に関する情報を更に格納し、所定アプリの機能配信を担うサーバによる、当該アプリでの処理データの登録要求を受けて、当該処理データを記憶装置に格納する処理と、所定企業の装置による、前記処理データを用いた他アプリとの連携処理の要求を受けた場合、前記所定アプリと前記他アプリとの間に関して、前記連携可否に関する情報に基づいて連携可否を判定する処理と、前記判定の結果、連携可能である場合、前記他アプリの機能配信を担うサーバに対して、前記処理データを配信し、前記他アプリに前記処理データを用いた処理を実行させる処理を更に実行する、としてもよい。

また、本実施形態のポータル提供方法において、前記情報処理装置が、所定のアプリベンダの装置から所定の要求を受けた場合、前記アプリベンダの装置に対し、対象アプリを所定企業の顧客向けに公開するための要求、対象アプリを他アプリとの連携対象として公開するための要求、および他アプリベンダによる公開中アプリと自アプリとの連携を図るための要求、のいずれの要求に該当するか確認するインターフェイスを表示させ、当該インターフェイスでの回答結果に応じて、予め定めた所定の支援処理を更に実行する、とし
てもよい。

１ ネットワーク
１０ ポータル提供システム
１００ アプリケーション管理サーバ
１０１ 記憶装置
１０２ プログラム
１０３ メモリ
１０４ 演算装置
１０５ 通信装置
１２５ 銀行ＤＢ
１２６ ベンダＤＢ
１２７ アプリＤＢ
１２８ 連携ＤＢ
１５０ ポータル提供サーバ
１５１ 記憶装置
１５２ プログラム
１５３ メモリ
１５４ 演算装置
１５５ 通信装置
１５６ 顧客ＤＢ
２００ 分析サーバ
２０１ 記憶装置
２０２ プログラム
２０３ メモリ
２０４ 演算装置
２０５ 通信装置
２２５ 利用履歴ＤＢ
２２６ 分析ＤＢ
３００ アプリ機能配信サーバ
４００ 企業端末

Claims (12)

1. 各企業における顧客とアプリベンダとの間におけるアプリの利用契約の情報、および前記アプリの機能配信を行うアプリベンダの情報を格納する記憶装置と、
   各企業の顧客向けの専用サイトを各企業向けのサーバ機能を介して配信し、当該顧客が利用するアプリを前記利用契約の情報に基づいて特定し、当該顧客の端末からのリクエストに応じて、前記顧客による利用対象アプリの機能配信元たるアプリベンダを前記アプリベンダの情報で特定し、当該アプリベンダの各アプリの機能配信を担うサーバから前記利用対象アプリの機能配信を受けて前記専用サイトに提供させる演算装置と、
   を備えるサーバを含むことを特徴とするポータル提供システム。
2. 前記記憶装置は、
   前記各企業における顧客の属性情報、および当該顧客による前記アプリの利用履歴の情報を更に格納しており、
   前記演算装置は、
   前記顧客の属性情報と当該顧客の前記利用履歴の情報とに基づき、顧客属性に応じたアプリの利用傾向について分析し、当該分析の結果を所定装置に配信する処理を更に実行するものである、
   ことを特徴とする請求項１に記載のポータル提供システム。
3. 前記演算装置は、
   前記分析の結果として、属性が共通する顧客グループにおいて契約ないし利用が所定基準より多いアプリの推奨情報を、所定装置に配信するものである、
   ことを特徴とする請求項２に記載のポータル提供システム。
4. 前記記憶装置は、
   各アプリにおける他アプリとの連携可否に関する情報を更に格納しており、
   前記演算装置は、
   所定企業の装置による、前記専用サイトを介した所定アプリに対する処理要求を受け、当該処理要求の示す処理が、前記所定アプリと他アプリとの連携処理を含む場合、前記所定アプリと前記他アプリとの間に関して、前記連携可否に関する情報に基づいて連携可否を判定する処理と、前記判定の結果、連携可能である場合、前記他アプリの機能配信を担うサーバに対して、前記処理要求の示す引数を含む呼び出しを実行し、前記呼び出しで得た前記他アプリでの処理結果を前記所定アプリの機能配信を担うサーバに提供し、前記所定アプリに前記処理要求に応じた処理を実行させる処理と、を更に実行するものである、
   ことを特徴とする請求項１に記載のポータル提供システム。
5. 前記記憶装置は、
   各アプリにおける他アプリとの連携可否に関する情報を更に格納しており、
   前記演算装置は、
   所定アプリの機能配信を担うサーバによる、当該アプリでの処理データの登録要求を受けて、当該処理データを記憶装置に格納する処理と、所定企業の装置による、前記処理データを用いた他アプリとの連携処理の要求を受けた場合、前記所定アプリと前記他アプリとの間に関して、前記連携可否に関する情報に基づいて連携可否を判定する処理と、前記判定の結果、連携可能である場合、前記他アプリの機能配信を担うサーバに対して、前記処理データを配信し、前記他アプリに前記処理データを用いた処理を実行させる処理を更に実行するものである、
   ことを特徴とする請求項１に記載のポータル提供システム。
6. 前記演算装置は、
   所定のアプリベンダの装置から所定の要求を受けた場合、前記アプリベンダの装置に対し、対象アプリを所定企業の顧客向けに公開するための要求、対象アプリを他アプリとの連携対象として公開するための要求、および他アプリベンダによる公開中アプリと自アプリとの連携を図るための要求、のいずれの要求に該当するか確認するインターフェイスを表示させ、当該インターフェイスでの回答結果に応じて、予め定めた所定の支援処理を更に実行するものである、
   ことを特徴とする請求項１に記載のポータル提供システム。
7. 情報処理装置が、
   記憶装置において、各企業における顧客とアプリベンダとの間におけるアプリの利用契約の情報、および前記アプリの機能配信を行うアプリベンダの情報を格納し、
   各企業の顧客向けの専用サイトを各企業向けのサーバ機能を介して配信し、当該顧客が利用するアプリを前記利用契約の情報に基づいて特定し、当該顧客の端末からのリクエストに応じて、前記顧客による利用対象アプリの機能配信元たるアプリベンダを前記アプリベンダの情報で特定し、当該アプリベンダの各アプリの機能配信を担うサーバから前記利用対象アプリの機能配信を受けて前記専用サイトに提供させる、
   ことを特徴とするポータル提供方法。
8. 前記情報処理装置が、
   前記記憶装置において、前記各企業における顧客の属性情報、および当該顧客による前記アプリの利用履歴の情報を更に格納し、
   前記顧客の属性情報と当該顧客の前記利用履歴の情報とに基づき、顧客属性に応じたアプリの利用傾向について分析し、当該分析の結果を所定装置に配信する処理を更に実行する、
   ことを特徴とする請求項７に記載のポータル提供方法。
9. 前記情報処理装置が、
   前記分析の結果として、属性が共通する顧客グループにおいて契約ないし利用が所定基準より多いアプリの推奨情報を、所定装置に配信する、
   ことを特徴とする請求項８に記載のポータル提供方法。
10. 前記情報処理装置が、
    前記記憶装置において、各アプリにおける他アプリとの連携可否に関する情報を更に格納し、
    所定企業の装置による、前記専用サイトを介した所定アプリに対する処理要求を受け、当該処理要求の示す処理が、前記所定アプリと他アプリとの連携処理を含む場合、前記所定アプリと前記他アプリとの間に関して、前記連携可否に関する情報に基づいて連携可否を判定する処理と、前記判定の結果、連携可能である場合、前記他アプリの機能配信を担うサーバに対して、前記処理要求の示す引数を含む呼び出しを実行し、前記呼び出しで得た前記他アプリでの処理結果を前記所定アプリの機能配信を担うサーバに提供し、前記所定アプリに前記処理要求に応じた処理を実行させる処理と、を更に実行する、
    ことを特徴とする請求項７に記載のポータル提供方法。
11. 前記情報処理装置が、
    前記記憶装置において、各アプリにおける他アプリとの連携可否に関する情報を更に格納し、
    所定アプリの機能配信を担うサーバによる、当該アプリでの処理データの登録要求を受けて、当該処理データを記憶装置に格納する処理と、所定企業の装置による、前記処理データを用いた他アプリとの連携処理の要求を受けた場合、前記所定アプリと前記他アプリとの間に関して、前記連携可否に関する情報に基づいて連携可否を判定する処理と、前記
    判定の結果、連携可能である場合、前記他アプリの機能配信を担うサーバに対して、前記処理データを配信し、前記他アプリに前記処理データを用いた処理を実行させる処理を更に実行する、
    ことを特徴とする請求項７に記載のポータル提供方法。
12. 前記情報処理装置が、
    所定のアプリベンダの装置から所定の要求を受けた場合、前記アプリベンダの装置に対し、対象アプリを所定企業の顧客向けに公開するための要求、対象アプリを他アプリとの連携対象として公開するための要求、および他アプリベンダによる公開中アプリと自アプリとの連携を図るための要求、のいずれの要求に該当するか確認するインターフェイスを表示させ、当該インターフェイスでの回答結果に応じて、予め定めた所定の支援処理を更に実行する、
    ことを特徴とする請求項７に記載のポータル提供方法。

Images