DETAILED ACTION
1. Claims 1-20 are pending.
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
2. Applicant’s arguments, see Remarks, filed January 21, 2026, with respect to the rejection(s) of claim(s) 1-20 under 35 U.S.C. 103 have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made.
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.
3. Claims 1, 3-5, 7-8, 10-12, 14-17, and 19-20 are rejected under 35 U.S.C. 103 as being
unpatentable over Jenson et al. US 20200174770 A1 in view of Arcese et al. US 20180217827 A1.
4. With regard to claim 1, Jenson teaches:
A computerized method of executing an application based on a uniform resource identifier (URI), the method comprising:
receiving, at a client computing device, user input indicating activation of the URI, the URI comprising a scheme name, an application identifier for an application, and a launch identifier ([0103] Returning to the method of FIG. 3 for creating a deployment, after the application is created at step 306, the identifier for the application object is received by application ReST call 254 from webserver 214 at step 308. At step 310, a request is submitted to the webserver to deploy the application to the devices. In accordance with one embodiment, the request is made through a deployment ReST call 256 on device 222, which submits a request to create a deployment using deployment resource 210 while passing the received collection identifier and the received application identifier. In accordance with one embodiment, the request for creation of the deployment is submitted as:
[0104] POST/deployment URI HTTP/1.1; Examiner’s Note: This is the scheme (http).
[0105] Content-type: application/JSON
[0106] Authorization: OAUTH access token
[0107] key: consumer key
[0108] application_id : Identifier of Application to be deployed; Examiner’s Note: Application identifier for an application
[0109] collection_id : Identifier of user or device collection that Application is to be deployed to; Examiner’s Note: Launch identifier
[0110] offer_type_id : Required/Available
[0111] desired_config_type : Install/Uninstall,
[0112] start_time : Date/time to make deployment available
[0113] enforcement_deadline : Date/Time by which devices must accept deployment
[0114] use_gmt_times : True/False
[0115] override_service_windows : True/False
[0116] reboot_outside_of_service_windows : True/False
[0117] require_approval : True/False
[0118] notify_user : True/False
[0119] wol enabled : True/False
[0120] deployment_description : Description of deployment
);
transmitting an application request to an application manager server, the application request including at least the application identifier and the launch identifier ([0122] FIG. 8 provides a flow diagram of a method performed by webserver 214 and API methods 216 to create a deployment. In step 800, a POST request to create the deployment is received from deployment ReST call 256 by webserver 214. At step 802, webserver 214 parses the request to retrieve the collection ID, the application ID, the start time, and the enforcement deadline, if any; Examiner’s Note: The webserver is acting as an application manager server. It parses the POST request, which includes a URI that contains the application ID (application identifier) and collection ID (launch identifier).);
Jenson fails to explicitly teach receiving, from the application manager server, an assignment of a virtual disk associated with the application and an execution path of the application; mounting, at the client computing device, the virtual disk; and executing the application from the virtual disk using the execution path.
However, in analogous art, Arcese teaches:
receiving, from the application manager server, an assignment of a virtual disk associated with the application and an execution path of the application ([0037] More specifically, each update that has been applied to the preparation machine generally comprises the modification of one or more artifacts thereof (for example, registries, databases), which are identified by corresponding artifact (unique) identifiers in the preparation machine (for example, a full path of files in the file system of the preparation machine, starting from the root until reaching the files through any interposed sub-directories); [0042] For each new virtual disk, the maintenance agent searches the application identifier extracted therefrom in the disk list. If the application identifier is not found, the new virtual disk is for the first installation of the corresponding software application, whereas on the contrary the new virtual disk is for the maintenance of a current level of the same software application, already installed in a corresponding (current) virtual disk, to a new level thereof (assuming that the level identifier of the new virtual disk is different form the level identifier of the current virtual disk).);
mounting, at the client computing device, the virtual disk ([0042] In any case, the maintenance agent dismounts a (local) file system of the current virtual disk from a corresponding mounting point within a (global) file system of the virtual machine, and then mounts a (local) file system of the new virtual disk to the same mounting point. The maintenance agent bounds each generalized identifier of the activation procedures extracted from the new virtual disk to corresponding values depending on the virtual machine (for example, the mounting point for the path to the local file system of the new virtual disk) and then runs the activation procedures.); and
executing the application from the virtual disk using the execution path ([0042] At the end, the maintenance agent detaches the current virtual disk from the virtual machine, updates the disk list accordingly and executes the start command extracted from the new virtual disk to re-start the software application (if necessary).).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Jenson with the teachings of Arcese receiving, from the application manager server, an assignment of a virtual disk associated with the application and an execution path of the application; mounting, at the client computing device, the virtual disk; and executing the application from the virtual disk using the execution path. Jenson teaches of how a URI can initiate the execution of an on-demand application through key identifiers in the application’s URI. The URI contains information such as application ID and destination of the application. Jenson also teaches that a deployment point is able to “retrieve the installation or update package. Once a device has downloaded an installation package, it invokes an install command provided as part of the installation package to install the application or update on the device” ([0019]). Similarly, Arcese teaches of copying a software application over to a virtual disk. The activation procedures and activation information obtained, which are similar to the installation or update package of Jenson, are able to be packaged and mounted to a virtual disk ([0005]; [0016]; [0042]). This enables the user to remotely access applications from device to device, without having to download the application locally on each device, as discussed in Arcese ([0013]).
5. With regard to claim 3, Jenson further teaches:
further comprising:
registering a URI handler of the client computing device to redirect URI processing to an agent service for URIs having the scheme name ([0021] In accordance with one embodiment, webserver 214 supports at least one HTTP request method for each resource URI, such as GET, POST, PUT, and DELETE, for example. Each resource corresponds to an object used by deployment management tool 102 and stored in a deployment database 230. Thus, application resource 204 corresponds to Application objects that describe applications that are to be deployed, collection resource 206 corresponds to Collection objects that describe collections of devices or users that are to receive deployed applications, maintenance window resource 208 corresponds to Maintenance Window objects that describe time periods when devices associated with a collection can receive a deployment and deployment resource 210 corresponds to Deployment objects that describe parameters of deployments. In general, if the GET method is supported for a resource, web server 214 will use deployment management tool 102 to retrieve one or more corresponding objects from deployment database 230; if the POST method is supported, web server 214 will use deployment management tool 102 to create a new corresponding object in deployment database 230; if the PUT method is supported, web server 214 will use deployment management tool 102 to change a corresponding object in deployment database 230; and if the DELETE method is supported, web server 214 will use deployment management tool 102 to remove a corresponding object from deployment database 230; Examiner’s Notes: There are different objects that describe what to do with applications. Based on the objects, the deployment management tool (agent service) will complete the request accordingly. Examples of types of requests are given.); and
identifying, by the client computing device and in response to the receiving of the user input, the agent service registered to process the URI based on the scheme name ([0021] In accordance with one embodiment, webserver 214 supports at least one HTTP request method for each resource URI, such as GET, POST, PUT, and DELETE, for example. Each resource corresponds to an object used by deployment management tool 102 and stored in a deployment database 230. Thus, application resource 204 corresponds to Application objects that describe applications that are to be deployed, collection resource 206 corresponds to Collection objects that describe collections of devices or users that are to receive deployed applications, maintenance window resource 208 corresponds to Maintenance Window objects that describe time periods when devices associated with a collection can receive a deployment and deployment resource 210 corresponds to Deployment objects that describe parameters of deployments. In general, if the GET method is supported for a resource, web server 214 will use deployment management tool 102 to retrieve one or more corresponding objects from deployment database 230; if the POST method is supported, web server 214 will use deployment management tool 102 to create a new corresponding object in deployment database 230; if the PUT method is supported, web server 214 will use deployment management tool 102 to change a corresponding object in deployment database 230; and if the DELETE method is supported, web server 214 will use deployment management tool 102 to remove a corresponding object from deployment database 230; Examiner’s Notes: There are different objects that describe what to do with applications. Based on the objects, the deployment management tool (agent service) will complete the request accordingly. Examples of types of requests are given.).
6. With regard to claim 4, Jenson further teaches:
wherein executing the application includes executing the application as a user other than a requesting user that activates the URI ([0071] Thus, the maintenance window designates a period of time and one or more dates during which an application may be deployed to the devices listed in a collection of devices or devices operated by a collection of users; [0121] The body of the request includes the application ID for the application to be deployed and the collection ID for the collection of devices or users that the application is to be deployed to; Examiner’s Note: The application is deployed to multiple users, not just the user that activates the URI.).
7. With regard to claim 5, Arcese further teaches:
further comprising requesting, from the application manager server, the execution path of the application ([0037] More specifically, each update that has been applied to the preparation machine generally comprises the modification of one or more artifacts thereof (for example, registries, databases), which are identified by corresponding artifact (unique) identifiers in the preparation machine (for example, a full path of files in the file system of the preparation machine, starting from the root until reaching the files through any interposed sub-directories); [0042] The maintenance agent bounds each generalized identifier of the activation procedures extracted from the new virtual disk to corresponding values depending on the virtual machine (for example, the mounting point for the path to the local file system of the new virtual disk) and then runs the activation procedures; Examiner’s Note: The maintenance agent is analogous with the application manager server.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Jenson with the teachings of Arcese further comprising requesting, from the application manager server, the execution path of the application. By requesting and accessing the execution path of the application, the application manager server is able to know the instructions for launching the application, as discussed in Arcese ([0042]). This ensures that the application is correctly executed at the right destination; therefore, ensuring that the user is able to access their desired application seamlessly.
8. With regard to claim 7, Jenson further teaches:
wherein the URI further includes a command, wherein the command includes one of (i) a launch command configured to cause delivery and launch of the application and (ii) a deliver command configured to cause delivery of the application ([0021] In accordance with one embodiment, webserver 214 supports at least one HTTP request method for each resource URI, such as GET, POST, PUT, and DELETE, for example. Each resource corresponds to an object used by deployment management tool 102 and stored in a deployment database 230. Thus, application resource 204 corresponds to Application objects that describe applications that are to be deployed, collection resource 206 corresponds to Collection objects that describe collections of devices or users that are to receive deployed applications, maintenance window resource 208 corresponds to Maintenance Window objects that describe time periods when devices associated with a collection can receive a deployment and deployment resource 210 corresponds to Deployment objects that describe parameters of deployments. In general, if the GET method is supported for a resource, web server 214 will use deployment management tool 102 to retrieve one or more corresponding objects from deployment database 230; if the POST method is supported, web server 214 will use deployment management tool 102 to create a new corresponding object in deployment database 230; if the PUT method is supported, web server 214 will use deployment management tool 102 to change a corresponding object in deployment database 230; and if the DELETE method is supported, web server 214 will use deployment management tool 102 to remove a corresponding object from deployment database 230; Examiner’s Note: POST launches a command to cause delivery and launch of an application by creating a new application, and GET retrieves the application identifiers in order to be delivered.).
9. Regarding claim 8, it is rejected under the same reasoning as claim 1 above. Therefore, it is rejected under the same rationale.
10. Regarding claim 10, it is rejected under the same reasoning as claim 3 above. Therefore, it is rejected under the same rationale.
11. Regarding claim 11, it is rejected under the same reasoning as claim 4 above. Therefore, it is rejected under the same rationale.
12. Regarding claim 12, it is rejected under the same reasoning as claim 5 above. Therefore, it is rejected under the same rationale.
13. Regarding claim 14, it is rejected under the same reasoning as claim 7 above. Therefore, it is rejected under the same rationale.
14. Regarding claim 15, it is rejected under the same reasoning as claim 1 above. Therefore, it is rejected under the same rationale.
15. Regarding claim 16, it is rejected under the same reasoning as claim 7 above. Therefore, it is rejected under the same rationale.
16. Regarding claim 17, it is rejected under the same reasoning as claim 1 above. Therefore, it is rejected under the same rationale.
17. Regarding claim 19, it is rejected under the same reasoning as claim 1 above. Therefore, it is rejected under the same rationale.
18. With regard to claim 20, Jenson further teaches:
the method further comprising:
providing an application programming interface (API) configured to respond to requests from the agent device ([0020] In particular, webserver 214 interacts with deployment management tool 102 through one or more API methods 216 on deployment management server 104 where API methods 216 are able to call methods within deployment management tool 102 directly.);
receiving, via the API, an execution path request from the agent device for the execution path of the application, the execution path request including the application identifier ([0122] FIG. 8 provides a flow diagram of a method performed by webserver 214 and API methods 216 to create a deployment. In step 800, a POST request to create the deployment is received from deployment ReST call 256 by webserver 214. At step 802, webserver 214 parses the request to retrieve the collection ID, the application ID, the start time, and the enforcement deadline, if any. At step 804, webserver 214 uses API methods 216 to create a deployment object in deployment management tool 102. In accordance with one embodiment, this involves storing an identifier for the deployment object in deployment database 230. At step 806, webserver 214 sets the collection for the deployment object to the parsed collection ID. At step 808, webserver 214 uses API methods 216 to set the application for the deployment object to the parsed application ID. At step 810, webserver 214 uses API methods 216 to set the schedule of the deployment for the deployment object.); and
transmitting the execution path to the agent device in response to the execution path request ([0122] Once the deployment has been created, deployment management tool 102 will use the schedule stored for the deployment to trigger the deployment and the information associated with the identified application and the identified collection will be used by deployment management tool 102 to locate and deploy the installation files for the application and to distribute them to the devices represented by the collection.).
19. Claims 2 and 9 are rejected under 35 U.S.C. 103 as being unpatentable over Jenson et al. US 20200174770 A1 and Arcese et al. US 20180217827 A1, as applied in claim 1, in further view of Tshouva et al. US 20200159553 A1.
20. With regard to claim 2, Jenson and Arcese teach the computerized method of claim 1 but fail to explicitly teach wherein the launch identifier is a hash of the execution path.
However, in analogous art, Tshouva teaches:
wherein the launch identifier is a hash of the execution path ([0057] Each of the intermediate code file(s) may be analyzed to identify the plurality of routines. Each intermediate code file may be further analyzed to identify one or more valid executions paths, in particular valid executions paths leading to execution of one of the critical routine(s). Each of the valid executions paths may describe a respective order of execution of one or more preceding routines executed prior to execution of a critical routine. For example, a Control flow Graph (CFG) may be generated for the intermediate code file(s) to identify the valid executions path(s) and the preceding routine(s). In order to identify each of the valid execution path(s), each of the plurality of routines may be assigned with a unique identifier such that each of the valid execution path(s) may be represented by a respective ordered pattern concatenating the unique identifiers of the preceding routines identified to execute along the respective valid execution path. Moreover, each of the valid execution path(s) may be represented by a hash value calculated for the respective ordered pattern concatenating the unique identifiers of the preceding routine(s) identified along the respective valid execution path. In particular, the hash value may be calculated using one or more rolling hash functions.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Jenson and Arcese with the teachings of Tshouva wherein the launch identifier is a hash of the execution path. Jenson and Arcese teach of an application package that includes executable code and configuration data for remote application execution. These packages are similar to the intermediate code files that are taught in Tshouva. Each intermediate code file is analyzed for one or more valid execution paths. These execution paths are then represented by a hash value ([0057]). This provides a layer of security in order to protect execution path data from malicious cyber threats. Hashes create a unique identifier that helps identify data that has been tampered with.
21. Regarding claim 9, it is rejected under the same reasoning as claim 2 above. Therefore, it is rejected under the same rationale.
22. Claims 6 and 13 are rejected under 35 U.S.C. 103 as being unpatentable over Jenson et al. US 20200174770 A1 and Arcese et al. US 20180217827 A1, as applied in claim 1, in further view of Lee et al. US 20130151672 A1.
23. With regard to claim 6, Jenson and Arcese teach the computerized method of claim 1 but fail to explicitly teach further comprising caching a plurality of application identifiers and associated execution paths for a plurality of applications previously mounted on the client computing device.
However, in analogous art, Lee teaches:
further comprising caching a plurality of application identifiers and associated execution paths for a plurality of applications previously mounted on the client computing device ([0016] The downloading and executing an execution file may include determining whether the execution file of the requested application has been previously stored, determining whether a version of the previously stored execution file is the most recent version when in response to a determination that the execution file of the requested application has been previously stored, and executing the previously stored execution file in response to a determination that the version of the previously stored execution file is the most recent version.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Jenson and Arcese with the teachings of Lee further comprising caching a plurality of application identifiers and associated execution paths for a plurality of applications previously mounted on the client computing device. Similarly to Jenson and Arcese, Lee teaches of a receiving, by a computing apparatus, a virtual disc for executing an application from a server connected to the computing apparatus; transmitting a request to execute the application; and downloading and executing an execution file corresponding to the requested application, ([0011]). This is similar to Jenson and Arcese’s teachings of an application package that is received by a computing device through a virtual disk. The application package contains information such as execution path. Lee continues to teach determining whether the application has been previously stored. If it has and it is the most recent version, the previously stored application is executed. This prevents the computing device from having to redownload configuration data and other data; therefore, avoiding redundant processes and allowing the user to access the application quickly.
24. Regarding claim 13, it is rejected under the same reasoning as claim 6 above. Therefore, it is rejected under the same rationale.
25. Claim 18 is rejected under 35 U.S.C. 103 as being unpatentable over Jenson et al. US 20200174770 A1 and Arcese et al. US 20180217827 A1, as applied in claims 1 and 17, in further view of Gabryjelski et al. US 20220236858 A1.
26. With regard to claim 18, Jenson and Arcese teach the non-transitory computer storage medium of claim 17 but fail to explicitly teach wherein the GUI is further configured to provide a URI copy button, the URI copy button being configured to copy the URI to a buffer of the agent device.
However, in analogous art, Gabryjelski teaches:
wherein the GUI is further configured to provide a URI copy button, the URI copy button being configured to copy the URI to a buffer of the agent device ([0110] In accordance with an embodiment, original URIs determined by original URI determiner 118 and/or the final redirect URI are stored buffer 1208 responsive to a copy operation. For instance, when a user provides user input to copy a final redirect URI displayed in an address bar of user interface 128, original URI determiner 118 may determine and/or provide the determined original URI (shown as original URI 1210) to buffer 1208. Original URI determiner 118 may determine original URI 1210 based on an application of rule(s) 130, as described above with reference to FIG. 1. Original URI determiner 118 may further specify a format of original URI 1210. For example, original URI determiner 118 may specify that the URI being provided to buffer 1208 is an original URI. User interface 128 may also provide the final redirect URI (shown as final redirect URI 912) to buffer 1208. User interface 128 may further specify a format of final redirect URI 1212. For example, user interface 128 may specify that the URI being provided to buffer 1208 is the final redirect URI that is displayed in the address bar of user interface 128. Examples of user input for copying text, include, but are not limited to highlighting the text (e.g., the final redirect URI) and pressing a combination of one or more keys (e.g., CTRL+C) on a keyboard, selecting a menu option made available, e.g., via user interface 128 and/or operating system 1202, etc.; Examiner’s Note: Copy and pasting a URI into a buffer can be done through a menu option made available through a user interface, which to one of ordinary skill in the art could infer is a button.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Jenson and Arcese with the teachings of Gabryjelski wherein the GUI is further configured to provide a URI copy button, the URI copy button being configured to copy the URI to a buffer of the agent device. Gabryjelski teaches of storing URIs in a buffer. This is similar to Jenson and Arcese, which teach of a URI that contains execution paths for an application. It would be obvious to one of ordinary skill in the art that when a URI from Jenson and Arcese is copied in order to be executed, the copied URI is currently stored in a buffer until time for execution. That being said, Gabryjelski teaches of methods of copy and pasting a URI in order to be stored in a buffer, and the copy and pasting can be done through a menu made option such as via user interface, ([0110]). One of ordinary skill in the art can infer an option made available through a user interface could be a button. Having a button in order to copy and paste a URI allows a user to quickly copy a URI in an intuitive and simple way. Therefore, helping the user access their desired application through the URI as efficiently as possible.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to AN-AN N NGUYEN whose telephone number is (571)272-6147. The examiner can normally be reached Monday-Friday 8:00-5:00 ET.
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, AIMEE LI can be reached at (571) 272-4169. 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.
/AN-AN NGOC NGUYEN/Examiner, Art Unit 2195
/Aimee Li/Supervisory Patent Examiner, Art Unit 2195