Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
DETAILED ACTION
This Office Action corresponds to application 19/090,244 which was filed on 3/25/2025.
Response to Amendment
In the reply filed 3/30/2026, claims 1-8, 10-17, and 19-20 have been amended. No additional claims have been added or cancelled. Accordingly claims 1-20 stand pending.
The 35 USC 101 rejections have been withdrawn in light of the amendments/arguments.
Response to Arguments
Applicant's arguments filed 3/30/2026 have been fully considered but are moot in view of new grounds of rejection.
The applicant argues that Portisch does not teach “the statically compiled executable code being generated prior to runtime based on a rule logic configuration and a static definition of a data schema”. The examiner respectfully disagrees. Portisch teaches, in paragraphs 29-33 and 35-36, that rule generation is triggered by the rule generation request and that the request input may include an alignment, an identifier for an alignment, one or more mappings or identifiers for mappings, an identifier for a source database, a source schema or identifier for a source schema, source instance data or references to source instance data, an identifier for a target database, a target schema or identifier for a target schema, and/or target instance data or references to target instance data. Portisch teaches that the included alignment aligns the source schema with a target schema and can include mappings which indicate which fields match and contain information on how the data is to be translated such as with specific field types and data formats, which is interepted as statically compiled executable code, e.g., the alignment and mapping, generated prior to runtime, since it is included in the input request, that is based on rule logic and static definition of data schemas. Therefore, the examiner is not persuaded.
The applicant also argues that Portisch doesn’t teach a pre-constructure structure that is used in the mapping. The examiner respectfully disagrees. Portisch teaches, in paragraphs 29-33 and 35-36, that rule generation is triggered by the rule generation request and that the request input may include an alignment or an identifier for an alignment as part of the input. The alignment aligns the source schema with a target schema and can include mappings which indicate which fields match and contain information on how the data is to be translated such as with specific field types and data formats. The alignment is interpreted as a pre-constructed structure used to map field types and data formats. Therefore, the examiner is not persuaded.
The applicant also argues that it would be improper to combined Portisch and Molteni. The examiner respectfully disagree. Even though Molteni is using a rule engine in regards to containerized computing and Portisch is using a rule engine with more focus on ETL, both Portisch and Molteni are generally related to rule engines technologies. Additionally, Molteni is cited for rule engine related teachings and not containerized computer teachings. Therefore, the examiner is not persuaded.
Lastly, the applicant has amended the title to make it more descriptive, however specifying the use of a data processing engine in the title is still not clearly indicative of the invention. It is suggested to amend the title to something along the lines of “METHOD, DEVICE, AND STORAGE MEDIUM FOR DATA PROCESSING USING DATA TYPE PROCESSING RULES”. Therefore, the examiner is not persuaded.
Specification
The title of the invention is not descriptive. A new title is required that is clearly indicative of the invention to which the claims are directed.
The following title is suggested: “METHOD, DEVICE, AND STORAGE MEDIUM FOR DATA PROCESSING USING DATA TYPE PROCESSING RULES”.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1-3, 5, 8-12, 14, and 17-20 are is/are rejected under 35 U.S.C. 103 as being unpatentable over Portisch et al. (US2021/0232591, previously presented in ‘892), hereinafter Portisch, in view of Molteni et al. (US2024/0144048, previously presented in ‘892), hereinafter Molteni, and Krishnaraju et al. (US2022/0188279), hereinafter Krishnaraju.
Regarding Claim 1:
Portisch teaches:
A method of data processing, comprising: obtaining, via a static code generator executed by a processor, a data processing engine instance comprising statically compiled executable code implementing a set of processing rules compiled therein, the set of processing rules being configured for at least one party, the statically compiled executable code being generated prior to runtime based on a rule logic configuration and a static definition of a data schema (Portisch, figures 1-3, abstract, [0029-0033, 0035-0036, 0121], note using a transformation rule engine, e.g., data processing engine; note obtaining and executing processing rules to format data, e.g., code for a set of processing rules; note the use of static definition of data schemas; note the rule generation request may be a function call or made through an interface and it is the request that initiates the transformation rule engine, such as based on input; note the request input may include an alignment, an identifier for an alignment, one or more mappings or identifiers for mappings, an identifier for a source database, a source schema or identifier for a source schema, source instance data or references to source instance data, an identifier for a target database, a target schema or identifier for a target schema, target instance data or references to target instance data; note the alignment aligns the source schema with a target schema and can include mappings which indicate which fields match and contain information on how the data is to be translated such as with specific field types and data formats. This is all interepted as statically compiled executable code generated prior to runtime since it is included in the input and is based on rule logic and static definition of data schemas);
in response to receiving first data to be processed that is associated with a first data type from a first party of the at least one party, determining, by the data processing engine instance based on the first data type using a pre-constructed structure that maps data types, the pre-constructed structured being generated during the static compilation (Portisch, figures 1-3 and 5b, abstract, [0029-0033, 0035-0036, 0070, 0075, 0104, 0121], note the transformation rules are determined based on data types of data to be processed; note the rules generation request includes the alignment as input; note the alignment aligns the source schema with a target schema and can include mappings which indicate which fields match and contain information on how the data is to be translated such as with specific field types and data formats. The alignment is interpreted as a pre-constructed structure used to map field types and data formats); and
processing, using the data processing engine instance by executing the statically compiled executable code of the determined subset of the processing rules, the first data by applying the at least one first processing rule, to obtain processed first data (Portisch, figures 1-4, abstract, [0029-0033, 0035-0036, 0070, 0079-0080, 0099-0100], note transformation rules produces output values which can be assigned to the target field; note the transformation rules used the inputted alignment).
While Portisch teaches data processing rules using statically compiled executable code, Molteni further supports this interpretation and is in the same field of endeavor, data management, and Molteni teaches:
obtaining, via a static code generator executed by a processor, a data processing engine instance comprising statically compiled executable code implementing a set of processing rules compiled therein, the set of processing rules being configured for at least one party, the statically compiled executable code being generated prior to runtime (Molteni, figures 2 and 4, [0002, 0038, 0051], note utilizing rule processing engines with rules; note each rule may be defined based on an executable model that is used to generate java source code representation of the rule; note the rules repository may store previously created rules, e.g., generated prior to runtime).
It would have been obvious to one of ordinary skill in the art before the effective date of filing to modify the cited references to incorporate the teachings of Molteni because all references are directed towards data management and because Molteni would expand upon the teachings of the previously cited references in data processing by improving the speed and efficiency by utilizing rule engines (Molteni, [0017]).
While Portisch as modified teaches data processing rules, Portisch as modified doesn’t specifically state using a pre-constructed structure that maps data types to corresponding processing rules, a subset oof the processing rules comprising at least one first processing rule, the pre-constructed structured being generated during the static compilation. However, Krishnaraju is in the same field of endeavor, data management and processing, and Krishnaraju teaches:
A method of data processing, comprising: obtaining, via a static code generator executed by a processor, a data processing engine instance comprising statically compiled executable code implementing a set of processing rules compiled therein, the set of processing rules being configured for at least one party, the statically compiled executable code being generated prior to runtime based on a rule logic configuration and a static definition of a data schema (Krishnaraju, figures 3-6, [0016, 0022-0024, 0038, 0067-0068], note mapping, business, and technical rules; note a mapping rule can define a software code script to modify the data to translate it from a first format to a second format; note rules for processing data types of a static definition of a schema are defined/created prior to runtime; note determining mapping rules to apply to a specific type of data to modify the data from a first format to a second format);
in response to receiving first data to be processed that is associated with a first data type from a first party of the at least one party, determining, by the data processing engine instance based on the first data type using a pre-constructed structure that maps data types to corresponding processing rules, a subset oof the processing rules comprising at least one first processing rule, the pre-constructed structured being generated during the static compilation (Krishnaraju, figures 3-6, [0016, 0022-0024, 0038, 0067-0068], note identifying data to be processed and determining mapping rules to apply to a specific type of data to modify the data from a first format to a second format. The rules that map the data type to the processing rules/format transformations is interpreted as the pre-constructed structure that maps data types to rules); and
processing, using the data processing engine instance by executing the statically compiled executable code of the determined subset of the processing rules, the first data by applying the at least one first processing rule, to obtain processed first data (Krishnaraju, figures 3-6, [0022-0024, 0038, 0067-0068, 0071], note utilizing the mapping rules to modify the data).
It would have been obvious to one of ordinary skill in the art before the effective date of filing to modify the cited references to incorporate the teachings of Krishnaraju because all references are directed towards data management and because Krishnaraju would expand upon the teachings of the previously cited references in data processing by improving the efficiency and accuracy by utilizing mapping rules to ensure data is processed appropriately.
Regarding Claim 2:
Portisch as modified shows the method as disclosed above;
Portisch as modified further teaches:
obtaining the rule logic configuration for the set of processing rules and the static definition of the data schema (Portisch, figures 1-3, [0029-0033, 0035-0036, 0070, 0075, 0104, 0121], note obtaining rule logic configurations and obtaining static data schemas; note the rule generation request may be a function call or made through an interface and it is the request that initiates the transformation rule engine, such as based on input; note the request input may include an alignment, an identifier for an alignment, one or more mappings or identifiers for mappings, an identifier for a source database, a source schema or identifier for a source schema, source instance data or references to source instance data, an identifier for a target database, a target schema or identifier for a target schema, target instance data or references to target instance data; note the alignment aligns the source schema with a target schema and can include mappings which indicate which fields match and contain information on how the data is to be translated such as with specific field types and data formats. This is all interepted as statically compiled executable code generated prior to runtime since it is included in the input and is based on rule logic and static definition of data schemas) (Molteni, [0014, 0038, 0051], note evaluating one or more rules against one or more facts, where each rule specifies, by its left-hand side, a condition and, by its right-hand side, at least one action to be performed if the condition of the rule is satisfied, which is interpreted as rule logic) (Krishnaraju, figures 3-6, [0016, 0022-0024, 0038, 0067-0068], note mapping, business, and technical rules; note a mapping rule can define a software code script to modify the data to translate it from a first format to a second format; note rules for processing data types of a static definition of a schema are defined/created prior to runtime; note determining mapping rules to apply to a specific type of data to modify the data from a first format to a second format); and
generating the statically compiled executable code for the set of processing rules based on the rule logic configuration and the static definition of the data schema prior to runtime (Portisch, figures 1-3 and 5b, abstract, [0029-0033, 0035-0036, 0070, 0075, 0104, 0121], note the transformation rules are determined based on rule logic and data types of data to be processed and the data schemas; note the rule generation request may be a function call or made through an interface and it is the request that initiates the transformation rule engine, such as based on input; note the request input may include an alignment, an identifier for an alignment, one or more mappings or identifiers for mappings, an identifier for a source database, a source schema or identifier for a source schema, source instance data or references to source instance data, an identifier for a target database, a target schema or identifier for a target schema, target instance data or references to target instance data; note the alignment aligns the source schema with a target schema and can include mappings which indicate which fields match and contain information on how the data is to be translated such as with specific field types and data formats. This is all interepted as statically compiled executable code generated prior to runtime since it is included in the input and is based on rule logic and static definition of data schemas) (Molteni, figures 2 and 4, [0002, 0038, 0051], note evaluating one or more rules against one or more facts, where each rule specifies, by its left-hand side, a condition and, by its right-hand side, at least one action to be performed if the condition of the rule is satisfied; note each rule may be defined based on an executable model that is used to generate java source code representation of the rule) (Krishnaraju, figures 3-6, [0016, 0022-0024, 0038, 0067-0068], note mapping, business, and technical rules; note a mapping rule can define a software code script to modify the data to translate it from a first format to a second format; note rules for processing data types of a static definition of a schema are defined/created prior to runtime; note determining mapping rules to apply to a specific type of data to modify the data from a first format to a second format).
It would have been obvious to one of ordinary skill in the art before the effective date of filing to modify the cited references to incorporate the teachings of Molteni because all references are directed towards data management and because Molteni would expand upon the teachings of the previously cited references in data processing by improving the speed and efficiency by utilizing rule engines (Molteni, [0017]).
It would have been obvious to one of ordinary skill in the art before the effective date of filing to modify the cited references to incorporate the teachings of Krishnaraju because all references are directed towards data management and because Krishnaraju would expand upon the teachings of the previously cited references in data processing by improving the efficiency and accuracy by utilizing mapping rules to ensure data is processed appropriately.
Regarding Claim 3:
Portisch as modified shows the method as disclosed above;
Portisch as modified further teaches:
wherein obtaining the data processing engine instance comprises: generating the data processing engine instance by compiling, by an embedded compiler, static code for the set of processing rules (Portisch, figures 1-3, abstract, [0029-0033, 0035-0036, 0121], note using a transformation rule engine, e.g., data processing engine; note obtaining and executing processing rules to format data, e.g., code for a set of processing rules; note invoking executable code to run the rule; note using the inputted alignment data for the generation of the rules) (Molteni, figures 2 and 4-5, [0002, 0038, 0051], note utilizing rule processing engines with rules; note obtaining rules and each rule may be defined based on an executable model that is used to generate java source code representation of the rule) (Krishnaraju, figures 3-6, [0016, 0022-0024, 0038, 0067-0068], note mapping, business, and technical rules; note a mapping rule can define a software code script to modify the data to translate it from a first format to a second format; note rules for processing data types of a static definition of a schema are defined/created prior to runtime; note determining mapping rules to apply to a specific type of data to modify the data from a first format to a second format); and
initializing the data processing engine instance generated (Portisch, figures 1-3, abstract, [0029-0030, 0035, 0121], note using a transformation rule engine, e.g., data processing engine; note obtaining and executing processing rules to format data, e.g., code for a set of processing rules; note invoking executable code to run the rule) (Molteni, figures 2 and 4, [0002, 0014, 0038, 0051], note utilizing rule processing engines with rules; note obtaining rules and each rule may be defined based on an executable model that is used to generate java source code representation of the rule) (Krishnaraju, figures 3-6, [0022-0024, 0038, 0067-0068, 0071], note utilizing the mapping rules to modify the data).
It would have been obvious to one of ordinary skill in the art before the effective date of filing to modify the cited references to incorporate the teachings of Molteni because all references are directed towards data management and because Molteni would expand upon the teachings of the previously cited references in data processing by improving the speed and efficiency by utilizing rule engines (Molteni, [0017]).
It would have been obvious to one of ordinary skill in the art before the effective date of filing to modify the cited references to incorporate the teachings of Krishnaraju because all references are directed towards data management and because Krishnaraju would expand upon the teachings of the previously cited references in data processing by improving the efficiency and accuracy by utilizing mapping rules to ensure data is processed appropriately.
Regarding Claim 5:
Portisch as modified shows the method as disclosed above;
Portisch as modified further teaches:
wherein the received first data is represented in a serialized bitstream, and the method further comprises: deserializing the received first data based on the static definition of the data schema to obtain deserialized first data, wherein the at least one first processing rule is applied to the deserialized first data (Portisch, figures 1-3 and 5b, [0031, 0035, 0070, 0075, 0104, 0121], note obtaining rule logic configurations and obtaining static data schemas) (Molteni, [0035], note deserialize a binary stream of serialized data to convert it into a format useable by the rules engine. When combined with the previously cited references deserializing the binary stream to make the data compatible based on the data schema would be for the schemas as taught by Portisch); and
serializing the processed first data based on the static definition of the data schema, to output the processed first data in a further serialized bitstream (Portisch, figures 1-3 and 5b, [0031, 0035, 0070, 0075, 0104, 0121], note the transformation rules are determined based on rule logic and data types of data to be processed and the data schemas, therefore if the target schema required serialized data the data would be reserialized when combined with the serializing teachings of Molteni) (Molteni, [0035], note deserialize a binary stream of serialized data to convert it into a format useable by the rules engine; note the data can be written to a binary stream, e.g. serialized. When combined with the previously cited references deserializing/serializing the binary stream based on the data schema would be for the schemas as taught by Portisch).
It would have been obvious to one of ordinary skill in the art before the effective date of filing to modify the cited references to incorporate the teachings of Molteni because all references are directed towards data management and because Molteni would expand upon the teachings of the previously cited references in data processing by improving the speed and efficiency by utilizing rule engines (Molteni, [0017]).
Regarding Claim 8:
Portisch as modified shows the method as disclosed above;
Portisch as modified further teaches:
in response to receiving second data to be processed from a second party of the at least one party, determining at least one second processing rule from the set of processing rules to be applied to the second data based on a data type of the second data (Portisch, figures 1-3 and 5b, abstract, [0070, 0075, 0104, 0121], note the transformation rules are determined based on data types of data to be processed; note this is done for each client/party using the system) (Krishnaraju, figures 3-6, [0016, 0022-0024, 0038, 0067-0068], note identifying data to be processed and determining mapping rules to apply to a specific type of data to modify the data from a first format to a second format. The rules that map the data type to the processing rules/format transformations is interpreted as the pre-constructed structure that maps data types to rules); and
processing, using the data processing engine instance, the second data by applying the at least one second processing rule, to obtain processed second data (Portisch, figures 1-4, abstract, [0070, 0079-0080, 0099-0100], note transformation rules produces output values which can be assigned to the target field; note this is done for each client/party using the system) (Krishnaraju, figures 3-6, [0022-0024, 0038, 0067-0068, 0071], note utilizing the mapping rules to modify the data).
It would have been obvious to one of ordinary skill in the art before the effective date of filing to modify the cited references to incorporate the teachings of Krishnaraju because all references are directed towards data management and because Krishnaraju would expand upon the teachings of the previously cited references in data processing by improving the efficiency and accuracy by utilizing mapping rules to ensure data is processed appropriately.
Regarding Claim 9:
Portisch as modified shows the method as disclosed above;
Portisch as modified further teaches:
wherein the data processing engine instance is comprised in an engine for extracting, transforming and loading data (Portisch, figures 1-3, abstract, [0029-0030, 0035, 0121, 0128], note using a transformation rule engine, e.g., data processing engine; note obtaining and executing processing rules) (Molteni, figures 2 and 4, [0002, 0038, 0051], note utilizing rule processing engines with rules; note each rule may be defined based on an executable model that is used to generate java source code representation of the rule).
It would have been obvious to one of ordinary skill in the art before the effective date of filing to modify the cited references to incorporate the teachings of Molteni because all references are directed towards data management and because Molteni would expand upon the teachings of the previously cited references in data processing by improving the speed and efficiency by utilizing rule engines (Molteni, [0017]).
Claim 10 discloses substantially the same limitations as claim 1 respectively, except claim 10 is directed to a system with a processor and memory (Portisch, figure 7, note processor and memory) while claim 1 is directed to a method. Therefore claim 10 is rejected under the same rationale set forth for claim 1.
Claim 11 discloses substantially the same limitations as claim 2 respectively, except claim 11 is directed to a system with a processor and memory (Portisch, figure 7, note processor and memory) while claim 2 is directed to a method. Therefore claim 11 is rejected under the same rationale set forth for claim 2.
Claim 12 discloses substantially the same limitations as claim 3 respectively, except claim 12 is directed to a system with a processor and memory (Portisch, figure 7, note processor and memory) while claim 3 is directed to a method. Therefore claim 12 is rejected under the same rationale set forth for claim 3.
Claim 14 discloses substantially the same limitations as claim 5 respectively, except claim 14 is directed to a system with a processor and memory (Portisch, figure 7, note processor and memory) while claim 5 is directed to a method. Therefore claim 14 is rejected under the same rationale set forth for claim 5.
Claim 17 discloses substantially the same limitations as claim 8 respectively, except claim 17 is directed to a system with a processor and memory (Portisch, figure 7, note processor and memory) while claim 8 is directed to a method. Therefore claim 17 is rejected under the same rationale set forth for claim 8.
Claim 18 discloses substantially the same limitations as claim 9 respectively, except claim 18 is directed to a system with a processor and memory (Portisch, figure 7, note processor and memory) while claim 9 is directed to a method. Therefore claim 18 is rejected under the same rationale set forth for claim 9.
Claim 19 discloses substantially the same limitations as claim 1 respectively, except claim 19 is directed to a non-transitory computer readable storage medium executed by an electronic device (Portisch, figure 7) while claim 1 is directed to a method. Therefore claim 19 is rejected under the same rationale set forth for claim 1.
Claim 20 discloses substantially the same limitations as claim 2 respectively, except claim 20 is directed to a non-transitory computer readable storage medium executed by an electronic device (Portisch, figure 7) while claim 2 is directed to a method. Therefore claim 20 is rejected under the same rationale set forth for claim 2.
Claim Rejections - 35 USC § 103
Claim(s) 4 and 13 is/are rejected under 35 U.S.C. 103 as being unpatentable over Portisch in view of Molteni, Krishnaraju, and Singh et al. (US2024/0184979, previously presented in ‘892), hereinafter Singh.
Regarding Claim 4:
Portisch as modified shows the method as disclosed above;
Portisch as modified further teaches:
wherein determining the subset of the processing rules comprising the at least one first processing rule comprises: in accordance with a determination that the set of processing rules comprise a subset of transformation rules for transforming data each associated with a predetermined data type from the at least one party, determining whether the data type of the first data matches a predetermined data type associated with at least one transformation rule among the subset of transformation rules (Portisch, figures 1-3 and 5b, abstract, [0029-0033, 0035-0036, 0070-0075, 0104, 0121], note the transformation rules are determined based on data types of data to be processed matching the data types of the rules; note the use of alignment data) (Krishnaraju, figures 3-6, [0016, 0022-0024, 0038, 0067-0068], note identifying data to be processed and determining mapping rules to apply to a specific type of data to modify the data from a first format to a second format. The rules that map the data type to the processing rules/format transformations is interpreted as the pre-constructed structure that maps data types to rules); and
in accordance with a determination that the data type of the first data matches the predetermined data type, determining the at least one transformation rule to be applied to the first data (Portisch, figures 1-3 and 5b, abstract, [0029-0033, 0035-0036, 0070-0075, 0104, 0121], note the transformation rules are determined based on data types of data to be processed matching the data types of the rules; note the use of inputted alignment data) (Krishnaraju, figures 3-6, [0016, 0022-0024, 0038, 0067-0068], note identifying data to be processed and determining mapping rules to apply to a specific type of data to modify the data from a first format to a second format. The rules that map the data type to the processing rules/format transformations is interpreted as the pre-constructed structure that maps data types to rules).
It would have been obvious to one of ordinary skill in the art before the effective date of filing to modify the cited references to incorporate the teachings of Krishnaraju because all references are directed towards data management and because Krishnaraju would expand upon the teachings of the previously cited references in data processing by improving the efficiency and accuracy by utilizing mapping rules to ensure data is processed appropriately.
While Portisch as modified teaches data processing rules, Portisch as modified doesn’t specifically state filter rules. However, Singh is in the same field of endeavor, data management, and Singh teaches:
in accordance with a determination that the set of processing rules comprise a subset of filter rules for filtering data, determining the subset of filter rules to be applied to the first data (Singh, abstract, figure 4, [0004, 0042, 0045, 0052, 0079], note filtering rules).
It would have been obvious to one of ordinary skill in the art before the effective date of filing to modify the cited references to incorporate the teachings of Singh because all references are directed towards data management and because Singh would expand upon the teachings of the previously cited references in data processing by improving the usability and efficiency by utilizing rule engines (Singh, [0022, 0055]).
Claim 13 discloses substantially the same limitations as claim 4 respectively, except claim 13 is directed to a system with a processor and memory (Portisch, figure 7, note processor and memory) while claim 4 is directed to a method. Therefore claim 13 is rejected under the same rationale set forth for claim 4.
Claim Rejections - 35 USC § 103
Claim(s) 6-7 and 15-16 is/are rejected under 35 U.S.C. 103 as being unpatentable over Portisch in view of Molteni, Krishnaraju, and Lytle (US2016/0328488, previously presented in ‘892).
Regarding Claim 6:
Portisch as modified shows the method as disclosed above;
Portisch as modified further teaches:
wherein the least one first processing rule is applied to the deserialized first data (Portisch, figures 1-3 and 5b, [0031, 0035, 0070, 0075, 0104, 0121], note obtaining rule logic configurations and obtaining static data schemas to determine and apply processing rules to deserialized first data) (Molteni, [0035], note deserialize a binary stream of serialized data to convert it into a format useable by the rules engine. When combined with the previously cited references deserializing the binary stream to make the data compatible based on the data schema would be for the schemas and rules processing as taught by Portisch); and
wherein serializing the processed first data comprises: serializing the processed first data, to output the serialized first data in the further serialized bitstream (Portisch, figures 1-3 and 5b, [0031, 0035, 0070, 0075, 0104, 0121], note the transformation rules are determined based on rule logic and data types of data to be processed and the data schemas, therefore if the target schema required serialized data the data would be reserialized when combined with the serializing teachings of Molteni) (Molteni, [0035], note the data can be written to a binary stream, e.g. serialized. When combined with the previously cited references deserializing/serializing the binary stream based on the data schema would be for the schemas as taught by Portisch).
It would have been obvious to one of ordinary skill in the art before the effective date of filing to modify the cited references to incorporate the teachings of Molteni because all references are directed towards data management and because Molteni would expand upon the teachings of the previously cited references in data processing by improving the speed and efficiency by utilizing rule engines (Molteni, [0017]).
While Portisch as modified teaches deserialization and serialization, Portisch as modified doesn’t specifically teach wherein the static definition of data schema is defined with a class bytecode of at least one data field, and wherein deserializing the received first data comprises: deserializing the received first data using the class bytecode of the at least one data field to obtain the deserialized first data; serializing the processed first data using the class bytecode of the at least one data field. However, Lytle is in the same field of endeavor, data management, and Lytle teaches:
wherein the static definition of the data schema is defined with a class bytecode of at least one data field (Lytle, [0137, 0143-0144, 0147], note deserializing objects; note using the bytecode for the object for deserialization/serialization; note the bytecode may be references using a schema), and wherein deserializing the received first data comprises
deserializing the received first data using the class bytecode of the at least one data field to obtain the deserialized first data (Lytle, [0137, 0143-0144, 0147], note deserializing objects; note using the bytecode for the object for deserialization/serialization; note the bytecode may be references using a schema)
wherein serializing the processed first data comprises: serializing the processed first data using the class bytecode of the at least one data field, to output the serialized first data in the further serialized bitstream (Lytle, [0137, 0143-0144, 0147], note serializing objects to send replies to the client; note using the bytecode for the object for deserialization/serialization; note the bytecode may be references using a schema).
It would have been obvious to one of ordinary skill in the art before the effective date of filing to modify the cited references to incorporate the teachings of Lytle because all references are directed towards data management and because Lytle would expand upon the teachings of the previously cited references in data processing by improving the useability and accessibility of the system by converting data to compatible formats to be processed.
Regarding Claim 7:
Portisch as modified shows the method as disclosed above;
Portisch as modified further teaches:
wherein the static definition of the data schema is defined with a descriptor of at least one data field, and wherein deserializing the received first data comprises: wherein the at least one first processing rule is applied to the deserialized segmentation of the first data (Portisch, figures 1-3 and 5b, [0031, 0035, 0070, 0075, 0104, 0121], note obtaining rule logic configurations and obtaining static data schemas to determine and apply processing rules to deserialized first data; note the data schemas comprise descriptors of data fields) (Molteni, [0035], note deserialize a binary stream of serialized data to convert it into a format useable by the rules engine. When combined with the previously cited references deserializing the binary stream to make the data compatible based on the data schema would be for the schemas and rules processing as taught by Portisch); and
wherein serializing the processed first data comprises: serializing a processed segmentation of the first data using the descriptor, to output the processed segmentation of the first data in the further serialized bitstream (Portisch, figures 1-3 and 5b, [0031, 0035, 0070, 0075, 0104, 0121], note the data schemas comprise descriptors of data fields; note the transformation rules are determined based on rule logic and data types of data to be processed and the data schemas, therefore if the target schema required serialized data the data would be reserialized when combined with the serializing teachings of Molteni) (Molteni, [0035], note the data can be written to a binary stream, e.g. serialized. When combined with the previously cited references deserializing/serializing the binary stream based on the data schema would be for the schemas as taught by Portisch).
It would have been obvious to one of ordinary skill in the art before the effective date of filing to modify the cited references to incorporate the teachings of Molteni because all references are directed towards data management and because Molteni would expand upon the teachings of the previously cited references in data processing by improving the speed and efficiency by utilizing rule engines (Molteni, [0017]).
While Portisch as modified teaches deserialization and serialization, Portisch as modified doesn’t specifically teach deserializing a segmentation of the received first data using the descriptor of the at least one data field to obtain a deserialized segmentation of the first data. However, Lytle is in the same field of endeavor, data management, and Lytle teaches:
deserializing a segmentation of the received first data using the descriptor of the at least one data field to obtain a deserialized segmentation of the first data (Lytle, [0137, 0143-0144, 0147], note deserializing objects; note using the bytecode for the object for deserialization/serialization; note the use of descriptors; note the bytecode may be references using a schema. When combined with the previously cited references this would include the schema teachings of Portisch)
wherein serializing the processed first data comprises: serializing the processed segmentation of the first data using the descriptor, to output the processed segmentation of the first data in the further serialized bitstream (Lytle, [0137, 0143-0144, 0147], note serializing objects to send replies to the client; note using the bytecode for the object for deserialization/serialization; note the use of descriptors; note the bytecode may be references using a schema. When combined with the previously cited references this would include the schema teachings of Portisch).
It would have been obvious to one of ordinary skill in the art before the effective date of filing to modify the cited references to incorporate the teachings of Lytle because all references are directed towards data management and because Lytle would expand upon the teachings of the previously cited references in data processing by improving the useability and accessibility of the system by converting data to compatible formats to be processed.
Claim 15 discloses substantially the same limitations as claim 6 respectively, except claim 15 is directed to a system with a processor and memory (Portisch, figure 7, note processor and memory) while claim 6 is directed to a method. Therefore claim 15 is rejected under the same rationale set forth for claim 6.
Claim 16 discloses substantially the same limitations as claim 7 respectively, except claim 16 is directed to a system with a processor and memory (Portisch, figure 7, note processor and memory) while claim 7 is directed to a method. Therefore claim 16 is rejected under the same rationale set forth for claim 7.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Vaishnav et al. (US2024/0169299) teaches statically compiled executable code implementing a set of processing rules generated prior to runtime.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JOHN J MORRIS whose telephone number is (571)272-3314. The examiner can normally be reached M-F 6:00-2:00 PM EST.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, James Trujillo can be reached at 571-272-3677. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/JOHN J MORRIS/Examiner, Art Unit 2151 6/6/2026
/James Trujillo/Supervisory Patent Examiner, Art Unit 2151
Prosecution Insights