System for transform generation
46 claims: 6 independent, 40 dependent
- 1データを変換するための規則セットをコード化する、1つ以上のデータ処理装置によって実行される方法であって、 実行ケースのシーケンスの内部の少なくとも1つの実行ケースが、1つ以上のトリガ条件と、前記1つ以上のトリガ条件がすべて満たされると生成される出力の仕様とを含む前記実行ケースのシーケンスを含む規則セットを受信することと、 前記規則セット内の1つ以上の実行ケースに対応する行のシーケンスを含む制御構造を生成することであって、各行が、1つ以上のトリガ条件のシーケンスと、対応する実行ケースの出力を規定する情報とを含み、前記生成された制御構造が、前記トリガ条件の1つが失敗したときに異なる行で継続するように処理を誘導するように構成され、前記生成された制御構造が、前記制御構造内の前記トリガ条件の少なくとも1つについて、前記少なくとも1つのトリガ条件が失敗したときに、前記制御構造が、 前記失敗したトリガ条件を有する 行の前記シーケンス内の少なくとも1つの 残りの 行をスキップさせるように処理を誘導するように構成されたことと、 前記制御構造を記憶又は送信することと、 を含む、方法。
- 2入力データを受信することと、 前記制御構造を用いて決定したシーケンス内の前記入力データに照らしてトリガ条件を検査することと、 前記制御構造によって規定された出力に基づいてデータを記憶又は送信することと、 をさらに含む、請求項1に記載の方法。
- 3前記行の少なくとも1つが、前記対応する実行ケースのトリガ条件を除外し、前記除外されたトリガ条件が実行ケースの前記シーケンス内の前記対応する実行ケースより前の実行ケース内で発生する、請求項1に記載の方法。
- 4行内のトリガ条件の前記シーケンスが、各々が前記規則セットの一意的なトリガ条件のリスト内のあるトリガ条件へ処理を誘導するコードの部分のシーケンスである、請求項1に記載の方法。
- 5行内の前記出力を規定する前記情報が、前記規則セットの一意的な出力のリスト内の出力式へ処理を誘導するコードの部分である、請求項1に記載の方法。
- 6データ処理中に前記シーケンス内のトリガ条件が失敗したときに処理が誘導される異なる行に基づいて行のトリガ条件の前記シーケンスをソートすることをさらに含む、請求項1に記載の方法。
- 7前記トリガ条件の実行時間に基づいて行のトリガ条件の前記シーケンスをソートすることをさらに含む、請求項1に記載の方法。
- 8入力データを受信することと、 前記制御構造を用いて決定したシーケンス内の前記入力データに照らしてトリガ条件を検査することと、 前記入力データで前記トリガ条件を実行するのにかかる時間に基づいて一意的なトリガ条件の リスト内 のトリガ条件の前記実行時間を更新することと、 前記更新された実行時間に基づいて前記制御構造内の行のトリガ条件への ポインタ をソートすることと、 をさらに含む、請求項7に記載の方法。
- 9トリガ条件の失敗率に基づいて行のトリガ条件の前記シーケンスをソートすることをさらに含む、請求項1に記載の方法。
- 10入力データを受信することと、 前記制御構造を用いて決定したシーケンス内の前記入力データに照らしてトリガ条件を検査することと、 前記入力データ内のレコードによって前記トリガ条件が満たされるか否かに基づいて一意的なトリガ条件の リスト内 のトリガ条件の失敗率を更新することと、 前記更新された失敗率に基づいて前記制御構造内の行のトリガ条件への ポインタ をソートすることと、 をさらに含む、請求項9に記載の方法。
- 11前記制御構造の行が、前記行のすべての前記トリガ条件が満たされると次に処理する前記制御構造の異なる行へ処理を誘導するコードの部分をさらに含む、請求項1に記載の方法。
- 12前記規則セットが、グラフィカルユーザインターフェイスを介して規定される、請求項1に記載の方法。
- 13前記規則セット内の実行ケースの少なくとも2つのトリガ条件が組み合わされて、前記制御構造内の単一のトリガ条件で表される、請求項1に記載の方法。
- 14前記規則セット内の異なる実行ケースの少なくとも2つの出力が組み合わされて、前記制御構造内の行内の単一の出力式で表される、請求項1に記載の方法。
- 15前記制御構造が、ノードが前記制御構造の行内の前記トリガ条件及び出力式に対応する非周期的有向グラフである、請求項1に記載の方法。
- 16データを変換するための規則セットをコード化するソフトウェアを記憶したコンピュータ可読媒体であって、前記ソフトウェアが、コンピューティングシステムに、 実行ケースのシーケンスの内部の少なくとも1つの実行ケースが、1つ以上のトリガ条件と、前記1つ以上のトリガ条件がすべて満たされると生成される出力の仕様とを含む前記実行ケースのシーケンスを含む規則セットを受信させ、 前記規則セット内の1つ以上の実行ケースに対応する行のシーケンスを含む制御構造を生成させ、各行が、1つ以上のトリガ条件のシーケンスと、対応する実行ケースの出力を規定する情報とを含み、前記生成された制御構造が、入力データを変換する将来の処理中に、前記トリガ条件の1つが失敗したときに異なる行で継続するように処理を誘導するように構成され、前記生成された制御構造が、前記制御構造内の前記トリガ条件の少なくとも1つについて、前記少なくとも1つのトリガ条件が失敗したときに、前記制御構造が、 前記失敗したトリガ条件を有する 行の前記シーケンス内の少なくとも1つの 残りの 行をスキップさせるように処理を誘導するように構成され、 前記制御構造を記憶又は送信させる命令を含む、媒体。
- 17コンピューティングシステムに、 入力データを受信させ、 前記制御構造を用いて決定したシーケンス内の入力データに照らしてトリガ条件を検査させ、 前記制御構造によって規定された出力に基づいてデータを記憶又は送信させる命令を含む、請求項16に記載の媒体。
- 18前記行の少なくとも1つが、前記対応する実行ケースのトリガ条件を除外し、前記除外されたトリガ条件が実行ケースのシーケンス内の前記対応する実行ケースより前の実行ケース内で発生する、請求項16に記載の媒体。
- 19行内のトリガ条件の前記シーケンスが、各々が前記規則セットの一意的なトリガ条件のリスト内のあるトリガ条件へ処理を誘導するコードの部分のシーケンスである、請求項16に記載の媒体。
- 20行内の前記出力を規定する前記情報が、前記規則セットの一意的な出力のリスト内の出力式へ処理を誘導するコードの部分である、請求項16に記載の媒体。
- 21コンピューティングシステムに、 データ処理中に前記シーケンス内のトリガ条件が失敗したときに処理が誘導される異なる行に基づいて行のトリガ条件の前記シーケンスをソートさせる命令を含む、請求項16に記載の媒体。
- 22コンピューティングシステムに、 前記トリガ条件の実行時間に基づいて行のトリガ条件の前記シーケンスをソートさせる命令を含む、請求項16に記載の媒体。
- 23コンピューティングシステムに、 入力データを受信させ、 前記制御構造を用いて決定したシーケンス内の前記入力データに照らしてトリガ条件を検査させ、 前記入力データで前記トリガ条件を実行するのにかかる時間に基づいて一意的なトリガ条件の リスト内 のトリガ条件の実行時間を更新させ、 前記更新された実行時間に基づいて前記制御構造内の行のトリガ条件への ポインタ をソートさせる命令を含む、請求項22に記載の媒体。
- 24コンピューティングシステムに、 前記トリガ条件の失敗率に基づいて行のトリガ条件の前記シーケンスをソートさせる命令を含む、請求項16に記載の媒体。
- 25コンピューティングシステムに、 入力データを受信させ、 前記制御構造を用いて決定したシーケンス内の前記入力データに照らしてトリガ条件を検査させ、 前記入力データ内のレコードによって前記トリガ条件が満たされるか否かに基づいて一意的なトリガ条件の リスト内 のトリガ条件の失敗率を更新させ、 前記更新された失敗率に基づいて前記制御構造内の行のトリガ条件への ポインタ をソートさせる命令を含む、請求項24に記載の媒体。
- 26前記制御構造の行が、前記行のすべてのトリガ条件が満たされると、次に処理する前記制御構造の異なる行へ処理を誘導するコードの部分をさらに含む、請求項16に記載の媒体。
- 27前記規則セットがグラフィカルユーザインターフェイスを介して規定される、請求項16に記載の媒体。
- 28前記規則セット内の実行ケースの少なくとも2つのトリガ条件が組み合わされて、前記制御構造内の単一のトリガ条件で表される、請求項16に記載の媒体。
- 29前記規則セット内の異なる実行ケースの少なくとも2つの出力が組み合わされて、前記制御構造の行内の単一の出力式で表される、請求項16に記載の媒体。
- 30前記制御構造が、ノードが前記制御構造の前記行内の前記トリガ条件及び出力式に対応する非周期的有向グラフである、請求項16に記載の媒体。
- 31データを変換するための規則セットをコード化するコンピューティングシステムであって、 実行ケースのシーケンスの内部の少なくとも1つの実行ケースが、1つ以上のトリガ条件と、前記1つ以上のトリガ条件がすべて満たされると生成される出力の仕様とを含む前記実行ケースのシーケンスを含む規則セットを受信するように構成された入力デバイス又はポートと、 前記規則セット内の1つ以上の実行ケースに対応する行のシーケンスを含む制御構造を生成する手段であって、各行が、1つ以上のトリガ条件のシーケンスと、対応する実行ケースの出力を規定する情報とを含み、前記生成された制御構造が、入力データを変換する将来の処理中に、前記トリガ条件の1つが失敗したときに異なる行で継続するように処理を誘導するように構成され、前記生成された制御構造が、前記制御構造内の前記トリガ条件の少なくとも1つについて、前記少なくとも1つのトリガ条件が失敗したときに、前記制御構造が、 前記失敗したトリガ条件を有する 行の前記シーケンス内の少なくとも1つの 残りの 行をスキップさせるように処理を誘導するように構成された手段と、 前記制御構造を記憶するように構成されたデータ記憶システムと、 を含む、コンピューティングシステム。
- 32入力データを受信するように構成された入力デバイス又はポートと、 前記制御構造を用いて決定したシーケンス内の前記入力データに照らしてトリガ条件を検査することを含む動作を実行するように構成された少なくとも1つのプロセッサと、 前記制御構造によって規定された出力に基づいてデータを送信するように構成された出力デバイス又はポートとを含む、請求項31に記載のシステム。
- 33前記行の少なくとも1つが、前記対応する実行ケースのトリガ条件を除外し、前記除外されたトリガ条件が、実行ケースの前記シーケンス内の前記対応する実行ケースより前の実行ケース内で発生する、請求項31に記載のシステム。
- 34行内のトリガ条件の前記シーケンスが、各々が前記規則セットの一意的なトリガ条件のリスト内のあるトリガ条件へ処理を誘導するコードの部分のシーケンスである、請求項31に記載のシステム。
- 35行内の前記出力を規定する前記情報が、前記規則セットの一意的な出力のリスト内の出力式へ処理を誘導するコードの部分である、請求項31に記載のシステム。
- 36データ処理中に前記シーケンス内のトリガ条件が失敗したときに処理が誘導される異なる行に基づいて行のトリガ条件の前記シーケンスをソートする手段を含む、請求項31に記載のシステム。
- 37前記トリガ条件の実行時間に基づいて行のトリガ条件の前記シーケンスをソートする手段を含む、請求項31に記載のシステム。
- 38入力データを受信するように構成された入力デバイス又はポートと、 動作を実行するように構成された少なくとも1つのプロセッサであって、前記動作が、 前記制御構造を用いて決定したシーケンス内の前記入力データに照らしてトリガ条件を検査することと、 前記入力データでトリガ条件を実行するのにかかる時間に基づいて一意的なトリガ条件の リスト内 のトリガ条件の前記実行時間を更新することとを含む少なくとも1つのプロセッサと、 前記更新された実行時間に基づいて前記制御構造内の行のトリガ条件への ポインタ をソートする手段と、を含む、請求項37に記載のシステム。
- 39トリガ条件の失敗率に基づいて行の前記トリガ条件の前記シーケンスをソートする手段を含む、請求項31に記載のシステム。
- 40前記 コンピューティングシステム が、 入力データを受信するように構成された入力デバイス又はポートと、 複数の 動作を実行するように構成された少なくとも1つのプロセッサであって、前記 複数の 動作が、前記制御構造を用いて決定したシーケンス内の前記入力データに照らしてトリガ条件を検査することと、前記入力データ内のレコードによって前記トリガ条件が満たされるか否かに基づいて一意的なトリガ条件の リスト内 のトリガ条件の失敗率を更新することとを含む、少なくとも1つのプロセッサと、 前記更新された失敗率に基づいて前記制御構造内の行のトリガ条件への ポインタ をソートする手段と、 をさらに含む、請求項39に記載のシステム。
- 41前記制御構造の行が、前記行のすべての前記トリガ条件が満たされると次に処理する前記制御構造の異なる行へ処理を誘導するコードの部分をさらに含む、請求項31に記載のシステム。
- 42前記規則セットが、グラフィカルユーザインターフェイスを介して規定される、請求項31に記載のシステム。
- 43前記規則セット内の実行ケースの少なくとも2つのトリガ条件が組み合わされて、前記制御構造内の単一のトリガ条件で表される、請求項31に記載のシステム。
- 44前記規則セット内の異なる実行ケースの少なくとも2つの出力が組み合わされて、前記制御構造の行内の単一の出力式で表される、請求項31に記載のシステム。
- 45前記制御構造が、ノードが前記制御構造の前記行内の前記トリガ条件及び出力式に対応する非周期的有向グラフである、請求項31に記載のシステム。
- 46前記制御構造を生成する前記手段は、少なくとも1つのプロセッサを含む、請求項31から45のいずれか一項に記載のシステム。
Independent claims46
143 paragraphs, as filed
(Cross-reference of related applications) This application claims the priority of US Patent Application No. 13 / 958,037 filed on August 2, 2013, which is the priority of US Provisional Application No. 61 / 751,814 filed on January 11, 2013 and December 2012. Claim the priority of US Provisional Application No. 61 / 735,451 filed on the 10th, which is incorporated herein by reference in its entirety.
The present specification relates to a system for generating a transformation of data based on a rule set.
Complex operations are often data flows by directed graphs (called "data flow graphs") where the components of the operation are associated with the vertices of the graph and the data flow between the components corresponds to the links (arc, edges) of the graph. Can be expressed as. A component is a data processing component that receives data on one or more input ports, processes the data, and provides data from one or more output ports, and a dataset component that acts as a source or sink for the data flow. May include. Systems that perform such graph-based operations are described in US Pat. No. 5,966,072, "EXECUTING COMPUTATIONS EXPRESSED AS GRAPHS."
In general aspect 1, a method performed by one or more data processors that encodes a set of rules for transforming data is such that at least one execution case within it is one or more trigger conditions. To receive a rule set containing a sequence of execution cases, including the specifications of the output generated when all one or more trigger conditions are met, and the line corresponding to one or more execution cases in the rule set. Is to generate a control structure containing a sequence of, including that each row contains a sequence of one or more trigger conditions and information defining the output of the corresponding execution case. Is configured to guide the process to continue on a different row if one of the trigger conditions fails during future processing that transforms the input data, and the generated control structure is the trigger in the control structure. For at least one of the conditions, the control structure is configured to guide the process to skip at least one row in the sequence of rows when at least one trigger condition fails, and the control structure. Includes storing or transmitting.
Receiving input data, inspecting trigger conditions against the input data in a sequence determined using the control structure, and storing or transmitting data based on the output specified by the control structure. Aspect 2 according to Aspect 1, further comprising.
One of aspects 1-2, in which at least one of the rows excludes the trigger condition for the corresponding execution case, and the excluded trigger condition occurs in an execution case that precedes the corresponding execution case in the sequence of execution cases. Aspect 3 according to item 1.
The sequence of trigger conditions in a line is described in any one of aspects 1 to 3, wherein each is a sequence of parts of the code that guide processing to a certain trigger condition in the list of unique trigger conditions in the rule set. Aspect 4.
Aspect 5 according to any one of aspects 1 to 4, wherein the information defining the output in a line is a portion of the code that directs processing to an output expression in the list of unique outputs of the ruleset.
The item according to any one of aspects 1 to 5, further comprising sorting the sequence of row trigger conditions based on different rows to which processing is guided when the trigger condition in the sequence fails during data processing. Aspect 6.
7. Aspects 7 of any one of aspects 1-6, further comprising sorting a sequence of trigger conditions in a row based on the execution time of the trigger condition.
A unique trigger based on receiving the input data, inspecting the trigger condition against the input data in the sequence determined using the control structure, and executing the trigger condition on the input data. Any of aspects 1-7, further comprising updating the execution time of the trigger condition in the list of conditions and sorting the pointer to the trigger condition of the row in the control structure based on the updated execution time. Aspect 8 according to item 1.
9. Aspects 9 of any one of aspects 1-8, further comprising sorting a sequence of trigger conditions in a row based on the failure rate of the trigger condition.
Unique based on receiving the input data, inspecting the trigger condition against the input data in the sequence determined using the control structure, and whether the records in the input data satisfy the trigger condition. Aspects 1-9, which further include updating the failure rate of the trigger condition in the list of trigger conditions and sorting the pointers to the trigger conditions of the rows in the control structure based on the updated failure rate. 10. The aspect according to any one of the above.
The embodiment according to any one of aspects 1 to 10, wherein the control structure row further includes a portion of code that guides processing to a different row of control structure to be processed next when all the trigger conditions of the row are satisfied. 11.
12. Aspects 12 according to any one of aspects 1-11, wherein the rule set is defined via a graphical user interface.
13. Aspect according to any one of aspects 1-12, wherein at least two trigger conditions of the execution case in the rule set are combined and represented by a single trigger condition in the control structure.
Aspects 14 according to any one of aspects 1-13, wherein at least two outputs of different execution cases in the rule set are combined and represented by a single output expression in a row in the control structure.
15. Aspects 15 according to any one of aspects 1-14, wherein the control structure is an aperiodic directed graph in which the nodes correspond to the trigger conditions and output equations in the rows of the control structure.
A general aspect 16 is a system that includes a data processing device and a memory coupled to the data processing device. When executed by a data processor, the data processor is given at least one execution case within it a trigger condition of one or more and an output specification that is generated when all of the trigger conditions are met. A memory in which instructions that perform an operation, including receiving a set of rules containing a sequence of execution cases, are stored on it. The behavior may further include generating a control structure containing a sequence of rows corresponding to one or more execution cases in the rule set, where each row has a sequence of one or more trigger conditions and a corresponding execution case. The generated control structure, including the information that defines the output of, now guides the process to continue on a different line if one of the trigger conditions fails during future processes that transform the input data. The configured and generated control structure causes the control structure to skip at least one row in the sequence of rows if at least one trigger condition fails for at least one of the trigger conditions in the control structure. It is configured to guide the process. The operation may further include storing or transmitting the control structure.
The operation receives the input data, inspects the trigger condition against the input data in the sequence determined using the control structure, and stores or transmits the data based on the output specified by the control structure. Aspects 17 according to Aspect 16, further comprising:
One of aspects 16-17, where at least one of the rows excludes the trigger condition for the corresponding execution case, and the excluded trigger condition occurs in an execution case that precedes the corresponding execution case in the sequence of execution cases. Aspect 18 according to item 1.
The sequence of trigger conditions in a line is described in any one of aspects 16-18, each of which is a sequence of parts of code that direct processing to a trigger condition in a list of unique trigger conditions in a rule set. Aspect 19.
20. Aspect 20 according to any one of aspects 16-19, wherein the information defining the output in a line is a portion of the code that directs processing to an output expression in the list of unique outputs of the ruleset.
Any one of aspects 16-20, further comprising sorting the sequence of row trigger conditions based on different rows to which processing is guided when the trigger condition in the sequence fails during data processing. 21.
22. The aspect 22 of any one of aspects 16-21, wherein the operation further comprises sorting a sequence of trigger conditions in a row based on the execution time of the trigger condition.
The operation is unique based on receiving the input data, inspecting the trigger condition against the input data in the sequence determined using the control structure, and the time it takes to execute the trigger condition on the input data. Aspect 16 ~, which further comprises updating the execution time of the trigger condition in the list of typical trigger conditions and sorting the pointers to the trigger conditions of the rows in the control structure based on the updated execution time. 23. The aspect 23 according to any one of 22.
24. The aspect 24 of any one of aspects 16-23, wherein the operation further comprises sorting a sequence of trigger conditions in a row based on the failure rate of the trigger condition.
The operation is based on receiving the input data, inspecting the trigger condition against the input data in the sequence determined using the control structure, and whether the record in the input data satisfies the trigger condition. Further including updating the failure rate of the trigger condition in the unique list of trigger conditions and sorting the pointers to the trigger conditions of the rows in the control structure based on the updated failure rate. Aspect 25 according to any one of 16 to 24.
The embodiment according to any one of aspects 16 to 25, wherein the control structure row further includes a portion of code that guides processing to a different row of control structure to be processed next when all the trigger conditions of the row are met. 26.
27. The aspect 27 of any one of aspects 16-26, wherein the rule set is defined via a graphical user interface.
28. The aspect 28 of any one of aspects 16-27, wherein at least two trigger conditions of the execution case in the rule set are combined and represented by a single trigger condition in the control structure.
Aspect 29, according to any one of aspects 16-28, wherein at least two outputs of different execution cases in the rule set are combined and represented by a single output expression in a row of control structures.
30. Aspects 30 according to any one of aspects 16-29, wherein the control structure is an aperiodic directed graph in which the nodes correspond to the trigger conditions and output equations in the rows of the control structure.
In general aspect 31, an instruction that can be executed by a processing device, when executed, has at least one execution case inside the processing device with one or more trigger conditions and one or more. A computer-readable storage medium containing software containing instructions to perform an operation, including receiving a set of rules containing a sequence of execution cases, including specifications of the output generated when all trigger conditions are met. The behavior may further include generating a control structure containing a sequence of rows corresponding to one or more execution cases in the rule set, where each row has a sequence of one or more trigger conditions and a corresponding execution case. The generated control structure, including the information that defines the output of, now guides the process to continue on a different line if one of the trigger conditions fails during future processes that transform the input data. The configured and generated control structure causes the control structure to skip at least one row in the sequence of rows if at least one trigger condition fails for at least one of the trigger conditions in the control structure. It is configured to guide the process. The operation may further include storing or transmitting the control structure.
The operation receives the input data, inspects the trigger condition against the input data in the sequence determined using the control structure, and stores or transmits the data based on the output specified by the control structure. 32. The aspect 32 according to the aspect 31, further comprising the above.
Any of aspects 31-32, where at least one of the rows excludes the trigger condition for the corresponding execution case, and the excluded trigger condition occurs in an execution case that precedes the corresponding execution case in the sequence of execution cases. 33.
The sequence of trigger conditions in a line is described in any one of aspects 31-33, each of which is a sequence of parts of the code that direct processing to a trigger condition in the list of unique trigger conditions in the rule set. Aspect 34.
Aspect 35 according to any one of aspects 31-34, wherein the information defining the output in a line is a portion of the code that directs processing to an output expression in the list of unique outputs of the ruleset.
Any one of aspects 31-35, further comprising sorting the sequence of row trigger conditions based on different rows to which processing is guided when the trigger condition in the sequence fails during data processing. 36.
37. The aspect 37 of any one of aspects 31-36, wherein the operation further comprises sorting a sequence of trigger conditions in a row based on the execution time of the trigger condition.
The operation is unique based on receiving the input data, inspecting the trigger condition against the input data in the sequence determined using the control structure, and the time it takes to execute the trigger condition on the input data. Aspect 31 ~, which further comprises updating the execution time of the trigger condition in the list of typical trigger conditions and sorting the pointers to the trigger conditions of the rows in the control structure based on the updated execution time. 38. The aspect 38 according to any one of 37.
39. The aspect 39 of any one of aspects 31-38, wherein the operation further comprises sorting a sequence of trigger conditions in a row based on the failure rate of the trigger condition.
The operation is based on receiving the input data, inspecting the trigger condition against the input data in the sequence determined using the control structure, and whether the record in the input data satisfies the trigger condition. Further including updating the failure rate of the trigger condition in the list of unique trigger conditions and sorting the pointers to the trigger conditions of the rows in the control structure based on the updated failure rate. Aspect 40 according to any one of 31 to 39.
The embodiment according to any one of aspects 31 to 40, wherein the control structure row further includes a portion of code that guides processing to a different row of control structure to be processed next when all the trigger conditions of the row are met. 41.
42. The aspect 42 of any one of aspects 31-41, wherein the rule set is defined via a graphical user interface.
13. Aspect 43, according to any one of aspects 31-42, wherein at least two trigger conditions of the execution case in the rule set are combined and represented by a single trigger condition in the control structure.
Aspect 44 according to any one of aspects 31-43, wherein at least two outputs of different execution cases in the rule set are combined and represented by a single output expression in a row of control structures.
Aspect 45 according to any one of aspects 31-44, wherein the control structure is an aperiodic directed graph in which the nodes correspond to the trigger conditions and output equations in the rows of the control structure.
46. The aspect 46 of any one of aspects 1-15, wherein the control structure is part of a transform that is performed in parallel on a plurality of processing devices.
47. Aspects 47, according to any one of aspects 16-30, wherein the control structure is part of a transform that is performed in parallel on a plurality of processing devices.
48. The aspect 48 of any one of aspects 31-45, wherein the control structure is part of a transform that is performed in parallel on a plurality of processing devices.
In one aspect, in general, a method of generating a transform based on a rule set is generated when at least one execution case within it meets one or more trigger conditions and all of one or more trigger conditions. Includes receiving a rule set containing a sequence of execution cases, including output specifications. The method may further include generating a control structure containing a sequence of rows corresponding to one or more execution cases in the rule set, where each row has a sequence of one or more trigger conditions and a corresponding execution case. The generated control structure, including the information that defines the output of, now guides the process to continue on a different line if one of the trigger conditions fails during future processes that transform the input data. The configured and generated control structure causes the control structure to skip at least one row in the sequence of rows if at least one trigger condition fails for at least one of the trigger conditions in the control structure. It is configured to guide the process. The method may further include storing or transmitting control structures.
In general, one aspect of the subject matter described herein can be embodied within a system that includes a data processing device and a memory coupled to the data processing device. When executed by a data processor, the data processor is given at least one execution case inside it a trigger condition of one or more and an output specification that is generated when all of the trigger conditions are met. A memory in which instructions that perform an operation, including receiving a set of rules containing a sequence of execution cases, are stored on it. The behavior may further include generating a control structure containing a sequence of rows corresponding to one or more execution cases in the rule set, where each row has a sequence of one or more trigger conditions and a corresponding execution case. The generated control structure, including the information that defines the output of, now guides the process to continue on a different line if one of the trigger conditions fails during future processes that transform the input data. The configured and generated control structure causes the control structure to skip at least one row in the sequence of rows if at least one trigger condition fails for at least one of the trigger conditions in the control structure. It is configured to guide the process to. The operation may further include storing or transmitting the control structure.
In general, one aspect of the subject matter described herein is an instruction that can be executed by a processing device that, when executed, triggers the processing device to have at least one execution case within it. A computer-readable software that contains instructions to perform an operation, including receiving a rule set containing a sequence of execution cases, including a condition and a specification of the output generated when all one or more trigger conditions are met. It can be embodied in a storage medium. The behavior may further include generating a control structure containing a sequence of rows corresponding to one or more execution cases in the rule set, where each row has a sequence of one or more trigger conditions and a corresponding execution case. The generated control structure, including the information that defines the output of, now guides the process to continue on a different line if one of the trigger conditions fails during future processes that transform the input data. The configured and generated control structure causes the control structure to skip at least one row in the sequence of rows if at least one trigger condition fails for at least one of the trigger conditions in the control structure. It is configured to guide the process. The operation may further include storing or transmitting the control structure.
In general, one aspect of the subject matter described herein is that at least one execution case within it has one or more trigger conditions and a specification of the output that is produced when all of the one or more trigger conditions are met. It can be embodied in a system that includes an input device or port configured to receive a set of rules that includes a sequence of execution cases. The system may include means to generate a control structure containing a sequence of rows corresponding to one or more execution cases in a rule set, where each row contains a sequence of one or more trigger conditions and the corresponding execution case. The generated control structure, including the information that defines the output, is configured to guide the process to continue on a different line if one of the trigger conditions fails during future processes that transform the input data. The generated control structure is processed so that for at least one of the trigger conditions in the control structure, the control structure skips at least one row in the sequence of rows if at least one trigger condition fails. Is configured to induce. The system may include a data storage system configured to store the control structure.
In general, one aspect of the subject matter described herein is that at least one execution case within it is a specification of the output produced when one or more trigger conditions and one or more trigger conditions are all met. It can be embodied in a system that includes an input device or port configured to receive a set of rules that includes a sequence of execution cases that include. The system may include at least one processor configured to perform operations, including generating a control structure containing a sequence of rows corresponding to one or more execution cases in a ruleset. The generated control structure contains a sequence of one or more trigger conditions and information defining the output of the corresponding execution case when one of the trigger conditions fails during future processing of transforming the input data. The control structure is configured to guide the process to continue on different rows, and the generated control structure will have the control structure fail for at least one of the trigger conditions in the control structure when at least one trigger condition fails. It is configured to guide the process to skip at least one row in the sequence of rows. The system may include output devices or ports configured to transmit control structures.
Aspects may include one or more of the following features: The input data can be received and the trigger condition can be inspected against the input data in the sequence determined using the control structure. Data based on the output specified by the control structure can be stored or transmitted. At least one of the lines can exclude a trigger condition for the corresponding execution case, and the excluded trigger condition occurs in the execution case that precedes the corresponding execution case in the sequence of execution cases. The sequence of trigger conditions in a line may be a sequence of parts of the code that guide processing to the trigger conditions in the list of unique trigger conditions in the rule set. The information that specifies the output in a line may be part of the code that directs processing to the output in the list of unique outputs in the ruleset. A sequence of row trigger conditions can be sorted based on different rows to which processing is guided when a trigger condition in the sequence fails during data processing. The sequence of trigger conditions for a row can be sorted based on the execution time of the trigger condition. The execution time of a trigger condition in a list of unique trigger conditions can be updated based on the time it takes to execute the trigger condition on the input data. Pointers to trigger conditions for rows in the control structure can be sorted based on the updated execution time. The sequence of trigger conditions for a row can be sorted based on the failure rate of the trigger condition. The failure rate of a trigger condition in a list of unique trigger conditions can be updated based on whether the trigger condition is satisfied by a record in the input data. Pointers to trigger conditions for rows in the control structure can be sorted based on the updated failure rate. A line of control structure may include a portion of code that guides processing to a different line of control structure to be processed next when all the row trigger conditions are met. The rule set can be specified by a graphical user interface. At least two trigger conditions for execution cases in a rule set can be combined and represented by a single trigger condition in the control structure. Different executions in the rule set At least two outputs of a device can be combined and represented by a single output within a line of control structure. The control structure may be an aperiodic directed graph in which the nodes correspond to the trigger conditions and outputs within the rows of the control structure.
Aspects may include one or more of the following advantages:
In some embodiments, the processing time per record of the transform can be reduced based on the rule set. Some embodiments can reduce transform editing and launch times based on a set of rules. Some embodiments can reduce memory usage during transformation editing based on a set of rules. Some embodiments can provide, among other things, more efficient processing of data representing physical entities such as aircraft, automobiles, computers, buildings, or other infrastructure. Some embodiments can reduce the cognitive burden of users handling large amounts of data. For example, a user can more easily specify the processing of a large amount of data (eg, millions or billions of records), which makes it easier for the user to understand the data processing and of the ruleset specification. You can apply the user's domain information for a particular application without worrying about the task of discovering efficient structures.
Other features and advantages of the present invention will become apparent from the following description and claims.
<figref num="1">It is a schematic diagram of an exemplary data flow graph.</figref><figref num="2">2A-2B are diagrams illustrating an exemplary graphical user interface for inputting spreadsheet-based rules.</figref><figref num="3A">An example of a list of unique trigger conditions for a rule set is shown.</figref><figref num="3B">Here is an example of a list of unique outputs for a rule set.</figref><figref num="4">4A-4B show exemplary control structures for transforms based on a set of rules represented as aperiodic directed graphs.</figref><figref num="5">An exemplary control structure for a transform based on a set of rules represented as a display table is shown.</figref><figref num="6">It is a block diagram of the system which performs a graph-based operation.</figref><figref num="7">It is a flowchart of an exemplary process of generating and executing a transform based on a rule set.</figref><figref num="8">It is a flowchart of an exemplary process of performing a transform based on a rule set.</figref>
Large datasets can be processed using graph-based operations. For example, a credit card issuer uses graph-based arithmetic to process the transaction data of millions of credit cards and award points. Point) can be issued and the affiliated products to be presented in the offer of redemption of award points can be selected. In another example, airlines can frequently update their airline frequent flyer accounts for millions of airline passengers using graph-based calculations. In another example, a bank uses graph-based arithmetic to process consumer data from a variety of sources to approve a loan up to the maximum amount that depends on the data available to a particular consumer. Can be generated. In another example, an airline can use graph-based arithmetic to track and control the maintenance of a group of aircraft. In another example, a car rental company can use graph-based calculations to track and control the maintenance of a group of cars. In another example, an online service provider can use graph-based arithmetic to track and control maintenance and / or load balancing of one or more clusters of web servers. In another example, the city can control road traffic signal lights based on road traffic data. In another example, the wireless network operator can use graph-based arithmetic to control wireless network access and bandwidth allocation for a personal wireless communication device (eg, a smartphone or tablet device). These are just a few examples of applications for graph-based arithmetic, and many other applications are possible.
Graph-based operations may include one or more components that correspond to transforms applied to records (or other data elements) in a set in the input data. In general, transforms process input records to produce (eg, create or update) one or more output records. For example, a credit card issuer processes a transaction record associated with a credit card account record to generate a transaction approval or rejection record for a proposed credit card transaction. The details of how the transform processes the input records and produces the output records are complex and rely on a large amount of domain information about a particular application. It would be useful to allow users with little software development or coding information (eg, operators or developers) to easily configure transforms based on the information they have about a particular application. A system that produces efficient transforms based on defined rules through an easy-to-understand interface can help reduce the cognitive burden of such users.
In some embodiments, the user can configure potentially complex transforms through a spreadsheet-based graphical user interface (GUI). For example, a user can specify a rule set that includes an execution case by creating a row in the spreadsheet-based graphical user interface for each execution case. Each execution case may include one or more conditions called trigger conditions that can be inspected against input data and one or more outputs. When all the trigger conditions of an execution case are satisfied by the input data, one or more outputs of that execution case can be generated. For example, trigger conditions and outputs may correspond to columns in a spreadsheet-based GUI that lack software coding skills but have domain information and allow spreadsheet-savvy users to specify rule sets. .. In some embodiments, rule sets can be specified (eg, in data manipulation language (DML)) using formats other than spreadsheet-based GUIs.
When the user specifies a rule set, it can generate one or more transforms that can process input data records based on the rule set. The rule set may include trigger conditions and / or outputs that occur within multiple execution cases. Transforms can be generated by taking advantage of the redundancy in the rule set that reduces the memory and processing time required to edit the transform and apply it to the input data records. For example, when a trigger condition occurs in a plurality of execution cases, if the input data does not satisfy the trigger condition, the transform can skip checking the remaining execution cases against the trigger condition. By taking advantage of the redundancy within the rule set, it is possible to perform transforms on large input datasets with reduced memory and processor cycles. A transform can be partially encoded as a control structure that controls the execution flow of the transform. The control structure may include a logical grouping of trigger conditions and outputs, each corresponding to a rule set execution case, called a row. If it is evaluated that the trigger condition is satisfied during execution of the transform, the next trigger condition in the sequence of trigger conditions in the row is evaluated. If the last trigger condition in a row is met when evaluated on the input data, then at least part of the corresponding output specified by the row is produced. If the trigger condition fails when evaluated on the input data (eg, the trigger condition is not met), the control structure directs processing to different rows corresponding to different execution cases. For example, if the trigger condition fails, the execution flow skips some execution cases by jumping and begins evaluating the trigger condition in a row that is not in the next order on the sequence of rows in the control structure. In some embodiments, the control structure references a list of unique trigger conditions and unique outputs, so that these trigger conditions and outputs transform even if they occur many times within the rule set. It only needs to be stored once in the coding of.
In some embodiments, references to trigger conditions and trigger conditions that occur within the ruleset specification may be excluded from the control structure of the corresponding transform. For example, if the same trigger condition occurs elsewhere in the rule set that is always evaluated before the current instance of the trigger condition is evaluated, the trigger condition may be excluded from the control structure row. By excluding the trigger condition from the row, the memory usage and processing time of the corresponding transform can be reduced.
In some embodiments, the trigger conditions referenced within the control structure row or by the control structure row can be sorted based on the parameters of the trigger condition. This sorting can be performed to reduce the average processing time of the records to which the transform is applied. For example, a sequence of trigger conditions based on the execution time of the trigger condition, the number of rows skipped if the trigger condition fails during evaluation (eg jump size), or the failure cycle of the input data previously processed by the transform. Can be sorted. In some embodiments, the sequence of rows in the control structure can be sorted to increase the jump size of the trigger condition (eg, by grouping the execution case and the common trigger condition together). In some embodiments, the sequence of trigger conditions within a row and / or sequence of rows is modified to perform the corresponding transform on a large dataset with statistics similar to previously processed data. The processing time required for this can be reduced.
As used herein, the term "rule set" refers to a set of one or more rules, each composed of one or more execution cases. The execution cases in the rule may have an array that can determine the order in which the execution cases are evaluated during the processing of the input data. An "execution case" is a set of one or more trigger conditions associated with one or more outputs. A "trigger condition" is a condition used to determine whether an execution case fires, along with any other trigger condition of the execution case. The execution case "starts" when it is determined that all the trigger conditions for an execution case are met by the input data. That is, one or more outputs of the execution case are produced. The output is static in the sense that it is generated based on certain parameters specified as part of the rule set, or the output is partially generated based on input data values and / or intermediate result values. It is dynamic in the sense that it is done. The rule is single start or multiple start. With a single start rule, only the first execution case that meets all of its trigger conditions will start. A multi-start rule checks all the execution cases that make up the rule and produces output for all execution cases that meet all of the respective trigger conditions. Multiple rules in a rule set can be applied to data flows in a sequence. For example, a transform based on the first rule in a rule set can retrieve records from multiple input data sources and produce output records. These output records are then passed as input records to a second transform based on the second rule of the rule set, which can generate a second set of output records.
FIG. 1 shows a schematic diagram of an exemplary data flow graph 100 containing one or more transforms. Data is passed from one or more data sources to one or more data sinks through a sequence of data processing components in Data Flow Graph 100 that processes the flow of data. Any of the various data processing components in a data flow graph can be performed by processes running on separate processing devices, or one or more processes running multiple data processing components on a single processing device. It can also be carried out by. In some embodiments, the input data record can be processed continuously upon arrival (eg, in response to a credit card transaction request). In some embodiments, the data can be processed in batch units that identify the set of input data records processed by the data flow graph 100.
The processing of the data batch by the data flow graph 100 can be initiated by user input or some other event such as timer expiration. When the processing of the data batch is started, the input data records are read from one or more input data sources. For example, input data can be read from one or more files stored on a computer-readable storage device, such as represented by the data storage component 110. Input data records can also be read from a database running on a server as represented by the data storage component 112. The join component 120 reads data (eg, records) from multiple data sources in the sequence and organizes the input data into a discrete sequence of work units. The work unit may represent, for example, a record stored in a predetermined format based on the input record, or, for example, a transaction to be processed. Work units (eg records) are passed in the sequence to the next component in the data flow graph.
An exemplary data flow graph 100 also includes transform components 130 and 140. The transform performed by transform component 130 is based on a single starting rule. That is, only one execution case is started for each work unit (eg, a record of join process input data). Transform component 130 produces an output record that is passed to the next data processing component, transform component 140 in this example.
The transform performed by transform component 140 is based on multiple start rules. The output data record produced by the transform component 140 may include a list of output values corresponding to each of the execution cases initiated for the input work unit.
For example, transform component 130 can process input data records from join process 120 that correspond to credit card transaction records from various data sources. The transform component 130 can generate an output record that reflects the amount of award points assigned to the credit card as a result of the transaction reflected in the record. In this example, Transform Component 140 can then process the award points assigned to the credit card account to generate one or more offerings presented to the holder of the corresponding credit card account. it can.
Transform component 130 and transform component 140 are grouped as a larger component 150 that corresponds to a rule set that includes both a single start rule for transform component 130 and a multiple start rule for transform component 140. Can be transformed into.
Because the work units travel through the data processing components of the data flow graph, the result output records associated with each work unit are passed to the data queue 160 where they are stored before being transferred to the data sink 170. The data sink 170 may be, for example, a work unit or a data storage component that stores some accumulated output based on the work unit, or the data sink 170 may be a matrix in which the work unit is exposed or the final result. It may be some other type of sink that receives. In some embodiments, the batch process ends when all work units in the batch have been transferred to the data sink 170. At this point, the components in the data flow graph can be terminated.
Figure 2A shows an exemplary GUI200 for entering spreadsheet-based rules. GUI200 consists of a user defining a single starting rule that determines the "award points" value for a credit card account based on the transaction data available in one or more records affiliated with the credit card account. To. The GUI200 contains five lines that specify the five rule cases of the rule. The user uses GUI200 to specify the trigger conditions and output of the rule execution case, and the metadata obtained from the transform test run based on the rules that the user can use to facilitate debugging or tuning of the transform. Is displayed. For example, GUI200 can be presented to the user via the application specialist environment 622 of FIG. In some embodiments, the rule set defined via GUI200 can be received via the network interface of execution environment 604 of FIG.
The first column 204 defines the trigger conditions applied to the variables in the input data record that reflect the average monthly billing amount for the credit card account. The down arrow 206 in the third row of the first column indicates that the first trigger condition of the third execution case is the same as the trigger condition for the first trigger condition of the second execution case. In some embodiments, the user manually selects the down arrow icon to insert the down arrow into one or more cells of the spreadsheet-based GUI200, directly above the start point of the down arrow. It is possible to specify the trigger condition of the execution case through which the same downward arrow as the trigger condition passes. In some embodiments, the user can manually enter the same trigger conditions in adjacent cells of the spreadsheet-based GUI200, which automatically recognizes that the trigger conditions are the same and repeats this iteration. You can generate a pointing down arrow to indicate.
The second column 208 of GUI200 specifies the trigger condition applied to the variable derived from the input data record of the credit card account that reflects the number of years the credit card account has been valid so far. Column 208 also includes two downward arrows 210, each indicating a pair of matching trigger conditions.
The third column 214 of GUI200 defines the output produced when all trigger conditions in an execution case are evaluated and determined to be met. Column 214 also includes a down arrow 216 indicating that the first two execution cases have the same output. The user defines this as a single start rule 218 via GUI200, so the execution case is known to start (for example, all trigger conditions in the execution case are satisfied by the input data work unit). Can be evaluated one at a time. When an execution case is started, the output specified for that execution case is generated, and a transform based on this rule completes the work unit's processing. At this point, the transform begins or ends processing of the next work unit in the data flow.
In the last row of GUI200, all the trigger condition cells are set to the keyword "any" 230. This indicates that the corresponding trigger conditions do not exist or are equivalently that these trigger conditions are always truly evaluated. Since this fifth line has no trigger condition and is evaluated last, the corresponding output of this fifth execution case is specified as the default output.
Fourth column 220 displays metadata obtained from a traced test run of rule-based transforms that users can use to facilitate rule debugging or tuning. In general, different transforms can be generated based on at least three different modes of operation: production mode, record test mode, and file test mode rule set. The production mode transform implements the logic of the rule set and applies it to the input data (if any) with little additional code. Code test mode transforms allow stepping by performing transforms on individual work units (eg, input data records representing accounts, transactions, aircraft, cars, computers, mobile devices, buildings, etc.) Become. In addition to the required logic encoding of the rule set, the record test mode transform provides detailed logging messages (eg, each input field, output, trigger condition result (true or false), lookup key, lookup field). May include code that generates (reflecting the value of, which execution case was started, and some intermediate parameters). You can code a file test mode transform, apply the transform to large batch test data, and review logs summarizing test results for many work units. In addition to the required logic coding of the rule set, the file test mode transform evaluates logging messages (eg, the number of times each execution case was started and / or each trigger condition is evaluated, satisfied, and / or failed. May include code that generates (reflecting the number of times). In this example, column 220 is the number of times the execution case was started during a file test mode transform that processed thousands of work units (eg credit card account records) for each execution case. Display the count.
Figure 2B shows an exemplary GUI250 for inputting spreadsheet-based rules. The GUI250 is a credit card account holder based on the "Award Points" value determined using a transform based on the rules set out in the exemplary GUI200 of Figure 2A and other data associated with the credit card account. It consists of the user prescribing multiple start rules that generate a list of offerings to present to. GUI250 contains five lines that specify the five rule cases of the rule. The user uses GUI250 to specify the trigger conditions and output of the rule execution case, and the metadata obtained from the transform test run based on the rules that the user can use to facilitate debugging or tuning of the transform. Is displayed. For example, GUI250 can be presented to the user via the application specialist environment 622 of FIG. In some embodiments, the rule set defined via GUI250 can be received via the network interface of execution environment 604 of FIG.
The first column 254 defines the trigger conditions that apply to variables that reflect the "award points" of a credit card account. These "award point" values can be set and written to records in the data flow with a transform based on the rules specified in GUI200 in Figure 2A. The down arrow 256 in the second to third rows of the first column indicates that the first trigger condition of the second and third execution cases is the same as the trigger condition for the first trigger condition of the first execution case. Is shown.
The second and third columns 258 of GUI200 apply to other variables derived from the input data records associated with the credit card account that reflect the type of credit card and the population of the country of residence of the credit card account holder. Specifies the trigger condition to be performed. Column 258 also includes a down arrow, each indicating a pair of matching trigger conditions.
The fourth column 264 of GUI250 specifies the output produced when all trigger conditions in an execution case are evaluated and determined to be met. All execution cases can be evaluated because the user specifies this as multiple start rule 268 via GUI250. When an execution case starts, it produces a specified output for that execution case, and you can add this output to the list of output values for the current work unit. When all execution cases have been evaluated, the transform begins or ends processing of the next work unit in the data flow.
Fifth column 270 displays metadata obtained from a traced test run of a rule-based transform that can be used by the user to facilitate debugging or tuning of the transform. In this example, column 270 is the number of times the execution case was started during a file test mode transform that processed thousands of work units (eg credit card account records) for each execution case. Display the count.
Figure 3A shows an example of List 300 of unique trigger conditions for a rule set. In some embodiments, when one or more transforms are generated based on a rule set, the transforms should be used to remember a duplicate copy of the trigger condition for each execution case that occurs inside it. To save memory, part of the transform generation process produces a unique list of trigger conditions that the control structure can reference. In some embodiments, the transform may be generated based on the rule specification, some of the rules, including Listing 300, are application specialists who specify the rule in the technical backend name used in the transform coding. May include translating the data name used by. For example, the conversion operation can be performed based on a fixed key with a variable name or other mapping. In this example, the rule set consists of a rule defined through GUI200 in FIG. 2A (Rule 1) and a rule defined through GUI250 in FIG. 2B (Rule 2).
The list of unique trigger conditions may include a single copy of each trigger condition that occurs once or multiple times within the rule set. In this example, each trigger condition is encoded as a data manipulation language (DML) expression. The DML coding of the trigger condition is shown in the first column 310 of Figure 3A. Other coding formats for trigger conditions are also possible (eg C, C ++, Java, or Cobol code).
In some embodiments, the unique list of trigger conditions may also include a list of utilization pointers that facilitates a reverse lookup of the occurrence of the trigger conditions in the transform. For example, the second column 320 in FIG. 3A shows a list of usage pointers for a rule set containing Rule 1 and Rule 2. Each pointer is a triplet of numbers that identifies rule_id (eg, rule 1 or 2), row_id (eg, corresponds to a particular execution case), and column_id (eg, corresponds to a trigger condition sequence position in the execution case). Is. In this example, the first five unique trigger conditions occur in Rule 1, and the next seven unique trigger conditions occur in Rule 2. In some embodiments, the utilization pointer is not included in the list of unique trigger conditions.
In some embodiments, Listing 300 reuses the results of complex operations defined by the equations in Listing 300, and results based on the same inputs that the input data is perceived to be the same during the transform. A data structure that caches the results of this complex operation may be included so that the re-operation of is avoided.
The list 300 of unique trigger conditions can be stored in various formats or data structures (eg, linked lists or indexed arrays). In this example, the unique list of trigger conditions 300 is stored as an indexed array, facilitating the lookup of trigger conditions based on the reference of the trigger condition by the index in the transform's control structure.
Figure 3B shows an example of a list of unique outputs for a rule set. In some embodiments, once one or more transforms were generated based on a rule set, the transforms were supposed to be used to store a duplicate copy of the output of each execution case that occurs inside it. To save memory, part of the transform generation process produces a unique list of outputs that the control structure can reference. In this example, the rule set consists of Rule 1 and Rule 2.
The list of unique outputs may include a single copy of each output that occurs once or multiple times within the ruleset. In this example, each output is encoded as a DML expression. The DML coding of the output is shown in the first column 360 of Figure 3B. Other coding formats for the output are also possible (eg C, C ++, Java, or Cobol code).
In some embodiments, the unique list of outputs may also include a list of utilization pointers that facilitates a reverse lookup of the occurrence of the output in the transform. For example, the second column 370 of FIG. 3B shows a list of usage pointers for a rule set containing Rule 1 and Rule 2. In this example, the first four unique outputs occur in Rule 1, and the next five unique outputs occur in Rule 2. In some embodiments, the utilization pointer is not included in the list of unique outputs.
The unique output list 350 can be stored in various formats or data structures (eg, linked lists or indexed arrays). In this example, list 350 of unique outputs is stored as an indexed array indexed (eg, at disjoint index value intervals) with list 300 of unique trigger conditions.
Part of the transform generation process is the generation of control structures that control the transform execution flow, with reference to a list of unique trigger conditions and / or a list of unique outputs. As used herein, the term "control structure" refers to various coding formats and is not limited to double-indexed two-dimensional arrays. For example, the aperiodic directed graphs of FIGS. 4A and 4B and the doubly linked list shown in FIG. 5 are examples of control structures that control the transform execution flow. The control structure has rows corresponding to execution cases. For transform control structures, the term "row" refers to one or more trigger conditions and one or more outputs in which the output of the row is executed when it is determined that all the trigger conditions in the row are met. Refers to the logical grouping with. Here, the term "row" is not limited to a horizontal subset of display tables.
4A-4B show an exemplary control structure 400 of a transform based on a rule set represented as an aperiodic directed graph. In this example, the rule set on which the transform is based includes Rule 1 and Rule 2. In this example, the transform is performed within component 150 of the data flow graph 100, or equivalently, the transform is a component that follows a second transform under Rule 2 that is performed within component 140. It can be implemented as the first transform under Rule 1 implemented within 130. In FIGS. 4A and 4B, each node is labeled by a utilization pointer (rule_id, row_id, column_id), as described in connection with FIG. 3A.
The nodes in control structure 400 correspond to trigger conditions or outputs. The node corresponding to the trigger condition has two edges emerging from the node. One of these two edges is traced to being determined to be true when the node's corresponding trigger condition is applied to the input data. The second of these two edges is traced to being determined to be false when the node's corresponding trigger condition is applied to the input data. A node corresponding to an output has one edge that emerges from the node that is always followed after the corresponding output is generated. A row in control structure 400 may contain a sequence of one or more trigger condition nodes that are continuously connected by "true" edges that emerge from the previous trigger condition node. The last trigger condition node in a sequence of rows can be connected to the first node of one or more output nodes in the row by its "true" edge. Edges emerging from output nodes in the line can connect to additional output nodes in the line. The edge that emerges from the last output node in a row can connect to a node in another row that corresponds to a different execution case or rule, or can direct the execution flow to the end of the work unit's transform process, 448. Similarly, a "false" edge that emerges from a trigger condition node can connect to a node in another row that corresponds to a different execution case or rule, or directs the execution flow to the end of the work unit's transform process, 448. be able to.
Control structure 400 encodes the start point 402 of the transform execution flow. The transformation begins by evaluating the first trigger condition of the first execution case 404.
In some cases, the "false" edge causes the execution flow to jump to a row that is not adjacent to the current row, thereby skipping the evaluation of some execution cases. Skipping this line reduces complexity and allows the transform to handle input data records representing work units such as accounts, transactions, aircraft, cars, computers, mobile devices, buildings, etc. Processing time is reduced.
In this example, some of the nodes, including the trigger condition node 420, have no edges to connect to them. The lack of edges connecting to the node reflects the fact that the corresponding trigger condition or output does not have to be handled by the logic of the rule set on which the transform is based. As a result, these disconnected nodes and their corresponding trigger conditions can be excluded from control structure 400. Exclusion of unnecessary trigger conditions is shown in control structure 450 in FIG. 4B.
In some cases, multiple nodes can be combined and represented as a single node in the control structure. For example, nodes 454 and 456 can be combined by creating a single trigger condition node that guides the evaluation of the logical product of the trigger condition referenced by node 454 and the trigger condition referenced by node 456. This is possible because if both trigger conditions are true, the output node 458 is processed next, and if any of these trigger conditions are false, the trigger condition for node 460 is processed next. In this way, two trigger conditions can be combined and represented by a single trigger condition within 450 within the control structure of the execution case in the rule set. Trigger conditions can also be combined within a single entry in a unique list of trigger conditions if the combined nodes correspond only to instances of these trigger conditions. Similarly, the outputs corresponding to the output nodes 470 and 472 are always generated together, so that the output nodes 470 and 472 can be combined. In this example, the output nodes 470 and 472 can be combined to combine the corresponding rows into a single row corresponding to the two execution cases of the transform-based rule set. These node combination technologies can reduce the memory usage and processing time of transforms by reducing the amount of control flow code to be generated and executed.
FIG. 5 shows an exemplary control structure 500 for a transform based on a rule set represented as a display table. The control structure 500 can be stored, for example, as a doubly linked list (eg, a linked list of rows, where each row contains a row trigger condition and an output linked list). In this example, control structure 500 controls the transform execution flow based on a rule set that includes Rule 1 and Rule 2. In this example, control structure 500 references a trigger condition in list 300 of unique trigger conditions and an output in list 350 of unique outputs.
The first column 510 in FIG. 5 shows the index (eg, execution case number) of the rows of control structure 500. This index can be used to reference rows in control structures to facilitate jumps in the execution flow to avoid unnecessary processing. The second column 520 shows the sequence of trigger conditions for each row. For example, control structure 500 refers to a trigger condition in a list of unique trigger conditions 300 and processes the transform after the trigger condition has been evaluated based on the result (eg, fulfillment or failure / true or false). Further, it may include a code part of the trigger condition to be induced. If the trigger condition fails, the transform process is directed to a different row, which may be two or more rows away from the current row in the sequence of rows in control structure 500. For example, the part of code 522 in the third line guides the process to evaluate the third trigger condition in the list 300 of unique trigger conditions, and if the trigger condition fails, the part of code 522 is Directs processing to the 5th line of control structure 500 and skips the 4th line.
If all of the trigger conditions listed for a row in the control structure are met, the process is directed to the output of the row. The fourth column 530 of FIG. 5 shows a reference to the output in Listing 350 of the unique output. Finally, after executing the output of one row in control structure 500, the process can be guided to continue processing in another row of control structure 500 or to end the processing of the current work item. The third column 540 of FIG. 5 shows a reference to another row in control structure 500 referenced by the control structure row index (eg, execution case number).
FIG. 6 shows an exemplary data processing system 600 for which transform generation techniques can be used. The system 600 may store data in any of a variety of storage formats (eg, database tables, spreadsheet files, plain text files, or unique formats used by mainframes), such as storage devices or online data streams. Includes data source 602, which may contain one or more data sources of. The execution environment 604 includes a transform generation module 606 and an execution module 612. The execution environment 604 can be hosted on one or more general purpose computers under the control of a preferred operating system, such as the UNIX operating system. For example, the execution environment 604 may have multiple central processing units (CPUs), local (eg, a multiprocessor system such as an SMP computer) or locally distributed (eg, clusters or MPP-coupled processors). ), Or remote or distributed to the remote side (eg, multiple processors coupled over a local area network (LAN) and / or a wide area network (WAN)), or any combination thereof. It may include a multinode parallel computing environment that includes the configuration of the computer system that was used.
Transform generation module 606 receives a set of rules containing a sequence of execution cases, including at least one of the trigger conditions and the specifications of the output generated when all of the one or more trigger conditions are met. .. A rule set also includes an execution case that contains one or more outputs but lacks a trigger condition or, equivalently, has a trigger condition that is always truly evaluated (eg, the default execution case of exemplary Rule 1). be able to. For example, the rule set may be specified by a user 626 accessing the execution environment 604 through the application specialist environment 622. In some embodiments, the application specialist environment comprises client software running on a remote computing device that provides a GUI that specifies a rule set for user 626. For example, through the application specialist environment 622, the user can specify a rule set in a spreadsheet-based GUI, as described in connection with FIGS. 2A and 2B. In some embodiments (not shown), the development environment 618 and the application specialist environment 622 are combined to provide both the data flow graphs and the ruleset specification for the transforms instantiated within those data flow graphs. It can be accessed from a single user or group of users to edit.
The transform generation module 606 generates one or more transforms based on the received rule set. You can generate control structures that control the execution flow of one or more transforms. The control structure may include rows corresponding to execution cases in the rule set. Each line may contain a sequence of one or more trigger conditions for the execution case and information that defines the output. Some trigger conditions induce the process to continue on a different line that is at least two lines below the current line if the trigger condition fails during the process of transforming the data, and therefore some execution cases. You can skip the evaluation of and reduce the processing time required for the transform.
The control structure can be stored or transmitted with any other data encoding the generated transform. For example, the generated transform containing the control structure can be stored in the data storage system 616. In some embodiments (not shown), the transform generation module 606 can be implemented as part of the application specialist environment 622, and the data encoding the generated transform, including control structures, is the application specialist environment 622. Can be sent from the remote computing device running to the execution environment 604.
Execution module 612 uses one or more transforms generated by transform generation module 606 to process input data records and generate output data records for transmission or storage. When one or more transforms in a graph-based operation are generated, execution module 612 applies the operation containing the transform to the input data. Execution module 612 reads data from the data source 602 and generates output data records 614 that can be stored in the data storage system 616 accessible to the execution environment 604. For example, the data storage system 616 may include a database server and / or a server running a version control application.
In some embodiments, the execution module also records the execution time and / or result of the trigger condition evaluated during the processing of the input data record. For example, the transform generation module 606 can use these logs to update the transform by changing the order of the trigger conditions in the control structure.
The storage device that provides the data source 602 may be on the local side of the execution environment 104 and is stored, for example, on a storage medium (eg, hard drive 608) connected to the computer running the execution environment 604. It may be, or it may be on the remote side of the execution environment 604, for example, hosted by a remote connection on a remote system (eg, mainframe 610) communicating with the computer running the execution environment 604. You may be.
The data storage system 616 has access to a development environment 618 that allows developers 620 to create and manage graph-based operations that include components that support transforms. The behavior of these transforms can be configured by a user (eg, user 626) who has special information about the application to which the graph-based operation is applied. In some embodiments, development environment 618 develops an application as a data flow graph containing vertices (representing a component or dataset) connected by directed links (representing the flow of work elements) between vertices. It is a system. For example, such an environment is detailed in US Publication No. 2007/0011668 entitled "Managing Parameters for Graph-Based Applications" which is incorporated herein by reference. Systems that perform such graph-based operations are incorporated herein by reference in US Pat. No. 5,566,072, "EXECUTING COMPUTATIONS EXPRESSED AS." It is described in "GRAPHS". Data flow graphs created according to this system provide a way to capture information input and output to and from individual processes represented by graph components, move information between processes, and define the order in which processes are executed. This system selects an interprocess communication method (for example, the communication path by linking the graph can use TCP / IP or UNIX domain socket, or data can be passed between processes using shared memory). Includes algorithms to do.
Execution module 612 can receive data from different types of systems, including different types of database systems. The data can be organized as records with the values of each field (also called "attribute" or "column") that may contain null values. When reading data from a data source for the first time, execution module 612 typically starts with some initial format information about the records in that data source. In some situations, the record structure of a data source is initially unknown and can be determined after analysis of the data source. Initial information about a record may include the exact value represented by the bits, the order of the fields in the record, and the number of bits representing the type of value (eg, string, signed / unsigned integer).
FIG. 7 shows a flowchart of an exemplary transform generation and execution process 700. For example, process 700 can be executed by the execution environment 604 of FIG.
Process 700 starts when the rule set is received at 702. The rule set may include a sequence of execution cases. An execution case in a rule set may include one or more trigger conditions and a specification of the output produced when all one or more trigger conditions of the execution case are met. In some embodiments, the ruleset is a user interface (eg, a text file editor, etc.) that includes hardware (eg, a computer monitor and keyboard and / or mouse) connected to the local side of the processing device that receives the ruleset. Received via a spreadsheet-based GUI, or any other type of GUI). For example, the rule set can be received through the user interface of execution environment 604 of FIG. In some embodiments, the rule set is received by the server from the remote processing device over the network interface. For example, a rule set can be received from a remote processing device running application specialist environment 622 through the network interface of execution environment 604.
A transform containing control structures is generated in 704 based on the received rule set. Control structures can be used to control the transform execution flow when applying a transform to input data. The control structure can refer to other parts of the generated transform (eg, a list of unique trigger conditions and / or a list of unique outputs). Control structures can be coded in a variety of formats. Examples of control structure formats are, among other things, executable files edited for one or more processors in the execution environment, text files containing text that can be edited by a computer language interpreter or a run-time compiler, and can be interpreted or edited. A double-indexed (two-dimensional) array of text records containing parts of the code, the aperiodic directed graphs in Figures 4A and 4B, and the double-linked list shown in Figure 5.
The generated control structure may contain rows corresponding to one or more execution cases in the rule set. A line in the control structure may contain a sequence of one or more trigger conditions and information that defines the output of the execution case. A line of control structure may be a logical grouping of execution control flow codes corresponding to one or more trigger conditions in a rule set and one or more outputs of execution cases. In some embodiments, the lines of the control structure are a sequence of pieces of code that guide the execution of the transform to cause the processing device to inspect the trigger condition or produce output (eg, sorted as a linked list). Included). The code portion of the trigger condition can also direct the execution of the transform to a different trigger condition or to another portion of the code corresponding to the output based on the evaluation result of the current trigger condition. If the trigger condition in the control structure fails during the data conversion process, it can induce the process to continue on different rows that are two or more rows away from the current row in the sequence of rows. In this way, the processing time of the work unit (eg, the input data record) can be reduced by skipping the execution of the trigger condition and / or the output of some rows.
In some embodiments, the sequence of trigger conditions for a row can be sorted based on the row number of a different row to which processing is guided when the trigger condition in the sequence fails during data processing. For example, put a sequence of row trigger conditions earlier in the sequence of row trigger conditions that causes a large jump in the control structure in a failure situation, while a small jump in the control structure in a failure situation. You can sort the triggering conditions later in the sequence of triggering conditions in a row during the transform generation process.
In some embodiments, a row of control structures is generated at 704 in a manner that excludes the trigger condition of the corresponding execution case that occurs in the execution case immediately before the corresponding execution case in the sequence of execution cases. Exclusions can reduce the memory requirements required to edit and / or execute transforms.
In some embodiments, a list of unique trigger conditions for the rule set is also generated at 704 as part of the transform. List 300 of the unique trigger conditions for a rule set containing Rule 1 and Rule 2 is an example of a list of unique trigger conditions that can be generated. For example, if a sequence of trigger conditions in a line is stored as a sequence of parts of code, one of the parts of code directs processing to the trigger conditions encoded in the list of unique trigger conditions in the rule set. can do.
In some embodiments, a list of unique outputs of the rule set is also generated at 704 as part of the transform. List 350 of the unique output of a rule set containing Rule 1 and Rule 2 is an example of a list of unique outputs that can be generated. For example, if the output in a line is stored as a part of the code, the part of the code can direct processing to the output in the list of unique outputs of the rule set.
In some embodiments, a control structure row is a piece of code that directs processing to a different row of control structure to process next when all the trigger conditions of the row are met and the output of the row is generated. Including further.
For example, the transform generation module 606 running in the execution environment 604 of FIG. 6 can generate a transform including control structures in the 704.
The generated transform containing the control structure can be stored and / or transmitted at 706. In some embodiments, the transform is stored in a memory device (eg, random access memory) and passed to an execution module that applies the transform to the input data. For example, the transform generation module 606 can store the transform in the 706 in a volatile memory device that is part of the execution environment 604 accessible by the execution module 612 in FIG. In some embodiments, the transform can be stored within a data storage device that includes non-volatile memory (eg, a database server or server running a version control application). For example, the transform can be stored in the data storage system 616 with the 706. In some embodiments, the transform can be sent to a remote device (eg, via an electronic communication network). For example, a transform generator running within an application specialist environment can send a transform at 706 to a remote execution environment for application to input data.
Once the transform is generated and the processing system that performs the transform is available, the transform can be applied to the input data. For example, the transform can be accessed from a processing system running a data flow graph that includes one or more components that perform the transform (eg, components 130 and 140 of the data flow graph 100). Input data can be received by the 708 from one or more data sources (eg, data source 602). In some embodiments, the input data can be preprocessed (eg, by component 120 that performs the join process) to create a work unit of data flow that is passed to one or more components that perform the transform. .. Each work unit is prepared based on the received input data and can be passed to the transform. In some embodiments, groups of work units are passed to the transform in batch units. For example, the input data can be received by the 708 via the network interface of the execution environment 604 shown in FIG.
The transform is performed on the 710 and the received input data is processed. In some embodiments, the transform is further interpreted and / or edited at run time when processing new input data. For example, using process 800, described in connection with FIG. 8, the transform can be performed on the 710 and applied to the input data. Applying the transform to the input data may include checking the trigger condition against the input data in the sequence determined using the control structure. For example, the execution module 606 running in the execution environment 604 of Figure 6 allows the transform to be executed on the 710.
Execution of the transform can continue until there is no more input data available on the 712. Data that reflects the result of applying the transform to the input data can be stored in the 714 (for example, as an output data record written to the data sink). The stored result data may be generated based on the output defined by the control structure. For example, the result can be stored by the execution module 612 in the data storage system 614 of FIG. In some embodiments (not shown), the resulting data based on the output specified by the control structure (eg to the application specialist environment 622) is delivered over the electronic communication network (eg via the network interface of the execution environment 604). Will be sent.
FIG. 8 is a flow chart of an exemplary process 800 that performs a transformation based on a rule set. For example, process 800 can be executed by execution module 612 running on execution environment 604 of FIG.
Process 800 includes searching for the transform's control structure applied to the input data 802. In some embodiments, the control structure is retrieved by 802 when the component in the data flow graph performing the transform is passed to a work unit in the data flow. In some embodiments, the control structure is retrieved on 802 from a memory device (eg, random access memory). In some embodiments, the control structure is retrieved in 802 from a data storage device that includes non-volatile memory (eg, a database server or server running a version control application). In some embodiments, the control structure is passed to the interpreter and / or compiler at run time to prepare the control structure for execution.
The first trigger condition is checked at 810 against the input data of the work unit. For example, interpret and execute a DML expression that encodes a trigger condition, access any reference input data field in the record associated with the work unit, and test the accessed data by applying the logic of the trigger condition. can do. The result of this evaluation may be successful or unsuccessful (true or false).
The results of the evaluation of the trigger condition can be recorded (eg, for testing, debugging, or optimization). In some embodiments, the execution time of the trigger condition (eg, measured in microseconds or processor cycle units) can be recorded. Data on the failure rate or execution time of the trigger condition when applied to the input data can be used to dynamically update the control structure in an effort to reduce the average processing time for future records.
If the input data of the work unit does not satisfy the trigger condition with 815 (eg, the result is unsuccessful or false), the transform execution refers to the control flow code associated with the trigger condition (eg, the trigger condition). It can lead to different lines of control structure, based in part on (or the part of the code it contains). According to the control structure, the execution can jump to a different line of control structure at 820. For example, some failure conditions allow an execution to jump at 820 to a different line that is two or more lines away from the current line in the control structure's line sequence. In this way, it is possible to reduce the processing time of the work unit by skipping the execution of the trigger condition and / or the output of some rows. You can then check the next trigger condition for the new row at 810. In some embodiments (not shown), the execution of the transform can jump directly to a row without a trigger condition (eg, corresponding to the default execution case) or to the end of the control structure.
If the input data of the work unit satisfies the trigger condition with 815 (eg, the result is true or true), the execution of the transform can be directed to the next element in the current row of the control structure. If there are more trigger conditions in the sequence of trigger conditions in line 825, the next trigger condition in line is checked at 810. Otherwise, the 830 can produce one or more outputs of a row.
For example, interpreting and executing a DML expression that encodes the output, accessing any reference input data field in the record associated with the work unit, and / or applying the logic of the output, one at 810. The above output record can be generated. The resulting output record may be completely new, or may update or extend an existing record to include additional fields or other data.
After the output of the current row is generated at 830, you can direct the execution of the transform to a different row that corresponds to an additional execution case. In some embodiments, the row contains a pointer that directs the execution of the transform to a different row in the control structure. If there are more execution cases to handle in 835, the control structure causes the transform execution to jump to a different line in the control structure at 840. For example, in the case of multiple start rules, additional rows need to be processed for additional execution cases. If the transform corresponds to a rule set with multiple rules, then depending on the control structure, the execution of the transform jumps at 840 to different rows of control structures that correspond to different rules. The next trigger condition for the new row is then checked at 810.
At 835, the control structure can be dynamically updated based on the log information of the processed input data when there are no more execution cases, i.e., when there is no need to process the rows. For example, the trigger conditions in a sequence of row trigger conditions can be sorted by 850, in part, based on new log information about the average failure rate or execution time of the trigger conditions.
In some embodiments, the execution time measurement of a trigger condition in a unique list of trigger conditions can be updated based on the time it takes to execute the trigger condition on the input data. Trigger conditions in a sequence of row trigger conditions can be sorted by 850, partially based on updated measurements of the execution time of the trigger condition. In some embodiments, the trigger condition failure rate measurement in the unique list of trigger conditions can be updated based on whether the trigger condition is satisfied by one or more records in the input data. Trigger conditions in a sequence of row trigger conditions can be sorted by 850, in part based on updated measurements of the failure rate of the trigger condition.
An updated version of the control structure can be stored in the 852 for application to future input data. In some embodiments, the updated control structure can be stored in the memory device (eg, random access memory) at the 852. In some embodiments, the 852 can store updated control structures within a data storage device that includes non-volatile memory (eg, a database server or server running a version control application).
The above transform generation method can be carried out using software running on a computer. For example, each with at least one processor, at least one data storage system (including volatile and non-volatile memory and / or storage elements), at least one input device or port, and at least one output device or port. The software forms a procedure within one or more computer programs running on one or more programmed or programmable computer systems (of various architectures such as distributed, client / server, or grid), including. The software can form, for example, one or more modules of a larger program that provides other services related to the design and configuration of data flow graphs. The nodes and elements of the graph can be implemented as data structures stored on a computer-readable medium or other organized data that conforms to a data model stored in a data repository.
The software can be provided on a storage medium such as a CD-ROM that can be read by a general purpose or purpose-built programmable computer, or delivered (propagated signal) to the computer's storage medium over a network communication medium during execution. Can be coded in). All functions can be performed on a special purpose computer or using special purpose hardware such as a coprocessor. The software can be performed in a distributed manner in which different parts of the operations specified by the software are performed by different computers. Each such computer program is preferably a general purpose or specific purpose for configuring and operating a computer as the storage medium or device is read by the computer system and performs the procedures described herein. Stored or downloaded on a tangible, non-transient storage medium or device (eg, solid-state memory or medium, or magnetic or optical medium) that can be read by a programmable computer. The system of the present invention is considered to be implemented as a computer-readable storage medium composed of computer programs, and the storage medium so configured operates the computer system in a specific predetermined manner and is described herein. To execute the function to be performed.
So far, some embodiments of the present invention have been described. However, it will be appreciated that various changes can be made without departing from the spirit and scope of the invention. For example, some of the above steps are order independent and can be performed in a different order than the one described.
It should be understood that the above description is exemplary and does not limit the scope of the invention as defined by the appended claims. For example, some of the above functional steps can be performed in a different order without substantially affecting the overall process. It should be noted that the details of the specific business rules regarding credit accounts are described in the examples of FIGS. 2A and 2B only to illustrate the functions of GUI200 and GUI250 and the transform generation system in which they provide the user interface. Referenced throughout the book. The details of the particular business rules presented are not essential features and should not be construed as limiting the scope of the claims. Other embodiments are also included in the claims below.
11 sheets
Sheet 1 Sheet 2 Sheet 3 Sheet 4 Sheet 5 Sheet 6 Sheet 7 Sheet 8 Sheet 9 Sheet 10 Sheet 11
Every citation, both ways
| Document | Relation | Office |
|---|---|---|
| JP2008059135A | Cites | Japan |
| JP07036706A | Cites | Japan |
| JP2010524134A | Cites | Japan |
19 members in 10 offices
Priority claims19
| Document | Office | Kind | Date |
|---|---|---|---|
| 201261735451 | United States of America | P | |
| 201261735451 | United States of America | P | |
| 61735451 | United States of America | – | |
| 201361751814 | United States of America | P | |
| 201361751814 | United States of America | P | |
| 61751814 | United States of America | – | |
| 13958037 | United States of America | – | |
| 201313958037 | United States of America | A | |
| 201313958037 | United States of America | A | |
| 2013073899 | United States of America | W | |
| 2013073899 | United States of America | W | |
| 13958037 | – | – | – |
| 61735451 | – | – | – |
| 61751814 | – | – | – |
| US201261735451P | – | – | – |
| US2013073899 | – | – | – |
| US201313958037 | – | – | – |
| US201361751814P | – | – | – |
| WO2013US73899 | – | – | – |
Members19
| Document | Office | Kind | |
|---|---|---|---|
| US2014164410A1 | United States of America | A1 | |
| CA2889884A1 | Canada | A1 | |
| WO2014093232A1 | World Intellectual Property Organization (WIPO) | A1 | |
| AU2013359617A1 | Australia | A1 | |
| SG11201503470TA | Singapore | A | |
| KR20150095648A | Republic of Korea | A | |
| CN104919445A | China | A | |
| EP2929457A1 | European Patent Office (EPO) | A1 | |
| JP2016510442A | Japan | A | |
| HK1209869A1 | Hong Kong, China | A1 | |
| EP2929457A4 | European Patent Office (EPO) | A4 | |
| US9703822B2 | United States of America | B2 | |
| US2018067982A1 | United States of America | A1 | |
| JP6419081B2This record | Japan | B2 | |
| AU2013359617B2 | Australia | B2 | |
| US10817503B2 | United States of America | B2 | |
| CA2889884C | Canada | C | |
| KR102237167B1 | Republic of Korea | B1 | |
| CN104919445B | China | B |
15 legal events, as the office reported them to INPADOC
Over the term
Point at a mark for the eventEvents
| Event | Code | |
|---|---|---|
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Certificate of patent or registration of utility modelJAPANESE INTERMEDIATE CODE: R150R150 | R150 | |
| First payment of annual fees (during grant procedure)JAPANESE INTERMEDIATE CODE: A61A61 | A61 | |
| Written decision to grant a patent or to grant a registration (utility model)JAPANESE INTERMEDIATE CODE: A01A01 | A01 | |
| Decision of grant or rejection writtenTRDD | TRDD | |
| Request for written amendment filedJAPANESE INTERMEDIATE CODE: A523A521 | A521 | |
| Written request for extension of timeJAPANESE INTERMEDIATE CODE: A601A601 | A601 | |
| Notification of reasons for refusalJAPANESE INTERMEDIATE CODE: A131A131 | A131 | |
| Report on retrievalJAPANESE INTERMEDIATE CODE: A971007A977 | A977 | |
| Request for written amendment filedJAPANESE INTERMEDIATE CODE: A523A521 | A521 | |
| Written request for application examinationJAPANESE INTERMEDIATE CODE: A621A621 | A621 |
Numbers
- Publication
- 6419081
- Publication, DOCDB
- 6419081
- Publication, EPODOC
- JP6419081B
- Application
- 2015545913
- Application, DOCDB
- 2015545913
- Application, EPODOC
- JP20150545913
Titles2
- Japanese
- トランスフォーム生成システム
- English
- Transform generation system
Classification
- CPC, 4
- G06F16/2365
- G06F16/254
- G06F16/2453
- G06F16/24534
- IPC, 2
- G06F8 35
- G06F8 41
