Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Arguments
Applicant’s arguments with respect to claim(s) 1-20 have been considered but are moot in view of new ground(s) of rejection.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-4, and 6-19 are rejected under 35 U.S.C. 103 as being unpatentable over Akers et al. “Akers” (US 10021196 B1) in view of Panchal et al. “Panchal” (US 10819630 B1).
As for Claims 1 and 18, Akers discloses
a method (fig.9) comprising:
providing an indication of availability of a producer workload (Svc1 120 – fig.1)(i.e., in response to a discovery request from C2, an indication that Svc1 is accessible is provided)(910 – fig.9; Col.20 lines 58-62), located on a first virtual private cloud (VPC)(110A – fig.1) or being a cloud application programming interface (API) on a first cloud (i.e., a client C1(producer workload) on whose behalf a particular isolated virtual network IVN1(first cloud) has been established may implement a service Svc1 in IVN1) (col.4 lines 35-38) as a virtual private endpoint (Svc1-PPE)(150A – fig.1) to a consumer workload (i.e., C2; 125B – fig.1) in a second VPC (110C – fig. 1) on a second cloud, that is different from the first cloud (in order to facilitate access to services across IVN boundaries, in some embodiments a provider network operator may support the establishment of private addresses (private pathway endpoints i.e. virtual private endpoints) for customer-implemented services (consumer workload). In such embodiments, a private address assigned to a service implemented at one IVN may enable an application running within a second IVN to send service requests to (and receive responses from) the service without having to expose the second IVN to the public Internet and without traversing network links outside the provider network) (col 4 lines 57-67),
receiving, from the consumer workload (i.e., C2) based at least in part on the indication of availability (i.e., after Svc1 indicates accessibility), a request for access to the producer workload (i.e., C2 sends request to C1 to establish connectivity between IVN2 and Svc1) (913 – fig. 9; Col. 21, lines 5-24);
and establishing, based at least in part on the request (i.e., in response to establish connectivity between C2 and C1, a private pathway is established), the producer workload as the VPE (i.e. a private pathway endpoint (PPE) 150(Svc1-PPE; 150A – fig.1) may be assigned to one or more resources of Svc1 implementation
fleet 120(Svc1 implementation fleet 120) for each Svc1-consuming IVN.)(col.9 lines 7-39) in the second VPC via a link (162B – fig.1) between the first cloud and the second cloud (i.e., After the requisite configuration changes are made, packets containing Svc1 service requests from IVN2 may be transmitted to IVN1 using private pathways of the provider network, and similarly service responses may be transmitted from IVN1 to IVN2 using private pathways) (916 – fig. 9; Col. 21 lines 25-40).
Akers fails to disclose, wherein the first cloud is provided by a first cloud provider and the second cloud is provided by a second cloud provider that is different from the first cloud provider.
In an analogous art, Panchal discloses,
wherein the first cloud is provided by a first cloud provider and the second cloud is provided by a second cloud provider that is different from the first cloud provider (i.e. Multi-cloud linking by the cloud exchange enables cloud customers to request a direct connection between multiple cloud services providers via the cloud exchange that bypasses the public Internet. Such a direct connection between multiple service providers can allow customers to transfer large amounts of data between the cloud service providers, or obtain a mix of services from different cloud service providers in a “service mesh,” and may improve performance.)(Col.1 Line 56 – Col.2 Line 5)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date to modify Akers to include wherein the first cloud is provided by a first cloud provider and the second cloud is provided by a second cloud provider that is different from the first cloud provider as taught in Panchal for the benefit of increasing the security and privacy of the connections. (Panchal, Col.2 lines 3-5)
As for Claim 2, Akers in view of Panchal discloses, in particular Akers teaches,
wherein the producer workload (i.e., Svc1) comprises one or more of a virtual machine instance, a service (i.e. a client may implement service Svc1 in IVN1)(col.4 lines 35-40), or an application hosted on the first cloud.
Motivation to combine is similar to that of Claim 1.
As for Claim 3, Akers in view of Panchal discloses, in particular Akers teaches,
wherein establishing the producer workload as the VPE (i.e. Svc1-PPE) in the second VPC comprises: establishing a surrogate (i.e. a respective pathway endpoint (150B – fig.1 ) may be assigned to one or more resources of Svc1 implementation fleet 120 for each Svc1-consuming IVN) of the producer workload as the VPE in the second VPC (col. 9 lines 14-19).
Motivation to combine is similar to that of Claim 1.
As for Claim 4, Akers in view of Panchal discloses, in particular Akers teaches,
further comprising: receiving, before providing the indication of availability of the producer workload, an indication via the first VPC that the producer workload is available (i.e., in response to a discovery request from C2, an indication that Svc1 is accessible is provided)(910 – fig.9; Col.20 lines 58-62)
Motivation to combine is similar to that of Claim 1.
As for Claim 6, Akers in view of Panchal discloses, in particular Akers teaches,
wherein establishing the producer workload as the VPE in the second VPC comprises one or more of: establishing the link with a control plane and a data plane between the first cloud and the second cloud; establishing a service level objective (SLO) of the link; establishing, in the second VPC, a cross-cloud VPE associated with the producer workload (i.e. Svc1-PPE; In at least one embodiment in which cross-IVN access to Svc1 is to be provided to service consuming clients at several different IVNs such as IVN2,IVN3, and IVN4, a respective private address for Svc1 may be provided for each service-consuming IVN in which private addresses are used to create private path endpoints)(col.6 lines 50-53)
Motivation to combine is similar to that of Claim 1.
As for Claim 7, Akers in view of Panchal discloses, in particular Akers teaches,
wherein communication between the producer workload and the consumer workload is based at least in part on the service level objective (SLO) of the link (i.e. services can be selected from the layout region (popular service categories; 710 - fig. 7) within the service marketplace based on link quality of service metrics such as performance levels (e.g., throughput or latency of service requests)(col.18 lines 64 -67 & col.19 lines 1-5 )
Motivation to combine is similar to that of Claim 1.
As for Claim 8, Akers in view of Panchal discloses, in particular Akers teaches,
wherein one or more of the SLO or the routing configuration (i.e. a metrics analyzer may determine using a service public to private address mapping that a producer workload using public addresses can also be using private addresses. If such compute instances are found, they may be designated as public-to-private switch candidates. If the client (and the service owner) agree, the required configuration changes may be made, so that for example subsequent Svc1-related request/response traffic between compute instance 512 (and/or other instances in IVN 510B) and the service implementation fleet 530 flows using a private address 560 assigned to Svc1)(col.16 lines 27-46) is based at least in part on: the producer workload(i.e. A programmatic indication that it is possible to start using a private IP address for Svc1 instead of the public IP address may be provided to the client on whose behalf IVN 510B is established)(col.16 lines 27-46), the consumer workload, or a pairing of the consumer workload and the producer workload.
Motivation to combine is similar to that of Claim 1.
As for Claim 9, Akers in view of Panchal discloses, in particular Akers teaches,
wherein the link between the first cloud and the second cloud comprises one or more of: the internet (i.e. If Svc1 only allows requests to be submitted via a public IP address, one way to establish connectivity between IVN2 and IVN1 may involve assigning one or more public IP addresses to resources within IVN2 (and/or setting up an Internet-accessible gateway for IVN2)(col.4 lines 40-44), one or more access networks, an enterprise network, a virtual private network(i.e. Another way to establish connectivity between compute instances running in IVN2 and resources of a publicly-accessible service may be to first establish a VPN (virtual private network) connection between IVN2 and an external network owned by C2, and then send traffic indirectly from IVN2 to Svc1 via the customer network)(col.4 lines 46-51), a collocation device, or a tunneling network (i.e. A tunneling protocol may be used in some embodiments to encapsulate packets of traffic originating at the service consumer's IVN for transmission to the service implementer's IVN)(col.5 lines 13-16).
Motivation to combine is similar to that of Claim 1.
As for Claim 10, Akers in view of Panchal discloses, in particular Akers teaches,
further comprising: identifying performance of the link between the first cloud and the second cloud (i.e. metrics may be collected on a per-IP-address basis with respect to outgoing and/or incoming traffic at various resources of the provider network (e.g., for network management, auditing and/or billing purposes) regardless of whether the traffic is associated with a privately-accessed client-owned service or not)(col.7 lines 30-55);
and modifying link between the first cloud and the second cloud based at least in part on the performance (i.e. such metrics may be usable (e.g., by control-plane components of the provider network) to identify opportunities for service consumers to switch from using public addresses to using private addresses)(col.7 lines 30-55).
Motivation to combine is similar to that of Claim 1.
As for Claim 11, Akers in view of Panchal discloses, in particular Akers teaches,
further comprising:
identifying performance of the link between the first cloud and the second cloud(i.e. metrics are collected on a per-IP-address basis with respect to outgoing and incoming traffic in order to identify opportunities for service consumers to switch from using public addresses to private addresses) (Col. 7, lines 30-55 & Col. 10, lines 26-35);
and closing the link between the first cloud and the second cloud based at least in part on the performance (i.e. control plane components may programmatically indicate to C2 that access to Svc1 is also available via a private address. An interface may be provided to close the existing public link and use the private link instead to achieve better performance.)(col.7 lines 30-55).
Motivation to combine is similar to that of Claim 1.
As for Claim 12, Akers in view of Panchal discloses, in particular Akers teaches,
further comprising publishing the indication of availability of the producer workload as the VPE to multiple consumer workloads on multiple VPCs (i.e. Svc1 may be made accessible via a marketplace or “published” interface in some embodiments after it is registered. In at least some embodiments, one or more services that are implemented using provider network resources which are not part of IVNs, but can nevertheless be reached via private networking pathways from service consumers within IVNs, may also be added to the database of privately-accessible services)(col.5 lines 62-67).
Motivation to combine is similar to that of Claim 1.
As for Claim 13, Akers in view of Panchal discloses, in particular Akers teaches,
wherein establishing the producer workload as the VPE in the second VPC comprises: establishing a link between the first VPC and the second VPC, the link including a control plane (i.e. control-plane components of the provider network may monitor the traffic, e.g., at a per-IP address level, and may provide metrics pertaining to the use of Svc1 to C1 and/or C2 (element 919) in various embodiments.)(col.21 lines 25-40) associated with parameters of the link and a data plane associated with communications between the consumer workload and the producer workload (i.e. After the requisite configuration changes are made, packets containing Svc1 service requests from IVN2 may be transmitted to IVN1 using private pathways of the provider network, and similarly service responses may be transmitted from IVN1 to IVN2 using private pathways (element 916). The packets may be transmitted by data-plane components of the provider network in at least some embodiments)(col.21 lines 25-40).
Motivation to combine is similar to that of Claim 1.
As for Claim 14, Akers in view of Panchal discloses, in particular Akers teaches,
A computer program product comprising:
one or more computer readable storage media (i.e. a computer-accessible medium may include non-transitory storage media or memory media such as magnetic or optical media, e.g., disk or DVD/CD coupled to computing device 9000 )(col.23 lines 44-51), and program instructions collectively stored on the one or more computer readable storage media (i.e. In some embodiments, system memory 9020 may be one embodiment of a computer-accessible medium configured to store program instructions and data)(col. 23 lines 37-40), the program instructions comprising:
program instructions to provide an indication of availability of a producer workload (Svc1 120 – fig.1)(i.e., in response to a discovery request from C2, an indication that Svc1 is accessible is provided)(910 – fig.9; Col.20 lines 58-62), located on a first virtual private cloud (VPC)(110A – fig.1) or being a cloud application programming interface (API) on a first cloud (i.e., a client C1(producer workload) on whose behalf a particular isolated virtual network IVN1(first cloud) has been established may implement a service Svc1 in IVN1) (col.4 lines 35-38), as a virtual private endpoint (Svc1-PPE)(150A – fig.1) to a consumer workload (i.e., C2; 125B – fig.1) in a second VPC (110C – fig. 1) on a second cloud, that is different from the first cloud (in order to facilitate access to services across IVN boundaries, in some embodiments a provider network operator may support the establishment of private addresses (private pathway endpoints i.e. virtual private endpoints) for customer-implemented services (consumer workload). In such embodiments, a private address assigned to a service implemented at one IVN may enable an application running within a second IVN to send service requests to (and receive responses from) the service without having to expose the second IVN to the public Internet and without traversing network links outside the provider network) (col 4 lines 57-67);
program instructions to receive from the consumer workload (i.e., C2) and based at least in part on the indication of availability (i.e., after Svc1 indicates accessibility), a request for access to the producer workload(i.e., C2 sends request to C1 to establish connectivity between IVN2 and Svc1) (913 – fig. 9; Col. 21, lines 5-24);
program instructions to identify, based at least in part on the request, a service level objective (SLO) for a link between the producer workload and the consumer workload(i.e. In one embodiment, searching for services based at least in part on quality of service metrics such as performance levels (e.g., throughput or latency of service requests), availability levels, and the like may also be supported)(col.18 line 58 to col. 19 line 4); and
program instructions to establish, based at least in part on the SLO, the producer workload as the VPE (i.e. a private pathway endpoint (PPE) 150(Svc1-PPE; 150A – fig.1) may be assigned to one or more resources of Svc1 implementation fleet 120(Svc1 implementation fleet 120) for each Svc1-consuming IVN.)(col.9 lines 7-39) in the second VPC via the link between the first cloud and the second cloud(i.e., After the requisite configuration changes are made, packets containing Svc1 service requests from IVN2 may be transmitted to IVN1 using private pathways of the provider network, and similarly service responses may be transmitted from IVN1 to IVN2 using private pathways) (916 – fig. 9; Col. 21 lines 25-40).
Akers fails to disclose wherein the first cloud is provided by a first cloud provider and the second cloud is provided by a second cloud provider that is different from the first cloud provider.
In an analogous art, Panchal discloses,
wherein the first cloud is provided by a first cloud provider and the second cloud is provided by a second cloud provider that is different from the first cloud provider (i.e. Multi-cloud linking by the cloud exchange enables cloud customers to request a direct connection between multiple cloud services providers via the cloud exchange that bypasses the public Internet. Such a direct connection between multiple service providers can allow customers to transfer large amounts of data between the cloud service providers, or obtain a mix of services from different cloud service providers in a “service mesh,” and may improve performance.)(Col.1 Line 62 – Col.2 Line 3));
Motivation to combine is similar to that of Claim 1.
As for Claim 15, Akers in view of Panchal discloses, in particular Akers teaches,
wherein the SLO is associated with one or more of: a data rate of communications between the producer workload and the consumer workload, a latency of the communications between the producer workload and the consumer workload (i.e. In one embodiment, searching for services based at least in part on quality of service metrics such as performance levels (e.g., throughput or latency of service requests), availability levels, and the like may also be supported)(col.18 line 58 to col. 19 line 4); privacy configuration of the communications between the producer workload and the consumer workload, or a cost of the communications between the producer workload and the consumer workload.
Motivation to combine is similar to that of Claim 1.
As for Claim 16, Akers in view of Panchal discloses, in particular Akers teaches,
wherein, to establish the producer workload as the VPE in the second VPC, the program instructions comprise:
program instructions establish the link with a control plane and a data plane between the first cloud and the second cloud(i.e. establishing a link between the first and second IVN’s with both control plane and data plane functionality, where control plane components of the provider network detect service requests and programmatically indicate use of the private path, while service requests flow between the two via private network paths)(col.7 lines 11-24);
program instructions to establish a service level objective (SLO) of the link;
program instructions to establish, in the second VPC, a cross-cloud VPE associated with the producer workload(i.e. a respective private address for svc1 may be provided for each service consuming ivn)(col.6 lines 57-67);
program instructions to establish a domain name system in the second VPC that resolves a consumer service name of the producer workload to a local address of the VPC; or
program instructions to establish a routing configuration for the link.
Motivation to combine is similar to that of Claim 1.
As for Claim 17, Akers in view of Panchal discloses, in particular Akers teaches,
wherein the SLO is based at least in part on one or more of: the producer workload, the consumer workload, or a pairing of the consumer workload and the producer workload (i.e. In one embodiment, searching for services based at least in part on quality of service metrics such as performance levels (e.g., throughput or latency of service requests), availability levels, and the like may also be supported)(col.18, line 67 to col. 19, line 4).
Motivation to combine is similar to that of Claim 1.
As for Claim 19, Akers in view of Panchal discloses, in particular Akers teaches,
wherein the one or more devices comprise: a virtual machine associated with the producer workload (i.e. a virtual computing service implemented at a provider network may enable clients to utilize one or more guest virtual machines (which may be referred to herein as “compute instances” or simply as “instances”) for their applications, with one or more compute instances being executed on an instance host of a large fleet of instance hosts )(col.3 lines 5-16), an application programming interface (API) server, or a collocation facility.
Motivation to combine is similar to that of Claim 1.
Claims 5 and 20, are rejected under 35 U.S.C. 103 as being unpatentable over Akers in view of Panchal, as applied to Claim 1 above, and in further view of Benardos et al. “Benardos” (US 20250247355 A1).
As for Claim 5, Akers in view of Panchal fails to disclose,
identifying one or more of the consumer workload or the second VPC for providing the indication of availability of the producer workload before providing the indication of availability of the producer workload.
In an analogous art, Benardos discloses
identifying one or more of the consumer workload (i.e. uses port based routing to identify which specific consumer workload is requesting the availability from the target producer workload; 110 – fig.1)( ¶ 0035 -0036) or the second VPC for providing the indication of availability of the producer workload (i.e. The consumer endpoint maps to a service attachment which forwards the service discovery request to the L4-internal load balancer (LB) forwarding rule and backend service.)( ¶ 0047) before providing the indication of availability of the producer workload. (i.e. The backend server (Producer VPC 950 – fig.9) responds to this initial service discovery request from this client with a list of currently active port references (e.g.:
portl , port2, ... ) corresponding to a shard where subsequent requests should be routed.)(i.e. 150 – fig.1)( ¶ 0047)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify Akers in view of Panchal to include, based at least in part on identifying one or more of the consumer workload or the second VPC for providing the indication of availability of the producer workload before providing the indication of availability of the producer workload as taught by Benardos for the benefit of identifying which consumer workload will be requesting services from the producer workload.
As for Claim 20, Akers in view of Panchal and Benardo further disclose, in particular Benardo teaches,
wherein the one or more devices are configured to: receive, before providing the indication of availability of the producer workload (i.e. The consumer endpoint maps to a service attachment which forwards the service discovery request to the L4-internal load balancer (]LB) forwarding rule and backend service)( ¶ 0047), an indication via the first VPC that the producer workload is available (i.e. The backend server (Producer VPC 950 – fig.9) responds to this initial service discovery request from this client with a list of currently active port references (e.g.: portl , port2, ... ) corresponding to a shard where subsequent requests should be routed.)(i.e. 150 – fig.1) ( ¶ 0047)
Motivation to combine is similar to that of Claim 5.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JONATHAN ESTRADA whose telephone number is (571) 272-9978. The examiner can normally be reached Monday through Friday 10:00 am to 6:00 pm.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, CHRIS PARRY can be reached at (571) 272-8328. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
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.
/JONATHAN ESTRADA/Examiner, Art Unit 2451
/Chris Parry/Supervisory Patent Examiner, Art Unit 2451
