CTNF 18/593,475 CTNF 101616 DETAILED ACTION 07-03-aia AIA 15-10-aia 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 claims filed 03/01/2024. Claims 1-20 are pending. Claim Objections 07-29-01 Claims 9 and 13 are objected to because of the following informalities, appropriate correction is required: Claim 9 recites “a request for the at least one webpage”, it is unclear if “a request” is the same or different to the previously declared “a request” from Claim 8. For the purposes of compact prosecution, Examiner will interpret “a request” in Claim 9 to refer to the same “a request” in established in Claim 8. Claim Rejections - 35 USC § 103 07-20-aia AIA 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. 07-21 AIA Claim s 1-2, 7-11, and 13-14 are rejected under 35 U.S.C. 103(a) as being unpatentable over Tank et al. (US 20210248205 A1) (hereinafter Tank) . Regarding Claim 1, Tank teaches: A system for using front-end micro-services in rendering a webpage, the system comprising: one or more memories; “The systems and methods can retrieve one or more user interface specifications corresponding to a micro-service that provides the micro-frontend”, (Tank: Abstract), “computer 100 may include one or more processors 105, volatile memory 110 (e.g., random access memory (RAM)), non-volatile memory 120 (e.g., one or more hard disk drives (HDDs)…”, (Tank: ¶030), “the request received by the frontend request receiver 225 can include a web-page, or an indication of a webpage”, (Tank: ¶063). and one or more processors, communicatively coupled to the one or more memories, configured to: receive, from a web host, code associated with at least one webpage; “the layout service 205 can include at least one processor and a memory” … “The memory stores processor-executable instructions that, when executed by processor, cause the processor to perform one or more of the operations…”, (Tank: ¶050), “The teams 335 can provide scripts, style sheets, web pages, images, video, text assets, or any other resource 260, user interface specification, meta data, or any other information to onboard a micro-service to the micro-services layer 340”, (Tank: ¶076), “The micro-services layer can provide one or more micro-services to the layout service, including one or more resources, scripts, APIs, user interface specifications, web pages, or other information to provide one or more micro-frontends to the customer 305”, (Tank: ¶077), “The data object loader 245 can load each of the resources identified by the resource identifier 235, for example from the content delivery network 215” … “The data object loader 245 can access the content delivery network 215 to retrieve the one or more resources identified by the resource identifier 235”, (Tank: ¶065), “the layout service 205 can retrieve each of the resources 260 identified by the tags in the web-page from the content delivery network 215”, (Tank: ¶094), “a layout service, which can receive requests” … “The layout service can load” … “one or more resources from a content delivery network” … “The one or more resources can include style sheets, script libraries, and HTML code, among others”, (Tank: ¶042). Examiner notes: the layout service providing webpage resources within the server/computing device/CDN is being interpreted as the “web host”. initiate a plurality of instances of a micro-service using the code; “The web application can be composed of multiple micro-frontends provided by a plurality of heterogeneous micro-services”, (Tank: ¶006), “The flow diagram 300 depicts an example process, flow or operation for providing one or more micro-services”, (Tank: ¶070, Fig 3), “Each micro-service 265 of the micro-services 265 can include or consist of code or scripts depending on two or more frameworks or programming interfaces”, (Tank: ¶054), “The layout service 205 can include any and all code (e.g., scripts, resources, etc.) to render one or more micro-services or micro-frontends”, (Tank: ¶075). perform a single application programming interface (API) call for a first instance in the plurality of instances, “The customer 305 can access one or more features (e.g., functionalities, scripts, etc.) of the one or more micro-services of the micro-services layer 340 using one or more API calls 330”, (Tank: ¶073), “The micro-frontend provided to the customer by the layout service 205 or the router 310 can include one or more scripts which can provide one or more API calls 330 to the micro-services layer 340”, (Tank: ¶073), “For example, an API call 330 can access the micro-services layer 340 in response to a user interaction, such as the actuation of an actionable item, or any of the other types of interactions described herein” … “the customer may execute a script which uses an API call 330 to get updated information from the micro-services”, (Tank: ¶073), “The micro-services layer 340 can receive one or more request for functionality via one or more API calls 330…”, (Tank: ¶077). wherein a response from the single API call is shared with remaining instances in the plurality of instances; “The data object loader 245 can communicate information between at least two of the rendered micro-frontends one or more scripting variables”, (Tank: ¶068), “The micro-frontend of the one or more micro-services of the micro-services layer 340 may contain one or actionable objects, for example buttons, links, clickable items, or any other items which may provide additional functionality in response to some sort of interaction received by the customer” … “For example, an API call 330 can access the micro-services layer 340” … “The customer 305 may also execute one or more scripts which use one or more API calls 330 to periodically update information in the micro-frontend corresponding to at least one micro-service of the micro-services layer 340”, (Tank: ¶073). While Tank does not explicitly teach a response from an API , it does teach services utilizing APIs to update information on the front end in “the customer may execute a script which uses an API call 330 to get updated information from the micro-services layer 340 on a periodic basis”, (Tank: ¶073). Using an API to get any type of information is similar to receiving an API response because an API being used to get updated information cannot provide said information without sending out a response. It would have been obvious that using an API to get information encompasses receiving a response from an API for receiving up-to-date data. render a plurality of web elements, corresponding to the plurality of instances, using the code and the response from the single API call; “The customer 305 can display one or more micro-services using a web application composed of one or more micro-frontends. Each of the micro-frontends can be a portion, region, or functional area of a user interface provided by the one or more micro-services”, (Tank: ¶071), “The customer 305 may also execute one or more scripts which use one or more API calls 330 to periodically update information in the micro-frontend corresponding to at least one micro-service of the micro-services layer 340” … “an API call 330 to get updated information from the micro-services layer 340 on a periodic basis”, (Tank: ¶073), “Rendering the at least two micro-services can include accessing the resources 260, scripts, style sheets, and any other information” … “The data object loader 245 can render two or more micro-frontends corresponding to two or more micro-services 265 in a single region, for example a single web page or application window”, (Tank: ¶067), “The micro-services layer 340 can provide the requested information (e.g., update information, processing information, micro-services layer status information, or any other requested information, etc.) to the customer 305 in response to the request via the API call 330”, (Tank: ¶077). and output the at least one webpage, including the plurality of web elements, to a user. “The micro-frontend” … “may contain one or actionable objects, for example buttons, links, clickable items, or any other items”, (Tank: ¶073), “The client device 220 may execute one or more applications, for example a web browser, to render and display a web based interface, for example a web-page” … “the application can be a web application composed of many micro-frontends (e.g., panels, frames, etc.)”, (Tank: ¶051), “The data object loader 245 can render two or more micro-frontends corresponding to two or more micro-services 265 in a single region, for example a single web page or application window” … “the data object loader 245 can display the contents of the graphics buffer on a display of the layout service 205” … “the data object loader 245 can transmit the contents of the graphics buffer to one or more computing devices for display, for example the client device 220”, (Tank: ¶067). Regarding Claim 2, Tank teaches: the plurality of instances are executed separately from a host application associated with the at least one webpage. “Different micro-services can be developed by different teams, which may operate independently from one another”, (Tank: ¶005), “establish a plurality of micro-frontends as data objects rendered in a container web application on a client device. Instead of providing a monolithic web application, each of the micro-frontends represent at least one micro-service, and can be developed, updated, and deployed by independent development teams on independent release cycles”, (Tank: ¶025), “onboard each micro-service without adding any additional code to the container application (e.g., the web application, etc.)”, (Tank: ¶044). Examiner notes: micro-services can be onboarded without affecting the host application since embodiment avoids a monolithic interface and each microservice acts independently. Regarding Claim 7, Tank teaches: the code comprises JavaScript code. “The data objects can be established in a JavaScript used by a framework to construct a document object model for rendering”, (Tank: ¶006), “two of the plurality of micro-frontends using a JavaScript properties variable or a JavaScript context variables”, (Tank: ¶009), “Some PaaS interfaces use HTTP packages, standard Java APIs, JavaMail API, Java Data Objects (JDO), Java Persistence API (JPA)”, (Tank: ¶039), “a number of different JavaScript back-ends, for example ReactJS, ZoneJS, and VueJS, among others”, (Tank: ¶046). Regarding Claim 8, Tank teaches: A method of using front-end micro-services in rendering a webpage, comprising: receiving, from a user device, a request to access at least one webpage; “receiving, from a client application executing on a client device, a request to access a micro-frontend of a user interface for a web application”, (Tank: ¶006), “The frontend request receiver 225 can receive a request from a client application executing on the client device 220”, (Tank: ¶055), “The request can be received from an application executing on a client device. The request can be a request to access a micro-frontend of a user interface for a web application composed of a plurality of micro-frontends provided via a plurality of heterogeneous micro-services”, (Tank: ¶096). initiating, by a web server, a plurality of instances of a micro-service using code associated with the at least one webpage; “The web application can be composed of multiple micro-frontends provided by a plurality of heterogeneous micro-services”, (Tank: ¶006), “The flow diagram 300 depicts an example process, flow or operation for providing one or more micro- services”, (Tank: ¶070, Fig 3), “Each micro-service 265 of the micro-services 265 can include or consist of code or scripts depending on two or more frameworks or programming interfaces”, (Tank: ¶054), “The layout service 205 can include any and all code (e.g., scripts, resources, etc.) to render one or more micro-services or micro-frontends”, (Tank: ¶075). performing, by the web server, a single application programming interface (API) call for a first instance in the plurality of instances, “The customer 305 can access one or more features (e.g., functionalities, scripts, etc.) of the one or more micro-services of the micro-services layer 340 using one or more API calls 330”, (Tank: ¶073), “The micro-frontend provided to the customer by the layout service 205 or the router 310 can include one or more scripts which can provide one or more API calls 330 to the micro-services layer 340”, (Tank: ¶073), “For example, an API call 330 can access the micro-services layer 340 in response to a user interaction, such as the actuation of an actionable item, or any of the other types of interactions described herein” … “the customer may execute a script which uses an API call 330 to get updated information from the micro-services”, (Tank: ¶073), “The micro-services layer 340 can receive one or more request for functionality via one or more API calls 330…”, (Tank: ¶077). wherein a response from the single API call is shared with remaining instances in the plurality of instances; “The data object loader 245 can communicate information between at least two of the rendered micro-frontends one or more scripting variables”, (Tank: ¶068), “The micro-frontend of the one or more micro-services of the micro-services layer 340 may contain one or actionable objects, for example buttons, links, clickable items, or any other items which may provide additional functionality in response to some sort of interaction received by the customer” … “For example, an API call 330 can access the micro-services layer 340” … “The customer 305 may also execute one or more scripts which use one or more API calls 330 to periodically update information in the micro-frontend corresponding to at least one micro-service of the micro-services layer 340”, (Tank: ¶073). While Tank does not explicitly teach a response from an API , it does teach services utilizing APIs to update information on the front end in “the customer may execute a script which uses an API call 330 to get updated information from the micro-services layer 340 on a periodic basis”, (Tank: ¶073). Using an API to get any type of information is similar to receiving an API response because an API being used to get updated information cannot provide said information without sending out a response. It would have been obvious that using an API to get information encompasses receiving a response from an API for receiving up-to-date data. rendering, by the web server, a plurality of web elements, corresponding to the plurality of instances, using the code and the response from the single API call; “The customer 305 can display one or more micro-services using a web application composed of one or more micro-frontends. Each of the micro-frontends can be a portion, region, or functional area of a user interface provided by the one or more micro-services”, (Tank: ¶071), “The customer 305 may also execute one or more scripts which use one or more API calls 330 to periodically update information in the micro-frontend corresponding to at least one micro-service of the micro-services layer 340” … “an API call 330 to get updated information from the micro-services layer 340 on a periodic basis”, (Tank: ¶073), “Rendering the at least two micro-services can include accessing the resources 260, scripts, style sheets, and any other information” … “The data object loader 245 can render two or more micro-frontends corresponding to two or more micro-services 265 in a single region, for example a single web page or application window”, (Tank: ¶067), “The micro-services layer 340 can provide the requested information (e.g., update information, processing information, micro-services layer status information, or any other requested information, etc.) to the customer 305 in response to the request via the API call 330”, (Tank: ¶077). and transmitting, to the user device, instructions for the at least one webpage including the plurality of web elements that were rendered. “The resource package can include each of the resources required to render the one or more micro-frontends 468, and can be transmitted to the browser 405 by the layout service 205”, (Tank: ¶094), “the UI specifications can be transmitted via a network (e.g., the network 210) to the browser 405 (ACT 484)”, (Tank: ¶091), “The layout service 205 can perform UI resource routing to provide the browser 405 with the one or more UI resources 260”, (Tank: ¶092), “The micro-frontend of the one or more micro-services of the micro-services layer 340 may contain one or actionable objects, for example buttons, links, clickable items, or any other items which may provide additional functionality”, (Tank: ¶073). Regarding Claim 9, Tank teaches: transmitting, to a web host, a request for the at least one webpage; “The layout service can receive, from a client application executed on a client device, a request to access a micro-frontend of a user interface for a web application”, (Tank: ¶010), “The applicant of the client device 220 can make a request to the layout service 205 for each micro-frontend individually”, (Tank: ¶051), “The layout service 205 can receive one or more requests for a micro-frontend corresponding to one or more micro-services of the micro-services layer 340 from the router 310 or the customer 305”, (Tank: ¶075). Examiner notes: the server/computing device/CDN providing webpage resources is being interpreted as the “web host”. and receiving, from the web host, the code associated with the at least one webpage. “The teams 335 can provide scripts, style sheets, web pages, images, video, text assets, or any other resource 260, user interface specification, meta data, or any other information to onboard a micro-service to the micro-services layer 340”, (Tank: ¶076), “The micro-services layer can provide one or more micro-services to the layout service, including one or more resources, scripts, APIs, user interface specifications, web pages, or other information to provide one or more micro-frontends to the customer 305”, (Tank: ¶077), “The data object loader 245 can load each of the resources identified by the resource identifier 235, for example from the content delivery network 215” … “The data object loader 245 can access the content delivery network 215 to retrieve the one or more resources identified by the resource identifier 235”, (Tank: ¶065), “the layout service 205 can retrieve each of the resources 260 identified by the tags in the web-page from the content delivery network 215”, (Tank: ¶094), “a layout service, which can receive requests” … “The layout service can load” … “one or more resources from a content delivery network” … “The one or more resources can include style sheets, script libraries, and HTML code, among others”, (Tank: ¶042). Regarding Claim 10, Tank teaches: initiating, for each web element in the plurality of web elements, a unique instance in the plurality of instances. “the application can be a web application composed of many micro-frontends (e.g., panels, frames, etc.). Each micro-frontend can be an individual user interface for a corresponding micro-service 265” … “The applicant of the client device 220 can make a request to the layout service 205 for each micro-frontend individually”, (Tank: ¶051), “he present disclosure also allows each micro-service to establish its own style sheet, thereby avoiding conflicts with style sheets of other micro-services. This is a significant improvement over other implementations which use shared style sheets”, (Tank: ¶043). Regarding Claim 11, Tank teaches: the instructions for the at least one webpage comprise hypertext markup language code. “The one or more resources can include style sheets, script libraries, and HTML code, among others”, (Tank: ¶042), “The client device 220 can execute different scripting languages embedded in web documents, for example JavaScript, HTML, cascading style sheets (CSS), among others”, (Tank: ¶051), “The user interface specifications can be used to load one or more resources and tags to generate a script to render one or more micro-frontends in a client application executing on a client device”, (Tank: ¶041). Regarding Claim 13, Tank teaches: the request comprises a hypertext transfer protocol request. “Some IaaS standards may allow clients access to resources over HTTP” … “Some PaaS interfaces use HTTP packages” … “other APIs that may be built on REST, HTTP, XML, or other protocols”, (Tank: ¶039), “a server or authentication server may authenticate a user via security certificates, HTTPS, or API keys”, (Tank: ¶040), “The API calls 330 can include requests for updated information, or may include one or more data packets for processing”, (Tank: ¶077). Regarding Claim 14, Tank teaches: generating a cached version of the response from the single API call; “the method can include storing, in cache accessible by the layout service, the one or more user interface specifications corresponding to the plurality of heterogeneous micro-services”, (Tank: ¶007), “The cache 250 can store any or all of the information described herein with respect to the layout service 205, including any data received by, transmitted by, provided to, calculated, determined, or otherwise generated by the layout service 205 or any of the components of the layout service 205”, (Tank: ¶069), “The micro-frontend provided by the layout service can include one or more API calls 330 to provide the customer 305 with direct access to the functionality of the micro-services layer 340”, (Tank: ¶075), “Downloading the one or more resources can include downloading one or more user specifications, scripts, or web pages to store in the cache 250 (ACT 473)”, (Tank: ¶086), “certain aspects of the micro-fronted may be updated on a periodic basis” … “he micro-frontend provided to the customer by the layout service 205” … “may execute a script which uses an API call 330 to get updated information from the micro-services layer 340 on a periodic basis”, (Tank: ¶073), “Onboarding a micro-service 265 can include transferring data associated with the particular micro-service 265 (e.g., scripts, tags, application programming interfaces (APIs), web-pages, user interface specifications, any other data associated with the micro-service, etc.) to the cache 250 or the content delivery network 215”, (Tank: ¶058). Examiner notes: UI specification updated gathered from API responses get downloaded into cache which is later retrieved for micro-frontend onboarding. and providing the cached version to an additional web element. “The cache 250 can store one or more web-pages associated with each micro-service 265, and may store one or more tags which can be inserted or added to the web pages by the tag injector 240”, (Tank: ¶069), “The API calls 330 can include requests for updated information, or may include one or more data packets for processing by the micro-services of the micro-services layer 340”, (Tank: ¶077), “The specification retriever 230 can access the cache 250, which can contain one or more user specifications for onboarded micro-frontends. The specification retriever 230 can access one or more data structures in the cache 250 to retrieve the corresponding one or more user interface specifications”, (Tank: ¶057) . 07-21 AIA Claim s 3 are rejected under 35 U.S.C. 103(a) as being unpatentable over Tank in view of Beecham et al. (US 20190288850 A1) (hereinafter Beecham) . Regarding Claim 3, Tank fails to teach: a portion of the code associated with the plurality of instances is less than 1 kilobyte. However, Beecham teaches: “In some cases, documents may be larger than one byte, 100 bytes, 1 kB, 100 kB, 1 MB, or 1 GB”, (Beecham: ¶047), “A program may be stored in a portion of a file that holds other programs or data (e.g., one or more scripts stored in a markup language document), in a single file dedicated to the program in question, or in multiple coordinated files (e.g., files that store one or more modules, sub programs, or portions of code)”, (Beecham: ¶367). It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to combine a portion of the code associated with the plurality of instances is less than 1 kilobyte of Beecham with the methods and systems of Tank resulting in stored code taking up less than 1KB of space. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of “data may be compressed, for example, with entropy coding to facilitate reduced use of bandwidth and faster retrieval”, (Beecham: ¶128) . 07-21 AIA Claim s 4-5, and 19-20 are rejected under 35 U.S.C. 103(a) as being unpatentable over Tank in view of Pivato et al. (US 20180285328 A1) (hereinafter Pivato) . Regarding Claim 4, Tank teaches: receive the response from the single API call “The micro-services layer 340 can provide the requested information” … “to the customer 305 in response to the request via the API call 330”, (Tank: ¶077), “may execute a script which uses an API call 330 to get updated information from the micro-services layer 340 on a periodic basis”, (Tank: ¶073), “the customer 305 to onboard one or more micro-services to the micro-service layer 340, and in response, provide the functionalities described herein above with respect to FIG. 2 to onboard the micro-service”, (Tank: ¶075, Fig 2). Further regarding Claim 4, Tank fails to teach: wherein the response includes an object, the first instance uses a first element from the object, and a second instance in the plurality of instances uses a second element, different than the first element, from the object. However, Pivato teaches: “the client can receive and parse the application load response from the server, which can be in the form of a JSON Response”, (Pivato: ¶107), “The client can Process Actions 403, for example, by dispatching each action to an action handler associated with the action. Each action type can have an array of data packages”, (Pivato: ¶120), “The action dispatcher can implement a simple and fast computer execution loop that calls the action at the specified index (action type) passing to the handler the data array associated with the action”, (Pivato: ¶121), “For example, a “create widget” handler can create new widgets by iterating the data array and creating all the widgets according to the JSON definition received with the action request”, (Pivato: ¶122), “an ‘update handler’ can update existing widgets by iterating the data array and applying the new property values to the specific widgets according to the JSON definition received with the action request”, (Pivato: ¶123), “Each server component 052 can have a corresponding client widget 032 (for example, JavaScript Widgets)”, (Pivato: ¶063), “During runtime, the server can send the mapped properties to the client to initialize or update the client widgets”, (Pivato: ¶065). It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to combine wherein the response includes an object, the first instance uses a first element from the object, and a second instance in the plurality of instances uses a second element, different than the first element, from the object of Pivato with the methods and systems of Tank resulting in an object being sent as a response whose varying field are used by different services. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of “The server is able to push updates to any widget anywhere on the browser simply by sending an action request”, (Pivato: ¶132), “Because the server has full control, this results in a more stable web-application, without relying on a client request, cutting down on stutter and choppiness of the application”, (Pivato: ¶133). Regarding Claim 5, Tank teaches: and render the plurality of web elements according to respective styles of the plurality of web elements. “Rendering the at least two micro-services can include accessing the resources 260, scripts, style sheets” … “The data object loader 245 can render the user interface and graphics data into the graphics buffer based on the style sheets”, (Tank: ¶067), “The layout service 205 can dynamically add script and style tags based on the list of UI resources 260 parsed from the one or more UI specifications (ACT 479)”, (Tank: ¶093), “Once the tags, scripts, or style sheets have been inserted or dynamically added to the web page to be rendered by the browser 405”, (Tank: ¶094). Further regarding Claim 5, Tank fails to teach pass portions of the response from the plurality of instances to the plurality of web elements; However, Pivato teaches: “The server can have a plurality of server components 052” … “Each server component 052 can have a corresponding client widget 032” … “The server components 052 and the client widgets 032 can be mapped to each other by a table, a database, or through properties belonging to the server component 052…”, (Pivato: ¶063), “Each component can contain property values, these property values belonging to the corresponding client. During runtime, the server can send the mapped properties to the client to initialize or update the client widgets”, (Pivato: ¶065), “In both the run-time and design-time cases, the properties can be sent the first time the widget is created on the client, subsequent updates can contain only the values that have changed since the last update”, (Pivato: ¶066), “preparing and sending a state and event response message, to a client, the message including updated widget definitions” … “wherein the message is formatted in JSON format and the client does not change appearance of the web application unless instructed to by the server”, (Pivato: Claim 3). It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to combine pass portions of the response from the plurality of instances to the plurality of web elements of Pivato with the methods and systems of Tank resulting in portions of response object being used to update components. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of “The server is able to push updates to any widget anywhere on the browser simply by sending an action request”, (Pivato: ¶132), “Because the server has full control, this results in a more stable web-application, without relying on a client request, cutting down on stutter and choppiness of the application”, (Pivato: ¶133). Regarding Claim 19, Tank fails to teach: the response comprises an object including a plurality of elements However, Pivato teaches: “the client can receive and parse the application load response from the server, which can be in the form of a JSON Response”, (Pivato: ¶107), “The client can Process Actions 403, for example, by dispatching each action to an action handler associated with the action. Each action type can have an array of data packages”, (Pivato: ¶120), “The action dispatcher can implement a simple and fast computer execution loop that calls the action at the specified index (action type) passing to the handler the data array associated with the action”, (Pivato: ¶121), “For example, a “create widget” handler can create new widgets by iterating the data array and creating all the widgets according to the JSON definition received with the action request”, (Pivato: ¶122), “an ‘update handler’ can update existing widgets by iterating the data array and applying the new property values to the specific widgets according to the JSON definition received with the action request”, (Pivato: ¶123), “Each server component 052 can have a corresponding client widget 032 (for example, JavaScript Widgets)”, (Pivato: ¶063), “During runtime, the server can send the mapped properties to the client to initialize or update the client widgets”, (Pivato: ¶065). It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to combine the response comprises an object including a plurality of elements of Pivato with the methods and systems of Tank resulting in an object being sent as a response whose varying field are used by different services. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of “The server is able to push updates to any widget anywhere on the browser simply by sending an action request”, (Pivato: ¶132), “Because the server has full control, this results in a more stable web-application, without relying on a client request, cutting down on stutter and choppiness of the application”, (Pivato: ¶133). Regarding Claim 20, Tank fails to teach: the response comprises a JavaScript object notation data structure However, Pivato teaches: “preparing and sending a state and event response message, to a client” … “wherein the message is formatted in JSON format”, (Pivato: ¶020), “the application load response from the server, which can be in the form of a JSON Response. The client can use the information in the JSON Response to generate a list of actions to execute on the client side”, (Pivato: ¶107). It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to combine the response comprises a JavaScript object notation data structure of Pivato with the methods and systems of Tank resulting in responses being in JSON format. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of “Each widget can be configured, for example in a JSON configuration, with one or more properties”, (Pivato: ¶109), “Because the server has full control, this results in a more stable web-application, without relying on a client request, cutting down on stutter and choppiness of the application”, (Pivato: ¶133) . 07-21 AIA Claim s 6, 12 and 16 are rejected under 35 U.S.C. 103(a) as being unpatentable over Tank in view of Tucker et al. (US 20200278884 A1) (hereinafter Tucker) . Regarding Claim 6, Tank fails to teach: the first instance in the plurality of instances is associated with an earliest request to an API in a queue, and the earliest request triggers the single API call. However, Tucker teaches: “add representations of the asynchronous function calls to a client-side queue” … “The client device may then generate a “batch” of asynchronous requests corresponding to the queued function calls (e.g., two or more asynchronous requests combined in some fashion into a single message)”, (Tucker: ¶004), “The client device 600 may continue to read the function calls and add representations of them in the client-side queue until the client device 600 detects that a trigger event has occurred…”, (Tucker: ¶126), “the client device 600 adds the first function call representation to the client-side queue”, (Tucker: ¶128), “a given “batch” of asynchronous requests may include two or more asynchronous requests combined in some fashion into the form of a single message including data representative of the requests”, (Tucker: ¶127), “in response to the first plurality of asynchronous function calls being all asynchronous function calls present in the queue when the trigger event is detected, the client device may transmit, to the web server device, the first message containing the ordered representation of the first plurality of asynchronous function calls”, (Tucker: ¶181) It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to combine the first instance in the plurality of instances is associated with an earliest request to an API in a queue, and the earliest request triggers the single API call of Tucker with the methods and systems of Tank resulting in a queue of API calls that is used to trigger the earliest call. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of “Notably, the number of transactions per web document that the client device carries out with the web server device may be reduced. This, in turn, can improve the performance of the web server device, since the web server device may be able to serve more web documents per unit of time.”, (Tucker: ¶006). Regarding Claim 12, Tank fails to teach: the first instance in the plurality of instances is associated with an earliest request to an API in a queue, and the earliest request triggers the single API call . However, Tucker teaches: “add representations of the asynchronous function calls to a client-side queue” … “The client device may then generate a “batch” of asynchronous requests corresponding to the queued function calls (e.g., two or more asynchronous requests combined in some fashion into a single message)”, (Tucker: ¶004), “The client device 600 may continue to read the function calls and add representations of them in the client-side queue until the client device 600 detects that a trigger event has occurred…”, (Tucker: ¶126), “the client device 600 adds the first function call representation to the client-side queue”, (Tucker: ¶128), “a given “batch” of asynchronous requests may include two or more asynchronous requests combined in some fashion into the form of a single message including data representative of the requests”, (Tucker: ¶127), “in response to the first plurality of asynchronous function calls being all asynchronous function calls present in the queue when the trigger event is detected, the client device may transmit, to the web server device, the first message containing the ordered representation of the first plurality of asynchronous function calls”, (Tucker: ¶181) It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to combine the first instance in the plurality of instances is associated with an earliest request to an API in a queue, and the earliest request triggers the single API call of Tucker with the methods and systems of Tank resulting in a queue of API calls that is used to trigger the earliest call. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of “Notably, the number of transactions per web document that the client device carries out with the web server device may be reduced. This, in turn, can improve the performance of the web server device, since the web server device may be able to serve more web documents per unit of time.”, (Tucker: ¶006) . 07-21 AIA Claim s 15-18 are rejected under 35 U.S.C. 103(a) as being unpatentable over Tank in view of Gaur et al. (US 20190180002 A1) (hereinafter Gaur) . Regarding Claim 15, Tank teaches: A non-transitory computer-readable medium storing a set of instructions for using front end micro-services in rendering a webpage, “a non-transitory computer readable medium storing program instructions” … “The program instructions can cause the one or more processors to receive, from a client application executed on a client device, a request to access a micro-frontend of a user interface for a web application composed of a plurality of micro-frontends provided via a plurality of heterogeneous micro-services”, (Tank: ¶014), “the program instructions further cause the one or more processors to: onboard, using the one or more user interface specifications, the plurality of heterogeneous micro-services in a cache and a content delivery network that is accessible by the layout service during runtime”, (Tank: Claim 20). the set of instructions comprising: one or more instructions that, when executed by one or more processors of a device, cause the device to: receive a request, at an application programming interface (API), from an instance of a micro-service associated with at least one webpage; “The systems and methods can receive a request to access a micro-frontend of a user interface for a web-application from a client application executing on a client device”, (Tank: Abstract), “the router 310 may receive one or more requests from the customer 305 to access at least one micro-fronted provided by a micro-service” … “In some implementations, the router 310 can use one or more template APIs 325 to perform any of the actions described herein with respect to the router 310 or the layout service 205” … “the router 310 can access the one or more templates API 325 to determine which micro-service to access in the micro-service layer 340”, (Tank: ¶074), “may include one or more APIs to access the functionality of the corresponding micro-service of the plurality of heterogeneous micro-services”, (Tank: ¶096). Further regarding Claim 15, Tank fails to teach: verify that the request is from the instance of the micro-service rather than from a host application associated with the at least one webpage; However, Gaur teaches: “Using the microservice trust relationship information, a determination is made as to whether a consensus exists among other microservices within the microservices system that the second microservice is authorized to inter- operate within the microservices system”, (Gaur: Abstract), “receiving, by a processor executing a first microservice from a second microservice within a microservices system, a microservice join request including microservice trust relationship information of the second microservice that defines microservice credentials and service description parameters of the second microservice”, (Gaur: ¶003), “At least one run-time inter-operation request is received that includes a relationship trust token from the second microservice”, (Gaur: ¶012), “in response to determining that parameters of the relationship trust token match the defined microservice credentials and service description parameters of the second microservice within the validated local run-time inter-operational microservice trust relationship information”, (Gaur: ¶073). and transmit a response to the instance of the micro-service based on verifying that the request is from the instance of the micro-service. However, Gaur teaches: “The other microservices may inspect the microservice trust relationship information and confirm or deny that any listed dependent service or similar service (e.g., cluster) exists, and may respond that the join request ” … “to determine by consensus with other microservices whether the new requesting microservice is authorized to inter-operate”, (Gaur: ¶077), “the process 500 documents the microservice trust relationship information of the requesting microservice as validated run-time inter-operational microservice trust relationship information for use in the microservices system” … “the process 500 creates a new entry in a locally-maintained (local) microservices trust ledger at block 514. The new entry in the local microservices trust ledger may be used to store the defined microservice credentials and service description parameters of the requesting microservice for locally-managed authentication of subsequent connection and inter-operation requests from the microservice”, (Gaur: ¶079). It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to combine verify that the request is from the instance of the micro-service rather than from a host application associated with the at least one webpage; and transmit a response to the instance of the micro-service based on verifying that the request is from the instance of the micro-service of Gaur with the methods and systems of Tank resulting in API verification that provides feedback to the sender. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of “improves microservice deployment and inter-operation by providing automated microservice trust management for microservice deployments”, (Gaur: ¶015). Regarding Claim 16, Tank teaches: receive an additional request from an additional instance of the micro-service associated with the at least one webpage; and reject the additional request based on the additional request being associated with a same micro-service as the request. “The customer 305 can access the router 310 by providing the router 310 with one or more requests for micro-frontends associated with the micro-services of the micro-services layer 340”, (Tank: ¶072), “The layout service 205 can receive one or more requests for a micro-frontend corresponding to one or more micro-services of the micro-services layer 340 from the router 310 or the customer 305”, (Tank: ¶075), “The browser 405 can make one or more requests to the layout service 205, or the modules included in the layout service 205. The browser 405 may interact with the layout service 205 to request one or more micro-frontends (e.g., the UI micro-frontend 468) for display in a web application in the browser 405”, (Tank: ¶080). Further regarding Claim 16, Tank fail to teach and reject the additional request based on the additional request being associated with a same micro-service as the request. However, Gaur teaches: “the process 500 validates the received relationship trust token with local microservices trust ledger entries to determine whether the received run-time inter-operation request may be granted or denied”, (Gaur: ¶083), “In response to determining that the run-time inter-operation request is not authorized, the process 500 denies the run-time inter-operation request at block 526”, (Gaur: ¶084), “the container may immediately deny a connection request from any microservice that does not have a previously provided relationship trust token present within the local microservices trust ledger”, (Gaur: ¶035), “rogue microservices that issue requests outside of the defined authorized time frames may be denied interaction”, (Gaur: ¶036). It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to combine and reject the additional request based on the additional request being associated with a same micro-service as the request of Gaur with the methods and systems of Tank resulting in API rejection from requesting microservice instance. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of “improves microservice deployment and inter-operation by providing automated microservice trust management for microservice deployments”, (Gaur: ¶015). Regarding Claim 17, Tank fails to teach: perform verification using a source indicated in the request. However, Gaur teaches: “The microservice trust token operates as a container identifier”, (Gaur: ¶023), “the microservice trust token is passed. Prior to honoring the request, the TTL, validity of the request, and requested services are evaluated against the committed/valid entries within the distributed microservices trust ledger”, (Gaur: ¶024), “the process 500 validates the received relationship trust token with local microservices trust ledger entries to determine whether the received run-time inter-operation request may be granted or denied”, (Gaur: ¶083). It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to combine perform verification using a source indicated in the request of Gaur with the methods and systems of Tank resulting in verify APIs by using its source. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of “improves microservice deployment and inter-operation by providing automated microservice trust management for microservice deployments”, (Gaur: ¶015). Regarding Claim 18, Tank fails to teach: perform verification using a secret code included in the request. However, Gaur teaches: “The microservice trust token operates as a container identifier”, (Gaur: ¶023), “the microservice trust token is passed. Prior to honoring the request, the TTL, validity of the request, and requested services are evaluated against the committed/valid entries within the distributed microservices trust ledger”, (Gaur: ¶024), “the process 500 validates the received relationship trust token with local microservices trust ledger entries to determine whether the received run-time inter-operation request may be granted or denied”, (Gaur: ¶083). It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to combine perform verification using a secret code included in the request of Gaur with the methods and systems of Tank resulting in verify APIs by using its source. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of “improves microservice deployment and inter-operation by providing automated microservice trust management for microservice deployments”, (Gaur: ¶015). Conclusion Any inquiry concerning this communication or earlier communications from the examiner should be directed to SHIHAB ALAM whose telephone number is (571)272-8705. The examiner can normally be reached Mon - Fri 7:30am-5pm. 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, Bradley Teets can be reached at (571) 272-3338. 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. /S.A./Examiner, Art Unit 2197 /JOANNE G MACASIANO/Examiner, Art Unit 2197 Application/Control Number: 18/593,475 Page 2 Art Unit: 2197 Application/Control Number: 18/593,475 Page 3 Art Unit: 2197 Application/Control Number: 18/593,475 Page 4 Art Unit: 2197 Application/Control Number: 18/593,475 Page 5 Art Unit: 2197 Application/Control Number: 18/593,475 Page 6 Art Unit: 2197 Application/Control Number: 18/593,475 Page 7 Art Unit: 2197 Application/Control Number: 18/593,475 Page 8 Art Unit: 2197 Application/Control Number: 18/593,475 Page 9 Art Unit: 2197 Application/Control Number: 18/593,475 Page 10 Art Unit: 2197 Application/Control Number: 18/593,475 Page 11 Art Unit: 2197 Application/Control Number: 18/593,475 Page 12 Art Unit: 2197 Application/Control Number: 18/593,475 Page 13 Art Unit: 2197 Application/Control Number: 18/593,475 Page 14 Art Unit: 2197 Application/Control Number: 18/593,475 Page 15 Art Unit: 2197 Application/Control Number: 18/593,475 Page 16 Art Unit: 2197 Application/Control Number: 18/593,475 Page 17 Art Unit: 2197 Application/Control Number: 18/593,475 Page 18 Art Unit: 2197 Application/Control Number: 18/593,475 Page 19 Art Unit: 2197 Application/Control Number: 18/593,475 Page 20 Art Unit: 2197 Application/Control Number: 18/593,475 Page 21 Art Unit: 2197 Application/Control Number: 18/593,475 Page 22 Art Unit: 2197 Application/Control Number: 18/593,475 Page 23 Art Unit: 2197 Application/Control Number: 18/593,475 Page 24 Art Unit: 2197 Application/Control Number: 18/593,475 Page 25 Art Unit: 2197 Application/Control Number: 18/593,475 Page 26 Art Unit: 2197 Application/Control Number: 18/593,475 Page 27 Art Unit: 2197 Application/Control Number: 18/593,475 Page 28 Art Unit: 2197 Application/Control Number: 18/593,475 Page 29 Art Unit: 2197 Application/Control Number: 18/593,475 Page 30 Art Unit: 2197 Application/Control Number: 18/593,475 Page 31 Art Unit: 2197 Application/Control Number: 18/593,475 Page 32 Art Unit: 2197
Prosecution Insights