Detailed Action
This is a Non-final Office action in response to communications received on 2/11/2025. Claims 1-20 are pending and are examined.
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 .
Drawings
The drawings, filed 2/11/2025 are acknowledged.
Foreign Priority
The foreign priority date of 12/20/2024 is acknowledged.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-16 are also rejected under 35 U.S.C. 101 as not falling within one of the four statutory categories of invention because the claims are directed to software per se.
Under 35 U.S.C. 101, a claimed invention must fall within one of the four eligible categories of invention (i.e. process, machine, manufacture, or composition of matter) and must not be directed to subject matter encompassing a judicially recognized exception as interpreted by the courts. MPEP § 2106. The four eligible categories of invention include: (1) process which is an act, or a series of acts or steps, (2) machine which is an concrete thing, consisting of parts, or of certain devices and combination of devices, (3) manufacture which is an article produced from raw or prepared materials by giving to these materials new forms, qualities, properties, or combinations, whether by hand labor or by machinery, and (4) composition of matter which is all compositions of two or more substances and all composite articles, whether they be the results of chemical union, or of mechanical mixture, or whether they be gases, fluids, powders or solids. MPEP 2106(I).
Claims 1 and 11 are directed to an application deployment platform . The Specification does not explicitly limit the platform nor its components to hardware. It is not sufficient to specify that the system is designed to perform a function – the claim must recite what hardware the system itself comprises which performs the claimed functions. The claim does not disclose the system as comprising any sort of physical device or machine to perform the functions of the platform. As such, the claims are interpreted as being directed to software per se.
Dependent claims 2-10 and 12-16 fail to remedy the deficiencies of claims 1 and 11 and therefore are similarly rejected. The Examiner recommends amending the independent claim to disclose the steps being performed by a physical device or machine.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claim 4 is rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 4 contains the trademark/trade name Jira. Where a trademark or trade name is used in a claim as a limitation to identify or describe a particular material or product, the claim does not comply with the requirements of 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph. See Ex parte Simpson, 218 USPQ 1020 (Bd. App. 1982). The claim scope is uncertain since the trademark or trade name cannot be used properly to identify any particular material or product. A trademark or trade name is used to identify a source of goods, and not the goods themselves. Thus, a trademark or trade name does not identify or describe the goods associated with the trademark or trade name. In the present case, the trademark/trade name is used to identify/describe a ticket number and, accordingly, the identification/description is indefinite.
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 (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 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.
Claim(s) 1-15 and 17-20 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Navert (US 11429384 B1).
Regarding claim 1, Navert teaches the limitations of claim 1 substantially as follows:
An application deployment platform comprising:
a web client application providing a graphical user interface (GUI) configured to receive one or more user inputs identifying a target application and a plurality of deployment parameters for the target application; (Navert; Col. 4, lines 31-39: An extension or plug-in 24 may be installed in a browser, providing functionality to or modifying the experience provided by the application executing on the browser, as described herein. Extension or plug-in 24 may be displayed on an application 10 executed by browser 24 (and thus it may be considered that either or both of browser 22 and application 10 may be modified by and interact with plug-in 24). For example, a user may select a plug-in 24 to display created data)
a backend control system integrated with a cloud workflow management platform API, an issue tracking platform API, a source data analytics and management platform API, and a developer platform API, (Navert; Col. 4, lines 47-51: take or receive data such as software development from Jira, an issue tracking software by Atlassian which is used by teams to track the work they have planned, in progress, and completed. Other work or issue tracking software may be used)
the backend control system performs one or more verification operations including determining whether the one or more user inputs are associated with an IT personnel or a business unit personnel; and a backend migration system configured, responsive to completion of the one or more verification operations by the backend control system, to migrate the target application from a developer platform associated with the developer platform API to a destination environment. (Navert; Col. 11, Table 7: Post-Done Overhead from when a Jira (i.e., one or more user inputs are associated with an IT personnel or a business unit personnel) is From Time of first ″Done″ Lead Time marked ″Done″ (i.e. Cycle state in Jira To Production Time) to when it is deployed Release to Production (i.e. Lead Time) (i.e., migrate the target application from a developer platform associated with the developer platform API to a destination environment))
Regarding claim 2, Navert teaches the limitations of claim 1.
Navert teaches the limitations of claim 2 as follows:
The application deployment platform of claim 1, wherein, the GUI includes an environment selection prompt and an application movement prompt. (Navert; Col. 11, Table 7: Post-Done Overhead from when a Jira is From Time of first ″Done″ Lead Time marked ″Done″ (i.e. Cycle state in Jira To Production Time) to when it is deployed Release to Production (i.e. Lead Time) (i.e., environment selection and application movement prompt))
Regarding claim 3, Navert teaches the limitations of claim 2.
Navert teaches the limitations of claim 3 as follows:
The application deployment platform of claim 2, wherein, the migrating of the target application includes sending a QVF file without data to the destination environment. (Navert; Col. 3, lines 55-59: data from source code revision or version control tools such as Git software (software for tracking changes in a set of software files) such as Git commits or other commits)
Regarding claim 4, Navert teaches the limitations of claim 1.
Navert teaches the limitations of claim 4 as follows:
The application deployment platform of claim 1, wherein, the one or more verification operations includes checking, based on a determination of a type of user, whether: a change request number associated with the IT personnel is valid; or a Jira ticket number, associated with the business unit personnel is valid. (Navert; Col. 11, Table 7: Post-Done Overhead from when a Jira (i.e., Jira ticket number) is From Time of first ″Done″ Lead Time marked ″Done″ (i.e. Cycle state in Jira To Production Time) to when it is deployed Release to Production (i.e. Lead Time))
Regarding claim 5, Navert teaches the limitations of claim 1.
Navert teaches the limitations of claim 5 as follows:
The application deployment platform of claim 1, wherein, the target application includes a dashboard template. (Navert; Col. 3, lines 9-14: The computed data or analysis results may be injected directly into (e.g. displayed on) development systems, planning systems or tools, development repositories views, agile software development boards, dashboards (i.e., dashboard template) and other sites, as well as aggregated into view points from various levels of granularity aligned with organizational structure)
Regarding claim 6, Navert teaches the limitations of claim 1.
Navert teaches the limitations of claim 6 as follows:
The application deployment platform of claim 1, wherein, the plurality of deployment parameters indicated by the one or more user inputs includes at least one of a source stream, a source application, a destination stream, or a destination application. (Navert; Col. 3, lines 55-59: Data such as SDLC or project development information or data may come from a variety of data sources or project development systems which software developers interact with on a daily basis, such as agile planning data, data from source code revision or version control tools such as Git software (software for tracking changes in a set of software files) such as Git commits or other commits, change management (e.g. the ServiceNow or Remedy systems, or other systems), incidents (e.g. problems in production code), builds, etc. Each set of or SDLC project development data may be in a format different from the format of other of the SDLC or project development systems and/or include different sets of information)
Regarding claim 7, Navert teaches the limitations of claim 1.
Navert teaches the limitations of claim 7 as follows:
The application deployment platform of claim 1, wherein, the backend control system determines that the one or more user inputs are associated with the IT personnel and, in response, sends an API request to the cloud workflow management platform API. (Navert; Col. 11, Table 7: Post-Done Overhead from when a Jira (i.e., one or more user inputs are associated with an IT personnel or a business unit personnel) is From Time of first ″Done″ Lead Time marked ″Done″ (i.e. Cycle state in Jira To Production Time) to when it is deployed Release to Production (i.e. Lead Time) (IT personnel would necessarily be operating in Jira to resolve production issues))
Regarding claim 8, Navert teaches the limitations of claim 1.
Navert teaches the limitations of claim 8 as follows:
The application deployment platform of claim 1, wherein, the backend control system determines that the one or more user inputs are associated with the business unit personnel and, in response, sends an API request to the cloud workflow management platform API. (Navert; Col. 11, Table 7: Post-Done Overhead from when a Jira (i.e., one or more user inputs are associated with an IT personnel or a business unit personnel) is From Time of first ″Done″ Lead Time marked ″Done″ (i.e. Cycle state in Jira To Production Time) to when it is deployed Release to Production (i.e. Lead Time) (business unit personnel would necessarily be operating in Jira to report product issues))
Regarding claim 9, Navert teaches the limitations of claim 7.
Navert teaches the limitations of claim 9 as follows:
The application deployment platform of claim 7, wherein, the backend control system is configured, responsive to receiving the plurality of deployment parameters, to send a query to a source data analytics and management server associated with the source data analytics and management platform API, for a list of streams for which a user associated with the one or more user inputs is authorized. (Navert; Col. 10, lines 54-65: By collecting information such as pull requests and commits from a Git repository (e.g. as part of an application 10 in FIG. 1) continually, an embodiment can determine which changes are going into each code release by combining the Git commit and pull request dataset with change management datasets. In such a manner a number of sets of SDLC or project development data, possibly from different project development systems, may be analyzed to produce an analysis (e.g. lead time). This combination enables some embodiments to compute metrics like the lead time for new features to be delivered)
Regarding claim 10, Navert teaches the limitations of claim 7.
Navert teaches the limitations of claim 10 as follows:
The application deployment platform of claim 7, wherein, the backend control system is configured, responsive to receiving the plurality of deployment parameters, to send a query to a source data analytics and management server for a list of streams for which a user associated with the one or more user inputs is authorized. (Navert; Col. 10, lines 54-65: By collecting information such as pull requests and commits from a Git repository (e.g. as part of an application 10 in FIG. 1) continually, an embodiment can determine which changes are going into each code release by combining the Git commit and pull request dataset with change management datasets. In such a manner a number of sets of SDLC or project development data, possibly from different project development systems, may be analyzed to produce an analysis (e.g. lead time). This combination enables some embodiments to compute metrics like the lead time for new features to be delivered)
Regarding claim 11, Navert teaches the limitations of claim 11 substantially as follows:
An application deployment platform comprising:
a web client application providing a graphical user interface (GUI) configured to receive one or more user inputs identifying a target application and a plurality of deployment parameters for the target application, (Navert; Col. 4, lines 31-39: An extension or plug-in 24 may be installed in a browser, providing functionality to or modifying the experience provided by the application executing on the browser, as described herein. Extension or plug-in 24 may be displayed on an application 10 executed by browser 24 (and thus it may be considered that either or both of browser 22 and application 10 may be modified by and interact with plug-in 24). For example, a user may select a plug-in 24 to display created data)
the plurality of deployment parameters includes an indication of at least one of a source application, a source stream, a destination application, or a destination stream; (Navert; Col. 3, lines 55-59: Data such as SDLC or project development information or data may come from a variety of data sources or project development systems which software developers interact with on a daily basis, such as agile planning data, data from source code revision or version control tools such as Git software (software for tracking changes in a set of software files) such as Git commits or other commits, change management (e.g. the ServiceNow or Remedy systems, or other systems), incidents (e.g. problems in production code), builds, etc. Each set of or SDLC project development data may be in a format different from the format of other of the SDLC or project development systems and/or include different sets of information)
a backend control system integrated with a cloud workflow management platform API, an issue tracking platform API, a source data analytics and management platform API, and a developer platform API, (Navert; Col. 4, lines 47-51: take or receive data such as software development from Jira, an issue tracking software by Atlassian which is used by teams to track the work they have planned, in progress, and completed. Other work or issue tracking software may be used)
the backend control system performs one or more verification operations including determining whether the one or more user inputs are associated with a user authorized to access the source application, the source stream, the destination application, or the destination stream; and a backend migration system configured, responsive to completion of the one or more verification operations by the backend control system, to migrate the target application from a developer platform associated with the developer platform API to a destination environment. (Navert; Col. 11, Table 7: Post-Done Overhead from when a Jira (i.e., one or more user inputs are associated with an IT personnel or a business unit personnel) is From Time of first ″Done″ Lead Time marked ″Done″ (i.e. Cycle state in Jira To Production Time) to when it is deployed Release to Production (i.e. Lead Time) (i.e., migrate the target application from a developer platform associated with the developer platform API to a destination environment))
Regarding claim 12, Navert teaches the limitations of claim 11.
Navert teaches the limitations of claim 12 as follows:
The application deployment platform of claim 11, wherein, the migrating of the target application includes identifying a previously uploaded application in the destination environment and replacing the previously uploaded application with the target application. (Navert; Col. 18, lines 17-22: an approved pull request can be updated with additional changes without having the approval invalidated)
Regarding claim 13, Navert teaches the limitations of claim 11.
Navert teaches the limitations of claim 13 as follows:
The application deployment platform of claim 11, wherein, the backend control system is configured to convert a plurality of responses from the source data analytics and management platform API from a plurality of JSON data files to a plurality of pandas data frame files. (Navert; Col. 5, Lines 13-14 and Table 1: example JSON snippet in Table 1 shows an example simplified sample representation of a Jira issue)
Regarding claim 14, Navert teaches the limitations of claim 13.
Navert teaches the limitations of claim 14 as follows:
The application deployment platform of claim 13, further comprising: a vectorization search performed on the plurality of pandas data frame files. (Navert; Col. 9, lines 24-28: Embodiments of the present invention may perform inference between data sets, such as agile planning and git commits, and infer and create the links between them if team fails to create a link)
Regarding claim 15, Navert teaches the limitations of claim 11.
Navert teaches the limitations of claim 15 as follows:
The application deployment platform of claim 11, further comprising: a token-based authentication between the web client application and the developer platform API. (Navert; Col. 6 line 65 – col 7, line 2: Communication with software such as Jira may be via a REST API (an application program interface) (i.e., communication between applications and platforms via API)
Regarding claim 17, Navert teaches the limitations of claim 17 substantially as follows:
A method of deploying an application using an application deployment platform, the method comprising: receiving, at a graphical user interface (GUI) of a web client application, one or more user inputs identifying a target application and a plurality of deployment parameters for the target application; (Navert; Col. 4, lines 31-39: An extension or plug-in 24 may be installed in a browser, providing functionality to or modifying the experience provided by the application executing on the browser, as described herein. Extension or plug-in 24 may be displayed on an application 10 executed by browser 24 (and thus it may be considered that either or both of browser 22 and application 10 may be modified by and interact with plug-in 24). For example, a user may select a plug-in 24 to display created data)
integrating a backend control system with a cloud workflow management platform API, an issue tracking platform API, a source data analytics and management platform API, and a developer platform API; (Navert; Col. 4, lines 47-51: take or receive data such as software development from Jira, an issue tracking software by Atlassian which is used by teams to track the work they have planned, in progress, and completed. Other work or issue tracking software may be used)
performing one or more verification operations, based on the plurality of deployment parameters, and using a plurality of communications between the backend control system and: the cloud workflow management platform API; the issue tracking platform API; the source data analytics and management platform API; or the developer platform API; and responsive to completion of the one or more verification operations, migrating, using a backend migration system, the target application from a developer platform associated with the developer platform API to a destination environment. (Navert; Col. 11, Table 7: Post-Done Overhead from when a Jira (i.e., one or more user inputs are associated with an IT personnel or a business unit personnel) is From Time of first ″Done″ Lead Time marked ″Done″ (i.e. Cycle state in Jira To Production Time) to when it is deployed Release to Production (i.e. Lead Time) (i.e., migrate the target application from a developer platform associated with the developer platform API to a destination environment))
Regarding claim 18, Navert teaches the limitations of claim 17.
Navert teaches the limitations of claim 18 as follows:
The method of claim 17, wherein, the plurality of deployment parameters include one or more indications of a source application, a source stream, a destination application, or a destination stream. (Navert; Col. 3, lines 55-59: Data such as SDLC or project development information or data may come from a variety of data sources or project development systems which software developers interact with on a daily basis, such as agile planning data, data from source code revision or version control tools such as Git software (software for tracking changes in a set of software files) such as Git commits or other commits, change management (e.g. the ServiceNow or Remedy systems, or other systems), incidents (e.g. problems in production code), builds, etc. Each set of or SDLC project development data may be in a format different from the format of other of the SDLC or project development systems and/or include different sets of information)
Regarding claim 19, Navert teaches the limitations of claim 18.
Navert teaches the limitations of claim 19 as follows:
The method of claim 18, wherein, the one or more verification operations include: determining whether a user associated with the one or more user inputs is authorized to access the source application, the source stream, the destination application, and the destination stream; or determining whether the one or more user inputs are associated with an IT personnel or a business unit personnel. (Navert; Col. 3, lines 55-59: Data such as SDLC or project development information or data may come from a variety of data sources or project development systems which software developers interact with on a daily basis, such as agile planning data, data from source code revision or version control tools such as Git software (software for tracking changes in a set of software files) such as Git commits or other commits, change management (e.g. the ServiceNow or Remedy systems, or other systems), incidents (e.g. problems in production code), builds, etc. Each set of or SDLC project development data may be in a format different from the format of other of the SDLC or project development systems and/or include different sets of information)
Regarding claim 20, Navert teaches the limitations of claim 17.
Navert teaches the limitations of claim 20 as follows:
A method of claim 17, further comprising: presenting, at the GUI: a first selectable interface element configured to receive a first user input indicating a deployment environment; a second selectable interface element configured to receive a second user input indicating a source server; a third selectable interface element configured to receive a third user input indicating a destination server; a fourth selectable interface element configured to receive a fourth user input indicating a source stream; and a fifth selectable interface element configured to receive a fifth user input indicating a destination stream. (Navert; Col. 3, lines 55-59: Data such as SDLC or project development information or data may come from a variety of data sources or project development systems which software developers interact with on a daily basis, such as agile planning data, data from source code revision or version control tools such as Git software (software for tracking changes in a set of software files) such as Git commits or other commits, change management (e.g. the ServiceNow or Remedy systems, or other systems), incidents (e.g. problems in production code), builds, etc. Each set of or SDLC project development data may be in a format different from the format of other of the SDLC or project development systems and/or include different sets of information)
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.
Claim 16 is rejected under 35 U.S.C. 103 as being unpatentable over Navert (US 11429384 B1), in view of Kumar (US 20240095127 A1).
Regarding claim 16, Navert teaches the limitations of claim 11.
Navert does not teach the limitations of claim 16 as follows:
The application deployment platform of claim 11,wherein,the backend control system is configured to: receive a fail or error message in response to an API request sent to the cloud workflow management platform API or the developer platform API; and responsive to the fail or error message, queue the API request for a retry.
However, in the same field of endeavor, Kumar discloses the limitations of claim 16 as follows:
The application deployment platform of claim 11,wherein,the backend control system is configured to: receive a fail or error message in response to an API request sent to the cloud workflow management platform API or the developer platform API; and responsive to the fail or error message, queue the API request for a retry. (Kumar; [0107]: in response to API request fail, retry)
Kumar is combinable with Navert because all are from the same field of endeavor of processing API calls. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the system of Navert to incorporate retrying failed API requests as in Kumar in order to make the system more robust to failed or otherwise errored API calls.
Prior Art Considered But Not Relied Upon
Mittal (US 20170123777 A1) which teaches techniques to deploy an application on an application platform.
Doshi (US 20180329700 A1) which teaches a target model which is determined for a source application that is to be migrated to a target system.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to BLAKE ISAAC NARRAMORE whose telephone number is (303)297-4357. The examiner can normally be reached on Monday - Friday 0700-1700 MT.
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, Taghi T Arani can be reached on (571) 272-3787. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see https://ppair-my.uspto.gov/pair/PrivatePair. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/BLAKE I NARRAMORE/Primary Examiner, Art Unit 2438
Prosecution Insights