DETAILED ACTION
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 .
Claim Rejections - 35 USC § 102
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 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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1-3,5-10, 12-17 and 19-20 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Farrell et al. (US 20190391798 A1).
As per claim 1, Farrell et al. teaches the invention as claimed including, “A method of debugging applications for delivery via an application delivery server, comprising:
identifying, by a data processing system comprising one or more processors and memory, for an application submitted by an application developer, a messaging object configured with an action by the application developer;”
Software vendors can submit software applications through a developer portal. Applications submitted though the portal are made part of a store catalog which can be accessed by organizations through an organizational storefront, including, in particular, a storefront page listing available software applications (0056-0057). Telemetry data is collected from a first plurality of computing devices during the testing of a first software application. The collected telemetry data may include a collection of all known configuration data across multiple organizations for the software application (or version thereof) (0038). The collected telemetry data includes usage of a first plurality of features (messaging object configured with an action) of the first software application by the first plurality of computing devices. The telemetry data includes data regarding a particular feature (actions) of the first software application used by a user of one of the first plurality of computing devices as well as errors that occurred during such state (0039-0042).
“determining, by the data processing system, a classification score based on historical execution of the action of the messaging object provided by the application developer;”
First telemetry data from a first plurality of computing devices during testing of a first software application is collected. The collected telemetry data includes usage (historic execution) of a first plurality of features of the first software application. Based on the received telemetry data, the deployment tool creates a first plurality of mappings. For each mapping, the deployment tool determines a level of deployment success (classification score) (0038-0041). The deployment tool uses these mappings to develop a testing plan (0042). When the level of deployment success (classification score based of approved actions that are similar/debugging result) associated with the matching feature does not satisfy the predetermined threshold, the deployment tool adds the matching features to a test plan. Alternatively, when the level of deployment success associated with the matching feature satisfies the predetermined threshold, the deployment tool does not add the matching feature to the testing plan. The software associated with the tests plan (or portions thereof) may be automatically deployed to one or more groups of users when the level of deployment success associated with the matching feature satisfies the predetermine threshold. The testing plan includes features that should be tested when the first software application is deployed to the deploying organization (0047).
“updating, by the data processing system, a delivery control parameter based on the classification score, wherein the delivery control parameter comprises an indicator to cause the application delivery server to control delivery of the application; and
controlling, by the data processing system responsive to the delivery control parameter updated by the data processing system, delivery of the application by the application delivery server.”
When the level of deployment success associated with the matching feature does not satisfy the predetermined threshold, the deployment tool adds the matching features to a test plan (deployment control parameter/control authorization of the action/feature). Alternatively, when the level of deployment success associated with the matching feature satisfies the predetermined threshold, the deployment tool does not add the matching feature to the testing plan. The software associated with the tests plan (or portions thereof) may be automatically deployed to one or more groups of users when the level of deployment success associated with the matching feature satisfies the predetermine threshold (separately control delivery). The testing plan includes features that should be tested when the first software application is deployed to the deploying organization (0047). After the testing plan is generated as described above, the testing plan is implemented as part of the deploying of the software application within the deploying application. Implementing the testing plan may include one or more automatic tasks (0052).
As per claim 2, Farrell et al. further teaches, “The method of claim 1, comprising:
receiving, by the data processing system, the application from an application developer device; and”
Software vendors can submit software applications through a developer portal (0056-0057).
receiving, by the data processing system, a data file associated with the application comprising a plurality of actions established by the application developer for the application.”
Telemetry data (data file) is collected form a first plurality of computing devices during the testing of a first software application. The collected telemetry data may include a collection of all known configuration data across multiple organizations for the software application (or version thereof) (0038). The collected telemetry data include usage of a first plurality of features (actions) of the first software application by the first plurality of computing devices. The telemetry data includes data regarding a particular feature of the first software application used by a user of one of the first plurality of computing devices as well as errors that occurred during such state (0039).
As per claim 3, Farrell et al. further teaches, “The method of claim 1, comprising:
determining to authorize delivery of the application based on the classification score; and
updating the delivery control parameter to cause delivery of the application by the application delivery server.”
When the level of deployment success (classification score) associated with the matching feature does not satisfy the predetermined threshold, the deployment tool adds the matching features to a test plan (delivery control parameter). Alternatively, when the level of deployment success associated with the matching feature satisfies the predetermined threshold, the deployment tool does not add the matching feature to the testing plan. The software associated with the tests plan (or portions thereof) may be automatically deployed (delivery control parameter) to one or more groups of users when the level of deployment success (classification score) associated with the matching feature satisfies the predetermine threshold. The testing plan includes features that should be tested when the first software application is deployed to the deploying organization (0047-0048). After the testing plan is generated as described above, the testing plan is implemented as part of the deploying of the software application within the deploying application. Implementing the testing plan may include one or more automatic tasks. The administrator may use the testing plan to initiate tests of various features within a particular subset of the organization (0050).
As per claim 5, Farrell et al. further teaches, “The method of claim 1, wherein the indicator included in the delivery control parameter is an instruction, a numeric parameter, an alphanumeric value, a flag, or a tag.
When the level of deployment success (classification score) associated with the matching feature does not satisfy the predetermined threshold, the deployment tool adds the matching features to a test plan (instruction for delivery control parameter). Alternatively, when the level of deployment success associated with the matching feature satisfies the predetermined threshold (classification failure), the deployment tool does not add the matching feature to the testing plan. The software associated with the tests plan (or portions thereof) may be automatically deployed (delivery control parameter) to one or more groups of users when the level of deployment success (classification score) associated with the matching feature satisfies the predetermine threshold. The testing plan includes features that should be tested when the first software application is deployed to the deploying organization (0047-0048). After the testing plan is generated as described above, the testing plan is implemented as part of the deploying of the software application within the deploying application. Implementing the testing plan may include one or more automatic tasks. The administrator may use the testing plan to initiate tests of various features within a particular subset of the organization (0050).
As per claim 6, Farrell et al. further teaches, “The method of claim 1, further comprising:
selecting, by the data processing system based on metadata associated with the application, a second application that is similar to the application; and
determining a second classification score based on the action of the messaging object provided by the application developer and an action approved for the second action;”
The deployment tool uses mappings (metadata) to develop a testing plan for an organization for the first software application (for example a third organization). To develop a plan for the deploying organization, the deployment tool collects second telemetry data (metadata) from a second plurality of computing devices associated with the deploying organization. The second telemetry data may include data regarding the usage of a second software application (debugging results) by the deploying organization, including what features of the second software application are used by the users of the deploying organization. The first software application may be a new version of the software product, the second software application may be a previous version of the same software product currently being used (approved) by the deploying organization. Alternatively, the second software application may be a different application that the first software application but may provide similar functionality (Similar Application) (0042-0043). The deployment tool compares the first plurality of mappings(meta data) to the second plurality of mappings similar to the first plurality of mappings. The deployment tool may filter the first plurality of mappings before performing this comparison to compare the second plurality of mappings with mappings created for similarly-situated organizations. For example, when an organization in a banking industry is seeking assistance in deploying a particular software application, the deployment tool may apply one or more rules to identify similarly-situated organization and limit the telemetry data used to generate the mappings to telemetry data collected from these identified organizations (0044). The deployment tool may compare mappings by identifying whether a mapping included in the first plurality of mappings includes the same (identical or matching) feature as the feature included in a mapping included in the second plurality of mappings. The deployment tool may also identify mappings that refer to the same (identical or matching version) software application and have the same (identical or matching) profile. The deployment tool may allow some variance in the matching (0045). When a feature included in the second plurality of mapping is also included in the first plurality of mappings ( level of similarity), the electronic processor compares the level of deployment success with the features included in the first plurality of mappings to a predetermined threshold (0046).
When the level of deployment success (classification score based of approved actions that are similar/debugging result) associated with the matching feature does not satisfy the predetermined threshold, the deployment tool adds the matching features to a test plan. Alternatively, when the level of deployment success associated with the matching feature satisfies the predetermined threshold, the deployment tool does not add the matching feature to the testing plan. The software associated with the tests plan (or portions thereof) may be automatically deployed to one or more groups of users when the level of deployment success associated with the matching feature satisfies the predetermine threshold. The testing plan includes features that should be tested when the first software application is deployed to the deploying organization (0047).
“wherein the delivery control parameter is further updated based on the second classification score.”
When the level of deployment success associated with the matching feature does not satisfy the predetermined threshold, the deployment tool adds the matching features to a test plan (deployment control parameter/control authorization of the action/feature). Alternatively, when the level of deployment success associated with the matching feature satisfies the predetermined threshold, the deployment tool does not add the matching feature to the testing plan. The software associated with the tests plan (or portions thereof) may be automatically deployed to one or more groups of users when the level of deployment success associated with the matching feature satisfies the predetermine threshold (separately control delivery). The testing plan includes features that should be tested when the first software application is deployed to the deploying organization (0047). After the testing plan is generated as described above, the testing plan is implemented as part of the deploying of the software application within the deploying application. Implementing the testing plan may include one or more automatic tasks (0052).
As per claim 7, Farrell et al. further teaches, “The method of claim 1, further comprising:
generating a machine generated action for the application based on metadata associated with the application; and”
A testing plan (machine generated action) is generated (0047-0049). After the testing plan is generated, the testing plan is implemented as part of deploying the software application within the deploying application. Implementing the testing plan may include one or more automatic tests (0050).
“determining a second classification score based on the action of the messaging object provided by the application developer and the machine generated action;
wherein the delivery control parameter is further updated based on the second classification score.”
The deployment tool collects telemetry data and calculates confidence levels which are used to control a rollout process (0052-0053).
As per claims 8-10, 12-17 and 19-20, the contains similar limitations to claims 1-3, and 5-7. Therefore they are rejected for the same reasons.
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 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 4, 11, and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Farrell et al. (US 20190391798 A1) as applied to claims 1, 8 and 15 and further in view of Qureshi (US 20150199515 A1).
As per claim 4, Farrell et al. further teaches, “The method of claim 1, comprising:
determining a classification failure based on the classification score;”
When the level of deployment success (classification score) associated with the matching feature does not satisfy the predetermined threshold, the deployment tool adds the matching features to a test plan (delivery control parameter). Alternatively, when the level of deployment success associated with the matching feature satisfies the predetermined threshold (classification failure), the deployment tool does not add the matching feature to the testing plan. The software associated with the tests plan (or portions thereof) may be automatically deployed (delivery control parameter) to one or more groups of users when the level of deployment success (classification score) associated with the matching feature satisfies the predetermine threshold. The testing plan includes features that should be tested when the first software application is deployed to the deploying organization (0047-0048). After the testing plan is generated as described above, the testing plan is implemented as part of the deploying of the software application within the deploying application. Implementing the testing plan may include one or more automatic tasks. The administrator may use the testing plan to initiate tests of various features within a particular subset of the organization (0050).
However, Farrell et al. does not explicitly appear to teach, “updating, responsive to the classification failure, the delivery control parameter to block delivery of the application by the application delivery server; and
transmitting a notification to the application developer of the classification failure.”
Qureshi teaches, the application store may determine based on the integrity score whether to publish the application in the application store. The application may evaluate whether the integrity score for the application meets or exceeds one or more threshold values, and based on this evaluation, may determine whether to publish the application in the application store by making the application available to one or more users (0110). Qureshi further teaches, in response to determining not to publish the application in the application store, the application store may generate a notification indication that the application has an insufficient integrity score (0113).
It would have been obvious to one or ordinary skill in the art before the effective filing date to modify Farrell et al. et al. with Qureshi et al. because both teach verifying an app before allowing it to be deployed. Both also teach receiving the application at an application store. Qureshi teaches verifying the app in the application store before it is allowed to be published to be deployed and generating a notification if the integrity score fails. Therefore, it would have been obvious for Farrell et al. to also perform its deployment success verification in the application store in response to receiving the application, prior to allowing it to be deployed and to generate a notification if the application is not published due to an issue. One would not want to deploy an application that is not tested properly or has issues and a developer would need to be informed about an issue to fix it. Therefore, it would have been obvious to try.
As per claims 11 and 18, they contain similar limitations to claim 4. Therefore, they are rejected for the same reasons.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MARK A GOORAY whose telephone number is (571)270-7805. The examiner can normally be reached Monday - Friday 10:00am - 6: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, Lewis Bullock 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.
/MARK A GOORAY/ Examiner, Art Unit 2199
/LEWIS A BULLOCK JR/ Supervisory Patent Examiner, Art Unit 2199
Prosecution Insights