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-3,6-10,13-17,20-21 and 27-29 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
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 (i.e., changing from AIA to pre-AIA ) 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, 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-3, 6-7, 8-10, 13-17, 15-17 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Innes (US 20150365412 A1) in view of Johnson (US 20180262388 A1) , Polis (US 20130086699 A1) and Kaluza(US 20190081861 A1).
Regarding claim 1, Innes teaches:
A computer-implemented method, comprising. (Claim 1. A method comprising)
obtaining, by one or more processing units, connection information for connecting to a requesting device by decoding authentication information, wherein the authentication information is created based at least on an identifier of the requesting device. ([0108] FIG. 7 depicts an illustrative system having a client device 705, a proxy device 710, resource(s) 720, and/or authentication service(s) 715. FIG. 8 depicts an illustrative detailed view of the client device 705 and proxy device 710. These elements may implement one or more aspects described herein. A brief summary of these aspects will now be provided, with additional examples provided below. The client device 705 may communicate with one or more resources 720 and/or authentication services 715 using a proxy device 710. In some aspects, the client device 705 might not be configured to communicate directly with the resources 720 and/or authentication services 715. For example, the client device 705 and resources 720 may use different authentication and/or communication protocols. The proxy device 710 may translate between these different protocols. Additionally or alternatively, the proxy device 710 may provide additional benefits, as will be described in the examples below. [0109] The client device 705 may send a request for resources 720, such as documents, emails, services, files, and the like, to the proxy device 710. The proxy device 710 may forward the request to the resource 720, and in response, authentication between the proxy device 710 and resource 720 may be initiated. At one or more points during the authentication, the resource 720 may request a signature, such as from a client certificate. The proxy device 710 might not directly have access to the client certificate, so the proxy device 710 may involve the client device 705 in the authentication process, such as if the client device 705 controls access to the client certificate. For example, the proxy device 710 may request that the client device 705 sign or decrypt an authentication message using the client certificate (or a private key included therein), or return a list of available security certificates or a selection by the user of a particular security certificate. [0149] In step 932, the client device 705 may receive the request for signature from the proxy device 710 and extract the context information included therein. For example, the client device 705 may decode and/or decrypt the request message. Examples of the context information were previously listed. In step 934, the client device 705 may attempt to verify the context information.)
sending, by the one or more processing units, a request including the connection information to a request proxy, wherein the request is redirected by the request proxy to a plurality of devices having more than one platform; and ([0109]For example, the proxy device 710 may request that the client device 705 sign or decrypt an authentication message using the client certificate (or a private key included therein), or return a list of available security certificates or a selection by the user of a particular security certificate. [0134] In step 916, the proxy device 710 may send the request to the client device 705 for a list of certificates available and/or accessible to the client device 705. The request may be encoded into an HTTP header. )
Innes does not explicitly: and wherein the connection information comprises at least a client identifier, a network address, a port, a private network indicator, an application type, and a Globally Unique Identifier (GUID) of a content forwarder;
However, Johnson teaches: [0251-0255] describes the information exchanged as part of establishing or authenticating a remot3.it connection. The message contains client UID, IP address, port , NAT type. [0279] For example, the remot3.it system may monitor bandwidth use, length of connection, type of connection, application type, or any feature, function, metric, etc. [0520] In one embodiment, if the remot3.it API accepts the message to be sent, then the message is forwarded to the correct chat server for the target device identified by the specified target UID. The chat server selected is the chat server that the target device is connected to. The chat server encrypts the message and forwards the message to the target device.
Accordingly, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention, having the teachings of Innes and Johnson before them, to modify Innes’s communication system to include Johnson’s connection information, including a client UID, IP address, port NAT/ network information and application information, Johnson teaches using such information to identify connection session and route appropriate server and target device (see Johnson [0251,0278, 0519]). A skilled person in art would have been motivated to incorporate these known connection identification routing parameters to Innes to improve connection establishment and routing across different networks.
Innes does not explicitly: platform, wherein the plurality of devices are selected based on a shared dependency map, the connection information, traffic, and workload, wherein and the shared dependency map indicates that the plurality of devices share at least one dependent application component with the requesting device, wherein the shared dependency map is generated by analyzing dependent application components of the plurality of devices and the requesting device
However, Kaluza teaches: [0043] In an exemplary embodiment of the disclosure, the information collected by agent application 130 is stored in a database 160. Optionally, one host 110 serves as an agent server 170 with an analysis application 175 that analyzes the collected information to determine dependencies of IT components from each other in system 100, for example to identify components that may be responsible for problems in the enterprise application. Optionally, the dependencies may be used to build a configuration management database (CMDB) 155 (e.g. in database 160). The CMDB 155 represents an inferred structure of system 100 and dependencies between the components of the system 100. See also [0055] and [0059] and claims 1-10. ([0058] After determining that there is a dependency connection between two hosts the name-values are analyzed (245) to determine if the identified dependency relationship is a reverse dependency relationship by checking according to the predefined rules for reverse dependency. Such a rule might be, for example, if host A grants FTP or SSH access to host B, then dependency is reversed. If any of the reverse matching rules applies, a link indicating dependency pointing from host B to host A is recorded (250), for example in CMDB 155. In the case of non-reversed dependency, a link indicating dependency pointing from host B to host A is recorded (250). For example if host B appears in an “FTP approved host” configuration file on host A then a predefined rule would state that it indicates that host B is dependent on A. Likewise a configuration parameter with a single IP address generally indicates an access request, whereas a configuration parameter with multiple IP addresses generally indicates granting access. See also [0062]
Accordingly, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention, having the teachings of Innes and Kaluza before them, to include Kaluza’s dependency maps in in Innes’s resource proxy. One would have been motivated to make such a combination to more efficiently manage the different type of available resources by creating a map that shows their dependency and therefore improving their use by applications when request are made.
Innes does not explicitly: teach combining, by the one or more processing units, responses received by the request proxy from the plurality of devices.
However Polis teaches: [0100] Parsed Content Aggregator[0101] This component consolidates, aggregates parsed output, from similar web services from different providers. The following aggregators can be defined: Email--Consolidate and aggregate email from a list of email providers--this list can contain, but is not limited to, MySpace.com, Yahoo.com, Gmail.com, MSN.com, sites hosting SquirrelMail, and other email providers; Social Networking; Blogs; Forums; Job Search; News; Shopping; etc. The master server system facilitates combining output of all web services
Accordingly, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention, having the teachings of Innes and Polis before them, to include Polis’s aggregation system with in Innes’s resource proxy. One would have been motivated to make such a combination to more to improve data management and response across the distributed system.
Regarding claim 2, Innes teaches:
The computer-implemented method of claim 1, wherein the request is a registration request, the responses to the request includes a decision whether the registration request is approved, and a response from each of the plurality of devices includes a message indicating whether each of the plurality of devices agrees with the registration request. ([0128] In step 904, the client device 705 may authenticate the proxy device 710. Additionally or alternatively, in step 906, the proxy device 710 may authenticate the client device 705. In other words, the client device 705 and proxy device may perform mutual authentication. To perform the authentication, the client device 705 may connect to the proxy device 710 using SSL with server authentication. The proxy device 710 may request the client device 705 and/or the user of the client device 705 to authenticate to the proxy device 710 before authorizing access to the proxy device 710. In some aspects, the client device 705 may use an enterprise client certificate for this authentication. The enterprise client certificate may be the same certificate used by the client device 705 to sign documents and/or authentication messages, as will be described in further detail in the examples below. Alternatively, the enterprise client certificate may comprise a different certificate. For example, the client device 705 may have multiple certificates, each used for a different purpose. See also [0136, 0149-0153, 0162-0166])
Regarding claim 3, Polis teaches:
The computer-implemented method of claim 1, wherein the request is a computation request, a response to the request includes a computation result, and a response from each of the plurality of devices includes at least a part of the computation result. [0100] Parsed Content Aggregator[0101] This component consolidates, aggregates parsed output, from similar web services from different providers. The following aggregators can be defined: Email--Consolidate and aggregate email from a list of email providers--this list can contain, but is not limited to, MySpace.com, Yahoo.com, Gmail.com, MSN.com, sites hosting SquirrelMail, and other email providers; Social Networking; Blogs; Forums; Job Search; News; Shopping; etc. The master server system facilitates combining output of all web services
Same motivation as claim 1
Regarding claim 6, Innes teaches:
The computer-implemented method of claim 1, wherein: the requesting device is in a private network; the request is sent to the request proxy through the content forwarder in a public network; and the response to the request is received from the content forwarder. ([0166] ]In some embodiments, the client device 705 may communicate with the resource 720, such as Sharepoint, using a VPN tunnel (e.g., through the proxy device 710) or other type of communication channel. Instead of the proxy device 710 receiving the resource authentication challenge from the resource 720 (e.g., in step 914 illustrated in FIG. 9A), the client device 705 may receive the challenge via the VPN tunnel.)
Regarding claim 7, Innes teaches:
The computer-implemented method of claim 1, wherein at least one shared dependent application component of two or more applications of the requesting device is run on a same runtime virtual machine. ([0042-0043] In one embodiment, the client machine 240 may be a virtual machine. The virtual machine may be any virtual machine, while in some embodiments the virtual machine may be any virtual machine managed by a Type 1 or Type 2 hypervisor, for example, a hypervisor developed by Citrix Systems, IBM, VMware, or any other hypervisor. In some aspects, the virtual machine may be managed by a hypervisor, while in aspects the virtual machine may be managed by a hypervisor executing on a server 206 or a hypervisor executing on a client 240. See also [0063])
Regarding claim 8, the claim recites similar limitation as corresponding claim 1 and is rejected for similar reasons as claim 1 using similar teachings and rationale. Innes also teaches:
A computing system, comprising. (Claim 13. A proxy device comprising)
Regarding claim 9, the claim recites similar limitation as corresponding claim 2 and is rejected for similar reasons as claim 2 using similar teachings and rationale.
Regarding claim 10, the claim recites similar limitation as corresponding claim 3 and is rejected for similar reasons as claim 3 using similar teachings and rationale.
Regarding claim 13, the claim recites similar limitation as corresponding claim 6 and is rejected for similar reasons as claim 6 using similar teachings and rationale.
Regarding claim 14, the claim recites similar limitation as corresponding claim 7 and is rejected for similar reasons as claim 7 using similar teachings and rationale
Regarding claim 15, the claim recites similar limitation as corresponding claim 1 and is rejected for similar reasons as claim 1 using similar teachings and rationale. Innes also teaches:
A computer program product, comprising a computer readable storage medium having program instructions embodied therewith, the program instructions executable by a processor to cause the processor to perform actions of. (0034] One or more aspects may be embodied in computer-usable or readable data and/or computer-executable instructions, such as in one or more program modules, executed by one or more computers or other devices as described herein.)
Regarding claim 16, the claim recites similar limitation as corresponding claim 2 and is rejected for similar reasons as claim 2 using similar teachings and rationale.
Regarding claim 17, the claim recites similar limitation as corresponding claim 3 and is rejected for similar reasons as claim 3 using similar teachings and rationale..
Regarding claim 20, the claim recites similar limitation as corresponding claim 7 and is rejected for similar reasons as claim 7 using similar teachings and rationale.
Claim 21 is rejected under 35 U.S.C. 103 as being unpatentable over Innes (US 20150365412 A1) in view of Johnson (US 20180262388 A1) , Polis (US 20130086699 A1), Kaluza(US 20190081861 A1) and in further view of Islam (US 20150120939 A1).
Regarding claim 21, Innes does not appear to explicitly teach:
The computer-implemented method of claim 1, further comprising: generating the shared dependency map by: providing application code to a build server, wherein the build server includes an application converter, an application manager, an application updater, a dependency detector, a dependency merger, and a dependency splitter; wherein the dependency detector is configured to detect the dependent application components of the application code; wherein the dependency merger is configured to merge the dependent application components in response to the dependent application components having a same file; wherein the dependency splitter is configured to split the dependent application components in response to the dependent application components having different libraries; wherein the application converter is configured to convert an application configured to run on a first platform to a corresponding application configured to run on a second platform, and wherein the application updater is configured to update packages of the application for different releases on different platforms; wherein the application manager is configured to manage libraries of the application; and outputting the shared dependency map from the build server.
However, Islam teaches: ([0026] In accordance with an embodiment, each of the IaaS, PaaS, and/or SaaS layers can generally include a variety of components. For example, in accordance with an embodiment, the IaaS layer can include a shared database hardware (e.g., an Exadata machine), and/or shared application server hardware (e.g., an Exalogic machine); while the PaaS layer can include one or more PaaS services, such as a database service, application server service, and/or WebCenter service; and the SaaS layer can include various SaaS services, such as enterprise applications (e.g., Oracle Fusion SaaS), and/or ISV or custom applications. The cloud environment can also include a shared enablement and managing infrastructure 30, which provides enablement and management tools that support the various service layers, for example, identity management, virtual assembly builder, system provisioning, tenant management, or other components.; [0031] FIG. 2 illustrates an administration server and a service domain, in accordance with an embodiment. As shown in FIG. 2, in accordance with an embodiment, the PaaS platform (platform) comprises a PaaS administration server 108, which supports an administration console 120, cloud platform provisioning/management logic 121, and virtual assembly builder (VAB) deployer 122, together with a virtual assembly or VAB repository 124. The VAB deployer can be provided by functionality, components, or products such as Oracle Virtual Assembly Builder (OVAB). The VAB deployer (e.g., OVAB Deployer) can then be used by the platform to manage those VMs that will host the servicing applications.; [0060] In accordance with an embodiment, services can be periodically maintained to ensure that they are up-to-date with, e.g., bug fixes, security updates and configuration changes. To help ensure homogeneous environments, services should be updated in a timely manner, with the same set of patches and configuration updates. In accordance with an embodiment, an update is defined to be a change which has to be made to the system; examples of which include application of a security patch, upgrade of a component, or changing of a configuration value. Depending on the type of update, some updates may require a service or system downtime, while other updates may not require a downtime; and each of these scenarios can be taken into account. [0062] In accordance with an embodiment, a service resource can be provided using a provider type and a provider SME. A service definition package (SDP) for the service can specify a dependency on a provider, and include association rules that define actions to be taken with regard to a runtime of the provider. When the service is provisioned, a service resource type which is derived from a provider SDP can be associated with the service. As a result of the association, a service resource can be automatically created from the service resource type in accordance with the association rules, to provide resources for consumption by the application. [0085] As shown in the example of Listing 2, the sample service definition xml defines a complete set of supported feature sets, and each feature set can refer to one or more property sets that can be used to provide property values when creating provider types or service resource types. [0086] In accordance with an embodiment, a service definition file in a service SDP can similarly define a complete set of supported feature sets, wherein each feature set can refer to one or more dependencies. When creating a service type, a user can select a feature set. Later, when the service is created using that service type, an orchestration engine can associate the service with dependencies based on the selected feature set. If no feature set is specified as part of the service type, the feature set marked as default can be selected. [0086] In accordance with an embodiment, a service definition file in a service SDP can similarly define a complete set of supported feature sets, wherein each feature set can refer to one or more dependencies. When creating a service type, a user can select a feature set. Later, when the service is created using that service type, an orchestration engine can associate the service with dependencies based on the selected feature set. If no feature set is specified as part of the service type, the feature set marked as default can be selected.; see also [0045][0130-0133])
Accordingly, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention, having the teachings of Innes and Islam before them, to include Islam’s depend based service definition, provisioning, and updating functionally into Innes resource proxy system. One would have been motivated to make such combination to enable identified application dependencies to be used when provisioning required application resources and to maintain the application components w with updates across different service environments. Islam teaches defining dependencies for a service and associating resources with those dependencies during provisioning ( Islam [0062][0086]), as well as updating services and configuration changes (Islam [0060]). The combination would therefore provide a predictable way to ensure that application dependencies are properly provisioned and maintained during application deployment and operation.
Claim 27 is rejected under 35 U.S.C. 103 as being unpatentable over Innes (US 20150365412 A1) in view of Johnson (US 20180262388 A1) , Polis (US 20130086699 A1), Kaluza(US 20190081861 A1) and in further view of Marques “code splitting”.
Regarding claim 27, Innes does not appear to explicitly teach:
The computer-implemented method of claim 1, wherein the shared dependency map is generated by: detecting the dependent application components to construct a dependency tree; merging shared files of two or more of the dependent application components into a library; and splitting different libraries of two or more of the dependent application components to determine whether they share a same file, and wherein the shared dependency map is based on the merging and the splitting.
However, Marques teaches: Page 3, Chunk content All dependencies at a split point go into a new chunk. Dependencies are also recursively added. If you pass a function expression (or bound function expression) as callback to the split point, webpack automatically puts all dependencies required in this function expression into the chunk too. Chunk optimization If two chunks contain the same modules, they are merged into one. This can cause chunks to have multiple parents. If a module is available in all parents of a chunk, it's removed from that chunk. If a chunk contains all modules of another chunk, this is stored. It fulfills multiple chunks. Page 5, Commons chunk The CommonsChunkPlugin can move modules that occur in multiple entry chunks to a new entry chunk (the commons chunk).
Accordingly, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention, having the teachings of Innes with Marques’s dependency splitting and merging techniques to identify shared dependencies, reduce duplicate modules, and consolidate common dependencies into a shared chunk or library. Marques teaches recursively adding dependencies, merging chunks containing the same modules, and moving modules occurring in multiple entry chunks into a common chunk, thereby providing a predictable way to improve dependency organization.
Claim 28 is rejected under 35 U.S.C. 103 as being unpatentable over Innes (US 20150365412 A1) in view of Johnson (US 20180262388 A1) , Polis (US 20130086699 A1), Kaluza(US 20190081861 A1) and in further view of Toebes (US 20060117038 A1).
Regarding claim 28, Innes does not appear to explicitly teach:
The computer-implemented method of claim 1, wherein the request proxy gives priority to devices in a same network type as the requesting device when selecting the plurality of devices.
However, Toebes teaches: [0043] As apparent from the foregoing, the resolution or list of resolutions may specify either an explicit IP address, or another host name for a secondary DNS server configured for providing more specific resolutions based on a different set of criteria. Multi-tiered resolutions may be deployed, where a first DNS server 50 directs the client device to a second DNS server (not shown) based on authentication (or SLA validation) of the client device; the second DNS server can then direct the client device to the appropriate destination based on locality, load sharing, etc. [0053] Assuming in step 106 that the default server (e.g., 14a) includes the selection resource 40, the selection resource 40 executed in the server 14a performs the same selection operations described above with respect to FIGS. 4B and 4C, namely identifying the client device location and the respective server locations from the network topology map 42 or the subnet prefix list 48 in step 90, and identifying the selected server (e.g., 14b) that is available a having the minimum distance to the client device location (or having the same subnet prefix 22) in step 92. [0054] According to the disclosed embodiment, distributed services are implemented based on deploying multiple servers throughout a network, each server configured for providing the distributed service for any requesting client device. The requesting client device is connected to one of the servers having been identified as most appropriate for the requesting client device, for example the server closest to the client device.
Accordingly, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention, having the teachings of Innes and Toebes before them, to include in in Innes’s resource proxy. Toebes’s selection or priority to a device having the same or closest network as the requesting device. One would have been motivated to make such modification in order to reduce unnecessary network traffic and improve the efficiency of directing requests to distributed devices. See Toebes [0049]
Claim 29 is rejected under 35 U.S.C. 103 as being unpatentable over Innes (US 20150365412 A1) in view of Johnson (US 20180262388 A1) , Polis (US 20130086699 A1), Kaluza(US 20190081861 A1) and in further view of Elias (US 20200106828 A1).
Regarding claim 29, Innes does not appear to explicitly teach:
The computer-implemented method of claim 7, wherein the request is a computation request, and combining the responses comprises generating a computation result by combining partial results from the plurality of devices using at least one selected from a group consisting of: add, average, and maximize, and wherein each partial result is produced using the at least one shared dependent application component.
However, Elias teaches: [0044] Another solution is to provide high speed links between each ingress port and the central block or multiple high speed links from forwarding circuitry to the central block with the central block including multiple ALUs arranged in a hierarchical structure so that in a first level of the hierarchical structure, data from any two ingress ports is reduced by one ALU, and in a second level the data output of the ALUs in the first level is reduced by the ALUs in the second level and so on until a central ALU receives data input from two ALUs to yield a final reduced data output. [0068] Packet headers of the packets 316 targeted for the data reduction process may also include data needed by the application layer controller 308 for managing the aggregation protocol, such as which operation(s) (e.g., mathematical operation(s)) the ALUs 312 should perform and where resultant reduced data should be sent. Therefore, at least one packet (e.g., a first packet in a message) of the packets 316 targeted for the data reduction process is forwarded to the central block 306 via the forwarding circuitry 304 for receipt by the application layer controller 308. [0074] The application layer controller 308 is configured to: control at least part of the aggregation protocol among network nodes in the network; manage operation(s) (e.g., mathematical operation(s)) performed by the ALUs; and select at least one network node (e.g., according to the aggregation protocol) to which to forward the resultant reduced data output by the central ALU 312-3.
Accordingly, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention, having the teachings of Innes and Elias before them, to include in in Innes’s resource proxy. Elias’s method to process a computation request by performing distributed reduction operations on partial results and progressively combining those partial results to generate a final computation result. One would have been motivated to make such modification to efficiently perform computations distributed among multiple network devices while maintaining processing throughout and reducing congestion. See Elias [0041-0046]
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Turovsky (US 20180046446 A1) – relates to creating a dependency map using Linux command ldd.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CARLOS A ESPANA whose telephone number is (703)756-1069. The examiner can normally be reached Monday - Friday 8 a.m - 5 p.m EST.
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, LEWIS BULLOCK JR can be reached at (571)272-3759. 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.
/C.A.E./Examiner, Art Unit 2199
/LEWIS A BULLOCK JR/Supervisory Patent Examiner, Art Unit 2199
Prosecution Insights