JP2019021173A - 情報出力管理装置および情報出力管理方法 - Google Patents

Abstract

【課題】各企業のデータを論理的に分離させ管理するマルチテナントシステムにおいて、リソースの誤設計や改ざん等に抗して、データの誤出力を的確に回避可能とする。【解決手段】情報出力管理装置１００において、参照情報定義ＤＢ１２８を保持し、ユーザ端末９０による所定機能の実行に応じ、当該ユーザ企業を実行ユーザとして前記機能を実行した場合の呼び出しデータに関して参照情報定義ＤＢ１２８を参照して、対応する出力条件を特定し、前記呼び出しデータをユーザ端末９０に出力するに先立ち、前記実行に関する所定データと前記呼び出しデータに含まれる所定事象のデータとの関係性が、前記出力条件を満たす場合に、前記呼び出しデータをユーザ端末９０に出力する演算装置１０４を含む構成とする。【選択図】図２

Description

本発明は、情報出力管理装置および情報出力管理方法に関するものであり、具体的には、各企業のデータを論理的に分離させ管理するマルチテナントシステムにおいて、リソースの誤設計や改ざん等に抗して、データの誤出力を的確に回避可能とする技術に関する。

バイヤー企業とサプライヤ企業とがＮ対Ｎで電子商取引可能な環境において、運用コスト低減や企業間での情報の参照性確保を図るため、データ装置やプログラム装置を企業間で共有するマルチテナント型のＳａａＳ（Ｓｏｆｔｗａｒｅ ａｓ ａ Ｓｅｒｖｉｃｅ）が広がりを見せている。また、上述のマルチテナント型のＳａａＳの登場以前に、バイヤー企業とサプライヤ企業とが電子商取引を行う形態として、企業間ＥＤＩ（Ｅｌｅｃｔｒｏｎｉｃ Ｄａｔａ Ｉｎｔｅｒｃｈａｎｇｅ）取引が広く普及している。
これら２つの形態は、異なる企業間のデータを扱う仕組みであり、情報漏洩の観点からデータの正しさを検査する手段が重要、との観点は共通する。

こうした企業間の電子商取引システムに関する従来技術としては、例えば、小売店とメーカとのうち少なくとも小売店との間に構成されるシステムであって、当該システムを実行するシステム実行部と、小売店及びメーカーとはそれぞれ情報伝達手段により情報の授受が可能なよう接続され、小売店には当該小売店における商品の販売状況をデータとして収集する購買者／販売情報収集手段（以下「情報収集手段」とする）が設けられ、システム実行手段には、当該情報収集手段から出力された情報を分析し、小売店における商品の販売を促進するデータを作成する手段と、メーカーに対して新たな商品を開発するための製品開発データを作成する手段とのうち少なくとも商品の販売を促進するデータを作成する手段が設けられていることを特徴とする商品の販売管理システム（特許文献１参照）などが提案されている。

また、商品売買に関するＥＤＩシステムの伝送データを管理するコンピュータシステムであって、買い手側端末が利用する売り手側システムのネットワーク上のアドレスを記憶した記憶手段と、買い手側端末より商品の注文情報をネットワークを介して受信し、注文情報が含む情報に基づいて前記記憶手段で売り手側システムのアドレスを検索する手段と、前記買い手側端末より受信している注文情報を含むチェック用データを、前記検索した売り手側システムのアドレスに宛ててチェック依頼とともに送信し、売り手側システムの保持するデータチェックプログラムによる前記チェック用データに関するデータチェック結果を、売り手側システムから受信する手段と、前記データベースチェック結果が問題ないものであれば該当注文情報を含む注文伝送データを該当売り手側システムに送信する手段と、を備えることを特徴とするＥＤＩデータ管理システム（特許文献２参照）なども提案されている。

特開２００７−２５８６０号公報 特開２０１１−１２８８９１号公報

上述のマルチテナント型のＳａａＳでは、論理的に各企業のデータが分離された状態で記録されたデータ装置やプログラム装置を、企業間共有する構成となっている。そのため
、例えばパラメータ改ざん等があった場合、本来ならば出力すべきでない自他企業の情報を検索要求等に応じて出力してしまう恐れがある。

また、上述した共用の構成を採用していることで、特定企業向けのプログラム装置のカスタマイズや標準機能の拡張、データ装置のテーブル拡張などの改修機会に際し、設計誤りや不具合の発生リスクが高い。そのため、上述同様に出力すべきでない情報を出力してしまう恐れがある。

一方、従来技術を採用するとしても、マルチテナントシステムにおける設計誤りや不具合、改ざん等に起因する不正表示を的確に回避する機構は備えておらず、例えばバイヤとサプライヤの間の情報紐付を誤った場合などにおいて、情報の誤表示や装置間での送受信データ混入などの恐れが依然として残されている。

そこで本発明では、各企業のデータを論理的に分離させ管理するマルチテナントシステムにおいて、リソースの誤設計や改ざん等に抗して、データの誤出力を的確に回避可能とする技術を提供することにある。

上記課題を解決する本発明の情報出力管理装置は、各ユーザ企業のデータを論理的に分離させて管理するマルチテナント型の電子商取引環境における、各機能が呼び出すデータの出力条件を規定した参照情報定義ＤＢを保持する記憶装置と、前記ユーザ企業の端末による所定機能の実行に応じ、当該ユーザ企業を実行ユーザとして前記機能を実行した場合の呼び出しデータに関して前記参照情報定義ＤＢを参照して、対応する出力条件を特定し、前記呼び出しデータを前記端末に出力するに先立ち、前記実行に関する所定データと前記呼び出しデータに含まれる所定事象のデータとの関係性が、前記出力条件を満たす場合に、前記呼び出しデータを前記端末に出力する演算装置と、を備えることを特徴とする。

また、本発明の情報出力管理方法は、各ユーザ企業のデータを論理的に分離させて管理するマルチテナント型の電子商取引環境における、各機能が呼び出すデータの出力条件を規定した参照情報定義ＤＢを保持する記憶装置を備えた情報処理装置が、前記ユーザ企業の端末による所定機能の実行に応じ、当該ユーザ企業を実行ユーザとして前記機能を実行した場合の呼び出しデータに関して前記参照情報定義ＤＢを参照して、対応する出力条件を特定し、前記呼び出しデータを前記端末に出力するに先立ち、前記実行に関する所定データと前記呼び出しデータに含まれる所定事象のデータとの関係性が、前記出力条件を満たす場合に、前記呼び出しデータを前記端末に出力する、ことを特徴とする。

本発明によれば、各企業のデータを論理的に分離させ管理するマルチテナントシステムにおいて、リソースの誤設計や改ざん等に抗して、データの誤出力を的確に回避できることとなる。

本実施形態における情報出力管理装置を含むネットワーク構成例を示す図である。 本実施形態の購買業務システムの構成例を示す図である。 本実施形態における注文情報ＤＢの構成例を示す図である。 本実施形態における見積依頼情報ＤＢの構成例を示す図である。 本実施形態における見積回答情報ＤＢの構成例を示す図である。 本実施形態における参照情報定義ＤＢの構成例を示す図である。 本実施形態における情報出力管理方法のフロー例１を示す図である。 本実施形態における情報出力管理方法のフロー例２を示す図である。 本実施形態における情報出力管理方法のフロー例３を示す図である。 本実施形態における情報出力管理方法のフロー例４を示す図である。 本実施形態における画面例１を示す図である。 本実施形態における画面例２を示す図である。 本実施形態における画面例３を示す図である。 本実施形態における画面例４を示す図である。 本実施形態における画面例５を示す図である。 本実施形態におけるダウンロードデータ例１を示す図である。 本実施形態におけるダウンロードデータ例２を示す図である。 本実施形態におけるダウンロードデータ例３を示す図である。 本実施形態におけるダウンロードデータ例４を示す図である。 本実施形態における画面例６を示す図である。 本実施形態における画面例７を示す図である。

−−−ネットワーク構成−−−

以下に本発明の実施形態について図面を用いて詳細に説明する。図１は、本実施形態の情報出力管理システムたるＷＥＢサーバ１００（以下、ＷＥＢサーバ１００）を含むネットワーク構成図である。図１に示すＷＥＢサーバ１００は、各企業のデータを論理的に分離させ管理するマルチテナントシステムにおいて、リソースの誤設計や改ざん等に抗して、データの誤出力を的確に回避するサーバ装置である。

図１で示すように、ＷＥＢサーバ１００は、ＤＢサーバ１５０と共に購買業務システム１０を構成している。この購買業務システム１０は、複数のバイヤー企業２０、サプライヤ企業３０が、それぞれのユーザ端末９０を利用することで、インターネット等のネットワーク５を経由して同時に利用することができる、すなわちＮ対Ｎのマルチテナント型の電子商取引環境を提供するシステムである。

この購買業務システム１０は、電子商取引に必要な機能およびデータを保持し、これらをネットワーク５経由でユーザ端末９０に適宜に提供する、クラウドシステムでもある。購買業務システム１０がユーザ端末９０に提供する機能としては、ＷＥＢサーバ１００におけるログインプログラム１１１、バイヤープログラム１１２、および、サプライヤープログラム１１３、の各プログラムを実行することで実装される機能を想定している。また、セキュリティプログラム１１４は、本実施形態の情報出力管理方法を実行するプログラムである。これらプログラムの機能の詳細については後述する。

また、購買業務システム１０において、ＷＥＢサーバ１００およびＤＢサーバ１５０では、各ユーザ企業すなわちバイヤー企業２０およびサプライヤ企業３０に関する種々のデータを、論理的に分離させ管理している。つまり、バイヤー３０およびサプライヤ企業３０のそれぞれに関して専用の記憶装置や記憶領域を設けて、それぞれのデータを格納・管理しているわけではない。具体的には、ＷＥＢサーバ１００やＤＢサーバ１５０にて、各データにバイヤー企業２０やサプライヤ企業３０の企業コード等の識別情報が付与された上で、例えば、機能別や目的別に記憶されている。

なお、本実施形態の購買業務システム１０では、処理対象となるバイヤー企業２０やサプライヤ企業３０の各データは、主としてＤＢサーバ１５０のデータベース１６０に格納されている構成を想定する。勿論、ＤＢサーバ１５０の機能およびデータベース１６０を、ＷＥＢサーバ１００が備えるとしてもよい。
−−−購買業務システムの構成−−−

続いて、上述の購買業務システム１０の構成について説明する。既に述べたように、購買業務システム１０は、ＷＥＢサーバ１００およびＤＢサーバ１５０で構成されている。これらＷＥＢサーバ１００およびＤＢサーバ１５０は、ネットワーク５との間に配置されたＦＷ６（Fire Wall）を介して、バイヤー企業２０やサプライヤ企業３０のユーザ端末
９０と通信可能となっている。また、ＷＥＢサーバ１００とＤＢサーバ１５０とはＬＡＮなど購買業務システム内のネットワーク７で通信可能に接続されている。

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

なお、記憶装置１０１内には、本実施形態の情報出力管理装置として必要な機能を実装する為のプログラム、すなわち業務用アプリケーション１１０およびセキュリティプログラム１１４が少なくとも記憶されている。また、業務用アプリケーション１１０は、既に述べたように、ログインプログラム１１１、バイヤープログラム１１２、および、サプライヤープログラム１１３を含んでいる。

このうちバイヤープログラム１１２においては、商品検索機能１１２１、発注・検索機能１１２２、ユーザ改廃機能１１２３、および、見積依頼機能１１２４を実装する。

上述の商品検索機能１１２１は、バイヤー企業２０がユーザ端末９０を操作してＷＥＢサーバ１００にアクセスした際、例えば、購買対象として所望の商品を指定する入力欄等を含む検索用のインターフェイスを提供し、当該インターフェイスで得た検索条件での検索リクエストをＤＢサーバ１５０に投げることで検索結果を得て、これをユーザ端末９０に返す機能となる。この時、ＤＢサーバ１５０では、検索リクエストに応じたクエリで商品情報ＤＢ１２７を検索することとなる。

また、発注・検収機能１１２２は、上述の商品検索機能１１２１で特定した商品を対象として、所定のサプライヤ企業３０に対して発注をかける処理を担う機能である。

また、ユーザ改廃機能１１２３は、例えばバイヤー企業２０が指定したサプライヤ企業３０に関して、ユーザ情報ＤＢ１２６での情報の改廃処理を担う機能である。
また、見積依頼機能１１２４は、商品検索機能１１２１で特定した商品に関して、或るサプライヤ企業３０のユーザ端末９０に見積依頼を通知するものである。
また、サプライヤープログラム１１３においては、注文受付機能１１３１、出荷登録機能１１３２、および、見積回答機能１１３３を実装する。

上述の注文受付機能１１３１は、バイヤー企業２０による発注・検収機能１１２２の利用によって発注手続がなされた注文に関して受注処理を行う機能であり、ここで処理した注文の情報を注文情報ＤＢ１２３に格納する機能である。

また、出荷登録機能１１３２は、注文受付機能１１３１で受注した注文に基づき、該当商品を該当サプライヤ企業３０が出荷した場合に、当該出荷情報をユーザ端末９０から得てＤＢサーバ１５０において適宜に格納する機能である。

また、見積回答機能１１３３は、見積依頼機能１１２４から見積依頼を受けたサプライヤ企業３０のユーザ端末９０から、見積回答を取得し、これを見積依頼情報ＤＢ１２４に格納する機能である。
なお、注文実績管理機能１１０１は、バイヤープログラム１１２およびサプライヤープログラム１１３で共用している。

この注文実績管理機能１１０１は、バイヤー企業２０やサプライヤ企業３０のユーザ端末９０からの検索要求を受けて、ＤＢサーバ１５０の注文情報ＤＢ１２３を検索し、これをセキュリティプログラム１１４に送信して、出力可否の判定に供する機能である。こうした検索やセキュリティプログラム１１４での処理の詳細については後述する。

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

なお、記憶装置１５１内には、本実施形態の情報出力管理装置として必要な機能を実装する為のプログラム１５２の他、データベース１６０が少なくとも記憶されている。

また、データベース１６０には、注文情報ＤＢ１２３、見積依頼情報ＤＢ１２４、見積回答情報ＤＢ１２５、ユーザ情報ＤＢ１２６、商品情報ＤＢ１２７、および、参照情報定義ＤＢ１２８、を格納している。なお、上述の各ＤＢは、バイヤー企業２０やサプライヤ企業３０といったユーザ共通で論理的に分割してデータを保存する。これら各ＤＢの詳細については後述する。
−−−データ構造例−−−

続いて、本実施形態の情報出力管理装置たるＷＥＢサーバ１００が用いるＤＢ類について説明する。図３に、本実施形態における注文情報ＤＢ１２３の一例を示す。

注文情報ＤＢ１２３は、バイヤー企業２０がユーザ端末９０を操作して商品検索機能１１２１で商品検索をし、当該商品に関して見積依頼機能１１２４にて所定サプライヤ企業３０宛の見積依頼を実行し、当該見積依頼に対する見積回答を認識した上で、発注・検収機能１１２２を利用し、所定のサプライヤ企業３０に宛てて発注をかけた注文の情報を蓄積したデータベースである。

そのデータ構造は、各注文を一意に特定する注文番号７０１をキーとして、注文依頼日７０２、この注文を行ったバイヤー企業２０の発注企業コード７０３、発注者名７０４、発注商品の商品コード７０５、商品名７０６、発注先のサプライヤ企業３０を示す取引先企業コード７０７、取引先名７０８、管理企業コード７０９、発注商品の数量７１０、仕入単価７１１、および、販売単価７１２といった値を対応付けたレコードの集合体となっている。

また、図４に、本実施形態における見積依頼情報ＤＢ１２４の一例を示す。本実施形態の見積依頼情報ＤＢ１２４は、バイヤー企業２０がユーザ端末９０を操作して、見積依頼機能１１２４を利用し、所定のサプライヤ企業３０に宛てて行った見積依頼の情報を蓄積したデータベースである。

そのデータ構造は、同じ商品と数量、希望単価に関する見積依頼を一意に特定する見積番号９０１をキーとして、見積依頼番号９０２、配送情報９０３、バイヤー企業２０を示す依頼企業コード９０４、商品名９０５、見積依頼先のサプライヤ企業３０を示す取引先企業コード９０６、見積依頼商品の数量９０７、および、希望単価９０８、といった情報を対応付けたレコードの集合体となっている。

なお、１つの見積番号９０１で異なるサプライヤ企業３０への相見積と、それぞれ複数回の見積回答を受け付けることができるものとする。よって、図４で示す見積依頼情報ＤＢ１２４でも、同内容の見積依頼に関して、「ＳＵＰ＿Ａ」と「ＳＵＰ＿Ｂ」の二社のサプライヤ企業３０宛てに、同内容の見積依頼が生成・送信された例を示している。

また、図５に、本実施形態における見積回答情報ＤＢ１２５の一例を示す。本実施形態の見積回答情報ＤＢ１２５は、上述の見積依頼情報ＤＢ１２４に登録された各見積依頼に対して、対応すべきサプライヤ企業３０から回答があった見積回答の情報を蓄積したデータベースである。

そのデータ構造は、見積回答を一意に特定する見積回答番号１００１をキーとして、当該見積回答の契機となった見積依頼の見積依頼番号１００２、見積回答日１００３、商品名１００４、数量１００５、および、回答単価１００６、といったデータを対応付けたレコードの集合体となっている。このうち、見積依頼番号１００２は、当然ながら、上述の見積依頼情報ＤＢ１２４における見積依頼番号９０２と共通するキーとなっている。

また、図６に、本実施形態における参照情報定義ＤＢ１２６の一例を示す。本実施形態の参照情報定義ＤＢ１２６は、購買業務システム１０が提供する電子商取引環境における、業務用アプリケーション１１０の各機能が、バイヤー企業２０ないしサプライヤ企業３０が操作するユーザ端末９０の指示を受けて、ＤＢサーバ１５０の注文情報ＤＢ１２３、見積依頼情報ＤＢ１２４、および、見積回答情報ＤＢ１２５のいずれかから呼び出したデータの出力条件を蓄積したデータベースである。

そのデータ構造は、業務用アプリケーション１１０のいずれかの機能を実行したユーザ、すなわちバイヤー企業２０ないしサプライヤ企業３０を示す実行ユーザ８０１をキーとして、呼び出し元機能８０２、比較元８０３、比較先８０４、比較内容８０５、および、不一致時命令８０６といったデータを対応付けたレコードの集合体となっている。

このうち比較元８０３は、上述の機能の実行に関する所定情報であり、具体的には、実行ユーザ８０１が示すバイヤー企業２０ないしサプライヤ企業３０の企業コードや、呼び出し対象のデータに関する所定項目（例：見積依頼情報、見積回答情報らにおける見積依頼番号）、すなわち「機能の実行に関する所定データ」である。

また比較先８０４は、呼び出されたデータに含まれる所定事象（例：注文情報における発注企業コードや、管理企業コード、取引先企業コード、販売価格、或いは、見積依頼情報や見積回答情報らにおける見積依頼番号など）のデータである。

また、比較内容８０５は、上述の比較元８０３と比較先８０４との好適な関係性に関して規定したものであり、上述の機能により呼び出されたデータの出力を許容する条件を示すものと言える。

情報出力管理装置たるＷＥＢサーバ１００は、この比較内容８０５で規定する条件が満たされた場合、実行ユーザ８０１が示す企業のユーザ端末９０に対し、該当データを出力することとなる。

また、不一致時命令８０６は、上述の比較元８０３と比較先８０４との関係性が比較内容８０５で規定する条件を満たさない場合、上述の機能により呼び出されたデータの出力を拒絶する、或いは所定の一部データのみ出力する／しない、などの所定処理を規定するものとなる。

なお、図示は省略するが、ユーザ情報ＤＢ１２６は、バイヤー企業２０ないしサプライヤ企業３０の各担当者に関するログイン用の情報が格納されたデータベースである。このログイン用の情報は、ログインＩＤとパスワード、該当担当者の所属先企業の企業コード、権限（例：発注者、管理者、見積処理者）が規定されている。従って、ログインプログラム１１１によるログイン処理に際し、ログイン認証に成功した場合、該当担当者の所属先や権限が確定することとなる。

また、商品情報ＤＢ１２７は、購買業務システム１０が提供する電子商取引環境において取引対象となる商品の情報を格納したデータベースである。この商品の情報は、サプライヤ企業３０のユーザ端末９０から登録要求を受けて格納した情報を想定出来るが、これに限定しない。
−−−実施例１−−−

以下、本実施形態における情報出力管理方法の実際手順について図に基づき説明する。以下で説明する情報出力管理方法に対応する各種動作は、情報出力管理装置たるＷＥＢサーバ１００が実行するプログラムによって実現される。そして、このプログラムは、以下に説明される各種の動作を行うためのコードから構成されている。また、ＷＥＢサーバ１００は、ＤＢサーバ１５０から必要なデータを取得し処理を実行する。

図７は、本実施形態における情報出力管理方法のフロー例１を示す図であり、具体的には、購買業務システム１０でトランザクションとして管理される注文実績をユーザ端末９０で画面参照する際のフローチャートである。

ここで、ログインプログラム１１１の機能を利用したログイン済み（従って担当者の所属先企業の企業コードや権限が確定済みである）のバイヤー企業２０ないしサプライヤ企業３０のユーザ端末９０は、注文実績管理機能１１０１を利用して、実績検索要求をＷＥＢサーバ１００に送信した状況を想定する。また、ＷＥＢサーバ１００は、この実績検索要求を受けて、実績検索画面１１００（図１１）を、当該ユーザ端末９０に返したとする。

この場合、ユーザ端末９０は、実績検索画面１１００をディスプレイ等の表示装置に出力し、ここでユーザからの検索条件の入力と一覧検索ボタン１１０１の押下を受け付け、当該検索条件をＷＥＢサーバ１００に送信する（ｓ１００）。

ここでＷＥＢサーバ１００に送信される検索条件は、図１１の実績検索画面１１００のインターフェイスで例示するように、注文番号、商品コード、商品名、といった注文情報が含みうる値となる。

一方、ＷＥＢサーバ１００の注文実績管理機能１１３１は、上述の検索条件を受信し、実績検索要求の実行ユーザの情報（ログインプログラム１１１でのログイン処理済みあるから実行ユーザの企業コードや権限等の情報は判明済み）と、上述のユーザ端末９０から受信した検索条件とに基づいて、検索用のクエリを生成し、これをＤＢサーバ１５０に問い合わせる（ｓ１０１）。

他方、ＤＢサーバ１５０は、上述のクエリを受けて、データベース１６０の注文情報ＤＢ１２３における検索を実行し、クエリの示す検索条件に一致したレコードを特定し、これを、ＷＥＢサーバ１００の注文実績管理機能１１３１へ返信する（ｓ１０２）。

ＷＥＢサーバ１００の注文実績管理機能１１３１は、ＤＢサーバ１５０からレコード、すなわち注文情報のデータを受信し、これと実行ユーザ情報とをセキュリティプログラム１１４に送信する（ｓ１０３）。

なお、上述の例では、ＤＢサーバ１５０で検索された情報をセキュリティプログラム１１４に送信する例としたが、この例に限らず、ＷＥＢサーバ１００の記憶装置１０１にて特定されたデータをセキュリティプログラム１１４に送信するとしてもよい。

ＷＥＢサーバ１００のセキュリティプログラム１１４は、注文実績管理機能１１０１から受信したデータの、ユーザ端末９０への出力可否について評価する（ｓ１０４）。

このセキュリティプログラム１１４における評価（ｓ１０４）の詳細について図８のフローに基づき詳述する。図８は本実施形態の情報出力管理方法のフロー例２を示す図であり、具体的には、セキュリティプログラム１１４での処理フローを示す図である。

この場合、セキュリティプログラム１１４は、フロー例１のｓ１０１でユーザ端末９０から呼び出された機能、すなわち呼び出し元機能（上述の例では、「注文実績管理機能」における一覧検索）の情報と、注文実績管理機能１１０１から受信した実行ユーザ情報とを取得する（ｓ１４０１）。

次に、セキュリティプログラム１１４は、ｓ１４０１で得た実行ユーザ情報、および、呼び出し元機能の情報をキーに、ＤＢサーバ１５０の参照定義情報ＤＢ１２８で検索を実行し、該当キーと実行ユーザ８０１および呼び出し元機能８０２の各値が一致するデータを取得する（ｓ１４０２）。

例えば、実行ユーザ情報が「バイヤー（企業）の発注者」で、呼び出し元機能の情報が「注文実績管理機能による一覧検索」を示すものである場合、セキュリティプログラム１１４は、図６の参照情報定義ＤＢにおいてレコード８１０を特定し、このデータを取得することとなる。
続いて、セキュリティプログラム１１４は、上述のｓ１４０２の結果、参照定義情報ＤＢ１２８から１件以上のデータを取得できたか判定する（ｓ１４０３）。

上述の判定の結果、１件も取得できなかった場合（ｓ１４０３：ｎ）、セキュリティプログラム１１４は、セキュリティチェック不要と判断し、呼び出し元機能すなわち注文実績管理機能１１０１からｓ１０４で受け付けたデータを、そのまま出力可能として呼び出し元機能に返し（ｓ１４０４）、処理をフロー例１のｓ１０５へ遷移させる。
他方、上述の判定の結果、１件以上取得できた場合（ｓ１４０３：ｙ）、セキュリティプログラム１１４は、処理をｓ１４０５に遷移させる。

この場合、セキュリティプログラム１１４は、上述のｓ１４０２で得たデータの比較元８０３および比較先８０４のそれぞれで規定された情報を、ｓ１０４で得ているデータにて特定し、これらが比較内容８０５の規定に合致しているか判定する（ｓ１４０５）。

上述の具体例であれば、比較元８０３が「実行ユーザの企業コード」で、比較先８０４が「検索結果の発注企業コード」であって、比較内容８０５が「比較元と比較先が一致すること」を規定している。一方、ｓ１０４で注文実績管理機能１１０１から得ている情報
で、「実行ユーザの企業コード」が例えば「ＫＩＧＹＯ＿Ａ」、「検索結果の発注企業コード」が例えば「ＫＩＧＹＯ＿Ａ」であったならば、両者は一致するから比較内容８０５の規定を満たすと判定される。

このように、セキュリティプログラム１１４は、注文実績検索管理機能１１０１からの呼び出しでは、実行ユーザが「バイヤー企業の発注者」の場合、比較先８０４で規定する「発注企業コード」と比較元８０３で規定する「実行ユーザの企業コード」が一致しているか判定する。また同様に、実行ユーザが「バイヤー企業の管理者」の場合、比較先８０４で規定する「管理企業コード」と、比較元８０３で規定する「実行ユーザの企業コード」とが一致しているか判定する。また、実行ユーザが「サプライヤ」の場合、比較先８０４が規定する「取引先企業コード」と、比較元８０３が規定する「実行ユーザの企業コード」が一致しているか判定する。

上述の判定の結果、比較内容８０５の規定に合致しない結果が得られた場合（ｓ１４０６：ＮＧ）、セキュリティプログラム１１４は、ユーザ端末９０での出力を「否」と判定し、処理をｓ１４０７に遷移させる。

他方、上述の判定の結果、比較内容８０５の規定に合致する結果が得られた場合（ｓ１４０６：ＯＫ）、セキュリティプログラム１１４は、ユーザ端末９０での出力を「合」と判定し、処理をｓ１４０８に遷移させる。

セキュリティプログラム１１４は、ｓ１４０６での判定結果が「合」の場合に応じて、呼び出し元機能の注文実績管理機能１１０１から送付されたデータを、そのまま呼び出し元機能へ返し（ｓ１４０８）、処理をフロー例１のｓ１０５に遷移させる。

一方、ｓ１４０６での判定結果が「否」の場合、セキュリティプログラム１１４は、これに応じて、ｓ１４０２で得たデータの不一致時命令８０６の規定に応じた命令を呼び出して、これを呼び出し元機能に返し（ｓ１４０７）、処理をフロー例１のｓ１０５に遷移させる。

ここで、フロー例１の説明に戻る。ＷＥＢサーバ１００の注文実績管理機能１１０１は、上述のｓ１０４を実行したセキュリティプログラム１１４から、「合」すなわち出力可とされたデータまたは「否」に応じて呼び出された命令を取得する（ｓ１０５）。

続いて、注文実績管理機能１１０１は、ｓ１０５で取得したデータから、実績検索一覧画面を生成し、ユーザ端末９０に送信し（ｓ１０６）、処理を終了する。この実績検索一覧画面は、図１２に示す画面１２００、図１３に示す画面１３００、図１４に示す画面１４００、を想定出来る。

このうち図１２の画面１２００は、実行ユーザが「バイヤー企業の発注者」であった場合のユーザ端末９０での表示画面である。また、図１３の画面１３００は、実行ユーザが「バイヤー企業の管理者」であった場合のユーザ端末９０での表示画面である。また、図１４の画面１４００は、実行ユーザが「サプライヤ企業」であった場合のユーザ端末９０での表示画面である。

一方、注文実績管理機能１１０１は、上述のｓ１０５でセキュリティプログラム１１４から、不一致時命令８０６を得て、それが例えば「対象の検索結果を出力しない」との指示であった場合、エラー画面１５００（図１５）を生成し、このデータファイルをユーザ端末９０に送信することとなる。すなわちこの場合、注文実績管理機能１１０１は、注文情報ＤＢ１２３から取得したデータを、ユーザ端末９０に対して一切出力しない。

以上のように、参照定義情報ＤＢ１２８を用いて出力制御を行うことで、例えば、注文実績管理機能１１０１のｓ１０２における、ＤＢサーバ１５０の注文情報ＤＢ１２３に問い合わせるクエリの設計誤りや、実行ユーザの企業コードの改ざんが行われても、セキュリティプログラム１１４によって、ユーザ端末９０での情報表示を回避することができる。
−−−実施例２−−−

ここでは、上述の実施例１とは異なり、ユーザ端末９０において、実績検索画面１１００のデータダウンロードボタン１１０２の押下を受け付けた状況を想定する。このようにデータダウンロードをユーザが所望する場合、実施例１とは、データファイル出力とエラー時の振る舞いが異なる。

この場合、ユーザ端末９０は、バイヤー企業２０ないしサプライヤ企業３０の担当者による、実績検索画面１１００での検索条件の入力と、データダウンロードボタン１１０２の押下を受けて、この検索条件とデータダウンロードの指示について、ＷＥＢサーバ１００の注文実績管理機能１１３１に送信する（ｓ２００）。

一方、ＷＥＢサーバ１００の注文実績管理機能１１０１は、これを受けて、フロー例１のｓ１０１〜ｓ１０５と同様に、ｓ２０１〜２０５を実行する。なお、本フローで呼び出されるセキュリティプログラム１１４がｓ１４０２で参照定義情報ＤＢ１２８から取得するデータは、呼び出し元機能８０２で「ダウンロード」が規定されているレコード８１４〜８１７となる。

続いて、注文実績管理機能１１０１は、ｓ２０５でセキュリティプログラム１１４から取得したデータよりデータファイルを生成し、これをユーザ端末９０に送信し（ｓ２０６）、処理を終了する。

このデータファイルの例としては、図１６に示すデータファイル１６００（実行ユーザが「バイヤー企業の発注者」である場合のダウンロードデータ）、図１７に示すデータファイル１７００（実行ユーザが「バイヤー企業の管理者」である場合のダウンロードデータ）、図１８に示すデータファイル１８００（実行ユーザが「サプライヤ企業」である場合のデータファイル）、を想定出来る。

一方、注文実績管理機能１１０１は、上述のｓ２０５でセキュリティプログラム１１４から、不一致時命令８０６を得て、それが例えば「対象の検索結果を出力しない」との指示であった場合、セキュリティプログラム１１４におけるｓ１４０５の判定で比較内容８０５の規定に合致するとされたデータのみを含むデータファイル（図１９のデータファイル１９００）を、ユーザ端末９０に送信することとなる。

以上のように、参照情報定義ＤＢにおける不一致時命令８０６の定義により、セキュリティプログラム１１４による判定結果に応じて、ユーザ端末９０での出力内容を制御することができる。
−−−実施例３−−−

ここでは、見積情報の閲覧（見積依頼機能１１２４）にセキュリティプログラム１１４を適用した例について示す。なお、見積依頼情報ＤＢ１２４および見積回答情報ＤＢ１２５は、見積依頼番号９０２と見積依頼番号１００２とで互いに関連付けられている関係にある。よって、ＷＥＢサーバ１００の見積依頼機能１１２４が、見積依頼情報ＤＢ１２４と見積回答情報ＤＢ１２５を参照すれば、上述の関係にある見積依頼情報ＤＢ１２４およ
び見積回答情報ＤＢ１２５から、１つの見積番号９０１で異なるサプライヤ企業３０の相見積と、それぞれ複数回の見積回答の各情報を特定することができる。

図１０は、本実施形態における情報出力管理方法のフロー例４を示す図である。この場合、ユーザ端末９０は、所定の画面等において、バイヤー企業２０の見積処理者による見積処理画面の表示要求の指示を受け付けて、この表示要求をＷＥＢサーバ１００の見積依頼機能１１２４に送信する（ｓ３００）。この表示要求には、当該バイヤー企業２０および見積処理者の情報すなわち実行ユーザの情報（企業コード、権限）と、見積番号の情報とが含まれているものとする。

一方、ＷＥＢサーバ１００の見積依頼機能１１２４は、ユーザ端末９０から得た実行ユーザの情報と見積番号に基づき、ＤＢサーバ１５０に問い合わせるクエリを生成し、これをＤＢサーバ１５０に問い合わせる（ｓ３０１）。

他方、上述のクエリを受け取ったＤＢサーバ１５０は、当該見積番号が一致する見積依頼のレコードを見積依頼情報ＤＢ２０４で特定し、ここで特定したレコードが示す見積依頼番号を含むレコードを見積回答情報ＤＢ２０５で特定して、それぞれ特定した見積依頼および見積回答の各レコードを結合し、これをＷＥＢサーバ１００へ送信する（ｓ３０２）。

続いて、見積依頼機能１１２４は、ＤＢサーバ１５０から送信されたレコードを取得し、当該レコードが含むデータと実行ユーザ情報を、セキュリティプログラム１１４に送信する（ｓ３０３）。

他方、セキュリティプログラム１１４は、上述の見積依頼機能１１２４から送信されてきたデータを参照情報定義ＤＢに基づいて評価し、その結果を見積依頼機能１１２４に返信する（ｓ３０４）。このとき、本ステップで呼びされるセキュリティプログラム１１４が、ｓ１４０２を実行すれば、実行ユーザ８０１が「バイヤー企業の見積処理者」で、呼び出し元機能８０２が「見積依頼機能」である、レコード８１８を参照定義情報ＤＢ１２８にて特定することになる。

また、セキュリティプログラム１１４は、上述のように特定した参照情報定義ＤＢのレコード８１８の比較内容８０５に基づき、見積情報ＤＢ１２４での検索結果であるレコードにおける見積依頼番号と、見積回答情報ＤＢ１２５での検索結果であるレコードにおける見積依頼番号とが一致するか、判定することとなる。一致した場合、該当データは出力可であり、一致しない場合、出力不可となる。

一方、見積依頼機能１１２４は、上述のｓ３０４を実行したセキュリティプログラム１１４から、その評価結果に応じて出力可とされたデータまたは評価結果に応じて呼び出された命令を取得する（ｓ３０５）。

次に、見積依頼機能１１２４は、ｓ３０５で取得したデータから、見積詳細画面２０００（図２０）を生成し、これをユーザ端末９０に送信し（ｓ３０６）、処理を終了する。なお、ｓ３０５で取得したのが、不一致時命令８０６の「対象の検索結果を出力しない」であった場合、見積依頼機能１１２４は、エラー画面２１００（図２１）をユーザ端末９０に送信する一方で、見積依頼情報ＤＢ１２４、見積回答情報ＤＢ１２５から取得したデータを、ユーザ端末９０に対して一切出力しない。

以上の様に参照定義情報ＤＢ１２８を定義しておくことで、異なるＤＢから得たレコードをユーザ端末９０にて結合表示させる場合に、例えば、結合条件の誤りがあった場合に
もセキュリティプログラム１１４により、ユーザ端末９０に本来なら表示不可のものを表示させるといった事態を防ぐことができる。

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

こうした本実施形態によれば、各企業のデータを論理的に分離させ管理するマルチテナントシステムにおいて、リソースの誤設計や改ざん等に抗して、データの誤出力を的確に回避することが可能となる。

本明細書の記載により、少なくとも次のことが明らかにされる。すなわち、本実施形態の情報出力管理装置において、前記演算装置は、前記機能を実行した場合の、複数のリソースからそれぞれ呼び出され、所定データを共通のキーとして互いに結びつくデータのセットに関して、前記参照情報定義ＤＢを参照して、対応する出力条件を特定し、前記セットを前記端末に出力するに先立ち、前記セットの一方のデータが含む所定データと他方のデータが含む所定データとの関係性が、前記出力条件を満たす場合に、前記データのセットを前記端末に出力するものである、としてもよい。

これによれば、各ユーザ企業に関する各種データが複数のサーバ等に分散している状況等に対応し、或る機能の実行に伴って呼び出すデータの繋がりを踏まえつつ、その出力可否を的確に判定し制御することができる。ひいては、各企業のデータを論理的に分離させ管理するマルチテナントシステムにおいて、リソースの誤設計や改ざん等に抗して、データの誤出力を更に的確に回避することが可能となる。

また、本実施形態の情報出力管理装置において、前記演算装置は、所定装置より、前記参照情報定義ＤＢにおける所定の出力条件の修正を受け付けて、前記参照情報定義ＤＢを更新し、当該更新の以後、前記出力条件の特定を前記更新を経た参照情報定義ＤＢを参照して実行するものである、としてもよい。

これによれば、出力条件の変更に伴う大規模なプログラム改修等のコストや手間を抑制し、参照情報定義ＤＢの更新手順を行うのみで、出力条件の管理とこれに伴う出力可否の判定精度の維持を図ることが可能となる。ひいては、各企業のデータを論理的に分離させ管理するマルチテナントシステムにおいて、リソースの誤設計や改ざん等に抗して、データの誤出力を更に的確に回避することが可能となる。

また、本実施形態の情報出力管理方法において、前記情報処理装置が、前記機能を実行した場合の、複数のリソースからそれぞれ呼び出され、所定データを共通のキーとして互いに結びつくデータのセットに関して、前記参照情報定義ＤＢを参照して、対応する出力条件を特定し、前記セットを前記端末に出力するに先立ち、前記セットの一方のデータが含む所定データと他方のデータが含む所定データとの関係性が、前記出力条件を満たす場合に、前記データのセットを前記端末に出力する、としてもよい。

また、本実施形態の情報出力管理方法において、前記情報処理装置が、所定装置より、前記参照情報定義ＤＢにおける所定の出力条件の修正を受け付けて、前記参照情報定義ＤＢを更新し、当該更新の以後、前記出力条件の特定を前記更新を経た参照情報定義ＤＢを参照して実行する、としてもよい。

５、７ ネットワーク
６ ＦＷ
１０ 購買業務システム
２０ バイヤー企業
３０ サプライヤ企業
９０ ユーザ端末
１００ ＷＥＢサーバ（情報出力管理装置）
１０１ 記憶装置
１０３ メモリ
１０４ ＣＰＵ（演算装置）
１０５ 通信装置
１１０ 業務用アプリケーション
１１１ ログインプログラム
１１２ バイヤープログラム
１１０１ 注文実績管理機能
１１２１ 商品検索機能
１１２２ 発注・検収機能
１１２３ ユーザ改廃機能
１１２４ 見積依頼機能
１１３ サプライヤープログラム
１１３１ 注文受付機能
１１３２ 出荷登録機能
１１３３ 見積回答機能
１１４ セキュリティプログラム
１２３ 注文情報ＤＢ
１２４ 見積依頼情報ＤＢ
１２５ 見積回答情報ＤＢ
１２８ 参照定義情報ＤＢ
１５０ ＤＢサーバ
１５１ 記憶装置
１５２ プログラム
１５３ メモリ
１５４ ＣＰＵ
１６０ データベース

Claims (6)

1. 各ユーザ企業のデータを論理的に分離させて管理するマルチテナント型の電子商取引環境における、各機能が呼び出すデータの出力条件を規定した参照情報定義ＤＢを保持する記憶装置と、
   前記ユーザ企業の端末による所定機能の実行に応じ、当該ユーザ企業を実行ユーザとして前記機能を実行した場合の呼び出しデータに関して前記参照情報定義ＤＢを参照して、対応する出力条件を特定し、前記呼び出しデータを前記端末に出力するに先立ち、前記実行に関する所定データと前記呼び出しデータに含まれる所定事象のデータとの関係性が、前記出力条件を満たす場合に、前記呼び出しデータを前記端末に出力する演算装置と、
   を備えることを特徴とする情報出力管理装置。
2. 前記演算装置は、
   前記機能を実行した場合の、複数のリソースからそれぞれ呼び出され、所定データを共通のキーとして互いに結びつくデータのセットに関して、前記参照情報定義ＤＢを参照して、対応する出力条件を特定し、前記セットを前記端末に出力するに先立ち、前記セットの一方のデータが含む所定データと他方のデータが含む所定データとの関係性が、前記出力条件を満たす場合に、前記データのセットを前記端末に出力するものである、
   ことを特徴とする請求項１に記載の情報出力管理装置。
3. 前記演算装置は、
   所定装置より、前記参照情報定義ＤＢにおける所定の出力条件の修正を受け付けて、前記参照情報定義ＤＢを更新し、当該更新の以後、前記出力条件の特定を前記更新を経た参照情報定義ＤＢを参照して実行するものである、
   ことを特徴とする請求項１に記載の情報出力管理装置。
4. 各ユーザ企業のデータを論理的に分離させて管理するマルチテナント型の電子商取引環境における、各機能が呼び出すデータの出力条件を規定した参照情報定義ＤＢを保持する記憶装置を備えた情報処理装置が、
   前記ユーザ企業の端末による所定機能の実行に応じ、当該ユーザ企業を実行ユーザとして前記機能を実行した場合の呼び出しデータに関して前記参照情報定義ＤＢを参照して、対応する出力条件を特定し、
   前記呼び出しデータを前記端末に出力するに先立ち、前記実行に関する所定データと前記呼び出しデータに含まれる所定事象のデータとの関係性が、前記出力条件を満たす場合に、前記呼び出しデータを前記端末に出力する、
   ことを特徴とする情報出力管理方法。
5. 前記情報処理装置が、
   前記機能を実行した場合の、複数のリソースからそれぞれ呼び出され、所定データを共通のキーとして互いに結びつくデータのセットに関して、前記参照情報定義ＤＢを参照して、対応する出力条件を特定し、
   前記セットを前記端末に出力するに先立ち、前記セットの一方のデータが含む所定データと他方のデータが含む所定データとの関係性が、前記出力条件を満たす場合に、前記データのセットを前記端末に出力する、
   ことを特徴とする請求項４に記載の情報出力管理方法。
6. 前記情報処理装置が、
   所定装置より、前記参照情報定義ＤＢにおける所定の出力条件の修正を受け付けて、前記参照情報定義ＤＢを更新し、当該更新の以後、前記出力条件の特定を前記更新を経た参照情報定義ＤＢを参照して実行する、
   ことを特徴とする請求項４に記載の情報出力管理方法。

Images