DETAILED ACTION
Claims 1-20 are pending in the current application.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Objections
Claim 20 is objected to because of the following informalities: it recites in lines 5-6 “the second navigation event” and believed this is supposed to “the first navigation event”. Appropriate correction is required.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 1-6, 11-14 and 19-20 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-4 and 8 of U.S. Patent No. US 12,061,918 B2. Although the claims at issue are not identical, they are not patentably distinct from each other as the claims in application 18/794136 are merely a broader description of and recite essentially the same subject matter seen in US Patent 12,061,918 B2 as the species in that case will anticipate the genus.
Application 18/794136
US Patent 12,061,918 B2
1. A method, comprising: parsing, in a shell application of a web application, a uniform resource locator (URL) for the web application into a first route label and unmatched portions;
1. A method, comprising: parsing, in a shell application of a web application, a uniform resource locator (URL) for the web application into a first route label and unmatched portions;
loading, in the shell application, a first micro front end (MFE) of the webpage application based on the first route label;
loading, in the shell application, a first micro front end (MFE) nested in the shell application based on the first route label;
sending, by the shell application, the unmatched portions to the first MFE; and
sending, by the shell application, the unmatched portions to the first MFE;
loading, by the first MFE, a second MFE nested in the first MFE, wherein the second MFE and the shell application are agnostic to one another.
loading, by the first MFE, a second MFE nested in the first MFE using a second route label corresponding to the second MFE determined from the unmatched portions, wherein loading the second MFE comprises loading an active second-level MFE tab and one or more inactive second-level MFE tabs;
4. The method of claim 3, wherein the first MFE is agnostic to the third MFE, and the shell application is agnostic to the second and third MFEs.
in response to receiving user input to activate an inactive second-level MFE tab of the one or more inactive second-level MFE tabs, deactivating the active second-level MFE tab; generating, in the second MFE, a navigation event to a new URL specified by the activated second-level MFE tab; sending, by the second MFE, the navigation event to the first MFE; sending, by the first MFE, the navigation event to the shell application; and navigating, in the shell application, to the new URL
2. The method of claim 1, wherein loading the second MFE comprises loading the second MFE using a second route label, the second route label being based on the unmatched portions.
1. A method, comprising:….
loading, by the first MFE, a second MFE nested in the first MFE using a second route label corresponding to the second MFE determined from the unmatched portions, wherein loading the second MFE comprises loading an active second-level MFE tab and one or more inactive second-level MFE tabs;
3. The method of claim 1, further comprising: generating, in the second MFE, a navigation event in response to activation of a link in the second MFE, the navigation event identifying the link; sending, by the second MFE, the navigation event to the first MFE; sending, by the first MFE, the navigation event to the shell application; and navigating, in the shell application, to a new URL based on the link
1. A method, comprising: …
in response to receiving user input to activate an inactive second-level MFE tab of the one or more inactive second-level MFE tabs, deactivating the active second-level MFE tab; generating, in the second MFE, a navigation event to a new URL specified by the activated second-level MFE tab; sending, by the second MFE, the navigation event to the first MFE; sending, by the first MFE, the navigation event to the shell application; and navigating, in the shell application, to the new URL
4. The method of claim 3, further comprising: parsing, in the shell application, the new URL into an updated first route label and new unmatched portions; loading, in the shell application, the first MFE based on the updated first route label; sending, by the shell application, the new unmatched portions to the first MFE; and loading, by the first MFE, a third MFE nested in the first MFE, wherein the third MFE and the shell application are agnostic to one another.
2. The method of claim 1, further comprising: parsing, in the shell application, the new URL into an updated first route label and new unmatched portions; loading, in the shell application, the first MFE based on the updated first route label; sending, by the shell application, the new unmatched portions to the first MFE; and loading, by the first MFE, a third MFE nested in the first MFE, wherein the third MFE and the shell application are agnostic to one another.
5. The method of claim 1, further comprising loading, in the shell application, a third MFE based on one of the first route label or a third route label that is parsed from the URL
2. The method of claim 1, further comprising: parsing, in the shell application, the new URL into an updated first route label and new unmatched portions; loading, in the shell application, the first MFE based on the updated first route label; sending, by the shell application, the new unmatched portions to the first MFE; and loading, by the first MFE, a third MFE nested in the first MFE, wherein the third MFE and the shell application are agnostic to one another.
3. The method of claim 1, further comprising: sending, by the first MFE, remaining unmatched portions to the second MFE; and loading, by the second MFE, a third MFE nested in the second MFE using a third route label corresponding to the third MFE determined from the remaining unmatched portions.
6. The method of claim 1, further comprising loading, in the first MFE, a third MFE nested in the first MFE separate from the second MFE, wherein the third MFE and the shell application are agnostic to one another.
2. The method of claim 1, further comprising: parsing, in the shell application, the new URL into an updated first route label and new unmatched portions; loading, in the shell application, the first MFE based on the updated first route label; sending, by the shell application, the new unmatched portions to the first MFE; and loading, by the first MFE, a third MFE nested in the first MFE, wherein the third MFE and the shell application are agnostic to one another.
19. A system, comprising: one or more processors; memory communicatively coupled to the one or more processors, the memory storing instructions which, when executed by the one or more processors, cause the one or more processors to: provide a shell application configured to: navigate to a uniform resource locator (URL) by:
8. A system, comprising: one or more processors; memory communicatively coupled to the one or more processors, the memory storing instructions which, when executed by the one or more processors, cause the one or more processors to: provide a shell application configured to: navigate to a uniform resource locator (URL) by:
parsing the URL into a first route label and unmatched portions, the first route label corresponding to a first micro front end (MFE);
parsing the URL into a first route label and unmatched portions, the first route label corresponding to a first micro front end (MFE);
loading the first MFE based on the first route label; and
loading the first MFE based on the first route label; and
sending the unmatched portions to the first MFE;
sending the unmatched portions to the first MFE;
provide the first MFE configured to: receive the unmatched portions from the shell application; determine a second route label from the unmatched portions, the second route label corresponding to a second MFE; load the second MFE based on the second route labels; and provide the second MFE;
provide the first MFE configured to: receive the unmatched portions from the shell application; determine a second route label from the unmatched portions, the second route label corresponding to a second MFE; load the second MFE based on the second route label, wherein loading the second MFE comprises loading an active second-level MFE tab and one or more inactive second-level MFE tabs; and provide the second MFE configured to: in response to receiving user input to activate an inactive second-level MFE tab of the one or more inactive second-level MFE tabs, deactivate the active second-level MFE tab; generate a navigation event to a new URL specified by the activated second-level MFE tab; and send the navigation event to the first MFE; the first MFE is further configured to, in response to receiving the navigation event from the second MFE, send the navigation event to the shell application; and the shell application is further configured to, in response to receiving the navigation event from the first MFE, navigate to the new URL based on the navigation event;
wherein the shell application, the first MFE, and the second MFE together are configured to provide a web application that can be run in a browser; and
wherein the shell application, the first MFE, and the second MFE together are configured to provide a web application that can be run in a browser; and
wherein the shell application is agnostic to the second MFE and the second MFE is agnostic to the shell application.
wherein the shell application is agnostic to the second MFE and the second MFE is agnostic to the shell application
Where claims 11-14 and 20 of the application include similar limitation to claims 1, 3, 4 and 6 of the application above and thus rejected under similar reasoning.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-2, 5-6 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Tank et al. (Pub. No. US 2021/0248205 A1), in view of Benge et al. (Pub. No. US 2018/0074795 A1) and further in view of Martin (Pub. No. US 2013/0218999 A1).
As to claim 1, Tank discloses a method, comprising: loading, in the shell application, a first micro front end (MFE) of the webpage application based on the first route label (Tank [0014] lines 5-10 and [0075] lines 3-11; which shows a request for providing/loading a micro frontend tied to a web application based on indicator including any kind of identifier of locator, viewed as a type of route label information where it is seen specifically disclosed below the specifics of shell application of a web application);
sending, by the shell application, the unmatched portions to the first MFE (Tank [0025] lines 1-10 and [0065] lines 14-21; which shows that the data object can be plurality of micro frontend and that the data object can include data structure and being able to load/send into that structure further data objects, thus viewed as sending to on MFE further data, where it is seen specifically disclosed below the specifics of the unmatched data portions); and
loading, by the first MFE, a second MFE nested in the first MFE, wherein the second MFE and the shell application are agnostic to one another (Tank [0025] lines 1-14, [0065] lines 14-21 and [0066] lines 1-8; which shows the ability to load/install within a data object structure, viewed a first MFE, another data object viewed as including another/second MFE where it is seen that each micro frontend is platform and language agnostic thus viewed as it being agnostic to the shell application).
Tank does not specifically disclose parsing, in a shell application of a web application, a uniform resource locator (URL) for the web application.
However, Benge discloses parsing, in a shell application of a web application, a uniform resource locator (URL) for the web application (Benge [0041] lines 7-15 and [0045] 1-7; which shows an end user, viewed as including a shell application is able to use the management system to parse a URL).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date to incorporate the teachings of Benge showing parsing a URL, into the application systems of Tank, for the purpose of increasing usability by being able to identify specific information based on the provided URL information, as taught by Benge [0041] lines 7-15.
Tank as modified by Benge does not specifically disclose parsing a URL into a first route label and unmatched portions.
However, Martin discloses parsing a URL into a first route label and unmatched portions (Martin [0344] lines 14-21 and claim 1; which shows the ability to parse the URL for known and unknown information includes URL, IP addresses viewed as types of route labels).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date to incorporate the teachings of Martin showing the parsing URL for known and unknow information into the parsing of URL of Tank as modified by Benge for the purpose of increasing usability by being able to determine the relevance of the URL, as taught by Martin [0344] lines 5-21.
As to claim 2, Tank discloses wherein loading the second MFE comprises loading the second MFE using a second route label, the second route label being based on the unmatched portions (Tank [0014] lines 5-10, [0025] lines 1-14, [0065] lines 14-21 and [0066] lines 1-8 and [0075] lines 3-11; which shows a request for providing/loading a micro frontend tied to a web application based on indicator including any kind of identifier of locator, viewed as a type of route label information, where there can be plurality of micro frontends loaded, where it is seen specifically disclosed above the specifics of both known and unknown information including URL and IP address viewed as route labels thus viewed as being able to use the unmatched/unknown information to load MFE).
As to claim 5, Tank discloses loading, in the shell application, a third MFE based on one of the first route label or a third route label that is parsed from the URL (Tank [0014] lines 5-10 and [0075] lines 3-11; which shows a request for providing/loading a micro frontend tied to a web application based on indicator including any kind of identifier of locator, viewed as a type of route label information where this can be done for a plurality of micro-frontends thus viewed for including a third one and is not limited to what identifier/locator is used thus viewed could include a first route label or a third route label where it is seen specifically disclosed above the specifics of shell application of a web application and the specifics of the determination of the route information).
As to claim 6, Tank discloses loading, in the first MFE, a third MFE nested in the first MFE separate from the second MFE, wherein the third MFE and the shell application are agnostic to one another (Tank [0025] lines 1-14, [0065] lines 14-21 and [0066] lines 1-8; which shows the ability to load/install within a data object structure, viewed a first MFE, another data objects viewed as including another/third MFE where it is viewed as separate/different from the second MFE and where it is seen that each micro frontend is platform and language agnostic thus viewed as it being agnostic to the shell application seen specifically disclosed above).
As to claim 19, Tank discloses a system, comprising: one or more processors; memory communicatively coupled to the one or more processors, the memory storing instructions which, when executed by the one or more processors, cause the one or more processors to (Tank [0030] lines 1-8):
loading the first MFE based on the first route label (Tank [0014] lines 5-10 and [0075] lines 3-11; which shows a request for providing/loading a micro frontend tied to a web application based on indicator including any kind of identifier of locator, viewed as a type of route label information); and
sending the unmatched portions to the first MFE (Tank [0025] lines 1-10 and [0065] lines 14-21; which shows that the data object can be plurality of micro frontend and that the data object can include data structure and being able to load/send into that structure further data objects, thus viewed as sending to on MFE further data, where it is seen specifically disclosed below the specifics of the unmatched data portions);
provide the first MFE configured to: receive the unmatched portions from the shell application (Tank [0025] lines 1-10 and [0065] lines 14-21; which shows that the data object can be plurality of micro frontend and that the data object can include data structure and being able to load/send into that structure further data objects, thus viewed as sending to on MFE further data thus being able to receive the, where it is seen specifically disclosed below the specifics of the unmatched data portions and the specifics of the second route information);
determine a second route label from the unmatched portions, the second route label corresponding to a second MFE (Tank [0014] lines 5-10, [0025] lines 1-10, [0065] lines 14-21 and [0075] lines 3-11; which shows that the data object can be plurality of micro frontend and that the data object can include data structure and being able to load/send into that structure further data objects where indicators, viewed as types of route labels, are used for loading MFE, viewed as including second MFE,, thus viewed as sending to on MFE further data, where it is seen specifically disclosed above the specifics of the unmatched data portions);
load the second MFE based on the second route labels (Tank [0014] lines 5-10, [0025] lines 1-10, [0065] lines 14-21, [0066] lines 1-8 and [0075] lines 3-11; which shows the ability to load/install within a data object structure, viewed a first MFE, another data object viewed as including another/second MFE where as seen able that the MFEs can be provided/loaded based on an indicator, viewed as the type of route labels information); and
provide the second MFE; wherein the shell application, the first MFE, and the second MFE together are configured to provide a web application that can be run in a browser (Tank [0025] lines 1-14, [0051] lines 3-5, [0065] lines 14-21, [0066] lines 1-8 and [0088] lines 1-6; which shows the ability to load/install within a data object structure, viewed a first MFE, another data object viewed as including another/second MFE thus are viewed configured together to provide information where the MFEs can provide applications that can execute on a web browser); and
wherein the shell application is agnostic to the second MFE and the second MFE is agnostic to the shell application (Tank [0025] lines 1-14; where it is seen that each micro frontend is platform and language agnostic thus viewed as it being agnostic to the shell application).
Tank does not specifically disclose providing a shell application configured to: navigate to a uniform resource locator (URL) by: parsing the URL
However, Benge discloses providing a shell application configured to: navigate to a uniform resource locator (URL) by: parsing the URL (Benge [0041] lines 7-15 and [0045] 1-7; which shows an end user, viewed as including a shell application is able to use the management system to parse a URL and thus viewed as being navigated to the URL for parsing).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date to incorporate the teachings of Benge showing parsing a URL, into the application systems of Tank, for the purpose of increasing usability by being able to identify specific information based on the provided URL information, as taught by Benge [0041] lines 7-15
Tank as modified by Benge does not specifically disclose parsing the URL into a first route label and unmatched portions, the first route label corresponding to a first micro front end (MFE).
However, Martin discloses parsing the URL into a first route label and unmatched portions, the first route label corresponding to a first micro front end (MFE) (Martin [0344] lines 14-21 and claim 1; which shows the ability to parse the URL for known and unknown information includes URL, IP addresses viewed as types of route labels, where it is seen specifically disclosed above the association of a type of route label with a first MFE).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date to incorporate the teachings of Martin showing the parsing URL for known and unknow information into the parsing of URL of Tank as modified by Benge for the purpose of increasing usability by being able to determine the relevance of the URL, as taught by Martin [0344] lines 5-21
Claims 3 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Tank, Benge and Martin as applied to claims 1 and 19 above, and further in view of Vihar et al. (Pub. 2022/0166839 A1).
As to claim 3, Tank discloses generating, in the second MFE, a navigation event in response to activation of a link in the second MFE, the navigation event identifying the link (Tank [0057] lines 4-12; which shows the use of a link that corresponds to a particular MFE and associated retriever/navigation actions, which in light of above can be viewed as the second MFE).
Tank does not specifically disclose navigating, in the shell application, to a new URL based on the link.
However, Benge discloses navigating, in the shell application, to a new URL based on the link (Benge [0039] lines 19-22, [0041] lines 7-15 and [0045] 1-7; which shows an end user, viewed as including a shell application is able to use the management system to parse a URL that is received as part of a request/link directed to a URL where it is seen specifically disclosed below the specifics of the generated/new request thus viewed that this new request can lead to a new/different URL).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date to incorporate the teachings of Benge showing parsing a URL, into the application systems of Tank, for the purpose of increasing usability by being able to identify specific information based on the provided URL information, as taught by Benge [0041] lines 7-15
Tank as modified by Benge and Martin does not specifically disclose sending, by the second MFE, the navigation event to the first MFE; sending, by the first MFE, the navigation event to the shell application.
However, Vihar discloses sending, by the second MFE, the navigation event to the first MFE; sending, by the first MFE, the navigation event to the shell application (Vihar [0028] lines 1-5; which shows the ability to generate navigation events that allow for navigation across micro-frontend thus viewed as being able to navigate to a first MFE and thus in light of above disclosed teaching can arrive at the shell application)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date to incorporate the teachings of Vihar showing the navigation across micro frontends, into the micro frontends of Tank as modified by Benge and Martin for the purpose of increasing usability by being able to allow an application to navigate across plurality of micro frontends thus increasing functionality, as taught by Vihar [0028] lines 1-5.
As to claim 20, Tank discloses wherein: the second MFE is further configured to: generate a first navigation event in response to second MFE link in the second MFE being activated (Tank [0057] lines 4-12; which shows the use of a link that corresponds to a particular MFE and associated retriever/navigation actions, which in light of above can be viewed as the second MFE).
Tank does not specifically disclose the shell application is further configured to: receive the first navigation event from the first MFE; and in response to receiving the first navigation event, navigate to a new URL based on the first navigation event.
However, Benge disclose the shell application is further configured to: receive the first navigation event from the first MFE; and in response to receiving the first navigation event, navigate to a new URL based on the first navigation event (Benge [0039] lines 19-22, [0041] lines 7-15 and [0045] 1-7; which shows an end user, viewed as including a shell application is able to use the management system to parse a URL that is received as part of a request/link/navigation directed to a URL where it is seen specifically disclosed below the specifics of the generated/new request thus viewed that this new request can lead to a new/different/updated URL).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date to incorporate the teachings of Benge showing parsing a URL, into the application systems of Tank, for the purpose of increasing usability by being able to identify specific information based on the provided URL information, as taught by Benge [0041] lines 7-15.
Tank as modified by Benge and Martin does not specifically disclose in response to the first navigation event being generated send the second navigation event to the first MFE; the first MFE is further configured to in response to receiving the first navigation event from the second MFE, send the first navigation event to the sell application.
However, Vihar discloses in response to the first navigation event being generated send the second navigation event to the first MFE; the first MFE is further configured to in response to receiving the first navigation event from the second MFE, send the first navigation event to the sell application (Vihar [0028] lines 1-5; which shows the ability to generate navigation events that allow for navigation across micro-frontend thus viewed as being able to navigate between MFEs viewed as from a second to a first MFE and thus in light of above disclosed teaching can arrive at the shell application connected to the MFE).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date to incorporate the teachings of Vihar showing the navigation across micro frontends, into the micro frontends of Tank as modified by Benge and Martin for the purpose of increasing usability by being able to allow an application to navigate across plurality of micro frontends thus increasing functionality, as taught by Vihar [0028] lines 1-5
Claim 4 is rejected under 35 U.S.C. 103 as being unpatentable over Tank, Benge and Martin, Vihar as applied to claim 3 above, and further in view of Ray et al. (Pub. No. US 2020/0097611 A1)
As to claim 4, Tank discloses loading, in the shell application, the first MFE based on the updated first route label (Tank [0014] lines 5-10 and [0075] lines 3-11; which shows a request for providing/loading a micro frontend tied to a web application based on indicator including any kind of identifier of locator, viewed as a type of route label information where it is seen specifically disclosed above the specifics of shell application of a web application where it can be seen specifically disclosed below the specifics of the updated route label);
sending, by the shell application, the new unmatched portions to the first MFE (Tank [0025] lines 1-10 and [0065] lines 14-21; which shows that the data object can be plurality of micro frontend and that the data object can include data structure and being able to load/send into that structure further data objects, thus viewed as sending to on MFE further data, where it is seen specifically disclosed above the specifics of the unmatched data portions and where it is seen specifically disclosed below the specifics of a new/updated URL that would have this new unmatched portion); and
loading, by the first MFE, a third MFE nested in the first MFE, wherein the third MFE and the shell application are agnostic to one another (Tank [0025] lines 1-14, [0065] lines 14-21 and [0066] lines 1-8; which shows the ability to load/install within a data object structure, viewed a first MFE, another data object viewed as including another/third MFE where it is seen that each micro frontend is platform and language agnostic thus viewed as it being agnostic to the shell application).
Tank as modified by Benge, Martin and Vihar does not specifically disclose parsing, in the shell application, the new URL into an updated first route label and new unmatched portions.
However, Ray discloses parsing, in the shell application, the new URL into an updated first route label and new unmatched portions (Ray [0059] lines 8-12 and [0060] lines 1-1-3; which shows the link used in updating, creating a new URL with an updated route information and with the new/updated URL can include new unmatched portion).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date to incorporate the teachings of Ray of updating URL, into the URLs of Tank as modified by Benge, Martin and Vihar for the purpose of increasing usability by being able to update the URL without forced navigation, as taught by Ray [0059] lines 8-12.
Claim 7 is rejected under 35 U.S.C. 103 as being unpatentable over Tank, Benge and Martin as applied to claim 1 above, and further in view of Levi et al. (Pub. No. US 2015/0347616 A1).
As to claim 7, Tank discloses wherein loading the second MFE nested in the first MFE further comprises: loading, in the first MFE, a first MFE tab associated with the second MFE (Tank [0014] lines 5-10 and [0075] lines 3-11 and [0080] lines 1-15; which shows the ability to load/call a plurality of micro frontend in a browser thus acting as types of tab/page area in the browser where as seen specifically disclosed above the specifics of a second MFE within the first MFE); and
loading, in the first MFE, a second MFE tab associated with a third MFE (Tank [0014] lines 5-10, [0025] lines 1-14, [0065] lines 14-21, [0066] lines 1-8, [0075] lines 3-11 and [0080] lines 1-15; which shows the ability to load/call a plurality of micro frontend in a browser thus acting as types of tab/page area in the browser where as seen specifically disclosed above the nested MFE can be the specifics a third MFE).
Tank as modified by Benge and Martin does not specifically disclose where a tab is an active tab and a second tab as an inactive tab.
However, Levi discloses where a tab is an active tab and a second tab as an inactive tab (Levi [0032] lines 1-10 and [0047] lines 21-30; which is able to show being able to have loaded/installed a plurality of tabs in the web browser associated with web application that can be active or inactive, where it is seen specifically disclosed above being able to nest with one MFE another MFE so viewed as being able to related to a third MFE as well).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date to incorporate the teachings of Levi showing the active and inactive tabs into the tab/windows of Tank as modified by Benge and Martin for the purpose of increasing usability by being able to switch between active and inactive tabs making them active for use, as taught by Levi [0047] lines 21-30.
Claim 8 is rejected under 35 U.S.C. 103 as being unpatentable over Tank, Benge, Martin and Levi as applied to claim 7 above, and further in view of Vihar et al. (Pub. 2022/0166839 A1).
As to claim 8 Tank does not specifically disclose, however, Benge discloses navigating, in the shell application, to the new URL (Benge [0039] lines 19-22, [0041] lines 7-15 and [0045] 1-7; which shows an end user, viewed as including a shell application is able to use the management system to parse a URL that is received as part of a request/link directed to a URL where it is seen specifically disclosed below the specifics of the generated/new request thus viewed that this new request can lead to a new/different URL).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date to incorporate the teachings of Benge showing parsing a URL, into the application systems of Tank, for the purpose of increasing usability by being able to identify specific information based on the provided URL information, as taught by Benge [0041] lines 7-15.
Tank as modified by Benge and Martin do not specifically disclose in response to activating the second MFE tab, generating, in the first MFE, a navigation event to a new URL specified by the second MFE tab.
However, Levi discloses in response to activating the second MFE tab, generating, in the first MFE, a navigation event to a new URL specified by the second MFE tab (Levi [0047] lines 4-13 and 21-30; which shows an event can activate a previously inactive tab that can navigate to a different/new URL, where in light of above disclosed information can be viewed as the second MFE tab).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date to incorporate the teachings of Levi showing the active and inactive tabs into the tab/windows of Tank as modified by Benge and Martin for the purpose of increasing usability by being able to switch between active and inactive tabs making them active for use, as taught by Levi [0047] lines 21-30.
Tank as modified by Benge, Martin and Levi do not specifically disclose sending, by the first MFE, the navigation event to the shell application.
However, Vihar discloses sending, by the first MFE, the navigation event to the shell application (Vihar [0028] lines 1-5; which shows the ability to generate navigation events that allow for navigation across micro-frontend thus viewed as being able to navigate to a first MFE and thus in light of above disclosed teaching can arrive at the shell application).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date to incorporate the teachings of Vihar showing the navigation across micro frontends, into the micro frontends of Tank as modified by Benge, Martin and Levi for the purpose of increasing usability by being able to allow an application to navigate across plurality of micro frontends thus increasing functionality, as taught by Vihar [0028] lines 1-5.
Claims 9-10 are rejected under 35 U.S.C. 103 as being unpatentable over Tank, Benge, Martin, Levi and Vihar as applied to claim 8 above, and further in view of Ray et al. (Pub. No. US 2020/0097611 A1)
As to claim 9, Tank discloses loading, in the shell application, the first MFE based on the updated first route label (Tank [0014] lines 5-10 and [0075] lines 3-11; which shows a request for providing/loading a micro frontend tied to a web application based on indicator including any kind of identifier of locator, viewed as a type of route label information where it is seen specifically disclosed above the specifics of shell application of a web application where it can be seen specifically disclosed below the specifics of the updated/new route label);
sending, by the shell application, the new unmatched portions to the first MFE (Tank [0025] lines 1-10 and [0065] lines 14-21; which shows that the data object can be plurality of micro frontend and that the data object can include data structure and being able to load/send into that structure further data objects, thus viewed as sending to on MFE further data, where it is seen specifically disclosed above the specifics of the unmatched data portions and where it is seen specifically disclosed below the specifics of a new/updated URL that would have this new unmatched portion); and
loading, in the first MFE, the third MFE nested in the first MFE based on a route label determined from the new unmatched portions, wherein the third MFE and the shell application are agnostic to one another (Tank [0014] lines 5-10, [0025] lines 1-14, [0065] lines 14-21 and [0066] lines 1-8 and [0075] lines 3-11; which shows the ability to load/install within a data object structure, viewed a first MFE, another data object viewed as including another/third MFE where it is seen that each micro frontend is platform and language agnostic thus viewed as it being agnostic to the shell application where the providing/loading a micro frontend tied to a web application based on indicator including any kind of identifier of locator, viewed as a type of route label information, where there can be plurality of micro frontends loaded, where it is seen specifically disclosed above the specifics of both known and unknown information including URL and IP address viewed as route labels thus viewed as being able to use the unmatched/unknown information to load MFE).
Tank as modified by Benge, Martin, Levi and Vihar do not specifically disclose parsing, in the shell application, the new URL into an updated first route label and new unmatched portions.
However, Ray discloses parsing, in the shell application, the new URL into an updated first route label and new unmatched portions (Ray [0059] lines 8-12 and [0060] lines 1-1-3; which shows the link used in updating, creating a new URL with an updated route information and with the new/updated URL can include new unmatched portion).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date to incorporate the teachings of Ray of updating URL, into the URLs of Tank as modified by Benge, Martin, Levi and Vihar for the purpose of increasing usability by being able to update the URL without forced navigation, as taught by Ray [0059] lines 8-12.
As to claim 10, Tank discloses loading, in the first MFE, the first MFE tab as the inactive tab and the second MFE tab as the active tab (Tank [0014] lines 5-10 and [0075] lines 3-11 and [0080] lines 1-15; which shows the ability to load/call a plurality of micro frontend in a browser thus acting as types of tab/page area in the browser where as seen specifically disclosed above the specifics of a second MFE within the first MFE and seen specifically disclosed above that a tab can be determined to be active or an inactive tab and being able to change its activity state).
Claims 11 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Tank et al. (Pub. No. US 2021/0248205 A1), and further in view of Martin (Pub. No. US 2013/0218999 A1).
As to claim 11, Tank discloses a method, comprising: receiving, at a first micro front end (MFE), first uniform resource locator (URL) data (Tank [0014] lines 5-10 and [0075] lines 3-11; which shows a request for providing/loading a micro frontend tied to a web application based on indicator including any kind of identifier of locator, viewed as a type of route label information where it is seen specifically disclosed below the specifics of the route information being part of parsed URL information);
determining, in the first MFE, a first route label for a second MFE based on the first URL data (Tank [0025] lines 1-10 and [0065] lines 14-21; which shows that the data object can be plurality of micro frontend and that the data object can include data structure and being able to load/send into that structure further data objects, thus viewed as sending to on MFE further data, where it is seen specifically disclosed below the specifics of the parsed route data of URL); and
loading, by the first MFE, the second MFE nested in the first MFE based on the first route label, wherein the second MFE is agnostic to a parent application of the first MFE and the parent application is agnostic to the second MFE (Tank [0025] lines 1-14, [0065] lines 14-21 and [0066] lines 1-8; which shows the ability to load/install within a data object structure, viewed a first MFE, another data object viewed as including another/second MFE where it is seen that each micro frontend is platform and language agnostic thus viewed as it being agnostic to the parent/host application).
Tank does not specifically disclose a first uniform resource locator (URL) data parsed from a URL
However, Martin discloses a first uniform resource locator (URL) data parsed from a URL (Martin [0344] lines 14-21 and claim 1; which shows the ability to parse the URL for known and unknown information includes URL, IP addresses viewed as types of route labels).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date to incorporate the teachings of Martin showing the parsing URL for known and unknow information into the parsing of URL of Tank as modified by Benge for the purpose of increasing usability by being able to determine the relevance of the URL, as taught by Martin [0344] lines 5-21.
As to claim 14, Tank discloses loading, in the first MFE, a third MFE separate from the second MFE and based on one of the first route label or a second route label determined by the first MFE from the first URL data (Tank [0014] lines 5-10, [0025] lines 1-14, [0065] lines 14-21, [0066] lines 1-8 and [0075] lines 3-11; Tank; which shows the ability to load/install within a data object structure, viewed a first MFE, another data objects viewed as including another/third MFE where it is viewed as separate/different from the second MFE and where a request for providing/loading a micro frontend tied to a web application based on indicator including any kind of identifier of locator, viewed as a type of route label information where this can be done for a plurality of micro-frontends thus viewed for including a third one where it is seen specifically disclosed above being able to determine the route label from the URL data).
Claims 12-13 are rejected under 35 U.S.C. 103 as being unpatentable over Tank and Martin as applied to claim 11 above, and further in view of Vihar et al. (Pub. 2022/0166839 A1) and of Ray et al. (Pub. No. US 2020/0097611 A1).
As to claim 12, Tank discloses generating, in the second MFE, a navigation event in response to activation of a link, the navigation event identifying the link sending, by the second MFE, the navigation event to the first MFE (Tank [0057] lines 4-12; which shows the use of a link that corresponds to a particular MFE and associated retriever/navigation actions, which in light of above can be viewed as the second MFE).
Tank as modified by Martin do not specifically disclose generating, in the second MFE, a navigation event in response to activation of a link to a new URL in the second MFE, the navigation event identifying the link; sending, by the second MFE, the navigation event to the first MFE; sending, by the first MFE, the navigation event to the parent application.
However, Vihar discloses generating, in the second MFE, a navigation event in response to activation of a link, the navigation event identifying the link; sending, by the second MFE, the navigation event to the first MFE; sending, by the first MFE, the navigation event to the parent application (Vihar [0028] lines 1-5; which shows the ability to generate navigation events that allow for navigation across micro-frontend thus viewed as being able to navigate to a first MFE from another/second MFE and thus in light of above disclosed teaching can arrive at the parent/host application in light of the navigation/link information)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date to incorporate the teachings of Vihar showing the navigation across micro frontends, into the micro frontends of Tank as modified by Martin for the purpose of increasing usability by being able to allow an application to navigate across plurality of micro frontends thus increasing functionality, as taught by Vihar [0028] lines 1-5.
Tank as modified by Martin and Vihar do not specifically disclose the specifics of the activation of a link to a new URL in the second MFE.
However, Ray disclose the specifics of the activation of a link to a new URL in the second MFE (Ray [0059] lines 8-12 and [0060] lines 1-1-3; which shows the link used in updating, creating a new URL with an updated route information and with the new/updated URL can include new unmatched portion, where it is seen specifically disclosed above the specifics of the second MFE).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date to incorporate the teachings of Ray of updating URL, into the URLs of Tank as modified by Martin and Vihar for the purpose of increasing usability by being able to update the URL without forced navigation, as taught by Ray [0059] lines 8-12.
As to claim 13, Tank discloses receiving from the parent application, in the first MFE, second uniform resource locator (URL) data (Tank [0014] lines 5-10 and [0075] lines 3-11; which shows a request for providing/loading a micro frontend tied to a web application based on indicator including any kind of identifier of locator, viewed as a type of route label information where it is seen specifically disclosed below the specifics of the route information being part of parsed URL information);
determining, in the first MFE, a second route label for a third MFE based on the second URL data (Tank [0025] lines 1-10 and [0065] lines 14-21; which shows that the data object can be plurality of micro frontend and that the data object can include data structure and being able to load/send into that structure further data objects, thus viewed as sending to on MFE further data for another/third data object, where it is seen specifically disclosed below the specifics of the parsed route data of URL); and
loading, by the first MFE, the third MFE nested in the first MFE based on the second route label, wherein the third MFE and the parent application are agnostic to one another (Tank [0025] lines 1-14, [0065] lines 14-21 and [0066] lines 1-8; which shows the ability to load/install within a data object structure, viewed a first MFE, another data object viewed as including another/third MFE where it is seen that each micro frontend is platform and language agnostic thus viewed as it being agnostic to the parent/host application).
Tank does not specifically disclose second uniform resource locator (URL) data parsed from the new URL.
However, Martin discloses second uniform resource locator (URL) data parsed from the new URL (Martin [0344] lines 14-21 and claim 1; which shows the ability to parse the URL for known and unknown information includes URL, IP addresses viewed as types of route labels, where it is seen specifically disclosed above the specifics of the new URL).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date to incorporate the teachings of Martin showing the parsing URL for known and unknow information into the parsing of URL of Tank as modified by Benge for the purpose of increasing usability by being able to determine the relevance of the URL, as taught by Martin [0344] lines 5-21.
Claim 15 is rejected under 35 U.S.C. 103 as being unpatentable over Tank and Martin as applied to claim 11 above, and further in view of Levi et al. (Pub. No. US 2015/0347616 A1).
As to claim 15, Tank discloses wherein loading the second MFE nested in the first MFE further comprises loading a first MFE tab associated with the second MFE (Tank [0014] lines 5-10 and [0075] lines 3-11 and [0080] lines 1-15; which shows the ability to load/call a plurality of micro frontend in a browser thus acting as types of tab/page area in the browser where as seen specifically disclosed above the specifics of a second MFE within the first MFE); and
loading a second MFE tab associated with a third MFE (Tank [0014] lines 5-10, [0025] lines 1-14, [0065] lines 14-21, [0066] lines 1-8, [0075] lines 3-11 and [0080] lines 1-15; which shows the ability to load/call a plurality of micro frontend in a browser thus acting as types of tab/page area in the browser where as seen specifically disclosed above the nested MFE can be the specifics a third MFE).
Tank as modified by Martin do not specifically disclose where a tab is an active tab and a second tab as an inactive tab.
However, Levi discloses where a tab is an active tab and a second tab as an inactive tab (Levi [0032] lines 1-10 and [0047] lines 21-30; which is able to show being able to have loaded/installed a plurality of tabs in the web browser associated with web application that can be active or inactive, where it is seen specifically disclosed above being able to nest with one MFE another MFE so viewed as being able to related to a third MFE as well).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date to incorporate the teachings of Levi showing the active and inactive tabs into the tab/windows of Tank as modified by Martin for the purpose of increasing usability by being able to switch between active and inactive tabs making them active for use, as taught by Levi [0047] lines 21-30.
Claims 16-18 are rejected under 35 U.S.C. 103 as being unpatentable over Tank, Martin and Levi as applied to claim 15 above, and further in view of Vihar et al. (Pub. 2022/0166839 A1)
As to claim 16, Tank as modified by Martin does not specifically disclose, however, Levi discloses in response to activating the second MFE tab, generating, in the first MFE, a navigation event to a new URL specified by the second MFE tab (Levi [0047] lines 4-13 and 21-30; which shows an event can activate a previously inactive tab that can navigate to a different/new URL, where in light of above disclosed information can be viewed as the second MFE tab).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date to incorporate the teachings of Levi showing the active and inactive tabs into the tab/windows of Tank as modified by Martin for the purpose of increasing usability by being able to switch between active and inactive tabs making them active for use, as taught by Levi [0047] lines 21-30.
Tank as modified by Martin and Levi do not specifically disclose sending, by the first MFE, the navigation event to the parent application.
However, Vihar discloses sending, by the first MFE, the navigation event to the parent application (Vihar [0028] lines 1-5; which shows the ability to generate navigation events that allow for navigation across micro-frontend thus viewed as being able to navigate to a first MFE and thus in light of above disclosed teaching can arrive at a parent application).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date to incorporate the teachings of Vihar showing the navigation across micro frontends, into the micro frontends of Tank as modified by Martin and Levi for the purpose of increasing usability by being able to allow an application to navigate across plurality of micro frontends thus increasing functionality, as taught by Vihar [0028] lines 1-5.
As to claim 17, Tank discloses receiving from the parent application, in the first MFE, second uniform resource locator (URL) data (Tank [0014] lines 5-10 and [0075] lines 3-11; which shows a request for providing/loading a micro frontend tied to a web application based on indicator including any kind of identifier of locator, viewed as a type of route label information where it is seen specifically disclosed below the specifics of the route information being part of parsed URL information);
determining, in the first MFE, a second route label for a third MFE based on the second URL data (Tank [0025] lines 1-10 and [0065] lines 14-21; which shows that the data object can be plurality of micro frontend and that the data object can include data structure and being able to load/send into that structure further data objects, thus viewed as sending to on MFE further data for another/third data object, where it is seen specifically disclosed above the specifics of the parsed route data of URL); and
loading, by the first MFE, the third MFE nested in the first MFE based on the second route label, wherein the third MFE is agnostic to the parent application and the parent application is agnostic to the third MFE (Tank [0025] lines 1-14, [0065] lines 14-21 and [0066] lines 1-8; which shows the ability to load/install within a data object structure, viewed a first MFE, another data object viewed as including another/third MFE where it is seen that each micro frontend is platform and language agnostic thus viewed as it being agnostic to the parent application).
Tank does not specifically disclose the second uniform resource locator (URL) data parsed from the new URL.
However, Martin disclose the second uniform resource locator (URL) data parsed from the new URL (Martin [0344] lines 14-21 and claim 1; which shows the ability to parse the URL for known and unknown information includes URL, IP addresses viewed as types of route labels, where it is seen specifically disclosed above the specifics of the new URL).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date to incorporate the teachings of Martin showing the parsing URL for known and unknow information into the parsing of URL of Tank as modified by Benge for the purpose of increasing usability by being able to determine the relevance of the URL, as taught by Martin [0344] lines 5-21.
As to claim 18, Tank discloses loading, in the first MFE, the second MFE tab as the active MFE tab and the first MFE tab as the inactive tab (Tank [0014] lines 5-10 and [0075] lines 3-11 and [0080] lines 1-15; which shows the ability to load/call a plurality of micro frontend in a browser thus acting as types of tab/page area in the browser where as seen specifically disclosed above the specifics of a second MFE within the first MFE and seen specifically disclosed above that a tab can be determined to be active or an inactive tab).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to BRADFORD F WHEATON whose telephone number is (571)270-1779. The examiner can normally be reached Monday-Friday 8:00-5:00 EST.
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, Chat Do can be reached at 571-272-3721. 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.
/BRADFORD F WHEATON/Examiner, Art Unit 2193
Prosecution Insights