DETAILED ACTION
Response to Amendment
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 .
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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-8, 16, and 18-24 are rejected under 35 U.S.C. 103 as being unpatentable over Hanada et al. (U.S. Patent Application Publication Number 2016/0004513) and Ostrye et al. (U.S. Patent Application Publication Number 2019/0163213).
Regarding Claim 1, Hanada discloses a system operation planning device (Figure 1, item 100) comprising:
at least one memory configured to store instructions (paragraph 0048); and
at least one processor (paragraph 0047) configured to execute the instructions to:
generate, based on abstract requirements (paragraph 0060; i.e., the “abstract requirements” may include requirements such as “avoid using expensive resources in order to cut the cost of physical resources”, and “avoid using a resource that is small in free capacity so as not to affect other business operation systems operating on the same physical server”) that are first information indicating requirements to be satisfied by a target system (Figure 1, item 210) as a system to be operated, specific requirements (Figure 7, items 1412-1414, paragraph 0073; i.e., specific requirements [e.g., limit values] for the various parameters are created/generated based on the abstract requirements) that are second information indicating requirements to be satisfied by the target system (i.e., the target system should not exceed those limits), the specific requirements including third information indicating values of each of a plurality of values of a variable factor (Figure 7; i.e., the ”variable factor” being the various parameters, e.g., DB connection count, maximum process count, and connection timeout; each of those parameters has an associated per-unit resource usage value) included in a variable factor range (paragraphs 0072-0073; i.e., the upper and lower limits being equivalent to the “variable factor range”), the third information including information indicating a variable factor range as a range of values allowed for a variable factor to take during operation of the target system (i.e., the upper and lower limits are the range of values that the target system is allow to take), each value of the variable factor being a value varying during the operation of the target system and having a correlation with an operation status of the target system (Figure 8, item 1422 and Figure 9, item 1433, paragraph 0083; i.e., the different parameters have the associated per-unit resource usage values [CPU, memory, and network band ranges] that will take on actual measurements during operation of the performance test [the “target system”]; they have a “correlation” with the operation status of the target system in that they are constantly being changed while the performance test is executing).
Hanada does not expressly disclose generate difference information between a pre-change system configuration, which is a current system configuration of the target system, and a post-change system configuration, which is a target system configuration of the target system, the post-change system configuration corresponding to the specific requirements;
generate, based on the difference information, state transition information indicating a transition from the pre-change system configuration to the post-change system configuration; and
calculate, based on the state transition information, a state transition procedure for transition from the pre-change system configuration to the post-change system configuration with a fewest number of state transitions.
In the same field of endeavor (e.g., target system configuration techniques), Ostrye teaches generate difference information between a pre-change system configuration, which is a current system configuration of the target system (Figure 6, items 632, paragraph 0105), and a post-change system configuration, which is a target system configuration of the target system, the post-change system configuration corresponding to the specific requirements (paragraphs 0106-0107; i.e., the current heating and cooling capacity being equivalent to the claimed “pre-change system configuration” and the target desired heating and cooling capacity being equivalent to the claimed “post-change system configuration”; the total changes needed for the various devices 632 to take on [e.g., by turning on or off] to achieve the desired heating and cooling capacity being equivalent to the claimed “difference information”);
generate, based on the difference information, state transition information indicating a transition from the pre-change system configuration to the post-change system configuration (paragraphs 0107 and 0109; i.e., different combination options containing different transitions [the claimed “state transition information”] of the various devices 632 can be determined and generated by the combination finder 623); and
calculate, based on the state transition information, a state transition procedure for transition from the pre-change system configuration to the post-change system configuration with a fewest number of state transitions (paragraphs 0107-0109; i.e., different state transition options can be calculated, including an option that has the lowest total transition count [“fewest number of state transitions”]; the combination selector 625 selects that particular post-change system configuration).
Accordingly, 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 Ostrye teachings of target system configuration techniques with the teachings of Hanada, for the purpose of increasing the lifetime and performance of the target system devices (i.e., by avoiding constant on/off switching of the devices) (see Ostrye, paragraph 0108).
Regarding Claims 2 and 18, Hanada discloses wherein in a case where generating the specific requirements, the specific requirements are generated including a requirement that the target system includes a configuration for performing an observation in order to obtain the value of the variable factor (paragraphs 0088-0091; i.e., the parameter sets are observed in determining whether any more need to be generated).
Regarding Claims 3 and 19, Hanada discloses wherein the at least one processor is configured to execute the instructions to generate configuration information indicating a plurality of system configurations of the target system, each system configuration satisfying a respective one of the specific requirements (paragraph 0077; i.e., each chosen parameter falls within the upper and lower limit range, and thus satisfies each of the specific requirements).
Regarding Claims 4 and 20, Hanada discloses wherein the at least one processor is configured to execute the instructions to generate a configuration change procedure which is information indicating a procedure for changing from one of the plurality of system configurations to another of the plurality of system configurations (Figure 11, item S117, paragraphs 0098-0099; i.e., the parameters are changed for each test; this is equivalent to the claimed “system configuration”).
Regarding Claims 5 and 21, Hanada discloses wherein the at least one processor is configured to execute the instructions to generate an operation plan that is information including information linking each of the specific requirements with the configuration change procedure that indicates a procedure for changing from one of the plurality of system configurations of the target system to another of the plurality of system configurations that satisfies a respective one of the specific requirements (paragraphs 0098-0099; i.e., each of the different parameter sets that are changed for each test run still fall within the upper and lower limits [paragraph 0072] and therefore satisfy the requirements).
Regarding Claims 6 and 22, Hanada discloses wherein the at least one processor is configured to execute the instructions to change the plurality of system configurations of the target system based on the configuration change procedure indicating a procedure for changing from one of the plurality of system configurations of the target system to another of the plurality of system configurations that satisfies the specific requirement corresponding to the value of the variable factor obtained using a configuration for performing observation to obtain the value of the variable factor (paragraphs 0088-0091; i.e., the parameter sets are observed in determining whether any more need to be generated; further, appropriate parameters are chosen [the “system configuration”] that fall within the upper and lower limits [paragraph 0072] and thus satisfy the requirements).
Regarding Claims 7 and 23, Hanada discloses wherein the at least one processor is configured to execute the instructions to: compare the value of the variable factor indicated by the specific requirements satisfied by the pre-change system configuration with the value of the variable factor indicated by the specific requirements corresponding to the value of the variable factor obtained using a configuration for performing observations to obtain the value of the variable factor; and determine whether or not the system configuration of the target system needs to be changed (Figure 10, item S103 and Figure 11, item S117, paragraphs 0090 and 0098-0099; i.e., after performing the test on one of the sets of parameters [the “current system configuration”], the system determines whether a new set of parameters need to be loaded [“determine whether or not the system configuration of the target system needs to be changed”]).
Regarding Claims 8 and 24, Hanada discloses wherein the at least one processor is configured to execute the instructions to, in a case where a deviation between the value of the variable factor indicated by the specific requirement satisfied by the pre-change system configuration and the value of the variable factor obtained using a configuration for performing observation to obtain the value of the variable factor is greater than a predetermined threshold, determine the value of the variable factor indicated by the specific requirement corresponding to the value of the variable factor obtained using a configuration for performing observation to obtain the value of the variable factor, and determine whether or not the system configuration of the target system needs to be changed (paragraphs 0100-0102; i.e., only parameter sets that fulfill the system requirements are used; if their values have deviated from the specific requirements [they are greater than a predetermined threshold], they are not used and another parameter set/system configuration is used instead).
Regarding Claim 16, Hanada discloses a system operation planning method executed by a computer, the method comprising:
based on abstract requirements (paragraph 0060; i.e., the “abstract requirements” may include requirements such as “avoid using expensive resources in order to cut the cost of physical resources”, and “avoid using a resource that is small in free capacity so as not to affect other business operation systems operating on the same physical server”) that are first information indicating requirements to be satisfied by a target system (Figure 1, item 210) as a system to be operated, generating specific requirements (Figure 7, items 1412-1414, paragraph 0073; i.e., specific requirements [e.g., limit values] for the various parameters are created/generated based on the abstract requirements) that are second information indicating requirements to be satisfied by the target system (i.e., the target system should not exceed those limits), the specific requirements including third information indicating values of each of a plurality of values of a variable factor (Figure 7; i.e., the ”variable factor” being the various parameters, e.g., DB connection count, maximum process count, and connection timeout; each of those parameters has an associated per-unit resource usage value) included in a variable factor range (paragraphs 0072-0073; i.e., the upper and lower limits being equivalent to the “variable factor range”), the third information including information indicating a variable factor range as a range of values allowed for a variable factor to take during operation of the target system (i.e., the upper and lower limits are the range of values that the target system is allow to take), the value of the variable factor being a value varying during the operation of the target system and having a correlation with an operation status of the target system (Figure 8, item 1422 and Figure 9, item 1433, paragraph 0083; i.e., the different parameters have the associated per-unit resource usage values [CPU, memory, and network band ranges] that will take on actual measurements during operation of the performance test [the “target system”]; they have a “correlation” with the operation status of the target system in that they are constantly being changed while the performance test is executing).
Hanada does not expressly disclose generating difference information between a pre-change system configuration, which is a current system configuration of the target system, and a post-change system configuration, which is a target system configuration of the target system, the post-change system configuration corresponding to the specific requirements;
generating, based on the difference information, state transition information indicating a transition from the pre-change system configuration to the post-change system configuration; and
calculating, based on the state transition information, a state transition procedure for transition from the pre-change system configuration to the post-change system configuration with a fewest number of state transitions.
In the same field of endeavor, Ostrye teaches generating difference information between a pre-change system configuration, which is a current system configuration of the target system (Figure 6, items 632, paragraph 0105), and a post-change system configuration, which is a target system configuration of the target system, the post-change system configuration corresponding to the specific requirements (paragraphs 0106-0107; i.e., the current heating and cooling capacity being equivalent to the claimed “pre-change system configuration” and the target desired heating and cooling capacity being equivalent to the claimed “post-change system configuration”; the total changes needed for the various devices 632 to take on [e.g., by turning on or off] to achieve the desired heating and cooling capacity being equivalent to the claimed “difference information”);
generating, based on the difference information, state transition information indicating a transition from the pre-change system configuration to the post-change system configuration (paragraphs 0107 and 0109; i.e., different combination options containing different transitions [the claimed “state transition information”] of the various devices 632 can be determined and generated by the combination finder 623); and
calculating, based on the state transition information, a state transition procedure for transition from the pre-change system configuration to the post-change system configuration with a fewest number of state transitions (paragraphs 0107-0109; i.e., different state transition options can be calculated, including an option that has the lowest total transition count [“fewest number of state transitions”]; the combination selector 625 selects that particular post-change system configuration).
The motivation discussed above with regards to Claim 1 applies equally as well to Claim 16.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure because each reference discloses systems for operation planning for target systems.
Response to Arguments
Applicant’s arguments with respect to claim 1 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
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 FAISAL M ZAMAN whose telephone number is (571)272-6495. The examiner can normally be reached Monday - Friday, 8 am - 5 pm, alternate Fridays.
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, Andrew J. Jung can be reached at 571-270-3779. 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.
/FAISAL M ZAMAN/ Primary Examiner, Art Unit 2175
Prosecution Insights