図面 (/)

技術 アプリケーションデータモデルに従って指定されたオブジェクトを更新するよう設計されたルールを実現する命令セットの生成

出願人 オラクル・フィナンシャル・サービシーズ・ソフトウェア・リミテッド
発明者 ナグラコンダ,ガンガダーバダパンデシワラ,ラジャラム・ナラシムハ
出願日 2015年7月31日 (4年0ヶ月経過) 出願番号 2017-514362
公開日 2017年11月24日 (1年9ヶ月経過) 公開番号 2017-534955
状態 特許登録済
技術分野 ストアードプログラム
主要キーワード 併合対象 併合結果 手動表示 視覚的強調 管理者システム 併合後 修正ルール 計算ルール
関連する未来課題
重要な関連分野

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

図面 (8)

課題・解決手段

本開示の局面では、アプリケーションデータモデルに従って指定されたオブジェクト更新するよう設計されたルールを実現する命令セットを生成する。一実施例では、オブジェクトを更新するよう設計されたルールは、各バケット実行順序の点で相互依存性をもたないルールを含むように(ルールの)バケットのセットを形成するように処理される。次いで、各バケットについて、共通のオブジェクトを更新するよう設計されたルールのサブセットが決定され、各々の決定されたルールのサブセットについて、対応する単一の命令セットが生成される。次いで、各バケットに含まれるルールのサブセットについて生成された命令セットは、同時に実行される。

概要

背景

関連技術
アプリケーションは、データを処理して、対応する所望の機能を提供するために使用される。金融アプリケーションは、クレジットカードローン銀行口座などの金融手段の管理に関するアプリケーションのクラスである。関連技術で周知であるように、金融アプリケーションは、銀行保険会社証券会社などの多様なビジネス企業で使用されている。

アプリケーションは、しばしば、データモデル(「アプリケーションデータモデル」)に基づいて開発され、当該データモデルは、データを記憶するためのデータモデルとは異なっている可能性がある。例えば、データは、リレーショナルデータベースモデルに従って表の形式で記憶されてもよいのに対して、アプリケーションは、アプリケーションデータモデルに従って指定されたオブジェクト(以下、「データオブジェクト」)に基づいて開発されてもよい。データオブジェクトは、さまざまな属性を含むように定義され、データオブジェクトのインスタンス(「オブジェクトインスタンス」)は、それぞれの属性の対応する値を有する。

アプリケーションデータモデルに従って指定されたデータオブジェクトを更新するために、アプリケーションにおいてルールが利用される。ルールは、マシンが動作可能なレベル(例えば、プログラミング言語SQLクエリなど)に近い対応するインプリメンテーション精通していないかもしれないユーザ(例えば、管理者、マネージャアナリスト経営幹部など)が理解できる概念レベルである。

データオブジェクトの更新は、当該データオブジェクトのそれぞれのオブジェクトインスタンスの1つ以上の属性の対応する値の変更を意味する。単純な事例として、銀行は、顧客の信用格付けのさまざまなレベル(高リスク、中リスクおよび低リスク)およびローンのタイプ(例えば、住宅ローン自動車ローン個人ローンなど)によって金利を更新するルールを有し得る。容易に理解できるように、ルールを実行することにより、複数のオブジェクトインスタンスが変更される。一般に、複雑なルールは、いくつかのより多くの変数次元、複数の属性の更新、および/または、更新された属性の値の複雑な計算を伴う。

ルールは、マシンでの実行にとってより適切な等価の命令セットに変換される。例えば、データオブジェクトがリレーショナルデータベースシステムに記憶されるとすると、命令セットは、リレーショナルデータベースシステムの表に向けられるSQL構造化照会言語クエリを含む。

概要

本開示の局面では、アプリケーションデータモデルに従って指定されたオブジェクトを更新するよう設計されたルールを実現する命令セットを生成する。一実施例では、オブジェクトを更新するよう設計されたルールは、各バケット実行順序の点で相互依存性をもたないルールを含むように(ルールの)バケットのセットを形成するように処理される。次いで、各バケットについて、共通のオブジェクトを更新するよう設計されたルールのサブセットが決定され、各々の決定されたルールのサブセットについて、対応する単一の命令セットが生成される。次いで、各バケットに含まれるルールのサブセットについて生成された命令セットは、同時に実行される。

目的

関連技術
アプリケーションは、データを処理して、対応する所望の機能を提供する

効果

実績

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

この技術が所属する分野

(分野番号表示ON)※整理標準化データをもとに当社作成

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

請求項1

コンピュータによって実行される方法であって、複数のルールを受信するステップを備え、各ルールは、アプリケーションデータモデルに従って指定された対応するオブジェクトのセットを更新するよう設計され、前記方法はさらに、バケットのセットを形成するステップを備え、各バケットは、前記複数のルールのうち、実行順序の点で相互依存性をもたないルールを含み、前記方法はさらに、前記バケットのセットの各バケットについて、前記バケットに含まれるルールの複数のサブセットを決定するステップを備え、ルールの各サブセットは、前記アプリケーションデータモデルに従って共通のオブジェクトを更新するよう設計され、前記ルールの複数のサブセットの各サブセットについて、対応する単一の命令セットを生成するステップと、前記バケットに含まれる前記ルールの複数のサブセットについて生成された前記命令セットを同時に実行するステップとを備える、方法。

請求項2

前記決定するステップは、前記バケットのセットの第1のバケットにおけるルールの第1の複数のサブセットを決定することを含み、前記ルールの第1の複数のサブセットは、ルールの第1のサブセットを含み、前記方法はさらに、前記ルールの第1の複数のサブセットの各々を併合できることを示しながら、前記ルールの第1のサブセットを含む前記ルールの第1の複数のサブセットを表示のために送信するステップを備え、前記生成するステップは、前記ルールの第1のサブセットが併合対象であることを示す入力データがユーザから受信された場合にのみ、前記ルールの第1のサブセットに対して実行される、請求項1に記載の方法。

請求項3

前記ルールの第1の複数のサブセットは、ルールの第2のサブセットをさらに含み、前記入力データは、前記ルールの第2のサブセットの第1のルールが併合から除外されることを示し、前記生成するステップは、前記第1のルールを除く前記ルールの第2のサブセットについて前記対応する単一の命令セットを生成することを含む、請求項2に記載の方法。

請求項4

前記ルールの第1の複数のサブセットは、第3のオブジェクトを更新するよう設計されたルールの第3のサブセットを含み、前記第1のバケットの第3のルールも、前記第3のルールが前記第3のオブジェクトを更新しないことに鑑みて、前記ルールの第3のサブセットに含まれず、前記方法はさらに、前記第3のルールの修正ルールを受信するステップを備え、前記修正ルールは、前記第3のオブジェクトを更新するよう設計され、前記決定するステップおよび前記生成するステップは、前記修正ルールを前記ルールの第3のサブセットに含めるため、および、前記修正ルールを含むように前記ルールの第3のサブセットについての前記対応する単一の命令セットを生成するために、再び実行される、請求項2または3に記載の方法。

請求項5

第1のルールおよび第2のルールは、前記実行順序に従って前記第1のルールの実行が完了して初めて前記第2のルールの実行が開始することを求められる場合に、相互依存性を有すると見なされ、前記第1のルールおよび前記第2のルールは、前記複数のルールに含まれ、前記形成するステップは、前記第1のルールを第1のバケットに含めることと、前記第2のルールを前記第1のバケットとは異なる第2のバケットに含めることとを含み、前記第1のバケットおよび前記第2のバケットは、前記バケットのセットに含まれる、請求項1〜4のいずれか1項に記載の方法。

請求項6

前記受信するステップは、前記複数のルールの各ルールの実行に先立って実行されなければならない対応するルールのセットを示す優先データをさらに受信することを含み、前記優先データは、前記第1のルールが前記第2のルールに先立って実行されなければならないことを示す、請求項5に記載の方法。

請求項7

前記アプリケーションデータモデルに従って指定された前記オブジェクトは、リレーショナルデータベースサーバに記憶され、前記複数のルールの各々は、独立して実行されると、前記リレーショナルデータベースサーバに向けられる対応するSQL構造化照会言語コマンドとして実現され、前記対応する単一の命令セットは、前記実行するステップ時に、前記リレーショナルデータベースサーバに向けられる単一のSQLコマンド形式で実現される、請求項1〜6のいずれか1項に記載の方法。

請求項8

ステムがルールの管理をサポートすることを可能にするための命令の1つ以上のシーケンスを記憶する非一時的な機械読取可能な媒体であって、前記システムに含まれる1つ以上のプロセッサによる前記1つ以上の命令の実行は、前記システムが動作を実行することを可能にし、前記動作は、複数のルールを受信する動作を含み、各ルールは、アプリケーションデータモデルに従って指定された対応するオブジェクトのセットを更新するよう設計され、前記動作はさらに、バケットのセットを形成する動作を含み、各バケットは、前記複数のルールのうち、実行順序の点で相互依存性をもたないルールを含み、前記動作はさらに、前記バケットのセットの各バケットについて、前記バケットに含まれるルールの複数のサブセットを決定する動作を含み、ルールの各サブセットは、前記アプリケーションデータモデルに従って共通のオブジェクトを更新するよう設計され、前記ルールの複数のサブセットの各サブセットについて、対応する単一の命令セットを生成する動作と、前記バケットに含まれる前記ルールの複数のサブセットについて生成された前記命令セットを同時に実行する動作とをさらに含む、非一時的な機械読取可能な媒体。

請求項9

前記決定する動作は、前記バケットのセットの第1のバケットにおけるルールの第1の複数のサブセットを決定することを含み、前記ルールの第1の複数のサブセットは、ルールの第1のサブセットを含み、前記非一時的な機械読取可能な媒体はさらに、前記ルールの第1の複数のサブセットの各々を併合できることを示しながら、前記ルールの第1のサブセットを含む前記ルールの第1の複数のサブセットを表示のために送信するための1つ以上の命令を備え、前記生成する動作は、前記ルールの第1のサブセットが併合対象であることを示す入力データがユーザから受信された場合にのみ、前記ルールの第1のサブセットに対して実行される、請求項8に記載の非一時的な機械読取可能な媒体。

請求項10

前記ルールの第1の複数のサブセットは、ルールの第2のサブセットをさらに含み、前記入力データは、前記ルールの第2のサブセットの第1のルールが併合から除外されることを示し、前記生成する動作は、前記第1のルールを除く前記ルールの第2のサブセットについて前記対応する単一の命令セットを生成することを含む、請求項9に記載の非一時的な機械読取可能な媒体。

請求項11

前記ルールの第1の複数のサブセットは、第3のオブジェクトを更新するよう設計されたルールの第3のサブセットを含み、前記第1のバケットの第3のルールも、前記第3のルールが前記第3のオブジェクトを更新しないことに鑑みて、前記ルールの第3のサブセットに含まれず、前記非一時的な機械読取可能な媒体はさらに、前記第3のルールの修正ルールを受信するための1つ以上の命令を備え、前記修正ルールは、前記第3のオブジェクトを更新するよう設計され、前記決定する動作および前記生成する動作は、前記修正ルールを前記ルールの第3のサブセットに含めるため、および、前記修正ルールを含むように前記ルールの第3のサブセットについての前記対応する単一の命令セットを生成するために、再び実行される、請求項9または10に記載の非一時的な機械読取可能な媒体。

請求項12

第1のルールおよび第2のルールは、前記実行順序に従って前記第1のルールの実行が完了して初めて前記第2のルールの実行が開始することを求められる場合に、相互依存性を有すると見なされ、前記第1のルールおよび前記第2のルールは、前記複数のルールに含まれ、前記形成する動作は、前記第1のルールを第1のバケットに含めることと、前記第2のルールを前記第1のバケットとは異なる第2のバケットに含めることとを含み、前記第1のバケットおよび前記第2のバケットは、前記バケットのセットに含まれる、請求項8〜11のいずれか1項に記載の非一時的な機械読取可能な媒体。

請求項13

前記受信する動作は、前記複数のルールの各ルールの実行に先立って実行されなければならない対応するルールのセットを示す優先データをさらに受信することを含み、前記優先データは、前記第1のルールが前記第2のルールに先立って実行されなければならないことを示す、請求項12に記載の非一時的な機械読取可能な媒体。

請求項14

前記オブジェクトは、リレーショナルデータベースサーバに記憶され、前記複数のルールの各々は、独立して実行されると、前記リレーショナルデータベースサーバに向けられる対応するSQL(構造化照会言語)コマンドとして実現され、前記対応する単一の命令セットは、前記実行する動作時に、前記リレーショナルデータベースサーバに向けられる単一のSQLコマンドの形式で実現される、請求項8〜13のいずれか1項に記載の非一時的な機械読取可能な媒体。

請求項15

デジタル処理システムであって、プロセッサと、ランダムアクセスメモリ(RAM)と、1つ以上の命令を記憶するための非一時的な機械読取可能な媒体とを備え、前記1つ以上の命令は、前記RAMに取り出されて前記プロセッサによって実行されたときに、前記デジタル処理システムにルールを処理させ、前記デジタル処理システムは、複数のルールを受信する動作を実行し、各ルールは、アプリケーションデータモデルに従って対応するオブジェクトのセットを更新するよう設計され、前記デジタル処理システムはさらに、バケットのセットを形成する動作を実行し、各バケットは、前記複数のルールのうち、実行順序の点で相互依存性をもたないルールを含み、前記デジタル処理システムはさらに、前記バケットのセットの各バケットについて、前記バケットに含まれるルールの複数のサブセットを決定する動作を実行し、ルールの各サブセットは、共通のオブジェクトを更新するよう設計され、前記ルールの複数のサブセットの各サブセットについて、対応する単一の命令セットを生成する動作を実行し、前記バケットに含まれる前記ルールの複数のサブセットについて生成された前記命令セットを同時に実行する動作を実行する、デジタル処理システム。

請求項16

前記決定する動作のために、前記デジタル処理システムは、前記バケットのセットの第1のバケットにおけるルールの第1の複数のサブセットを決定し、前記ルールの第1の複数のサブセットは、ルールの第1のサブセットを含み、前記デジタル処理システムはさらに、前記ルールの第1の複数のサブセットの各々を併合できることを示しながら、前記ルールの第1のサブセットを含む前記ルールの第1の複数のサブセットを表示のために送信する動作を実行し、前記デジタル処理システムは、前記ルールの第1のサブセットが併合対象であることを示す入力データがユーザから受信された場合にのみ、前記ルールの第1のサブセットに対して前記生成する動作を実行する、請求項15に記載のデジタル処理システム。

請求項17

前記ルールの第1の複数のサブセットは、ルールの第2のサブセットをさらに含み、前記入力データは、前記ルールの第2のサブセットの第1のルールが併合から除外されることを示し、前記デジタル処理システムは、前記第1のルールを除く前記ルールの第2のサブセットについて前記対応する単一の命令セットを生成する、請求項16に記載のデジタル処理システム。

請求項18

前記ルールの第1の複数のサブセットは、第3のオブジェクトを更新するよう設計されたルールの第3のサブセットを含み、前記第1のバケットの第3のルールも、前記第3のルールが前記第3のオブジェクトを更新しないことに鑑みて、前記ルールの第3のサブセットに含まれず、前記デジタル処理システムはさらに、前記第3のルールの修正ルールを受信する動作を実行し、前記修正ルールは、前記第3のオブジェクトを更新するよう設計され、前記デジタル処理システムは、前記修正ルールを前記ルールの第3のサブセットに含めるため、および、前記修正ルールを含むように前記ルールの第3のサブセットについての前記対応する単一の命令セットを生成するために、前記決定する動作および前記生成する動作を再び実行する、請求項15〜17に記載のデジタル処理システム。

請求項19

第1のルールおよび第2のルールは、前記実行順序に従って前記第1のルールの実行が完了して初めて前記第2のルールの実行が開始することを求められる場合に、相互依存性を有すると見なされ、前記第1のルールおよび前記第2のルールは、前記複数のルールに含まれ、前記デジタル処理システムは、前記複数のルールの各ルールの実行に先立って実行されなければならない対応するルールのセットを示す優先データをさらに受信し、前記優先データは、前記第1のルールが前記第2のルールに先立って実行されなければならないことを示し、前記デジタル処理システムは、前記第1のルールを第1のバケットに含めるとともに、前記第2のルールを前記第1のバケットとは異なる第2のバケットに含め、前記第1のバケットおよび前記第2のバケットは、前記バケットのセットに含まれる、請求項15〜18のいずれか1項に記載のデジタル処理システム。

請求項20

前記オブジェクトは、リレーショナルデータベースサーバに記憶され、前記複数のルールの各々は、独立して実行されると、前記リレーショナルデータベースサーバに向けられる対応するSQL(構造化照会言語)コマンドとして実現され、前記対応する単一の命令セットは、前記実行する動作時に、前記リレーショナルデータベースサーバに向けられる単一のSQLコマンドの形式で実現される、請求項15〜19のいずれか1項に記載のデジタル処理システム。

技術分野

0001

優先権主張
本特許出願は、全文が本明細書に援用される以下の同時係属出願に関連し、その優先権を主張する:
A.2014年9月9日に出願された、本特許出願と同一の出願人の名義の、「金融アプリケーションビジネスオブジェクト更新するよう設計されたビジネスルールを実現する命令セットの生成(Generating Instruction Sets Implementing Business Rules Designed To Update Business Objects Of Financial Applications)」と題されるインド特許出願連続番号第4421/CHE/2014号;および
B.2015年1月13日に出願された、本特許出願と同一の出願人の名義の、「金融アプリケーションのビジネスオブジェクトを更新するよう設計されたビジネスルールを実現する命令セットの生成(Generating Instruction Sets Implementing Business Rules Designed To Update Business Objects Of Financial Applications)」と題される米国特許本出願連続番号第14/595,223号。

0002

背景
技術分野
本開示は、企業アプリケーションサーバに関し、より具体的には、アプリケーションデータモデルに従って指定されたオブジェクトを更新するよう設計されたルールを実現する命令セットの生成に関する。

背景技術

0003

関連技術
アプリケーションは、データを処理して、対応する所望の機能を提供するために使用される。金融アプリケーションは、クレジットカードローン銀行口座などの金融手段の管理に関するアプリケーションのクラスである。関連技術で周知であるように、金融アプリケーションは、銀行保険会社証券会社などの多様なビジネス企業で使用されている。

0004

アプリケーションは、しばしば、データモデル(「アプリケーションデータモデル」)に基づいて開発され、当該データモデルは、データを記憶するためのデータモデルとは異なっている可能性がある。例えば、データは、リレーショナルデータベースモデルに従って表の形式で記憶されてもよいのに対して、アプリケーションは、アプリケーションデータモデルに従って指定されたオブジェクト(以下、「データオブジェクト」)に基づいて開発されてもよい。データオブジェクトは、さまざまな属性を含むように定義され、データオブジェクトのインスタンス(「オブジェクトインスタンス」)は、それぞれの属性の対応する値を有する。

0005

アプリケーションデータモデルに従って指定されたデータオブジェクトを更新するために、アプリケーションにおいてルールが利用される。ルールは、マシンが動作可能なレベル(例えば、プログラミング言語SQLクエリなど)に近い対応するインプリメンテーション精通していないかもしれないユーザ(例えば、管理者、マネージャアナリスト経営幹部など)が理解できる概念レベルである。

0006

データオブジェクトの更新は、当該データオブジェクトのそれぞれのオブジェクトインスタンスの1つ以上の属性の対応する値の変更を意味する。単純な事例として、銀行は、顧客の信用格付けのさまざまなレベル(高リスク、中リスクおよび低リスク)およびローンのタイプ(例えば、住宅ローン自動車ローン個人ローンなど)によって金利を更新するルールを有し得る。容易に理解できるように、ルールを実行することにより、複数のオブジェクトインスタンスが変更される。一般に、複雑なルールは、いくつかのより多くの変数次元、複数の属性の更新、および/または、更新された属性の値の複雑な計算を伴う。

0007

ルールは、マシンでの実行にとってより適切な等価の命令セットに変換される。例えば、データオブジェクトがリレーショナルデータベースシステムに記憶されるとすると、命令セットは、リレーショナルデータベースシステムの表に向けられるSQL構造化照会言語クエリを含む。

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

0008

本開示の局面は、アプリケーションデータモデルに従って指定されたオブジェクトを更新するよう設計されたルールを実現する命令セットを生成することに向けられる。

0009

以下で簡単に説明する添付の図面を参照して、本開示の例示的な実施例について説明する。

0010

図中、同様の参照番号は、一般に、同一の要素、機能的に類似した要素、および/または、構造的に類似した要素を示す。要素が最初に登場する図面は、対応する参照番号における最上位桁によって示される。

図面の簡単な説明

0011

本開示のいくつかの局面を実現できる例示的な環境を示すブロック図である。
本開示の局面に従った、アプリケーションデータモデルに従って指定されたオブジェクトを更新するよう設計されたルールを実現する命令セットが生成される態様を示すフローチャートである。
一実施例における、実行のためにルールが指定される態様を示す。
一実施例における本開示のいくつかの局面に従った、ルールが処理される態様を示す。
一実施例における、併合に適していると判断されたルールのサブセットが表示される態様を示す。
一実施例における、ルールのサブセットの併合結果がユーザに表示される態様を示す。
適切なソフトウェア命令の実行によって本開示のいくつかの局面が機能するデジタル処理システムの詳細を示すブロック図である。

実施例

0012

例示的な実施例の説明
1.概要
本開示の局面では、アプリケーションデータモデルに従って指定されたオブジェクトを更新するよう設計されたルールを実現する命令セットを生成する。一実施例では、オブジェクトを更新するよう設計されたルールは、各バケット実行順序の点で相互依存性をもたないルールを含むように(ルールの)バケットのセットを形成するように処理される。次いで、各バケットについて、共通の(データ)オブジェクトを更新するよう設計されたルールのサブセットが決定され、各々の決定されたルールのサブセットについて、対応する単一の命令セットが生成される。次いで、各バケットに含まれるルールのサブセットについて生成された命令セットは、同時に実行される。

0013

共通のオブジェクトを更新するルールの各サブセットについて、(例えば、最終的に単一のSQLクエリに変換される)単一の命令セットを生成することによって、このような共通のオブジェクトがバケットのルールの処理に必要とされる合計時間を短縮することができる。このような更新中は(例えば、データベース内の表/列のロッキングを使用して)排他的アクセスがオブジェクトに提供されるものとすると、排他的アクセスの時間もそれに従って短縮され、それによって、他のアプリケーションが当該オブジェクトへの排他的アクセスを必要とする状態での同一のオブジェクトに対する相反する競合の確率が減少する。また、バケット内のルールに対応する命令セットを同時に実行することによって、少なくとも基礎をなす環境が十分なマルチプロセッシング機能を提供する場合に同様の効率を得ることができる。

0014

本開示の別の局面によれば、バケット内で決定されたルールのサブセットは、ルールのサブセットの各々を併合できる(すなわち、単一の命令セットを生成できる)ことを示しながら、表示のために送信される。したがって、ルールのサブセットに対応する命令セットの生成は、ルールのサブセットの各々が併合対象であることを示す入力データがユーザから受信された場合にのみ、実行される。

0015

したがって、(アプリケーションの)ユーザは、併合対象の特定のサブセット(および生成される単一の命令セット)を示し、どのサブセットが併合されないか(すなわち、各ルールごとの個々の命令セットが生成される)を示すことが容易になる。したがって、ルールのサブセットにおける特定のルールが併合から除外されることを、(ユーザから受信される)入力データが示す場合、当該ルールのサブセットについての対応する単一の命令セットは、当該特定のルールを除外して(すなわち、サブセットにおける他のルールについてのみ)生成される。その結果、ユーザは、ルールの併合に対する制御を向上させることができる。

0016

本開示の1つ以上の局面によれば、各ルールの実行に先立って実行されるべきである対応するルールのセットを示す優先データが受信される。したがって、バケットは、対応するルールのセットが、ルールを含む同一のバケットに含まれないように形成される(なぜなら、当該ルールは、実行のための対応するルールのセットに対する依存性を有するからである)。

0017

本開示のさらに別の局面によれば、アプリケーションデータモデルに従って指定されたオブジェクトは、リレーショナルデータベースサーバに記憶される。したがって、各ルールは、独立して実行されると、リレーショナルデータベースサーバに向けられる対応するSQL(構造化照会言語)コマンドとして実現されるであろう。また、対応する単一の命令セットは、リレーショナルデータベースサーバに向けられる単一のSQLコマンドの形式で実現される。したがって、サブセットにおけるルールに対応して実行されるであろうさまざまなSQLコマンドは、単一のSQLコマンドに置換される。

0018

例示のために、例を参照して本開示のいくつかの局面について以下で説明する。しかし、本開示は、具体的な詳細のうちの1つ以上がなくても、または他の方法、構成要素、材料などによっても実施できることを当業者は認識するであろう。他の例では、本開示の特徴を曖昧にすることを回避するために、周知の構造、材料またはオペレーションは詳細に示されていない。さらに、記載されている特徴/局面は、さまざまな組み合わせで実施できるが、簡潔にするために当該組み合わせの一部のみが本明細書に記載されている。

0019

2.例示的な環境
図1は、本開示のいくつかの局面を実現できる例示的な環境を示すブロック図である。当該ブロック図は、エンドユーザシステム110A〜110Zと、インターネット120と、イントラネット130と、サーバシステム140A〜140Cと、管理者システム150と、データストア180A〜180Bとを含むものとして示されている。

0020

単に例示のために、典型的な数/タイプのシステムが図に示されているに過ぎない。環境が設計される目的に応じて、多くの環境は、数の点でもタイプの点でも、より多くのシステムを含んでいることが多い。図1の各システム/装置について以下でさらに詳細に説明する。

0021

イントラネット130は、(点線境界線によって示される)企業内に設けられるサーバシステム140A〜140Cと管理者システム150とデータストア180A〜180Bとの間の接続を提供するネットワークを表わす。インターネット120は、エンドユーザシステム110A〜110Zなどの外部システムとのこれら(および企業の他のシステム)の接続を拡張する。イントラネット140およびインターネット120の各々は、関連技術で周知の伝送制御プロトコル(Transmission Control Protocol:TCP)および/またはインターネットプロトコル(Internet Protocol:IP)などのプロトコルを使用して実現されてもよい。一般に、TCP/IP環境では、トランスポート基本単位としてIPパケットが使用され、パケット発生源ソースシステム割り当てられるIPアドレスソースアドレスが設定され、パケットが最終的に送達される宛先システムのIPアドレスに宛先アドレスが設定される。

0022

IPパケットは、パケットの宛先IPアドレスが宛先システムのIPアドレスに設定されると宛先システムに向けられ、その結果、パケットがネットワーク120および130によって最終的に宛先システムに送達されると考えられる。パケットは、宛先アプリケーションを指定するポート番号などのコンテンツを含む場合には、このようなアプリケーションにも向けられると考えることができる。宛先システムは、対応するポート番号を利用可能/オープンなままにして、対応する宛先ポートを用いてパケットを処理しなければならないであろう。インターネット120およびイントラネット130の各々は、有線または無線媒体の任意の組み合わせを使用して実現されてもよい。

0023

データストア180A〜180Bの各々は、サーバシステム140A〜140Cおよび管理者システム150などの企業の他のシステムで実行される(金融アプリケーション、分析フレームワークなどの)企業アプリケーションによるデータの集合体の記憶および検索を容易にする不揮発性永続的)ストレージを表わす。

0024

データストア180A〜180Bの各々は、リレーショナルデータベース技術を使用するデータベースサーバとして実現され、したがって、SQL(構造化照会言語)などの構造化クエリを使用してデータの記憶および検索を行ってもよい。代替的に、データストア180A〜180Bの各々は、関連技術で周知であるように、1つ以上のディレクトリとして編成されるファイルの形式でデータの記憶および検索を行うファイルサーバとして実現されてもよい。

0025

一実施例では、データストア180A〜180Bに維持されるデータに対しては、背景欄に上記したように、データオブジェクト、属性およびオブジェクトインスタンスを含む、(データストアの外部に設けられる)アプリケーションデータモデルに従ってアクセスが提供される。データオブジェクトは、リレーショナルデータベースシステムに記憶される場合には1つ以上の表に対応し得て、各属性は、このような表のそれぞれの列に対応し、各オブジェクトインスタンスは、このような表における行に対応する。各データオブジェクトは、ファイルサーバに記憶される場合には1つ以上のファイルに対応し得て、各オブジェクトインスタンスは、ファイル内の行のセットによって表わされ、各行はさらに、属性および対応する値を指定する。

0026

エンドユーザシステム110A〜110Zの各々は、企業の特定のシステムに向けられるユーザ要求を生成して送信するためにユーザによって使用される、パーソナルコンピュータワークステーション移動端末携帯電話コンピューティングタブレットなどのシステムを表わす。ユーザ要求は、適切なユーザインターフェイス(例えば、企業内で実行されるアプリケーションによって提供されるウェブページ)を使用して生成されてもよい。例えば、ユーザは、サーバシステム140A〜140Cで実行される企業アプリケーションに対してさまざまなタスクを実行するためのユーザ要求を送信してもよい。

0027

サーバシステム140A〜140Cの各々は、エンドユーザシステム110A〜110Zを使用するユーザによって要求されるタスクを実行することができる(金融アプリケーション、分析フレームワークなどの)企業アプリケーションを実行する、ウェブアプリケーションサーバなどのサーバを表わす。エンドユーザシステムから要求を受信したことに応答して、各サーバシステムは、当該要求に規定されるタスクを実行し、タスクの実行結果を、要求を行ったエンドユーザシステムに送信する。各サーバシステムは、内部に(例えば、サーバ内の不揮発性ストレージハードディスクに)記憶されたデータ、(例えば、データストア180A〜180Bに維持される)外部データ、および/または、このようなタスクを実行する際に外部ソースから(例えば、ユーザから)受信されるデータを使用し得る。

0028

管理者システム150は、サーバシステム140A〜140Cで実行されるさまざまな企業アプリケーションによってアクセスされる対応するデータをユーザが管理(作成、更新、削除)することを容易にする、ウェブ/アプリケーションサーバなどのサーバを表わす。一実施例では、管理者システム150で実行される分析フレームワークは、アプリケーションデータモデルに従って指定されたオブジェクトを更新するためのルールをユーザが指定することを容易にし、当該フレームワークは、次いで、当該ルールを、データストア180A〜180Bのインプリメンテーションに適切であるように対応する命令セット(例えば、SQLクエリ)に変換する。このような分析フレームワークの一例は、本願の所期の譲受人であるオラクル社から入手可能なオラクル金融サービス分析アプリケーション(Oracle Financial Services Analytical Applications:OFSAA)である。

0029

ある従前のアプローチでは、分析フレームワークは、各ルールを対応する命令セットに変換する(すなわち、命令セットの数は、ルールの数に等しい)。したがって、最適な(より少ない)数の命令セットが所与のルールのセットについて生成されることが望ましい。本開示のいくつかの局面に従って拡張される管理者システム150は、例を用いて以下で説明するように、アプリケーションデータモデルに従って指定されたオブジェクトを更新するよう設計されたルールを実現するこのような最適な命令セットの生成を容易にする。

0030

3.ルールを実現する命令セットの生成
図2は、本開示の局面に従った、アプリケーションデータモデルに従って指定されたオブジェクトを更新するよう設計されたルールを実現する命令セットが生成される態様を示すフローチャートである。当該フローチャートは、単に例示のために、図1、特に管理者システム150に関して記載されている。しかし、本明細書において提供されている開示を読むことによって当業者に明らかであるように、特徴のうちの多くは、本開示のいくつかの局面の範囲および精神から逸脱することなく、他の環境でも(場合によっては、他のタイプのシステム/サーバを使用しても)実現可能である。

0031

また、当業者に明らかであるように、ステップのうちのいくつかは、特定の環境に適合させるように、以下に示されるシーケンスとは異なるシーケンスで実行されてもよい。このようなインプリメンテーションの多くは、本開示のいくつかの局面によって包含されるよう意図される。フローチャートはステップ201から開始し、制御は直ちにステップ210に進む。

0032

ステップ210において、管理者システム150は、アプリケーションデータモデルに従って指定されたデータオブジェクトを更新するよう設計されたルールを受信する。したがって、各ルールは、オペレータオペランドとを含み、オペランドのうちの少なくとも1つは、データオブジェクトまたは対応する属性である。ルールは、エンドユーザシステム110A〜110Zのうちの1つを使用するユーザから受信されてもよい。

0033

ステップ220において、管理者システム150は、各バケットにおけるルールが実行順序の点で相互依存性をもたないようにルールのバケットを形成する。相互依存性は、当該実行順序で先立つルールの実行が完了して初めて後続のルールの実行が開始することを求められる場合に存在すると考えられる。このような相互依存性がない場合、両方のルールは場合によっては同時に実行可能である。

0034

以下で説明する実施例では、ユーザは、優先データ/順序付け(すなわち、所与のルールを実行するためにどの先立つルールを完了させなければならないかということの手動表示)を指定するが、このようなまたは他の依存性は、各ルールについて指定される入力および出力を調べることによって推測されてもよい。このようなシナリオでは、管理者システム150は、先立つルールが、所与のルールを含むバケットに確実に含まれないようにする。

0035

ステップ230において、管理者システム150は、ステップ220において形成された1つ以上のバケットからバケットを選択する。特に、(以下で説明するステップ240〜270に従って)ルールが未処理のバケットが選択される。このような未処理のバケットの選択は、公知の方法で実行されてもよい。例えば、各バケットは、対応するバケットが処理済みである(第1の値)か未処理である(第2の値)かを示すフラグに関連付けられてもよい。したがって、管理者システム150は、フラグが第2の値に設定されるバケットを選択することができる。

0036

ステップ240において、管理者システム150は、選択されたバケットの各ルールによって更新されるデータオブジェクト(および対応する属性)を識別する。更新されるデータオブジェクトの識別は、分析フレームワークによって維持されるメタデータを調べることによって決定されてもよい。

0037

ステップ250において、管理者システム150は、同一のデータオブジェクトを更新するルールのサブセットを決定する。言い換えれば、同一のデータオブジェクトを更新するバケットにおけるルールは、同一のサブセットに含まれる。実施例では、決定されたルールのサブセットは、ルールのサブセットの各々を併合できる(すなわち、単一の命令セットを生成できる)ことを示しながら、(エンドユーザシステム110A〜110Zのうちの1つに関連付けられる)ディスプレイユニットでの表示のために送信される。ユーザは、併合対象の特定のサブセットおよび/または各サブセットにおける特定のルールを選択することが可能になる。全てのルールのサブセットが併合対象であることを示す入力データがユーザから受信されるものとして説明を続ける。

0038

ステップ260において、管理者システム150は、ルールの各サブセットについて単一の命令セットを生成する。サブセットについて生成される単一の命令セットは、(当該サブセットに対応する)データオブジェクトの属性の、(サブセットにおけるルールによって決定される)値の更新を実行するよう設計される。実施例では、単一の命令セットは、単一のSQLステートメントとして、例えば更新のために複数の列を有する「MERGE」ステートメントとして形成される。

0039

ステップ270において、管理者システム150は、同時実行のために、(さまざまなルールのサブセットについて生成された)さまざまな命令セットをマークする。言い換えれば、ステップ250において4つのルールのサブセットが形成されると、対応する4つの命令セットを同時に実行することができる。

0040

ステップ280において、管理者システム150は、処理すべきより多くのバケットがあるか否か(すなわち、どのフラグが第2の値に設定されるか)を確認する。このような確認に先立って、管理者システム150は、まず、選択されたバケットが処理済みであることを示すために、選択されたバケットに関連付けられるフラグを第1の値に設定する。より多くのバケットがある場合、制御はステップ230に進んで(まだ未処理の)新たなバケットが選択される。そうでなければ(全てのバケットが処理された後)、制御はステップ299に進む。フローチャートは、ステップ299で終了する。

0041

したがって、所与のルールのセットのうちのどれを組み合わせて単一の命令セットにすることができるかを識別することによって、データオブジェクトを更新するよう設計された所与のルールのセットについて最適な命令セットを生成することができる。さらに、(高い概念レベルで操作を行うマネージャなどの)ユーザが併合対象の特定のルールを選択できるようにすることによって、データオブジェクトの基本的なインプリメンテーションではなくビジネス/金融上の検討事項に基づいてルールの選択を実行できるということが理解できる。

0042

図2に従って管理者システム150が命令セットの生成を実行することができる態様について、例を用いて以下で説明する。

0043

4.例示的な例
図3A図3Bおよび図4A図4Bは、ともに、一実施例における、アプリケーションモデルに従って指定されたオブジェクトを更新するよう設計されたルールを実現する命令セットが生成される態様を示す。図の各々について以下で詳細に説明する。

0044

図3Aは、一実施例における、実行のためにルールが指定される態様を示す。例示のために、当該ルールは、(行と列とを有する)表の形式で指定されるものとして示されている。しかし、代替的な実施例では、当該ルールは、適切なユーザインターフェイスを使用して、任意の都合のよい態様で指定されてもよい。ルールを指定するための例示的なユーザインターフェイスは、「データベースに記憶されたデータ項目グループ分けの簡略化(SIMPLIFYING GROUPING OFDATAITEMS STORED IN A DATABASE)」と題される米国特許第8,856,126号に詳細に記載されている。

0045

したがって、表310は、エンドユーザシステム110A〜110Zのうちの1つを使用するユーザによって分析フレームワークに規定される、(データオブジェクトを更新するよう設計された)ルールのセットを示す。列311(「ルールId」)は、ルールの固有の識別子(R1,R2など)を指定し、列312(「階層/ドメイン」)は、ルールによって入力として使用される対応する値のセット(H1,H2などと称される)を指定し、列313(「程度/範囲」)は、ルールによって更新されるM1,M2などの(さまざまなデータオブジェクトの)属性を指定する。

0046

各々の階層/ドメインは、データオブジェクトの属性に記憶できる対応する可能な値のセットを表わす。可能な値は、当該技術分野で周知のツリーデータ構造の形式で編成される。各々の程度は、関連付けられる計算のセットを実行した結果として更新される(データオブジェクトにおける)対応する1つ以上の属性を表わす。データオブジェクトがリレーショナルデータベースシステムに記憶される場合、各々の階層は、データベースシステム内の列に記憶できる可能な値を表わし、各々の程度は、データベースシステム内の(表の)列を表わす。

0047

表310の行の各々は、企業アプリケーションのデータオブジェクトを更新するために利用される対応するルールを指定する。一般に、各ルールは、階層/ドメインの値(列312への入力)のさまざまな組み合わせについて、対応する計算を指定し、当該計算の結果として生じる値は、(列313における)程度/範囲に記憶される。例えば、行318は、「R3」という名前によって固有に識別されるルールが、階層H4およびH5における値のさまざまな組み合わせについて、対応する計算を指定し、当該計算の結果として生じる値が程度M4において更新されることを示す。同様に、他の行は、対応するルールの詳細を指定する。

0048

表320は、典型的には分析フレームワークの開発者/管理者によって分析フレームワークに規定される程度のセットを示す。列321(「程度Id」)は、程度の固有の識別子(M1,M2など)を指定し、列322(「オブジェクト」)および323(「属性」)は、程度によって表わされる対応するデータオブジェクトおよび属性を指定する。

0049

表320の行の各々は、分析フレームワークに規定されるルールによって更新され得る対応する程度を指定する。例えば、行328は、(行318によって示されるルールR3によって更新される)程度M4が、データオブジェクトB1に含まれる属性A5およびA6に対応することを示す。同様に、他の行は、分析フレームワークにおいて使用される対応する程度の詳細を指定する。

0050

表330は、分析フレームワークにおいて実行定義の一部として定義されるプロセスのセットを示す。実行定義は、(シーケンシャル順序で実行される)プロセス/ステップのシーケンスの形式で指定されるアプリケーションプロセスフローを表わす。ユーザは、分析フレームワークによって提供される(ルールなどの)1つ以上のコンポーネントを実行定義におけるプロセスとして示してもよい。以下の説明では、実行定義のさまざまなプロセスは、ルールのみを示すものとする。

0051

したがって、表330は、エンドユーザシステム110A〜110Zのうちの1つを使用するユーザによって分析フレームワークに規定されるプロセスステップのセットを示す。列331(「プロセスId」)は、プロセスステップのためのプロセスの識別子(P1,P2など)を指定する。なお、複数の行に規定される対応するプロセスステップが同一のプロセスの一部であることを示すために、同一のプロセス識別子が複数の行において繰返されてもよい。列332(「ルールId」)は、プロセスステップとして実行されるルールの識別子を指定し、列333(「優先度」)は、対応するプロセスステップに規定されるルールを実行するためにどの先立つルールを完了しなければならないかを示す。先立つルールの欠如記号「−」によって示される)は、ルール(R1,R2,R3など)を同時に実行できることを意味する。

0052

表330の行の各々は、プロセス(P1,P2)のシーケンスを指定し、各プロセスは、対応するルールのセットを実行するために示される。例えば、プロセスP1は、対応するプロセスステップとしてルールR1,R2,R4,R6,R3,R5およびR9を実行するために、(列331における同一の識別子P1に基づいて)示される。ルールのうちのいくつかは、先立つルールに対して相互依存性を有するものとして(列333に)示され、これは、1つ以上の先立つルールの実行が完了して初めてルールの実行が開始されることを意味する。例えば、行338は、ルールR4がルールR2に対して相互依存性を有することを示し、ルールR2の実行が完了して初めてルールR4の実行を開始できることを意味する。

0053

上記のシーケンスおよび優先度はルール間の実行順序を徹底する、ということが理解できる。本明細書における開示では、ユーザは、相互依存性を生じさせ得るさまざまな条件を調べて、ルール間に存在する条件に従ってシーケンスを指定するものとする。例えば、ユーザは、2つのルールが、同一のデータオブジェクトにおける同一の属性にマッピングされる程度を更新するか否かを調べ、それに従って、当該2つのルール間に相互依存性が存在することを指定してもよい。代替的な実施例では、実行順序の点でのこのような相互依存性は、各ルールによって更新されるさまざまな程度を検証することによって管理者システム150によって判断されてもよい。

0054

したがって、ユーザは、アプリケーションデータモデルに従って指定されたオブジェクトの属性に対応する所望の程度、程度(および対応してデータオブジェクトの属性)を更新するためのルール、ならびに所望の実行順序に従って実行されるルールのシーケンスを指定する実行定義を指定することが可能になる。ユーザがルールを指定した態様は、例を用いて以下で説明するように、最適な命令セットを生成するように管理者システム150によって処理されてもよい。

0055

5.処理ルール
図3Bは、一実施例における、ルールが処理される態様を示す。特に、プロセスP1について図3Aで指定されたルールの処理が図3Bに示され、以下で詳細に説明する。

0056

管理者システム150は、表330の実行定義を受信したことに応答して、まず、各バケットにおけるルールが実行順序の点で相互依存性をもたないようにプロセスP1のためのルールのバケットを形成する。一般に、列333の優先データに(記号「−」によって)示される、先立つルールを持たないルールは、共通のバケットにグループ分けされる。次いで、優先データに示される、先立つルールを有するルールはいずれも、先立つルールが属しているバケットに基づいて、他のバケットにグループ分けされる。特に、先立つルールは、グループ分けされているルールと同一のバケットには含まれない。

0057

表340は、受信した実行定義(表330)のプロセスP1におけるルールのために形成されるバケットのセットを指定する。各々のバケット(♯1,♯2など)は、ルールの対応するグループ/セット({R1,R2,R3,R9}および{R4,R5,R6}など)を含むものとして示されている。なお、バケット♯1は、(表330に「−」によって示される)優先ルールを持たないルールから形成される。他のルールR4,R5およびR6は、バケット♯2にグループ分けされるものとして示されている。なぜなら、当該ルールは全て、同一のバケット♯1に属する対応する優先ルールを有しているからである。

0058

その後、管理者システム150は、ルールの各バケットを処理し得る。表350および355はともに、バケット♯1におけるルールが処理される態様を示し、表360および365はともに、バケット♯2におけるルールが処理される態様を示す。バケット♯1におけるルールが処理される態様について以下で詳細に説明する。

0059

管理者システム150は、まず、バケット♯1における各ルールによって更新されるデータオブジェクト(および属性)を識別する。識別は、まず、表310に基づいて、各ルールによって更新される程度を識別し、その後、表320に基づいて、更新された程度に対応する特定の属性/データオブジェクトを決定することによって実行されてもよい。表350は、バケット♯1におけるルール(すなわち、{R1,R2,R3,R9})について管理者システム150によって識別されるデータオブジェクト(B1およびB2)ならびに対応する属性(A1,A2など)を示す。

0060

次いで、管理者システム150は、同一のデータオブジェクトを更新するルールのサブセットを決定する。表355は、バケット♯1について決定されたさまざまなルールのサブセットを示す。ルールR1,R3およびR9は、これらのルールが全て同一のデータオブジェクトB1を更新するので第1のサブセットに含まれるように示されており、ルールR2は、ルールR2が異なるデータオブジェクトB2を更新するので第2のサブセットに含まれるように示されていることが分かる。

0061

次いで、管理者システム150は、ルール{R1,R3,R9}について単一の命令セットを生成し、ルール{R2}について別の命令セットを生成する。同様に、管理者システム150は、バケット♯2におけるルール(すなわち、{R4,R5,R6})を(表360および365に示されるように)処理し、サブセット{R4,R6}および{R5}についてそれぞれの命令セットを生成する。プロセスP1について決定される4つのルールのサブセットに対応して、命令セットが4つだけ生成されることが分かる。これは、上記の従前のアプローチにおいて(プロセスP1における7つのルールに対応して)生成されたであろう7つの命令セットとは対照的である。

0062

表380は、決定されたルールのサブセットが実行定義の一部としてユーザに提供される態様を示す。表380は表330と同様であり、したがって、簡潔にするために共通の要素の説明はここでは繰返さない。ルールの各サブセットは、実行定義における対応するプロセス(P1,P2)のもとでのサブプロセス(S11,S12,S21など)として示されていることが分かる。各々のサブプロセスは、管理者システム150によってサブセット内にあるように決定されるさまざまなルールを含むように示されている。例えば、サブプロセスS11は、(表355に示される)バケット♯1について管理者システム150によって決定されたルールのサブセット{R1,R3,R9}に対応する。

0063

一実施例では、管理者システム150は、サブプロセスの一部として指定されるさまざまなルールについて単一の命令セットを生成する。したがって、併合対象である決定されたルールのサブセットは、対応するサブプロセスとして表380に示される。しかし、代替的な実施例では、サブプロセスは、単にサブセットを視覚的に表わすために使用されてもよい。次いで、管理者システム150は、さまざまなサブセットに属するルールを示すさらなるデータ(例えば、サブセットを示す番号)を記憶し、それに従って、当該さらなるデータに基づいて単一の命令セットを生成し得る。

0064

本開示の局面に従って、決定されたルールのサブセットは、例えばエンドユーザシステム110A〜110Zのうちの1つに関連付けられるディスプレイユニット(図1には図示せず)上でユーザに表示される。ルールのサブセットの併合(単一の命令セットの生成)は、(対応するサブセットの)このような併合が実行される予定であることを示す、(ユーザから受信される)入力データに応答して初めて実行される。管理者システム150が決定されたサブセットを表示して、(エンドユーザシステム110A〜110Zを使用する)ユーザから入力データを受信し得る態様について、例を用いて以下で説明する。

0065

6.併合のためのルールの表示
図4Aは、一実施例における、併合に適していると判断されたルールのサブセットがユーザに表示される態様を示す。本明細書における例示的な環境は銀行/金融アプリケーションに対応するが、本明細書に記載されている特徴は、同様のアーキテクチャを利用する他の環境にも適用可能である。

0066

表示領域400は、エンドユーザシステム110A〜110Zのうちの1つ(例示のために110Aであると想定される)に関連付けられるディスプレイユニット(図1には図示せず)に設けられたユーザインターフェイスの一部を示す。一実施例では、表示領域400は、管理者システム150によって提供されるそれぞれのウェブページを表示するブラウザに対応する。ウェブページは、エンドユーザシステム110Aにおけるブラウザを使用してユーザが(例えば、対応するURLを指定することによって)適切な要求を送信したことに応答して提供される。

0067

特に、表示領域400のユーザインターフェイスは、ユーザ/マネージャがプロセス/実行定義の詳細を閲覧する(および編集する)ことを容易にする。表示領域410は、プロセス定義の名前、タイプ、バージョンなどの詳細を提供する。表示領域420は、プロセス定義の一部として指定されるプロセスステップの階層を示す。特に、表示領域420は、プロセスが「Non−Sec移行前RWA−EL」および「Non−Sec移行前RWA−UL」と称される2つのステップを含むことを示す。

0068

表示領域430は、プロセス定義に規定されるプロセスステップの各々の詳細を指定する。特に、表示領域430は、(表示領域420のものと同一の)各オブジェクト/プロセスステップの固有の識別子、(対応するステップの実行前にどの先立つステップ/オブジェクト/ルールを実行すべきかを示す)オブジェクトの優先度、およびオブジェクトのタイプを示す。オブジェクトもプロセスステップも、そのオブジェクトタイプ計算ルールであるように示されていることが分かる。

0069

2つのオブジェクト/ルールのサブセットを併合できる(および単一の命令セットを生成できる)ことを示しながら、(対応するチェック欄を選択することによって)両方のオブジェクトが選択されるように示されていることがさらに分かる。なお、代替的な実施例では、併合できる特定のルールのサブセットを示すために、(同一の色、フォントの使用などの)任意の適切な視覚的強調が使用されてもよい。例えば、併合できないルールは全て、共通の色で表示されてもよく、ルールの各サブセットは、(当該共通の色とは異なる)対応する固有の色で表示されてもよい。

0070

したがって、ユーザは、表示領域400のユーザインターフェイスを使用して、併合対象の特定のサブセットを示すことが可能になる。例えば、ユーザは、(対応するチェック欄の選択を解除することによって)サブセットにおけるルールを除外してもよい。また、ユーザは、サブセットにおける他のルールによって更新される共通のデータオブジェクトを特定のルールが更新しないことに鑑みて、当該特定のルールがルールのサブセットに含まれないことに、(サブセットの表示/視覚的強調に基づいて)気付くことができる。したがって、ユーザは、特定のルールを修正して、(共通のデータオブジェクトを更新する)修正ルールを形成し、次いで、当該修正ルールがサブセットに含まれ(および表示領域430に表示され)るようにサブセットの決定を実行することができる。

0071

ユーザは、併合対象のサブセットを選択した後、「併合ルール」リンク/ボタン450をクリック/選択して、選択されたルールのサブセット(ここでは、「Non−Sec移行前RWA−EL」および「Non−Sec移行前RWA−UL」)が併合対象であることを示す。これに応答して、管理者システム150は、(ユーザから受信される入力データによって、表示領域430に)併合対象であるように示されるルールのサブセットの各々に対応するサブプロセスを作成する。次いで、管理者システム150は、以下で詳細に説明するように、作成されたサブプロセスをユーザに表示し得る。

0072

図4Bは、一実施例における、ルールのサブセットの併合結果がユーザに表示される態様を示す。特に、図4Bは、図4Aにおける「併合ルール」リンク450をユーザがクリックしたことに応答した結果を示す。

0073

表示領域470は、対応するルールのサブセットの併合後のプロセスステップの階層を示す。表示領域470は、「併合後Exeサブプロセス」と称される新たなプロセスステップが作成され、当該新たなプロセスステップの下に、「Non−Sec移行前RWA−EL」および「Non−Sec移行前RWA−UL」という以前の2つのステップが表示されることを示すことが分かる。表示領域480は、「併合後Exeサブプロセス」という新たなプロセスステップが(タイプによって示されるように)サブプロセスであることを示す。

0074

したがって、ユーザは、プロセス定義のさまざまなサブプロセスの形式でルールのサブセットの併合結果が表示される。その後、ユーザは、「保存」ボタン490をクリック/選択し得て、併合対象のさまざまなルールのサブセットを含むプロセス定義がプロセス定義の一部として保存/記憶されることを示す。(図4Bの)保存されたプロセス/実行定義を実行したことに応答して、管理者システム150は、「併合後Exeサブプロセス」というプロセスステップについて単一の命令セットを生成し、次いで、対応する計算に基づいて特定の程度を更新するように(他の単一の命令セットと同時に)当該単一の命令セットを実行する。

0075

一実施例では、企業アプリケーションによって使用されるデータオブジェクトは、リレーショナルデータベースサーバに記憶される。したがって、各ルールは、独立して実行されると、リレーショナルデータベースサーバに向けられる対応するSQL(構造化照会言語)コマンドとして実現される。付表Aは、「Non−Sec移行前RWA−EL」というルールが独立して実行される場合に管理者システム150によって生成および実行され得るSQLコマンドを示す。同様に、付表Bは、「Non−Sec移行前RWA−UL」というルールのために生成され得るSQLコマンドを示す。単一の命令セットも、実行時に、リレーショナルデータベースサーバに向けられる単一のSQLコマンドの形式で実現される。付表Cは、「併合後Exeサブプロセス」という併合されたルール/サブプロセスのサブセットについての単一の命令セットとして生成され得るSQLコマンドを示す。次いで、SQLコマンドが実行され、概要欄に上記した効率のうちの1つ以上が場合によっては実現される。

0076

上記の特徴は、ハードウェア、実行可能なモジュールおよびファームウェアのうちの1つ以上の所望の組み合わせとしてさまざまな実施例において実現可能であるということがさらに理解されるべきである。実行可能なモジュールにおける命令が実行されたときにさまざまな特徴が機能する実施例に関して説明を続ける。

0077

7.デジタル処理システム
図5は、適切なソフトウェア命令の実行によって本開示のいくつかの局面が機能するデジタル処理システム500の詳細を示すブロック図である。デジタル処理システム500は、管理者システム150に対応する。

0078

デジタル処理システム500は、(中央処理装置(central processing unit:CPU)510などの)1つ以上のプロセッサと、ランダムアクセスメモリ(random access memory:RAM)520と、二次メモリ530と、グラフィックスコントローラ560と、ディスプレイユニット570と、ネットワークインターフェイス580と、入力インターフェイス590とを含み得る。ディスプレイユニット570以外のコンポーネントは全て、通信経路550を介して互いに通信することができ、当該通信経路550は、関連技術で周知であるようにいくつかのバスを含み得る。図5のコンポーネントについて以下でさらに詳細に説明する。

0079

CPU510は、本開示のいくつかの特徴を提供するように、RAM520に記憶された命令を実行し得る。CPU510は、複数の処理ユニットを含んでいてもよく、各処理ユニットは、場合によっては、特定のタスク向けに設計される。代替的に、CPU510は、単一の汎用処理ユニットのみを含んでいてもよい。RAM520は、通信経路550を使用して二次メモリ530から命令を受信し得る。

0080

RAM520は、共有環境525および/または(金融アプリケーション、分析フレームワークなどの)ユーザプログラム526を構成するソフトウェア命令を現在のところ含むものとして示されている。共有環境525は、ユーザプログラムによって共有されるユーティリティを含み、このような共有ユーティリティは、ユーザプログラム526を実行するための(共通の)ランタイム環境を提供する、オペレーティングシステムデバイスドライバ仮想マシンフローエンジンなどを含む。

0081

グラフィックスコントローラ560は、CPU510から受信されるデータ/命令に基づいて、ディスプレイユニット570に対する(例えば、RGBフォーマットの)表示信号を生成する。ディスプレイユニット570は、(図4A図4Bのユーザインターフェイスの部分などの)表示信号によって定義される画像を表示するためのディスプレイ画面を含む。入力インターフェイス590は、(図4A図4Bのユーザインターフェイスにおいて所望の入力などを指定するなど)さまざまな入力を提供するために使用可能なキーボードおよびポインティング装置(例えば、タッチパッドマウス)に対応し得る。ネットワークインターフェイス580は、(例えば、インターネットプロトコルを使用して)ネットワークとの接続を提供し、(サーバシステム130A〜130C、データストア180A〜180Bなどの)他の接続されたシステムとの通信に使用可能である。

0082

二次メモリ530は、ハードドライブ535と、フラッシュメモリ536と、リムーバブルストレージドライブ537とを含み得る。二次メモリ530は、非一時的な媒体を表わし、デジタル処理システム500が本開示に従ったいくつかの特徴を提供することができるようにデータ(例えば、図3A図3Bに示されるデータの部分)および(例えば、図2のステップを実行するための)ソフトウェア命令を記憶し得る。二次メモリ530に記憶されるコード/命令は、実行速度高速化のために、CPU510による実行に先立ってRAM520にコピーされてもよく、またはCPU510によって直接実行されてもよい。

0083

二次メモリ530は、ハードドライブ535と、フラッシュメモリ536と、リムーバブルストレージドライブ537とを含み得る。データおよび命令の一部または全ては、リムーバブルストレージユニット540に提供されてもよく、データおよび命令は、リムーバブルストレージドライブ537によって読み出されてCPU510に提供されてもよい。リムーバブルストレージユニット540は、リムーバブルストレージドライブ537がデータおよび命令を読み出すことができるように、リムーバブルストレージドライブ537に適合した媒体およびストレージフォーマットを使用して実現されてもよい。したがって、リムーバブルストレージユニット540は、コンピュータソフトウェアおよび/またはデータが記憶されたコンピュータ読取可能な(記憶)媒体を含む。しかし、コンピュータ(または、一般に機械)読取可能な媒体は、他の形態(例えば、非リムーバブルランダムアクセスなど)であってもよい。

0084

本文献では、「コンピュータプログラム製品」という語は、概してリムーバブルストレージユニット540またはハードドライブ535にインストールされたハードディスクを指すように用いられる。これらのコンピュータプログラム製品は、デジタル処理システム500にソフトウェアを提供するための手段である。CPU510は、ソフトウェア命令を検索し、命令を実行して、上記の本開示のさまざまな特徴を提供してもよい。

0085

本明細書で用いられる「記憶媒体」という語は、特定の態様でマシンを動作させるデータおよび/または命令を記憶する任意の非一時的な媒体を指す。このような記憶媒体は、不揮発性媒体および/または揮発性媒体を含み得る。不揮発性媒体は、例えば、ストレージメモリ530などの、光ディスク磁気ディスク、またはソリッドステートドライブを含む。揮発性媒体は、RAM520などのダイナミックメモリを含む。記憶媒体の共通の形態は、例えば、フロッピー登録商標ディスクフレキシブルディスク、ハードディスク、ソリッドステートドライブ、磁気テープまたはその他の磁気データ記憶媒体CD−ROM、その他の光学式データ記憶媒体、穴のパターンを有する任意の物理的媒体、RAM、PROMおよびEPROMフラッシュEPROM、NVRAM、その他のメモリチップまたはカートリッジを含む。

0086

記憶媒体は、伝送媒体とは別であるが、伝送媒体と併用されてもよい。伝送媒体は、記憶媒体間で情報を転送することに関与する。例えば、伝送媒体は、バス550を備えるワイヤを含む、同軸ケーブル銅線および光ファイバを含む。また、伝送媒体は、電波および赤外線データ通信中に生成されるような音波または光波の形態をとってもよい。

0087

本明細書全体を通して「一実施例」、「実施例」または同様の言い回しに言及することは、当該実施例に関連して記載される特定の特徴、構造または特性が本開示の少なくとも1つの実施例に含まれることを意味する。したがって、本明細書全体を通じた「一実施例では」、「実施例では」というおよび同様の言い回しの登場は、全てが同一の実施例を指してもよいが、必ずしも同一の実施例を指すとは限らない。

0088

さらに、本開示の記載されている特徴、構造または特性は、1つ以上の実施例において任意の好適な態様で組み合わせられてもよい。上記の説明では、本開示の実施例の完璧な理解を提供するために、プログラミングソフトウェアモジュールユーザ選択ネットワークトランザクションデータベースクエリデータベース構造ハードウェアモジュールハードウェア回路、ハードウェアチップなどの例などの多数の具体的な詳細が提供されている。

0089

8.結論
本開示のさまざまな実施例について上記してきたが、それらは限定的ではなく単に一例として提示されているということが理解されるべきである。したがって、本開示の広さおよび範囲は、上記の例示的な実施例のうちのいずれかによって限定されるべきではなく、以下の特許請求の範囲およびそれらの等価物に従ってのみ規定されるべきである。

0090

本開示の機能および利点を強調する添付物に示される図面および/またはスクリーンショットは、単に例示的な目的で提示されているということが理解されるべきである。本開示は、十分に柔軟性があり、構成可能であるので、添付の図面に示されている態様以外の態様で利用できる。

0091

さらに、以下の要約書の目的は、特許および公衆、一般におよび特に、特許または法律用語または語法に精通していない当該技術分野における科学者技術者および専門家が、本願の技術的開示の性質および本質を大まかな検証により素早く判断できるようにすることである。要約書は、本開示の範囲について限定的であるよう意図されたものでは決してない。

0092

0093

0094

0095

0096

0097

0098

0099

0100

0101

0102

0103

0104

ページトップへ

この技術を出願した法人

この技術を発明した人物

ページトップへ

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

関連する公募課題

ページトップへ

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

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

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

(分野番号表示ON)※整理標準化データをもとに当社作成

ページトップへ

おススメ サービス

おススメ astavisionコンテンツ

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

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

関連性が強い 技術一覧

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

関連性が強い人物一覧

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

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

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

関連する公募課題一覧

astavision 新着記事

サイト情報について

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

主たる情報の出典

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