DETAILED ACTION
This office action is in response to the amendments filed June 9, 2026.
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 with respect to claim(s) 1-20 have been considered but are moot because the new ground of rejection, necessitated by the amendments to the independent claims, does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
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 “Mohaban” (US PG Pub 2016/0100032) and “Bai” (US PG 2016/0094477).
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)
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 is greater than a threshold,
(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 Bai 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 (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 does not teach, but Mohaban teaches: 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 the change z comprising an addition, removal, or modification ofone or more assets forming the solution stack;(Mohaban e.g. ¶¶24,195-204, Fig. 4, and 640, Fig. 6 teaches an iterative re-discovery of an application structure including adding or removing components based on the up-to-date application state, including at time intervals as in e.g. ¶24)
and continuing iteratively monitoring of the solution stack with the one or more second assets included in the state of the solution stack. (Mohaban e.g. ¶¶24,195-204, Fig. 4, and 640, Fig. 6 teaches an iterative re-discovery of an application structure including adding or removing components based on the up-to-date application state, including at time intervals as in e.g. ¶24)
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 Mohaban as each is directed to system for application component discovery and Mohaban recognized the need that “it may be useful to frequently check if any instances were added or removed to/from a cluster or whether a certain virtual server moved to a different physical server.”
Borohovski does not teach, but Bai teaches:
the threshold being a configurable value defining a minimum weighted score sufficient for the candidate asset to qualify for inclusion in the solution stack;(Bai 1302, Fig. 13, ¶139 describe a user control to enter a threshold for a weighted similarity score to group or not group in the discovered group for an application in process described in e.g. ¶¶140-151, see similarity threshold set as minimum in e.g. ¶146)
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 Bai as each is directed to system for application component discovery and the user control in Bai allows configurability of the grouping where Bai’s “method may also comprise grouping the plurality of servers into a plurality of groups based on the similarity measure and at least a greedy algorithm. Migration of the plurality of servers may be planned based at least on the plurality of groups.” (¶7).
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 in view of “Mohaban” (US PG Pub 2016/0100032) and “Bai” (US PG 2016/0094477) 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.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
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
9/11/2026
/MATTHEW J BROPHY/Primary Examiner, Art Unit 2191
Prosecution Insights