DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This office action is in response to the amendment July 23, 2026.
Claims 1-23 are pending. Claims 24-68 have been canceled by preliminary amendment.
Information Disclosure Statement
The information disclosure statements (IDS) submitted on June 29, 2026 was filed after the mailing date of the application on January 29, 2026. The submissions are in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statements are being considered by the examiner.
Response to Arguments
Applicant’s arguments, see Remarks, filed July 23, 2026, with respect to the rejection(s) of claim(s) 1-23 under §103 been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of the prior art below.
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(s) 1-2,4,5,7-20,22 and 23 is/are rejected under 35 U.S.C. 103 as being unpatentable over “McVeigh” (US PG Pub 2023/0409415) in view of “Srivastava” (US PG Pub 2022/0334829) and further in view of “Boodman” (US Patent 8,756,617).
Regarding Claim 1, McVeigh teaches:
1. (Original) A non-transitory computer readable medium containing instructions that when executed by at least one processor cause the at least one processor to perform operations for designing a modular software platform with extendable functionality, the operations comprising:
accessing a plurality of building blocks, each building block defining a specific set of capabilities for implementation by the software platform for modifying the functionality thereof, (McVeigh See Extension Modules 150, Fig. 1, ¶¶7,31-32 teaches providing a set of extension modules which can be applied to the core multi-tenant SAAS platform to provide customized functionality for tenant-specific services, see further Fig. 2B, ¶45)
and wherein each building block is associated with a specific building block schema defining specific building block connectivity information; (See e.g. McVeigh ¶¶58, 68, 115 describing accessing components including extension modules via URL and version schema which provides for unique identification of components and their location in the system, where the filesystem includes code, data and metadata related to the extensions (see e.g. ¶48) which provides configuration information for configuring the customized components with the extension points).
maintaining a first extension point of a plurality of differing extension points available in the software platform, the first extension point being configured to host at least a first subset of the plurality of building blocks, (McVeigh see Extension Points 148, Fig. 1, ¶¶7,31-32 teaches the modules including extension points at which the build system may link the extension modules in order to incorporate customized tenant specific functionality. see further Fig. 2B, ¶45)wherein the first extension point is associated with a first extension point schema defining first extension point connectivity information; (See e.g. McVeigh ¶¶57-58, 68, 115 describing accessing components including extension modules via URL and version schema which provides for unique identification of components and their location in the system, where the filesystem includes code, data and metadata related to the extensions (see e.g. ¶48) which provides configuration information for configuring the customized components with the extension points, including, for example extension points corresponding to customization functions and input and output types of the extension points ).
enabling selection of the first extension point for hosting at least one of the plurality of building blocks; (McVeigh See ¶¶60-63, 65 describing using reference to select customization extension modules to be included at specific extension points , including using nocode and low code options to specify tenant-specific customizations to be included)
enabling selection of a first building block for hosting by the first extension point; (McVeigh See ¶¶60-63, 65 describing using reference to select customization extension modules to be included in a build, including using nocode and low code options to specify tenant-specific customizations to be included)
and linking the first building block to the first extension point, (See McVeigh Links in Fig. 2B, ¶45 teaches linking the extension modules to the extension points of the core modules as depicted, and is linked in the build process as described in ¶¶74-75)
McVeigh Does not teach, but Srivastava teaches:
using first building block connectivity information and the first extension point connectivity information to generate connectivity instructions defining how the first building block is to be linked with the first extension point, and and implementing the connectivity instructions …modifying the functionality of the software platform.
Srivastava e.g. 216-227, Fig. 2, ¶¶47-49, 54-56 teaches a system which identifies enhancement points in the code, and cloud elements for implement extensions and generates code to integrate the extension at the enhancement point including resolving the compatibility between input/output parameters of the enhancements point and cloud element to ensure compatibility)
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 McVeigh and Srivastava as each is directed to extensible cloud platforms and Srivastava recognized the need for systems “which support an intelligent migration of on-premise applications having custom extensions/add-ons to a cloud platform.” (¶3).
McVeigh further does not teach, but Boodman teaches:
validating the connectivity instructions against the first building block schema and the first extension point schema to determine whether the connectivity instructions include sufficient information to implement hosting of the first building block by the first extension point; (See Boodman e.g. Col. 9, Ln 42-67, Col. 11, Ln 35-59 teach a schema validation which identifies information in the extension which break compatibility which can be identified and corrected)
determining, based on the validating, that the connectivity instructions lack at least one item of information required to implement the hosting; (See Boodman e.g. Col. 9, Ln 42-67, Col. 11, Ln 35-59 teach a schema validation which identifies information in the extension which break compatibility which can be identified and corrected)
obtaining the at least one item of information required to implement the hosting; (See Boodman e.g. Col. 9, Ln 42-67, Col. 11, Ln 35-59 teach a schema validation which identifies information in the extension which break compatibility which can be identified and corrected)
using the obtained at least one item of information to thereby link the first building block to the first extension point and modify (See Boodman e.g. Col. 9, Ln 42-67, Col. 11, Ln 35-59 teach a schema validation which identifies information in the extension which break compatibility which can be identified and corrected)
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 McVeigh and
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 McVeigh and Boodman as each is directed to extensible software systems and Boodman recognized a need in extensible systems to “provide an error message which identifies the particular error detected, and possibly a suggested correction or type of correction that may be applied to address the detected error.” (Col. 9, Ln 54-55).
Regarding Claim 22, McVeigh teaches:
22. (Original) A system for designing a modular software platform with extendable functionality, the system comprising:
at least one processor (1308, 1348 Fig. 13) configured to: access a plurality of building blocks, each building block defining a specific set of capabilities for implementation by the software platform for modifying the functionality thereof, (McVeigh See Extension Modules 150, Fig. 1, ¶¶7,31-32 teaches providing a set of extension modules which can be applied to the core multi-tenant SAAS platform to provide customized functionality for tenant-specific services, see further Fig. 2B, ¶45) and wherein each building block is associated with a specific building block schema defining specific building block connectivity information; (See e.g. McVeigh ¶¶58, 68, 115 describing accessing components including extension modules via URL and version schema which provides for unique identification of components and their location in the system, where the filesystem includes code, data and metadata related to the extensions (see e.g. ¶48) which provides configuration information for configuring the customized components with the extension points).
maintain a first extension point of a plurality of differing extension points available in the software platform, the first extension point being configured to host at least a first subset of the plurality of building blocks, (McVeigh see Extension Points 148, Fig. 1, ¶¶7,31-32 teaches the modules including extension points at which the build system may link the extension modules in order to incorporate customized tenant specific functionality. see further Fig. 2B, ¶45) wherein the first extension point is associated with a first extension point schema defining first extension point connectivity information; (See e.g. McVeigh ¶¶57-58, 68, 115 describing accessing components including extension modules via URL and version schema which provides for unique identification of components and their location in the system, where the filesystem includes code, data and metadata related to the extensions (see e.g. ¶48) which provides configuration information for configuring the customized components with the extension points, including, for example extension points corresponding to customization functions and input and output types of the extension points ).
enable selection of the first extension point for hosting at least one of the plurality of building blocks; (McVeigh See ¶¶60-63, 65 describing using reference to select customization extension modules to be included at specific extension points , including using nocode and low code options to specify tenant-specific customizations to be included)enable selection of a first building block for hosting by the first extension point; (McVeigh See ¶¶60-63, 65 describing using reference to select customization extension modules to be included in a build, including using nocode and low code options to specify tenant-specific customizations to be included) and link the first building block to the first extension point, (See McVeigh Links in Fig. 2B, ¶45 teaches linking the extension modules to the extension points of the core modules as depicted, and is linked in the build process as described in ¶¶74-75)
McVeigh Does not teach, but Srivastava teaches:
wherein linking includes using first building block connectivity information and the first extension point connectivity information to generate connectivity instructions defining how the first building block is to be linked with the first extension point, (Srivastava e.g. 216-227, Fig. 2, ¶¶47-49, 54-56 teaches a system which identifies enhancement points in the code, and cloud elements for implement extensions and generates code to integrate the extension at the enhancement point including resolving the compatibility between input/output parameters of the enhancements point and cloud element to ensure compatibility)
and implementing the connectivity instructions to …modify the functionality of the software platform. (Srivastava e.g. 216-227, Fig. 2, ¶¶47-49, 54-56 teaches a system which identifies enhancement points in the code, and cloud elements for implement extensions and generates code to integrate the extension at the enhancement point including resolving the compatibility between input/output parameters of the enhancements point and cloud element to ensure compatibility)
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 McVeigh and Srivastava as each is directed to extensible cloud platforms and Srivastava recognized the need for systems “which support an intelligent migration of on-premise applications having custom extensions/add-ons to a cloud platform.” (¶3).
McVeigh further does not teach, but Boodman teaches:
validate the connectivity instructions against the first building block schema and the first extension point schema to determine whether the connectivity instructions include sufficient information to implement hosting of the first building block by the first extension point; (See Boodman e.g. Col. 9, Ln 42-67, Col. 11, Ln 35-59 teach a schema validation which identifies information in the extension which break compatibility which can be identified and corrected)
determine, based on the validating, that the connectivity instructions lack at least one item of information required to implement the hosting; (See Boodman e.g. Col. 9, Ln 42-67, Col. 11, Ln 35-59 teach a schema validation which identifies information in the extension which break compatibility which can be identified and corrected)
obtain the at least one item of information required to implement the hosting; (See Boodman e.g. Col. 9, Ln 42-67, Col. 11, Ln 35-59 teach a schema validation which identifies information in the extension which break compatibility which can be identified and corrected)
using the obtained at least one item of information to thereby link the first building block to the first extension point and modify (See Boodman e.g. Col. 9, Ln 42-67, Col. 11, Ln 35-59 teach a schema validation which identifies information in the extension which break compatibility which can be identified and corrected)
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 McVeigh and
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 McVeigh and Boodman as each is directed to extensible software systems and Boodman recognized a need in extensible systems to “provide an error message which identifies the particular error detected, and possibly a suggested correction or type of correction that may be applied to address the detected error.” (Col. 9, Ln 54-55).
Regarding Claim 23, McVeigh teaches:
23. (Original) A method for designing a modular software platform with extendable functionality, the method comprising: accessing a plurality of differing building blocks, each building block defining a specific set of capabilities for implementation by the software platform for modifying the functionality thereof, (McVeigh See Extension Modules 150, Fig. 1, ¶¶7,31-32 teaches providing a set of extension modules which can be applied to the core multi-tenant SAAS platform to provide customized functionality for tenant-specific services, see further Fig. 2B, ¶45) and wherein each building block is associated with a specific building block schema defining specific building block connectivity information; (See e.g. McVeigh ¶¶58, 68, 115 describing accessing components including extension modules via URL and version schema which provides for unique identification of components and their location in the system, where the filesystem includes code, data and metadata related to the extensions (see e.g. ¶48) which provides configuration information for configuring the customized components with the extension points). maintaining a first extension point of a plurality of differing extension points available in the software platform, the first extension point being configured to host at least a first subset of the plurality of building blocks, (McVeigh see Extension Points 148, Fig. 1, ¶¶7,31-32 teaches the modules including extension points at which the build system may link the extension modules in order to incorporate customized tenant specific functionality. see further Fig. 2B, ¶45)wherein the first extension point is associated with a first extension point schema defining first extension point connectivity information; (See e.g. McVeigh ¶¶57-58, 68, 115 describing accessing components including extension modules via URL and version schema which provides for unique identification of components and their location in the system, where the filesystem includes code, data and metadata related to the extensions (see e.g. ¶48) which provides configuration information for configuring the customized components with the extension points, including, for example extension points corresponding to customization functions and input and output types of the extension points ) selecting the first extension point for hosting at least one of the plurality of building blocks; (McVeigh See ¶¶60-63, 65 describing using reference to select customization extension modules to be included at specific extension points , including using nocode and low code options to specify tenant-specific customizations to be included)
selecting a first building block for hosting by the first extension point; (McVeigh See ¶¶60-63, 65 describing using reference to select customization extension modules to be included in a build, including using nocode and low code options to specify tenant-specific customizations to be included)
and linking the first building block to the first extension point, (See McVeigh Links in Fig. 2B, ¶45 teaches linking the extension modules to the extension points of the core modules as depicted, and is linked in the build process as described in ¶¶74-75)
McVeigh Does not teach, but Srivastava teaches:
wherein linking includes using first building block connectivity information and the first extension point connectivity information to generate connectivity instructions defining how the first building block is to be linked with the first extension point, (Srivastava e.g. 216-227, Fig. 2, ¶¶47-49, 54-56 teaches a system which identifies enhancement points in the code, and cloud elements for implement extensions and generates code to integrate the extension at the enhancement point including resolving the compatibility between input/output parameters of the enhancements point and cloud element to ensure compatibility)
and implementing the connectivity instructions to …modify the functionality of the software platform. (Srivastava e.g. 216-227, Fig. 2, ¶¶47-49, 54-56 teaches a system which identifies enhancement points in the code, and cloud elements for implement extensions and generates code to integrate the extension at the enhancement point including resolving the compatibility between input/output parameters of the enhancements point and cloud element to ensure compatibility)
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 McVeigh and Srivastava as each is directed to extensible cloud platforms and Srivastava recognized the need for systems “which support an intelligent migration of on-premise applications having custom extensions/add-ons to a cloud platform.” (¶3).
McVeigh further does not teach, but Boodman teaches:
validating the connectivity instructions against the first building block schema and the first extension point schema to determine whether the connectivity instructions include sufficient information to implement hosting of the first building block by the first extension point; (See Boodman e.g. Col. 9, Ln 42-67, Col. 11, Ln 35-59 teach a schema validation which identifies information in the extension which break compatibility which can be identified and corrected)
determining, based on the validating, that the connectivity instructions lack at least one item of information required to implement the hosting; (See Boodman e.g. Col. 9, Ln 42-67, Col. 11, Ln 35-59 teach a schema validation which identifies information in the extension which break compatibility which can be identified and corrected)
obtaining the at least one item of information required to implement the hosting; (See Boodman e.g. Col. 9, Ln 42-67, Col. 11, Ln 35-59 teach a schema validation which identifies information in the extension which break compatibility which can be identified and corrected)
using the obtained at least one item of information to thereby link the first building block to the first extension point and modify (See Boodman e.g. Col. 9, Ln 42-67, Col. 11, Ln 35-59 teach a schema validation which identifies information in the extension which break compatibility which can be identified and corrected)
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 McVeigh and
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 McVeigh and Boodman as each is directed to extensible software systems and Boodman recognized a need in extensible systems to “provide an error message which identifies the particular error detected, and possibly a suggested correction or type of correction that may be applied to address the detected error.” (Col. 9, Ln 54-55).
Regarding Claim 2, McVeigh teaches: 2. (Original) The computer readable medium of claim 1, wherein the first extension point is anchored to a particular location in an architecture of the software platform. (McVeigh e.g. ¶¶53, 58, 68 teach a URL and unique identifier system for providing unique location and identification of components in the platform).
Regarding Claim 4, McVeigh teaches 4. (Original) The computer readable medium of claim 1, wherein the first extension point is exposed to a user interface configured to enable connection of the first building block to the first extension point. (McVeigh e.g. ¶¶63, 96, 164, Fig. 4A & 4B teaches use of a coupled UI for one-click interactions to connect elements in a service definition for building tenant specific services)
Regarding Claim 5, McVeigh teaches 5. (Original) The computer readable medium of claim 4, wherein the user interface includes a no-code environment for enabling receiving of the selection of the building block. (McVeigh See ¶¶60-63, 65 describing using reference to select customization extension modules to be included at specific extension points , including using nocode and low code options to specify tenant-specific customizations to be included)
Regarding Claim 7, McVeigh does not teach, but Srivastava teaches: 7. (Original) The computer readable medium of claim 1, wherein the connectivity instructions resolve the first building block connectivity information with the first extension point connectivity information. (Srivastava ¶¶48-49 teaches a system determining if suitable code for matching the enhancement point exists including matching import/export parameter sets between the enhancement point and app as depicted in Figs. 6 and 7, and described further in ¶¶50-53) 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 McVeigh and Srivastava as each is directed to extensible cloud platforms and Srivastava recognized the need for systems “which support an intelligent migration of on-premise applications having custom extensions/add-ons to a cloud platform.” (¶3).
Regarding Claim 8, McVeigh does not teach, but Srivastava teaches:8. (Original) The computer readable medium of claim 7, wherein resolving the first building block connectivity information with the first extension point connectivity information defines input-output types enabling communication between the first building block and the first extension point. (Srivastava ¶¶48-49 teaches a system determining if suitable code for matching the enhancement point exists including matching import/export parameter sets between the enhancement point and app as depicted in Figs. 6 and 7, and described further in ¶¶50-53) 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 McVeigh and Srivastava as each is directed to extensible cloud platforms and Srivastava recognized the need for systems “which support an intelligent migration of on-premise applications having custom extensions/add-ons to a cloud platform.” (¶3).
Regarding Claim 9, McVeigh does not teach, but Srivastava teaches:9. (Original) The computer readable medium of claim 8, wherein resolving the first building block connectivity information with the first extension point connectivity information defines an implementation of the capabilities of the first building block while hosted by the first extension point. (Srivastava ¶¶48-49 teaches a system determining if suitable code for matching the enhancement point exists including matching import/export parameter sets between the enhancement point and app as depicted in Figs. 6 and 7, and described further in ¶¶50-53; and further the implementation of the extension code is described in ¶¶55-56) 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 McVeigh and Srivastava as each is directed to extensible cloud platforms and Srivastava recognized the need for systems “which support an intelligent migration of on-premise applications having custom extensions/add-ons to a cloud platform.” (¶3).
Regarding Claim 10, McVeigh does not teach, but Srivastava teaches:10. (Original) The computer readable medium of claim 1, wherein differing iterations of the first building block hosted by the first extension point are associated with differing implementations of the capabilities and differing versions of the building block schema of the first building block. (Srivastava e.g. ¶¶48-53, Figs. 5A,5B,6 and 7 describe analyzing multiple extension codes from the whitelist and determining which of these to link to which explicit or implicit enhancement point) 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 McVeigh and Srivastava as each is directed to extensible cloud platforms and Srivastava recognized the need for systems “which support an intelligent migration of on-premise applications having custom extensions/add-ons to a cloud platform.” (¶3).
Regarding Claim 11, McVeigh does not teach, but Srivastava teaches:11. (Original) The computer readable medium of claim 1, further comprising, in response to determining a mismatch between the first extension point and the first building block, preventing the linking of the first building block with the first extension point. (Srivastava e.g. ¶¶48-53, Figs. 5A,5B,6 and 7 describe analyzing multiple extension codes from the whitelist and determining which of these to link to which explicit or implicit enhancement point, including specifically e.g. Fig. 7 depicting identifying a mismatch and preventing linking thereof) 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 McVeigh and Srivastava as each is directed to extensible cloud platforms and Srivastava recognized the need for systems “which support an intelligent migration of on-premise applications having custom extensions/add-ons to a cloud platform.” (¶3).
Regarding Claim 12, McVeigh does not teach, but Srivastava teaches:12. (Original) The computer readable medium of claim 1, wherein the first extension point includes a plurality of connection sites for linking the first building block thereto, the operations further comprising enabling selection of a particular connection site from the plurality of connection sites for linking the first building block to the first extension point. (Srivastava e.g. ¶¶48-53, Figs. 5A,5B,6 and 7 describe analyzing multiple extension codes from the whitelist and determining which of these to link to which explicit or implicit enhancement point, including specifically Figs. 5A and 5B depicting picking from the multiple enhancement points) 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 McVeigh and Srivastava as each is directed to extensible cloud platforms and Srivastava recognized the need for systems “which support an intelligent migration of on-premise applications having custom extensions/add-ons to a cloud platform.” (¶3).
Regarding Claim 13, McVeigh further teaches:
13. (Original) The computer readable medium of claim 1, wherein hosting of the first building block by the first extension point enables generating an additional product atop the software platform. (McVeigh ¶¶39-40 teaches the extension modules may provide additive software products in addition to the core functionality of the computing platform)
Regarding Claim 14, McVeigh does not teach, but Srivastava teaches:
14. (Original) The computer readable medium of claim 1, wherein the connectivity instructions are based on the first extension point schema. (Srivastava ¶¶47-48, 56-57 Fig. 2 teaches generating code for implementing the extension at the enhancement points, where the generated code conforms to the enhancement point scheme in Srivastava, including identifying both implicit and explicit enhancement points, mapping the extension elements to these points based on the type of point and import/export parameters as displayed in Figs. 5a, 5b, 6 and 7). 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 McVeigh and Srivastava as each is directed to extensible cloud platforms and Srivastava recognized the need for systems “which support an intelligent migration of on-premise applications having custom extensions/add-ons to a cloud platform.” (¶3).
Regarding Claim 15, McVeigh further teaches: 15. (Original) The computer readable medium of claim 1, wherein the first building block exposes a second extension point associated with a second extension point schema defining second extension point connectivity information and configured to host at least a second subset of the plurality of differing building blocks, the operations further comprising accessing the second extension point to enable alteration of the software platform via the second extension point. (McVeigh e.g. Fig. 2b, ¶¶45-46 describes extension modules, e.g. 260(3) with extension points therein for connecting to further extension points (e.g. 270(2)) to create multiple tiers of extension modules linked from extension modules)
Regarding Claim 16, McVeigh further teaches: 16. (Original) The computer readable medium of claim 15, wherein the operations further comprise enabling selection of a second building block from the second subset of the plurality of differing building blocks for hosting by the second extension point on the first building block. (McVeigh e.g. Fig. 2b, ¶¶45-46 describes extension modules, e.g. 260(3) with extension points therein for connecting to further extension points (e.g. 270(2)) to create multiple tiers of extension modules linked from extension modules)
Regarding Claim 17, McVeigh further teaches: 17. (Original) The computer readable medium of claim 16, wherein the second building block exposes a third extension point associated with a third extension point schema and is configured to host at least a third subset of the plurality of differing building blocks. (McVeigh e.g. Fig. 2b, ¶¶45-46 describes extension modules, e.g. 260(3) with extension points therein for connecting to further extension points (e.g. 270(2)) to create multiple tiers of extension modules linked from extension modules)
Regarding Claim 18, McVeigh further teaches:
18. (Original) The computer readable medium of claim 17, wherein removal of the third building block is required prior to removal of the second building block. (McVeigh e.g. Fig. 2b, ¶¶45-46 describes extension modules, e.g. 260(3) with extension points therein for connecting to further extension points (e.g. 270(2)) to create multiple tiers of extension modules linked from extension modules. Further Fig. 4D-4E, ¶¶59-61 teach the mult-layered resuable customization components, wherein customizations are specificed on top of customizations, including code to add, delete or replace in configuration amendments. Inherent here is that that higher tiered (e.g. 270(2)) fig 2b) customzination would necessarily need to be removed before a delete of a lower tiered one (e.g. 260(3), Fig. 2b) because the higher tiered customization component is linked to the platform only through the lower one in those cases)
Regarding Claim 19, McVeigh further teaches:
19. (Original) The computer readable medium of claim 17, wherein the second building block inherits features from at least one other building block of the plurality of differing building blocks. (McVeigh e.g. ¶¶58-59 describes one customization partition inheriting a resuable customization from another partition by virtue of the reference between the two)
Regarding Claim 20, McVeigh does not teach, but Srivastava teaches:
20. (Original) The computer readable medium of claim 16, further comprising verifying that second connectivity instructions defining how the second building block is to be linked with the second extension point are compatible with the first extension point schema and the building block schema associated with the first building block. (Srivastava ¶¶47-48, 56-57 Fig. 2 teaches generating code for implementing the extension at the enhancement points, where the generated code conforms to the enhancement point scheme in Srivastava, including identifying both implicit and explicit enhancement points, mapping the extension elements to these points based on the type of point and import/export parameters as displayed in Figs. 5a, 5b, 6 and 7). 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 McVeigh and Srivastava as each is directed to extensible cloud platforms and Srivastava recognized the need for systems “which support an intelligent migration of on-premise applications having custom extensions/add-ons to a cloud platform.” (¶3).
Claim(s) 3 is/are rejected under 35 U.S.C. 103 as being unpatentable over “McVeigh” (US PG Pub 2023/0409415) in view of “Srivastava” (US PG Pub 2022/0334829) and further in view of “Boodman” (US Patent 8,756,617) as applied above and further in view of “Procopio” (US PG Pub 2025/0068396)
Regarding Claim 3, McVeigh does not teach, but Procopio teaches 3. (Original) The computer readable medium of claim 1, wherein the first extension point is anchored to a particular location on a graphical user interface associated with the software platform. (Procopio 508, Fig. 5, ¶¶4,7, ¶27 teaches rendering an embedded application view at an anchored location in a host application for an extension of the host). 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 McVeigh and Procopio as each is directed to use of cloud based software programs including rendering add-on portions within a host application, and Procopio recognized the need for a system for “rendering, within the host container at an anchor location, an embedded application view based on the data record of the dataset.” (¶3).
Claim(s) 6 is/are rejected under 35 U.S.C. 103 as being unpatentable over “McVeigh” (US PG Pub 2023/0409415) in view of “Srivastava” (US PG Pub 2022/0334829) and further in view of “Boodman” (US Patent 8,756,617).as applied above and further in view of “Shedigumme” (US PG Pub 2020/0293185)
Regarding Claim 6, McVeigh does not teach, but Shedigumme teaches
6. (Original) The computer readable medium of claim 1, wherein the first extension point is unexposed to a user interface. (Shedigumme ¶22, 55 teaches hiding integrated third-party service content from a generated user interface such that the integrated service is not exposed to the user). 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 McVeigh and Shedigumme as each is directed to cloud based software with integration and rendering of additional components and Shedigumme recognized the need for third-party service intergration (see ¶1) while also recognizing the utilty of hiding certain integrated services from the UI at times as “the user interface element 203 can include a panel or other type of component that can be integrated into the original user interface 148 and can allow the user to view the panel contents while still having access to the content of the original user interface 148. In this example, the panel can include a visible portion of content and a hidden portion of content. When a user interacts with the panel by pulling the panel in a given direction, the hidden portion of the content received from the second third-party service 121 can be exposed.” (¶22).
Claim(s) 21 is/are rejected under 35 U.S.C. 103 as being unpatentable over “McVeigh” (US PG Pub 2023/0409415) in view of “Srivastava” (US PG Pub 2022/0334829) and further in view of “Boodman” (US Patent 8,756,617) as applied above and further in view of “Duggal” (US PG Pub 2025/0258657).
Regarding Claim 21, McVeigh does not further teach, but Duggal teaches:
21. (Original) The computer readable medium of claim 1, further comprising an AI agent configured to facilitate automated generation of a software product, the AI agent being operative to: receive a requirement specification defining a functionality to be achieved by a SaaS platform; (Duggal See Fig. 3, e.g. ¶¶157-158 receives a set of functionality features request for the target software from the user)
analyze the plurality of existing building blocks and their respective schemas to determine available capabilities within the software platform; (Duggal Fig. 5, e.g. ¶77 describes the system prompts the LLM to analyze the existing feature code blocks and provide summaries indicating their capabilities)
generate a manifest specifying the required building blocks and corresponding connectivity instructions based on the received requirement and a SaaS platform schema, wherein the manifest defines the required interconnections among the selected building blocks; (Duggal 220, Fig. 5, ¶140 teaches based on the blocks, summaries and requested features, the system generates an implementation plan
and automatically construct the software product by linking the selected building blocks in accordance with the generated manifest. (Duggal e.g. Figs 6-8, ¶¶141,157 teaches taking the implementation plan and using it to generate new code and use the existing code as needed to automatically create the target application).
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 McVeigh and Duggal as each is directed to software reuse and development and Duggal recognized “Conventional systems lack robustness in the provided tools that can reliably improve the design creation of a new customer application and improve the efficiency of the build such as by automatically relying on previously developed code, testing, or other advanced tools and features that solve deficiencies in the code generation process.”
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 prior art relevant to applicant’s disclosures related to software functionality extension systems.
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 Monday-Friday, 9am-4:30pm.
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
8/26/2026
/MATTHEW J BROPHY/Primary Examiner, Art Unit 2191
Prosecution Insights