DETAILED ACTION
This office action is in response to the amendments filed December 18, 2025.
Claims 1-20 are pending.
This application is a continuation of application 16/818,834 and provisional applications 62/819369 and 62/941537 and is examined as entitled to the earlier filing dates herein.
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 .
Response to Arguments
Applicant's arguments filed December 18, 2025 have been fully considered but they are not persuasive. Regarding Applicant’s remarks regarding the rejections under §103 in view of Borohovski and Fuller, the Examiner respectfully disagrees. Borohovski teaches an iterative profiling and identification process which identifies software components in a system. The system creates a set of identifications in an identifier list for the stack (208, Fig 7, see e.g. initial tokens added to list as in ¶69) identify a first set of components in the stack, and iteratively applies its analysis technique, including parse the the metadata (212, Fig. 7) and application of induction rules, (216, Fig. 7) as well as machine-learning classification, to add to, and refine the identifications in the list (e.g. adding to list 208 as in ¶¶70&71, adding component identifications (“second assets”) not in the initial identification based on the attributes of the first assets). Importantly here, in ¶70 Borohovski describes the process as “Based on the recognition of identifying aspects, typified by identifiers embedded in the page metadata, the identifier list 208 of tokens is updated to potentially include additional tokens, to refine the product identifications and versions employed, and, as appropriate, adjust the confidence weights associated with the different token fields.” Inherently, in Borohovski, there is the weights are adjusted to refine the identification of products identified in for inclusion. That is, Borohovski teaches the confidence for inclusion in the identifier may be adjusted as appropriate as part of the identification process. While Borohovski does not teach a “threshold” per se, it teaches adjustment of the weights and confidence factors sufficient for asset identification. This includes, for example, using the mutual use rules and other induction rules to assign confidence weights for various asset identifications (see table 1 after ¶68). It would be obvious to one of ordinary skill, therefore, to apply a threshold as taught by Fuller, to this adjustable weight and confidence system described in Borohovski in order to carryout production identification for stacks because Fuller teaches use of such a threshold in the context of specifying a tolerance for configuration matching (see fuller e.g. ¶155). These arguments, therefore, are unpersuasive and the rejection is maintained.
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 1-4,9-14 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over “Borohovski” (US PG Publication 2015/0172308) in view of “Fuller” (US PG Pub 2006/0168183).
Regarding Claim 1, Borohovski teaches:
1. A method comprising: Identifying, by one or more processors, a state of a solution stack among a plurality of different solution stacks in a computer environment, the state identifying a first set of assets as belonging to the solution stack; (Fig. 4, 140, ¶¶44-49 describe a process of auditing the software components of a web page to identifying the components of the software stack associated with the web page, See further e.g. Fig. 7 Audit Phase in detail)
monitoring, by the one or more processors iteratively based on one or more time intervals, the solution stack for a change to the state of the solution stack comprising a set of assets forming the solution stack;; (Fig. 4, 132, 136,140,146, ¶¶44-49 teaches a cyclical process of crawling, auditing and reporting on the stacks of components for a webpage. Further ¶20 teaches the fig. 4 process is repeated, and ¶45 and ¶49 describes bounding the process based on based on a defined crawl duration interval time)
causing, by the one or more processors, profiling of the one or more first assets of the first set of assets to identify one or more first attributes of the one or more first assets;(Fig. 7, ¶¶65-74, describe the audit process of identifying software components and versions in the software stack)
identifying, by the one or more processors using the one or more first attributes, one or more second assets of the computer environment not included in the state of the solution stack but related to one or more first assets of the first set of assets of the solution stack and a candidate asset for belonging to the solution stack;
; (Fig. 7, ¶¶65-74, describe the audit process of identifying software components and versions in the software stack -including 212 Fig. 2 parsing the metadata to identify software components of the stack)
causing, by the one or more processors, profiling of the one or more second assets to identify one or more second attributes of the one or more second assets; (214-218, Fig. 7, ¶¶71-73 teaches a data analysis to apply induction rules and identifying other software components based on the collected data)
comparing, by the one or more processors, the one or more first attributes of the one or more first assets belonging to the solution stack to the one or more second attributes to determine whether the one or more second assets belong to the solution stack, each of the one or more first attributes and the one or more second attributes assigned a weight; (Fig. 7, ¶¶65-74, describe the audit process of identifying software, where the use attributes of the software are compared, e.g. using a mutual use matrix and other metadata to determine components of the software stack, and assigning weights based on degrees of confidence for a particular component being part of the stack based on data analysis (see ¶¶69,70,77)
determining, by the one or more processors based on the comparison, that a weighted score of matching the one or more second attributes of a second asset of the one or more second assets to the one or more first attributes… the threshold set to a value of the weighted score of the candidate asset being sufficient for inclusion in the solution stack; (Fig. 7, ¶¶65-74, describe the audit process of identifying software, where the use attributes of the software are compared, e.g. using a mutual use matrix and other metadata to determine components of the software stack, and assigning weights based on degrees of confidence for a particular component being part of the stack based on data analysis (see ¶¶69,70,77) see further e.g. “Based on the recognition of identifying aspects, typified by identifiers embedded in the page metadata, the identifier list 208 of tokens is updated to potentially include additional tokens, to refine the product identifications and versions employed, and, as appropriate, adjust the confidence weights associated with the different token fields. “ (¶70) [Paragraphs 66-70, including table 1, describe adjusting the confidence intervals as appropriate for updating the identification of included software elements based on updated confidence level. Inherent here in Borohovski is the selection and adjustment of a cut-off level sufficient for addition to the identifier list 208 in order to carry out Borohovski. While Borohovski does not teach a “threshold” per se, it would be obvious to one of ordinary skill in the art, however, to adjust the confidence sufficiency needed for identification of an asset as described in Borohovski in combination with the use of a “threshold” based on these teachings of Borohovski and the teachings of Fuller described below]
identifying, by the one or more processors based at least on the determination, the second asset as belonging to the solution stack; (Fig. 7, ¶¶65-74, describe the audit process of identifying software, where the use attributes of the software are compared, e.g. using a mutual use matrix and other metadata to determine components of the software stack, and assigning weights based on degrees of confidence for a particular component being part of the stack based on data analysis (see ¶¶69,70,77)
and including, by the one or more processors, the one or more second assets as additional assets of the set of assets of solution stack with the first set of assets in continuing monitoring the solution stack. (Fig. 7, ¶¶65-74, describe the audit process of identifying software, where the use attributes of the software are compared, e.g. using a mutual use matrix and other metadata to determine components of the software stack, and assigning weights based on degrees of confidence for a particular component being part of the stack based on data analysis (see ¶¶69,70,77) – further see Fig. 4 teaches repeating the crawling/auditing/reporting cycle of fig. 4, ¶¶44-49).
Borohovski further does not teach, Fuller teaches: …is greater than a threshold;
(See e.g. Fuller Fig. 5 ¶¶155, 161, 195 describing a system which scores similarities between components of system configurations and determines where the similarity scores are above a threshold set to a specific tolerance to indicate a match).
In addition, it would have been obvious to one of ordinary skill in the art prior to the effective filing date of the application to combine the teachings of Borohovski with those Fuller as each is directed to managing and matching software system configurations and Fuller recognized “Increasingly, computers are required to be used and programmed by those who are not highly trained in computer programming techniques….As a result, in many cases it is extremely difficult for a user to be able to create various computer programs and distribute these programs among devices in a distributed system” (¶6) and further Fuller provides “a difference or matching score may be computed, e.g., based on similarities or differences between the components, where exceeding a tolerance threshold may determine whether two components match.”
Regarding dependent claims 2-4, and 9-11, Borohovski further teaches:
2. The method of claim 1, further comprising receiving, by the one or more processors, identification of the first set of assets as belonging to the solution stack from one a device or a user. (See Borohovski teaches a wizard e.g. ¶86 for user entry of supplementary information, as in ¶59 including an inventory of software components for the software stack for including in the data analysis process of Fig. 7).
3. The method of claim 1, further comprising causing, by the one or more processors, one or more devices to profile the one or more first assets or the one or more second assets. (See Borohovski teaches a system in Fig. 4 and 7 of crawling and auditing the software stack components in e.g. ¶¶44-49, 65-74).
4. The method of claim 1, further comprising requesting, by the one or more processors, a connectivity table or network statistics from one or more devices to profile the one or more first assets or the one or more second assets. (See Borohovski ¶¶66-67,74,76 teaches use of a metadata such as a mutual use matrix comprising usage statistics from the networked software stack components for use in the audit data analysis of fig. 7.
9. The method of claim 1, wherein the weighted score represents a probability that the second asset belongs to the solution stack. (Fig. 7, ¶¶65-74, describe the audit process of identifying software, where the use attributes of the software are compared, e.g. using a mutual use matrix and other metadata to determine components of the software stack, and assigning weights based on degrees of confidence for a particular component being part of the stack based on data analysis (see ¶¶69,70,77)
10. The method of claim 1, further comprising determining, by the one or more processors,the weighted score as a function of individual scores for matches between the first one or more attributes and the second one or more attributes. (Fig. 7, ¶¶65-74, describe the audit process of identifying software, where the use attributes of the software are compared, e.g. using a mutual use matrix and other metadata to determine components of the software stack, and assigning weights based on degrees of confidence for a particular component being part of the stack based on data analysis calculated based on data analysis on metadata including e.g. mutual use matrix between components(see ¶¶69,70,77))
11. The method of claim 1, further comprising determining, by the one or more processors, the weighted score as a function of individual scores for one or more of determined physical connections, logical connections, physical dependencies or logical dependencies. (Fig. 7, ¶¶65-74, describe the audit process of identifying software, where the use attributes of the software are compared, e.g. using a mutual use matrix and other metadata to determine components of the software stack, and assigning weights based on degrees of confidence for a particular component being part of the stack based on data analysis calculated based on data analysis on metadata including e.g. mutual use matrix between components indicating logical connections and dependencies among the components (see ¶¶69,70,77))
Claims 12—14 are rejected on the same basis as claims 1, 2 and 4 respectively above.
Claim 19 is rejected on the same basis as claim 1 above.
Claim 5-8, 15-18 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over “Borohovski” (US PG Publication 2015/0172308) in view of “Fuller” (US PG Pub 2006/0168183) as applied above and further in view of “Maheshwari” (US PG Pub 2013/0219044).
Regarding Claim 5, Borohovski et al teach the limitations of claim 1 above but do not further teach, while Maheshwari teaches:
5. The method of claim 1, further comprising requesting, by the one or more processors, a communication log from one or more devices to profile the one or more first assets or the one or more second assets. (Maheshwari ¶¶39-40 260-289, fig. 2 and 350, fig. 3, ¶¶47, 57 teaches a system of software stacks which uses stored message cues 280 where the message queues may be monitored to identify communications between stack components)
In addition, it would have been obvious to one of ordinary skill in the art prior to the effective filing date of the application to combine the teachings of Borohovski with those Maheshwari as each is directed to software stack monitoring and Maheshwari recognized there exists “a need to correlate execution characteristics across components implemented on multiple stacks.” (¶10).
Regarding Claim 6, Borohovski et al teach the limitations of claim 1 above but do not further teach, while Maheshwari teaches:
6. The method of claim 1, further comprising identifying, by the one or more processors, the one or more second assets as related to the first one or more assets based on the one or more second assets being connected to or have communicated with the first one or more assets. (Maheshwari ¶¶39-40 260-289, fig. 2 and 350, fig. 3, ¶¶47, 57 teaches a system of software stacks which uses stored message cues 280 where the message queues may be monitored to identify communications between stack components)
In addition, it would have been obvious to one of ordinary skill in the art prior to the effective filing date of the application to combine the teachings of Borohovski with those Maheshwari as each is directed to software stack monitoring and Maheshwari recognized there exists “a need to correlate execution characteristics across components implemented on multiple stacks.” (¶10).
Regarding Claim 7, Borohovski et al teach the limitations of claim 1 above but do not further teach, while Maheshwari teaches:
7. The method of claim 1, further comprising identifying, by the one or more processors, the one or more second assets as related to the first one or more assets based on the one or more second assets accessing or sharing a same data with the one or more first assets. (Maheshwari ¶¶39-40 260-289, fig. 2 and 350, fig. 3, ¶¶47, 57 teaches a system of software stacks which uses stored message cues 280 where the message queues may be monitored to identify communications between stack components)
In addition, it would have been obvious to one of ordinary skill in the art prior to the effective filing date of the application to combine the teachings of Borohovski with those Maheshwari as each is directed to software stack monitoring and Maheshwari recognized there exists “a need to correlate execution characteristics across components implemented on multiple stacks.” (¶10).
Regarding Claim 8, Borohovski et al teach the limitations of claim 1 above but do not further teach, while Maheshwari teaches:
8. The method of claim 1, further comprising identifying, by the one or more processors, the one or more second assets as related to the first one or more assets based at least on the one or more second assets sharing a same storage or a virtualization host as the one or more first assets.
(Maheshwari ¶¶39-40 260-289, fig. 2 and 350, fig. 3, ¶¶47, 57 teaches a system of software stacks which uses stored message cues 280 where the message queues may be monitored to identify communications between stack components)
In addition, it would have been obvious to one of ordinary skill in the art prior to the effective filing date of the application to combine the teachings of Borohovski with those Maheshwari as each is directed to software stack monitoring and Maheshwari recognized there exists “a need to correlate execution characteristics across components implemented on multiple stacks.” (¶10).
Claim 15-18 are rejected on the same basis as claims 5-8 respectively above.
Regarding Claim 20, Borohovski et al teach the limitations of claim 19 above but do not further teach, while Maheshwari teaches: 20. The non-transitory computer-readable medium of claim 19, further comprising instructions that the one or more processors to identify the one or more second assets as related to the first one or more assets based on one or more of the following: the one or more second assets being connected to or have communicated with the first one or more assets, the one or more second assets being connected to or have communicated with the first one or more assets or the one or more second assets accessing or sharing a same data with the one or more first assets. (Maheshwari ¶¶39-40 260-289, fig. 2 and 350, fig. 3, ¶¶47, 57 teaches a system of software stacks which uses stored message cues 280 where the message queues may be monitored to identify communications between stack components)
In addition, it would have been obvious to one of ordinary skill in the art prior to the effective filing date of the application to combine the teachings of Borohovski with those Maheshwari as each is directed to software stack monitoring and Maheshwari recognized there exists “a need to correlate execution characteristics across components implemented on multiple stacks.” (¶10).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. The Prior Art cited in the attached PTO-892 form includes additional prior art relevant to applicant’s disclosure regarding monitoring and analysis of software solution stacks.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MATTHEW J BROPHY whose telephone number is (571)270-1642. The examiner can normally be reached Tuesday-Thursday 9:00am-4: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, Wei Zhen 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.
MJB
3/6/2026
/MATTHEW J BROPHY/Primary Examiner, Art Unit 2191