DETAILED ACTION
1. Claims 1-2 have been presented for examination.
Claim 3 has been cancelled.
Notice of Pre-AIA or AIA Status
2. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
PRIORITY
3. Acknowledgment is made that this application is a 371 of PCT/JP2020/017124 filed 04/21/2020.
Response to Arguments
4. Applicant's arguments filed 1/6/26 have been fully considered but they are not persuasive.
i) Following Applicants amendments the previously presented claim objections are WITHDRAWN.
ii) Following Applicants amendments the previously presented specification objections are WITHDRAWN.
iii) Following Applicants amendments the previously presented 112 rejections are WITHDRAWN.
iv) Following Applicants amendments and arguments an additional prior art rejection has been presented below.
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.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103(a) are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
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 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.
5. Claim(s) 1-2 are rejected under 35 U.S.C. 103 as being unpatentable over Weber et al. U.S. Patent Publication No. 20170147324, hereafter Weber in view of Inoue, Takeru, et al. "An efficient framework for data-plane verification with geometric windowing queries." IEEE Transactions on Network and Service Management 14.4 (2017): 1113-1127, hereafter Inoue.
Regarding Claim 1: The reference discloses An execution procedure searching device that searches for a command sequence to be set for a plurality of devices constituting a system, comprising:
a processor; and
a storage medium having computer program instructions stored thereon, when executed by the processor, performs:
a first step for determining whether a simulator of the system having executed a temporary update command sequence satisfies a predetermined policy, and executes, until satisfaction for the predetermined policy of the simulator, processing for: (Weber. “[0110] Heuristics 362 may include data representing one or more conditions. Each condition may indicate whether hot- or warm-swapping can be used at test environment system 364. For instance, if changing inheritance hierarchies in a set of updated compiled targets would not permit hot-swapping, heuristics may include a condition to test for changed inheritance hierarchies in either the source code or bytecode of the updated compiled targets. If verifier module 360 determines that either the changed source code or bytecode of the updated compiled targets satisfies a condition in heuristics 362 that hot-swapping or warm-swapping cannot be used, then verifier module 360 may send data to packaging module 358, which causes packaging module 358 to insert data within a target set or target subset that hot-swapping or warm-swapping cannot be used. If verifier module 360 determines that either the changed source code or bytecode of the updated compiled targets satisfies a condition in heuristics 362 that hot-swapping or warm-swapping cannot be used, then verifier module 360 may send data to deploy module 356 to send a command that indicates hot-swapping or warm-swapping cannot be used and/or that cold-swapping should be used for the updated target set. Heuristics 362 may be configured by a software developer, hardcoded, or learned based on previous failures of hot-swapping or warm-swapping data received from test environment 364.”)
a second step with addition of one new candidate command of one or more new candidate commands to the temporary update command sequence on condition that the simulator does not satisfy the predetermined policy; (Weber. “[0106] The coordinator may also receive a command to restart the resource manager without restarting application 130 entirely. Based on the command, the coordinator may swap the name of the predefined location or directory that stores the resources and is known to the resource manager and the name of the temporary file or directory that stores the updated resources. For instance, the coordinator may rename the predefined location or directory that stores the resources and is known to the resource manager to the name of the temporary file or directory that stores the updated resources, and vice versa.”)
adding the new candidate command to the temporary update command sequence on condition that the simulator approaches the state where the predetermined policy is satisfied, with the addition of the new candidate command, or deleting a command at the end of the temporary update command sequence on condition that the simulator does not approach the state where the predetermined policy is satisfied, with addition of any one of the new candidate commands; and then (Weber. “[0110] Heuristics 362 may include data representing one or more conditions. Each condition may indicate whether hot- or warm-swapping can be used at test environment system 364. For instance, if changing inheritance hierarchies in a set of updated compiled targets would not permit hot-swapping, heuristics may include a condition to test for changed inheritance hierarchies in either the source code or bytecode of the updated compiled targets. If verifier module 360 determines that either the changed source code or bytecode of the updated compiled targets satisfies a condition in heuristics 362 that hot-swapping or warm-swapping cannot be used, then verifier module 360 may send data to packaging module 358, which causes packaging module 358 to insert data within a target set or target subset that hot-swapping or warm-swapping cannot be used. If verifier module 360 determines that either the changed source code or bytecode of the updated compiled targets satisfies a condition in heuristics 362 that hot-swapping or warm-swapping cannot be used, then verifier module 360 may send data to deploy module 356 to send a command that indicates hot-swapping or warm-swapping cannot be used and/or that cold-swapping should be used for the updated target set. Heuristics 362 may be configured by a software developer, hardcoded, or learned based on previous failures of hot-swapping or warm-swapping data received from test environment 364.”)
returning to the first step, and performs a third step for determining whether the actual system having executed the temporary update command sequence satisfies the predetermined policy on condition that the simulator satisfies the predetermined policy, and executes processing for returning to the second step until satisfaction for the predetermined policy of the actual system, on condition that the actual system does not satisfy the predetermined policy. (Weber. “[0110] Heuristics 362 may include data representing one or more conditions. Each condition may indicate whether hot- or warm-swapping can be used at test environment system 364. For instance, if changing inheritance hierarchies in a set of updated compiled targets would not permit hot-swapping, heuristics may include a condition to test for changed inheritance hierarchies in either the source code or bytecode of the updated compiled targets. If verifier module 360 determines that either the changed source code or bytecode of the updated compiled targets satisfies a condition in heuristics 362 that hot-swapping or warm-swapping cannot be used, then verifier module 360 may send data to packaging module 358, which causes packaging module 358 to insert data within a target set or target subset that hot-swapping or warm-swapping cannot be used. If verifier module 360 determines that either the changed source code or bytecode of the updated compiled targets satisfies a condition in heuristics 362 that hot-swapping or warm-swapping cannot be used, then verifier module 360 may send data to deploy module 356 to send a command that indicates hot-swapping or warm-swapping cannot be used and/or that cold-swapping should be used for the updated target set. Heuristics 362 may be configured by a software developer, hardcoded, or learned based on previous failures of hot-swapping or warm-swapping data received from test environment 364.”)
Weber does not explicitly recite for determining whether a reachable range of a packet is expanded.
However Inoue recites for determining whether a reachable range of a packet is expanded. (Inoue. Page 1115, left column, 2nd paragraph, “Thanks to abstraction in the formalization, our framework supports several types of tests beyond the example above; e.g., every packet outside the window is unreachable, and only the packets inside the window exit through a specified firewall. Our framework is, in addition, very efficient, because all steps are connected via the quotient space, not the large header space.” Page 1114, left column, 2nd paragraph, “2) Policy Compliance: Network operators have to not only know the set of reachable packets, but also check the consistency between the reachable set and another set of packets intended to be reachable. This is because network policies are often defined by forwarding behaviors as well as a set of intended packets (the packets are usually specified by IP address prefixes and TCP/UDP port ranges) [3], [26]. For example, a verifier would find that packets destined for 192.0.2.0/24 with ports 22 and 23 are reachable between the specified interfaces, but operators might have intended to set only port 22 as admissible following their policy, so the consistency check is mandatory.”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to utilize the reachability analysis of Inoue with the system of Weber since this analysis is “efficient, because all steps are connected via the quotient space, not the large header space” and further “Network operators have to not only know the set of reachable packets, but also check the consistency between the reachable set and another set of packets intended to be reachable. This is because network policies are often defined by forwarding behaviors as well as a set of intended packets.” (Inoue, citations above)
Regarding Claim 2: The reference discloses An execution procedure searching method executed by an execution procedure searching device that searches for a command sequence to be set for a plurality of devices constituting a system, comprising
performing, by the execution procedure searching device, a first step for determining whether a simulator of the system having executed a temporary update command sequence satisfies a predetermined policy and comprising executing, until satisfaction for the predetermined policy of the simulator, processing for: (Weber. “[0110] Heuristics 362 may include data representing one or more conditions. Each condition may indicate whether hot- or warm-swapping can be used at test environment system 364. For instance, if changing inheritance hierarchies in a set of updated compiled targets would not permit hot-swapping, heuristics may include a condition to test for changed inheritance hierarchies in either the source code or bytecode of the updated compiled targets. If verifier module 360 determines that either the changed source code or bytecode of the updated compiled targets satisfies a condition in heuristics 362 that hot-swapping or warm-swapping cannot be used, then verifier module 360 may send data to packaging module 358, which causes packaging module 358 to insert data within a target set or target subset that hot-swapping or warm-swapping cannot be used. If verifier module 360 determines that either the changed source code or bytecode of the updated compiled targets satisfies a condition in heuristics 362 that hot-swapping or warm-swapping cannot be used, then verifier module 360 may send data to deploy module 356 to send a command that indicates hot-swapping or warm-swapping cannot be used and/or that cold-swapping should be used for the updated target set. Heuristics 362 may be configured by a software developer, hardcoded, or learned based on previous failures of hot-swapping or warm-swapping data received from test environment 364.”)
performing, by the execution procedure searching device, with addition of one new candidate command of one or more new candidate commands to the temporary update command sequence on condition that the simulator does not satisfy the predetermined policy; (Weber. “[0106] The coordinator may also receive a command to restart the resource manager without restarting application 130 entirely. Based on the command, the coordinator may swap the name of the predefined location or directory that stores the resources and is known to the resource manager and the name of the temporary file or directory that stores the updated resources. For instance, the coordinator may rename the predefined location or directory that stores the resources and is known to the resource manager to the name of the temporary file or directory that stores the updated resources, and vice versa.”)
adding, by the execution procedure searching device, the new candidate command to the temporary update command sequence on condition that the simulator approaches the state where the predetermined policy is satisfied, with the addition of the new candidate commands, or deleting, by the execution procedure searching device, a command at the end of the temporary update command sequence on condition that the simulator does not approach the state where the predetermined policy is satisfied, with addition of any one of the new candidate commands; and then returning, by the execution procedure searching device, to the first step, and (Weber. “[0110] Heuristics 362 may include data representing one or more conditions. Each condition may indicate whether hot- or warm-swapping can be used at test environment system 364. For instance, if changing inheritance hierarchies in a set of updated compiled targets would not permit hot-swapping, heuristics may include a condition to test for changed inheritance hierarchies in either the source code or bytecode of the updated compiled targets. If verifier module 360 determines that either the changed source code or bytecode of the updated compiled targets satisfies a condition in heuristics 362 that hot-swapping or warm-swapping cannot be used, then verifier module 360 may send data to packaging module 358, which causes packaging module 358 to insert data within a target set or target subset that hot-swapping or warm-swapping cannot be used. If verifier module 360 determines that either the changed source code or bytecode of the updated compiled targets satisfies a condition in heuristics 362 that hot-swapping or warm-swapping cannot be used, then verifier module 360 may send data to deploy module 356 to send a command that indicates hot-swapping or warm-swapping cannot be used and/or that cold-swapping should be used for the updated target set. Heuristics 362 may be configured by a software developer, hardcoded, or learned based on previous failures of hot-swapping or warm-swapping data received from test environment 364.”)
performing, by the execution procedure searching device, a third step for determining whether the actual system having executed the temporary update command sequence satisfies the predetermined policy on condition that the simulator satisfies the predetermined policy; and executing, by the execution procedure searching device, processing for returning to the second step until satisfaction for the predetermined policy of the actual system, on condition that the actual system does not satisfy the predetermined policy. (Weber. “[0110] Heuristics 362 may include data representing one or more conditions. Each condition may indicate whether hot- or warm-swapping can be used at test environment system 364. For instance, if changing inheritance hierarchies in a set of updated compiled targets would not permit hot-swapping, heuristics may include a condition to test for changed inheritance hierarchies in either the source code or bytecode of the updated compiled targets. If verifier module 360 determines that either the changed source code or bytecode of the updated compiled targets satisfies a condition in heuristics 362 that hot-swapping or warm-swapping cannot be used, then verifier module 360 may send data to packaging module 358, which causes packaging module 358 to insert data within a target set or target subset that hot-swapping or warm-swapping cannot be used. If verifier module 360 determines that either the changed source code or bytecode of the updated compiled targets satisfies a condition in heuristics 362 that hot-swapping or warm-swapping cannot be used, then verifier module 360 may send data to deploy module 356 to send a command that indicates hot-swapping or warm-swapping cannot be used and/or that cold-swapping should be used for the updated target set. Heuristics 362 may be configured by a software developer, hardcoded, or learned based on previous failures of hot-swapping or warm-swapping data received from test environment 364.”)
Weber does not explicitly recite a second step for determining whether a reachable range of a packet is expanded.
However Inoue recites a second step for determining whether a reachable range of a packet is expanded. (Inoue. Page 1115, left column, 2nd paragraph, “Thanks to abstraction in the formalization, our framework supports several types of tests beyond the example above; e.g., every packet outside the window is unreachable, and only the packets inside the window exit through a specified firewall. Our framework is, in addition, very efficient, because all steps are connected via the quotient space, not the large header space.” Page 1114, left column, 2nd paragraph, “2) Policy Compliance: Network operators have to not only know the set of reachable packets, but also check the consistency between the reachable set and another set of packets intended to be reachable. This is because network policies are often defined by forwarding behaviors as well as a set of intended packets (the packets are usually specified by IP address prefixes and TCP/UDP port ranges) [3], [26]. For example, a verifier would find that packets destined for 192.0.2.0/24 with ports 22 and 23 are reachable between the specified interfaces, but operators might have intended to set only port 22 as admissible following their policy, so the consistency check is mandatory.”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to utilize the reachability analysis of Inoue with the system of Weber since this analysis is “efficient, because all steps are connected via the quotient space, not the large header space” and further “Network operators have to not only know the set of reachable packets, but also check the consistency between the reachable set and another set of packets intended to be reachable. This is because network policies are often defined by forwarding behaviors as well as a set of intended packets.” (Inoue, citations above)
Conclusion
6. 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.
7. All Claims are rejected.
8. The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
i) U.S. Patent No. 9721052
ii) U.S. Patent No. 10404700
iii) U.S. Patent Publication No. 20180374001
iv) U.S. Patent No. 20160246278
9. Any inquiry concerning this communication or earlier communications from the examiner should be directed to Saif A. Alhija whose telephone number is (571) 272-8635. The examiner can normally be reached on M-F, 10:00-6:00.
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, Renee Chavez, can be reached at (571) 270-1104. The fax phone number for the organization where this application or proceeding is assigned is (571) 273-8300. Informal or draft communication, please label PROPOSED or DRAFT, can be additionally sent to the Examiners fax phone number, (571) 273-8635.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
SAA
/SAIF A ALHIJA/Primary Examiner, Art Unit 2188