DETAILED ACTION
This action is responsive to the Application filed 8/07/2023.
Accordingly, claims 1-20 are submitted for prosecution on merits.
Claim Objections
Claim 2 is objected to because of the following informalities: a typo error in form of a “the an” (enterprise-wide) on line 3 necessitates appropriate correction.
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, 11, 16 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., Saleh-Esa discloses a law of nature, Saleh-Esa discloses a natural phenomenon, or an abstract idea) without significantly more. Claim(s) 1, 11, 16 is/are directed to Abstract Idea. The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception because the 2-step analysis as follows.
Eligibility of claim 1
Step I
Claim 1 is directed to a method category.
Step 2A
prong One
The elements recited as “accessing a library”, “scanning … documentation library … to identify technical documentation”, “instantiating … technical documentation set”, “monitoring DevOps to trigger a scan” and “revising the documentation set” are all activities that can be practically performed by a human mind or via use of pen/paper. A human can access documentation library, scan its content, identify a technical item of interest, monitor information based on the technical item, effectuate a decision to make another scan and updating/revising the scan record. These are mere steps of identifying/collecting documentation, analyzing evaluating the information and render decision to record or reorganize the data which describe activity flow of a typical Mental Processes subgroup defined under MPEP 2106.04(a)(2)
prong Two:
The elements recited as “documentation library”, “technical entitlement” , DevOps events amount to well-known static concepts, stored information or real-time data that can be detected or identified from an application and recognized by a human coupled with use of a generic computer. No part in the documentation library or technical entitlement is understood beyond a mere static and established concept with no connection with each other, Saleh-Esa discloses claim does not provide event hooks by a DevOps, such as message queues, endpoints and pipeline control associated with DevOps; but merely describes this DevOps via a generic “monitoring”.
The limitations surrounding scanning and monitoring or revising do not show how a scan can reduce memory overhead, alleviate NW congestion, or optimize CPU utilization on large corpus scanning; nor can the claim show how these limitations meaningfully improve entitlement processing, diversifying or promoting; nor is there a direct result from monitoring/scanning toward improving the internal physical and hardware functionality of host system for which a technical entitlement is destined.
The claim merely describes a generic administrative workflow including well-understood concepts and static information instead of demonstrating a framework effecting a solution associated with real-time DevOps compliance and entitlement management. Per MPEP 2106.04(d) the claim element as recited fail to integrate the Abstract Idea of prong one into a Practical application.
Step 2B
The action elements recited as “scanning”, “monitoring” are well-understood techniques or routine in information processing and structuring – MPEP 2106.05(a), (b); and when combined, they cannot demonstrate a non-conventional cooperation that improve SW development environment or a transformation effecting a new solution to entitlement management in software- MPEP 2106.05(c ) (e)
As claimed these scanning and monitoring steps preclude a restrictive scanning scenario in which code or paths linked to detected DevOps events can support finetuning entitlement of SW; instead, these elements only describe a broad scanning or re-scanning understood in a very high level of generality. These additional elements in their high-level of genericity and well-understood nomination fail to include non-conventional data or mechanisms to demonstrate a inventive concept being realized. MPEP 2106.05(d) (f)
Claim 1 is deemed non-eligible under the 35 USC § 101 statute.
Eligibility of claim 11
Step I
Claim 11 is directed to machine/system category.
Step 2A
prong One:
The elements recited as “documentation library”, “technical entitlement” , DevOps events amount to well-known static concepts, stored information or real-time data that can be detected or identified from an application and recognized by a human coupled with use of a generic computer.
These are mere steps of identifying/collecting documentation, analyzing evaluating the information and render decision to record or reorganize the data which describe activity flow of a typical Mental Processes subgroup defined under MPEP 2106.04(a)(2)
prong Two:
The elements recited as “documentation library”, “technical entitlement”, DevOps events amount to well-known static concepts, stored information or real-time data that can be detected or identified from an application and recognized by a human coupled with use of a generic computer
The claim merely describes a generic administrative workflow including well-understood concepts and static information instead of demonstrating a framework effecting a solution associated with real-time DevOps compliance and entitlement management. Per MPEP 2106.04(d) the claim element as recited fail to integrate the Abstract Idea of prong one into a Practical application.
Step 2B
The elements recited as “scanning”, “monitoring” “computer program code” as additional elements are well-understood computer techniques or routine used in information processing and structuring – MPEP 2106.05(a), (b); and when combined, they cannot evidence of a non-conventional cooperation between them indicative of an improvement in SW development environment or a transformation effecting a new solution to entitlement management in software- MPEP 2106.05(c ) (e)
Claim 11 is deemed non-eligible under the 35 USC § 101 statute
Eligibility of claim 16
Step I
This claim is directed to a product/apparatus category.
Step 2A
prong One
The elements recited as “accessing a library”, “scanning … documentation library … to identify technical documentation”, “instantiating … technical documentation set”, “monitoring DevOps to trigger a scan” and “revising the documentation set” are all activities that can be practically performed by a human mind or via use of pen/paper. A human can access documentation library, scan its content, identify a technical item of interest, monitor information based on the technical item, effectuate a decision to make another scan and updating/revising the scan record. These are steps of identifying/collecting documentation, analyzing evaluating the information and rendering decision to record or reorganize the information which merely describe activity flow of a typical Mental Processes subgroup defined under MPEP 2106.04(a)(2)
prong Two:
The elements recited as “documentation library”, “technical entitlement” , DevOps events amount to well-known static concepts, stored information or real-time data that can be detected or identified from an application and recognized by a human coupled with use of a generic computer
The claim merely describes a generic administrative workflow including well-understood concepts and static information instead of demonstrating a framework effecting a solution associated with real-time DevOps compliance and entitlement management. Per MPEP 2106.04(d) the claim element as recited fail to integrate the Abstract Idea of prong one into a Practical application
Step 2B
The elements recited as “scanning”, “monitoring” “computer program code”, ”computer processors” as additional elements are expressed in a generic manner and construed mostly as well-understood computer techniques or routine used in standard computer-based information processing and structuring – MPEP 2106.05(a), (b); and when combined, they cannot demonstrate a non-conventional cooperation that improve SW development environment or a transformation effecting a new solution to entitlement management in software- MPEP 2106.05(c ) (e)
Claim 16 is deemed non-eligible under the 35 USC § 101 statute
Step 2B analysis of dependent claims.
Claim 2 recites enterprise-wide technical library or documentation repository comprising content relating to SW, middleware operational procedures; and this static characterization of repository or library cannot add significantly more to the abstract Idea.
Claim 3 recites scanning to identify documentation matching the entitlement to identify associated relevant documentation; these steps belong to mental processing and cannot add significantly more to the Abstract Idea.
Claims 4, 12, 17 recite filtering the technical documentation based on observed usage of the entitlement; this activity falls into the typical organization of information by a human activity associated with a mental process.
Claim 5 recites analyzing the entitlement of a environment based on user classification of usage data, and this human-based analysis constitute well-understood administrative activities than can be performed by a human or via pen/paper.
Claims 6, 13, 18 recite using a NLP model trained on technical documentation library to identify pages related to technical documentation; the recital of a model in very high level of generality for the purpose to identify documentation fails to show how this training mode operates in order to reach the desired result of identifying pages; therefore cannot add significantly more to the abstract Idea.
Claim 7 recites monitoring of DevOps events in terms of monitoring predefined actions taken by a user; this monitoring of user events falls under the well-known activity associated with mental processes subgroup of a Judicial exception.
Claims 8, 14, 19 recite automatically filtering customized technical documentation set responsive to identifying a DevOps event; but the enumerating of functional elements without providing implementation details surrounding these nominal elements fail to make customized set, filtering, or predefined DevOps event as claimed susceptible of realizing a transformation that amount to significantly more than the abstract Idea.
Claims 9, 15, 20 recites monitoring DevOps events such as new Software installation, newly added entitlement, or code check-in(s), and this fails to demonstrate how these events effectuate a non-conventional transformation or improvement to the technical field of DevOps management or operation.
Claim 10 recites revising a technical documentation set by dynamically updating the set to accommodate a new entitlement context; but this update operation amounts to mere listing of a nominal functionality along with a desired result. This activity fails to demonstrate how updating is being implemented upon a documentation set so to specifically achieve a non-conventional transformation or improvement to the technical field of entitlement managing or accreditation.
In all, claims 1-20 are deemed non-eligible under the 35 USC § 101 statute.
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-5, 7, 10-12, 16-17 is/are rejected under § 35 U.S.C. 103 as being unpatentable over Saleh-Esa et al, USPubN: 2018/0225194 (herein Saleh-Esa) in view of Bouffard et al, USPubN: 2023/0049227 (herein Boudreau), Hansen et al, USPN: 2019/0098082(herein Hansen) and Rachamadugu , USPN: 10,200,246 (herein Rachamadugu)
As per claim 1, Saleh-Esa discloses a method comprising:
accessing a technical documentation library (Blockchain – para 0031; para 0052-0053, 0062, 0066, 0071; Fig. 9-10; Blockchain/OpenChain for entitlements, open source distributed ledger – para 0023, para 0028) of an enterprise computer system (para 0074; Fig. 12);
scanning (scans 222- Fig. 2; framework may include support of codification of policies and requirement to support build, test and deployment. Rules may relate to entitlement, scans and policy – para 0030-0031; scans 222 – para 0036 - Note1: distributed Blockchain and framework having rules for consolidating policies and requirements related to codifying, build and deployment – para 0030 – and operating with rule-driven scans to identify entitlement smart contract – para 0007 - reads on scanning the documentation library/blockchain in relation to an entitlement of the system to a) provide guidance in servicing developers or user request for entitlement – para 0031, para 0048, 0055 – b) to identify resources, privileges to add entitlement to a delegate – para 0054; Fig. 9 – or c) to review/reconcile a ledger – Fig .8 ) the technical documentation library (see above) based on technical entitlements (federates entitlements, entitlement policies - para 0006-0007) of a given system environment (para 0051, 0055; policies … mapped to entitlements from business partners …. Business (company) – para 0074; entitlements that may align to firmwide policies – para 0051) to identify technical documentation (JDK version, application logs and policies, configurations and properties, ID roles, Scheduling and Notifications – para 0036; resource may be any data, reports, applications, privileges – para 0054; Fig. 11; data structure may be defined with version control, number of use, life span - para 0066) in the technical documentation library (see above) corresponding to the technical entitlements;
instantiating a customized technical documentation set (package delivery packaging wrappers, packaging processor … ensure that the package is created for the application – para 0033; smart contract – para 0065-0066; Fig. 10 and entitlement data structure - para 0071) for the given system environment based on the corresponding technical documentation(para 0039 - Note2: Framework and automation tools enabling automated build and continuous testing, and deployment coupled with validation tools, QA features and Packaging processor – para 0033 – using repositories, policies requirements, and standards rules support to define and codify a build as part of a created package and POE blockchain in configuring a smart contract, entitlement data structure for a entitlement instance of a POE reads on instantiating a customized documentation set – e.g. package, contract or entitlement data structure - for a given environment – e.g. test, delivery, packaging framework or BlockChain/DevOps technology, see para 0008 - based on technical entitlement- see para 0071).
A) Saleh-Esa does not explicitly disclose leveraging tools with continuous, rapid Dev-Ops production with blockchain management of entitlements in terms of
monitoring DevOps events to trigger a new scan based on the technical entitlements of the given system environment to identify new scan results; and revising the customized technical documentation set for the given system environment based on the new scan results.
Saleh-Esa discloses management of entitlements associated with delivery tool and standards that support the provisioning (para 0050; Fig. 8) by the control and entitlement framework under a Entitlement blockchain established upon proof of Entitlement consensus (para 0064), in leveraging firmwide code repositories and development tools having standardization support (para 0008),using distributed, decentralized ledger technology where separate ledger access can permit real-time review and updates, in that leveraging the codified entitlement under this distributed access can be made to align with firm policies, the de-centralized ledger access providing ability to review the entitlement – reconciliation in real-time - to align with user attributes(para 0051), the delivery and decentralized entitlement framework facilitating continuous application delivery using optimization and automation in environment of the likes of Dev-Ops model or automation with DevOps organizational structures (para 0008) so to render development cycles by SW developers more agile and more efficient in SW production (para 0025-0026). So entitlement framework effecting continuous and prompt delivery of SW production – under Dev-Ops - using Blockchain/ledger entitlement via leveraging of repositories, development tools and standardization support with capability to review configuration set associated with generating a entitlement structure consensus via a distributed ledger access is recognized.
Monitoring compliance check events associated with scanning an entitlement deployment set (blueprint) is shown in Rachamadugu (e.g. scan the blue print to ensure operating system versions used in the blueprint are approved by corporate policies – col. 27 li. 50 to col. 28 li. 13) ; that is, for each fetching and analysis of entitlement-related element from micro-segmented policy database instance (col. 27 li. 60 to col. 28 li. 3) in response to a deployment-time request entitlement check, a developer-created blueprint structure is customized (col. 19 li. 50 to col. 20 li. 8) via an API (Fig. 20) to collect/aggregate parameters and entitlement requirements forming criteria with which to check compliancy to regulations, security, contractual terms and best-practices of the application (col. 19 li. 16-49) being entitled for deployment under policies of an enterprise IaaS(col. 42 li 21-60), where one such blueprint can be edited (Fig. 18) updated or customized to match constraints of a hierarchy, for consistency of reference or due to additions to entitlement on behalf of the customer(col. 25 li. 4 to col. 26 li. 8); such that if an entitlement constraint or criterion is not met based on the blueprint, deployment cannot proceed (Fig. 16) or is subjected to abort or postponement(col. 23 li. 2-19), the entitlement checks via use of blueprint customization benefitting from a secure DevOps automation system for obtaining the most compliant, secure, and budgetary checks thereby assuring best practice policy-enforcement benefits of business perspective (col. 23 li. 39-49). Hence revising the customized technical documentation set for the given system environment (entitlement check runtime) based on the newly generated policy/DB collection structure and scan results thereof is recognized.
Tracking DevOps for events triggering alerts associated with deployment-provision of services in accordance to tenant entitlement enforced by the PaaS/IaaS infrastructure (para 0027-0030) is shown in Hansen, where a PaaS service manager provides interfaces to lifecycle operations exposed via RestAPI, CLI between the PSM client and backend services so that a DevOps can monitor state of the job execution for runtime monitoring and generating devOps alerts (para 0038)
Similar to use of software kit and interfaces like in DevOps environment, Bouffard discloses a policy information point (PIP) environment deployed from APIs, SDK and library provisioned from the policy framework(para 0052) orchestrated by a policy enforcement and decision platform (para 0050 )in conjunction front end applications and backend entitlement DB (Fig. 4), and operating via the policy decision point platform (PDP) for examining DB credentials in response to intercepting API calls associated with application access by the user (para 0026-0031), the PDP and the PIP (para 0021-0023) utilizing API to access the backend entitlement database, via a API controller, to query stored entitlement identities (para 0053-0054; Fig. 5), thereby to identify and determine if the requesting user has credentials to be authorized for operating the API or a business action (para 0048-0051), including possible update of the database(para 0032). Hence, interception of APIs calls implemented via SW development kit underlying a policy enforcing and entitlement check platform, where upon detection of API calls from users, an entitlement database is accessed and scanned for the proper identities and credentials to be located and verified against a authentication or entitlement policy for decision to grant a user access or to possibly update the entitlement database is recognized.
Thus, as DevOps or SDK based development platform offer secure access to various application assets and SW development endpoints with support of SDK, CLI, REST API and library (see Hansen: para 0036, 0038) and that enforcing policies and regulations surrounding user API/access to particular SW application – test as in Saleh-Esa - bounded by entitlement credentials necessitate checking and verification - as in Gouffard - with reference to backend database, it would have been obvious for one of ordinary skill in the art before the effective filing date of the invention to policies enforcing platform in accordance to PaaS/IaaS infrastructure of continuous integration and effect of leveraging front end tools (e.g. SDK, API library) associated with Dev-Ops continuous, rapid organizational and production scheme with back-end blockchain management in Saleh-Esa so that
(1) DevOps operations involving SW access and developer APIs would be subjected to monitoring – as in Hansen - whereby particularly detected DevOps events would trigger access to query a backend database– entitlement DB as in Gouffard - effecting a new scan so to collect relevant technical entitlements corresponding to a given system environment – entitlement of software under test as in Saleh-Esa --- where the returned scan includes relevant technical documentation – as per Gouffard and Rachamadugu- corresponding to an entitled entity; so that
(2) based thereon, the front end platform would revise the customized technical documentation set - as per Rachamadugu - for the given system environment based on the new scan results; e.g. to approve user access or update the entitlement database; because
provision of a backend entitlement database to collect latest entitlement credentials for software and application under development by secure frameworks and API of the likes of DevOps to enforce system policies coupled with use of intercepting/monitoring frontend layer to detect DevOps operations or intended user access/API attempts/calls to the SW assets or application code under the enterprise wide policies enforcing infrastructure as set forth above in Saleh-Esa, so to enable real-time trigger responsive to one such detected API events, via backend support in form of DB query and returned scans, and set up a dynamic verification (as set forth above) using the latest scan result including identification data and entitlement authorization and policies constraints based on which for the development front end to decide on as whether to grant or deny operation to the identified user – DevOps developer - in regard to intended software access, thus improving the secure operation to users operating with assets inside the development infrastructure, while assuring that enterprise-wide policies established for software entitlement and relevant tenants are properly enforced during any given stage of the DevOps development cycles, deterring use of unauthorized users and information usage/configuration that surpass the restrictive boundaries of corresponding back-end stored entitlement.
As per claim 2, Saleh-Esa discloses method of claim 1, wherein the technical documentation library of the enterprise computer system comprises an enterprise-wide technical documentation library (see Blockchain, database – para 0023; ID and Entitlements 218 include ID, roles and repository credentials – para 0036) of an enterprise-wide technical documentation repository (entitlement may specify … user from company a can access reports – para 0073; para 0071) in the enterprise computer system, the an enterprise-wide technical documentation library comprises content (policies of the hosting business (company) to provide seamless mapping of entitlements – para 0074; entitlements that may align to firmwide policies – para 0051) relating to one or more of software, middleware, of operational procedures (DevOps organizational structures – para 0008; Dev-Ops model – para 0025; performance testing, open source – para 0023).
As per claim 3, Saleh-Esa discloses method of claim 1, wherein scanning the technical documentation library based on technical entitlements of the given system environment further comprises scanning the technical documentation library (scans 222- Fig. 2; framework may include support of codification of policies and requirement to support build, test and deployment. Rules may relate to entitlement, scans and policy – para 0030-0031; scans 222 – see Note1) to identify technical documentation directly matching the technical entitlements of the given system environment (para 0074) and to identify associated relevant documentation (Rules Policies: Role policy mappings, Mapped entitlement from business partner – Figure 12).
As per claim 4, Saleh-Esa discloses method of claim 1, wherein scanning the technical documentation library based on technical entitlements of the given system environment further comprises filtering the technical documentation library (consensus reconciliation - Fig. 8; systematic review for right updates to ledger – para 0050; entitlement review … to monitor … transactions aligned to user attributes where access may be confirmed by security … the POE is a modified raft – para 0051,0052) based on observed usage of the technical entitlements (Note2: tracking of transactions and use of review to align the observed transactions with user attribute based on ledger access with update to ledger – per a Reconciliation module - and generating a modified raft to the POE as result from the entitlement review reads on filtering technical documentation in library based on observed usage) in the given system environment.
As per claim 5, Saleh-Esa discloses method of claim 1, wherein scanning the technical documentation library based on technical entitlements of the given system environment further comprises analyzing the technical entitlements of the given system environment (Figure 12) based on user-generated classification data(authorized roles and responsibilities – para 0024; entitlements … may include … roles and credentials – para 0036; end user entailment attributes (name, role) – para 0050; categories may include Business, Functional, Data and UX … Web services – para 0039) related to usage.
As per claim 7, Saleh-Esa discloses method of claim 1, wherein monitoring the DevOps events to trigger the new scan based on the technical entitlements of the given system environment further comprises monitoring predefined actions taken by a technical user of the given system environment.
(Refer to rationale A of claim 1 using the DevOps designer action monitoring by Hansen)
As per claim 10, Saleh-Esa does not explicitly disclose method of claim 1, wherein revising the customized technical documentation set for the given system environment based on the new scan results further comprises dynamically updating the customized technical documentation set to accommodate new technical entitlements and technical documentation contexts.
Modifying and updating the structure blueprint that collects scanned information from policies and entitlement database is shown in Rachamadugu in collecting entitlement-related information from a database, so that a developer-created blueprint structure is customized (col. 19 li. 50 to col. 20 li. 8) via an API (Fig. 20) to collect/aggregate parameters and entitlement requirements forming criteria with which to check compliancy to regulations, security, contractual terms and best-practices of the application (col. 19 li. 16-49) being entitled for deployment under policies of an enterprise IaaS(col. 42 li 21-60), where one such blueprint can be edited (Fig. 18) updated or customized to match constraints of a hierarchy, for consistency of reference or due to additions to entitlement on behalf of the customer(col. 25 li. 4 to col. 26 li. 8), which can be used to make update to table of the source control (col. 10, li. 36-57; col. 45 li. 18-25)
Thus, it would have been obvious for one of ordinary skill in the art before the effective filing date of the invention to implement initiation of a entitlement collection set in Saleh-Esa approach so that a review of the set can be offered to the user for further action, according to which, a customized technical documentation set for the given system environment based on the new scan results can be subjected to dynamically updating – as shown in Rachamadugu – in order for it to accommodate new technical entitlements and technical documentation contexts, including update made backward to reconcile with the repository; because
Information stored in a policies database or entitlement library reflect information that can be subjected to constant changes due to the complex nature of vulnerability attack and ever increasing scale of malicious intrusion affecting application traffic and API interchange, and latest scan result including identification data and entitlement authorization and policies constraints as in Saleh-Esa based on which for the development platform front end – such as DevOps - to decide on as whether to grant or deny operation to the identified user – DevOps developer - in regard to intended software access, would necessitate constant revision and update so to port the most up-to-date fixes back into the respective policies or entitlement database, thus ameliorating the protective aspect of the policy/entitlement documentation data, and improving the secure operation and protection of asset associated with users operating inside the development infrastructure such as DevOps, while assuring that enterprise-wide policies established for software entitlement and relevant tenants are properly enforced and retained during and subsequent to any given stage of the DevOps development cycles, deterring use of unauthorized users and information usage/configuration that surpass the restrictive boundaries of corresponding back-end stored entitlement
As per claim 11, Saleh-Esa discloses a system, comprising: a processor; and a memory, wherein the memory includes a computer program product configured to perform operations for implementing customized technical documentation sets (package delivery packaging wrappers, packaging processor … ensure that the package is created for the application – para 0033; smart contract – para 0065-0066; Fig. 10 and entitlement data structure - para 0071) for multiple system environments (para 0084) of an enterprise computer system, the operations comprising:
accessing a technical documentation library of an enterprise computer system;
scanning the technical documentation library based on technical entitlements of a given system environment to identify technical documentation in the technical documentation library corresponding to the technical entitlements;
instantiating a customized technical documentation set for the given system environment based on the corresponding technical documentation;
monitoring DevOps events to trigger a new scan based on the technical entitlements of the given system environment and identify new scan results; and
revising the customized technical documentation set for the given system environment based on the new scan results.
( All of which having been addressed in claim 1)
As per claim 12, refer to rejection of claim 4.
As per claim 16, Saleh-Esa discloses a computer program product for implementing customized technical documentation sets for multiple system environments of an enterprise computer system, the computer program product comprising: a computer-readable storage medium having computer-readable program code embodied therewith, the computer-readable program code executable by one or more computer processors to perform an operation comprising:
accessing a technical documentation library of an enterprise computer system;
scanning the technical documentation library based on technical entitlements of a given system environment to identify technical documentation in the technical documentation library corresponding to the technical entitlements;
instantiating a customized technical documentation set for the given system environment based on the corresponding technical documentation;
monitoring DevOps events to trigger a new scan based on the technical entitlements of the given system environment to identify new scan results; and
revising the customized technical documentation set for the given system environment based on the new scan results.
( All of which having been addressed in claim 1)
As per claim 17, refer to rejection of claim 4.
Claims 6, 13, 18 is/are rejected under § 35 U.S.C. 103 as being unpatentable over Saleh-Esa et al, USPubN: 2018/0225194 (herein Saleh-Esa) in view of Bouffard et al, USPubN: 2023/0049227 (herein Boudreau), Hansen et al, USPN: 2019/0098082(herein Hansen) and Rachamadugu , USPN: 10,200,246 (herein Rachamadugu) further in view of Wootton et al, USPubN: 2012/0110174 (herein Wootton)
As per claim 6, Saleh-Esa does not explicitly disclose method of claim 1,
wherein scanning the technical documentation library based on technical entitlements of the given system environment (refer to claim 1) further comprises using a natural language processing model trained on the technical documentation library to identify specific pages of the technical documentation library related to technical documentation of the given system environment.
Saleh-Esa discloses applying a machine learning to learn of a web application expressed as alphanumeric input, text considered AN input or even a hyperlink input applied to the learning generate implementation choices (para 0043-0044) when configuring Test screen hash (Fig. 4; para 0046) using a testing framework to correlate testable categories in generating categories of products and services for the designer to consider in direction of further parameterization and consolidating boundary values learned from additional test cases (para 0039) as a manner to reduce extraneous documentation storage (para 0040) and scope. Hence, use of a natural language input into a training model to consolidate boundary values in accordance with hash test for a designer to consider the most acceptable values in the effect of reducing storage of the documentation is recognized.
Wootton discloses API for scanning (Fig. 14A) and crawling stored sources (e.g. app content), to continuously analyze/assess the gathered information from storage/database (para 0031) using artificial intelligence to process feature in the data for a desired rating or categorization (para 0110-0113), the assessment reflecting up-to-date information which can be re-assessed because of new application and changes (para 0114) due to adverse effects caused by malware (para 0115), where scanning corpus of a an app is utilized by a security analyzer using policy rules, such that when a app is updated with change in the policy, the policy is implemented as an arbitrary machine learning model (para 0285) to learn on the changes, to assess via heuristics, characteristics and behavior of objects considered malicious or not (para 0109) in the endeavor to generate, based on scan results as input to the trained model (para 0308), app profile structured with improved classification of malware-affected objects and non-affected objects, thereby consolidating versioned information of an app profile database (para 0302 ; Fig 19)
Hence, using continual modification and re-assess of scanned data from storage (app database) and submitted the scan results for assessing by a security machine learning model to generate security assessment for app content/objects and improved classification thereof reflecting the latest security policy and categorization of undesirable malware content versus unaffected content entails use of a processing model trained on input (text scans) from the technical content or security-related documentation based on scanned sets to identify (via a training model) specific pages or portion of the content in direct relation to technical behavior and causality effect attached with usage of the content in a given policy-driven system environment, for a improved classification of such pages or content portion.
Thus, it would have been obvious for one of ordinary skill in the art before the effective filing date of the invention to implement framework to correlate testable categories in generating categories of products and services for the designer to consider in direction of further parameterization and consolidating boundary values to improve operational organization of a repository in Saleh-Esa so that a machine learning can be employed in support for processing testable input or information scanned from storage/library in terms of
utilizing a natural language processing model trained on the technical documentation library by Saleh-Esa framework, to identify specific pages or recorded content of the technical library related to technical documentation of the given system environment, via use of trained model – as in Wootton use of arbitrary policy machine learning - to generate, based on library scanned data as training input, technical data classified as categories or differentiated profile, thereby consolidating versioned information of technical documentation profile/record in their respective library or datastore; because
the continually state of security-type application being exposed to real-world communication dynamics and vulnerability impact to the state of the content persisted in datastore, database and library due to multitude of traffic, check-in, check-out interchange with the outside environment or internet can alter the integrity of the stored asset necessarily when the asset and changes thereto implicate enterprise wide security coverage and established policies - such as entitlement setting for application software made available to developers in DevOps environment front end; and
use of machine learning techniques to assess of state of these assets or content thereof scanned from corresponding database or library, per effect of intelligent, in-depth evaluation or re-assessment by the model would provide clearer distinction between objects or content of the persisted data, whereby the mixed state of information from the raw training input can be differentiated into subset or categories as part of a improved classification that would be implemented as update to the datastore or library, which in turn can serve as consolidated reference to more evaluation of applications or developed assets in which implications on security regarding data integrity, asset entitlement and information access policies constitute core concerns of enterprise platform(s) on which the applications or assets are being developed or produced for delivery to users.
As per claim 13, refer to rejection of claim 6.
As per claim 18, refer to rejection of claim 6
Allowable Subject Matter
Claims 8-9 as an indivisible ensemble are objected to as being dependent upon a rejected base claim, but would be allowable (pending resolution of any rejection stated in another form) if rewritten in independent form, and so, including all of the limitations of the base claim and any intervening claims, the objected subject matter including:
(claims 8-9) method of claim 1,
wherein monitoring the DevOps events to trigger the new scan further comprises automatically filtering the customized technical documentation set for the given system environment responsive to identifying a predefined DevOps event
wherein monitoring the DevOps events to trigger the new scan further comprises monitoring DevOps events including one or more of when code is checked-in, a new software is installed, a new entitlement added, or the given system environment is reconfigured.
Claims 14-15, 19-20, each pair as an indivisible ensemble are objected to as being dependent upon a rejected base claim, but would be allowable (pending resolution of any rejection stated in another form) if rewritten in independent form, for the same reasons set forth above for claims 8-9.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Tuan A Vu whose telephone number is (571) 272-3735. The examiner can normally be reached on 8AM-4:30PM/Mon-Fri.
If attempts to reach the examiner by telephone are unsuccessful, the examiner's supervisor, Chat Do can be reached on (571)272-3721.
The fax phone number for the organization where this application or proceeding is assigned is (571) 273-3735 ( for non-official correspondence - please consult Examiner before using) or 571-273-8300 ( for official correspondence) or redirected to customer service at 571-272-3609.
Any inquiry of a general nature or relating to the status of this application should be directed to the TC 2100 Group receptionist: 571-272-2100.
/Tuan A Vu/
Primary Examiner, Art Unit 2193
Septembre 18, 2026
Prosecution Insights