CTFR 17/301,645 CTFR 89673 DETAILED ACTION Notice of Pre-AIA or AIA Status 07-03-aia AIA 15-10-aia 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 Regarding claims rejected under 35 USC 103: further with respect to the independent claims: 07-37 Applicant's arguments have been fully considered but they are not persuasive. Applicant argues that the Sama-Babbar-Singleton-Thornton combination does not disclose the claimed invention. First, Applicant argues that the secondary reference “Babbar does not disclose that the tunnel endpoints satisfy other aspects of the claimed communication delegates and thus cannot be equated to the claimed communication delegates… at least because Babbar does not appear to disclose that its tunnel endpoints include or perform at least the above-identified features [as identified on pages 14-15 of Applicant’s arguments] of the claimed particular communication delegate, the cited tunnel endpoints of Babbar do not disclose, teach, or suggest the claimed particular communication delegate or plurality of communication delegates. Therefore, even if Babbar might disclose a type of component (the tunnel endpoints) that purportedly is uniquely mapped to a particular tenant of a plurality of tenants with each tunnel endpoint being uniquely mapped, in a one-to-one mapping, to a corresponding tenant of the plurality of tenants (which, again, Applicant does not address), the tunnel endpoints still could not be considered to disclose, teach, or suggest the claimed communication delegates or features of the claimed communication delegates… If Applicant demonstrates that the cited tunnel endpoints of Babbar are not disclosed to include or perform the features of the claimed communication delegates, as Applicant has done here based on the claim language, Applicant respectfully submits that the rejection is deficient.” In response to Applicant's arguments against the references individually, one cannot show nonobviousness by attacking references individually where the rejections are based on combinations of references. See In re Keller , 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986). In this case, the rejection is based on the teachings of Sama as the primary reference and proposes various modifications to Sama with various secondary references, including Babbar. The examiner found and rejection sets forth that the Sama reference disclosed communication delegates (e.g., connector service in FIG. 2 and [0029] of Sama) hosted on a cloud platform (e.g., “a connector service that runs in the cloud” as in [0029] of Sama), receiving tenant associated data (e.g., “a connector service… that may support multiple tenants” in [0029] of Sama; also see [0031] of Sama concerning data traffic between the connector service and tenant applications), and performing encryption using a certificate (e.g., [0038] and [0045]-[0046] of Sama concerning session credentials and TSL/HTTPS/SSL, which use certificates as part of their respective protocol). The examiner found and the rejection sets forth that, in Sama, the connector service is not mapped to the tenant applications such that each connector service of a plurality of connector services is uniquely mapped, in a one-to-one mapping, to a corresponding tenant of the plurality of tenants. The examiner found and the rejection sets forth that the teachings of Babbar have been relied upon for that particular mapping. Specifically, “associate[ing] each tenant… with a unique tunnel endpoint… [which] corresponds to a unique tenant identifier” as in [0013] of Babbar. Where Applicant argues that the tunnel endpoints of Babbar are fundamentally different from the claimed “communication delegates” to the point of its teachings being incompatible, it is first noted that the tunnel endpoints perform similar functionality and are reasonably pertinent to the claimed invention. For instance, [0013] of Babbar states that “[w]hen a packet is to be communicated by… a particular tenant…. Once obtained at tunnel endpoint 110, tunnel endpoint 110 may encapsulate the packet… and communicate the packet to a destination host computing system” while [0031] of Babbar states that “[i]n some implementations, packet 505 may be encrypted as part of the encapsulation process.” Thus, Babbar’s tunnel endpoints both route and encrypt packets on behalf of tenants. While Babbar does not specifically mention a cloud platform as argued on page 14 of Applicant’s arguments, it is noted that Babbar concerns virtual machines (e.g., FIG. 1), which are widely known to be part of cloud computing platforms and solutions and thus there is no incompatibility. Additionally, the test for obviousness is not whether the features of a secondary reference may be bodily incorporated into the structure of the primary reference; nor is it that the claimed invention must be expressly suggested in any one or all of the references. Rather, the test is what the combined teachings of the references would have suggested to those of ordinary skill in the art. See In re Keller , 642 F.2d 413, 208 USPQ 871 (CCPA 1981). In this case, Babbar has been relied upon for its teachings concerning how to map communication nodes to tenant nodes rather than a particular implementation of cloud communication technology. Likewise, the argued claim does not specify any particular cloud platform and protocol beyond a high level of generality. Applicant further argues against Sama-Babbar-Singleton-Thornton as it concerns the claimed certificate, stating that “[t]he cited portions of Sama, Babbar, Singleton, and Thornton, whether considered alone or in combination, do not disclose, teach, or suggest a unique certificate having all three of these features: (1) association with a particular communication delegate, (2) inclusion of an identifier of that particular communication delegate, and (3) inclusion of an IP address associated with that same particular communication delegate.” Specifically concerning Thornton, Applicant states that “it does not appear that the supposed certificate of Thornton would include both an identifier and an address… Second, the address or identifier in Thornton is of the client device, not for any supposed particular communication delegate (of a plurality of communication delegates) that is uniquely mapped to the tenant, as recited in Claim 1. Third, Applicant respectfully submits that nothing about the Office Action's explanation of why these teachings from Thornton supposedly would have rendered the claim features obvious in view of the other references actually explains why it would have been obvious to modify Sama with the cited features of Thornton. Neither the cited portion of Thornton nor the Office Action's explanation connects the cited information of Thornton back to the protocols disclosed in Sama or in any way explains why these features would be applicable to the particular environment of Sama.” In response, it is noted that [0182] of Thornton discusses a use case of a certificate where certificates are fixed to a given device (i.e., “prevent the transfer of a certificate from one client device to another”), such that “the certificate may include information unique to the client device, for example a MAC address, a fixed IP address, a serial number or a processor ID.” Here, the certificate of Thornton is fixed to a given network device and includes any of a MAC address of the device or a fixed IP, where the “or” is considered to be inclusive rather than limiting to an exclusive interpretation. Further, an x509 certificate is used in the SSL, TLS, and HTTPS example protocols (e.g., [0038] and [0045]-[0046] of Sama). An x509 certificate has subject and subject alternative fields as part of its specification, where these are commonly used for identifiers and IP addresses. Thus, Sama-Babbar-Singleton-Thornton discloses using encryption protocols making use of x509 certificates, and further provides for certificates being uniquely fixed to network devices according to information unique to the device being part of the certificate fields (including a MAC address and IP address unique to the device). Where Applicant argues that Thornton’s client device is not the claimed “particular communication delegate,” it is noted that the test for obviousness is not whether the features of a secondary reference may be bodily incorporated into the structure of the primary reference; nor is it that the claimed invention must be expressly suggested in any one or all of the references. Rather, the test is what the combined teachings of the references would have suggested to those of ordinary skill in the art. See In re Keller , 642 F.2d 413, 208 USPQ 871 (CCPA 1981). Here, the Sama-Babbar-Singleton combination already makes use of x509 certificates for encrypting tenant data. The teachings of Thornton are applied as they concern what information goes into certificate fields, where the certificates are uniquely bound to a given device. MAC addresses and IP addresses are extremely well known in the field, and their addition to the certificates of Sama-Babbar-Singleton would be a matter of looking up the correct data and mere substitution of elements for the certificate fields. further with respect to dependent claim 3: Applicant’s arguments have been fully considered and are persuasive. The rejection has been withdrawn. Claim Rejections - 35 USC § 103 07-20-aia AIA 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. 07-21-aia AIA Claim(s) 1, 4, 7-13, 18-20, and 23 is/ar e rejected under 35 U.S.C. 103 as being unpatentable over Sama ( US 2016/0036921 A1) in view of Babbar (US 2021/0028957 A1) , Singleton (US 2021/0058470 A1) , and Thornton (US 2005/0071630 A1) . Regar ding claim 1, Sama discloses: A method comprising: receiving, by a particular communication delegate (connector service—e.g., FIG. 2 of Sama) hosted on a cloud platform and mapped to a particular tenant of a plurality of tenants of the cloud platform (cloud and tenant—e.g., [0029] of Sama) , data traffic associated with the particular tenant and directed to an application hosted on an on-premise private network of the tenant (private communication system and tenant application—e.g., FIG. 2 of Sama) , wherein the cloud platform is hosted outside of the on-premise private network (e.g., FIG. 1-2 and [0005]-[0006] of Sama) ; Refer to at least FIG. 2 and [0029] of Sama with respect to communications between the cloud connector service and the private communication system comprising the tenant application. encrypting, by the particular communication delegate, the data traffic to generate an encrypted data traffic using a unique certificate associated with the particular communication delegate (e.g., TLS, SSL certificates as per the protocols) , wherein the unique certificate comprises [an identifier and an IP address for related parties]; and Refer to at least [0038] and [0045]-[0046] of Sama with respect to egress traffic from the connector to the tenant application, the traffic having the form of TLS, HTTPS, or SSL. Session credentials may be provided for each traffic direction. communicating, by the particular communication delegate, the encrypted data traffic to the application via a secure communication tunnel specific to the particular tenant between the particular communication delegate and the on-premise private network, wherein: Refer to at least the abstract, FIG. 2 and [0036]-[0038] of Sama with respect to a bridge between the tenant application in the private communication system and the cloud connector. The bridge comprises independent inbound and outbound pipes (ingress and egress). The pipes may use secure protocols such as TLS, HTTPS, or SSL. the secure communication tunnel comprises: a first communication tunnel between the particular communication delegate and a [bridge] ; and a second communication tunnel between the [bridge] and the on-premise private network; and Refer to at least [0036]-[0037] and [0042]-[0043] of Sama with respect to the ingress and egress pipes. communicating the encrypted data traffic comprises sending the encrypted data traffic from the particular communication delegate to the [bridge] via the first communication tunnel [ prior to forwarding the encrypted data traffic to the application via the second communication tunnel] . Refer to at least [0036]-[0037] and [0042]-[0043] of Sama with respect to sending egress traffic to the bridge and onward to the ingress pipe to the tenant application. Sama discusses a proxy server (e.g., FIG. 2 and [0038]-[0040] of Sama), but does not specify if it is the bridge. Sama further discusses secure communication protocols (e.g., [0038] of Sama), but does not specify verifying the connector. As such, Sama does not fully disclose: the bridge further comprising a midway server; prior to forwarding the encrypted data traffic to the application via the second communication tunnel further comprising the midway server configured to verify, using the unique certificate associated with the particular communication delegate, an identity of the communication delegate prior to forwarding the encrypted data traffic to the application via the second communication tunnel. Sama further does not disclose: the particular communication delegate being one of a plurality of communication delegates hosted on the cloud platform, each communication delegate of the plurality of communication delegates being uniquely mapped, in a one-to-one mapping, to a corresponding tenant of the plurality of tenants; the mapping further comprising the particular communication delegate being uniquely mapped to a particular tenant; the identifier and IP address for related parties further comprising wherein the unique certificate comprises an identifier of the particular communication delegate and an IP address associated with the particular communication delegate. However, Sama in view of Babbar discloses: the particular communication delegate being one of a plurality of communication delegates hosted on the cloud platform, each communication delegate of the plurality of communication delegates being uniquely mapped, in a one-to-one mapping, to a corresponding tenant of the plurality of tenants; the mapping further comprising the particular communication delegate being uniquely mapped to a particular tenant; Refer to at least 110 and 111 in FIG. 1, the abstract, and [0013] of Babbar with respect to a tunnel endpoint being uniquely associated with each tenant on a computing system 100. The teachings of Babbar likewise concern facilitating secure connections for tenants, and are considered to be within the same field of endeavor and combinable as such. Therefore it would have been obvious to one of ordinary skill in the art before the filing date of Applicant’s invention to modify the teachings of Sama to further include per-tenant connectors for at least the reasons discussed in [0002]-[0003] and [0021] of Babbar (i.e., improving connection configuration and also allowing for per-tenant QoS). Sama-Babbar does not disclose: the bridge further comprising a midway server; prior to forwarding the encrypted data traffic to the application via the second communication tunnel further comprising the midway server configured to verify, using the unique certificate associated with the particular communication delegate, an identity of the communication delegate prior to forwarding the encrypted data traffic to the application via the second communication tunnel. However, Sama-Babbar in view of Singleton discloses: the bridge further comprising a midway server; Refer to at least FIG. 1, FIG.4, [0009], [0022], and [0049] of Singleton with respect to a gateway appliance having a first and second route between a cloud and private enterprise network (e.g., [0017] of Singleton). prior to forwarding the encrypted data traffic to the application via the second communication tunnel further comprising the midway server configured to verify, using the unique certificate associated with the communication delegate, an identity of the communication delegate prior to forwarding the encrypted data traffic to the application via the second communication tunnel; Refer to at least the [0006] and [0053] of Singleton with respect to tokens used for handshaking and authentication with the gateway appliance for implementing and using the first and second routes. The teachings of Sama-Babbar and Singleton both concern establishing secure connections between private enterprise networks and cloud networks, and are considered to be within the same field of endeavor and combinable as such. Therefore it would have been obvious to one of ordinary skill in the art before the filing date of Applicant’s invention to modify the teachings of Sama-Babbar to further include an intermediary appliance for the bridge because the substitution of one known element for another would have yielded predictable results to one of ordinary skill in the art at the time (e.g., [0022] and [0049 of Singleton concerning various different implementations of the gateway). It further would have been obvious to implement specific handshaking and authentication for the connector for at least the purpose of increasing the security of connections (i.e., protection from malicious access and impersonation / replay attacks). Sama-Babbar-Singleton does not disclose: the identifier and IP address for related parties further comprising wherein the unique certificate comprises an identifier of the particular communication delegate and an IP address associated with the particular communication delegate. However, Sama-Babbar-Singleton in view of Thornton discloses: the identifier and IP address for related parties further comprising wherein the unique certificate comprises an identifier of the particular communication delegate and an IP address associated with the particular communication delegate. Refer to at least [0182] of Thornton concerning a certificate including information unique to a device, such as a MAC/serial/ID and an IP address. The teachings of Thornton concern certificates such as those for SSL/TLS, and are combinable with those of Sama-Babbar-Singleton likewise relating to such. Therefore it would have been obvious to one of ordinary skill in the art before the filing date of Applicant’s invention to modify the teachings of Sama-Babbar-Singleton to further include information unique to a device as part of the certificate for at least the purpose of increasing security by properly authenticating all principals (i.e., mutual authentication of all parties), and because the substitution of one known element for another would have yielded predictable results to one of ordinary skill in the art at the time (i.e., filling out x.509 fields with particular information). Regarding claim 4, Sama-Babbar-Singleton-Thornton discloses: The method of claim 1, further comprising retrieving, by the particular communication delegate, the unique certificate associated with the particular communication delegate from a certificate store. Refer to at least [0007] and [0029] of Sama with respect to a certificate authority. Regarding claim 7, it is rejected for substantially the same reasons as claim 1 above (i.e., authentication and handshaking for, e.g., x509 format certificates as part of SSL or TLS; [0038] of Sama with respect to TLS and SSL). Regarding claim 8, it is rejected for substantially the same reasons as claims 1 and 3 above (i.e., the citations and obviousness rationale—e.g., to [0048]-[0049] and [0053] of Singleton concerning per-tenant tokens). Regarding claim 9, it is rejected for substantially the same reasons as claims 1 and 3 above (i.e., the citations and obviousness rationale—e.g., the citations to authentication and handshaking for the credential / token). Regarding claim 10, Sama-Babbar-Singleton-Thornton discloses: The method of claim 1, further comprising linking a remote communication agent associated with the application and hosted at the on-premise private network with the application by allocating an IP address and a port associated with the application to the remote communication agent. Refer to at least [0050] of Singleton with respect to prior art knowledge and implementation of ports and IP addresses for session connectors at the private enterprise network. Therefore the claim would have been obvious because a particular known technique (allocating IP addresses and ports) was recognized as part of the ordinary capabilities of one skilled in the art. Regarding claim 11, Sama-Babbar-Singleton-Thornton discloses: The method of claim 1, further comprising mapping the secure communication tunnel to a unique Uniform Resource Locator (URL) accessible by the particular tenant. Refer to at least [0045] of Sama with respect to a URL as part of implementing the pipes. Regarding claim 12, Sama-Babbar-Singleton-Thornton discloses: The method of claim 1, further comprising establishing a plurality of communication links within the secure communication tunnel between the particular communication delegate and a remote communication agent, wherein the encrypted data traffic is transported over one or more of the plurality of communication links. Refer to at least FIG. 2 and [0031] of Sama with respect to a plurality of connections. Regarding independent claim 13, it is substantially similar to elements of independent claim 1 and dependent claim 4 above, and is therefore likewise rejected (i.e., the citations and obviousness rationale). Regarding claim 18, it is substantially similar to claim 7 above, and is therefore likewise rejected. Regarding independent claim 19, it is substantially similar to elements of independent claim 13 above, and is therefore likewise rejected (i.e., the citations and obviousness rationale). Regarding claim 20, it is substantially similar to claim 3 above, and is therefore likewise rejected. Regarding claim 23, it is rejected for substantially the same reasons as claim 1 above (i.e., TLS/SSL using the certificate for encrypting traffic as per the protocol) . 07-22-aia AIA Claim (s) 2 is/are rejected under 35 U.S.C. 103 as being unpatentable over Sama-Babbar-Singleton-Thornton as applied to claim s 1, 4, 7-13, 18-20, and 23 above, and further in view of Official Notice . Regarding claim 2, Sama-Babbar-Singleton-Thornton does not specify: wherein the application is provided to the particular tenant on a pay-per-use basis. However, the examiner hereby takes official notice that it was well known in the art before the filing date of Applicant’s invention to provide cloud and hybrid cloud applications for a fee; that payment could be consumption-based/metered/pay-per-use. Therefore it would have been obvious to one of ordinary skill in the art before the filing date of Applicant’s invention to modify the teachings of Sama-Babbar-Singleton-Thornton to include wherein the application is provided to the particular tenant on a pay-per-use basis because design incentives or market forces provided a reason to make an adaptation, and the invention resulted from application of the prior knowledge in a predictable manner (i.e., monetization of the service; monetization based on usage such that more frequent users pay more money) . 07-22-aia AIA Claim (s) 21-22 is/are rejected under 35 U.S.C. 103 as being unpatentable over Sama-Babbar-Singleton-Thornton as applied to claim s 1, 4, 7-13, 18-20, and 23 above, and further in view of Chandrashekhar (US 2018/0063193 A1) . Regarding claim 21, Sama-Babbar-Singleton-Thornton discloses: The method of claim 1, wherein: the second communication tunnel is between the midway server and a first remote communication agent hosted at the on-premise private network and linked to the application; Refer to at least 17 in FIG. 2 and [0040] of Sama with respect to a tenant-side proxy server for the tenant application’s communications. Sama-Babbar-Singleton-Thornton does not disclose: the secure communication tunnel comprises a standby communication tunnel between the midway server and a second remote communication agent hosted at the on-premise private network and linked to the application; and the method further comprises switching, by a communications controller of the cloud platform and in response to detecting a threshold number of failures of one or more of a plurality of communication links within the secure communication tunnel, the secure communication tunnel to the standby communication tunnel such that the secure communication tunnel comprises the first communication tunnel and the standby communication tunnel. However, Sama-Babbar-Singleton-Thornton in view of Chandrashekhar discloses: the secure communication tunnel comprises a standby communication tunnel between the midway server and a second remote communication agent hosted at the on-premise private network and linked to the application; and the method further comprises switching, by a communications controller of the cloud platform and in response to detecting a threshold number of failures of one or more of a plurality of communication links within the secure communication tunnel, the secure communication tunnel to the standby communication tunnel such that the secure communication tunnel comprises the first communication tunnel and the standby communication tunnel. Refer to at least [0078] and [00105] of Chandrashekhar with respect to active and standby gateway DCNs, where the standby DCN is used in case of failure. The teachings of Chandrashekhar likewise concern establishing secure connections between private enterprise networks and cloud networks, and are considered to be within the same field of endeavor and combinable as such. Therefore it would have been obvious to one of ordinary skill in the art before the filing date of Applicant’s invention to modify the teachings of Sama-Babbar-Singleton-Thornton to further include standby gateway functionality for at least the purpose of maintaining uptime and improving quality of service. Regarding claim 22, it is substantially similar to claim 21 above, and is therefore likewise rejected. Conclusion 07-39 AIA 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 VADIM SAVENKOV whose telephone number is (571)270-5751. The examiner can normally be reached 12PM-8PM. 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, Jeffrey L Nickerson can be reached at (469) 295-9235. 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. /Jeffrey Nickerson/Supervisory Patent Examiner, Art Unit 2432 /V.S/Examiner, Art Unit 2432 Application/Control Number: 17/301,645 Page 2 Art Unit: 2432 Application/Control Number: 17/301,645 Page 3 Art Unit: 2432 Application/Control Number: 17/301,645 Page 4 Art Unit: 2432 Application/Control Number: 17/301,645 Page 5 Art Unit: 2432 Application/Control Number: 17/301,645 Page 6 Art Unit: 2432 Application/Control Number: 17/301,645 Page 7 Art Unit: 2432 Application/Control Number: 17/301,645 Page 8 Art Unit: 2432 Application/Control Number: 17/301,645 Page 9 Art Unit: 2432 Application/Control Number: 17/301,645 Page 10 Art Unit: 2432 Application/Control Number: 17/301,645 Page 11 Art Unit: 2432 Application/Control Number: 17/301,645 Page 12 Art Unit: 2432 Application/Control Number: 17/301,645 Page 13 Art Unit: 2432 Application/Control Number: 17/301,645 Page 14 Art Unit: 2432 Application/Control Number: 17/301,645 Page 15 Art Unit: 2432 Application/Control Number: 17/301,645 Page 16 Art Unit: 2432
Prosecution Insights