Prosecution Insights
Last updated: April 19, 2026
Application No. 18/597,989

Dynamic Benchmarking of Combinations of Main and Sub Libraries for Library Developer Operations (LIBOPS)

Non-Final OA §103
Filed
Mar 07, 2024
Examiner
VO, TED T
Art Unit
2191
Tech Center
2100 — Computer Architecture & Software
Assignee
Kyndryl Inc.
OA Round
1 (Non-Final)
81%
Grant Probability
Favorable
1-2
OA Rounds
3y 2m
To Grant
90%
With Interview

Examiner Intelligence

Grants 81% — above average
81%
Career Allow Rate
649 granted / 801 resolved
+26.0% vs TC avg
Moderate +9% lift
Without
With
+9.3%
Interview Lift
resolved cases with interview
Typical timeline
3y 2m
Avg Prosecution
26 currently pending
Career history
827
Total Applications
across all art units

Statute-Specific Performance

§101
15.4%
-24.6% vs TC avg
§103
39.4%
-0.6% vs TC avg
§102
15.0%
-25.0% vs TC avg
§112
14.7%
-25.3% vs TC avg
Black line = Tech Center average estimate • Based on career data from 801 resolved cases

Office Action

§103
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 action is in response to the claimed listing filed on 03/07/2024. Claims 1-20 are pending. 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-20 are rejected under 35 U.S.C. 103 as being unpatentable over TomatenSalat et al., “Shared library and modules with versioning”, 2022, Software Engineering Stack Exchange, retrieved from https://softwareengineering.stackexchange.com/questions/430848/shared-library-and-modules-with-versioning , 4 pages, and in view of Chen, CN Patent, No. CN-116233249-A, and in view of Sridhara et al., US PAT No. US 11,354,108 B2. As per Claim 1: TomatenSalat et. al., disclose the limitation in bold as below: A computer implemented method for supporting self-assessed upgrades (Questions/Answers for upgrading modules in the reference read : “supporting self-assessed upgrades” ) using dynamic benchmarking of combinations of main and sub libraries (The Chart in p. 1 with hierarchy of Shared Libraries) for carrying out Library Developer Operations (LibOps) (The Chart in p. 1), the method comprising: identifying a software library module being used in a software application; (TomatenSalat: The Chart in p. 1, Module A, B, C) identifying dependencies and upgrades for the software library module; (TomatenSalat: The Chart in p. 1, Module A, B, C, and referred to “The 1…” and “The 2..” ) identifying a latest software library module version; (TomatenSalat: The Chart in p. 1, visually shows v4, v3, v2 in Shared Libraries ) Regarding, [identifying a change.log module for the latest software library module version, wherein the change.log module includes a record of all changes to the software library module;] (*) (TomatenSalat does not disclose the limitations in italics above) TomatenSalat et al., further disclose: categorizing breaking changes and deprecated features for the latest software library module version; (TomatenSalat: The Chart in p. 1, with version numbers in shared libraries as latest for software library module. And in p. 1, “2. create a framework that allows using different versions for each module?”. And in p. 2 “2 is the only one that actually works if you have breaking changes” ) Regarding, [generating an upgrade score responsive to a quality of the upgrades and suggesting recommendations responsive to the upgrade score], (**) (TomatenSalat et al., do not disclose the limitations in italics above) TomatenSalat et al., further disclose the limitations in bold as below: and updating the software library module with the latest software library module version [responsive to the upgrade score] (***). (TomatenSalat: The Chart in p. 1, and “1. always use the latest version of the Shared Library for every Module”). Per above limitations of Claim 1, TomatenSalat et al., do not disclose the limitation as in (*) above. Chen discloses the limitations (*) of “identifying a change.log module for the latest software library module version, wherein the change.log module includes a record of all changes to the software library module” (See Chen: in p. 5: in item 4: “4. The original library module will change to generate a change log, where the change log table is show in Table (2)”, and the example of change log shown as msg below item 5 in p.6 and further in p. 7. The change log identifies the source that changes, all the necessary records, including the name of the object, dates, times in the attribute list. Therefore, it would be obvious to an ordinary of skills in the art before the effective filing of the application to include the identifying in change log for analyzing the original full-scale network data to obtain original library data of Chen with identifications of change versions in the library operation of TomatenSalat et al., the combination would yield predictable results because Changelog is a component used across in all types of software development for communicating the changes to users and developers; it would help the library operation to record and to identify easily the changes and thus with the additional of change log would ease the identification and only for conforming to use of the component availability. TomatenSalat et al and in view of Chen, TomatenSalat et al., disclose upgrade responsive, but, TomatenSalat et al and further in view of Chen do not disclose the limitation as in (**) and (***) above. Sridhara discloses the limitations (**) of “generating an upgrade score responsive to a quality of the upgrades and suggesting recommendations responsive to the upgrade score” (Sridhara: in Abstract, “A computer-implemented method includes determining differences between a first version of a dependency used by a software application and each of a plurality of upgrade candidates,” :‘suggesting recommendations’ , in col. 5, lines 40-46, “In some exemplary embodiments, the system may prioritize ( or rank) different versions of a given dependency based on the impact analysis and the differences report. Referring again to the example above, the system may rank version 1. 7 of the dependency higher than version 1.8, if, for example, upgrading to version 1.7 involves fewer (or less complex) code changes.”: ‘upgrade score’ ); and discloses (***) “ responsive to the upgrade score” (Sridhara: col.6 lines 38-44, “Step 504 may be performed for each of the upgrade candidates, and the process may include steps of: ranking the upgrade candidates based at least in part on the classifying; and outputting a list of said upgrade candidates, based on said ranking, to a human-computer interface. Step 506 may be performed in response to user input with respect to at least one of the upgrade candidates in the list” ). The rank is involved in many candidates, various sources, for an upgrade entity, and thus it requires an classifying analysis for an upgrade version recommendation. Therefore, it would be obvious to an ordinary of skills in the art before the effective filing of the application to include the teaching for ranking of upgrade versions (upgrade score) in responsive to an upgrade of software in a library operation of Sridhara with the teaching for categorizing and identifying versions for library applications upgrade as of TomatenSalat et al and further in Chen. The combination would yield predictable results because ranking or upgrade score providing accuracy and it is always used in development process when requires a choice. As per Claim 2: TomatenSalat et al., and combining Chen and Sridhara, where TomatenSalat et al., further disclose: 2. The computer implemented method of claim 1, further includes identifying if there are library patches or other upgrades for the software library module, (TomatenSalat: The Chart in p. 1, with visual indication of shared library v4, and Module A v2, and in p. 2, the answers to BenCottrell: “@BenCottrell sometimes a Module needs a bugfix in the Share Library, then the newest version has to be used at least in that one”) and conducting a specific library assessment to determine the dependencies. (TomatenSalat: e.g. in the three bold dots read on “conducting a specific library assessment” , especially, the first bold dot: “. a test of all dependent modules”) As per Claim 3: TomatenSalat et al., and combining Chen and Sridhara, where Sridhara further disclose: 3. The computer implemented method of claim 2, further including examining a Package.json module the software application to determine project information. (Sridhara: Col. 2, lines 54-62, “Additionally, exemplary embodiments may include estimating effort to modernize the pieces of code and generating a summary (e.g., in an open-standard file format such as, for example, a JSON (JavaScript Object Notation) format) of the upgrade options, the identified pieces of code, and the estimated efforts. Further, relevant code changes .”) Therefore, it would be obvious to an ordinary of skills in the art before the effective filing of the application to include the teaching for using JSON as pack of information of code project of Sridhara with the teaching for categorizing and identifying versions for library applications upgrade as of TomatenSalat et al and further in Chen. The combination would yield predictable results because JSON is human readable format and it is common and the choice in software developers for storing and transmitting data across the network. As per Claim 4: TomatenSalat et al., and combining Chen and Sridhara, where TomatenSalat et al., further disclose: 4. The computer implemented method of claim 1, further performing test operations on the libraries to classify the upgrades based on the quality of the upgrades. (TomatenSalat: in p. 3, see the three bold dots “…a certain lib by a newer version will require . a test of all dependent modules . a recompilation when using a compiled language environment . and if the new version of the lib contains breaking changes, some modifications to their client modules.”) As per Claim 5: TomatenSalat et al., and combining Chen and Sridhara, where Sridhara further disclose: 5. The computer implemented method of claim 4, wherein conducting the specific library assessment includes assessing library content and searching websites for relevant information regarding the library content. (Sridhara: See in col. 5, lines 47-53, “word embeddings and/or wordnets may be used to identify information (e.g., posts) from online sources. For example, the online source can be searched using word embeddings and/or wordnets to identify synonyms for words such as, for example 'modernize', 'newer', 'latest', 'recent'+'version', 'release', 'arrival', etc.,”) Therefore, it would be obvious to an ordinary of skills in the art before the effective filing of the application to include the teaching for ranking of upgrade version (upgrade score) and searching for library contents in responsive to an upgrade of software in a library operation of Sridhara with the teaching for categorizing and identifying versions for library applications upgrade as of TomatenSalat et al and further in Chen. The combination would yield predictable results because web search it is always used and it is a common and readily available component. As per Claim 6: Incorporated with limitation of claim 5, with Sridhara providing further in web search, TomatenSalat et al., and combining Chen, where TomatenSalat et al., further disclose: 6. The computer implemented method of claim 5, wherein conducting the specific library assessment includes testing the specific library assessment to determine if the upgrades will generate any critical, major or minor issues. (TomatenSalat: in p. 3, see the three bold dots “…a certain lib by a newer version will require . a test of all dependent modules . a recompilation when using a compiled language environment . and if the new version of the lib contains breaking changes, some modifications to their client modules.”) As per Claim 7: TomatenSalat et al., and combining Chen and Sridhara, where TomatenSalat et al., further disclose: 7. The computer implemented method of claim 1, wherein categorizing includes identifying breaking changes and deprecated features by conducting an assessment of the software library module. (TomatenSalat: The Chart in p. 1, with version numbers in shared libraries as latest for software library module. And in p. 1, “2. create a framework that allows using different versions for each module?”. And in p. 2 “2 is the only one that actually works if you have breaking changes”; in p. 3, the third bold dot “. and if the new version of the lib contains breaking changes, some modifications to their client modules.” ) As per claims 8-14: Claims recite a system that have claimed functionality corresponding to the claimed recitations in the method of claims 1-7. The Claims are rejected with the same rationales addressed in Claims 1-7 above. As per claims 15-20: Claims recite a computer program product that have claimed functionality corresponding to the claimed recitations in the method of claims 1-7. The Claims are rejected with the same rationales addressed in Claims 1-7 above. Conclusion Any inquiry concerning this communication or earlier communications from the examiner should be directed to Ted T Vo whose telephone number is (571)272-3706. The examiner can normally be reached 8am-4:30pm ET. Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Wei Y Mui can be reached at (571) 272-3708. 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. TTV February 21, 2026 /Ted T. Vo/ Primary Examiner, Art Unit 2191
Read full office action

Prosecution Timeline

Mar 07, 2024
Application Filed
Feb 21, 2026
Non-Final Rejection — §103 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12578928
SOFTWARE DEVELOPMENT PLATFORM FOR INTERNET OF THINGS APPLICATIONS
2y 5m to grant Granted Mar 17, 2026
Patent 12576861
VEHICLE CALIBRATION SYSTEM AND VEHICULAR DEVELOPMENT AND DEBUGGING SYSTEM
2y 5m to grant Granted Mar 17, 2026
Patent 12572452
System and Method for Automated Software Testing
2y 5m to grant Granted Mar 10, 2026
Patent 12547398
SYSTEMS AND METHODS FOR MANAGING A SOFTWARE REPOSITORY
2y 5m to grant Granted Feb 10, 2026
Patent 12541329
CLOUD PROVISIONED BOOT VOLUMES
2y 5m to grant Granted Feb 03, 2026
Study what changed to get past this examiner. Based on 5 most recent grants.

AI Strategy Recommendation

Get an AI-powered prosecution strategy using examiner precedents, rejection analysis, and claim mapping.
Powered by AI — typically takes 5-10 seconds

Prosecution Projections

1-2
Expected OA Rounds
81%
Grant Probability
90%
With Interview (+9.3%)
3y 2m
Median Time to Grant
Low
PTA Risk
Based on 801 resolved cases by this examiner. Grant probability derived from career allow rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month