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 .
DETAILED ACTION
This office action is in response to the application filed on 03/27/2024. Claims 1-
20 are pending in this application. Claims 1,8 and 15 are independent claims.
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 - 20 are rejected under 35 U.S.C. 101 because the claimed invention
recites a judicial exception, is directed to that judicial exception, an abstract idea, it has
not been integrated into practical application and the claims further do not recite
significantly more than the judicial exception. Examiner has evaluated the claims under
the framework provided in the 2019 Patent Eligibility Guidance published in the Federal
Register 01/07/2019 and has provided such analysis below.
Claim 15 -20 are rejected because the claimed invention is directed to non-statutory subject matter. The claims do not fall within at least one of the four categories of patent eligible subject matter because the claims and specification do not explicitly exclude signals for the computer-readable tangible storage media; Thus, claim 15, and dependent claims 16,17,18, 19 and 20 are directed to software per se. Examiner has evaluated the claims for the mental process in the interest of compact prosecution.
Regarding claims 1, 8 and 15, the limitations “identifying a contribution to an application”, “tagging engrams in the application corresponding to the contribution” , as drafted, are functions that, under its broadest reasonable interpretation, recite the abstract idea of a mental process. These limitations encompass a human mind carrying out these functions through observation, evaluation judgment and /or opinion, or even with the aid of pen and paper. For example , the “identifying” limitation can be performed by looking at the files, code or commit logs for an application and recording using a pen and paper information associated with the contribution such as the contributor, metadata fields, or features. Similarly, the “tagging” limitation can be performed by looking at application source code and annotating with contribution information. Thus, these limitations recites and falls within the “Mental Processes” grouping of abstract ideas under Prong 1.
Under Prong 2, the judicial exception is not integrated into a practical application. The additional elements “monitoring the application at runtime for a subset of the tagged engrams”, merely recite instructions to implement an abstract idea on a generic computer, or merely uses a generic computer or computer components as a tool to perform the abstract ideas, thus is not a practical application under Prong 2. The additional elements, “preparing a visualization for one or more identified contributions based on an engram stored from the subset” and “presenting the visualization to a user” do nothing more than add insignificant extra solution activity to the judicial exception of merely gathering data. Accordingly, the additional elements do not integrate the recited judicial exception into a practical application and the claim is therefore directed to the judicial exception. See MPEP 2106.05(f) and (g), respectively.
Under Step 2B, the claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As stated above in prong 2, the additional elements “monitoring the application at runtime for a subset of the tagged engrams”, merely recite instructions to implement an abstract idea on a generic computer, or merely uses a generic computer or computer components as a tool to perform the abstract idea. The additional elements “preparing a visualization for one or more identified contributions based on an engram stored from the subset” and “presenting the visualization to a user” are merely gathering data which the courts have identified as well-understood, routine conventional activity. Therefore, the additional elements do not amount to significantly more, thus, cannot provide an inventive concept. Accordingly, the claims are not patent eligible under 35 USC 101.
Claims 8 recites further additional elements “one or more processors, one or more computer-readable memories, one or more computer-readable tangible storage media, and program instructions stored on at least one of the one or more tangible storage media for execution by at least one of the one or more processors via at least one of the one or more memories“. These additional elements are recited at a high-level of generality such that it amounts no more than mere instructions to apply the exception using generic computer, and/or generic computer components. See MPEP 2106.05(f). Therefore, the additional elements recited in claims 8 do not integrate the judicial exception into a practical application under prong 2, nor amount to significantly more under step 2B.
Claims 15 recites further additional elements “one or more computer-readable tangible storage media and program instructions stored on at least one of the one or more tangible storage media, the program instructions executable by a processor “. These additional elements are recited at a high-level of generality such that it amounts no more than mere instructions to apply the exception using generic computer, and/or generic computer components. See MPEP 2106.05(f). Therefore, the additional elements recited in claims 8 do not integrate the judicial exception into a practical application under prong 2, nor amount to significantly more under step 2B.
Regarding claims 4,11,18 the limitation “identifying a type of the contribution” recites additional mental process under Prong 1.
Regarding claims 5,12 and 19 the limitations recited in these claims merely describe the data being identified in each of claims 4, 11 and 18, respectively. Thus, are likewise analyzed under Prong 1 as mental process.
Regarding claims 6,13,20 the limitations recited in these claims further elaborates the “tagging” abstract idea in each of claims 1, 8 and 15. Thus, are likewise analyzed under Prong 1 as mental process.
Regarding dependent claims (2, 3, 7), (9, 10, 14) and (16,17) , these claims are rejected under the same rational as cited above wherein these claims do not include additional elements that are significantly more than the judicial exception. The limitations recited in these claims merely describe visualization of the abstract idea in each of claims 1, 8 and 15 respectively which does not impose any meaningful limits on practicing the abstract idea.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the
effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1, 4,6,8,11,13,15,18,20 are rejected under 35 U.S.C. 103 as being unpatentable over Masis et. al (US11237824B2) hereafter Masis, in view of Moore et. al ( US 10554516 B1) hereafter Moore.
Regarding claim 1, Masis teaches: identifying a contribution to an application;([Col 5, Lines 16-27] “In one or more embodiments, annotation tracker 150 may be used to automatically track annotated source code changes for a user-customized feature of the software project. For example, the source code changes may be annotated by a user of client 110A via source code editor 115A. … The user-customized feature may correspond to annotated source code changes that span several lines of source code within one or multiple files and repositories associated with the software project.”) The annotated source code changes that correspond to a user-customized feature for a software project correspond to identifying a contribution to an application.
tagging engrams in the application corresponding to the contribution(“[Col 6, Lines 37-67 ] In one or more embodiments, code parser 202 may use annotation identifier 206 to determine whether the parsed source code file(s) 201 includes at least one annotation related to a user-customized feature of the software project, e.g., a workaround introduced by the user. In one or more embodiments, code parser 202 may be configured to parse the source code in code repository 125 or 135 and convert it to a data structure that can be analyzed by annotation identifier 206. The annotation may be, for example and without limitation, a keyword specified by the user for the user-customized feature. The keyword may be stored in dictionary 204 along with other keywords for the user-customized feature. Accordingly, annotation identifier 206 may use dictionary 204 to determine whether source code file(s) 201 is annotated with a keyword for the user-customized feature. In some implementations, dictionary 204 may include a list of different keywords for each of a plurality of user-customized features for the software project. When source code file(s) 201 is determined to be annotated for the user-customized feature of the software project, annotation identifier 206 may store metadata identifying the annotated portion of source code file(s) 201 for the user-customized feature in an annotation database 145. The metadata may include, for example and without limitation, a location of the annotated source code change within the one or more files of the code repository and a description of the changes that were made to the annotated source code. Once the metadata for the annotated source code related to the user-customized feature is stored, source code file(s) 201 with the user's changes may be checked-in or submitted to a version control system, e.g., version control system 122 of… [Col 7, Lines 1-3 ] FIG. 1, as described above, which merges the changes into the code repository and updates a corresponding commit log.”)The source code files that are checked in are tagged with keywords corresponding to the features of the code. These tags are stored in the annotation database and retained in the source code when the code changes are merged with the code repository so that the annotations can be compared to subsequent incoming files. Thus, tagging the source code changes with features which are merged into the code repository for the software corresponds to tagging engrams in the application corresponding to the contribution.
Masis does not teach: monitoring the application at runtime for a subset of the tagged engrams; However, Moore teaches: monitoring the application at runtime for a subset of the tagged engrams;([Col 7, Lines 20-26] “ For example, the metrics application 114 may monitor various metrics features of a software product (or multiple software products) executing on the client device 110 (or at the deployment 130). The metrics application 114 may then deliver the software usage metrics collected to the collection module 210 as a metrics submission (e.g., UMI).” [Col 3, Lines 1-44]” The software usage metrics collected by the metrics collection system include a rate or frequency with which features of a software product are executed, a number of devices executing the software product at a deployment, a number of deployments executing versions of the software product, a number of unique users, a number of failed login attempts (e.g., by location, user, or day), a frequency of use of the software product, a frequency of crashes, bug reports, and performance metrics related to a speed or efficiency of actions of the software product. As a means of standardization, the metrics collection system may include a metrics application that executes at client devices, to quantify and format metrics submissions for the metrics collection system. The usage metrics of the metrics submissions may be based on a “Uniform Metrics Identifier” (UMI) that quantifies, based on what the software product is, what the actual metric collected is, and what the point or duration scale of the metric is, and a value of the metric.… based on the UMI, the usage metrics may be formatted as a concatenation of strings associated with the above components, separated by “:” in the following form: <Group>:<Metric>:<Duration>. In some example embodiments, the “<Group>” and “<Metric>” component of the UMI can be further split out into terms separated by “.” in the following form: <G-term-1>.<G-term-2>.<G-term-N>:<M-term-1>.<M-term-2>.<M-term-N>:<Duration> . The “<Group>” string indicates what the metric is in reference to. As used herein, the “<Group>” string identifies a particular software product (e.g., from among a corpus of products). The “<Group>” portion of the UMI may consist of an arbitrarily nested set of terms that provide increasing levels of specificity from left to right. Similarly, the “<Metric>” portion of the UMI may describe what feature of the software product is being measured (e.g., a rate of use of distinct features of the software product, number of unique users, etc.) and may also consist of an arbitrarily nested set of terms that provide increasing levels of specificity from left to right.”)
The UMI for monitoring the metrics specifies one or more group terms which represent the software product. The metric components of the UMI are used to measure a rate of use of distinct features of the software product in which the features correspond to engrams, such that M-term-1 to M-term-n may be each associated with a measurement of a feature of the product. Thus, specifying a UMI with metrics fields for a desired set of features of the program and monitoring the metrics of a software product executing on a client device corresponds to monitoring the application at runtime for a subset of the tagged engrams.
preparing a visualization for one or more identified contributions based on an engram stored from the subset; and presenting the visualization to a user.([Col 6, Lines 41-47]“The visualization module 240 receives visualization requests from one or more client devices. The visualization requests include indications of a visualization type (e.g., bar graph), a metrics category or feature, and a time period. The visualization module 240 generates and causes display of a visualization at the client device (e.g., client device 110) based on the visualization request.”) The visualization is based on metrics associated with selected monitored features of the software product , in which the features correspond to engrams. Thus, visualizing the metrics corresponds to preparing a visualization for one or more identified contributions based on an engram stored from the subset; and presenting the visualization to a user.
Therefore, it would have been obvious to one of ordinary skill in the art to which said subject matter pertains before the effective filing date of the claimed invention to combine Masis with, monitoring the application at runtime for a subset of the tagged engrams; and preparing a visualization for one or more identified contributions based on an engram stored from the subset; and presenting the visualization to a user, as taught by Moore in order to identify areas of software products that need improvements based on usage metrics for the monitored features.[Moore, Section: Background]
Regarding claim 4, Masis in view of Moore teach the method of Claim 1 above., Masis further teaches: wherein identifying the contribution further includes identifying a type of the contribution.([Col4, Lines 62-64] “Each time a user makes (or “commits”) a change to source code file(s) stored in code repository 125 or 135, version control system 122 or 132 logs data pertaining to the change into a commit log. Such data may include information describing the source code change (e.g., the type and location of the file(s) and repository in which the changed source code is stored) as well as information identifying the user that committed the change.”)Data describing the source code change such as specifying the types of files for the code changes corresponds to wherein identifying the contribution further includes identifying a type of the contribution.
Regarding claim 6, Masis and Moore teach the method of claim 1 above. Regarding the limitation : wherein tagging an engram includes placing the engram in the source code of the program. As stated in the rejection of claim 1, the engrams are annotated in source code changes which are retained when merged with the program repository. Therefore claim 6 is rejected for the same reasons as claim 1.
Claims 2, 3 , 9, 10, 16, 17 are rejected under 35 U.S.C. 103 as being unpatentable over (US11237824B2) Masis, in view of (US10554516 B1) Moore, and further in view of Schreiber et. al (Visualization of Contributions to Open-Source Projects , Published 12/02/2020) hereafter Schreiber.
Regarding claim 2, Masis in view of Moore teach the method of Claim 1 above. Masis and Moore do not explicitly teach: wherein the visualization includes a contribution tree. However, Schreiber teaches: wherein the visualization includes a contribution tree: ([Section 4, Par 2-3] “We visualize the Android app cwa-app-android, for which the database has 3672 Entities, 56 Agents, and 379 Activities. This leads to 571 contributions by team members and 1230 contributions by external contributors. We draw one graph where we scale node sizes proportional to the in-degree of file nodes (Figure 2a) and a second one where we scale proportional to the out-degree of contributors (Figure 2b). Our graph drawing show typical patterns: team members and external contributors work collaboratively on many files. Because the drawing is based on provenance data, the interpretation is that over the time of development many files were changed by developers with different roles; where a small number of developers made most of the changes.”) Provenance data represents the history of files within a repository. The graph structures or figure 2 representing the contributors to various files in the database is connected with edges that indicate file changes by the contributor and nodes of various sizes representing the files and contributors. Thus, the graph visualizations corresponds to wherein the visualization includes a contribution tree.
Therefore, it would have been obvious to one of ordinary skill in the art to which said subject matter pertains before the effective filing date of the claimed invention to combine Masis with, wherein the visualization includes a contribution tree, as taught by Schreiber, in order to visualize the relationships between contributions and contributors to different files in the project.
Regarding claim 3, Masis, Moore, and Schreiber teach the method of claim 2 above. Regarding the limitation : wherein the contribution tree includes two or more nodes that are visually distinct from one another; As stated in the rejection of claim 2, the nodes of the tree such as in figure 2 are scaled to different sizes based on contribution factors. Therefore claim 3 is rejected for the same reasons as claim 2.
Claims 5,12,19 are rejected under 35 U.S.C. 103 as being unpatentable over (US11237824B2) Masis, in view of (US10554516 B1) Moore, and further in view of Hindle et. al (Release Pattern Discovery via Partitioning: Methodology and Case Study, Published:05/20/2007) hereafter Hindle.
Regarding claim 5, Masis in view of Moore teach the method of Claim 4 above. Masis and Moore do not explicitly teach: wherein the types of contribution include at least development contribution, build contribution, and test contribution. However, Hindle teaches: wherein the types of contribution include at least development contribution, build contribution, and test contribution. ([1.2 Terminology, Par 1] “Version control systems (VCS) are repository-like systems such as CVS or BitKeeper which control and store versions of a project’s source code. They record changes to files, these changes are called revisions which are committed to the VCS. We consider a commit to be the act of submitting a set of revisions to the version control system.” [1.2 Terminology, Par 6] “For our analysis we partition the files in the version control system into four classes: source, test, build, and documentation.“) Classifying the files in the code repository as source, build, and test corresponds to, wherein the types of contribution include at least development contribution, build contribution, and test contribution respectively.
Therefore, it would have been obvious to one of ordinary skill in the art to which said subject matter pertains before the effective filing date of the claimed invention to combine Masis with, wherein the types of contribution include at least development contribution, build contribution, and test contribution, as taught by Hindle,
In order to differentiate between types of contributions prior to monitoring the contributions during execution of the program.
Claims 7,14 are rejected under 35 U.S.C. 103 as being unpatentable over (US11237824B2) Masis, in view of ( US 10554516 B1) Moore and further in view of Morgan (US 9213622 B1) hereafter Morgan.
Regarding claim 7, Masis and Moore teach the method of claim 1 above. Masis and Moore do not teach: wherein the visualization includes a stack trace. However, Morgan teaches: wherein the visualization includes a stack trace.([Col 2, Lines 36 – 41]“The debugger can provide an interface that displays, e.g., through a display of the device 102, a stack trace. The stack trace includes data from the call stack and is organized in a developer-friendly manner. In particular, the stack trace can refer to line numbers of executed code running on the call stack. An example of a stack trace is described further below in reference to FIG. 3.” Displaying the stack trace corresponds to wherein the visualization includes a stack trace.
Therefore, it would have been obvious to one of ordinary skill in the art to which said subject matter pertains before the effective filing date of the claimed invention to combine Masis with, wherein the visualization includes a stack trace, as taught by Morgan, in order to view details associated with code contributions that failed during execution.
Regarding claim 8, it is a computer system claim that recites limitations similar to those of claim 1. Therefore claim 8 is rejected for the same reasons as outlined in the rejections of claim 1.
Regarding claim 9, it is a computer system claim that recites limitations similar to those of claim 2. Therefore claim 9 is rejected for the same reasons as outlined in the rejections of claim 2.
Regarding claim 10, it is a computer system claim that recites limitations similar to those of claim 3. Therefore claim 10 is rejected for the same reasons as outlined in the rejections of claim 3.
Regarding claim 11, it is a computer system claim that recites limitations similar to those of claim 4. Therefore claim 11 is rejected for the same reasons as outlined in the rejections of claim 4.
Regarding claim 12, it is a computer system claim that recites limitations similar to those of claim 5. Therefore claim 12 is rejected for the same reasons as outlined in the rejections of claim 5.
Regarding claim 13, it is a computer system claim that recites limitations similar to those of claim 6. Therefore claim 13 is rejected for the same reasons as outlined in the rejections of claim 6.
Regarding claim 14, it is a computer system claim that recites limitations similar to those of claim 7. Therefore claim 14 is rejected for the same reasons as outlined in the rejections of claim 7.
Regarding claim 15, it is a computer program product claim that recites limitations similar to those of claim 1. Therefore claim 15 is rejected for the same reasons as outlined in the rejections of claim 1.
Regarding claim 16, it is a computer program product claim that recites limitations similar to those of claim 2. Therefore claim 16 is rejected for the same reasons as outlined in the rejections of claim 2.
Regarding claim 17, it is a computer program product claim that recites limitations similar to those of claim 3. Therefore claim 17 is rejected for the same reasons as outlined in the rejections of claim 3.
Regarding claim 18, it is a computer program product claim that recites limitations similar to those of claim 4. Therefore claim 18 is rejected for the same reasons as outlined in the rejections of claim 4.
Regarding claim 19, it is a computer program product claim that recites limitations similar to those of claim 5. Therefore claim 19 is rejected for the same reasons as outlined in the rejections of claim 5.
Regarding claim 20, it is a computer program product claim that recites limitations similar to those of claim 6. Therefore claim 20 is rejected for the same reasons as outlined in the rejections of claim 6.
Prior Art Made of Record
The prior art made of record and not relied upon is considered pertinent to
applicant's disclosure:
US 10303586 B1, discloses a code contribution monitoring system that can be implemented as a multi-tenant system.
US 7739653 B2, discloses a graph-based visualization system for displaying relationship between developers and code.
US 20090254883 A1, discloses a system for monitoring code based on metadata associated with the code.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to LAWRENCE O'CONNOR EMANUEL whose telephone number is (571)272-8975. The examiner can normally be reached M-F 9:00 - 5:00 pm .
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, Chat Do can be reached at (571) 272-3721. 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.
/L.S.O./Examiner,ArtUnit2193
/Chat C Do/Supervisory Patent Examiner, Art Unit 2193
Prosecution Insights