DETAILED ACTION
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 .
Introductory Remarks
In response to communications filed on 12 July 2026, claims 1, 10, and 17 are amended per Applicant's request. No claims were cancelled. No claims were withdrawn. No new claims were added. Therefore, claims 1-20 are presently pending in the application, of which claims 1, 10, and 17 are presented in independent form.
The previously raised 102/103 rejection of the pending claims is withdrawn in view of the amendments to the claims. A new ground(s) of rejection has been issued.
Response to Arguments
Applicant’s arguments filed 12 July 2026 with respect to the rejection of the claims under 35 U.S.C. 102/103 (see Remarks, p. 9-13) have been fully considered but are not persuasive.
Applicant’s argument that “Bhatti does not teach a validator that instantiates an instance of the received data object from the received string and obtains the multilayer schema from that instantiated data-object instance”, “iteratively instantiates objects associated with the referenced subschemas to cause those instances to load their respective schemas”, and “iteratively instantiating objects associated with the subschemas and causing those object instances to load schemas associated with the respective instances” (see Remarks, p. 11, and similarly in Remarks, p. 12), are moot, as Applicant is arguing against a reference not being used in the current rejection (i.e., secondary reference Cosentino was used in combination with Bhatti to reject these claimed features).
Applicant’s argument that “Bhatti also does not teach or suggest that the multilayer schema and each referenced subschema are implemented by respective object classes that follow a common template schema” (see Remarks, p. 11) is unpersuasive for the reasons set forth in the 112 and 103 rejections below (e.g., this language was unsupported by the Specification, and based on the interpretation that was taken by the Office that was more consistent with the Specification, Bhatti did indeed disclose this claimed feature, e.g., the “base schema” being the claimed “template schema”).
Therefore, Applicant’s argument that modifying Bhatti to arrive at “the claimed object-instance-driven multilayer-schema architecture[,] would change the manner in which schemas are discovered, loaded, and assembled” (see Remarks, p. 12) is unpersuasive, as both Bhatti and the claimed invention pertain to linking schemas together into a sort of hierarchy, and iterating through that hierarchy to identify and retrieve/load those schemas in order to provide validation of the individual elements contained within those schemas. The instantiation of the object, as disclosed by secondary reference Cosentino, does not change the fundamental aspect of either Bhatti or the claimed invention, as the claimed steps disclosed by Bhatti would have been performed in the same manner regardless of instantiation or not. However, it would have been obvious to have incorporated Cosentino’s instantiation to arrive at the claimed invention for at least the reasons set forth in the 103 rationale below.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1-20 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Independent claims 1, 10, and 17 recite “wherein the multilayer schema is implemented by an object class that follows a template schema object, wherein each subschema of the one or more subschemas is implemented by a respective object class that follows the template schema object”.
Specification, [0021] and [FIG. 1] appears to be the closest paragraph. However, it states that the object class includes a template schema object 202 that every schema and/or subschema must follow, e.g., root schemas 204 implement the schema defined by the template schema. Thus, the object class is actually the entirety of [FIG. 2]; see, e.g., Specification, [0009] (“FIG. 2 is a diagram showing an example implementation of object classes that implement the multilevel schema…”).
Therefore, it is not that the object class follows a template schema object as claimed, but rather that the object class includes the template schema object, and each subschema of the one or more subschemas follows that template schema object.
The rest of the dependent claims are rejected for at least by virtue of their dependency on their respective independent claims.
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-20 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Independent claims 1, 10, and 17 recite “wherein the multilayer schema is implemented by an object class that follows a template schema object, wherein each subschema of the one or more subschemas is implemented by a respective object class that follows the template schema object”.
There is no support for such a limitation; rather, the object class is what appears to be defined by (i.e., implement) a multilevel schema, with object classes including the template schema object 202 (e.g., at the top of the schema hierarchy; see, e.g., [FIG. 2]). Thus, the object class is actually the entirety of [FIG. 2]; see, e.g., Specification, [0009] (“FIG. 2 is a diagram showing an example implementation of object classes that implement the multilevel schema…”). Therefore, it cannot be ascertained what is meant by, e.g., the entirety of FIG. 2 “following” one of its own sub-elements, e.g., template schema 202.
For purposes of examination, the interpretation that the object class is defined/implemented by a multilayer schema hierarchy which includes a template schema that includes subschemas has been taken, e.g., in accordance with the Specification at [FIG. 2], [0009], and [0021].
The rest of the dependent claims are rejected for at least by virtue of their dependency on their respective independent claims, and for failing to cure the deficiencies of their respective independent claims.
Claims 5-8 and 14 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claims 5 and 14 recite “instantiating an instance of the data object from the string”. Claim 8 recites “iteratively instantiating an instance of each object associated with the one or more subschemas”. These were already claimed in their respective independent claims.
For purposes of examination, the interpretation that these are repeated claim limitations of their respective independent claims have been taken.
Claims 6-7 are rejected for at least by virtue of their dependency on claim 5, and for failing to cure the deficiencies of claim 5.
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.
Claims 1-6 and 8-20 are rejected under 35 U.S.C. 103 as being unpatentable over Bhatti et al. (“Bhatti”) (US 2018/0232403 A1), in view of Cosentino et al. (“Cosentino”) (US 2022/0374398 A1).
Regarding claim 1: Bhatti teaches A data processing system comprising:
a processor; and a machine-readable medium storing executable instructions that, when executed, cause the processor alone or in combination with other processors to perform operations comprising (Bhatti, [0085], where the disclosed computing system 1000 may include one or more processors coupled to system memory 1020, where the processor may receive instructions and data from memory. See also Bhatti, [0021], where the processes may be embodied by program code stored in a tangible, non-transitory, machine-readable medium that are executable by a processor):
obtaining a string representing a data object at a validator, the data object comprising data generated by a first component of a cloud-based computing environment (Bhatti, [0022-0023], where the system obtains a node, e.g., by receiving a record encoded in a hierarchical serialized data format such as JSON (i.e., “data object”), where obtaining a node may include obtaining an entry to be added to the graph database in the form of an application program interface response, e.g., from a third party software-as-a-service (SaaS) application (i.e., “first component”), e.g., from a cloud computing system (Bhatti, [0068] and [0092]) (i.e., “generated by a first component of a cloud-based computing environment”). See Bhatti, [0072], where the computing environment 230 includes a data validator 228 that performs the operations of [FIG. 1] and [FIG. 2], where [FIG. 1] pertains to data validation (see also Bhatti, [0009]).
After obtaining the schema (whether from forming the polymorphic schema, or accessing the polymorphic schema that is already stored in program state), the system determines whether the node satisfies criteria (i.e., “constraints”) of the polymorphic schema which includes a plurality of criteria for determining whether nodes or other data entries are valid (i.e., “which must be satisfied in order for the data object to be valid against the schema”). Such entries may include a plurality of different fields of information, and the polymorphic schema may include criteria pertaining to some or all of those fields and indicating acceptable values (i.e., “one or more first constraints on the data of the data object”1). Recall from Bhatti, [0009] and [0072], where a data validator performs the operations of [FIG. 1], which pertains to data validation);
obtaining a multilayer schema for validating the data object using the validator, the multilayer schema specifying one or more first constraints on the data of the data object which must be satisfied in order for the data object to be valid against the multilayer schema (Bhatti, [0029], [0041] and [FIG. 2], where a plurality of schemas may be arranged in a hierarchical arrangement of schemas, like in a schema tree (i.e., “multilayer schema”). A schema may reference another schema, where upon determining that the schema contains a reference to another schema, that referenced schema may be obtained from memory, where block 38 (obtaining the referenced schema from memory) and block 40 (determining a schema references another schema) may be performed by a recursive function, where in this recursive function/fashion, the system may process and obtain a number of referenced schemas in a chain (e.g., through a hierarchy) of referenced schemas (i.e., “obtaining a multilayer schema”).
See Bhatti, [0027-0028] and [0032-0033], where the polymorphic schema is used to determine whether a node (corresponding to a set of validation criteria in a schema) satisfies criteria of the polymorphic schema, thereby validating whether the node satisfies the polymorphic schema (i.e., “obtaining a multilayer schema for validating the data object using the validator”));
determining, using the validator, that the multilayer schema references one or more subschemas, wherein the multilayer schema is implemented by an object class that follows a template schema object, wherein each subschema of the one or more subschemas is implemented by a respective object class that follows the template schema object, and wherein the one or more subschemas are reusable and interchangeable and specify one or more second constraints on the data of the data object which must be satisfied in order for the data object to be valid against the one or more subschemas; obtaining the one or more subschemas using the validator … (Bhatti, [0029], [0041] and [FIG. 2], where a schema may reference another schema, where upon determining that the schema contains a reference to another schema (i.e., “determining, using the validator, that the multilayer schema references one or more subschemas”), that referenced schema may be obtained from memory, where block 38 (obtaining the referenced schema from memory) and block 40 (determining a schema references another schema) may be performed by a recursive function, where in this recursive function/fashion, the system may process and obtain a number of referenced schemas in a chain (e.g., through a hierarchy) of referenced schemas (i.e., “obtaining the one or more subschemas using the validator”).
See Bhatti, [0027-0029], [0032-0033], [0041], and [FIG. 2] above with respect to the polymorphic schema containing criteria for determining whether nodes or other data entries are valid (i.e., “wherein the one or more subschemas…specify one or more second constraints on the data of the data object which must be satisfied in order for the data object to be valid against the one or more subschemas”). The system may process and obtain a number of referenced schemas in a chain (e.g., through a hierarchy) of referenced schemas (i.e., “the one or more subschemas being…interchangeable”).
See Bhatti, [0051], where the disclosed techniques may be used to implement polymorphic schemas by which schema criteria are reused across multiple schemas (i.e., “the one or more subschemas being reusable”)
See Bhatti, [0020] and [0045-0049], where documents define polymorphic schemas with inheritance, where base schemas (i.e., “template schema”) may be declared, and then aspects of that base schema may be modified by a more specific variant. For example, “accountSaaSCo.json” and “accounts.json” are examples of the claimed “object classes”, each of which extends the “accounts.json” schema and “targetEntities” schema, respectively. Thus, “accounts” and “targetEntities” function as the claimed “template schema”, which include properties of their inherited template schema, and may extend them by adding new properties or redefining existing ones. These may be combined with other schemas to form a set of referenced schemas along a chain or hierarchy, resulting in a polymorphic schema with multiple layers (i.e., “wherein the multilayer schema is implemented by an object class that follows a template schema object, wherein each subschema of the one or more subschemas is implemented by a respective object class that follows the template schema object”));
forming, by the validator, a single schema from definitions of the multilayer schema and the one or more subschemas, the single schema including the one or more first constraints and the one or more second constraints for validating the data object (Bhatti, [0028] and [0036], where the disclosed polymorphic schema is formed by combining a plurality of different schemas, e.g., having already been formed in an earlier instance of the process 10. See Bhatti, [0027-0029], [0032-0033], [0041], and [FIG. 2] above with respect to the polymorphic schema containing criteria for determining whether nodes or other data entries are valid (i.e., “the single schema including the one or more first constraints and the one or more second constraints for validating the data object”). See also, e.g., Bhatti, [0045-0047], where “accountSaaSCo.json” schema, corresponding to a fictitious example SaaS application provider named SaaSCo, may be declared as extending an “accounts.json” schema, where the merging signifies that the nodes/properties declared in the “properties” section of the accountSaaSCo.json schema are added to the accounts schema, thereby adding new properties or redefining existing ones);
validating, by the validator, the data object using the single schema by determining that the data object satisfies the first constraints specified by the multilayer schema and the second constraints specified by the one or more subschemas (Bhatti, [0027-0029] and [0032-0033], where the polymorphic schema is used to determine whether a node (corresponding to a set of validation criteria in a schema) satisfies criteria of the polymorphic schema, thereby validating whether the node satisfies the polymorphic schema. Recall from Bhatti above that this is done via the polymorphic schema that contains criteria for determining whether nodes or other data entries are valid); and
performing one or more actions using the data object in response to validating the data object (Bhatti, [0033-0034], where upon determining that the node does not satisfy the polymorphic schema, the system may proceed to block s28 and throw a validation error, including a message indicating the type of error, e.g., a validation error, and an indication of the criteria that the node failed to satisfy, e.g., including a list of failed criteria. Errors may be logged for later troubleshooting and, in some cases, handled by an error handling routine that implements logic to potentially address the validation error at issue. Alternatively, upon determining that the node does satisfy the criteria of the polymorphic schema, the system may proceed to block 26 and store the node and related edges in the graph database).
Bhatti does not appear to explicitly teach instantiating, by the validator, an instance of the data object from the string; [and] wherein obtaining the one or more subschemas comprises iteratively instantiating an instance of each object associated with the one or more subschemas and causing each respective instance to load a schema associated with the respective instance.
Cosentino teaches instantiating, by the validator, an instance of the data object from the string; [and] wherein obtaining the one or more subschemas comprises iteratively instantiating an instance of each object associated with the one or more subschemas and causing each respective instance to load a schema associated with the respective instance (Cosentino, [0018], where after obtaining schema 136 from registry 132 and copying it locally as schema 124, the processing device generates class 119 (e.g., a container class) in view of schema 124 (i.e., “instantiating…an instance of the data object from the string”), so that the class has properties compatible with records 134. When an instance is instantiated using class 119, it may act as a container for a record that is consumed by the consumer application. See Bhatti above with respect to “validator”.
See also Bhatti, [0041], with respect to the “iteratively” and “subschema” aspect, i.e., where a schema may reference another schema, where upon determining that the schema contains a reference to another schema, that referenced schema may be obtained from memory, where block 38 (obtaining the referenced schema from memory) and block 40 (determining a schema references another schema) may be performed by a recursive function. In this manner, in a recursive manner, the system may process and obtain referenced schemas in a chain (e.g., through a hierarchy) of referenced schemas).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have combined the teachings of Bhatti and Cosentino (hereinafter “Bhatti as modified”) by iterating through all of Bhatti’s schemas and subschemas (for instantiation in Cosentino) with the motivation of accommodating new relationships, types of entities, data types, and parameters of relationships and entities with little additional effort even with more complex types of data relationships (Bhatti, [0003]), i.e., greater flexibility in types of data that can be managed, including complex data relationships.
Regarding claim 2: Bhatti as modified teaches The data processing system of claim 1, wherein performing the one or more actions using the data object in response to validating the data object further comprises:
generating an incident report with an incident management system in response to determining that the data object is invalid (Bhatti, [0033], where upon determining that the node does not satisfy the polymorphic schema, the system may proceed to block s28 and throw a validation error, including a message indicating the type of error, e.g., a validation error, and an indication of the criteria that the node failed to satisfy, e.g., including a list of failed criteria. Errors may be logged for later troubleshooting and, in some cases, handled by an error handling routine that implements logic to potentially address the validation error at issue).
Although Bhatti does not appear to explicitly state that the error is logged as an “incident report with an incident management system” as claimed, one of ordinary skill in the art would have found it obvious to have modified Bhatti with predictably equivalent characteristics, which is that errors are reported. One of ordinary skill in the art would have found it obvious to do so with the motivation of logging errors for later troubleshooting and possibly addressing the validation error at issue (Bhatti, [0033]).
Regarding claim 3: Bhatti as modified teaches The data processing system of claim 1, wherein performing the one or more actions using the data object in response to validating the data object further comprises:
sending the data object to a second component of a cloud-based computing environment (Bhatti, [0034], where upon determining that the node does satisfy the criteria of the polymorphic schema, the system may proceed to block 26 and store the node and related edges in the graph database (i.e., “second component of a cloud-based computing environment”)).
Regarding claim 4: Bhatti as modified teaches The data processing system of claim 1, wherein the machine-readable medium further includes instructions configured to cause the processor alone or in combination with other processors to perform operations of:
processing the data object using the first component of the cloud-based computing environment (Bhatti, [0024], where a node may represent an account to be added to a SaaS application, the node being an update to an existing node within the graph database, or be a new node not yet stored in the graph database. See also, e.g., Bhatti, [0076], where controller 248 may respond to updates to a graph data structure by instructing the data sync module 252 to translate the modified nodes and edges into API commands, and send those API commands to the corresponding third-party SaaS applications (i.e., “first component”)).
Although Bhatti does not appear to explicitly state “processing” the JSON object, but rather states that the API commands are received by the third-party SaaS applications (i.e., the “first component”), API commands specify a type of action, e.g., processing, to be taken. Therefore, one of ordinary skill in the art would have been suggested by Bhatti’s disclosure to explicitly include a “processing” of the API command step with the motivation of ensuring that the graph database and corresponding records are synchronized with corresponding third-party SaaS applications 234 and 236 to implement new account configurations (Bhatti, [0071]), e.g., for security purposes while enabling users to be added/removed as desired (see, e.g., Bhatti, [0076]).
Regarding claim 5: Bhatti as modified teaches The data processing system of claim 1, wherein the validator is implemented by the first component of the cloud-based computing environment (Bhatti, [0072], where the computing environment 230 includes a data validator 228 that performs the operations of [FIG. 1] and [FIG. 2], where [FIG. 1] pertains to data validation (see also Bhatti, [0009])), and wherein the machine-readable medium further includes instructions configured to cause the processor alone or in combination with other processors to perform operations of:
instantiating an instance of the data object from the string, wherein obtaining the schema for validating the data object further comprises executing a get schema method on the data object to obtain the schema and the one or more subschemas (Cosentino, [0018], where the processing device obtains a schema 136 from the registry 132 and copies it locally as schema 124 (i.e., corresponding to “a get schema method”). The processing device can generate class 119 (e.g., a container class) in view of the schema 124, so that the class has properties that are compatible with the records 134. When an instance is instantiated using the class 119, it may act as a container for a record that is consumed by the consumer application. See Bhatti, [0027-0029], [0041], [FIG. 1] and [FIG. 2], above with respect to the obtaining of the JSON schema “and the one or more JSON subschemas”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have combined the teachings of Bhatti and Cosentino (hereinafter “Bhatti as modified”) with the motivation of using a container class that has properties that are compatible with incoming records to act as a container for a record that is consumed by the consumer application, thereby enabling development of consumer applications in an event streaming environment to be streamlined (Cosentino, [0018]), and enabling interoperability.
Although Bhatti as modified does not appear to explicitly state that the schemas are obtained by “executing a get schema method on the data object” as claimed, one of ordinary skill in the art would have recognized that a “get schema” method represents one of the common set of web services exposed by ASK, which retrieves (specified) schemas.2 Therefore, one of ordinary skill in the art would have found it obvious to have modified Bhatti as modified to include this specific method with the motivation of enabling programmers/developers to take advantage of pre-existing, i.e., built-in functions for ease of programmability (and possibly efficiency, as the pre-existing functions may be better optimized for handling such processes).
Regarding claim 6: Bhatti as modified teaches The data processing system of claim 5, wherein each subschema of the one or more subschemas is associated with a class of object of a plurality of classes of objects (Bhatti, [0036], where each node type (i.e., “class of object”) of a relatively large collection of node types (i.e., “of a plurality of classes of objects”) may correspond to a distinct schema, where these node type schemas may reference a plurality of schemas combined together to form the polymorphic schema).
Regarding claim 8: Bhatti as modified teaches The data processing system of claim 5, wherein the machine-readable medium further includes instructions configured to cause the processor alone or in combination with other processors to perform operations of:
iteratively instantiating an instance of each object associated with the one or more subschemas; and calling a get schema method on the instance of each object to cause the object to load a schema associated with the object (Cosentino, [0018], where the processing device obtains a schema 136 from the registry 132 and copies it locally as schema 124 (i.e., corresponding to “a get schema method”). The processing device can generate class 119 (e.g., a container class) in view of the schema 124, so that the class has properties that are compatible with the records 134. When an instance is instantiated using the class 119, it may act as a container for a record that is consumed by the consumer application.
See Bhatti, [0041], with respect to the “iteratively” and “subschema” aspect, i.e., where a schema may reference another schema, where upon determining that the schema contains a reference to another schema, that referenced schema may be obtained from memory, where block 38 (obtaining the referenced schema from memory) and block 40 (determining a schema references another schema) may be performed by a recursive function. In this manner, in a recursive manner, the system may process and obtain referenced schemas in a chain (e.g., through a hierarchy) of referenced schemas).
Regarding claim 9: Bhatti as modified teaches The data processing system of claim 1, wherein validating the data object using the schema and the one or more subschemas by comparing the data object with the schema and the one or more subschema further comprises:
determining that the data object is invalid if one or more properties indicated to be required by the schema or one or more subschemas is not present in the data object (Bhatti, [0032-0033], where the system determines whether the node satisfies criteria of the polymorphic schema, including a plurality of criteria for determining whether nodes or other data entries are valid. A criterion may require that a particular field have a value, regardless of what that value is, for instance, by indicating that a field is required (though in some cases, a criterion may indicate that a particular field is optional) (implying that the node (i.e., “JSON object”) would be invalid upon not meeting this criterion, i.e., that a required field (i.e., “property”) is not present). Upon determining that the node does not satisfy the polymorphic schema, i.e., that the child that is not a valid entry in the graph database of the type of the node, the system may throw a validation error).
Regarding claim 10: Claim 10 recites substantially the same claim limitations as claim 1, and is rejected for the same reasons.
Regarding claim 11: Claim 11 recites substantially the same claim limitations as claim 2, and is rejected for the same reasons.
Regarding claim 12: Claim 12 recites substantially the same claim limitations as claim 3, and is rejected for the same reasons.
Regarding claim 13: Claim 13 recites substantially the same claim limitations as claim 4, and is rejected for the same reasons.
Regarding claim 14: Claim 14 recites substantially the same claim limitations as claim 5, and is rejected for the same reasons.
Regarding claim 15: Claim 15 recites substantially the same claim limitations as claim 6, and is rejected for the same reasons.
Regarding claim 16: Claim 16 recites substantially the same claim limitations as claim 7, and is rejected for the same reasons.
Regarding claim 17: Claim 17 recites substantially the same claim limitations as claim 1, and is rejected for the same reasons.
Regarding claim 18: Claim 18 recites substantially the same claim limitations as claim 2, and is rejected for the same reasons.
Regarding claim 19: Claim 19 recites substantially the same claim limitations as claim 3, and is rejected for the same reasons.
Regarding claim 20: Claim 20 recites substantially the same claim limitations as claim 4, and is rejected for the same reasons.
Conclusion
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 IRENE BAKER whose telephone number is (408)918-7601. The examiner can normally be reached M-F 8-5PM PT.
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, Boris Gorney can be reached at (571) 270-5626. 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.
/IRENE BAKER/Primary Examiner, Art Unit 2154
4 August 2026
1 Note that Bhatti’s “criteria” describe the equivalent of “constraints”. See, e.g., Mandadi et al. (US 2020/0334374 A1) at [0052] (“Attribute constraints may be automatically validated…as part of execution data of client-specified code…. Constraints may include min/max values, min/max lengths (e.g., for strings), acceptable character sets, or regular expression-based validation”).
2 Hampapur et al. (US 2014/0330745 A1) at [0030-0031] and [TABLE 1].
Prosecution Insights