DETAILED ACTION
This final Office action is responsive to Applicant’s amendment filed July 22, 2025. Claims 1-2, 5-6, 8-9, 12-13, 15-16, and 18-19 have been amended. Claims 3-4, 10-11, and 17 are cancelled. Claims 1-2, 5-9, 12-16, and 18-20 are presented for examination.
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 .
Response to Arguments
Applicant's arguments filed July 22, 2025 have been fully considered but they are not persuasive.
Regarding the rejection under 35 U.S.C. § 101, Applicant states, “Claim 1 is directed to dynamically controlling multi-nested OKR alignment, which cannot practically be performed in the human mind. In particular, ‘calling an application programming interface in the background when the enterprise user provides the second user input’ and ‘loading the updated alignment permission policy in near real-time via the application programming interface’ require action by a processor that cannot be practically performed in the human mind.” (Page 10 of Applicant’s response) While the Examiner agrees that the use of APIs itself cannot be performed in the human mind, the Examiners points out that the use of APIs, including running them in the background, is a generic use of software. Aside from the general application of general-purpose processing elements, a human user could indeed perform most of the operations of the claims. Aside from the general application of the additional elements, a human user can present information for display, receive and gather information, determine who can access information based on a permission policy, etc.
Applicant submits that the use of APIs in the background improves efficiency and effectiveness of the OKR alignment, which improves the functioning of the computer technology and presents a solution rooted in technology (pages 11-12 of Applicant’s response). Many of the recited details regarding OKR alignment present aspects of the identified abstract ideas, as explained in the rejection. Furthermore, the running of APIs in the background is merely a generic use of software. The processing components presented in the claims simply utilize the capabilities of a general-purpose computer and are, thus, merely tools to implement the abstract idea(s). As seen in MPEP § 2106.05(a)(I) and § 2106.05(f)(2), the court found that accelerating a process when the increased speed solely comes from the capabilities of a general-purpose computer is not sufficient to show an improvement in computer-functionality and it amounts to a mere invocation of computers or machinery as a tool to perform an existing process (see FairWarning IP, LLC v. Iatric Sys., 839 F.3d 1089, 1095, 120 USPQ2d 1293, 1296 (Fed. Cir. 2016)).
Applicant asserts that “[t]he present invention provides a more efficient and faster way of determining who is on the list by calling an API and loading the alignment permission policy in near real-time via the API. Specification at [0032]. Therefore, the claimed invention is significantly more than well-understood, routine, and conventional solutions.” (Page 13 of Applicant’s response) Applicant has not presented persuasive arguments that, other than generally applying the APIs to implement the abstract ideas, the APIs operate in a manner that is not well-understood, routine, and conventional.
Regarding the art rejection, Applicant argues that Duggan and Olsen do not address the current claim amendments (pages 14-15 of Applicant’s response). The art rejection has been revised (incorporating the Lai reference) in order to help address the amended claim language.
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-2, 5-9, 12-16, and 18-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter.
Claims 1-2, 5-9, 12-16, and 18-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. The claimed invention is directed to “the dynamic control of multi-nested OKR [Objectives and Key Results] alignment” (Spec: ¶ 1) without significantly more.
Step
Analysis
1: Statutory Category?
Yes – The claims fall within at least one of the four categories of patent eligible subject matter. Process (claims 1-2, 5-7), Apparatus (claims 8-9, 12-14), Article of Manufacture (claims 15-16, 18-20)
** It is noted that Applicant’s Specification states the following: “…for purposes of this disclosure, the term ‘computer-readable storage medium (or media)’ refers specifically to non-transitory forms of computer-readable storage media and expressly excludes carrier waves and/or propagated signals.” (Spec: ¶ 73)
Independent claims:
Step
Analysis
2A – Prong 1: Judicial Exception Recited?
Yes – Aside from the additional elements identified in Step 2A – Prong 2 below, the claims recite:
[Claim 1] A method for dynamically controlling multi-nested OKR alignment, wherein the method comprises:
producing a display, wherein the display corresponds to a goal-setting feature;
receiving an updated alignment permission policy for a multi-nested Objective and Key Results (OKR) of an enterprise, wherein the updated alignment permission policy defines an updated list of enterprise users who are allowed to align child OKR objects to a parent objective of the multi-nested OKR, and wherein the updated alignment permission policy replaces an existing alignment permission policy in near real-time; and
applying the updated alignment permission policy to the multi-nested OKR;
performing automatic progress rollups in accordance with the updated alignment permission policy by only enabling child OKR objects defined by the enterprise users who are on the updated list to roll up to the parent objective;
receiving a second user input comprising an attempt to align to the parent objective;
determining whether an enterprise user providing the second user input is on the updated list by:
accessing the updated alignment permission policy in near real-time; and
analyzing the updated alignment permission policy in near real-time to determine whether the enterprise user is on the updated list; and
updating the OKR to provide the alignment only if the enterprise user is on the updated list.
[Claim 8] receive a user input comprising an updated alignment permission policy for a multi-nested Objective and Key Results (OKR) of an enterprise, wherein the updated alignment permission policy defines an updated list of enterprise users who are allowed to align child OKR objects to a parent objective of the multi-nested OKR, and wherein the updated alignment permission policy replaces an existing alignment permission policy in near real-time; and
apply the alignment permission policy to the multi-nested OKR;
perform automatic progress rollups in accordance with the updated alignment permission policy by only enabling child OKR objects defined by the enterprise users who are on the updated list to roll up to the parent objective;
receive a second user input comprising an attempt to align to the parent objective;
determine whether an enterprise user providing the second user input is on the updated list by:
accessing the updated alignment permission policy in near real-time; and
analyzing the updated alignment permission policy in near real-time to determine whether the enterprise user is on the updated list; and
update the OKR to provide the alignment only if the enterprise user is on the updated list.
[Claim 15] responsive to a first user input comprising a specification of an updated alignment permission policy for a multi-nested Objective and Key Results (OKR) of an enterprise, apply the updated alignment permission policy to the multi-nested OKR, wherein the updated alignment permission policy defines an updated list of enterprise users who are allowed to align child OKR objects to a parent objective of the multi-nested OKR, and wherein the updated alignment permission policy replaces an existing alignment permission policy in near real-time;
perform automatic progress rollups in accordance with the updated alignment permission policy by only enabling child OKR objects defined by the enterprise users who are on the updated list to roll up to the parent objective;
responsive to a second user input comprising an attempt to align to the parent objective, determine whether an enterprise user providing the second user input is on the list of enterprise users who are allowed to align child OKR objects to the parent objective by:
accessing the updated alignment permission policy in near real-time; and
analyzing the updated alignment permission policy in near real-time to determine whether the enterprise user is on the updated list; and
update the OKR to provide the alignment only if the enterprise user is on the list.
Aside from the additional elements, the aforementioned claim details exemplify the abstract idea(s) of a mental process (since the details include concepts performed in the human mind, including an observation, evaluation, judgment, and/or opinion). As explained in MPEP § 2106.04(a)(1)(III), “[t]he courts consider a mental process (thinking) that ‘can be performed in the human mind, or by a human using a pen and paper’ to be an abstract idea. CyberSource Corp. v. Retail Decisions, Inc., 654 F.3d 1366, 1372, 99 USPQ2d 1690, 1695 (Fed. Cir. 2011).” The limitations reproduced above, as drafted, are a process that, under its broadest reasonable interpretation, covers performance of the limitations in the mind but for the recitation of generic computer components. That is, other than reciting the additional elements identified in Step 2A – Prong 2 below, nothing in the claim elements precludes the steps from practically being performed in the mind and/or by a human using a pen and paper. For example, but for the recitations of generic computer and other processing components (identified in Step 2A – Prong 2 below), the respectively recited steps/functions of the claims, as drafted and set forth above, are a process that, under its broadest reasonable interpretation, covers performance of the limitations in the mind and/or with the use of pen and paper. A human user can present information for display, receive and gather information, determine who can access information based on a permission policy, etc. If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the mind (and/or with pen and paper) but for the recitation of generic computer components, then it falls within the “Mental Processes” grouping of abstract ideas. Accordingly, the claims recite an abstract idea.
Aside from the additional elements, the aforementioned claim details exemplify a method of organizing human activity (since the details include examples of commercial or legal interactions, including advertising, marketing or sales activities or behaviors, and/or business relations and managing personal behavior or relationships or interactions between people, including social activities, teaching, and following rules or instructions). More specifically, the evaluated process is related to “the dynamic control of multi-nested OKR [Objectives and Key Results] alignment” (Spec: ¶ 1), which (under its broadest reasonable interpretation) is an example of business relations and managing interactions between people (i.e., organizing human activity); therefore, aside from the recitations of generic computer and other processing components (identified in Step 2A – Prong 2 below), the limitations identified in the more detailed claim listing above encompass the abstract idea of organizing human activity.
2A – Prong 2: Integrated into a Practical Application?
No – The judicial exception(s) is/are not integrated into a practical application.
Claim 1 recites that the method is implemented via an application service provider server comprising a processor. Claim 1 further recites executing, via a network, an enterprise application on a remote computing system; causing surfacing of a user interface on a display of the remote computing system during the execution of the enterprise application; receiving, via the surfaced user interface, a user input; executing, via the network, the enterprise application on a second remote computing system; causing surfacing of the user interface on a display of the second remote computing system during the execution of the enterprise application; receiving, via the user interface, a second user input comprising an attempt to align to the parent objective; determining whether an enterprise user providing the second user input is on the updated list by: calling an application programming interface in background when the enterprise user provides the second user input; loading the updated alignment permission policy in near real-time via the application programming interface.
Claim 8 recites an application service provider server, comprising: a processor; an enterprise application that is utilized by an enterprise; a communication connection for connecting a remote computing system to the application service provider server via a network; and a computer-readable storage medium operatively coupled to the processor, the computer-readable storage medium comprising computer-executable instructions that, when executed by the processor, cause the processor to: cause execution of the enterprise application on the remote computing system; cause surfacing of a user interface on a display of the remote computing system during the execution of the enterprise application, wherein the user interface corresponds to a goal-setting feature of the enterprise application; receive, via the surfaced user interface, a user input. Claim 8 further recites: execute, via the network, the enterprise application on a second remote computing system; cause surfacing of the user interface on a display of the second remote computing system during the execution of the enterprise application; receive, via the user interface, a second user input comprising an attempt to align to the parent objective; determine whether an enterprise user providing the second user input is on the updated list by: calling an application programming interface in background when the enterprise user provides the second user input; loading the updated alignment permission policy in near real-time via the application programming interface.
Claim 15 recites a computer-readable storage medium comprising computer- executable instructions that, when executed by a processor, cause the processor to: cause execution of an enterprise application; cause surfacing of a user interface on a display during the execution of the enterprise application, wherein the user interface corresponds to a goal-setting feature of the enterprise application; determine whether an enterprise user providing the second user input is on the list of enterprise users who are allowed to align child OKR objects to the parent objective by: calling an application programming interface in background when the enterprise user provides the second user input; loading the updated alignment permission policy in near real-time via the application programming interface.
Calling an application programming interface (API) is an example of using software to implement the corresponding functions of the API.
The claims as a whole merely describe how to generally “apply” the abstract idea(s) in a computer environment. The claimed processing elements are recited at a high level of generality and are merely invoked as a tool to perform the abstract idea(s). Simply implementing the abstract idea(s) on a general-purpose processor is not a practical application of the abstract idea(s); Applicant’s specification discloses that the invention may be implemented using general-purpose processing elements and other generic components (Spec: ¶¶ 46-73).
The use of a processor/processing elements (e.g., as recited in all of the claims) facilitates generic processor operations. The use of a memory or machine-readable media with executable instructions facilitates generic processor operations.
The additional elements are recited at a high-level of generality (i.e., as generic processing elements performing generic computer functions) such that the incorporation of the additional processing elements amounts to no more than mere instructions to apply the judicial exception(s) using generic computer components. There is no indication in the Specification that the steps/functions of the claims require any inventive programming or necessitate any specialized or other inventive computer components (i.e., the steps/functions of the claims may be implemented using capabilities of general-purpose computer components). Accordingly, the additional elements do not integrate the abstract ideas into a practical application because they do not impose any meaningful limits on practicing the abstract idea. The claims are directed to an abstract idea(s).
The processing components presented in the claims simply utilize the capabilities of a general-purpose computer and are, thus, merely tools to implement the abstract idea(s). As seen in MPEP § 2106.05(a)(I) and § 2106.05(f)(2), the court found that accelerating a process when the increased speed solely comes from the capabilities of a general-purpose computer is not sufficient to show an improvement in computer-functionality and it amounts to a mere invocation of computers or machinery as a tool to perform an existing process (see FairWarning IP, LLC v. Iatric Sys., 839 F.3d 1089, 1095, 120 USPQ2d 1293, 1296 (Fed. Cir. 2016)).
There is no transformation or reduction of a particular article to a different state or thing recited in the claims.
Additionally, even when considering the operations of the additional elements as an ordered combination, the ordered combination does not amount to significantly more than what is present in the claims when each operation is considered separately.
2B: Claim(s) Provide(s) an Inventive Concept?
No – The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception(s). As discussed above with respect to integration of the abstract idea(s) into a practical application, the use of the additional elements to perform the steps identified in Step 2A – Prong 1 above amounts to no more than mere instructions to apply the exceptions using a generic computer component(s). Mere instructions to apply an exception using a generic computer component(s) cannot provide an inventive concept. The claims are not patent eligible.
Dependent claims:
Step
Analysis
2A – Prong 1: Judicial Exception Recited?
Yes – Aside from the additional elements identified in Step 2A – Prong 2 below, the claims recite:
[Claims 2, 9, 16] wherein performing the automatic progress rollups in accordance with the updated alignment permission policy comprises dynamically calculating the automatic progress rollups when the updated alignment permission policy is updated in near real-time.
[Claims 5, 12, 18] applying the updated alignment permission policy to any secondary objectives that are nested underneath the parent objective.
[Claims 6, 13, 19] wherein the updated list of enterprise users comprises at least one of an individual enterprise user or a team of enterprise users.
[Claims 7, 14, 20] wherein the child OKR objects comprise at least one of a key result, a project, or a secondary objective.
The dependent claims further present details of the abstract ideas identified above in regard to the independent claims.
Aside from the additional elements, the aforementioned claim details exemplify the abstract idea(s) of a mental process (since the details include concepts performed in the human mind, including an observation, evaluation, judgment, and/or opinion). As explained in MPEP § 2106.04(a)(1)(III), “[t]he courts consider a mental process (thinking) that ‘can be performed in the human mind, or by a human using a pen and paper’ to be an abstract idea. CyberSource Corp. v. Retail Decisions, Inc., 654 F.3d 1366, 1372, 99 USPQ2d 1690, 1695 (Fed. Cir. 2011).” The limitations reproduced above, as drafted, are a process that, under its broadest reasonable interpretation, covers performance of the limitations in the mind but for the recitation of generic computer components. That is, other than reciting the additional elements identified in Step 2A – Prong 2 below, nothing in the claim elements precludes the steps from practically being performed in the mind and/or by a human using a pen and paper. For example, but for the recitations of generic computer and other processing components (identified in Step 2A – Prong 2 below), the respectively recited steps/functions of the claims, as drafted and set forth above, are a process that, under its broadest reasonable interpretation, covers performance of the limitations in the mind and/or with the use of pen and paper. A human user can present information for display, receive and gather information, determine who can access information based on a permission policy, etc. If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the mind (and/or with pen and paper) but for the recitation of generic computer components, then it falls within the “Mental Processes” grouping of abstract ideas. Accordingly, the claims recite an abstract idea.
Aside from the additional elements, the aforementioned claim details exemplify a method of organizing human activity (since the details include examples of commercial or legal interactions, including advertising, marketing or sales activities or behaviors, and/or business relations and managing personal behavior or relationships or interactions between people, including social activities, teaching, and following rules or instructions). More specifically, the evaluated process is related to “the dynamic control of multi-nested OKR [Objectives and Key Results] alignment” (Spec: ¶ 1), which (under its broadest reasonable interpretation) is an example of business relations and managing interactions between people (i.e., organizing human activity); therefore, aside from the recitations of generic computer and other processing components (identified in Step 2A – Prong 2 below), the limitations identified in the more detailed claim listing above encompass the abstract idea of organizing human activity.
2A – Prong 2: Integrated into a Practical Application?
No – The judicial exception(s) is/are not integrated into a practical application.
The dependent claims include the additional elements of the independent claims.
Claim 1 and its dependent claims recite that the method is implemented via an application service provider server comprising a processor. Claim 1 further recites executing, via a network, an enterprise application on a remote computing system; causing surfacing of a user interface on a display of the remote computing system during the execution of the enterprise application; receiving, via the surfaced user interface, a user input; executing, via the network, the enterprise application on a second remote computing system; causing surfacing of the user interface on a display of the second remote computing system during the execution of the enterprise application; receiving, via the user interface, a second user input comprising an attempt to align to the parent objective; determining whether an enterprise user providing the second user input is on the updated list by: calling an application programming interface in background when the enterprise user provides the second user input; loading the updated alignment permission policy in near real-time via the application programming interface.
Claim 8 and its dependent claims recite an application service provider server, comprising: a processor; an enterprise application that is utilized by an enterprise; a communication connection for connecting a remote computing system to the application service provider server via a network; and a computer-readable storage medium operatively coupled to the processor, the computer-readable storage medium comprising computer-executable instructions that, when executed by the processor, cause the processor to: cause execution of the enterprise application on the remote computing system; cause surfacing of a user interface on a display of the remote computing system during the execution of the enterprise application, wherein the user interface corresponds to a goal-setting feature of the enterprise application; receive, via the surfaced user interface, a user input. Claim 8 further recites: execute, via the network, the enterprise application on a second remote computing system; cause surfacing of the user interface on a display of the second remote computing system during the execution of the enterprise application; receive, via the user interface, a second user input comprising an attempt to align to the parent objective; determine whether an enterprise user providing the second user input is on the updated list by: calling an application programming interface in background when the enterprise user provides the second user input; loading the updated alignment permission policy in near real-time via the application programming interface.
Claim 15 and its dependent claims recite a computer-readable storage medium comprising computer- executable instructions that, when executed by a processor, cause the processor to: cause execution of an enterprise application; cause surfacing of a user interface on a display during the execution of the enterprise application, wherein the user interface corresponds to a goal-setting feature of the enterprise application; determine whether an enterprise user providing the second user input is on the list of enterprise users who are allowed to align child OKR objects to the parent objective by: calling an application programming interface in background when the enterprise user provides the second user input; loading the updated alignment permission policy in near real-time via the application programming interface.
Calling an application programming interface (API) is an example of using software to implement the corresponding functions of the API.
The claims as a whole merely describe how to generally “apply” the abstract idea(s) in a computer environment. The claimed processing elements are recited at a high level of generality and are merely invoked as a tool to perform the abstract idea(s). Simply implementing the abstract idea(s) on a general-purpose processor is not a practical application of the abstract idea(s); Applicant’s specification discloses that the invention may be implemented using general-purpose processing elements and other generic components (Spec: ¶¶ 46-73).
The use of a processor/processing elements (e.g., as recited in all of the claims) facilitates generic processor operations. The use of a memory or machine-readable media with executable instructions facilitates generic processor operations.
The additional elements are recited at a high-level of generality (i.e., as generic processing elements performing generic computer functions) such that the incorporation of the additional processing elements amounts to no more than mere instructions to apply the judicial exception(s) using generic computer components. There is no indication in the Specification that the steps/functions of the claims require any inventive programming or necessitate any specialized or other inventive computer components (i.e., the steps/functions of the claims may be implemented using capabilities of general-purpose computer components). Accordingly, the additional elements do not integrate the abstract ideas into a practical application because they do not impose any meaningful limits on practicing the abstract idea. The claims are directed to an abstract idea(s).
The processing components presented in the claims simply utilize the capabilities of a general-purpose computer and are, thus, merely tools to implement the abstract idea(s). As seen in MPEP § 2106.05(a)(I) and § 2106.05(f)(2), the court found that accelerating a process when the increased speed solely comes from the capabilities of a general-purpose computer is not sufficient to show an improvement in computer-functionality and it amounts to a mere invocation of computers or machinery as a tool to perform an existing process (see FairWarning IP, LLC v. Iatric Sys., 839 F.3d 1089, 1095, 120 USPQ2d 1293, 1296 (Fed. Cir. 2016)).
There is no transformation or reduction of a particular article to a different state or thing recited in the claims.
Additionally, even when considering the operations of the additional elements as an ordered combination, the ordered combination does not amount to significantly more than what is present in the claims when each operation is considered separately.
2B: Claim(s) Provide(s) an Inventive Concept?
No – The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception(s). As discussed above with respect to integration of the abstract idea(s) into a practical application, the use of the additional elements to perform the steps identified in Step 2A – Prong 1 above amounts to no more than mere instructions to apply the exceptions using a generic computer component(s). Mere instructions to apply an exception using a generic computer component(s) cannot provide an inventive concept. The claims are not patent eligible.
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-2, 5-9, 12-16, and 18-20 are rejected under 35 U.S.C. 103 as being unpatentable over Duggan et al. (US 10,896,390) in view of Lai et al. (US 2020/0344233).
[Claim 1] Duggan discloses a method for dynamically controlling multi-nested OKR alignment, wherein the method is implemented via an application service provider server comprising a processor (col. 2: 39-45 – “The cascading goal system can be embodied in software, such as desktop, web, or mobile application or tool, software as service, or embedded or integrated as a component of another software application or service. The system can be embodied on multiple platforms at the same time, such as a Web version and smartphone version, and these clients are connected via the Internet or cloud.”; col. 10: 4-16 – processor; col. 15: 54 – col. 16: 16: 41 – Goals may be arranged in a hierarchy, including parent and contributing goals.), and wherein the method comprises:
executing, via a network, an enterprise application on a remote computing system (col. 2: 39-45 – “The cascading goal system can be embodied in software, such as desktop, web, or mobile application or tool, software as service, or embedded or integrated as a component of another software application or service. The system can be embodied on multiple platforms at the same time, such as a Web version and smartphone version, and these clients are connected via the Internet or cloud.”; col. 8: 44-51 – “Client systems 113, 116, and 119 enable users to access and query information stored by server system 122. In a specific embodiment, the client systems can run as a standalone application such as a desktop application or mobile smartphone or tablet application. In another embodiment, a “web browser” application executing on a client system enables users to select, access, retrieve, or query information stored by server system 122.”);
causing surfacing of a user interface on a display of the remote computing system during the execution of the enterprise application, wherein the user interface corresponds to a goal-setting feature of the enterprise application (col. 3: 43 – col. 4: 6 – “In an implementation, the system includes: an organization database including a hierarchical organization structure of a first organization, the hierarchical organization structure including: a plurality of users of the system; and a plurality of relationships of each user of the plurality of users to other users of the plurality of users; a goals database including a plurality of goals stored in the system, where each goal of the plurality of goals includes a goal owner and a goal assignee; a user interface component, accessible over an internet connection, where the user interface component: receives a first computer transmission over the Internet from a first user of the system to create a first goal and to assign the first goal to a second user, where a first owner of the first goal includes the first user and a first assignee of the first goal includes the second user; and receives a first computer transmission over the Internet from the second user of the system to create a second goal and to assign the second goal to the first user, where a second owner of the first goal includes the second user and a second assignee of the second goal includes the first user; and a goals manager component, coupled to the goals database and the organization database, where the goals manager component stores, adds, and updates the goals database and determines based on the information from the organization database that the first user is higher in the hierarchical organization structure of the first organization than the second user; allows the first and second requests to be stored in the system, while disregarding that the first user is higher in the hierarchical organization structure of the first organization than the second user; and instructing the goal database to store the first and second goals associated with the first organization.”);
receiving, via the surfaced user interface, a user input comprising an updated alignment permission policy for a multi-nested Objective and Key Results (OKR) of an enterprise, wherein the alignment permission policy defines an updated list of enterprise users who are allowed to align child OKR objects to a parent objective of the multi-nested OKR, and wherein the updated alignment permission policy replaces an existing alignment permission policy in near real-time (col. 3: 18-24 – “The system includes allowing the first user to modify the assignment of the first goal to a third user. The system includes allowing the second user to modify the assignment of the first goal to a third user. The system includes for a third user of the system associated with a second organization, disallowing access to first and second goals.”; col. 3: 43 – col. 4: 6 -- “In an implementation, the system includes: an organization database including a hierarchical organization structure of a first organization, the hierarchical organization structure including: a plurality of users of the system; and a plurality of relationships of each user of the plurality of users to other users of the plurality of users; a goals database including a plurality of goals stored in the system, where each goal of the plurality of goals includes a goal owner and a goal assignee; a user interface component, accessible over an internet connection, where the user interface component: receives a first computer transmission over the Internet from a first user of the system to create a first goal and to assign the first goal to a second user, where a first owner of the first goal includes the first user and a first assignee of the first goal includes the second user; and receives a first computer transmission over the Internet from the second user of the system to create a second goal and to assign the second goal to the first user, where a second owner of the first goal includes the second user and a second assignee of the second goal includes the first user; and a goals manager component, coupled to the goals database and the organization database, where the goals manager component stores, adds, and updates the goals database and determines based on the information from the organization database that the first user is higher in the hierarchical organization structure of the first organization than the second user; allows the first and second requests to be stored in the system, while disregarding that the first user is higher in the hierarchical organization structure of the first organization than the second user; and instructing the goal database to store the first and second goals associated with the first organization.”; col. 12: 7-14 – “In an implementation, the organization information is provided to the system by a user. Generally, a system administrator, a human resources team, manager, or other staffing related person is responsible for maintaining such information for an organization. These persons or others under their direction can enter this information into the system.” As discussed below, the organization information (which may be entered by human users) is used to establish permission policy related to alignment.; col. 14: 5-16 – “FIG. 6 shows a tree of cascading goals, where the goals are assigned according to atop-down approach only. In this tree, goals (represented by circles) flow from the top of the tree to the bottom (represented by arrows). This means that higher-level employees (or superiors) can add goals for lower-level employees, but not vice versa. For example, a goal 603 is subdivided into goals 605, 608, and 610. Goal 603 can be a goal created by someone higher up in an organization (e.g., CEO created goal) while goal 605 is created by someone in a mid-level position in the organization (e.g., manager created goal). The cascading goals tree is stored in the goals database.” In other words, one’s position in the organizational hierarchy determines alignment permissions.; Permissions include who can view which goals, as seen in col. 17: 45-56 – “FIGS. 9A-9F show user screens for different users in an organization. These users occupy different levels of the organization's organizational chart. Each screen represents what goals the system would present to each user for the organization's goal tree. For example, for a CEO of the organization, they can view goals that they have been assigned to. Here, the CEO has been assigned goals 1, 6, and 8. These goals can be created in the system by the CEO (goal 1) or others (goals 6 and 8). Employee 1 (or E1) created goal 8 and assigned the goal to CEO. This shows a bottom-up goal assignment, since employee 1 is lower in an organization structure than the CEO. The system also supports top down goal assignments. For example, for goal 2 CEO has assigned a goal to vice president 1 (VP1).”; col. 18: 12-40 – “Goal 16 is an example of a private goal. A user (e.g., E1) can create a private goal. In an implementation, the private goal is visible only by the user (e.g., E1) who created it. In another implementation, the private goal is visible by the user (e.g., E1) who created it and the immediate manager of the user (e.g., M1 who is the manager of E1). In another implementation, the private goal is visible by the user (e.g., E1) who created it and any users who are at a higher level in the organizational hierarchy. FIG. 10 shows a tree representing of the cascading goals represented in the user screens of FIGS. 9A-9F. In an implementation, the system restricts visibility of goals of an organization in tree format. For example, the system can provide views of goals in the system such as those in FIGS. 9A-9F, so that each user can access information relevant to their goals. This simplifies how users experience the system, so that only what is needed is visible to users. Users are generally allowed access to all the goals of an organization however, so if a user desires to do so, they can understand how their goals relate to parent goals in the system.”; col. 14: 49 – col. 15: 5 – “An example relationship is parent goal 708 that includes contributor goal 722 that was created by the owner of the parent goal 708. However, another person different than the owner created contributor goal 718. Although the person did not create the parent goal 708, they are allowed to link their contributor goal to the parent goal 708. This can happen in an organization when a user views another person's owned goal and wants to contribute to its completion. For example, sometimes a person has worked previously on a similar project and recognizes certain requirements that the owner of the goal did not. To assist in the completion of the owner's goal, the user can add a contributor goal to the owner's goal. In another example, users with more than one level of separation in an organization's organization chart can assign goals to each other. For example, goal 716 is created by a manager. In the organization's organizational chart, the manager directly reports to a vice president that in turn directly reports to a CEO. However, the system allows the manager to create goal 716 and assign it to the CEO. Once assigned the goal, the CEO can choose whether to complete the goal themselves, divide the goal into further goals, or assign the goal to another person.”; Additionally, a user can select a group or set of users to whom a goal is made visible, as seen in col. 18: 57-64 – “In another implementation, the system supports private goals that are visible to a selection of persons in an organization. The visibility can be user selected (e.g., the user selects a group or set of users of the organization) or system selected (e.g., the system determines the visibility of the goal by organization, historical information, or other method). For example, goals that a financial department is responsible for would appear for an engineer.”; col. 2: 26-38 – “Further aspects of a multidirectional cascading goal system include: All goals in the system are open and visible in the organization by default. Depending on the particular implementation, the company or organization can decide to turn on some privacy settings if less transparency is desired. Goals can be private to specific people, specific groups, or any combination of the two. People can assign goals top-down, bottom-up (upwards), or even sideways (e.g., to anyone who is a user of the system). People can sign up to be contributors on other's goals (i.e., bottoms up). Moreover, adding a milestone to another goal creates a contributing goal for any specified recipient. For the cascading goals, all progress is properly calculated and rolled up.”); and
applying the updated alignment permission policy to the multi-nested OKR (col. 2: 26-38 – “Further aspects of a multidirectional cascading goal system include: All goals in the system are open and visible in the organization by default. Depending on the particular implementation, the company or organization can decide to turn on some privacy settings if less transparency is desired. Goals can be private to specific people, specific groups, or any combination of the two. People can assign goals top-down, bottom-up (upwards), or even sideways (e.g., to anyone who is a user of the system). People can sign up to be contributors on other's goals (i.e., bottoms up). Moreover, adding a milestone to another goal creates a contributing goal for any specified recipient. For the cascading goals, all progress is properly calculated and rolled up.”; col. 3: 43 – col. 4: 6 – Goals can be updated.; col. 14: 49 – col. 15: 5 – “An example relationship is parent goal 708 that includes contributor goal 722 that was created by the owner of the parent goal 708. However, another person different than the owner created contributor goal 718. Although the person did not create the parent goal 708, they are allowed to link their contributor goal to the parent goal 708. This can happen in an organization when a user views another person's owned goal and wants to contribute to its completion. For example, sometimes a person has worked previously on a similar project and recognizes certain requirements that the owner of the goal did not. To assist in the completion of the owner's goal, the user can add a contributor goal to the owner's goal. In another example, users with more than one level of separation in an organization's organization chart can assign goals to each other. For example, goal 716 is created by a manager. In the organization's organizational chart, the manager directly reports to a vice president that in turn directly reports to a CEO. However, the system allows the manager to create goal 716 and assign it to the CEO. Once assigned the goal, the CEO can choose whether to complete the goal themselves, divide the goal into further goals, or assign the goal to another person.”).
performing automatic progress rollups in accordance with the updated alignment permission policy by only enabling child OKR objects defined by the enterprise users who are on the updated list to roll up to the parent objective (col. 3: 18-24 – “The system includes allowing the first user to modify the assignment of the first goal to a third user. The system includes allowing the second user to modify the assignment of the first goal to a third user. The system includes for a third user of the system associated with a second organization, disallowing access to first and second goals.”; col. 2: 26-38 – “Further aspects of a multidirectional cascading goal system include: All goals in the system are open and visible in the organization by default. Depending on the particular implementation, the company or organization can decide to turn on some privacy settings if less transparency is desired. Goals can be private to specific people, specific groups, or any combination of the two. People can assign goals top-down, bottom-up (upwards), or even sideways (e.g., to anyone who is a user of the system). People can sign up to be contributors on other's goals (i.e., bottoms up). Moreover, adding a milestone to another goal creates a contributing goal for any specified recipient. For the cascading goals, all progress is properly calculated and rolled up.”; Permissions include who can view which goals, as seen in col. 17: 45-56 – “FIGS. 9A-9F show user screens for different users in an organization. These users occupy different levels of the organization's organizational chart. Each screen represents what goals the system would present to each user for the organization's goal tree. For example, for a CEO of the organization, they can view goals that they have been assigned to. Here, the CEO has been assigned goals 1, 6, and 8. These goals can be created in the system by the CEO (goal 1) or others (goals 6 and 8). Employee 1 (or E1) created goal 8 and assigned the goal to CEO. This shows a bottom-up goal assignment, since employee 1 is lower in an organization structure than the CEO. The system also supports top down goal assignments. For example, for goal 2 CEO has assigned a goal to vice president 1 (VP1).”; col. 18: 12-40 – “Goal 16 is an example of a private goal. A user (e.g., E1) can create a private goal. In an implementation, the private goal is visible only by the user (e.g., E1) who created it. In another implementation, the private goal is visible by the user (e.g., E1) who created it and the immediate manager of the user (e.g., M1 who is the manager of E1). In another implementation, the private goal is visible by the user (e.g., E1) who created it and any users who are at a higher level in the organizational hierarchy. FIG. 10 shows a tree representing of the cascading goals represented in the user screens of FIGS. 9A-9F. In an implementation, the system restricts visibility of goals of an organization in tree format. For example, the system can provide views of goals in the system such as those in FIGS. 9A-9F, so that each user can access information relevant to their goals. This simplifies how users experience the system, so that only what is needed is visible to users. Users are generally allowed access to all the goals of an organization however, so if a user desires to do so, they can understand how their goals relate to parent goals in the system.”; col. 16: 12-21 – multi-level goal hierarchy);
executing, via the network, the enterprise application on a second remote computing system (col. 2: 39-45 – “The cascading goal system can be embodied in software, such as desktop, web, or mobile application or tool, software as service, or embedded or integrated as a component of another software application or service. The system can be embodied on multiple platforms at the same time, such as a Web version and smartphone version, and these clients are connected via the Internet or cloud.” Multiple (i.e., at least a first and second) clients may be connected via the Internet or cloud.; col. 3: 15-42 – First, second, and third users may be assigned certain goals and disallowed access to other goals.);
causing surfacing of the user inter