Referring to the example in Figure 2 below, annotated by Dr. Black, the system operates as an intermediary “Gateway” [204] that facilitates “interactions between enterprise users [202a, 202b, 202c] and cloud service providers [206a, 206b, 206c] for storage, retrieval, and searching of data and content stored by the providers.” Ex. 1001, 8:27-9:4; Ex. 2001, ¶¶31-32.
In an effort to remedy this deficiency, Petitioner alleges that a POSITA “would have added Herrmann’s gateway server and its access policy assignment functionality to Cidon’s management server.” Pet. 27; see also id., 21-22, 25-30, 44-46 (referring to Cidon/Shikfa/Herrmann combination in connection with multiple claim steps).
Petitioner asserts that a POSITA would have been motivated to make the purported modification “because, in addition to Auradkar’s existing whole-document search, the modified system would have allowed retrieval of encrypted document portions stored in the cloud.” Pet. 97; see also Pet. 79, 106 (identifying same alleged benefit).
Petitioner fails to explain how or why a POSITA would look to modify this comprehensive platform to implement Auradkar’s complex techniques on Chambers’ simple “network access device” (Petitioner’s identified “gateway” device) that cannot even perform its own existing functions without a separate “management server.” Chambers, ¶¶24- 28.
Auradkar teaches a comprehensive “trustworthy platform” that uses complex mathematical techniques to provide “containerless” protection of data stored by cloud services in a system of “distribute[d] trust” (Auradkar, Abstract, ¶¶9- 13), whereas Chambers teaches using “network access devices” to “automatically assign[] [network] access control policies (ACPs) based on [client] device types,” where the policies specify network parameters such as “bandwidth limits and traffic shaping rules, VLAN assignment, firewall rules, whether a captive portal should be applied to that device, etc.” Chambers, ¶¶21, 24-28, 32-40.