DETAILED ACTION
Claims 1-18 and 21-22 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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 02/03/2026 has been entered.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1, 2, 5, 6, 8-11, 12, and 15-18 are rejected under 35 U.S.C. 103 as being unpatentable over Samuel et al. (US 11,204,756 B1) in view of Landman et al. (US 2023/0139509 A1), in further view of Garman et al. (US 9,311,066 B1).
Samuel and Garman were cited in the previous Office Action.
Regarding claim 1, Samuel teaches the invention substantially as claimed including a method comprising:
receiving a mobile application that is for execution on a group of mobile devices (Col. 7, line 64 through Col. 8, line 18: In step 5a, it is assumed that optimal deployment detection engine 121 detects an update event relating to one or more software updates. This update event is intended to generally represent any occurrence or action relating to the deployment of one or more software updates. For example, the update event could be a request from update tool 113 on one of end user devices 110 for the one or more software updates. Update tool 113 could have identified that the one or more software updates are available by interfacing with a component of software update deployment solution 120. The update event could also be a request from an administrator that identifies the one or more software updates to be deployed. The update event could also be a notification received from another component of software update deployment solution 120 identifying the availability of the one or more software updates. In short, step 5a can represent any way in which optimal deployment detection engine 121 may determine that one or more software updates are available to be deployed on end user devices 110 (or a subset of end user devices 110). Of importance is that, at this step, optimal deployment detection engine 121 is aware of the particular software update(s) that are to be deployed.; Col. 11, line 2: mobile telephones);
receiving a first request with a deploy plan that specifies parameters for deploying the mobile application, wherein the deploy plan specifies a subset of mobile devices in the group of mobile devices that are to receive the mobile application (Col. 8, lines 19-23: In step 5b, optimal deployment detection engine 121 uses period-based groupings 210 to create an optimal deployment plan 220 for deploying the one or more software updates on each end user device 110 (or a subset of end user devices 110).; Col. 9, line 60-63: Turning to FIG. 2E, in step 6a, optimal deployment detection engine 121 can send each optimal deployment plan 220 to update tool 113 on the corresponding end user device 110); and
deploying the mobile application to the subset of mobile devices according to the deploy plan (In step 6b, update tool 113 can then cause each software update to be installed on the end user device 110 in accordance with the particular optimal deployment plan 220. For example, update tool 113 on end user device 110-1 could cause software update 2 to be installed during period P3 and could cause software update 1 to be installed during period Pn).
Samuel does not explicitly teach scanning the mobile application to determine whether the mobile application is secure and compliant in response to a determination that the configuration options or permissions granted by the mobile application are permitted; and
receiving a second request to alter the deploy plan in response to one or more errors in an operation of the mobile application being deployed.
However, Landman teaches scanning the mobile application to determine whether the mobile application is secure and compliant in response to a determination that the configuration options or permissions granted by the mobile application are permitted ([0009] When one or more files, including but not limited to a software release or software release update, are to be deployed, the additional node device may send a download approval request to an upstream node device, and the download approval request may be forwarded to the tracker device. The download approval request may correspond to at least part of one or more files, such as at least a portion of a binary. Based on the download approval request, the tracker device may determine whether the additional node device is permitted access to the files. For example, the tracker device may check one or more permissions or licenses corresponding to the additional node device to confirm that the additional node device is authorized to receive the portion of the file. Based on successful authorization of the additional node device, the tracker device may generate and/or send download information to a downstream distribution group to be forwarded (e.g., by the downstream distribution group or via multiple downstream distribution groups of multiple tiers of the hierarchical network) to the additional node device. In some implementations, the download information may include metadata, such as a checksum for each portion of multiple portions of a file and a checksum for the file. Additionally or alternatively, based on the download approval request and successful authorization of the additional node device, the tracker device may generate and/or send an authorization indicator, such as a token, to the additional node device via one or more intermediate distribution groups…Although described as two separate requests, in some implementations, the registration request process and the download approval request process may be combined in a single registration process that causes the tracker device to provide the registration response, the group key(s), the download information, and the authorization indicator (e.g., the token) to the additional node device. Additionally, although described as the additional node device requesting the one or more files (e.g., a pull operation), in other implementations, the one or more files may be distributed throughout the hierarchical network in a top-down manner (e.g., a push operation), such as via a proactive push distribution of a software release.; [0065] Deployer 253 may enable generation of a release bundle, auditing and traceability by tracking all changes associated with a release bundle distribution of the release bundle including permission levels release content, scheduling of a release bundle for distribution, tracking of a release bundle, stopping distribution of a release bundle, and/or selection of target destinations. Additionally, or alternatively, a software release may be provisioned amongst one or more node devices (e.g., 160a, 160b, 160c, 160d). In some implementations, as part of the release flow, release bundles are verified and validated by the source and/or destination to ensure that they are signed correctly and safe to use.; [0126] For example, tracker device 510 may update topology information 516 based on node device 560 joining the hierarchical network (e.g., via registration request message 580) to indicate assignment of node device 560 to a group or a tier within the hierarchical network. Additionally, the server or tracker device is able to check permissions and authorizations of devices prior to allowing the devices to join the hierarchical network or download the software release or files, providing improved security and varying permissions to be applied to different node devices and/or users, as compared to a typical P2P network.).
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 Landman of verifying the origin and integrity of a software to be deployed in devices that have associated permissions with the teachings of Samuel of selectively deploying an application to devices. The modification would have been motivated by the desire of ensuring the application is vetted prior to deployment can be performed in a safe and hassle-free manner.
Samuel nor Landman teach receiving a second request to alter the deploy plan in response to one or more errors in an operation of the mobile application being deployed.
However, Garman teaches a method for managing update deployment. Further, Garman teaches receiving a second request to alter the deploy plan in response to one or more errors in an operation of the mobile application being deployed (Abstract and Fig. 4 step 408 “Transmit deployment command to determined computing devices” discusses a first request with a deployment plan. Fig. 4 step 412 “Execute responsive action” corresponds to the second request to alter as supported by at least the following sections; Col. 2, line 32 through Col. 3, line 28: In an illustrative embodiment, an update deployment manager may deploy an update to a set of computing devices, while concurrently monitoring for potential effects of deploying the update. In some embodiments, the update deployment manager may monitor the set of computing devices themselves (e.g., to ascertain direct effects of deploying the update). In other embodiments, the update deployment manager may monitor alternative computing devices which may be affected by deployment of the update. For example, an update deployed to a back-end or non-user facing computing device may affect performance of a front-end or user facing computing device. As such, in order to deploy the update to an initial set of computing devices, the update deployment manager may issue an update deployment command to an initial set of computing devices. Thereafter, the computing devices in the initial set may receive and implement the update. During or subsequent to implementation of the update, the update deployment manager may receive monitoring information from a set of monitored computing devices, which may include one or more of the computing devices in the initial set. Illustratively, monitoring information may include any of a number of performance metrics of the operation of a computing device, such as latency, communication failure rate, available or used processing power, etc., as will be described in more detail below. In response to received monitoring information, the update deployment manager may modify further deployment of the update to additional computing devices. For example, received monitoring information may indicate that deployment of the update had a negative effect on one or more computing devices. As such, the update deployment manager may slow deployment of the update (e.g., to gather further information regarding the effects of the update), halt deployment of the update, or rollback the update (e.g., cause the initial set of computing devices to remove, uninstall, or de-implement the update)… As described above, the update deployment manager may modify aspects related to the deployment of an update. In some embodiments, modifying an aspect of the deployment of the update may include modifying the rate of deployment… As a further example, if performance metrics associated with the update or the computing devices implementing the update are negative, the update deployment manager may decrease the rate of deployment of the update. In some embodiments, where performance metrics are negative, deployment of an update may be halted. In still more embodiments, where performance metrics are negative, an update may be rolled back. As used herein, rollback of an update may generally refer to removing the update from one or more computing devices (e.g., by uninstalling the update or undoing modifications caused by the update). As such, the deployment of an update to multiple computing devices may be controlled based on monitored performance metrics gathered in response to deployment.; Col. 8, line 62 through Col. 9, line 61: Subsequent to analysis of received monitoring information, the update deployment manager (e.g., via the scheduling module 114) may determine a deployment strategy in response to the analyzed monitoring information. Illustratively, a deployment strategy may include any one of halting or preventing deployment of the update to additional computing devices (such as computing devices 106A or 106B), rolling back deployment of the update (e.g., removing or de-implementing the update from at least one computing device), modifying a rate of deployment of the update to additional computing devices (e.g., lowering or raising the rate of deployment of the update), or maintaining the current rate of deployment of the update to additional computing devices.; Fig. 3A-C).
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 Garman with the teachings of Samuel and Landman to determine after the deployment of the software update whether any issues occurred and determine to alter the plan. The modification would have been motivated by the desire of ensuring the devices operate in an optimal manner.
Regarding claim 2, Samuel teaches wherein the subset of the group of mobile devices are related to each other based on location or type (Col. 2, line 65 through Col. 3, line 3: In a common example, end user devices 110 could represent a group or all of a particular entity's end user devices that are managed by an IT department. However, end user devices 110 could represent any other suitable combination of end user devices including a group or all of a particular OEM's (e.g., Dell's or HP's) end user devices. i.e., type).
Regarding claim 5, Samuel teaches wherein the deploy plan further specifies one or more of locations associated with the subset of mobile devices, a time period during which deployment of the mobile application to the subset of mobile devices is to take place (Col. 1, lines 17-19: For example, an administrator may schedule the deployment of a software update for a particular time.), a percentage of the subset of mobile devices that are to receive the mobile application, or configuration or setting changes involved with the mobile application (Col. 1, lines 25-29: when a software update addresses a security vulnerability, an administrator may force the immediate deployment of the software update (i.e., the end user will have no option to postpone the installation of the software update)).
Regarding claim 6, Samuel teaches wherein the mobile application comprises: a new version of a previously existing mobile application, the previously existing mobile application with a configuration change (Abstract: The installation of the software updates can then be performed on each end user device in accordance with that end user device's optimal deployment plan.; Col. 3, line 58 through Col. 4, line 4), or a new application.
Regarding claim 8, Landman teaches
cryptographically signing, via a signing service, the mobile application in response to a determination that the mobile application is secure and compliant ([0064] Additionally, or alternatively, the software release information may include a signature (or other cryptography technique) to render the release bundle information immutable.).
Regarding claim 10, it is a system type claim having similar limitations as claim 1 above. Therefore, it is rejected under the same rationale above.
Regarding claim 11, it is a system type claim having similar limitations as claim 8 above. Therefore, it is rejected under the same rationale above.
Regarding claim 12, it is a system type claim having similar limitations as claim 2 above. Therefore, it is rejected under the same rationale above.
Regarding claim 15, it is a system type claim having similar limitations as claim 5 above. Therefore, it is rejected under the same rationale above.
Regarding claim 16, it is a system type claim having similar limitations as claim 6 above. Therefore, it is rejected under the same rationale above.
Regarding claim 17, it is a media/product type claim having similar limitations as claim 1 above. Therefore, it is rejected under the same rationale above.
Regarding claim 18, it is a media/product type claim having similar limitations as claim 2 and 8 above. Therefore, it is rejected under the same rationale above.
Claims 3 and 13 are rejected under 35 U.S.C. 103 as being unpatentable over Samuel, Landman and Garman, as applied to claim 1, in further view of Ustaris (US 2004/0060035 A1)
Regarding claim 3, Samuel teaches creating a deployment plan to update a subset of end user mobile devices but neither Samuel, Landman nor Garman explicitly teach wherein the deploy plan specifies whether the at least one mobile application is to be in a foreground or a background on at least a first mobile device of the group of mobile devices.
However, Ustaris teaches wherein the deploy plan specifies whether the at least one mobile application is to be in a foreground or a background on at least a first mobile device of the group of mobile devices (Title: Automated Method And System For Building, Deploying And Installing Software Resources Across Multiple Computer Systems; [0064]; [0066] Afterwards, the system then creates a new deployment info file in the deployment directories as shown in block 624. To perform this, the system creates a file containing information that will be utilized by the deploy/install process. This file is utilized as a signal for a process executing in the background to install the newly deployed software package on the destination machine automatically.).
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 Ustaris with the teachings of Samuel, Landman and Garman to have the updates performed by a background process on the destination device. The modification would have been motivated by the desire of ensuring execution on destination machine is not affected by the newly deployed software.
Regarding claim 13, it is a system type claim having similar limitations as claim 3 above. Therefore, it is rejected under the same rationale above.
Claims 4 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Samuel, Landman and Garman, as applied to claim 1, in further view of Fanshier (US 2006/0041643 A1).
Regarding claim 4, Samuel, Landman and Garman do not expressly teach wherein receiving a first request with the deploy plan is via an application programming interface.
However, Fanshier teaches wherein receiving a first request with the deploy plan is via an application programming interface ([0072] Management of deployment plans is handled chiefly via the deployment API, which is based on JSR88. This API is geared towards use by deployment tools and provides for creation, modification, validation and deployment of deployment plans. The basic API (JSR88) provides tools with [0073] plan creation--when presented with an application a configuration (the deployment plan) is constructed.).
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 Fanshier with the teachings of Samuel, Landman and Garman to utilize an API for deployment purposes. The modification would have been motivated by the desire of providing integration and efficiency to perform and manage deployment tasks.
Regarding claim 14, it is a system type claim having similar limitations as claim 4 above. Therefore, it is rejected under the same rationale above.
Claims 7 and 9 are rejected under 35 U.S.C. 103 as being unpatentable over Samuel, Landman and Garman, as applied to claim 1, in further view of Tsai (US 2018/0197180 A1).
Regarding claim 7, Samuel, Landman nor Garman teach wherein the mobile application performs transaction processing when executed on mobile devices in the group of mobile devices, and wherein the mobile application comprises a first application to execute, when running on a respective mobile device, a payment flow for processing transaction and a second reader application for handling a payment for the payment flow.
However, Tsai teaches wherein the mobile application performs transaction processing when executed on mobile devices in the group of mobile devices, and wherein the mobile application comprises a first application to execute, when running on a respective mobile device, a payment flow for processing transaction and a second reader application for handling a payment for the payment flow ([0003] A typical payment terminal comprises of an interface for PIN entry, one or more card reader interfaces for interfacing with cards, a communication interface for communicating with the financial institution that processes the transaction, and payment applications to handle the transaction flow and handle the human interaction with the transaction flow, and user interfaces such as a screen, keypad, or touch panel for providing the means for user interaction. The high cost of payment terminal prevents small merchants to accept card payments.; [0004] More recently, smart phones and tablets have become very common, and most of the functionality in a traditional payment terminal can be realized on a smart device. The payment applications can be run on smart devices, and the smart devices provides various communication methods to connect with transaction processing entities.).
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 Tsai of payment applications with the teachings of Samuel, Landman and Garman of managing/updating applications. The modification would have been motivated by the desire of combining known elements to yield predictable results.
Regarding claim 9, Tsai teaches wherein the subset of mobile devices comprise mobile terminals for use in processing payments for transactions ([0003]).
Claims 21-22 are rejected under 35 U.S.C. 103 as being unpatentable over Samuel, Landman and Garman, as applied to claim 1, in further view of Nagaraja et al. (US 2020/0202007 A1).
Regarding claim 21, Samuel, Landman nor Garman do not expressly teach wherein scanning the mobile application to determine that the mobile application is secure and compliant further includes: performing vulnerability scanning to determine if the mobile application is susceptible to malicious attacks.
However, Nagaraja wherein scanning the mobile application to determine that the mobile application is secure and compliant further includes: performing vulnerability scanning to determine if the mobile application is susceptible to malicious attacks ([0018], [0019], [0024], [0041], [0042] The risk assessment module 130D-3, in conjunction with the processor 130A, can determine if there are known risks in an application. The risk assessment module 130D-3, in conjunction with the processor 130A, can receive information from the license database server and the security risk database server about potential vulnerabilities. The risk assessment module 130D-3, in conjunction with the processor 130A, may then scan the application to determine if the vulnerabilities identified by the license database server and the security risk database server are present in the application.; [0050]; [0066] In step 328, the remediation computer may use the final application precursor and the recommendations to determine a final application. Determining a final application may include automatically incorporated library versions and/or recommended manual changes. The final application can then, for example, be sent to another computer in the network for further testing or deployed as a complete application.; [0109] application vulnerability is performed prior to deployment of the application).
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 Nagaraja with the teachings of Samuel, Landman and Garman to verify an application for vulnerabilities prior to deployment. The modification would have been motivated by the desire of ensuring vulnerabilities are discovered prior to deployment and reduce time to address the issues. See at least Nagaraja’s [0109].
Regarding claim 22, it is a method type claim having similar limitations as claim 21 above. Therefore, it is rejected under the same rationale above.
Response to Arguments
Applicant’s arguments with respect to claims 1-18 and 21-22 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.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JORGE A CHU JOY-DAVILA whose telephone number is (571)270-0692. The examiner can normally be reached Monday-Friday, 6:00am-5:00pm.
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 J 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.
/JORGE A CHU JOY-DAVILA/Primary Examiner, Art Unit 2195