DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This office correspondence is in response to “Amendment and Response under 37 C.F.R. 1.111 filed on March 26, 2026 in response to a non-final office action issued on October 8, 2025.
Claims 17 – 36 are pending.
Claims 17 – 36 are rejected.
Applicant’s arguments filed on 03/26/2026 has been fully considered:
In regard to claims 17 – 37 which were rejected on the ground of non-provisional non-statutory anticipatory-type double patenting as being unpatentable over claims 1 – 17 of U.S. Patent 11,936,536, and claims 17 and 27 which were rejected on the ground of non-provisional non-statutory anticipatory-type double patenting as being unpatentable over claims 1 and 8 of U.S. Patent 11,159,394, the applicant is holding in abeyance a response, therefore the rejections are not withdrawn..
In regard to claims 17 – 36 which were rejected under 35 U.S.C. 103, the applicant’s arguments were not persuasive to the rejection of claims from the last office action and said rejections are not withdrawn. The examiner here now responds to each argument.
In regard to claims 17 – 18 and 27 – 28, the applicant argues the prior art combination of Zizlavsky, Breitbart, Dutta, Lee, and Salle fails to anticipate, disclose or teach:
“ determining individual network resources are in a reference group of network resources based at least partly on the individual network resources in the reference group of network resources each having non-intermediated communication relationships with at least a threshold number of network resources;” (as recited in claim 17 and substantially replicated in claim 27)
The applicant states:
“ . . . The office action cites to paragraph [0046] and [0047] of Dutta as teaching this element . . . the cited portions of Dutta relate to a graph, the nodes of
which "can correspond to data center resources," and the edges of which are "associated with multi-dimensional edge weights corresponding to commodities (e.g., bandwidth, delay, maximum jitter, buffer sizing, etc.) provided by the connections corresponding to the edges." Dutta further
explains that "edges of the graph can be associated with commodity requirements. For example, edges can be associated with bandwidth requirements for the connections represented by the edges."
The Office Action asserts that Dutta's "commodity requirements" correspond to the
claimed "threshold number of network resources." (Office Action, p. 22.). However, the
disclosure of Dutta regarding "commodities" is limited to "bandwidth, delay, maximum jitter, buffer sizing" for connections, and not the "non-intermediated communication relationships" recited in claim 17. That is, Dutta's "commodities" appear to be aspects of connections, rather than the connections themselves.
Thus Dutta, alone or in combination with the other art of record, fails to teach or render
obvious at least "determining individual network resources are in a reference group of network resources based at least partly on the individual network resources in the reference group of network resources each having non-intermediated communication relationships with at least a threshold number of network resources," in the context of claim 17.
For at least the foregoing reasons, Applicant respectfully submits that the cited references, individually or in combination, fail to teach or suggest each and every element of claim 17, and therefore the evidence as a whole does not show that the legal determination sought to be proved (i.e., the reference teachings establish a prima facie case of obviousness) is more probable than not. Accordingly, Applicant requests that rejection of claim 17 under 35 U.S.C. § 103 be withdrawn and the claim allowed. . . .” (Applicant’s remarks pages 8 – 10)
In response to the applicant’s argument:
The applicant’s argument is not persuasive because it is reasonable to equate the threshold number of network resources required in the claimed invention to the commodity requirement described in the prior art Dutta because the commodity requirements that are common to the network resources are used as a way to categorize or group the network resource to other similar resources that may behave or operate in a common relationship, therein this application of Dutta’s teaching reasonably interprets the determining step of the limitation under review, under a broadest reasonable interpretation analysis. See MPEP 2111 (“an examiner must construe claim terms in the broadest reasonable manner during prosecution as is reasonably allowed in an effort to establish a clear record of what applicant intends to claim. Thus, the Office does not interpret claims in the same manner as the courts. In re Morris, 127 F.3d 1048, 1054, 44 USPQ2d 1023, 1028 (Fed. Cir. 1997); In re Zletz, 893 F.2d 319, 321-22, 13 USPQ2d 1320, 1321-22 (Fed. Cir. 1989). Because applicant has the opportunity to amend the claims during prosecution, giving a claim its broadest reasonable interpretation will reduce the possibility that the claim, once issued, will be interpreted more broadly than is justified. In re Yamamoto, 740 F.2d 1569, 1571 (Fed. Cir. 1984); In re Zletz, 893 F.2d 319, 321, 13 USPQ2d 1320, 1322 (Fed. Cir. 1989) (“During patent examination the pending claims must be interpreted as broadly as their terms reasonably allow.”); In re Prater, 415 F.2d 1393, 1404-05, 162 USPQ 541, 550-51 (CCPA 1969)). Therein the rejections are not withdrawn. The applicant is referred to the claim rejections described below.
The examiner re recommends that the applicant review the specification for disclosure that if integrated into the independent claims would distinguish the amended claims from the cited prior art. The applicant should file the terminal disclaimer for the double patenting prior to the next response. The applicant is invited to contact the examiner for an interview to discuss how to move the prosecution forward.
Authorization for Internet Communications
The examiner encourages Applicant to submit an authorization to communicate with the examiner via the Internet by making the following statement (from MPEP 502.03):
“Recognizing that Internet communications are not secure, I hereby authorize the USPTO to communicate with the undersigned and practitioners in accordance with 37 CFR 1.33 and 37 CFR 1.34 concerning any subject matter of this application by video conferencing, instant messaging, or electronic mail. I understand that a copy of these communications will be made of record in the application file.”
Please note that the above statement can only be submitted via Central Fax (not Examiner's Fax), Regular postal mail, or EFS Web using PTO/SB/439.
Priority
This application is a continuation of prior filed application No. 17/510279 (now U.S. Patent 11,936,536) under 35 U.S.C. 120, 121, 365(c), or 386(c). Co-pendency between the current application and the prior application is required. Since the applications were co-pending at the time of the instant application’s file date, the applicant is entitled to the benefit claim to the prior-filed application, which claimed benefit to prior-filed application No. 16/192592 (now U.S. Patent 11,159,394) which further claims benefit to prior-filed application No. 15/700103 (now abandoned) which in turn claimed benefit to application 14/494697 (now abandoned). Therein the instant application is entitled to a priority date of September 24, 2014.
Double Patenting
The non-statutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A non-statutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on non-statutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP §§ 706.02(l)(1) - 706.02(l)(3) for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/process/file/efs/guidance/eTD-info-I.jsp.
Claims 17 – 36 are rejected on the ground of non-provisional non-statutory anticipatory-type double patenting as being unpatentable over claims 1 – 17 of U.S. Patent 11,936,536. Although the conflicting claims are not identical, they are not patently distinct from each other because both sets of claims are directed to the same invention. This is a non- provisional non-statutory anticipatory-type double patenting rejection since the claims directed to the same invention have been patented.
In regard to claim 17:
Application 18/606943
U.S. Patent 18/606943
17. A computer-implemented method comprising, as performed by one or more computing devices configured with computer-executable instructions:
1. A computer-implemented method comprising, as performed by one or more computing devices configured with computer-executable instructions:
monitoring communications among network resources of a networked environment to generate monitoring data, wherein the network resources include a plurality of network devices and a plurality of applications;
monitoring communications among network resources of a networked environment to generate monitoring data, wherein the network resources include a plurality of network devices and a plurality of applications;
identifying, based at least partly on the monitoring data, media access control addresses (MAC addresses) corresponding to the plurality of network devices, wherein the plurality of network devices and the plurality of applications distribute the communications among the network resources using the MAC addresses;
identifying, based at least partly on the monitoring data, media access control addresses (MAC addresses) corresponding to the plurality of network devices, wherein the plurality of network devices and the plurality of applications distribute the communications among the network resources using the MAC addresses;
identifying one or more non-intermediated communication relationships based at least partly on the MAC addresses, wherein a non-intermediated communication relationship comprises a first network resource associated with a first MAC address of the MAC addresses communicatively connected to at least a second network resource associated with a second MAC address of the MAC addresses without any network resource, communicatively intermediate the first network resource and the second network resource, associated with a MAC address;
identifying one or more non-intermediated communication relationships based at least partly on the MAC addresses, wherein a non-intermediated communication relationship comprises a first network resource associated with a first MAC address of the MAC addresses communicatively connected to at least a second network resource associated with a second MAC address of the MAC addresses without any network resource, communicatively intermediate the first network resource and the second network resource, associated with a MAC address;
Determ0ining individual network resources are in a reference group of network resources based at least partly on the individual network resources in the reference group of network resources each having non-intermediated communication relationships with at least a threshold number of network resources;
determining individual network resources are in a reference group of network resources based at least partly on the individual network resources in the reference group of network resources each having non-intermediated communication relationships with at least a threshold number of network resources;
identifying the first network resource from the reference group of network resources for migration to a second networked environment; and
identifying the first network resource as a critical interface based at least partly on the first network resources being an individual network resource being in non-intermediated communication relationships with the threshold number of network resources from the reference group of network resources, and based at least partly on data communicated via the first network resource; and
performing a migration action based at least partly on the first network resource.
performing a migration action based at least partly on the first network resource being the critical interface.
It is clear that all of the elements of the instant application 18/606943 (herein ‘943) claim 17 are to be found in U.S. Patent 11,936,536 (herein ‘536) claim 1 (as the instant application ‘943 claim 17 fully encompasses Patent ‘536 claim 1). The difference between ‘943 claim 17 and ‘536 claim 1 lies in the fact that the ‘536 claim includes many more elements and is thus much more specific. Thus the invention of claim 1 of the 536 patent is in effect a “species” of the “generic” invention of ‘943 claim 17. It has been held that the generic invention is “anticipated” by the “species”. See In re Goodman, 29 USPQ2d 2010 (Fed. Cir. 1993). Since the ‘943 claim 17 is anticipated by claim 1 of ‘536, it is not patently distinct from ‘536 claim 1.
In regard to claim 18, see claim 5 of ‘536.
In regard to claim 19, see claim 1 of ‘536.
In regard to claim 20, see claim 6 of ‘536.
In regard to claim 21, see claim 1 of ‘536.
In regard to claim 22, see claim 7 of ‘536.
In regard to claim 23, see claim 8 of ‘536.
In regard to claim 24, see claim 2 of ‘536.
In regard to claim 25, see claim 3 of ‘536.
In regard to claim 26, see claim 4 of ‘536.
In regard to claim 27:
Application 18/606943
U.S. Patent 11,936,536
27. A system comprising:
9. A system comprising:
computer-readable memory storing computer-executable instructions; and
computer-readable memory storing computer-executable instructions; and
one or more processors in communication with the computer-readable memory and configured by the computer-executable instructions to at least:
one or more processors in communication with the computer-readable memory and configured by the computer-executable instructions to at least:
monitor communications among network resources of a networked environment to generate monitoring data, wherein the network resources include a plurality of network devices and a plurality of applications;
monitor communications among network resources of a networked environment to generate monitoring data, wherein the network resources include a plurality of network devices and a plurality of applications;
identify, based at least partly on the monitoring data, media access control addresses (MAC addresses) corresponding to the plurality of network devices, wherein the plurality of network devices and the plurality of applications distribute the communications among the network resources using the MAC addresses;
identify, based at least partly on the monitoring data, media access control addresses (MAC addresses) corresponding to the plurality of network devices, wherein the plurality of network devices and the plurality of applications distribute the communications among the network resources using the MAC addresses;
identify one or more non-intermediated communication relationships based at least partly on the MAC addresses, wherein a non-intermediated communication relationship comprises a first network resource associated with a first MAC address of the MAC addresses communicatively connected to at least a second network resource associated with a second MAC address of the MAC addresses without any network resource, communicatively intermediate the first network resource and the second network resource, associated with a MAC address;
identify one or more non-intermediated communication relationships based at least partly on the MAC addresses, wherein a non-intermediated communication relationship comprises a first network resource associated with a first MAC address of the MAC addresses communicatively connected to at least a second network resource associated with a second MAC address of the MAC addresses without any network resource, communicatively intermediate the first network resource and the second network resource, associated with a MAC address;
determine individual network resources are in a reference group of network resources based at least partly on the individual network resources in the reference group of network resources each having non-intermediated communication relationships with at least a threshold number of network resources;
determine individual network resources are in a reference group of network resources based at least partly on the individual network resources in the reference group of network resources each having non-intermediated communication relationships with at least a threshold number of network resources;
identify the first network resource from the reference group of network resources for migration to a second networked environment; and
identify the first network resource as a critical interface based at least partly on the first network resource being an individual network resource being in non-intermediated communication relationships with a threshold number of network resources from the reference group of network resources, and based at least partly on data communicated via the first network resource; and
perform a migration action based at least partly on the first network resource.
perform a migration action based at least partly on the first network resource being the critical interface.
It is clear that all of the elements of the instant application 18/606943 (herein ‘943) claim 27 are to be found in U.S. Patent 11,936,536 (herein ‘536) claim 9 (as the instant application ‘943 claim 27 fully encompasses Patent ‘536 claim 9). The difference between ‘943 claim 27 and ‘536 claim 9 lies in the fact that the ‘536 claim includes many more elements and is thus much more specific. Thus the invention of claim 9 of the 536 patent is in effect a “species” of the “generic” invention of ‘943 claim 27. It has been held that the generic invention is “anticipated” by the “species”. See In re Goodman, 29 USPQ2d 2010 (Fed. Cir. 1993). Since the ‘943 claim 27 is anticipated by claim 9 of ‘536, it is not patently distinct from ‘536 claim 9.
In regard to claim 28, see claim 13 of ‘536.
In regard to claim 29, see claim 9 of ‘536.
In regard to claim 30, see claim 9 of ‘536.
In regard to claim 31, see claim 15 of ‘536.
In regard to claim 32, see claim 11 of ‘536.
In regard to claim 33, see claim 10 of ‘536.
In regard to claim 34, see claim 16 pf ‘536.
In regard to claim 35, see claim 12 of ‘536.
In regard to claim 36, see claim 17 of ‘536.
Claims 17 and 27 are rejected on the ground of non-provisional non-statutory anticipatory-type double patenting as being unpatentable over claims 1 and 8 of U.S. Patent 11,159,394. Although the conflicting claims are not identical, they are not patently distinct from each other because both sets of claims are directed to the same invention. This is a non- provisional non-statutory anticipatory-type double patenting rejection since the claims directed to the same invention have been patented.
Application 18/606943
U.S. Patent 11,159,394
17. A computer-implemented method comprising, as performed by one or more computing devices configured with computer-executable instructions:
1. A computer-implemented method comprising, as performed by one or more computing devices configured with computer-executable instructions,
monitoring communications among network resources of a networked environment to generate monitoring data, wherein the network resources include a plurality of network devices and a plurality of applications;
monitoring communications among network resources of a networked environment, wherein the network resources include a plurality of network devices and a plurality of applications;
identifying, based at least partly on the monitoring data, media access control addresses (MAC addresses) corresponding to the plurality of network devices, wherein the plurality of network devices and the plurality of applications distribute the communications among the network resources using the MAC addresses;
using information of the monitored communications to identify media access control addresses (MAC addresses) corresponding to the plurality of network devices, wherein a MAC address uniquely identifies a network device and represents an addressable location of the network device in the networked environment, wherein the plurality of network devices and the plurality of applications distribute the communications among the network resources using the MAC addresses, wherein the plurality of network devices comprise the network device;
identifying one or more non-intermediated communication relationships based at least partly on the MAC addresses, wherein a non-intermediated communication relationship comprises a first network resource associated with a first MAC address of the MAC addresses communicatively connected to at least a second network resource associated with a second MAC address of the MAC addresses without any network resource, communicatively intermediate the first network resource and the second network resource, associated with a MAC address;
using information of the monitored communications and information of the MAC addresses to identify non-intermediated communication relationships among the MAC addresses, wherein a non-intermediated communication relationship comprises a first network device with a first MAC address of the MAC addresses communicatively connected to at least a second network device with a second MAC address of the MAC addresses without any network device, communicatively intermediate the first network device and the second network device, having a MAC address;
Determ0ining individual network resources are in a reference group of network resources based at least partly on the individual network resources in the reference group of network resources each having non-intermediated communication relationships with at least a threshold number of network resources;
using information of the non-intermediated communication relationships to identify a reference group of network resources based at least partly on individual network resources in the reference group of network resources each having non-intermediated communication relationships with at least a threshold number of network resources;
identifying the first network resource from the reference group of network resources for migration to a second networked environment; and
evaluating a plurality of migration scenarios, wherein a migration scenario of the plurality of migration scenarios represents one or more functions of the reference group of network resources being performed in a second networked environment, external to the networked environment, in lieu of the one or more functions being performed in the networked environment; and
performing a migration action based at least partly on the first network resource.
identifying a network resource of the reference group of network resources for migration to the second networked environment based on the migration scenario.
It is clear that all of the elements of the instant application 18/606943 (herein ‘943) claim 17 are to be found in U.S. Patent 11,159,394 (herein ‘394) claim 1 (as the instant application ‘943 claim 17 fully encompasses Patent ‘394 claim 1). The difference between ‘943 claim 17 and ‘394 claim 1 lies in the fact that the ‘394 claim includes many more elements and is thus much more specific. Thus the invention of claim 1 of the ‘394 patent is in effect a “species” of the “generic” invention of ‘943 claim 17. It has been held that the generic invention is “anticipated” by the “species”. See In re Goodman, 29 USPQ2d 2010 (Fed. Cir. 1993). Since the ‘943 claim 17 is anticipated by claim 1 of ‘394, it is not patently distinct from ‘394 claim 1.
In regard to claim 27:
Application 18/606943
U.S. Patent 11,159,394
27. A system comprising:
8. A system comprising:
computer-readable memory storing computer-executable instructions; and
computer-readable memory storing computer-executable instructions; and
one or more processors in communication with the computer-readable memory and configured by the computer-executable instructions to at least:
one or more processors in communication with the computer-readable memory and configured by the computer-executable instructions to at least:
monitor communications among network resources of a networked environment to generate monitoring data, wherein the network resources include a plurality of network devices and a plurality of applications;
monitor communications among network resources of a networked environment, wherein the network resources include a plurality of network devices and a plurality of applications; use information of the monitored communications to identify media access control addresses (MAC addresses) corresponding to the plurality of network devices, wherein a MAC address uniquely identifies a network device and represents an addressable location of the network device in the networked environment, wherein the plurality of network devices and the plurality of applications distribute the communications among the network resources using the MAC addresses;
identify, based at least partly on the monitoring data, media access control addresses (MAC addresses) corresponding to the plurality of network devices, wherein the plurality of network devices and the plurality of applications distribute the communications among the network resources using the MAC addresses;
use information of the monitored communications and information of the MAC addresses to identify non-intermediated communication relationships among the MAC addresses,
identify one or more non-intermediated communication relationships based at least partly on the MAC addresses, wherein a non-intermediated communication relationship comprises a first network resource associated with a first MAC address of the MAC addresses communicatively connected to at least a second network resource associated with a second MAC address of the MAC addresses without any network resource, communicatively intermediate the first network resource and the second network resource, associated with a MAC address;
wherein a non-intermediated communication relationship comprises a first network device with a first MAC address of the MAC addresses communicatively connected to at least a second network device with a second MAC address of the MAC addresses, without any network device, communicatively intermediate the first network device and the second network device, having a MAC address;
determine individual network resources are in a reference group of network resources based at least partly on the individual network resources in the reference group of network resources each having non-intermediated communication relationships with at least a threshold number of network resources;
use information of the non-intermediated communication relationships to identify a reference group of network resources based at least partly on individual network resources in the reference group of network resources each having non-intermediated communication relationships with at least a threshold number of network resources;
identify the first network resource from the reference group of network resources for migration to a second networked environment; and
evaluate one or more migration scenarios, wherein a migration scenario of the one or more migration scenarios represents one or more functions of the reference group of network resources being performed in a second networked environment, external to the networked environment, in lieu of the one or more functions being performed in the networked environment; and
perform a migration action based at least partly on the first network resource
identify a network resource of the reference group of network resources for migration to the second networked environment.
It is clear that all of the elements of the instant application 18/606943 (herein ‘943) claim 27 are to be found in U.S. Patent 11,159,394 (herein ‘394) claim 1 (as the instant application ‘943 claim 17 fully encompasses Patent ‘394 claim 8). The difference between ‘943 claim 27 and ‘394 claim 8 lies in the fact that the ‘394 claim includes many more elements and is thus much more specific. Thus the invention of claim 8 of the ‘394 patent is in effect a “species” of the “generic” invention of ‘943 claim 27. It has been held that the generic invention is “anticipated” by the “species”. See In re Goodman, 29 USPQ2d 2010 (Fed. Cir. 1993). Since the ‘943 claim 27 is anticipated by claim 8 of ‘394, it is not patently distinct from ‘394 claim 8.
Claim Analysis - 35 USC § 101 (Judicial Exception)
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 17 – 36 are directed to statutory subject matter and no 35 USC 101 rejection is applied for the judicial exception. The claims are directed to non-abstract improvements in computer related technology. The claimed subject matter is integrated into a practical application under Prong 2 of the Step 2A analysis described in MPEP 2016.04(d). A claim is non-statutory when it is directed to a judicial exception (e.g. either one of mathematical concepts, mental processes, or certain methods of organizing human activity) without significantly more. The claimed invention is not directed to a judicial exception. Instead, the claimed invention is directed to a technological improvement for evaluating the system assets of a computerized network wherein the method recited evaluates “communication relationships” that are critical interfaces by uniquely identifying a network address with its MAC address and further using information of the monitored communications and information of the MAC addresses to identify non-intermediated communication relationships among the MAC addresses. This information is used to determine a reference group of network resources that are candidates for migration to a second network environment. The ordered combination of the elements and limitations recited bound the claimed invention to a specific and useful improvement for managing the assets of a computerized communications network and evaluating migration scenarios for a reference group of network resources.
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 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 of this title, 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 17 – 18 and 27 - 28 are rejected under 35 U.S.C. 103 as being unpatentable over Zizlavsky et al. (U.S. 2015/0127806 A1; herein referred to as Zizlavsky) in view of Breitbart et al. (A Topology discovery in heterogeneous IP networks: the NetInventory system. IEEE/ACM Transactions on Networking (TON). 2004 Jun 1;12(3):401-14: herein referred to as Breitbart) in further view of Dutta et al. (U.S. 2013/0055091 A1; herein referred to as Dutta) in further view of Lee et al. (U.S. U.S. 2014/0301192 A1; herein referred to as Lee) and in further view of Salle et al. (U.S. 2015/0222702 A1; herein referred to as Salle).
In regard to claim 17, Zizlavsky teaches A computer-implemented method comprising (“. . . methods, systems, and computer programs for node de-duplication of physical nodes monitored by a network monitoring system. . .” ¶ [0002]) , as performed by one or more computing devices configured with computer-executable instructions (“ . . . the functionality of any of the methods described herein, such as those of FIGS. 3, 4, and 6, may be implemented by software and/or computer program code stored in memory or othetor computer readable or tangible media, and executed by a processor. In other embodiments, the functionality may be performed by hardware, for example through the use of an application specific integrated circuit (ASIC), a programmable gate array (PGA), a field programmable gate array (FPGA), or any other combination of hardware and software. . .” ¶ [0053]):
monitoring communications (“ . . . a subset of network management includes network monitoring of network traffic . . . ” ¶ [0005]) among network resources of a networked environment (“ . . . Functions that can be performed as part of network management may include, for example, planning, controlling, deploying, allocating, coordinating, and monitoring the resources of a network. Further functions may be related to network planning, frequency allocation, load balancing, configuration management, fault management, security management, performance management, bandwidth management, route analytics, and accounting management. . .” ¶ [0004]) to generate monitoring data, wherein the network resources include a plurality of network devices (“ . . . the terms network devices and network nodes, or simply devices or nodes, may be used interchangeably to refer to any physical device that is capable of connecting to and/or communicating on a network. Examples of such devices or nodes may include, but is not limited to, routers, switches, servers, computers, laptops, tablets, telephones, printers, mobile devices, and any other current or future component capable of sending, receiving, or forwarding information over a communications channel . . . ” ¶ [0017]) and a plurality of applications (“ . . the Sysname may be the Sysname for Simple Network Management Protocol (SNMP) nodes or may be the full computer name for window management instrumentation (WMI) nodes, for example. It should be noted that embodiments do not limit data sources to SNMP and/or WMI, and other types of data sources are equally applicable according to certain embodiments . . .” ¶ [0035]) ;
identifying, based at least partly on the monitoring data, media access control addresses (MAC addresses) (“ . . . a data collection set made up of DNS name, Sysname, IP address, and MAC address for each network node is used to help identify duplicate nodes. One embodiment includes logic which compares pieces of information from the data collection set against each other, for example DNS to DNS, MACs to MACs, etc. . . .” ¶ [0026]) corresponding to the plurality of network devices (e.g. discovered nodes)(“ . . . the system is configured to collect list of all DNS names, Sysnames, IP addresses, and MAC addresses for all discovered nodes, and to store them, for example, as part of a discovery job result. . . . ” ¶ [0028]), wherein the plurality of network devices (“ . . In the example of FIG. 3, at 300, one or more nodes are discovered. At 310, the associated IP address of the node(s) is discovered . . . “¶ [0040]) and the plurality of applications (“. . . At 320, the supported technology used for obtaining device information, such as SNMP, WMI, etc. is detected. At 330, information about the node(s) is obtained via the (detected) supported technology . . . “¶ [0040]) distribute the communications among the network resources using the MAC addresses (“ . . . Table 4 below illustrates an example results table. . . “¶ [0039])
PNG
media_image1.png
361
446
media_image1.png
Greyscale
;
Zizlavsky fails to explicitly teach but Breitbart teaches
identifying one or more non-intermediated communication relationships based at least partly on the MAC addresses (“ . . . We develop novel, practical algorithmic solutions for the problem of discovering physical topology in heterogeneous IP networks comprising multiple IP subnets and different types of network elements. The practicality of our algorithms stems from the fact that they rely solely on standard information routinely collected in the SNMP MIBs of elements and they require no modifications to the operating system software running on elements or hosts. More specifically, our topology discovery tool utilizes information either from the address forwarding tables (AFTs) of elements capturing the set of medium access control (MAC—i.e., layer-2) addresses that are reachable from each element interface, or (in the absence of AFT data) from the elements’ NetToMedia tables. The main algorithmic challenge that our tool faces is how to “stitch” such (local) information together to identify inter- connected router/switch interfaces and come up with a complete physical LAN topology . . .”(Page 403: Col 1: ¶ [0004]) , wherein a non-intermediated (e.g. reachable from each element interface) communication relationship (“ . . . the element address forwarding tables are complete; that is, they contain the full set of MAC addresses in the subnet reachable from each element interface. . . .” (Page 403: Col 2: ¶ [0002]) comprises a first network resource associated with a first MAC address (e.g. a source address in the set which is S1 – see Fig. 6) of the MAC addresses communicatively connected (“ . . . Therefore,
PNG
media_image2.png
30
41
media_image2.png
Greyscale
is the set of MAC addresses that have been seen as source addresses on packet frames received at
PNG
media_image3.png
30
34
media_image3.png
Greyscale
. We say that
PNG
media_image2.png
30
41
media_image2.png
Greyscale
is complete if
PNG
media_image4.png
30
39
media_image4.png
Greyscale
contains the MAC addresses of all network nodes from which frames can be received at
PNG
media_image3.png
30
34
media_image3.png
Greyscale
. If the switched domain comprises only one subnet, then
PNG
media_image2.png
30
41
media_image2.png
Greyscale
corresponds to the set of nodes in that are reachable from via the interface
PNG
media_image3.png
30
34
media_image3.png
Greyscale
by a path in the switched domain spanning tree . . .” (Page 404: Col 2: ¶ [0003]) to at least a second network resource associated with a second MAC address of the MAC addresses without any network resource (see Fig. 6 – R1, S2) (“. . . We discover the edges of N, one switched domain (in this case, one subnet) at a time. Let
PNG
media_image5.png
73
72
media_image5.png
Greyscale
be the set of MAC addresses corresponding to the switches and the routers of a subnet
PNG
media_image6.png
73
64
media_image6.png
Greyscale
. We begin the description of our edge discovery algorithm with a lemma that establishes a necessary and sufficient condition for an interface of a switch element to be connected to an interface of another switch . . .” (Page 405: Col 1: ¶ [0005]; Page 405: Col 2: ¶ [0001]);” . . . Si(Sk) is reachable from
PNG
media_image7.png
25
37
media_image7.png
Greyscale
(respectively,
PNG
media_image3.png
30
34
media_image3.png
Greyscale
) . . .
PNG
media_image4.png
30
39
media_image4.png
Greyscale
), we have found two distinct paths (i.e., a loop) in the spanning tree of the switched domain between
PNG
media_image8.png
25
25
media_image8.png
Greyscale
and
PNG
media_image9.png
25
30
media_image9.png
Greyscale
. This is again a contradiction. Lemma 3.1 gives us the basis for a simple algorithm to dis- cover direct connections between switches . . .” Page 405: Col 2: ¶ [0002]), communicatively intermediate the first network resource and the second network resource, associated with a MAC address (“ . . .As mentioned earlier, the approach we adopt to discovering the topology of switched domains containing multiple subnets is to rule out interface connections that cannot exist. In the following lemmas, we identify the conditions under which two interfaces cannot be directly connected. The lemmas make use of the following property for switched domains containing multiple subnets: Suppose
PNG
media_image10.png
25
25
media_image10.png
Greyscale
and are two nodes from different subnets; then,
PNG
media_image4.png
30
39
media_image4.png
Greyscale
contains if and only if there is a node
PNG
media_image11.png
30
28
media_image11.png
Greyscale
from the same subnet as Sk such that Sp . . .Si . . .sk is a path in the spanning tree. Let U(j,k,l) denote the set of MAC addresses in the union . . .” Page 407: Col 1: ¶ [0002]);
It would have been obvious to one with ordinary skill in the art before the effective filing date of the applicant’s invention to incorporate a method of topology discovery for heterogeneous IP networks that uses a layer-2 spanning tree protocol to identify continuity between the MAC addresses associated with the various nodes of the network, as taught by Breitbart, into a method for discovering by a network monitoring apparatus, nodes in a network, and collecting a list of internet protocol (IP) addresses, media access control (MAC) addresses, domain name system (DNS) names, and sysnames for each of the nodes discovered in the network, as taught by Zizlavsky. Such incorporation provides an improvement for the management of assets of a distributed computer communications network by effectively mapping a layer-2 path that can be anchored to the higher level resources of the system.
The combination of Zizlavsky and Breitbart fails to explicitly teach but Dutta teaches
determining individual network resources are in a reference group of network resources (see Dutta ¶¶ [0021-0023] “. . . the network resource can be a network element (e.g., a router, switch, server, etc.). In some implementations, the network resource can be a connection between network elements. In some implementations, the requirements can include bandwidth requirements, throughput requirements, availability requirements, storage capacity requirements, redundancy requirements, load balancing requirements or any other requirement that might be imposed upon a computing device or network connection. In some implementations, the method can include receiving input identifying a new network resource to add to the graph, adding a new graphical element representing the new network resource to the graph and receiving input specifying a service requirement for the new network resource. In some implementations, the graphical elements can include a graphical element that represents a group of network resources. A user can select the graphical element associated with the group of network resources to display a sub-graph having graphical elements representing individual network resources in the group of network resources . . .”)based at least partly on the individual network resources in the reference group of network resources each having non-intermediated communication relationships (e.g. represented by an edge on the graph) with at least a threshold number (e.g. commodity requirement) of network resources (see Dutta Fig. 3A, Fig. 3B, ¶¶ [0046-0047] “ . . . FIG. 3A illustrates an example service provider data center topology. For example, the topology of the service provider data center (or a portion of the data center) can be represented by graph 300. The nodes of graph 300 can correspond to data center resources such as firewall 304, switches 306-310, load balancer 312, and unified computing system (UCS) blades 314-320 with nodes that reflect virtual machines (VM) 330-344. The edges 350-366 (e.g., lines between nodes) represent network connectivity. In some implementations, edges 350-366 can be associated with multi-dimensional edge weights corresponding to commodities (e.g., bandwidth, delay, maximum jitter, buffer sizing, etc.) provided by the connections corresponding to the edges. For example, an edge can represent a connection between network resources (e.g., servers) and the edge weight can represent the bandwidth that can be supported by the connection. The edge weight can be used to specify the capacity of the connection between network resources when solving the maximum flow problem for resource allocation, as described below. FIG. 3B illustrates an example virtual data center request graph 350. The VDC request is represented by request graph 350 which includes a line from the customer premises equipment node 372 followed by a tree like branching at the resource nodes. For example, graph 350 represents the VDC request with nodes representing virtual machines (VMs), virtual network elements and service elements, and the edges representing virtual network connectivity. In particular, graph 350 represents a customer-user VDC request defining a VDC with a firewall 374 followed by a load balancer 376 followed by a group of VMs 378, 380, 382. In this example, graph 350 corresponds to graphical elements 102, 104, 108 and 110 of FIG. 1. The edges of the graph (e.g., 390-398) can be associated with commodity requirements. For example, edges 390-398 can be associated with bandwidth requirements for the connections represented by the edges. These commodity requirements can be used as input to the maximum flow problem for resource allocation, as described below. For example, the commodity requirements can be used to determine the amount of flow that the data center represented by graph 300 should be able to handle. If the flow capacity of graph 300 is greater than or equal to the amount of flow indicated by the commodity requirements of associated with graph 350, then the data center represented by graph 300 has enough resources satisfy the VDC request represented by graph 350 . . . “);
It would have been obvious to one with ordinary skill in the art before the effective filing date of the applicant’s invention to incorporate a method and system directed to graph virtual data centers (VDC) running on service provider data center equipment where the graph is used to identify network elements (e.g. resources and connections) used in one or more VDCs, as taught by Dutta, into a method for discovering by a network monitoring apparatus, nodes in a network, the topology using layer-2 spanning tree protocol to identify continuity between the MAC addresses associated with the various nodes of the network, and collecting a list of internet protocol (IP) addresses, media access control (MAC) addresses, domain name system (DNS) names, and sysnames for each of the nodes discovered in the network, as taught by the combination of Zizlavsky and Breitbart. Such incorporation enables nodes to be mapped into resources and further grouped into components of the system.;
The combination of Zizlavsky, Breitbart, and Dutta fails to explicitly teach but Lee teaches
Identifying (e.g. via a control data plane interface (CDPI) 160) (see Fig. 9, ¶ [0053] “. . . the DCC 910 may compute a virtual path between the DC CE A 931 and DC CE C 931 in a VNT 951 (e.g. VNT 651) and may send a VNE connection setup command for each VNE in the computed virtual path to the NPC 920. When a VNE connection setup command is for a VNE that corresponds to a network node 941, the NPC 920 may convert the VNE connection setup command into a connection command for the network node 941 and may send the connection command to the network node 941 via a CDPI 960 (e.g. CDPI 160). When a VNE connection setup command is for a VNE that corresponds to a sub-network (e.g. a group of network nodes 941) in the transport network 940, the NPC 920 may compute a sub-network path across the sub-network, generate connection commands for the network nodes 941 in the sub-network path, and send the connection commands to the network nodes 941 via a CDPI. . .”) the first network resource(e.g. network node 941) from the reference group (e.g. sub-network) of network resources(e.g. subnetwork of network nodes 1141) (see ¶ [0051] “. . . At step 820, upon receiving the network query request from the DCC, the NPC may estimate network resources and compute paths according to the parameters in the VNS negotiation initiation parameters. At step 830, the NPC may send a VNS response message to the DCC in a form of a VNT. The granularity level of the VNT may depend on the initiation parameters. For example, when the initiation specifies a network endpoint granularity, the VNS response message may comprise resource information (e.g. capacity, cost, latency, etc.) between the DC endpoints, but may not include resources of links (e.g. links 142) or network nodes (e.g. network nodes 141 or 641) along the computed paths. Alternatively, when the initiation specifies a link level granularity, the VNS response message may comprise network resources between the DC endpoints as well as network nodes and links along the computed paths . . .”) for migration to a second networked environment(e.g. migrate network node 1141from DC A 1130 to DC B 1130) (see Fig. 11, ¶ [0055] “ . . . DC A 1130 may be connected to the transport network 1140 via a network node 1 1141 (e.g. network node 141) and may be managed by DCC 1110 (e.g. DCC 210), DCC 1130 may be connected to the transport network 1140 via a network node 3 1141, DC D 1130 may be connected to the transport network 1140 via a network node 8 1141, and DC B 1130 may be connected to the transport network 1140 via a network node 7. In method 1100, a network administrator at DC A 1130 may be monitoring for faults in the DCI network. Upon detection of a fault, for example, at DC C 1130, the network administrator may initiate an alternative network connection between DC A 1130 to DC B 1130. The DCC 1130 may employ CVNI 1150 (e.g. CVNI 250) to request that the NPC 1120 delete the connection between network nodes 1 and 3 1141 and connect network nodes 1 and 7 1141 (e.g. via network resource reservation). The NPC 1120 may respond to the DCC 1110 by sending an acknowledgement for the connection delete request and a reply for the connection request via CVNI 1150. The alternative network connection between DC A 1130 and DC B 1130 may enable data to be migrated from DC A 1130 to the DC B 1130 . . .”);
It would have been obvious to one with ordinary skill in the art before the effective filing date of the applicant’s invention to incorporate a method and system for migrating resources between physical data centers using a data center controller to group inter-connecting network nodes into sub-networks for mapping communication paths for the resources, as taught by Lee, into a method for discovering by a network monitoring apparatus, nodes in a network, the topology using layer-2 spanning tree protocol to identify continuity between the MAC addresses associated with the various nodes of the network, and collecting a list of internet protocol (IP) addresses, media access control (MAC) addresses, domain name system (DNS) names, and sysnames for each of the nodes discovered in the network, and identify a mapping of nodes to resources as taught by the combination of Zizlavsky, Breitbart and Dutta.. Such incorporation provides a migration path for resource allocation incorporating the mapping of the layer-2 path that can be anchored to the higher level resources of the system.
The combination of Zizlavsky, Breitbart, Dutta and Lee fails to explicitly teach but Salle teaches
and performing a migration action based at least partly on the first network resource(e.g. dependency group) (see Salle Fig. 2, ¶ [0037]) “ . . . The migration device (102) further comprises a dependency data set (250) stored within the data storage device (204). The dependency data set (250) is created as a result of the discovery module (240) discovering programs and other program components within the public network A (104). The processor (202) analyzes the results of the discovery module (240) and creates the dependency data set (250). As defined above, the dependency data set (250) is any data set that defines a number of relationships between applications and instances of network resources as deployed within a network . . .” see ¶ [0039] “. . . A dependency data set, as defined above, is any data set that defines a number of relationships between applications and other instances of cloud network resources within a network. The processor (202) analyzes and maps the relationships and dependencies between the applications and instances of network resources within network A (104). In one example, the dependency data set may be represented as a hierarchal tree with a root node symbolizing a root resource, and a number of levels of child nodes symbolizing the relationship of a number of resources and their dependency from the root resource and their dependency with each other. Lines between the root node and the child nodes symbolize the relationships and dependencies between the various elements within network A (104) . . . “(see ¶ [0040] “. . . Turning again to FIG. 3, the migration device (FIG. 2, 102) creates (block 304) a migration plan to migrate a number of applications from the first network to a second network based on the dependency data set. For example, the migration plan may call for the migration of a number of applications from network A (104) to network B (106) of FIG. 1. In this example, network A (104) is a public cloud, and network B is a private cloud service (106) . . .”)
It would have been obvious to one with ordinary skill in the art before the effective filing date of the applicant’s invention to incorporate a method and system for migrating a number of applications from a first network to a second network wherein a dependency data set is created for a first network, and a migration plan is created to migrate a number of applications from the first network to a second network based on the dependency data set, as taught by Salle, into a method and system for discovering by a network monitoring apparatus, nodes in a network, the topology using layer-2 spanning tree protocol to identify continuity between the MAC addresses associated with the various nodes of the network, and collecting a list of internet protocol (IP) addresses, media access control (MAC) addresses, domain name system (DNS) names, and sysnames for each of the nodes discovered in the network, and identify a mapping of nodes to resources for grouping inter-connecting network nodes into sub-networks for mapping communication paths for the resources as taught by the combination of Zizlavsky, Breitbart, Dutta and Lee. Such incorporation enables the grouping of resources to be migrated from one network to another.
In regard to claim 18, the combination of Zizlavsky, Breitbart, Dutta, Lee, and Salle teaches further comprising analyzing data regarding one or more migration scenarios (see Salle ¶ [0042] “. . . The migration device (FIG. 2, 102) migrates (block 306) a number of applications from the first network to the second network based on the migration plan. Thus, the applications which the purchaser of the public cloud services wishes to migrate (block 306) from network A (104) to network B (106) is accomplished according to the migration plan created at block 304. In this manner, application migration is completed. . . “) , wherein identifying the first network resource for migration to the second networked environment is based on a migration scenario (e.g. load balancing policies) of the one or more migration scenarios (see Salle ¶ ¶ [0050-0051] “. . . The migration device (102) then updates (block 420) a number of load balancing policies. The load balancers (127, 147) within the system (100) generally receive in-coming transaction (HTTP) requests and assign those transaction requests to a server (120, 140) within the network (104, 106). Thus, at block 420, the migration device (102) may update the load balancing policies used by the load balancers (127, 147) to include the ability to use the newly cloned load balancer (147) within network B (106) and its associated application components and resources. In connection with block 420 described above, at one point, a global load balancer (242) is created (block 422). The global load balancer (170) comprises a set of policies that define where transaction requests are directed. In this manner, the global load balancer (170) distributes workloads across the system (100). These policies within the global load balancer (170) may be updated in order to redirect traffic from network A (104) to network B (106), or vice versa. In the example described below, the policies within the global load balancer (170) are updated to direct new transaction requests to network B (106) instead of network A (104) due to the migration of applications and application resources from public network A (104) to private network B (106) . . . “).
The motivation to combine Salle with the combination of Zizlavsky, Breitbart, Dutta and Lee is described for the rejection of claim 17. Additionally Salle can implement polices for transactions at the new network environment.
In regard to claim 27, Zizlavsky teaches A system comprising(“. . . methods, systems, and computer programs for node de-duplication of physical nodes monitored by a network monitoring system. . .” ¶ [0002]) :
computer-readable memory storing computer-executable instructions(see ¶ [0053] “. . . the functionality of any of the methods described herein, such as those of FIGS. 3, 4, and 6, may be implemented by software and/or computer program code stored in memory or other computer readable or tangible media. . .”) ; and
one or more processors in communication with the computer-readable memory and configured by the computer-executable instructions (see ¶ [0053] “ . . . and executed by a processor. In other embodiments, the functionality may be performed by hardware, for example through the use of an application specific integrated circuit (ASIC), a programmable gate array (PGA), a field programmable gate array (FPGA), or any other combination of hardware and software. . .”) to at least:
monitor communications (see ¶ [0005] as described for the rejection of claim 17 and included herein) among network resources of a networked environment (see ¶ [0004] as described for the rejection of claim 17 and included herein) to generate monitoring data, wherein the network resources include a plurality of network devices (see ¶ ¶ [0017] as described for the rejection of claim 17 and included herein) and a plurality of applications(see ¶[0035] as described for the rejection of claim 17 and included herein) ;
identify, based at least partly on the monitoring data, media access control addresses (MAC addresses) (see ¶ [0026] as described for the rejection of claim 17 and included herein) corresponding to the plurality of network devices (e.g. discovered nodes)(see ¶ [0028] as described for the rejection of claim 17 and included herein),, wherein the plurality of network devices (see ¶ [0040] as described for the rejection of claim 17 and included herein) and the plurality of applications(see ¶ [0040] as described for the rejection of claim 17 and included herein) distribute the communications among the network resources using the MAC addresses(see ¶ [0039] as described for the rejection of claim 17 and included herein);
Zizlavsky fails to explicitly teach but Breitbart teaches
identify one or more non-intermediated communication relationships based at least partly on the MAC addresses(see Page 403: Col 1: ¶ [0004] as described for the rejection of claim 17 and included herein) , wherein a non-intermediated (e.g. reachable from each element interface) communication relationship (see Page 403: Col 2: ¶ [0002] as described for the rejection of claim 17 and included herein) comprises a first network resource associated with a first MAC address(e.g. a source address in the set which is S1 – see Fig. 6) of the MAC addresses communicatively connected (see Page 404: Col 2: ¶ [0003] as described for the rejection of claim 17 and included herein) to at least a second network resource associated with a second MAC address of the MAC addresses without any network resource(see Fig. 6 – R1, S2)(see Page 405: Col 2: ¶ [0002] as described for the rejection of claim 17 and included herein) , communicatively intermediate the first network resource and the second network resource, associated with a MAC address(see Page 407: Col 1: ¶ [0002] as described for the rejection of claim 17 and included herein) ;
The motivation to combine Breitbart with Zizlavsky is described for the rejection of claim 17 and is incorporated herein.
The combination of Zizlavsky and Breitbart fails to explicitly teach but Dutta teaches
determine individual network resources are in a reference group of network resources (see Dutta ¶¶ [0021-0023] as described for the rejection of claim 17 and included herein) based at least partly on the individual network resources in the reference group of network resources each having non-intermediated communication relationships (e.g. represented by an edge on the graph) with at least a threshold number (e.g. commodity requirement) of network resources (see Dutta Fig. 3A, Fig. 3B, ¶¶ [0046-0047] as described for the rejection of claim 17 and included herein);
The motivation to combine Dutta with the combination of Zizlavsky and Breitbart is described for the rejection of claim 17 and is incorporated herein.
The combination of Zizlavsky, Breitbart, and Dutta fails to explicitly teach but Lee teaches
Identify (e.g. via a control data plane interface (CDPI) 160) (see Fig. 9, ¶ [0053] as described for the rejection of claim 17 and incorporated herein) the first network resource (e.g. network node 941) from the reference group (e.g. sub-network) of network resources (e.g. subnetwork of network nodes 1141) (see ¶ [0051] as described for the rejection of claim 17 and incorporated herein) for migration to a second networked environment (e.g. migrate network node 1141from DC A 1130 to DC B 1130) (see Fig. 11, ¶ [0055] as described for the rejection of claim 17 and incorporated herein);
The motivation to combine Lee with the combination of Zizlavsky, Breitbart and Dutta is described for the rejection of claim 17 and is incorporated herein).
The combination of Zizlavsky, Breitbart, Dutta, and Lee fails to explicitly teach but Salle teaches and perform a migration action based at least partly on the first network resource (e.g. dependency group) (see Salle Fig. 2, ¶ [0037], ¶ [0039], ¶ [0040] as described for the rejection of claim 17 and incorporated herein).
The motivation to combine Salle with the combination of Zizlavsky, Breitbart, Dutta and Lee is described for the rejection of claim 17 and incorporated herein.
In regard to claim 28, the combination of Zizlavsky, Breitbart, Dutta, Lee, and Salle teaches wherein the one or more processors are programmed by further executable instructions to analyze data regarding one or more migration scenarios (see Salle ¶ [0042] as described for the rejection of claim 18 and incorporated herein) , wherein the first network resource is identified for migration to the second networked environment based on a migration scenario (e.g. load balancing policies) of the one or more migration scenarios (see Salle ¶ ¶ [0050-0051] ] as described for the rejection of claim 18 and incorporated herein).
The motivation to combine the references is described for the rejection of claim 18 and is incorporated herein.
Claims 19 – 21, 29 and 30 are rejected under 35 U.S.C. 103 as being unpatentable over Zizlavsky et al. (U.S. 2015/0127806 A1; herein referred to as Zizlavsky) in view of Breitbart et al. (A Topology discovery in heterogeneous IP networks: the NetInventory system. IEEE/ACM Transactions on Networking (TON). 2004 Jun 1;12(3):401-14: herein referred to as Breitbart) in further view of Dutta et al. (U.S. 2013/0055091 A1; herein referred to as Dutta) in further view of Lee et al. (U.S. U.S. 2014/0301192 A1; herein referred to as Lee) in further view of Salle et al. (U.S. 2015/0222702 A1; herein referred to as Salle) as applied to claims 17 - 18 and 27 – 28 in further view of Carlen et al. (U.S. 2014/0298091 A1; herein referred to as Carlen).
In regard to claim 19, , the combination of Zizlavsky, Breitbart, Dutta, Lee and Salle fails to explicitly teach but Carlen teaches further comprising identifying the first network resource (e.g. controller node 107) (see Fig. 1, ¶ ¶ [0038 - 0039] “. . . FIG. 1 depicts an example of a distributed computing system 100 according to one embodiment. Distributed computing system 100 may be organized around a controller node 107, with arrangements in either single controller configuration 100 or multi controller node configuration 101. The single controller configuration is a distributed computing system with a single controller and the multi controller node configuration is a distributed computing system with multiple controllers. In each configuration, controller node 107 may be connected to one or more physical nodes 102 by a connection, such as a combined data and out of band management cable, hereinafter referred to as the cloud cable, or, if a cloud cable is not used, other compatible primary network cables 103 in conjunction with a separate out of band management network cable 104. . .”) as a critical interface (e.g. connecting to main network switch 125) as a critical interface (e.g. connecting to main network switch 125) based at least partly on data communicated via the first network resource (see Fig. 1, ¶ [0045] “ . . . main network switch 125 is the interface by which the controller node 107 communicates with, provisions, and/or manages attached physical nodes 102, communicates with one or more aggregation switches 106, communicates with one or more out of band management switches 105 if a cloud cable is not used, communicates with one or more other controller nodes 107 (e.g., through aggregate switches), as well as the interface by which the attached physical nodes 102 communicate with one another. The resultant network is one example of what may be referred to as a cloud fabric. In one example, the interfaces on the main network switch 125 comprise one or more primary network interfaces 118, one or more management network interfaces 119, one or more serial management interfaces, and one or more universal serial bus interfaces 120. . . “).
It would have been obvious to one with ordinary skill in the art before the effective filing date of the applicant’s invention to incorporate a method and system for failure detection of a container in a controller node where the container includes a service being performed and isolated from other services being performed in other containers on the controller node, wherein the controller node interfaces with many physical nodes to provide said services, as taught by Carlen, into a method and system for discovering by a network monitoring apparatus, nodes in a network, the topology using layer-2 spanning tree protocol to identify continuity between the MAC addresses associated with the various nodes of the network, and collecting a list of internet protocol (IP) addresses, media access control (MAC) addresses, domain name system (DNS) names, and sysnames for each of the nodes discovered in the network, and a mapping of nodes into resource groups such that a migration can be performed using a data center controller to group inter-connecting network nodes into sub-networks for mapping communication paths for the resources wherein the resources are identified in a data dependency set for effective migration to a second network as taught by the combination of Zizlavsky, Breitbart, Dutta Lee and Salle. Such incorporation identifies devices that are critical and most be fault tolerant when providing a migration path for resource allocation incorporating the mapping of the layer-2 path that can be anchored to the higher level resources of the system.
In regard to claim 20, the combination of Zizlavsky, Breitbart, Dutta, Lee, Salle, and Carlen teaches further comprising determining that the first network resource communicates data regarding an operational status of the networked environment (e.g. orchestration service instance 703) (see Carlen Fig. 7, ¶ ¶ [0137 - 0138] “ . . . orchestration service instances 703, 708, 709, and 712 are organized hierarchically, each with a core set of functionality and some additional functionality depending on their place in the hierarchy. The zone's orchestration service instance 703 may present the illusion of a single system and may be responsible for exposing customer-facing functionality, adding and removing controller nodes 107 and physical nodes 102 from zone 702, verifying the health of all nodes, maintaining the global state of the system, backing up any data or state information, and masking failures, for example. Orchestration service instances 708 have functionality that monitor controller node level information, orchestration service instances have functionality that monitor system service 706 information for containers 802, and orchestration service instances 712 have functionality that monitor system service 710 information in physical nodes 102. In this example, the controller's node orchestration service instance 708 manages the controller node 107 including the status of service containers 802. This includes managing the set of controller-specific system services running on it (starting, stopping, restarting, and configuring), verifies their health, backs up any data or state information, and ensures that their capabilities are available in spite of failures. . . .”).
The motivation to combine Carlen with the combination of Zizlavsky, Breitbart, Dutta, Lee, and Salle is described for the rejection of claim 19 and is incorporated herein. Additionally Carlen adds a resource for monitoring of the network.
In regard to claim 21, the combination of Zizlavsky, Breitbart, Dutta, Lee, Salle, and Carlen teaches further comprising identifying the first network resource (e.g. controller node 107) as a critical interface (e.g. connecting to main network switch 125) (see Fig. 1, ¶ [0045] “ . . . main network switch 125 is the interface by which the controller node 107 communicates with, provisions, and/or manages attached physical nodes 102, communicates with one or more aggregation switches 106, communicates with one or more out of band management switches 105 if a cloud cable is not used, communicates with one or more other controller nodes 107 (e.g., through aggregate switches), as well as the interface by which the attached physical nodes 102 communicate with one another. The resultant network is one example of what may be referred to as a cloud fabric. In one example, the interfaces on the main network switch 125 comprise one or more primary network interfaces 118, one or more management network interfaces 119, one or more serial management interfaces, and one or more universal serial bus interfaces 120. . . “) based on the first network resource (e.g. control node 107) being in non-intermediated communication relationships with a threshold number of network resources (number of physical nodes supported by the effective base network throughput) (see Fig. 1, ¶ [0046] “ . . . Primary network interfaces 118 on the main network switch 125 form the network pathways between the controller node 107 and physical nodes 102 carrying the majority of traffic between the devices, including orchestration, cloud service, and client traffic. Example implementations of the primary network interfaces 118 may include RJ-45, small form-factor pluggable, quad small form-factor pluggable, or other network interface. Controller node 107 attaches to physical nodes 102 by means of one or more cloud cable or one or more compatible network cable 103 through the main network switch 125. When more than one cloud cable or compatible network cable is utilized to attach a physical node 102 to controller node 107, such connections may be combined or bonded for either redundancy or increased throughput where the effective base network throughput between controller node 107 and physical node 102 is multiplied by the number of such additional connections. This method of channel bonding permits high throughput configurations. In some embodiments, the primary network interfaces 118 on the controller node's main network switch 125 are configured to utilize an inter-integrated circuit communication protocol management ("I2C") bus present in the cloud cable. This configuration permits primary network traffic, inter-integrated circuit communication protocol management traffic, and inter-integrated circuit communication protocol system traffic to transit through any primary network interface 118 on the main network switch 125 to the attached physical nodes 102. . .”).
The motivation to combine Carlen with the combination of Zizlavsky, Breitbart, Dutta, Lee, and Salle is described for the rejection of claim 19 and is incorporated herein. Additionally Carlen describes a critical interface for a controller node that attaches to physical nodes through non-intermediated connections.
In regard to claim 29, the combination of Zizlavsky, Breitbart, Lee, Dutta, Salle, and Carlen teaches wherein the one or more processors are programmed by further executable instructions to:
identify the first network resource (e.g. controller node 107) (see Carlen Fig. 1, ¶ ¶ [0038 - 0039] as described for the rejection of claim 19 and is incorporated herein) as a critical interface (e.g. connecting to main network switch 125) based at least partly on data communicated via the first network resource (see Carlen Fig. 1, ¶ [0045] as described for the rejection of claim 19 and is incorporated herein) ; and determine that the first network resource communicates data regarding an operational status of the networked environment (e.g. orchestration service instance 703) (see Fig. 7, ¶ ¶ [0137 - 0138] as described for the rejection of claim 20 and is incorporated herein).
The motivation to combine Carlen with the combination of Zizlavsky, Breitbart, Dutta, Lee, and Salle is described for the rejection of claim 19 and is incorporated herein.
In regard to claim 30, the combination of Zizlavsky, Breitbart, Lee, Dutta, Salle, and Carlen teaches wherein the one or more processors are programmed by further executable instructions to identify the first network resource (e.g. controller node 107) as a critical interface (e.g. connecting to main network switch 125) (see Fig. 1, ¶ [0045] as described for the rejection of claim 21 and is incorporated herein) based on the first network resource (e.g. control node 107) being in non-intermediated communication relationships with a threshold number of network resources (number of physical nodes supported by the effective base network throughput) (see Fig. 1, ¶ [0046] as described for the rejection of claim 21 and is incorporated herein).
The motivation to combine Carlen with the combination of Zizlavsky, Breitbart, Dutta, Lee, and Salle is described for the rejection of claim 21 and is incorporated herein.
Claims 22 and 31 are rejected under 35 U.S.C. 103 as being unpatentable over Zizlavsky et al. (U.S. 2015/0127806 A1; herein referred to as Zizlavsky) in view of Breitbart et al. (A Topology discovery in heterogeneous IP networks: the NetInventory system. IEEE/ACM Transactions on Networking (TON). 2004 Jun 1;12(3):401-14: herein referred to as Breitbart) in further view of Dutta et al. (U.S. 2013/0055091 A1; herein referred to as Dutta) in further view of Lee et al. (U.S. U.S. 2014/0301192 A1; herein referred to as Lee) in further view of Salle et al. (U.S. 2015/0222702 A1; herein referred to as Salle) as applied to claims 17 - 18 and 27 – 28 in further view of Wang et al. (U.S. 2014/0229944 A1; herein referred to as Wang).
In regard to claim 22, the combination of Zizlavsky, Breitbart, Lee, Dutta, Salle, and Wang teaches further comprising determining that in a communication link between the first network resource associated with the first MAC address (e.g. source server) and the second network resource associated with the second MAC address (e.g. destination server), there is no network resource, intermediate the first network resource and the second network resource (e.g. located on the same subnet) , associated with any MAC address (see Wang Fig. 6 ¶ [0034] “. . . FIG. 6 illustrates an embodiment of a DC network 600 supporting VM mobility through address-based data routing. Network 600 may be an address-based routing network that may use an entity identifier (e.g. an IP/MAC address) to simultaneously serve dual roles of identifying an entity and a location of the entity within the network. Network 600 may comprise a source server 610, a destination server 620, an L2 routing block 630, and a network storage block 640. Source server 610 may host a VM (e.g. VM 310 of FIG. 3) managed by a hypervisor (e.g. hypervisor 210 of FIG. 2). The VM hosted by source server 610 may be established for migration to destination server 620 while serving a remote client. In order to provide client service continuity during migration, source server 610 and destination server 620 may need to be located on the same subnet to keep the entity identifier of the VM unchanged following migration. L2 routing block 630 may comprise one or more nodes (e.g. routers and/or switches) that may interconnect source server 610, destination server 620, and network storage block 640. Each node may be configured to provide both a data path component and a control path component. The data path component may allow the node to route data packets within network 600 while the control path component may determine the appropriate routing path for the data packet. In network 600, the data path and control path components may operate independently. Network 600 may use an address-based data flow table that may instruct the data path component how and/or where to route a received data packet. If the data path component receives a data packet that the data flow table does not address, the data path component may forward the data packet to the control path component. The control path component may examine the received data packet to determine how and/or where to route the data packet. Based upon its determination, the control path component may update the data flow table and return the data packet to the data path component for routing. Thus, each node of L2 routing block 630 may independently make routing decisions, which may result in decentralized VM mobility control within network 600. In an embodiment, the nodes of L2 routing block 630 may need to be manually provisioned prior to migration of the VM. Prior knowledge of the entity identifiers of the shareable content storage location, the non-shareable content storage location, and destination server 620 may be needed for this manual provisioning. Once the nodes of L2 routing block 630 have been manually provisioned, a hypervisor running on destination server 620 (destination hypervisor) may implement a method of establishing a VM (e.g. method 500). The destination hypervisor may retrieve a VM shareable content file from network storage block 640 and a VM non-shareable content file from source server 610 via L2 routing block 630. The VM shareable content may be installed onto destination server 620 and the destination hypervisor may then use the VM non-shareable content file to boot a migrated VM. Once the migrated VM is ready to serve the remote client, destination server 620 may initiate ARP or ND protocol messaging so the entity identifier for the VM may be updated in each of the data flow tables to reflect the current location of the VM. The migrated VM may then receive data packets at destination server 620 . . .”).
It would have been obvious to one with ordinary skill in the art before the effective filing date of the applicant’s invention to incorporate a method and system for migrating VMs from one server to another server and maintaining MAC and IP addressing after the migration, as taught by Wang, into a method and system for discovering by a network monitoring apparatus, nodes in a network, the topology using layer-2 spanning tree protocol to identify continuity between the MAC addresses associated with the various nodes of the network, and collecting a list of internet protocol (IP) addresses, media access control (MAC) addresses, domain name system (DNS) names, and sysnames for each of the nodes discovered in the network, and a mapping of nodes into resource groups such that a migration can be performed using a data center controller to group inter-connecting network nodes into sub-networks for mapping communication paths for the resources wherein the resources are identified in a data dependency set for effective migration to a second network as taught by the combination of Zizlavsky, Breitbart, Dutta, Lee and Salle. Such incorporation enables the migration to be fully supportive of the VM lifecycle by maintaining the layer 2 and layer 3 relationships.
In regard to claim 31, the combination of Zizlavsky, Breitbart, Lee, Dutta, Salle, and Wang teaches wherein the one or more processors are programmed by further executable instructions to determine that in a communication link between the first network resource associated with the first MAC address (e.g. source server) and the second network resource associated with the second MAC address (e.g. destination server), there is no network resource, intermediate the first network resource and the second network resource (e.g. located on the same subnet), associated with any MAC address (see Wang Fig. 6 ¶ [0034] as described for the rejection of claim 22 and is incorporated herein.
The motivation to combine Wang with the combination of Zizlavsky, Breitbart, Dutta, Lee, and Salle is described for the rejection of claim 22 and is incorporated herein.
Claims 23 and 32 are rejected under 35 U.S.C. 103 as being unpatentable over Zizlavsky et al. (U.S. 2015/0127806 A1; herein referred to as Zizlavsky) in view of Breitbart et al. (A Topology discovery in heterogeneous IP networks: the NetInventory system. IEEE/ACM Transactions on Networking (TON). 2004 Jun 1;12(3):401-14: herein referred to as Breitbart) in further view of Dutta et al. (U.S. 2013/0055091 A1; herein referred to as Dutta) in further view of Lee et al. (U.S. U.S. 2014/0301192 A1; herein referred to as Lee) in further view of Salle et al. (U.S. 2015/0222702 A1; herein referred to as Salle)as applied to claims 17 – 18 and 27 - 28 in further view of Dave et al. (U.S. 2014/0365662 A1; herein referred to as Dave).
In regard to claim 23, the combination of Zizlavsky, Breitbart, Lee, Dutta, Salle, and Dave teaches further comprising displaying a user interface comprising information regarding the reference group of network resources (see Dave Fig. 17 ¶ [0117] “. . . FIG. 17 is an illustrative view showing the IT architecture page of FIG. 14 with a resource group configuration action menu 600 displayed. The resource group configuration actions menu 600 is selectively displayable during a particular IT architecture status (e.g., planning). Examples of means for causing the resource group configuration actions menu 600 to be displayed during the particular IT architecture status include, but are not limited to, right-button clicking on a particular resource group icon, selection via the Actions 586, or the like. The resource group configuration actions menu 600 includes a plurality of selections for allowing resource group configuration actions to be implemented. Examples of the resource group configuration actions include, but are not limited to, an action for adding a resource group, an action for adding a resource/service, an action for adding a managed group, an action for making a copy of a resource group, resource/service or the like, an action for viewing services, an action for viewing activity logs, an action for managing SSH (secure shell) key pairs, an action for managing public IP's, an action for provisioning resource group changes, and an action for enabling/disabling a VPN connection . . .”).
It would have been obvious to one with ordinary skill in the art before the effective filing date of the applicant’s invention to incorporate a method and system for categorizing virtual machines (VM) within resource groups wherein the configuration of each VM can be displayed, as taught by Dave, into a method and system for discovering by a network monitoring apparatus, nodes in a network, the topology using layer-2 spanning tree protocol to identify continuity between the MAC addresses associated with the various nodes of the network, and collecting a list of internet protocol (IP) addresses, media access control (MAC) addresses, domain name system (DNS) names, and sysnames for each of the nodes discovered in the network, and a mapping of nodes into resource groups such that a migration can be performed using a data center controller to group inter-connecting network nodes into sub-networks for mapping communication paths for the resources wherein the resources are identified in a data dependency set for effective migration to a second network as taught by the combination of Zizlavsky, Breitbart, Dutta, Lee and Salle. Such incorporation enables the resources that have been grouped to be identified by an operator to facilitate the management of the migration of said resources.
In regard to claim 32, the combination of Zizlavsky, Breitbart, Lee, Dutta, Salle, and Dave teaches wherein the one or more processors are programmed by further executable instructions to display a user interface comprising information regarding the reference group of network resources (see Dave Fig. 17 ¶ [0117] as described for the rejection of claim 23 and is incorporated herein).
The motivation to combine Dave with the combination of Zizlavsky, Breitbart, Dutta, Lee, and Salle is described for the rejection of claim 23 and is incorporated herein.
Claims 24 – 26 and 33 -35 are rejected under 35 U.S.C. 103 as being unpatentable over Zizlavsky et al. (U.S. 2015/0127806 A1; herein referred to as Zizlavsky) in view of Breitbart et al. (A Topology discovery in heterogeneous IP networks: the NetInventory system. IEEE/ACM Transactions on Networking (TON). 2004 Jun 1;12(3):401-14: herein referred to as Breitbart) in further view of Dutta et al. (U.S. 2013/0055091 A1; herein referred to as Dutta) in further view of Lee et al. (U.S. U.S. 2014/0301192 A1; herein referred to as Lee) in further view of Salle et al. (U.S. 2015/0222702 A1; herein referred to as Salle)as applied to claims 17 – 18 and 27 - 28 in further view of Bhattacharya et al. (U.S. 2014/0359128 A1; herein referred to as Bhattacharya).
In regard to claim 24, the combination of Zizlavsky, Breitbart, Dutta, Lee, Salle, and Bhattacharya teaches further comprising: assessing traffic analytics data relative to a selection of migration scenarios (see Bhattacharya ¶ [0024] “. . the migration broker framework assesses and matches an optimal migration service and/or service combination based on selected metrics and/or benchmarking data. An example of metrics used by the migration broker includes the ability of a vendor migration service to migrate some middleware (and potentially the data or applications managed thereby) such as DB2 or Websphere without significant remediation . . .”) ; and generating a migration consideration set (see Fig. 1 set of registered migration services 122) comprising plurality of cloud service providers (see Bhattacharya ¶ [0017] “. . . an aspect of the present invention includes techniques for providing migration broker capabilities as a service. Additionally, at least one embodiment of the invention includes a migration broker framework capable for use by a vendor to plug-in an individual migration technology. Such a framework can be used to coordinate migration processes among migration service requesters, migration service providers and target clouds . . .”) capable of performing a network computing task in lieu of the network computing task being performed by the networked environment (see Bhattacharya ¶ [0023] “. . . Step 112 includes pre-qualifying the application for migration. Pre-qualifying includes using the meta information about the underlying application for comparison with the features and capabilities of the target cloud in order to determine if the underlying application does or does not require resources beyond the constraints of the target cloud. Once the application is pre-qualified, step 114 includes matching the application to a migration service from the set of registered migration services 122. In at least one embodiment of the invention, the migration broker framework recommends the most suitable back-end migration service and/or migration services combination for the given application. Such an embodiment includes identifying all capable migration services and/or service combinations to complete the application migration based on an analysis of the application specifications and migration requirements . . .”).
It would have been obvious to one with ordinary skill in the art before the effective filing date of the applicant’s invention to incorporate a method and system for coordinating application migration processes include selecting at least one migration service for an application based on analysis of application information and information pertaining to multiple migration services, creating a migration plan to migrate the application to a target cloud based on the at least one selected migration service, and executing the migration plan, utilizing the at least one selected migration service, to migrate the application to the target cloud, as taught by Bhattacharya, into a method and system for discovering by a network monitoring apparatus, nodes in a network, the topology using layer-2 spanning tree protocol to identify continuity between the MAC addresses associated with the various nodes of the network, and collecting a list of internet protocol (IP) addresses, media access control (MAC) addresses, domain name system (DNS) names, and sysnames for each of the nodes discovered in the network, and a mapping of nodes into resource groups such that a migration can be performed using a data center controller to group inter-connecting network nodes into sub-networks for mapping communication paths for the resources wherein the resources are identified in a data dependency set for effective migration to a second network as taught by the combination of Zizlavsky, Breitbart, Dutta, Lee and Salle. Such incorporation enables a migration plan to be evaluated on the performance of an application being migrated.
In regard to claim 25, the combination of Zizlavsky, Breitbart, Dutta, Lee, Salle, and Bhattacharya teaches wherein performing the migration action comprises displaying a user interface comprising information regarding the migration consideration set (see Bhattacharya ¶ [0022] “. . . FIG. 1 is a diagram illustrating a migration process via a migration broker, according to an embodiment of the present invention. By way of illustration, FIG. 1 depicts an application owner 102, an existing application deployment 104, registered migration services 122, a monitoring and reporting component 106 and migrated application 124. As illustrated in FIG. 1, the application owner 102 creates a migration order in step 108. Step 110 includes discovering application information from the existing application deployment 104. Such a step can be performed, for example, by the migration requester filling out forms provided by the migration broker API. Alternatively, the discovery process in step 110 can also be achieved by a requester downloading, from the migration broker server, a discovery software agent to be installed in each of the servers of the underlying application. Such a software agent collects information about the application and its components and passes such information to the migration broker to create the meta information for the underlying application (application vector.) By way of example, a client can upload information from the existing application deployment environment via a self-service portal to specify information such as application name, server uniform resource locators (URLs) and/or internet protocols (IPs), and an application profile in extensible markup language (XML) format. The client can also download and install the discovery agent from said migration broker portal to collect and send to the migration broker system the same information. . . “).
The motivation to combine Bhattacharya with the combination of Zizlavsky, Breitbart, Dutta, Lee, and Salle is described for the rejection of claim 24 and is incorporated herein. Additionally Bhattacharya provides a user with an interface for selecting and evaluating migration plans amongst the service providers.
In regard to claim 26, the combination of Zizlavsky, Breitbart, Dutta, Lee, Salle, and Bhattacharya teaches wherein performing the migration action comprises causing migration of the network computing task to a cloud service provider of the plurality of cloud service providers(see Bhattacharya ¶ [0034] “. . . the migration service broker 208 includes a migration technology analysis engine 240, a migration task scheduler and coordination component 250, a migration task fail-over handler component 260, and a migration measurement collector component 270. When the migration service matcher 230 selects one or more vendor migration services to perform migration for a source application, the service matcher 230 employs the migration task scheduler and coordinator 250 to formulate the migration plan and to coordinate the migration process integrating potentially multiple vendor migration services. When one vendor migration service fails to migrate its assigned component, the migration task fail-over handler component 260 can devise and schedule a new migration plan with an alternative vendor migration service for the failed component. Additionally, remediation tasks can be coordinated if the migration is successful, and/or failure causes can be analyzed and a next step can be recommended . . . “) , wherein the cloud service provider performs the network computing task in lieu of the network computing task being performed by the networked environment (see Bhattacharya ¶ [0035] “ . . . the migration service broker 208 includes a vendor migration performance data database 280 and an application migration pattern and interactive variables database 290. The vendor migration performance data database 280 maintains meta data for vendor migration services, which can facilitate at least one embodiment of the invention to create a capability profile with feature details for each migration service, as well as to tracks and maintain historical and statistical data for services performed by migration services. The migration technology analysis engine 240 monitors the migration tasks performed by the vendor migration services and records the results in the vendor migration performance database 280. The migration measurement collector 270 accesses result data of the vendor migration services from the vendor migration performance database 280 and computes vendor migration performance metrics to store back to the vendor migration performance database 280. The performance metrics are then used by the vendor matcher 232 processor to select the vendor migration services for a source application. . .”).
The motivation to combine Bhattacharya with the combination of Zizlavsky, Breitbart, Dutta, Lee, and Salle is described for the rejection of claim 24 and is incorporated herein. Additionally Bhattacharya provides the migration operation and performance metrics to evaluate the migration.
In regard to claim 33, the combination of Zizlavsky, Breitbart, Dutta, Lee, Salle, and Bhattacharya teaches wherein the one or more processors are programmed by further executable instructions to: assess traffic analytics data relative to a selection of migration scenarios (see ¶ [0024] as described for the rejection of claim 24 and is incorporated herein); and generate a migration consideration set (see Fig. 1 set of registered migration services 122) comprising plurality of cloud service providers (see ¶ [0017] as described for the rejection of claim 24 and is incorporated herein) capable of performing a network computing task in lieu of the network computing task being performed by the networked environment (see ¶ [0023] as described for the rejection of claim 24 and is incorporated herein).
The motivation to combine Bhattacharya with the combination of Zizlavsky, Breitbart, Dutta, Lee, and Salle is described for the rejection of claim 24 and is incorporated herein.
In regard to claim 34, the combination of Zizlavsky, Breitbart, Dutta, Lee, Salle, and Bhattacharya teaches wherein to perform the migration action, the one or more processors are programmed by further executable instructions to display a user interface comprising information regarding the migration consideration set (see Bhattacharya ¶ [0022] as described for the rejection of claim 25 and is incorporated herein).
The motivation to combine Bhattacharya with the combination of Zizlavsky, Breitbart, Dutta, Lee, and Salle is described for the rejection of claim 25 and is incorporated herein.
In regard to claim 35, the combination of Zizlavsky, Breitbart, Dutta, Lee, Salle, and Bhattacharya teaches wherein to perform the migration action, the one or more processors are programmed by further executable instructions to cause migration of the network computing task to a cloud service provider of the plurality of cloud service providers (see Bhattacharya ¶ [0034] as described for the rejection of claim 26 and is incorporated herein), wherein the cloud service provider performs the network computing task in lieu of the network computing task being performed by the networked environment (see Bhattacharya ¶ [0035] as described for the rejection of claim 26 and is incorporated herein).
The motivation to combine Bhattacharya with the combination of Zizlavsky, Breitbart, Dutta, Lee, and Salle is described for the rejection of claim 26 and is incorporated herein.
Claim 36 is rejected under 35 U.S.C. 103 as being unpatentable over Zizlavsky et al. (U.S. 2015/0127806 A1; herein referred to as Zizlavsky) in view of Breitbart et al. (A Topology discovery in heterogeneous IP networks: the NetInventory system. IEEE/ACM Transactions on Networking (TON). 2004 Jun 1;12(3):401-14: herein referred to as Breitbart) in further view of Dutta et al. (U.S. 2013/0055091 A1; herein referred to as Dutta in further view of Lee et al. (U.S. U.S. 2014/0301192 A1; herein referred to as Lee) in further view of Salle et al. (U.S. 2015/0222702 A1; herein referred to as Salle)as applied to claims 17 – 18 and 27 - 28 in further view of Gottimukkala et al. (U.S.2010/0005505 A1; herein referred to as Gottimukkala).
In regard to claim 36, the combination of Zizlavsky, Breitbart, Dutta, Lee, Salle, and Gottimukkala teaches wherein the reference group of network resources comprises a hierarchical listing of network resources (see Gottimukkala ¶¶ [0026 -0028]” . . . Operatively, the categorizing module 206 categorizes network resources in the service landscape instance 104 based on a particular service landscape model. According to a particular embodiment, the categorizing module 206 categorizes the network resources according to a role each network resource performs in the service landscape instance and according to a tier occupied by the network resource in a multi-tier hierarchical topology determined based upon the service landscape model. Thus, if the network resources of the service landscape instance 104 comprise, for example, an application server, a File Transfer Protocol (FTP) server, and database server, each server has a definite role for performing a unique function within the service landscape instance 104 The categorizing module 206 thus categorizes the application server, FTP server, and database server according to that server's particular role or function. According to this embodiment, because the service landscape model can be used to construct a multi-tier hierarchical topology, the categorizing module 206 additionally categorizes the network resources of the service landscape instance 104 according to the particular tier each occupies in the multi-tier hierarchy. One tier, for example, can correspond to a so-called demilitarized zone (DMZ), a physical or logical sub-network that contains and exposes external services of the service landscape instance to a larger, albeit not trusted, network such as the Internet. Other tiers can include an application server tier and an enterprise information system (EIS) tier. Regardless of the particular tier to which a distinct network resource corresponds, the categorizing module 206 categorizes the network resource according to the specification of the service landscape model. According to still another embodiment, the categorizing module 206 can further categorize each network resource of the service landscape instance 104 based on an IP address and port corresponding to the particular network resource. More generally, the service landscape model, which can be maintained in electronic memory of the system 102, dictates and describes different categories of the various resources of the service landscape instance 104 that are permitted to be in each tier of the hierarchical topology. The service landscape model also can describe which network resources in the service landscape instance 104 are permitted to communicate with other resources as well as the security requirements for connectivity. Thus, based on any combination of these categories and attributes, as dictated by the service landscape model, the categorizing module 206 categorizes each of the network resources comprising the service landscape instance 104. . . . “).
It would have been obvious to one with ordinary skill in the art before the effective filing date of the applicant’s invention to incorporate a method and system for updating network security policy rules when network resources are provisioned in a service landscape instance which comprises categorizing network resources in a service landscape instance based on a hierarchal service landscape model, as taught by Gottimukkala, into a method and system for discovering by a network monitoring apparatus, nodes in a network, the topology using layer-2 spanning tree protocol to identify continuity between the MAC addresses associated with the various nodes of the network, and collecting a list of internet protocol (IP) addresses, media access control (MAC) addresses, domain name system (DNS) names, and sysnames for each of the nodes discovered in the network, and a mapping of nodes into resource groups such that a migration can be performed using a data center controller to group inter-connecting network nodes into sub-networks for mapping communication paths for the resources wherein the resources are identified in a data dependency set for effective migration to a second network as taught by the combination of Zizlavsky, Breitbart, Dutta, Lee and Salle. Such incorporation enables the migration of resources to be more efficient by grouping resources hierarchal.
Conclusion
There are prior art made of record which are not relied upon but are considered pertinent to applicant’s disclosure. They are listed on the PTO-892 accompanying this action
THIS ACTION IS MADE FINAL. 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 JAMES N FIORILLO whose telephone number is (571)272-9909. The examiner can normally be reached on 7:30 - 5 PM Mon - Fri..
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, John A. Follansbee can be reached on 571-272-3964. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
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). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/JAMES N FIORILLO/Primary Examiner, Art Unit 2444
Prosecution Insights