DETAILED ACTION
This action is responsive to the Applicant’s response filed 7/09/26.
As indicated in Applicant’s response, claims 1, 16, 21 have been amended, and claims 2-3 cancelled. Claims 1, 4-23 are pending in the following office action.
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.
Claim 21 rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more. Claim(s) 21 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 following 2-step analysis.
Step I;
This claim is directed to a process/method category.
Step 2A
Prong One:
The Elements recited as: "generating… user data” (indicative of a HW microservice requested by a user, the data comprising a programming language used by the IDE) and "receiving” ( mapped data indicative of a determined HW microservice) are easily construed as activities that can be performed within a human mind or via use of pen/paper; as these actions such as data generating essentially amount to the collecting, identifying, and translating information. Courts and MPEP
2106.04(a) have held that collecting data, analyzing it, and providing a result is/are part of a mental
process that can be performed in the human mind or with pen and paper, while the "HW
microservice" and “integrated development environment” associated with the “generating” and “receiving” is merely a field of intended use or a specific type of data, whereas the feature describing
data as “comprising programming language" is merely a data format limitation that does not change the abstract nature of the information processing
Prong Two:
The element defining a “HW microservice” as "software abstraction of … physical hardware component … exposes the functionality of the … component … via an application programming interface" merely describes abstracted representation of a HW functionality or component via use of a interface and this cannot be viewed as a transformation to the field of computer technology mostly when IDE is a well-understood concept, when “abstraction of a hardware” cannot add to the Abstract Idea (from prong One) any particular limitations that render it reproducible in real-world and concrete machine format. In other words, the claim merely says “applying” the abstract idea in a IDE context to develop an abstraction of a hardware. MPEP 2106.05(f) (h)
The element recited as "integrated development environment is a software application … assist developers … comprising code editing and tools … to improve productivity and libraries for … environment that is … programming dependent” merely depicts well-understood field of use – MPEP 2106.05(d) - by which to develop programming and fail to convey how this field of use particularly improves a technical aspect of a computer or more significantly transforms this development field. MPEP 2106.05(h)
The elements recited as “transmitting mapped data” , the “mapped data” generated by emulating the determined microservice … using programming language” are post-activities or extra-solution activities that definitely result from the Abstract Idea by which the HW microservice is being “determined”; hence these extra-solution features cannot be viewed as particularly providing a technical solution to the abstracted microservice determination from above. MPEP 2106.05(g) - Moreover, the act of "emulating" data in a language for use in an IDE is often viewed as a "well-understood, routine, and conventional" activity or tool of a programmer, which is not an improvement to the functioning of the computer itself (MPEP 2106.05(a)).
In all, the features from above cannot integrate the Abstract Idea into a practical application
Step 2B
The additional elements comprise "IDE", “abstraction of a functionality”, “application programming interface”, “code editing environment”, “libraries”, and "transmitting/receiving”, “emulating microservice into programming language”, “for use within a IDE”, all expressed without specific, non-conventional technical details, thus are observed either as well-understood routine or concepts or field of use - MPEP 2106.05(h) – or mere known tools (IDE, editor, emulating) – MPEP 2106.05 (d) - or extra-solution activities (receiving or transmitting) – MPEP 2106.05(g). These elements fail to provide a non-conventional improvement to the Judicial Exception, and cannot add significantly more to the Abstract idea of prong One
The ordered combination of these elements and steps merely describes the standard flow of a client or server communication or request/responses within a development environment; thus fail to convey a transformation that bring forth novelty to the computer fields or environment in which the abstracted activities of “receiving” data and “determining” operate; therefore, these elements cannot add significantly more to the Abstract idea as set forth above.
Accordingly, claim 21 is deemed ineligible under 35 U.S.C. § 101 statute
Claims 1 and 16 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more. Claim(s) 1 and 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 following 2-step analysis
A. Eligibility of claim 1
Step I
This claim is a apparatus/machine category.
Step 2A
Prong One:
Elements recited as: "receive … user data” (indicative of a HW microservice requested by a user, the data comprising a programming language used by the IDE), receive (microservice data, from a catalog) “determine” ( a HW microservice) are easily construed as activities that can be performed within a human mind or via use of pen/paper – MPEP 2106.04(a)
Prong Two:
The element defining a “HW microservice” as "software abstraction of … physical hardware component … exposes the functionality of the … component … via an application programming interface" merely describes abstracted representation of a HW functionality or component via use of a interface and this cannot be viewed as a concrete transformation to the field of computer technology mostly when IDE is a well-understood concept, when “abstraction of a hardware” cannot add to the Abstract Idea (from prong One) particular limitation that render it reproducible in real-world and concrete machine format. In other words, the claim merely says “applying” the abstract idea in a IDE context to develop an abstraction of a hardware. MPEP 2106.05(f) (h)
The element recited as "integrated development environment is a software application … assist developers … comprising code editing and tools … to improve productivity and libraries for … environment that is … programming dependent” merely depicts well-understood field of use – MPEP 2106.05(d) - by which to develop programming and fail to convey how this field of use particularly improves a technical aspect of a computer or more significantly transforms this development field. MPEP 2106.05(h)
The elements recited as “transmit mapped data” , the “mapped data” generated by “emulating the determined microservice … using programming language” are post-activities or extra-solution activities that definitely result from the Abstract Idea by which the HW microservice is being “determined”; hence these extra-solution features cannot be viewed as particularly providing a technical solution to the abstracted microservice determination from above. MPEP 2106.05(g) - Moreover, the act of "emulating" data in a language “for use in an IDE” is often viewed as a "well-understood, routine, and conventional" activity or tool of a programmer, which is not an improvement to the functioning of the computer itself (MPEP 2106.05(a)(d)(h).
The elements recited as “lookup”, “catalog”, “libraries”, “emulating” expressed in a very high level of generality are viewed as well-understood routines, technique or tools thus cannot represent limitations that particularly improve or transform the Abstract idea more than itself; nor can they integrate the abstract Idea into a practical application.
Step 2B
The additional elements comprise "IDE", “abstraction of a functionality”, “application programming interface”, “code editing environment”, “libraries”, “look-up language” and "transmitting/receiving”, “emulating microservice into programming language”, “for use within a IDE”, all expressed without specific, non-conventional technical details, thus are observed either as well-understood routine or concepts or field of use - MPEP 2106.05(h) – or mere known tools (IDE, editor, emulating) – MPEP 2106.05 (d) - or extra-solution activities (receiving or transmitting) – MPEP 2106.05(g). These elements fail to provide a non-conventional improvement to the Judicial Exception, and cannot add significantly more to the Abstract idea of prong One
Claim 1 is not eligible under 35 USC § 101 statute.
B. Eligibility of claim 16.
Step I: this claim is directed to a method category.
Step 2A
Prong One:
This claim recites the same steps of “receiving”, “determining” of claim 1; and is viewed as directed to an Abstract Idea of a mental process genre bearing activities that a human mind can perform. MPEP 2106.04(a)
Prong Two:
This claim recites the same “HW microservice” as "software abstraction of … physical hardware component … exposes the functionality of the … component … via an application programming interface", "integrated development environment is a software application … assist developers … comprising code editing and tools … to improve productivity and libraries for … environment that is … programming dependent”, “transmit mapped data” , the “mapped data” generated by “emulating the determined microservice … using programming language” as in claim 1, whereas the elements recited as “lookup”, “catalog”, “libraries”, “emulating” (expressed in very general terms) are construed as mere well-understood routines or tools. As such, the elements fail to integrate the abstract Idea into a practical application.
Step 2B
As mentioned in the analysis of claim 1, the additional elements of claim 16 comprise "IDE", “abstraction of a functionality”, “application programming interface”, “code editing environment”, “libraries”, “look-up language” and "transmitting/receiving”, “emulating microservice into programming language”, “for use within a IDE”, all expressed without specific, non-conventional technical details, thus are observed either as well-understood routine or concepts or field of use - MPEP 2106.05(h) – or mere known tools (IDE, editor, emulating) – MPEP 2106.05 (d) - or extra-solution activities (receiving or transmitting) – MPEP 2106.05(g). These elements fail to provide a non-conventional improvement to the Judicial Exception, and cannot add significantly more to the Abstract idea of prong One
Claim 16, similar to claim 1, is deemed non-eligible under USC 35 § 101 statute.
Step 2B analysis of dependent claims.
Claim 4 recites mapped data being an environment language but this characterization does
not constitute a clear technical novelty to the implementation of the mental process of the base
claim.
Claims 5 and 6 recite nature of a connection established between source database and
interface apparatus and the circuitry of the base claim; but this interfacing limitation does not add
significantly more to the mental process of the base claim.
Claim 7 recites microservices rendering by the processing circuity in response to request
thereof, and a service to respond to requests is considered a well-known practice that cannot
transform the Abstract Idea to make it significantly more than itself.
Claim 8 recites obtaining a statistic and transmitting data indicative of a offered service; but
these are construed as insignificant extra-solution activities that fail to add significantly more to the
Abstract Idea of claim 1.
Claim 9 recites a client or server nature of a interface apparatus hence cannot impose a
specific and inventive limitation to the abstract Idea of the base claim.
Claim 10 recites circuitry to receive data from a database, but this well-understood data
acquiring fails to augment the Abstract Idea significantly more than itself.
Claim 11 recites transmit and receive user data or mapped data, which can be viewed as
extra-solution insignificant activities that surround exercise of an Abstract Idea, hence fail to make
the Abstract Idea to become significantly more than a mental process.
Claims 12 and 13 recite effect of checking user data and categorizing microservice; but
assessing data and categorizing data can be viewed as activities that can be performed by a human
mind or via pen/paper.
Claim 14 recites circuitry to establish a user interface to receive data, but this field of use
cannot add significantly more to the context in which mental process is being performed.
Claim 15 recites an intent for the user data for which the intent is being processed; and this
cannot be same as detailing how the abstract idea is carried out to improve upon a computer
technology; hence, the intent processing cannot add more to the Abstract idea of claim 1.
Claim 17 recites establishing a tunnel between an IDE or a database; but this interfacing
limitation does not add significantly more to the mental process of base claim 16.
Claim 18 recites providing HW microservices and arranging recipe for rendering actions in
the IDE but arranging recipe as part of providing a microservices can be viewed as extra-solution
activity that is not related to converting the Abstract Idea into a computer-based technical
improvement; hence cannot add significantly more to the Abstract idea of claim 16.
Claim 19 recites providing a catalog in association with the requested microservice; but the
mere provision of a catalog (recited in a generic manner) has not impact on transforming the
Abstract Idea toward a significant improvement of the computer field in which the microservice is to
be rendered.
Claim 20 recites generating a universal format for the determined service, and this high level
of generality cannot render the Abstract Idea of claim 16 significantly more than itself.
Claims 22 -23 recites use of a computer-readable medium for implementing claim 16 or 21,
and this well-known medium cannot add significantly more to the Abstract Idea deficiency of claim
16 or 21.
In all, claims 1, 4-23 are deemed non-eligible under USC 35 § 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, 4, 7-14, 16, 18-20, 22 is/are rejected under § 35 U.S.C. 103 as being unpatentable over Halty et al, USPubN: 2021/0065123 (herein Halty) in view of Hilgers et al, USPubN: 2008/0244399(herein Hilgers), and Andre et al, USPN: 12,217,029 (herein Andre), further in view of Bhatia et al, USPubN: 2021/0288891 (herein Bhatia) and Rajagopalan et al, USPubN: 2019/0243748 (herein Rajagopalan)
As per claim 1, Halty discloses an apparatus, the apparatus comprising interface circuitry, machine-readable instructions and processing circuitry to execute the machine-readable
instructions to:
receive, from an interface apparatus (platform 110 - para 0126; platform 110- para 0065;
clean technology platform - para 0011-0013; platform 110 - para 0043) comprising an integrated development environment (call center, third party service, CRM tools, marketing hub, service hub, Hub Spot, API that integrates with the CRM platform 110 include own module or software stack to
provide lead submission service 230 - para 0058), user data (leads, design, finance options,
pricing options, document collection, scheduling, fulfilling installation or tracking installation - para
0066; signals status changes with respect to microservices by qualified freelancers - para 0014; Fig.
6A, 6B; lead 124 – Fig. 4B) indicative of a hardware microservice (microservices selected by and carried out by the users with respect to lead generation, lead conversion and fulfillment - para 0066) requested by a user (see users and freelancers in Note1),
wherein the user data (see Note1 from below) comprises a first programming language (e.g. Software as a service, APIaaS, TEaaS, IPaaS – para 0126; para 0123) used by the integrated development environment (para 0126; para 0011-0013 - Note1: clean technology including service associated with energy, waste affecting environment and protection, recycling activities - para 0037; solar panel installation - para 0075, Fig. 6A, 6B – provided with inter-operation of various services – Software as a Service, APIaaS, TEaaS, IPaaS – see para 0126; platform 110 manages microservices … software-as-a-service, para 0045 - and networked support thereby – para 0126 - using APIs – para 0055 - and project design tool – para 0013- to perform design and approval thereof, to integrate connect multiple source and multiple parties – para 0004 – to schedule lead deployment and analyze representation of each community activity – para 0015 - reads on platform of a integrated development environment with software programming interface – SaaS, para 0126, and design tool, APIs - para 0013, 0055 - to service user data or freelancers via fulfillment UI – para 0072 - in collecting information from users related to services provided by hardware, solar, energy-related utilities, equipment and, recycling, waste transportation, all representing hardware-based microservices used by or rendered for consumers or end-users; e.g. solar energy install - Fig. 4A - for use and configure via APIs within the integrated development environment), and wherein the hardware microservice is a software abstraction (data representative of the microservices - para 0010) of a functionality of a physical hardware component that exposes the functionality (refer to APIs) of the physical hardware component to the integrated development environment via an application programming interface (para 0011; para 0055; APIs – claim 2, pg. 10),
receive, from a database (clean technology platform and database stores data representative
of microservices managed by the clean technology platform - para 0010; stores data relating to
microservices managed by the clean technology platform - para 0045) microservice data indicative of a plurality of hardware microservices (through user-interfaces of respective computing devices coupled to the clean technology platform to view one or more of the microservices relating to lead generation, lead conversion or fulfillment of clean technology installations - para 0010; para 0074),
determine a hardware microservice (e.g. identify candidates and generate leads to deploy
clean technology products like install solar panels - para 0075; para 0046; identify candidates for
solar panel 412 - Fig. 4A; para 0047, 0053; filters 312 and matching engine 314 - para 0064 -
Note2: determining candidate clean technology product such as to fulfill or match - filter 412, match
414 - Fig. 4A - user request for solar install microservice reads on determining a candidate
hardware microservice on basis of criteria, filters per some database collected information per effect
of matching the user request for a solar install - para 0017; microservices relating to lead conversion
microservices pertaining to solar installation - para 0050) based on the plurality of hardware
microservices (see data aggregated in database from above) and the requested hardware
microservice (see Fig. 6A, 6B; see matching criteria in lead generation for fulfillment - para 0025-
0027; para 0050) of the user; and
transmit, to the interface apparatus, mapped data indicative of the determined hardware microservice, wherein the mapped data (para 0047; para 0096-0097; para 0121 - Note3: visual data presented so to enable the user to interactively specify location at which a solar install -
equipment based microservice - is to be performed reads on circuitry transmitting to the user
interface mapped data – match remote users with available microservices - para 0047 - resulting from the IDE effect to map installation of a determined HW microservice)) is generated in a language that can be processed for use within the integrated development environment
A) Halty does not explicitly disclose receiving via a IDE interface user data indicative of a HW microservice in terms of
wherein the integrated development environment is a software application aimed
to assist software developers in writing software codes, comprising a code editing environment
and tools to improve coding productivity and libraries for a coding environment that is
programming language dependent.
Halty discloses integrated networked collaboration of networked services such as SaaS (para 0045), APIaaS, TEaaS, IPaaS (see para 0126) provided with open source community and database (para 0127) and design tool (para 0013), the community of users/freelancers interacting via UI to configure microservice lead (para 0010; Fig. 4A; para 0018) to arrange and schedule delivery of a HW microservice via team or design provided or proposed via API (para 0059); where the end-to-end process to convert lead into aggregation of information of disparate sources include quality control and editing to maintain quality of the accessed and parsed source data prior to committing them to DB (para 0074); hence provision of an integrated development environment equipped with user interfaces and API allowing users or freelancers to develop software via design tools under support of software, integrated programming, test and API provided from respective SaaS, IPaaS, TEaaS, and APIaaS entails integrated development environment is a software application aimed
to assist software developers or users in configuring software or test written in a programming language.
Andre discloses integrated development environment equipping the developers with APIs, software library (col. 1 li. 41-48) and framework having visual code editing (col. 5 li. 4-32) to elect source code instance and filtering thereof to implement a functionality to be configured from a pool of candidate source codes (col. 4 li. 44-67), including provision of programming language or interface source code (col. 12 li. 12-21) via the IDE’s APIs per use of programming code library (col. 6 li. 57-67) as candidate instance that logically matches a designated domain relevant to user’s implementation, using a request API (col. 10 li. 27-34); hence IDE to assist software developers in writing software codes, comprising a code editing environment and tools to improve coding productivity and libraries for a coding environment is recognized.
Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the invention to implement the integrated developer and freelancer programming environment in Halty so that platform of user-based microservice configuration, scheduling or programming is provided as integrated development environment implemented in software-based application aimed so as to assist software users/developers in writing software codes as in Andre IDE including a code editing environment, tools to improve coding productivity and libraries for a coding environment that is programming language dependent – as set forth in Andre; because
Integrating UI tools to support developers via database and library of code mitigate effort of by the development process to generate code from scratch, thereby enhancing code productivity and source code generation throughput, and use of code editor associated with domain-specific code source repository or library would facilitate the developers with ease in seeking the best source code snippets or library that matches a domain-specific design or a service functionality intended by the developers, and UI environment tool provided in form of code editor would assist in real-time the user process of generating code or writing programming language with a measure of code quality check and/or style defect filtering whereby improper code style or erroneous constructs can be tracked and expunged from a particular source programming endeavor.
B) Nor does Halty explicitly disclose interface apparatus with circuitry for
(i) receiving, from a database comprising a hardware microservice catalog of a plurality of hardware microservices each corresponding to a respective physical hardware component;
(ii) wherein the microservice data comprises a second, different look-up language to look-up
hardware microservices
(iii) wherein the mapped data is generated by an egress filter by emulating the determined hardware microservice into the first programming language that can be processed for use within
the integrated development environment
As for (i)
Retrieving microservice data indicative of a HW microservice from a repository such as a database is shown in Halty (database stores data representative of microservices managed by the clean technology platform - para 0010; stores data relating to microservices managed by the clean technology platform - para 0045), whereas use of equivalent store such as a catalog to store/bind instances of microservice (para 0052) previously customized by tenants is shown in Bhatia (Fig. 10).
As for (ii)
An interactive environment to support contextual data provided via an application interface in relation to customer service or project management applications is shown in Hilgers (para 0030-
0031) with implementation of UI, a detection module, a database coupled with a look-up module
(para 0032; Fig. 3), the UI comprising section for the user to specify contextual information whose
contents are processed by a detection module in conjunction with the look up module for use by a
server to locate contextual data from the database server (para 0039-0044; Fig. 8), including data on
object, a person, task of the person, role and position in a business, the object being detected including customer information section/clipboard indicative of activities, transaction statues and
service progress (para 0061-0062; Fig. 9-10); hence use of a service look-up associated with database from which to return user contextual information, user relevant activities, ongoing service statuses is recognized.
As for (iii)
Rajagopalan discloses interpreting communication and messages passing through microservices and emulating them into application-level testing (para 0023) provided as stage of emulated communications to test or inject fault, the manifest form from the microservice API calls, or responses investigated to establish failure, cascade thereof or failure modes (para 0025) based on which to implement proper recovery measures.
Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the invention to implement microservice integrated development environment in Halty so that
1) a catalog repository is provided with the IDE – as in Bhatia - so to enable retrieve microservice data from a hardware microservice catalog of a plurality of hardware microservices, each corresponding to a respective physical hardware component;
2) the microservice data comprises a second, different look-up language to look-up
hardware microservices – as in Hilgers;
3) so that egress for the mapped data into the IDE is implemented via stages of emulating the determined hardware microservice into the first programming language that can be processed - in test code per Rajagopalan - for use within the integrated development environment; because
specifications supplied from the user with intent to acquire microservice data via UI of a
microservice framework or development environment can be in various raw form like textual
description or structured information from a file written in a particular language, a schema or ADL
file containing specification detailing requisites for a microservice being requested of the framework, and a particular expression of this user data format when submitted into an IDE and programming tools thereof for exploring ways to configure and deploy the microservice, would necessitate developer effect of generating written source code or special programming language destined as executable that is carried out by tools of the IDE to render microservice behavior expected to meet the intent of the developers, including mimicking effect of emulating the microservice via the integrated development environment into application code or analytic routines (test as in Rajagopalan) to understand, extract, derive anomalies based on which to issue countermeasures or recovery should the emulated data returned failures or defect in the deployed behavior of the microservice;
implementation of proper environment integrated like the IDE per its intrinsic compiler
capability or services as set forth above, would effortlessly facilitate or expedite translation of
language received in one language into another language that would be more understandable or
compliant with a given stage of a development process initiated by the user so as to further assist the user in seeking microservice data - as shown in Halty framework, e.g. the integrated assistance
including converting raw text of a user seeking a lookup functionality into structured query format
that enables querying of a remote a database to extract via lookup utility included with the original language supplied by the user; notably when remote storage service is used to support users collection of microservice specification via support of a look-up utility associated with query applications directed to a remote repository configured for cataloguing previously customized microservices - as set forth in Bhatia – as this particular lookup software would expedite the users query to identify and retrieve the most relevant features befitting the extent of customizing a microservice as desired by the user.
As per claim 4, Halty discloses apparatus according to claim 1, wherein the mapped data comprises an integrated development environment language (refer to claim 1; para 0126) of the
interface apparatus or a universal language (see geographical map - para 0096-0097) which could be
interpreted by the interface apparatus.
As per claim 7, Halty discloses apparatus according to claim 1, wherein the processing circuitry is further to render the plurality of hardware microservices (users who can view and select
microservices managed by the platform 110 one or more microservices related to lead generation for
deployment of a clean technology, such as a solar panel - para 0046; candidates for Solar panel
Installation 412 - Fig. 4A; user can view and select different microservices - para 0053; through
user-interfaces coupled to the clean technology to view and select one or more of the microservices relating to the lead generation - para 0072) to the requested hardware microservice.
As per claim 8, Halty discloses apparatus according to claim 1, wherein the processing circuitry is further to:
obtain a statistic (user is homeowner registered to have solar panels installed dashboard
includes display areas control panel allows the user to navigate information regarding track
progress, profile, contribution, promotions, notifications dashboard indicating the completion
percentage - para 0094) of requested hardware microservice; and transmit offer data indicative of an offered hardware microservice to the interface circuitry.
As per claim 9, Halty discloses apparatus according to claim 1, wherein interface apparatus is part of an end client (browser to display panels that enable a user to select and view data home energy usage - para 0117) and the apparatus is part of a server (platform 110 implemented on one or more servers SasS web servers coupled to servers of platform 110 to support SaaS operations – para 0045).
As per claim 10, Halty discloses apparatus according to claim 1, wherein the processing circuitry is further to receive, from multiple databases, microservice data (e.g. clean technology platform and database stores data representative of microservices managed by the clean technology platform - para 0010; stores data relating to microservices managed by the clean technology platform - para 0045; through user-interfaces of respective computing devices coupled to the clean technology platform to view one or more of the microservices relating to lead generation, lead conversion or fulfillment of clean technology installations - para 0010; para 0074) indicative of a plurality of hardware microservices of the multiple databases (DBaaS - para 0126).
As per claim 11, Halty discloses an apparatus, the apparatus comprising interface circuitry,
machine-readable instructions and processing circuitry to execute the machine-readable
instructions to:
transmit, to the apparatus according to claim 1, the user data (e.g. candidate leads, design, finance options, pricing options, document collection, scheduling, fulfilling installation or tracking installation - para 0066; signals status changes with respect to microservices by qualified freelancers - para 0014; Fig. 6A, 6B; contact data, homeowner name, roof type, monthly bill amount, credit score familiarity with solar, interests, age of roof, planning on a move – para 0075) indicative of the hardware microservice (refer to Notel; filters for solar panel - Fig. 5) requested by a user (refer to claim 1; and
receive, from the apparatus, the mapped data (para 0096-0097; para 0121 - refer to Note3) indicative of the determined hardware microservice (see above) based on the user data.
As per claim 12, Halty discloses interface apparatus according to claim 11, wherein the processing circuitry is further to check whether the user data is supported (notify the user that QC coordinator validating the application - para 0109; validation to vet data - para 0120; once the design is accepted - para 0104) by the apparatus.
As per claim 13, Halty discloses interface apparatus according to claim 11, wherein the processing circuitry is further to categorize (fulfillment provider to categories 453 - Fig. 4E;
fulfillment provider and their services based on their categories, coverage area, capabilities, pricing -
para 0091) the requested hardware microservice (refer to lead generation, solar Panel installation -
Fig. 4A; fulfillment - Fig. 4D, 4E) of the user.
As per claim 14, Halty discloses interface apparatus according to claim 11, wherein the processing circuitry is further to establish a user interface (display view - para 0108; Fig. 8M, 8N) to receive the user data (user to review and sign documents pertinent to the fulfillment - para 0108) by generating a software hook (along with control buttons or links to upload, or electronically sign enable a user to verify service manager create a microservice to fulfill the installation - para 0108) into a development environment (create a microservice - para 0108; Fig. 8N, 80; Fig. 8H; customize the design, and upload a customized design - para 0102).
As per claim 16, Halty discloses a method, comprising:
receiving, from an apparatus comprising a first integrated development environment, user data indicative of a hardware microservice requested by a user, wherein the user data comprises a first programming language used by the first integrated development environment, and
wherein the hardware microservice is a software abstraction of a functionality of a physical
hardware component that exposes the functionality of the physical hardware component to the integrated development environment via an application programming interface, and
wherein the integrated development environment is a software application aimed to assist software developers in writing software codes, comprising a code editing environment and tools to
improve coding productivity and libraries for a coding environment that is programming
language dependent;
receiving, from a database comprising a hardware microservice catalog of a plurality of
hardware microservices each corresponding to a respective physical hardware component, microservice data indicative of a plurality of hardware microservices, wherein the microservice
data comprises a second, different look-up language to look-up hardware microservices;
determining a hardware microservice based on the plurality of hardware microservices
and the requested hardware microservice of the user; and
transmitting, to the apparatus, mapped data indicative of the determined hardware
microservice, wherein the mapped data is generated by an egress filter by emulating the
determined hardware microservice into a programming language that can be processed by the
interface apparatus for use within the first integrated development environment.
( All of which having been addressed in claim 1)
As per claim 18, Halty discloses method according to claim 16, further comprising:
provision hardware microservices of the plurality of hardware microservices (refer to claim 7) according to the user data (refer to claim 1); and
arranging an associated hardware microservice recipe (e.g. contact data from disparate sources of leads is aggregated data aggregator - para 0074; aggregated contact data to identify candidates and generate leads to deploy clean technology products like install solar panels- para 0075; para 0119) for rendering actions (see deploy clean technology products - para 0075; leads to a physical clean technology deployment - para 0076) in a development environment (refer to claim 1).
As per claim 19, Halty discloses method according to claim 16, further comprising
providing a catalog (database storing data representativity of microservices managed by the clean
technology platform - claim 1, pg. 10; refer to rationale B(ii) of claim 1) of determined hardware microservices based on the plurality of hardware microservices (refer to claim 7) and the requested hardware microservice of the user (refer to claim 1).
As per claim 20, Halty discloses method according to claim 16, further comprising generating a universal format (refer to visual representation or map data as universal language per
claim 4) comprising the determined hardware service (para 0096-0097 para 0047, 0053; para
0064).
As per claim 22, Halty discloses (refer to claim 16) a non-transitory, computer-readable medium comprising a program code that, when the program code is executed on a computer, a processor, or a programmable hardware component (para 0123-0125), performs the method according to claim 16.
Claims 5-6, 17 is/are rejected under § 35 U.S.C. 103 as being unpatentable over Halty et al, USPubN: 2021/0065123 (herein Halty) in view of Hilgers et al, USPubN: 2008/0244399(herein Hilgers), and Andre et al, USPN: 12,217,029 (herein Andre), further in view of Bhatia et al, USPubN: 2021/0288891 (herein Bhatia) and Rajagopalan et al, USPubN: 2019/0243748 (herein Rajagopalan) and further of Meng et al, CN 104469969A, (translation), 03-25-2015, 6 pgs (herein Meng) and Shedrinsky, USPubN: 2005/0021772 (herein Shedrinsky)
As per claims 5-6, Halty does not explicitly disclose apparatus according to claim 1, wherein the processing circuitry is further to establish a connection between the interface apparatus and the interface circuitry by a tunnel.
wherein the processing circuitry is further to establish a connection between the database and the interface circuitry by a tunnel.
Shedrinsky discloses establishing a virtual tunnel linking interface context of one processor
host and another computer host, the tunnel to support communication for instance between a client
application and a server application (para 0016-0017) as if there were no firewall between them,
using processing and protocol conversion by a client-side proxy in correspondence with a server-side
agent (para 0022, 0027-0029); hence establishing a virtual communication path via a tunnel between
a server circuitry and a client apparatus is recognized.
Provision of a communication interface by which a tunnel between databases and mobile
management (MM) platform entities is shown in Meng; where the requests initiated from terminals
to the database are sent via the NW tunnel, and parametric responses or query returned from the
database (para 0012-0017) follow the NW tunnel in accordance to correspondence between channel
parameters and unique set of values pre-configured in the DB (para 0030, 0035) as established under
tunnel management NW, so to support instant quality of service (para 0009-0010) - e.g. to address
abnormal recovery of the mobile management NW, where defect behavior of the mobile terminals
can be stored or modified with settings inside the database as reference used for future recoveries
(para 0041); hence establishing connection between a database and interface circuitry of recovery
entity of a MM system by way of a tunnel is recognized.
Therefore, it would have been obvious for one of ordinary skill in the art before the effective
filing date of the invention to alleviate communication complexities between a database, a server and
a client computer via protocol and firewall restrictions via use of tunneling as set forth in Shedrinsky
where setting of a virtual tunnel facilitate communication between apparatus interface of a client
machine with processing circuitry of a server; or as in Meng use of NW managed tunnel particularly
established via unique values setting between a dedicated database and the management circuitry
entities to enforce communication permissibility of the tunnel; because
communication between client apparatuses and respective server circuitry entails barrier of a
firewall and mismatch between protocols to meet before and after entry points or gateways across
disparate network and use of tunneling virtualization as set forth as short-term passage can alleviate
setbacks caused by this complication in temporarily bypassing any restrictions so to permit expedite
exchange between some client apparatuses and service circuitry; whereas use of tunnel configuration
approach as set forth in Meng to establish a structured and unique communication path between a
client/server circuitry and a database can enlist functionality of the very database to pre-record
required credentials associated with validating requirements established by a tunnel management
entity as set forth above.
As per claim 17, Halty discloses method according to claim 16, further comprising establishing at least one tunnel between a mediation engine and a development environment (refer to rationale of claim 5) or a mediation engine and a database (refer to rationale of claim 6)
Claims 15 is/are rejected under § 35 U.S.C. 103 as being unpatentable over Halty et al, USPubN: 2021/0065123 (herein Halty) in view of Hilgers et al, USPubN: 2008/0244399(herein Hilgers), and Andre et al, USPN: 12,217,029 (herein Andre), further in view of Bhatia et al, USPubN: 2021/0288891 (herein Bhatia) and Rajagopalan et al, USPubN: 2019/0243748 (herein Rajagopalan) and further of Kumar et al, USPubN: 2018/0213347 (herein Kumar) and JP 6376851, (translation) 8-22-2018, 19 pgs (herein '851)
As per claim 15, Halty does not explicitly disclose s interface apparatus according to claim 12, wherein when the user data comprises an unsupported DX intent the interface apparatus is further to perform at least one of document, tag or record the unsupported intent.
Kumar discloses a management service (para 0011) associated tracking of applications being selected or approved for installation by client in accordance with requirements by which applications can be installed ("approved" or uninstalled (unapproved), including providing a list of applications and identification that have authorized and slated for installation (para 0015, 0017); e.g. subjected to query by an IFrame utility (para 0047) based on which search and identification of instances of unapproved applications can be returned and subjected for removal by the management service (para 0049, 0051-0052); hence, tracking of unapproved install application by way of a management system in form of record or list subjected to query software is recognized.
Further, use of license presetting associated registration and identification of approved installation is shown in '851, wherein an installer service is configured to perform installation processing based on prestored registration information pertinent to the application (pg. 3), including
list of permitted applications being managed by the framework (pg. 10) or installer service, enabling
the latter in determining whether the application as intended is still valid or invalid based on terms of a license file (pg. 7), one of which constituting related information being appropriately stored and serving as manifest for enabling either authorization of the install by installer service, or otherwise abortion in case where an error is identified (pg. 10). Hence, registering of valid or invalid applications under management by a installer service entails unsupported intent from a client application being captured by a management service that tag or record the invalid intent via validating license information or mapping against a pre-approved list.
Thus, it would have been obvious for one of ordinary skill in the art before the effective
filing date of the invention to implement verification associated with authorizing installation of a
microservice in handling client request thereof in Halty so that the installation requests are managed
with administrative setting so to affirm intent from user in regard to authorizing the service or
microservice as requested as well as to detect invalid, or unsupported intents from user data based on
pre-arrangement of the microservice management layer on basis of registering or tagging of
applications deemed unapproved as set forth in Kumar list tracking or those considered invalid as set
forth in '851 license check authorization approach; because
registering of application or storing user intents deemed unsupported, invalid or unapproved
instances in form of a file, record or listing enable this registered information to be retrieved and
correlated in real-time with user data from incoming requests (for service install or microservice install) as part of the service authorization layer configured for determining whether data of the incoming request either fail the criteria that govern on how these applications were unapproved or match information as listed in the unapproved instances, facilitating thereby fast detection of which user request should be authorized or denied at the front end of the service authorization system of Halty.
Claims 21, 23 is/are rejected under § 35 U.S.C. 103 as being unpatentable over Halty et al, USPubN: 2021/0065123 (herein Halty) in view of Andre et al, USPN: 12,217,029 (herein Andre), and Rajagopalan et al, USPubN: 2019/0243748 (herein Rajagopalan)
As per claim 21, Halty discloses a method performed by an interface apparatus, comprising:
generating, within an integrated development environment (refer to claim 1; refer to Note1) installed on the interface apparatus, user data indicative of a hardware microservice (refer to claim 1; see Note1) requested by a user,
wherein the user data comprises a programming language (refer to rationale B(i) of claim 1) used by the integrated development environment, and
wherein the hardware microservice is a software abstraction of a functionality of a physical hardware component that exposes the functionality of the physical hardware component to the
integrated development environment via an application programming interface (refer to claim 1), and
wherein the integrated development environment is a software application aimed to assist software developers in writing software codes, comprising a code editing environment and tools to
improve coding productivity and libraries for a coding environment that is programming
language dependent (refer to rationale A of claim 1 in view of Andre);
transmitting the user data (refer to claim 1, refer to claim 11); and
receiving mapped data (refer to claim 1) indicative of a determined hardware microservice, wherein the mapped data is generated by an egress filter by emulating the determined hardware
microservice into a programming language (refer to rationale B(iii) of claim 1 in view of Rajagopalan) that can be processed by the interface apparatus for use within the integrated development environment.
As per claim 23, Halty discloses (refer to claim 21) a non-transitory, computer-readable medium comprising a program code that, when the program code is executed on a computer, a processor, or a programmable hardware component (para 0123-0125), performs the method according to claim 21.
Response to Arguments
Applicant's arguments filed 7/9/26 have been fully considered but they are not persuasive. Following are the Examiner’s observations in regard thereto.
(A) The Applicant has submitted that for the 101 rejection, the amended language of claim 1 is about eliminating the effort of rewriting microservice code due to programming language incompatibility, using instead a filter effect by emulating the HW microservice into a programming language natively with presentation of the IDE, and this constitute as combination of limitation that are not well-understood activity or routine as proffered in prong 2B (Applicant's Remarks pg. 8)
The office action analyzing claim 1, 16 or 21 has established prong 2B with the features exactly claimed with the last Office action, making the above allegation of eligibility merits of the newly introduced “egress filter” largely MOOT.
(B) The Applicant has submitted that none of the cited references teaches or suggests “hardware microservice” and “integrated development environment” as currently presented with claim 1 (Applicant's Remarks pg. 10-12)
Allegation of patentability merits of a newly introduced limitation cannot be viewed as proper grounds of rebut since the prior art rejection for this new language just happened to be presented now with this latest office action, rendering the above allegations largely premature.
( C ) The Applicant has submitted that for the look-up limitation and use thereof by Hilgers in generic database, there is no user facing side and database facing side in server base approach by Hilgers in regard to accessing HW microservices in a catalog (Applicant's Remarks pg. 13). There is no sufficient details in the claim to support the above remark about a dual language programming scheme using different programming languages; the obviousness as effectuated using Hilgers cannot be overcome; in that “different look-up language” cannot dictate that this language is written in a another language from any other non-lookup programming language.
( D) The Applicant has submitted that neither Iyer nor Hidgers teach a different lookup language, in the context that user data associated with the IDE as claimed, includes a first programming language (Applicant's Remarks pg. 14). Per BRI, the “second different lookup language” cannot be interpreted as a second language different that the “first programming language” in the user context because the structure of the claim makes this distinction so impossible for one to make the connection that a “different lookup language” is second language different from a “first programming language”. Applicant remark is largely non-persuasive.
(E ) The Applicant has submitted that (Applicant's Remarks pg. 14 bottom) “mapped data” as understood in the Examiner assertion as those matching user query cannot be relevant to the compilation context of Iyer. This remark has not relationship to any part of the office action or any prior art reference used therewith, notably in light of the latest ground of rejection effected to respond to the amended claims.
(F) The Applicant has submitted that Iyer in isolation or in combination with Halty, Padmanabhumi, Hilgers cannot teach or suggest egress filter implemented on the “mapped data” as by emulating the HW microservice to a programming language (Applicant's Remarks pg. 15). The limitations provided with this submission have necessitated an adjusted ground of rejection, which does not utilize all the prior art references as indicated above, and rebuttal built upon presenting deficiencies by a ground of rejection that was directed to a previous set of limitations is deemed largely misplaced.
As a side remark, applying a filter to a mapped data cannot be semantically and syntactically equivalent to “emulating a HW microservice” into a “programming language”.
In all, the claims as currently amended stand rejected with the office action set forth above.
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
August 8, 2026
Prosecution Insights