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 .
Information Disclosure Statement
An Information Disclosure Statement (IDS) has not been submitted as of the mailing of the last Office Action dated 11 June 2025. Applicant is reminded of the continuing obligation under 37 CFR 1.56 to timely apprise the Office of any information which is material to patentability of the claims under consideration in this application.
Introductory Remarks
In response to communications filed on 11 September 2025, claims 1, 6, 11, 14, and 19 are amended per Applicant's request. No claims were cancelled. No claims were withdrawn. No new claims were added. Therefore, claims 1-22 are presently pending in the application, of which claims 1, 11, and 19 are presented in independent form.
The previously raised 112 rejection of the pending claims is withdrawn for some, maintained for others, and new ground(s) raised for the independent claims.
The previously raised 101 rejection of the pending claims is maintained.
The previously raised 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 11 September 2025 with respect to the 112 rejections of the pending claims (see Remarks, p. 11-12) have been fully considered.
With respect to the independent claims, Applicant’s arguments are persuasive and the 112 rejection has been accordingly withdrawn. However, Applicant’s amendments have raised new issues, which are presented below.
Applicant’s arguments with respect to the 112 rejection is unpersuasive, as Applicant’s amendments to the independent claims still render the 112(b), indefiniteness rejection relevant to dependent claim 5. Therefore, the 112(b), indefiniteness rejection of claim 5 has been maintained.
Applicant’s arguments with respect to the 112 rejection of claims 6 and 14 have been fully considered. However, the amendments only addressed part of the issue. There is still a lack of antecedent basis issue with respect to the language “the” developer-end ecosystem and “the” user-end ecosystem.
Applicant’s arguments with respect to the 112 rejection of claims 7, 13, and 20 have been fully considered. The 112 rejection has been withdrawn.
Applicant’s arguments with respect to the 112 rejection of claims 8, 16, and 20 are not persuasive. Because “at least one” encompasses “both”, this means that Applicant is claiming that, if there were N user preferred values, a user preferred value i in the set of all user preferred values N, can be both approved and disapproved. Therefore, this is indefinite, as the same user preferred value i cannot be both approved and disapproved. Applicant is required to amend the claim language to indicate that for, e.g., ith user preferred value, it can be approved or disapproved, where as a jth user preferred value, different from the ith user preferred value, can be approved or disapproved, to more clearly articulate the intentions of the claimed invention.
Applicant’s arguments with respect to the 112 rejection of claims 10, 18, and 22 is unpersuasive, as Applicant solely argues that the example interpretation provided by the Office was meant to be taken with respect to “override”. However, simply stating what something is “not”, does not render it definite. Therefore, the 112 rejection has been maintained for claims 10, 18, and 22.
Applicant’s arguments filed 11 September 2025 with respect to the rejection of the claims under 35 U.S.C. 101 (see Remarks, p. 12-14) have been fully considered but are not persuasive.
Applicant argues that the claimed invention recites an improvement and thus were eligible (see Remarks, p. 13). However, this is unpersuasive. The claimed invention does not change the underlying functionality of the computer, but rather invoke the computer as tools to be implemented within the claimed process. The most that the computer is utilized within the claimed invention is simply stated in functional terms—e.g., an attempt to generally link the claimed steps to a particular technological environment, i.e., namely implementation via computers—and with respect to the most basic functioning aspects of a computer, e.g., receiving, transmitting, storing, and retrieving data.
Thus, the claimed invention does not improve the functioning of the computer itself, but merely invoke it generically utilizing the most basic processes of a computer, which does not lend any purported improvement to the relevant technology.
Applicant is recommended to consider focusing on the relevant elements that specifically indicates how the pin table “allow[s] for efficient tracking of all modifications, thereby providing a clear audit trail and enabling easy rollback of modifications, if necessary” (see, e.g., Specification, [0055]). However, note that any inventive concept must be in the claims, and thus the mere mention of the pin table within the claims does not add “significantly more”, if there were any purported advantages/benefits to the pin table that would render an improvement to the underlying technology. Any advantages/benefits of the pin table would require specific elements of the pin table that demonstrably achieve this purported advantage/benefit, and not simply the utilization of the pin table at a high level of generality, which, given the manner it is currently claimed, operates in a similar manner as generic storage.
Applicant’s arguments filed 11 September 2025 with respect to the rejection of the claims under 35 U.S.C. 103 (see Remarks, p. 14-16) have been fully considered but are not persuasive.
Applicant argues that the prior art do not disclose the amended claim features. However, these arguments are unpersuasive, as the prior does suggest or otherwise render obvious this amended claim feature, and the 103 rejection has been modified below to conform to the amended claim language.
Claim Objections
Claims 1, 11, and 19 are objected to because of the following informalities: the claims recite “wherein the conflict correspond…”. This should be “corresponds”. Appropriate correction is required.
Claim Rejections - 35 USC § 112
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-22 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, 11, and 19 recite both a singular “modification” of the hierarchical product parameter, and plural “modifications” of the hierarchical product parameter. It is unclear which is being claimed, i.e., there is a lack of antecedent basis for “modifications”.
As a result, there is also a lack of antecedent basis issue with Claim 5, which also recites the plural “modifications”.
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 6 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.
The claims recite “…at both the developer-end ecosystem and the user-end ecosystem”. There is a lack of antecedent basis for such limitations.
Claims 8-10, 16-18, and 20-22 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.
The claims recite “wherein the user validation includes at least one of approval and disapproval of the user preferred values of the hierarchical product parameter in the hierarchy of operational factors”.
Because the claims only pertain to one instance of a conflict, the user validation can only apply to either an approval or a disapproval of that one particular identified conflict. Even if one were to broadly interpret the user validation comprising multiple user validations, the manner in which the claims are written enables both approval and disapproval to occur for any singular user preferred value, which is indefinite, as the same user preferred value cannot be both approved and disapproved.
Dependent claims 9-10, 17-18, and 21-22 are rejected for at least by virtue of their dependency on claims 8, 16, and 20, and for failing to cure the deficiencies of their respective parent claims.
Claims 10, 18, and 22 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.
The claims recite “override the user preferred values…with the selected recommended value”.
Neither the independent claims nor these claims recite that the user preferred values are being overwritten/overridden, or what is meant by such a limitation, or whether the claim was intended to be directed to the pin table (as the only mention of storage refers to the pin table for tracking modifications). Therefore, it is unclear what is meant by such a limitation, and whether such a limitation has a relationship with the updating of the pin table step.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-22 are rejected under 35 U.S.C. 101 because the claims are directed to a judicial exception (i.e., an abstract idea) without significantly more.
Independent Claims 1, 11, and 19 recite both “Certain Methods of Organizing Human Activity” and “Mental Processes” groupings of abstract ideas. More particularly, the claims recite modifying a hierarchical product parameter in a hierarchy of operational factors, the hierarchical product parameter being an operational factor associated with an offering within the hierarchy of operational factors (i.e., “Managing personal behavior and relationships or interactions between people”, a subgrouping of “Certain Methods of Organizing Human Activity”); obtaining recommended values associated with the modifications of the hierarchical product parameter (i.e., a form of “filtering data”, which is “a long-standing, well-known method of organizing human behavior, similar to concepts previously found to be abstract”1); determining a conflict in the modifications associated with the modified hierarchical product parameter, comparing user preferred values of the modified hierarchical product parameter with recommended values to identify inconsistent values of the hierarchical product parameter (i.e., an evaluation, observation, and/or judgment, which falls under the “Mental Processes” grouping of abstract ideas); obtaining and notifying the user to validate the modifications based on the identified inconsistent values (i.e., “Managing personal behavior and relationships or interactions between people”).
Dependent Claims 6 and 14 recite monitoring the hierarchical product parameters to track the modifications on the hierarchical product parameters during operations. This is a form of “Managing personal behavior and relationships or interactions between people”, which falls under the “Certain Methods of Organizing Human Activity” grouping of abstract ideas.
Dependent Claims 7, 15, and 20 recite prompting the user to review the user preferred values of the modified hierarchical product parameter. This is a form of “Managing personal behavior and relationships or interactions between people”, which falls under the “Certain Methods of Organizing Human Activity” grouping of abstract ideas.
Dependent Claims 8-10, 16-18, and 20-22 recite that the user validation includes at least one of approval/disapproval of the user preferred values of the hierarchical product parameter in the hierarchy of operational factors, and that if the user approves, retaining the modified hierarchical product parameter with the user preferred values of the hierarchical product parameter; but if the user disapproves, then then override the user preferred values of the hierarchical product parameter (with the user’s selected recommended value).
Because the claims do no more than cover performance of the limitation in the mind but for the recitation of generic computer components, the claims therefore fall within the “Mental Processes” grouping of abstract ideas (in addition to “Certain Methods of Organizing Human Activity”). Accordingly, the claims recite an abstract idea.
The claims are not integrated into a practical application of that idea. In particular, the claims recite various computing hardware components, which are recited at a high level of generality and recited so generically that they represent no more than mere instructions to apply the judicial exception on a computer (see MPEP 2106.05(f)). These limitations can also be viewed as nothing more than an attempt to generally link the use of the judicial exception to the technological environment of a computer (see MPEP 2106.05(h)).
Furthermore, independent Claims 1, 11, and 19 recite recording the modified values in a database for storing modifications of the hierarchical product parameter, wherein the modifications are recorded in a pin table in the database; that the detected conflict corresponds to a conflicted pin value within the pin table in the database, and the conflict is detected by a part discovery module that runs within the system to identify the conflicting pin value within the pin table in the database; that the recommended values of a hierarchical product parameter are derived from a plurality of connected data sources, each connected data source from amongst the plurality of connected data sources being operated in connection with the unified platform; and updating the pin table based on the user validation. Similarly, dependent Claims 10, 18, and 22 recite updating the pin table (based on the user selected value). These are insignificant extra-solution activities that also attempt to limit the claims to a particular technological environment—namely, implementation via computers, which is an insignificant additional element.
The independent claims further recite receiving and processing the request to modify the hierarchical product parameter. Similarly, dependent Claims 7, 15, and 20 recite transmitting the identified inconsistent values to a feedback loop, where the feedback loop is configured to perform the prompting to the user. Dependent Claims 10, 18, and 22 recite receiving input from the user. These are all insignificant extra-solution activities that only represent a tangential or nominal addition to the claims.
Dependent Claim 2 recites that the unified platform comprises at least one of a developer-end ecosystem and a user-end ecosystem. Similarly, dependent Claim 4 recites that the offering operating in the unified platform comprises at least one of a product and a service. Dependent Claims 5 and 13 recite the types of modifications to the hierarchical product parameter. Dependent Claims 6 and 14 recite that the tracking of modifications occur at both the developer-end ecosystem and the user-end ecosystem. These are all insignificant field-of-use limitations, describing the context rather than a particular manner of achieving the result.
Dependent Claims 3 and 12 recite that the hierarchy of operational factors is formed from a variety of types of information including, e.g., a capability, a feature, a microservice, and a sub-module representing certain types of data and being sub-units of the other types of information, with the hierarchical product parameter comprising at least one of the capability, the feature, the microservice, and the sub-module. However, these are insignificant field-of-use limitations, describing the context rather than a particular manner of achieving the result (e.g., this structure is not utilized within the recited abstract ideas at all, but rather simply only list unrelated characteristics of the hierarchy of operational factors).
As such, the additional elements do not integrate the abstract idea into a practical application of that idea.
With respect to the well-understood, routine, and conventional elements, as stated previously above, the claims do not include any additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to the integration of the abstract idea into a practical application, the additional elements reciting the use of various computing software and hardware components amount to no more than mere instructions to apply the judicial exception using generic components. Mere instructions to apply an exception using generic computer components cannot provide an inventive concept.
Additionally, with regards to the claims’ recitation of receiving/transmitting data, accessing (i.e., retrieving) data, and updating data, are all well-understood, routine, and conventional activities within the computing realm. See MPEP 2106.05(d)(II) (“Receiving or transmitting data over a network, e.g., using the Internet to gather data” with respect to transmitting data, receiving data, and obtaining data; “Storing and retrieving data in memory” with respect to recording data; “Electronic recordkeeping” with respect to the recording and updating of data).
Even as an ordered combination, the claims as a whole do not contain any additional elements that amount to significantly more. The focus of the claims is on identifying conflicts in the data and presenting recommended values to the user for confirmation/acceptance/validation. The most detail with respect to the claimed computer is primarily as a tool for obtaining/storing/maintaining/updating data, and receiving the necessary inputs for storing/maintaining/updating. However, these are wholly conventional computing activities that are well-understood, routine, and conventional activities.
The identification of conflicts and the providing of recommendations are recited at a wholly generic level, that somehow the computer is able to determine conflicts or obtain the recommendations, which are used to compare against the user preferred values. However, such a high-level comparison is something that can be practically performed in the mind of a person. Therefore, the most the computer does in combination with the recited steps is primarily as a tool that is invoked in an attempt to limit the claims to a particular technological environment. However, simply reciting the abstract idea while adding the words “apply it” with a computer, does not amount to significantly more.
At that level of generality, the claims do no more than describe a desired function or outcome, without providing any limiting detail that confines the claims to a particular solution to an identified problem. The purely functional nature of the claim confirms that it is directed to an abstract idea, not to a concrete embodiment of that idea (see Affinity Labs of Texas LLC v. Amazon.com Inc., 838 F.3d 1253 (Fed. Cir. 2016) at p. 7-8, citing Elec. Power Grp., LLC v. Alstom S.A., 830 F.3d 1350 (Fed. Cir. 2016), slip op. 12 (“[T]he essentially result-focused, functional character of claim language has been a frequent feature of claims held ineligible under § 101”)). As a whole, the claims do not go beyond stating the relevant functions in general terms, without limiting them to a technical means for performing the functions that are arguably an advance over conventional database technologies.
Therefore, for at least the aforementioned reasons, the claims are rejected under 35 U.S.C. 101 for being directed to a judicial exception (i.e., an abstract idea) without significantly more.
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-22 are rejected under 35 U.S.C. 103 as being unpatentable over Samanthapudi et al. (“Samanthapudi”) (US 2015/0379442 A1), in view of Walker et al. (“Walker”) (US 2012/0213326 A1).
Regarding claim 1: Samanthapudi teaches A system to record modifications performed on a hierarchical product parameter in a hierarchy of operational factors for an offering operating in a unified platform, the system comprising: a processor to (Samanthapudi, [0005], where the system for implementing the disclosed steps may be implemented as computer-executable instructions that, when executed by the one or more processors, generate a configurable product based on multiple plans which are interdependent, e.g., in a hierarchical tree (see, e.g., Samanthapudi, [0008] and [0151-0152]). See Samanthapudi, [0026], where these configurable products may be offered to client devices 102-108 (i.e., “for an offering”). See Samanthapudi, [0032], where a product configuration server 110 and enterprise server 112 may communicate through an intranet or another type of public network, and/or may be directly connected (i.e., “unified platform”)):
receive a request from a user to modify the hierarchical product parameter in the hierarchy of operational factors, wherein the hierarchical product parameter is an operational factor associated with the offering within the hierarchy of operational factors; process the request for the modification of the hierarchical product parameter to obtain a modified hierarchical product parameter, the modified hierarchical product parameter being indicative of user preferred values of the hierarchical product parameter; record the modified hierarchical product parameter in a database for storing the modifications of the hierarchical product parameter, wherein the modifications are recorded in a pin table in the database (Samanthapudi, [0106-0107], where a modeler may make changes to the product plan, which are recorded in a task diary (implying that this request to make changes was “received”). See Samanthapudi, [0138] and, e.g., Samanthapudi, [0143], where changes may pertain to the feature, part, or coverage described in a component of the model (i.e., “an operational factor associated with the offering within the hierarchy of operational factors”). See Samanthapudi, [0106], where changes made to the product plan are recorded in a task diary (i.e., “pin table”) associated with the initiative/product plan, where a task diary may be any component capable of logging and/or tracking a user’s interactions with a document, where in this regard, the task diary may automatically track the changes and/or modifications made to the initiative, the user that makes those changes/modifications, and timestamp the changes/modifications.
Because Samanthapudi discloses (automatically) recording such information of the modifications/changes, this implies that the claimed “request for the modification of the hierarchical product parameter” was “process[ed]”, as claimed. Furthermore, because it is a modeler that is performing this value for later review (see, e.g., Samanthapudi, [0107]), this also implies that this modification is “indicative of user preferred values of the hierarchical product parameter” as claimed, as the reviewers may not necessarily approve this change (see, e.g., Samanthapudi, [0110]).
Although Samanthapudi does not appear to explicitly state that the task diary is a “pin table in [a] database” as claimed, one of ordinary skill in the art would have found it obvious to have modified Samanthapudi to have the task diary stored as a table within a database with the motivation of rendering such a log in a database form for more efficient organization and thus faster/easier retrieval of data given its more structured format); [and]
determine a conflict in the modifications associated with the modified hierarchical product parameter recorded in the pin table, wherein the conflict correspond to a conflicting pin value within the pin table in the database (Samanthapudi, [0107], where reviewers/approvers review the initiative/product plan (with the changes to the initiative/product plan) using the task diary (i.e., “pin table”) described in Samanthapudi, [0106], where the reviewers/approvers may check to ensure that the parameters set forth in the initiative request were met. Alternatively, the reviewers/approvers may review the initiative/product plan to check that it complies with company policy and applicable laws. This implies that a conflict may be detected, i.e., due to lack of compliance) … .
Although Samanthapudi does not appear to explicitly teach the conflict is detected by a part discovery module that runs within the system to identify the conflicting pin value within the pin table in the database, but rather that reviewers/approvers perform such a function, the only difference between the claimed invention and the prior art lie in that fact that the claimed invention automatically has this performed by the computer (e.g., via “a part discovery module that runs within the system”), broadly providing an automatic or mechanical means to replace a manual activity which accomplishes the same result is not sufficient to distinguish over the prior art. Therefore, one of ordinary skill in the art would have found it obvious to have modified Samanthapudi to have had such functions automatically performed with the motivation of increasing convenience to users.
Samanthapudi does not appear to explicitly teach obtain recommended values associated with the modification of the hierarchical product parameter, the recommended values of the hierarchical product parameter being derived from a plurality of connected data sources, each connected data source from amongst the plurality of connected data sources being operated in connection with the unified platform; compare the user preferred values of the recorded modified hierarchical product parameter with the recommended values of the hierarchical product parameter to identify inconsistent values of the hierarchical product parameter, notify the user to validate the modification based on the identified inconsistent values, wherein the notification includes recommended values of the hierarchical product parameter; and update the pin table based on the user validation.
Walker teaches obtain recommended values associated with the modification of the hierarchical product parameter, the recommended values of the hierarchical product parameter being derived from a plurality of connected data sources, each connected data source from amongst the plurality of connected data sources being operated in connection with the unified platform; compare the user preferred values of the recorded modified hierarchical product parameter with the recommended values of the hierarchical product parameter to identify inconsistent values of the hierarchical product parameter, notify the user to validate the modification based on the identified inconsistent values, wherein the notification includes recommended values of the hierarchical product parameter (Walker, [0029-0031], where each time a parameter is set or changed (by a user), the protocol parameter validator 212 can validate the parameters against the policy. When a default and/or user defined parameter differs from a policy-based parameter, the determiner 124 can variously respond, e.g., the protocol parameter validator 212 suggests or recommends replacement parameters that satisfy the policy. The user that has the accept/reject authority can receive a notification, where the notification may indicate that the personnel is needed to accept/reject a recommended scan parameter value, where the notification may include other relevant information such as the particular parameter, the initial parameter value, the recommended parameter value, and/or other information. See Walker, [0095-0097], where for a (radiation dose) policy, this can be drawn from a plurality of data sources, including, e.g., linking to offline databases that captured learned physician reading/IQ preferences to set preference-based dose reduction parameter thresholds (Walker, [0104]) (i.e., “the recommended value[] of the…parameter being derived from a plurality of connected data sources, each connected data source from amongst the plurality of connected data sources being operated in connection with the…platform”. See Samanthapudi, [0032], above with regards to the “unified platform”. See also Samanthapudi above with respect to the “hierarchical product” parameter); and
update the pin table based on the user validation (Walker, [0030-0031] and [0046], where an operator may accept a (change) suggestion, resulting in a replacement parameter being used to (manually) update the parameter. See Samanthapudi, [0106], where the task diary (i.e., “pin table”) only tracks the changes and/or modifications made to the initiative (implying that in combination with the user making changes via accepting a suggestion as disclosed in Walker, this would result in Samanthapudi’s task diary tracking that change/modification, i.e., “updat[ing] the pin table” as claimed).
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 Samanthapudi and Walker (hereinafter “Samanthapudi as modified”) with the motivation of (1) providing the convenience of suggestions, which helps expedite corrections or improvements, and (2) enabling the user to retain control over the nature of the suggestions, which enhances usability.
Regarding claim 2: Samanthapudi as modified teaches The system of claim 1, wherein the unified platform comprises at least one of a developer-end ecosystem and a user-end ecosystem (Samanthapudi, [0023-0024], where the disclosed system encompasses client devices 102-108 (i.e., “user-end ecosystem”) in communication with an enterprise server 120 (i.e., “developer-end ecosystem”) via network 112, where the one or more configurable products may be any type of product, including tangible or intangible products, including software products. See also Samanthapudi, [0029-0031], where published plans may be shared by multiple tenants on the cloud server, these plans having been developed (i.e., “developer-end ecosystem”) from one of the tenants, where users belonging to a tenant may collaborate to develop a model for the tenant. The product configuration system may allow extensions to be included on the models from third party content providers to allow a tenant subscriber to tailor the model to their specific needs and preferences (these tenant subscribers corresponding to the “user-end ecosystem”)).
Regarding claim 3: Samanthapudi as modified teaches The system of claim 1, wherein the hierarchy of operational factors is formed of:
a capability as a sub-unit of the offering, wherein the capability represents functions performed by the offering; a feature as a sub-unit of the capability, wherein the feature represents an item configurable to perform a capability; a microservice as a sub-unit of the feature, the microservice representing an executable piece of a programming file for performing the capability; and a sub-module as a sub-unit of the microservice, the sub-module representing a set of programming code integrable in the microservice; wherein the hierarchical product parameter comprises at least one of the capability, the feature, the microservice, and the sub-module (Samanthapudi, [0007-0008], where the system defines a configurable product/plan that includes product/plan parts, features, and/or options that refer to other configurable products/plans. One or more components (i.e., part, feature or option) may be defined for the configurable product/plan via the modeler, where the products, parts, features, clauses, options, and/or other aspects may be organized in a hierarchical structure, such as a tree structure. See also Samanthapudi, [0036], where the product model information includes hierarchies between various parts and features, and references between various product models.
See also, e.g., Samanthapudi, [0047-0049], where parts relate to various components that go into the product (i.e., “a feature as a sub-unit of the capability, wherein the feature represents an item configurable to perform a capability”). Features may provide additional details related to the parts, e.g., may further define the parts).
Although Samanthapudi does not appear to explicitly state that the information contained within the hierarchical configurable product/plan relates to, e.g., “a capability”, “offering”, “functions performed by the offering”, “a feature”, “an item configurable to perform a capability”, “a microservice”, etc., the claimed invention does not distinguish over the prior art because the differences in the claim limitations and the prior art’s disclosure are only found in the nonfunctional descriptive material and are not functionally involved in the steps recited. The storage of information in a hierarchical manner associated with hierarchical elements would have been performed the same regardless of the specific data involved (i.e., the claimed information, or some other data). Thus, this descriptive material will not distinguish the claimed invention from the prior art in terms of patentability. See In re Gulack, 703 F.2d 1381, 1385, 217 USPQ2d 401, 404 (Fed. Cir. 1983); In re Lowry, 32 F.3d 1579, 32 USPQ2d 1031 (Fed. Cir. 1994).
Therefore, it would have been obvious to a person of ordinary skill in the art to have referred to Samanthapudi’s teachings in making the claimed invention, because such data does not functionally relate to the steps in the method claimed and because the subjective interpretation of the data does not patentably distinguish the claimed invention over the prior art.
Regarding claim 4: Samanthapudi as modified teaches The system of claim 1, wherein the offering operating in the unified platform comprises at least one of a product and a service (Samanthapudi, [0024], where client devices 102-108 may request to search and/or configure one or more configurable products from the enterprise server 120, where the one or more configurable products may be any type of product, including tangible or intangible products, e.g., an intangible product such as a subscription or service).
Regarding claim 5: Samanthapudi as modified teaches The system of claim 1, wherein the modification of the hierarchical product parameter comprises at least one of an update in the dependency of the hierarchical product parameter, an addition of a link in the hierarchical product parameter, a deletion of a link associated with the hierarchical product parameter, and a modification in attributes of the hierarchical product parameter (Samanthapudi, [0138], where changes include a component change, e.g., the feature, part or coverage described in another product plan (i.e., “hierarchical product parameter”); see also, e.g., Samanthapudi, [0036], where the product model includes hierarchies between various parts and features, and references between various product models to a configuration server. See also Samanthapudi, [0143], where a user verifies that appropriate coverages are part of the model plan and may remove or delete coverages that should not have been included, and may also change or verify the factor attribute values associated with the various coverages).
Regarding claim 6: Samanthapudi as modified teaches The system of claim 1, wherein the processor is to monitor the hierarchical product parameter in the hierarchy of operational factors to track the modifications on the hierarchical product parameter during operations at both the developer-end ecosystem and the user-end ecosystem (Samanthapudi, [0106], where changes made to the product plan are recorded in a task diary associated with the initiative/product plan, where a task diary may be any component capable of logging and/or tracking a user’s interactions with a document, where in this regard, the task diary may automatically track the changes and/or modifications made to the initiative, the user that makes those changes/modifications, and timestamp the changes/modifications.
See Samanthapudi, [0029-0030], where plans may be shared/sold by multiple tenants which can be published on the cloud server/platform to other users/tenants in the cloud computing environment. See Samanthapudi, [0031], where each tenant can subscribe to one or more models from the core model, where based on the subscription plan, a tenant may extend and make their changes, which may be republished to other tenants for reference and subscriptions. Tenant changes and updates can be managed as plans which can drive overrides and references. This approach enables a flexible method to share proprietary and industry models, as well as allows models to be shared across different tenants or companies.
See claim 2 above with respect to the “developer-end ecosystem” and “user-end ecosystem”).
Regarding claim 7: Samanthapudi as modified teaches The system of claim 1, wherein to update the pin table based on the user validation, the processor is to:
transmit the identified inconsistent values of the hierarchical product parameter to a feedback loop, wherein the feedback loop is configured to prompt the user to review the user preferred values of the recorded modified hierarchical product parameter (Walker, [0029-0031], where each time a parameter is set or changed (by a user), the protocol parameter validator 212 can validate the parameters against the policy. When a default and/or user defined parameter differs from a policy-based parameter, the determiner 124 can variously respond, e.g., the protocol parameter validator 212 suggests or recommends replacement parameters that satisfy the policy. The user that has the accept/reject authority can receive a notification, where the notification may indicate that the personnel is needed to accept/reject a recommended scan parameter value, where the notification may include other relevant information such as the particular parameter, the initial parameter value, the recommended parameter value, and/or other information. See also Samanthapudi in claim 1 above with respect to the “hierarchical product” parameter). 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 Samanthapudi and Walker with the motivation of helping the user recall what the original inputted value was and thus better understand from and learn from the suggested/recommended values, e.g., potentially increasing efficiency and accuracy of the user’s future inputs.
Regarding claim 8: Samanthapudi as modified teaches The system of claim 1, wherein the user validation includes at least one of approval and disapproval of the user preferred values of the hierarchical product parameter in the hierarchy of operational factors (Walker, [0030-0031] and [0046], where an operator may accept a (change) suggestion, resulting in a replacement parameter being used to (manually) update the initial parameter).
Regarding claim 9: Samanthapudi as modified teaches The system of claim 8, wherein on approval of the user preferred values of the hierarchical product parameter, the processor is to:
retain the modified hierarchical product parameter with the user preferred values of the hierarchical product parameter in the pin table (Walker, [0030-0031], where an operator may reject a (change) suggestion/recommendation (implying that the original value is retained; see also, e.g., Walker, [010], where an operator may further minimize a dose (i.e., change the initial parameter) but is not required to do so (i.e., may retain the initial parameter)). See Samanthapudi, [0106], where the task diary (i.e., “pin table”) only tracks the changes and/or modifications made to the initiative. See also Samanthapudi in claim 1 above with regards to the “modified hierarchical product” parameter “in the pin table”).
Regarding claim 10: Samanthapudi as modified teaches The system of claim 8, wherein on disapproval of the user preferred values of the hierarchical product parameter, the processor is to:
receive input from the user, wherein the input includes a selected recommended value of the hierarchical product parameter derived from the plurality of connected data sources associated with the hierarchical product parameter; override the user preferred values of the hierarchical product parameter with the selected recommended value of the hierarchical product parameter (Walker, [0030-0033] and [0046], where an operator, via a notification, may accept a (change) suggestion using a web-based application, resulting in a replacement parameter being used to (manually) update the parameter. See Walker, [0095-0097] and [0104] in claim 1 above with regards to the “plurality of connected data sources”. See Samanthapudi in claim 1 above with regards to the “hierarchical product” parameter); and
update the pin table (Samanthapudi, [0106], where the task diary (i.e., “pin table”) only tracks the changes and/or modifications made to the initiative (implying that in combination with the user making changes via accepting a suggestion as disclosed in Walker, this would result in Samanthapudi’s task diary tracking that change/modification, i.e., “updat[ing] the pin table” as claimed).
Regarding claim 11: Claim 11 recites substantially the same claim limitations as claim 1, 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 5, and is rejected for the same reasons.
Regarding claim 14: Claim 14 recites substantially the same claim limitations as claim 6, and is rejected for the same reasons.
Regarding claim 15: Claim 15 recites substantially the same claim limitations as claim 7, and is rejected for the same reasons.
Regarding claim 16: Claim 16 recites substantially the same claim limitations as claim 8, and is rejected for the same reasons.
Regarding claim 17: Claim 17 recites substantially the same claim limitations as claim 9, and is rejected for the same reasons.
Regarding claim 18: Claim 18 recites substantially the same claim limitations as claim 10, and is rejected for the same reasons.
Regarding claim 19: Claim 19 recites substantially the same claim limitations as claim 1, and is rejected for the same reasons.
Note that Samanthapudi teaches A non-transitory computer-readable medium comprising instructions to record modifications performed on a hierarchical product parameter in a hierarchy of operational factors for an offering operating in a unified platform, the instructions being executable by a processing resource to [implement the claimed steps] (Samanthapudi, [0005], where the system for implementing the disclosed steps may include a non-transitory, computer-readable medium and one or more processors in communication with the non-transitory computer-readable medium. The non-transitory computer-readable medium may store computer-executable instructions that, when executed by the one or more processors, generate a configurable product based on multiple plans which are interdependent, e.g., in a hierarchical tree (see, e.g., Samanthapudi, [0008] and [0151-0152])).
Regarding claim 20: Claim 20 recites substantially the same claim limitations as claims 7-8, and is rejected for the same reasons as claims 7-8.
Regarding claim 21: Claim 21 recites substantially the same claim limitations as claim 9, and is rejected for the same reasons.
Regarding claim 22: Claim 22 recites substantially the same claim limitations as claim 10, 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, NEVEEN ABEL-JALIL can be reached at (571)270-0474. 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 2152
2 January 2026
1 Bascom Global Internet Services, Inc. v. AT&T Mobility LLC, 827 F.3d 1341 (Fed. Cir. 2016) at p. 12.