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 .
Drawings
The drawings are objected to as failing to comply with 37 CFR 1.84(p)(5) because they do not include the following reference sign(s) mentioned in the description:
par. [0026] “visual representation 114b”, “equipment 112c”, “visual representation 114c”.
par. [0027]-[0028] “CDSL 214”;
par. [0046] “tangible storage devices (528)”.
Corrected drawing sheets in compliance with 37 CFR 1.121(d) are required in reply to the Office action to avoid abandonment of the application. Any amended replacement drawing sheet should include all of the figures appearing on the immediate prior version of the sheet, even if only one figure is being amended. Each drawing sheet submitted after the filing date of an application must be labeled in the top margin as either “Replacement Sheet” or “New Sheet” pursuant to 37 CFR 1.121(d). If the changes are not accepted by the examiner, the applicant will be notified and informed of any required corrective action in the next Office action. The objection to the drawings will not be held in abeyance.
The drawings are objected to as failing to comply with 37 CFR 1.84(p)(5) because they include the following reference character(s) not mentioned in the description:
Fig. 1, Visual Representation 2 118-B, Visual Representation 2 118-N; and
Fig. 5, Portable Tangible Storage Device(s) 526, Location Device 530.
Corrected drawing sheets in compliance with 37 CFR 1.121(d), or amendment to the specification to add the reference character(s) in the description in compliance with 37 CFR 1.121(b) are required in reply to the Office action to avoid abandonment of the application. Any amended replacement drawing sheet should include all of the figures appearing on the immediate prior version of the sheet, even if only one figure is being amended. Each drawing sheet submitted after the filing date of an application must be labeled in the top margin as either “Replacement Sheet” or “New Sheet” pursuant to 37 CFR 1.121(d). If the changes are not accepted by the examiner, the applicant will be notified and informed of any required corrective action in the next Office action. The objection to the drawings will not be held in abeyance.
Specification
The disclosure is objected to because of the following informalities:
Par. [0046] “R/W drive or interface (514) … tangible storage devices (528) … adapters or interfaces (512)” should read “R/W drive or interface (512) … tangible storage devices (526) … adapters or interfaces (514)”;
Par. [0047] “adapters or interfaces (512)” should read “adapters or interfaces (514)”.
Appropriate correction is required.
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-9 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter. The claim(s) does/do not fall within at least one of the four categories of patent eligible subject matter because they are directed to software per se. (i.e. a software system comprising a “DSL”, and programs for providing a “catalog” and/or “web interface”.
Claim 10-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Claim 10 recites:
defining a structure of the software architecture and one or more architectural components required for the software architecture using a customizable domain specific language (DSL); (a mental process, i.e. providing a description of an architecture)
collating one or more resources using the DSL into a catalogue to define the software architecture, wherein the one or more resources comprise the one or more architectural components, each of the architectural components being customizable based on the defined structure of the software architecture (a mental process, i.e. organization of data);
standardizing definitions of the architectural components across a plurality of users (organizing human activity, e.g. requiring or otherwise causing the users to adopt the DSL);
configuring one or more implementations of the architectural components (a mental process, i.e. editing of the cataloged data); and
facilitating creation of standardized visual representations of the software architecture (mental process, e.g. producing a diagram), wherein each visual representation comprises one or more resources of the catalogue arranged in accordance with the structure of the software architecture (organizing human activity, e.g. requiring or otherwise causing the users to adopt the visual representation).
The claim(s) recite(s) defining a software architecture(s) collating the definitions of the software architecture(s), configuring (e.g. editing, see applicant’s par. [0038]) the definitions and facilitating visual representation of the definition(s). These are all actions capable of performance in the human mind. Further the limitations directed to “standardizing” organizing human activity (i.e. getting people to adopt your standard(s)). Accordingly, the claim recites an abstract mental concept(s).
This judicial exception is not integrated into a practical application and does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception because the only arguable additional element, i.e. the “visual representation” (presumably displayed on a display) amounts to no more than extra solution activity (see e.g. MPEP 2105.05(g)).
Claims 11-14 depend on claim 10, only recite further details of the abstract idea (e.g. collecting, organizing and displaying data) of claim 10, and similarly do not recite additional elements. Accordingly, the claims are directed to an abstract idea without significantly more.
Claim 15 is similarly directed to the abstract idea of claim 10, but also recites the additional elements of:
... a memory storing one or more processor-executable routines; and
a processor communicatively coupled to the memory, the processor configured to execute the one or more processor-executable routines; …
This judicial exception is not integrated into a practical application because the additional elements are only recited at a high level of generality describing only generic computing functionality and thus amount to no more than instructions to implement the abstract idea using a computer.
This judicial exception is not integrated into a practical application because the additional elements are only recited at a high level of generality describing only generic computing functionality and thus amount to no more than instructions to implement the abstract idea using a computer.
Claims 16-20 depend on claim 15, recite further details of the abstract idea and introduce additional elements comprising storing/sharing the designs on a repository.
This judicial exception is not integrated into a practical application because the additional elements are only recited at a high level of generality describing only generic computing functionality and thus amount to no more than instructions to implement the abstract idea using a computer.
This judicial exception is not integrated into a practical application because the additional elements are only recited at a high level of generality describing only generic computing functionality and thus amount to no more than instructions to implement the abstract idea using a computer.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 3-4, 12 and 20 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 3 recites the limitation " implementations for the each architectural component" in lines 3-4. There is insufficient antecedent basis for this limitation in the claim. Examiner believes this is intended to reference the “one or more architectural components” recited in line 2 of the claim and apparently referencing a set of the “architectural components” recited in claim 2. This is the understanding used in this examination.
Claim 4 is rejected based on its dependency on claim 3.
Claim 12 recites language similar to that of claim 3 and is thus similarly rejected.
Claim 12 further recites “a switch between a plurality of implementations of the software architecture”. It is not clear if this is intended to refer to the previously recited “plurality of implementations” or a different set. For the purposes of this examination the former understanding will be used.
Claim 20 recites language similar to that of claim 3 and is thus similarly rejected.
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claim(s) 1-3, 6-10, 12-13, 15-20 is/are rejected under 35 U.S.C. 102(a)(2) as being anticipated by US 2024/0303044 to Rammurthy et al. (Rammurthy)
Claims 1: Rammurthy discloses a system for standardizing the definition of a software architecture, wherein the system comprises:
a customizable domain specific language (DSL) configured to define a structure and one or more architectural components of the software architecture (par. [0048] “create a base Domain Specific Language (base-DSL) … enrich the base-DSL”);
a catalogue having one or more resources that are customizable based on the defined structure of the software architecture (par. [0087] “a set of base-DSL components are loaded … from a repository 814”); and
a web interface communicatively coupled to an interpreter (par. [0087] “the visualizer 802”, par. [0076] “standard web browsers”) and configured to:
translate the domain specific language (DSL) to a visual representation (par. [0087] “a set of base-DSL components are loaded on the visualizer 802”); and
enable creation of standardized visual representations of the software architecture, wherein each visual representation comprises one or more resources of the catalogue arranged in accordance with the structure of the software architecture par. [0010] “creating … a visual representation … based on … the set of application-specific DSL components”, also see e.g. Fig. 9).
Claim 2: Rammurthy discloses the system of claim 1, wherein the one or more resources comprise of architectural components, services, databases, caches, or combinations thereof (par. [0086] “the base-DSL components may include web server(s), repository (or Repositories), etc.”).
Claim 3: Rammurthy discloses the system of claim 2, wherein the customizable DSL is further configured to:
receive inputs from a user to define the one or more architectural components (par. [0088] “receiving … a first user input”); and
specify one implementation from a plurality of available implementations for the each architectural component (par. [0088] “receiving … a first user input … create an application-specific component”).
Claim 6: Rammurthy discloses the system of claim 1, wherein the web interface is configured to share the one or more architectural designs of the structure across a plurality of users (e.g. Fig. 2, Client Devices 208(1)-208(n)).
Claim 7: Rammurthy discloses the system of claim 6, wherein the web interface is further configured to facilitate standardization of definitions of each architectural component for use across the plurality of users (e.g. par. [0089] “specific to one application or one product or … product line”).
Claim 8: Rammurthy discloses the system of claim 6, wherein the web interface is configured to share the one or more architectural designs to a reference architecture repository accessible to the plurality of users (par. [0090] “stored in the repository 814 and could be re-used”).
Claim 9: Rammurthy discloses the system of claim 8, wherein the web interface is further configured to:
enable users to inherit architectural designs from the reference architecture repository (par. [0090] “stored in the repository 814 and could be re-used”);
mutate the inherited architectural designs based upon a selected implementation to create one or more mutated architectural designs (par. [0089] “created based on the relevant application-specific DSL and a second user input”, alternately or additionally see Fig. 6, S506-S508”); and
share the one or more mutated architectural designs to the reference architecture repository for use by the plurality of users (par. [0090] “stored in the repository 814”).
Claim 10: Rammurthy discloses a method for standardizing the definition of a software architecture, the method comprising:
defining a structure of the software architecture and one or more architectural components required for the software architecture using a customizable domain specific language (DSL) (par. [0048] “create a base Domain Specific Language (base-DSL) … enrich the base-DSL”);
collating one or more resources using the DSL into a catalogue to define the software architecture, wherein the one or more resources comprise the one or more architectural components, each of the architectural components being customizable based on the defined structure of the software architecture (par. [0090] “stored in the repository 814 and could be re-used”);
standardizing definitions of the architectural components across a plurality of users (e.g. par. [0089] “specific to one application or one product or … product line”, Fig. 2, Client Devices 208(1)-208(n));
configuring one or more implementations of the architectural components (par. [0088] “receiving … a first user input … create an application-specific component”); and
facilitating creation of standardized visual representations of the software architecture, wherein each visual representation comprises one or more resources of the catalogue arranged in accordance with the structure of the software architecture (par. [0010] “creating … a visual representation … based on … the set of application-specific DSL components”, also see e.g. Fig. 9).
Claim 12: Rammurthy discloses the method of claim 10, further comprising:
modifying, using the customizable DSL, one or more resources of the catalogue based upon a requirement of the architecture (par. [0093] “based on the relevant application-specific DSL and a second user input””);
specifying a plurality of implementations of the each architectural component based on the requirement (par. [0088] “receiving … a first user input … create an application-specific component”); and
facilitating a switch between a plurality of implementations of the software architecture, wherein each implementation is based on the requirement of the architecture, and wherein the one or more resources are adapted to the corresponding implementation (par. [0092] “various application-specific DSL entries or names … may be shown in a drop-down list”).
Claim 13: Rammurthy discloses the method of claim 10, further comprising:
facilitating sharing one or more architectural designs of the structure across a plurality of users (e.g. par. [0090] “stored in the repository 814 and could be re-used”, Fig. 2, Client Devices 208(1)-208(n)); and
standardizing definitions of each architectural component for use across the plurality of users (par. [0089] “specific to one application or one product or … product line”).
Claim 15: Rammurthy discloses a system for standardizing the definition of a software architecture, the system comprising:
a memory storing one or more processor-executable routines (e.g. Fig. 1, Memory 106); and
a processor communicatively coupled to the memory (e.g. Fig. 1, Processor(s) 104), the processor configured to execute the one or more processor-executable routines to:
define a structure and one or more architectural components of the software architecture using a customizable domain specific language (DSL) (par. [0048] “create a base Domain Specific Language (base-DSL) … enrich the base-DSL”);
collate one or more resources using the DSL into a catalogue to define the software architecture, wherein the one or more resources are customizable based on the defined structure of the software architecture (par. [0090] “stored in the repository 814 and could be re-used”); and
translate the domain specific language (DSL) to a visual representation to create standardized visual representations of the software architecture, wherein each visual representation comprises one or more resources of the catalogue arranged in accordance with the structure of the software architecture (par. [0010] “creating … a visual representation … based on … the set of application-specific DSL components”, also see e.g. Fig. 9).
Claim 16: Rammurthy discloses the system of claim 15, wherein the system comprises a web interface and an interpreter configured to generate the standardized visual representations of the software architecture (par. [0087] “the visualizer 802”, par. [0076] “standard web browsers”).
Claim 17: Rammurthy discloses the system of claim 15, wherein the web interface is configured to share one or more architectural designs of the structure across a plurality of users and store the designs on a reference architecture repository (Fig. 2, Client Devices 208(1)-208(n)).
Claim 18: Rammurthy discloses the system of claim 17, wherein the web interface is further configured to:
enable users to inherit architectural designs from the reference architecture repository (par. [0090] “stored in the repository 814 and could be re-used”);
mutate the inherited architectural designs based upon a selected implementation to create one or more mutated architectural designs (par. [0093] “based on the relevant application-specific DSL and a second user input””); and
share the one or more mutated architectural designs to the reference architecture repository for use by the plurality of users (par. [0090] “stored in the repository 814 and could be re-used”).
Claim 19: Rammurthy discloses the system of claim 15, wherein the one or more resources comprise architectural components, services, databases, caches, or combinations thereof (par. [0086] “the base-DSL components may include web server(s), repository (or Repositories), etc.).
Claim 20: Rammurthy discloses the system of claim 15, wherein the processor is further configured to:
receive inputs from the users to define the one or more architectural components (par. [0093] “based on the relevant application-specific DSL and a second user input””); and
specify one implementation from a plurality of available implementations for the each architectural component using the DSL (par. [0092] “various application-specific DSL entries or names … may be shown in a drop-down list … from which the product architect may select”).
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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) 4-5, 11 and 14 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 2024/0303044 to Rammurthy et al. (Rammurthy) in view of US 2018/0276060 to Arumugam (Arumugam).
Claim 4: Rammurthy discloses the system of claim 3, but does not explicitly disclose wherein the customizable DSL is further configured to reference one or more resource attributes of the each architectural component.
Arumugam teaches a DSL configured to reference one or more resource attributes of an architectural component (e.g. par. [0036] “defines the parameters and/or attributes”, par. [0038] “DSL syntax for the actions … attribute structure for actions”).
It would have been obvious before the effective filing date of the claimed invention to reference one or more resource attributes of the architectural component(s). Those of ordinary skill in the art would have been motivated to do so as a known means of describing a software system which would have produced only the expected results.
Claim 5: Rammurthy discloses the system of claim 1, but does not explicitly disclose wherein the catalogue is neutral of a type and configuration of a cloud on which the catalogue and the software architecture is hosted.
Arumugam teaches a catalog that is neutral of a type and configuration of a cloud on which the catalog and the software architecture is hosted (par. [0035] “DSL library 102 can include platform native DSL1 402, platform native DSL2 404, third party DS 404 [sic] and/or standard DSL 406 [sic]”).
It would have been obvious before the effective filing date of the claimed invention to implement a cloud neutral catalog. Those of ordinary skill in the art would have been motivated to do so to “orchestrate multiple Cloud platforms and services” (par. [0027]).
Claim 11: Rammurthy discloses the method of claim 10, further comprising abstracting a plurality of components of the software architecture (par. [0022] converting the set of model objects into a Diagram as Code (“DaC”)”).
Rammurthy does not explicitly disclose a cloud-neutral catalog.
Arumugam teaches a cloud-neutral catalog (par. [0035] “DSL library 102 can include platform native DSL1 402, platform native DSL2 404, third party DS 404 [sic] and/or standard DSL 406 [sic]”).
It would have been obvious before the effective filing date of the claimed invention to implement a cloud neutral catalog. Those of ordinary skill in the art would have been motivated to do so to “orchestrate multiple Cloud platforms and services” (par. [0027]).
Claim 14: Rammurthy discloses the method of claim 10, further comprising referencing one or more resource attributes of the each architectural component using the customizable DSL.
Arumugam teaches referencing one or more resource attributes of an architectural component using a DSL (e.g. par. [0036] “defines the parameters and/or attributes”, par. [0038] “DSL syntax for the actions … attribute structure for actions”).
It would have been obvious before the effective filing date of the claimed invention to reference one or more resource attributes of the architectural component(s). Those of ordinary skill in the art would have been motivated to do so as a known means of describing a software system which would have produced only the expected results.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JASON D MITCHELL whose telephone number is (571)272-3728. The examiner can normally be reached Monday through Thursday 7:00am - 4:30pm and alternate Fridays 7:00am 3: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, Lewis Bullock can be reached at (571)272-3759. 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.
/JASON D MITCHELL/Primary Examiner, Art Unit 2199
Prosecution Insights