DETAILED ACTION
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 .
This action is in response to communications filed on 03/30/2026. Claims 1-20 are pending and have been examined.
Priority
Applicant’s claim for the benefit of a prior-filed application under 35 U.S.C. 119(e) or under 35 U.S.C. 120, 121, 365(c), or 386(c) is acknowledged.
Claim Objections
Claims 1, 11, and 20 are objected to because of the following informalities:
As per claim 1, it appears that “includes” should be replaced with “include” in line 9 (e.g. replace with “wherein the first executable parts include[[s]] a first executable part…”; note: “include” is used when the subject is plural) and in line 23 (e.g. replace with “wherein the second executable parts include[[s]] the third executable part…”). It appears that “the first URL pattern the first URL pattern” in lines 25-26 should be replaced with “the first URL pattern”.
The above similarly applies to claims 11 and 20.
Appropriate correction is required.
Response to Arguments
Previous objections not included in this action have been withdrawn in view of amendments.
Previous rejections under 35 USC 112(a) have been withdrawn in view of amendments.
Previous rejections under 35 USC 112(b) have been withdrawn in view of amendments.
Applicant's arguments filed with respect to the prior art have been fully considered but they are not persuasive.
Applicant argues in substance that Charles allegedly teaches away from the claimed limitations. However, examiner respectfully disagrees. Applicant argues that displaymanagers are not nested referring to paragraph 92 and figure 3. As noted previously, “container/component objects” are executable parts. Examiner does not rely upon the displaymanagers to teach executable parts, but it is noted that displaymanagers perform “instantiating container/component objects and reference information in the specified displays” (e.g. in paragraphs 101 and 148-149). “Instantiating” is another word for “executing”. Therefore, “container/component objects” are executable parts. It is noted that the term “executable part” does not appear anywhere in applicant’s specification. Applicant also does not describe in the remarks how “executable part” is being interpreted. The specification only states “when a user enters the URL into a browser, the first backslash would cause computer executable instructions in code441 to start the application container210. The SaaSCloud part of the URL would cause the computer executable instructions in code441 start the SaaSCloud Module container220”, etc. (e.g. in paragraph 79). The broadest reasonable interpretation of “executable part”, therefore, includes any part that can be created by a computer. Therefore, at least the “container/component objects” of Charles reads on “executable parts” (note that the section in applicant’s specification also refers to a “container” object). Moreover, Charles does not state that that components, containers and sub-components must only be 2D components as alleged by applicant. Applicant appears to be mixing and matching parts of paragraph 148, but Charles actually states “Components, containers and sub-components are added or removed” and “load and display new and existing images, and vectorised and 2D components”, not that containers and subcomponents are 2D components. Even assuming arguendo that containers and sub-components include 2D components, the containers/components are created by a computer, i.e. are executable parts. Furthermore, as noted above, Charles describes “creating DisplayManager objects 22' for each new display and instantiating container/component objects and reference information in the specified displays” (e.g. in paragraphs 101 and 148-149) and “instantiating” is another word for “executing”; i.e. “container/component objects” are executable parts. “container/component objects” are understood as nestable (e.g. a “container” can hold a component or other container and a component may be part of another component). Moreover, in response to applicant's arguments against the references individually, one cannot show nonobviousness by attacking references individually where the rejections are based on combinations of references. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986). In this case, nested components can also be seen in Totale and Luther, which describe applications with nested components. For example, Totale shows “URL addressable hierarchical page structure” including “a master page 402 is displayed with an application page 404” with a nested “second instance page”, or “master page 402 is displayed with” nested “second application page”, etc. (e.g. in column 2 lines 18-25, column 2 lines 44-52, and column 4 lines 42 – column 5 line 10, and figures 4-5 showing provided order of nesting).
With respect to applicant’s argument regarding motivation for components created based on a URL pattern, the “instantiating… container/component objects…in the specified displays” (i.e. executable parts) of Charles is in response to a URL parser that loads and parses “URLs” and then “load and parse the new target URL”, i.e. based on a first URL pattern and a second URL pattern (note: the term “URL pattern” appears to be used in applicant’s specification interchangeably with the term “URL”, e.g. see paragraphs 79 and 170 and figure 1). When “load and parse the new target URL” in Charles, “Components, containers and sub-components are added or removed from the current application subset” (e.g. in paragraph 148). As such, the executable parts/“container/component objects” of Charles are created based on URL patterns.
Furthermore, Totale teaches “URL addressable hierarchical page structure” with executable parts including a master page, application page, etc. (e.g. in column 2 lines 18-25, column 2 lines 44-52, and column 4 lines 42 – column 5 line 10). As noted above, the term “executable part” does not appear anywhere in applicant’s specification. Applicant also does not describe in the remarks how “executable part” is being interpreted or why the teachings of Totale are allegedly “entirely different from executable part”. The specification only states “when a user enters the URL into a browser, the first backslash would cause computer executable instructions in code441 to start the application container210. The SaaSCloud part of the URL would cause the computer executable instructions in code441 start the SaaSCloud Module container220”, etc. (e.g. in paragraph 79). The broadest reasonable interpretation of “executable part” includes any part can be created by a computer. Therefore, at least any of the master page and/or application page of Totale reads on “executable parts”. Mitchell (US 20050203958 A1) also teaches nested executable parts associated with a nested order of hierarchical paths (e.g. in paragraphs 33 and 37, “Execution of one or more Lattices… Lattices nested”, and figures 4 and 7-8 showing multiple nested hierarchies with nested order).
With respect to Luther, in response to applicant's arguments against the references individually, one cannot show nonobviousness by attacking references individually where the rejections are based on combinations of references. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986). In this case, Charles and Totale are relied upon to teach executable parts as described above. Moreover, as noted above, the broadest reasonable interpretation of “executable part” includes any part can be created by a computer. As such, the created/destroyed data/objects of Luther are also reasonably interpreted as “executable parts”.
Examiner disagrees with applicant’s conclusion that Charles allegedly “teaches away” (see the reasons noted above). Dokovski is not addressed based purely on Charles allegedly teaching away (which it does not for reasons noted above). However, it is noted that Dokovski teaches claimed features including executable parts, such as shown by “Container that runs portlets and provides them with the required runtime environment. This Portlet Container is to provide means to host the portlets and manage their lifecycle… each of the one or more portal applications 106 is any application, program, module, process, or other software that may execute, change, delete, generate, or otherwise manage information… the render method of PortletContainer evaluates the RenderRequest. RENDER_PART request attribute [variable]… administrators can construct a full tree with all portlets deployed on the server in a hierarchical manner, such as "vendor/application name/module name/portlet” (e.g. in paragraphs 19-20, 39, 87, and 155). Applicant then argues that Luther is allegedly “entirely different” similar to arguments with respect to Totale. Luther pertains to at least hierarchy paths and, as noted above, the created/destroyed data/objects of Luther are also reasonably interpreted as “executable parts”.
As such, applicant’s arguments are not persuasive.
It is noted that applicant does not address the double patenting rejections. As such, the double patenting rejections are maintained.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-4, 10-14, and 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over Charles (US 20080189358 A1) in view of Totale et al. (US 9841863 B1) and Luther et al. (US 20080263565 A1) [or alternatively and Dokovski et al. (US 20110078708 A1)].
As per independent claim 1, Charles teaches a non-transitory processor-readable storage device storing instructions which when executed by a processor perform a method of providing a router configuration for creating and destroying executable parts of an application based on URL patterns (e.g. in paragraphs 68-69, “processor used to execute… storage”), the method comprising:
receiving a first uniform resource locator (URL) pattern for first executable parts (e.g. in paragraph 101, “URL parser”, i.e. parse a URL), wherein each of the first executable parts include code and at least one variable (e.g. in paragraphs 69, 116, and 155, “translating the object code at runtime to the executable computer specific code… execute the cached set of target URL application subset… each component can optionally have a state variable name associated with it”);
creating the first executable parts of an application based on the first URL pattern, wherein the first executable parts include a first executable part and a second executable part (e.g. in paragraph 101, “loads and parses remote application subset definition files 18A-18N creating DisplayManager objects 22' for each new display and instantiating, storing and layout-constraining container/component objects and reference information in the specified displays”);
providing a first path for the first executable parts, wherein the first path is associated with each of the first executable parts (e.g. in paragraph 92, “navigation through the entire application is dependant upon the logical pathways between different application subsets”);
receiving a second URL pattern with a portion that is different than the first URL pattern for second executable parts (e.g. in paragraph 148, “load and parse the new target URL”);
creating the second executable parts of the application based on the second URL pattern, wherein each of the second executable parts include code and at least one variable (e.g. in paragraphs 69, 116, and 155 “translating the object code at runtime to the executable computer specific code… execute the cached set of target URL application subset… each component can optionally have a state variable name associated with it”), wherein the second executable parts includes a third executable part created based on the second URL pattern (e.g. in paragraphs 101 and 148, others of created “container/component objects” associated with “new target URL”) and the first executable part created based on the first URL pattern and the second executable part created based on the first URL pattern the first URL pattern (e.g. in paragraph 101, “URL parser… loads and parses remote application subset definition files 18A-18N creating DisplayManager objects 22' for each new display and instantiating, storing and layout-constraining container/component objects and reference information in the specified displays”);
providing a second path for the second executable parts, wherein the second path is associated with each of the second executable parts (e.g. in paragraphs 92 and 148, “navigation through the entire application is dependant upon the logical pathways between different application subsets” associated with “new target URL”); and
destroying a subset of the first executable parts of the application (e.g. in paragraphs 101 and 148-149, “In the case of existing displays, components are…removed [i.e. destroy] as instructed… Components, containers and sub-components are added or removed [i.e. destroy] from the current application subset”),
but does not specifically teach the first URL pattern that specifies the first path including a first hierarchy path with a first order of nesting, wherein the first executable part is nested inside of the second executable part; wherein the path is associated with the first order of nesting of the first executable parts along the first hierarchy path, providing the first executable part access to a variable of the second executable part based on lifecycle events that correspond with the first executable part and the second executable part, wherein the first executable part and the second executable part do not access a variable of the third executable part; wherein the second URL pattern specifies a second hierarchy path with a second order of nesting, wherein the third executable part that is outside of the first executable part and outside of the second executable part, wherein the second path includes the second hierarchy path, wherein the path is associated with a second order of nesting of the second executable parts along the second hierarchy path, and destroying the subset of first executable parts based on the portion that is different between the first pattern and the second URL pattern.
However, Totale teaches a first URL pattern that specifies a first path including first hierarchy path with a first order of nesting for first executable parts, wherein the path is associated with the first order of nesting of the first executable parts along the first hierarchy path (e.g. in column 1 lines 50-58, column 2 lines 18-25, column 2 lines 44-52, and column 4 lines 42-48, “processor configured to execute instructions… a URL addressable hierarchical page structure… a master page 402 is displayed with an application page 404 and a first instance page 406. For example, first instance page 406 may include and display data about a particular customer” and figures 4-5 showing provided order of nesting), a second URL pattern specifying a second path including a second hierarchy path with a second order of nesting for second executable parts, wherein the path is associated with the second order of nesting of the second executable parts along the second hierarchy path (e.g. in column 2 lines 18-25, column 2 lines 44-52, and column 4 lines 42 – column 5 line 10, “URL addressable hierarchical page structure” including “a master page 402 is displayed with an application page 404” with a nested “second instance page”, or “master page 402 is displayed with” nested “second application page”, etc. and figures 4-5 showing provided order of nesting), and destroying a subset of executable parts of an application based on a portion that is different between a first URL pattern and a second URL pattern (e.g. in column 2 lines 18-25, column 3 lines 38-64, and column 4 lines 42 – column 5 line 10, and column 5 lines 11-35, “the browser URL identifies the current context and is used to determine the granularity of the page refresh, e.g., which part(s) of the page and at which level(s) in the hierarchy is/are required to be refreshed… the navigation manager compares the previous and current navigation URLs and figures out the granularity in the page hierarchy which requires refresh. This triggers a cascading refresh of individual sections of the page”, i.e. old section(s) destroyed and replaced with new section(s) based on comparison, i.e. differences, and figures 4-5). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Charles to include the teachings of Totale because one of ordinary skill in the art would have recognized the benefit of allowing parts of an application to be easily refreshed based on URL changes,
but the combination does not specifically teach wherein the first executable part is nested inside of the second executable part; providing the first executable part access to a variable of the second executable part based on lifecycle events that correspond with the first executable part and the second executable part, wherein the first executable part and the second executable part do not access a variable of the third executable part; wherein the third executable part that is outside of the first executable part and outside of the second executable part.
However, Luther teaches first parts including a first part and a second part, wherein the first part is nested inside of the second part and second parts including a third part that is outside of the first part and outside of the second part (e.g. in figures 6 and 12-13 showing containers on a different hierarchical paths/branches that are not embedded with each other associated with a pattern) and providing the first part access to a variable of the second part based on lifecycle events that correspond with the first part and the second part, wherein the first part and the second part do not access a variable of the third part (e.g. in paragraphs 26, 34, 58 and 67, “Bos…may be created… destruction of the BOs… data, such as BOs 170, which may include any data related to, used, created, stored by, or otherwise associated with an application … inherit both retention rules and a major part of the hierarchical path”, i.e. access based on lifecycle events, and figures 6 and 12-13 showing containers on a different hierarchical paths/branches that are not embedded with each other, i.e. would not have inheritance/access between containers that are part of different hierarchical paths). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of the combination to include the teachings of Luther because one of ordinary skill in the art would have recognized the benefit of facilitating hierarchical relationships and/or functionality.
If, alternatively, the combination is not interpreted to teach “executable parts” as applied above, then the teachings of Dokovski can be relied upon. Dokovski at least teaches executable parts (e.g. in paragraphs 19-20, 39, 87, and 155, “Container that runs portlets and provides them with the required runtime environment. This Portlet Container is to provide means to host the portlets and manage their lifecycle… each of the one or more portal applications 106 is any application, program, module, process, or other software that may execute, change, delete, generate, or otherwise manage information… the render method of PortletContainer evaluates the RenderRequest. RENDER_PART request attribute [variable]… administrators can construct a full tree with all portlets deployed on the server in a hierarchical manner, such as "vendor/application name/module name/portlet”). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of the combination to include the teachings of Dokovski because one of ordinary skill in the art would have recognized the benefit of facilitating execution of applications (also amounts a simple substitution that yields predictable results [e.g. see KSR Int'l Co v. Teleflex Inc., 550 US 398,82 USPQ2d 1385,1396 (U.S. 2007) and MPEP 2143(B)]).
As per claim 2, the rejection of claim 1 is incorporated and the combination further teaches wherein the first executable parts are containers (e.g. Charles, in paragraph 101, “creating DisplayManager objects 22' for each new display and instantiating, storing and layout-constraining container/component objects and reference information in the specified displays”) and wherein the method further comprises associating the containers with URL parts of the first URL pattern, wherein the URL parts are separated by slashes and wherein each of the URL parts of the first URL pattern has a separate container (e.g. Charles, in paragraph 148, “container”; Totale, in column 3 lines 38-64 and column 5 lines 11-35, “the navigation manager compares the previous and current navigation URLs and figures out the granularity in the page hierarchy which requires refresh. This triggers a cascading refresh of individual sections of the page… page hierarchy… http://server:port/dempapp/#apppage1/customer/34242/details” and figure 4).
As per claim 3, the rejection of claim 2 is incorporated and the combination further teaches providing a respective hierarchy path for each of the containers and an order of containers along the respective hierarchy path (e.g. Charles, in paragraph 148, “container”; Totale, in figures 4-5 showing path/order of containers).
As per claim 4, the rejection of claim 2 is incorporated and the combination further teaches providing a particular container access to variables of the particular container and variables for containers along a hierarchy path of the particular container (e.g. Totale, in column 2 line 53 – column 3 line 7 and column 4 lines 30-35, “object type associated with the instance page… customer id, product id, etc.”).
As per claim 10, the rejection of claim 1 is incorporated and the combination further teaches wherein the executable parts are containers (e.g. Charles, in paragraph 101, “creating DisplayManager objects 22' for each new display and instantiating, storing and layout-constraining container/component objects and reference information in the specified displays”) and the method further comprising: creating variables for the containers based on a hierarchy path of the containers, wherein the hierarchy path is based on the first URL pattern (e.g. Totale, in column 2 lines 18-25, column 2 line 53 – column 3 line 64, and column 4 lines 30-35, “the browser URL identifies the current context and is used to determine the granularity of the page refresh, e.g., which part(s) of the page and at which level(s) in the hierarchy is/are required to be refreshed… the navigation manager compares the previous and current navigation URLs and figures out the granularity in the page hierarchy which requires refresh. This triggers a cascading refresh of individual sections of the page… customer id, product id, etc.” and figure 4); and destroying variables for a subset of the containers based on the hierarchy path, wherein the subset of the containers are the subset of the executable parts of the application (e.g. Charles, in paragraphs 101 and 148-149, “In the case of existing displays, components are…removed [i.e. destroy] as instructed… Components, containers and sub-components are added or removed [i.e. destroy] from the current application subset”; Totale, in column 2 lines 18-25, column 2 line 53 – column 3 line 64 and column 4 lines 30-35, “the browser URL identifies the current context and is used to determine the granularity of the page refresh, e.g., which part(s) of the page and at which level(s) in the hierarchy is/are required to be refreshed… the navigation manager compares the previous and current navigation URLs and figures out the granularity in the page hierarchy which requires refresh. This triggers a cascading refresh of individual sections of the page… customer id, product id, etc.”, i.e. destroy old section(s) including associated variables).
Claims 11-14 and 19 are the method claims corresponding to device claims 1-4 and 10, and are rejected under the same reasons set forth.
Claim 20 is the system claim corresponding to device claim 1, and is rejected under the same reasons set forth.
Claims 5-9 and 15-18 are rejected under 35 U.S.C. 103 as being unpatentable over Charles (US 20080189358 A1) in view of Totale et al. (US 9841863 B1) and Luther et al. (US 20080263565 A1) [or alternatively and Dokovski et al. (US 20110078708 A1)] as applied above, and further in view of Mitchell et al. (US 20050203958 A1).
As per claim 5, the rejection of claim 2 is incorporated, but the combination does not specifically teach, as a whole, receiving user input, at a design time tool, defining part of the application; generating computer executable instructions for the application based on the input; and executing the generated computer executable instructions during runtime of the application. However, Mitchell teaches receiving user input, at a design time tool, defining part of an application (e.g. in paragraphs 61 and 227, and claim 52, “developer may be able to create a Lattice application in a highly visual mode, using drag and drop and visual property editors in a GUI environment”, i.e. design time tool, and paragraphs 35 and 45-46, “reduce programming to the selection and organization of predefined data and logic that may be specified by selecting Lattice constructs (including from a variety of Lattice types) and specifying Attributes for those constructs, then assembling the constructs together to form a hierarchy called a Lattice program… a single instantiated Lattice (Lattice Element 420) may contain within itself another Lattice Container 400 with an entirely different set of Lattice Elements 420”), generating computer executable instructions for the application based on the input and executing the generated computer executable instructions during runtime of the application (e.g. in paragraphs 33, 51-52, 76, and 164-166, “Execution of one or more Lattices may achieve a particular runtime task… Lattice Elements inside the container are executed in a hierarchical order…[e.g.]from top to bottom… developer may set a handler to trigger when the value of a path associated with a Site changes… Once enabled, the trigger may be set for the duration of the object… onInit (initialization), onDelete (deletion), onLoad (assignment), and onBody”). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of the combination to include the teachings of Mitchell because one of ordinary skill in the art would have recognized the benefit of facilitating creation of an application.
As per claim 6, the rejection of claim 2 is incorporated, but the combination does not specifically teach providing each of the containers a respective lifecycle, wherein a lifecycle includes phases. However, Mitchell teaches providing each of containers a respective lifecycle, wherein a lifecycle includes phases (e.g. in paragraphs 51-52, 76, and 164-166, “Lattice Elements inside the container are executed in a hierarchical order…[e.g.]from top to bottom… developer may set a handler to trigger when the value of a path associated with a Site changes… Once enabled, the trigger may be set for the duration of the object… onInit (initialization), onDelete (deletion), onLoad (assignment)”, i.e. lifecycle phases). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of the combination to include the teachings of Mitchell because one of ordinary skill in the art would have recognized the benefit of facilitating handling of container events.
As per claim 7, the rejection of claim 6 is incorporated and the combination further teaches associating a lifecycle of a container with a URL part that corresponds with the container (e.g. Mitchell, in paragraphs 51-52, 76, and 164-166, “Lattice Elements inside the container are executed in a hierarchical order…[e.g.]from top to bottom… developer may set a handler to trigger when the value of a path associated with a Site changes… Once enabled, the trigger may be set for the duration of the object… onInit (initialization), onDelete (deletion), onLoad (assignment)”, a lifecycle of a container; Totale, in column 3 lines 38-64 and column 5 lines 11-35, “page hierarchy [corresponding to] http://server:port/dempapp/#apppage1/customer/34242/details”).
As per claim 8, the rejection of claim 6 is incorporated and the combination further teaches wherein the phases are mutually exclusive (e.g. Mitchell, in paragraphs 52, 76, and 101, “onInit (initialization), onDelete (deletion), onLoad (assignment)”, i.e. mutually exclusive).
As per claim 9, the rejection of claim 6 is incorporated and the combination further teaches wherein at least one of the phases is an event for starting an action chain (e.g. Mitchell, in paragraphs 52, 76, and 101, “onInit (initialization)”, etc.; note that initializing a lattice element will cause lattice elements contained inside the lattice element to also initialize, etc.).
Claims 15-18 correspond to device claims 5-9, and are rejected under the same reasons set forth.
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-20 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-20 of U.S. Patent No. 11487514. Although the claims at issue are not identical, they are not patentably distinct from each other because recite similar subject matter which is obvious over one another. For example, claims 1-20 of ‘514 teach claimed features (e.g. “a hierarchy of containers with a first container nested inside of a second container, wherein each of the containers in the hierarchy includes a different executable part of a web client application… containers in the hierarchy that are created and destroyed according to an order and lifecycle events of the lifecycles, wherein the containers in the hierarchy are arranged in the order along a path of the hierarchy of the containers… the first container access to state of the first container, the second container access to state of the second container, and the first container access to the state of the second container based on lifecycle events that correspond with the first and second containers in the hierarchy, wherein the hierarchy of the containers includes a third container that is outside the first container and the second container, and wherein the first container and the second container do not access state of the third container; and creating and destroying the containers of the hierarchy, during runtime of the web client application, according to the order and lifecycle events… associating the containers with parts of a uniform resource locator (URL) pattern, wherein each part of the URL pattern is associated with one of the containers… creating variables for the subset of the containers based on the URL pattern; and destroying variables for the subset of the containers based on the URL pattern”, etc.), but do not specifically teach “receiving a second URL pattern with a portion that is different than the first URL pattern… destroying a subset of the first executable parts of the application based on the portion that is different between the first URL pattern and the second URL pattern”. However, the prior art (e.g. Totale et al. (US 9841863 B1) as noted above) teaches receiving a second URL pattern with a portion that is different than a first URL pattern (e.g. in column 2 lines 18-25, column 2 lines 44-52, and column 4 lines 42 – column 5 line 10, “URL addressable hierarchical page structure” including “a master page 402 is displayed with an application page 404” with a nested “second instance page”, or “master page 402 is displayed with” nested “second application page”, etc. and figures 4-5 showing provided order of nesting) and destroying a subset of first executable parts of an application based on a portion that is different between the first URL pattern and the second URL pattern (e.g. in column 2 lines 18-25, column 3 lines 38-64, and column 4 lines 42 – column 5 line 10, and column 5 lines 11-35, “the browser URL identifies the current context and is used to determine the granularity of the page refresh, e.g., which part(s) of the page and at which level(s) in the hierarchy is/are required to be refreshed… the navigation manager compares the previous and current navigation URLs and figures out the granularity in the page hierarchy which requires refresh. This triggers a cascading refresh of individual sections of the page”, i.e. old section(s) destroyed and replaced with new section(s) based on comparison, i.e. differences, and figures 4-5). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the claims of ‘514 to include the teachings of Totale because one of ordinary skill in the art would have recognized the benefit of allowing parts of an application to be easily refreshed based on URL changes.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
For example,
Nguyen et al. (US 20100095289 A1) teaches a pattern that specifies a hierarchical/hierarchy path with an order of nesting for executable parts (e.g. in paragraphs 76-78, 97, and 102, “determined text is split using the names of the identified data container portions… executed during execution” and figures 3B-3D showing “petapp.ear/interface.war/ui/decl/xul2.jar/acme/login.class” and “petapp.ear/logic/helpers.jar/security/user/userhelper.class”).
Chintalapati et al. (US 20030084018 A1) teaches “the server 102 (FIG. 1) identifies the requested application by mapping the URL to an application context. For example, consider the following URL: http:/Iserver.com/catalog/shoppingservlet. The "server.com" portion of the URL maps to a virtual server 106. The "/catalog/shoppingservlet" is termed request URI (Uniform Resource Identifier). The "catalog" portion of the URL is a context path which maps to an application named "catalog." The "shoppingservlet" portion of the request URI maps to an application component named "shoppingservlet." Once the server 102 resolves the URL to the appropriate application context, it can direct the container 104 to service the request, i.e., to invoke the application component identified in the URI. The container 104 provides the runtime, or execution time, environment for running the requested application” (e.g. in paragraph 26).
Biswas et al. (US 9152803 B2) teaches “As shown in FIG. 4, “my.oracle.com” may represent a top level website and lie at the top of the resource hierarchy. Accordingly, “my.oracle.com” may be considered a top level resource situated at the top of the resource hierarchy… resources for “HR” and “CRM” may be considered as children or descendants of “my.oracle.com” in the resource hierarchy. Alternatively, “my.oracle.com” may be referred to as the parent or ancestor of the “HR” and “CRM” resources. The “HR” and CRM resources may in turn have one or more associated applications. As shown in FIG. 4, “HR” resource has a child application resource “App3” and the “CRM” resource has two child application resources “App1” and “App2”. Application “App2” may comprise two web pages “Page1” and “Page2”” (e.g. in column 7 line 61 – column 8 line 29, and figure 4).
De Magalhaes (US 20150331675 A1) teaches providing hierarchy pathways for executable parts, wherein there is at least one respective hierarchy path for each of the executable parts and an order of the executable parts along each of the respective hierarchy paths (e.g. in paragraphs 59-61, 63, and 66, “nodes arranged in a hierarchy… APIs can then be modeled by constructing an object graph… top node could be programmatically queried for its children (child paths 503, 504, 506, 508, 510), which would result in links that could then be followed… search can be quickly performed for certain URL patterns… a GET (node 556) can be performed to www.company.sample.com/software/products”, and figures 5A-5F showing respective paths of executable parts and order along paths).
Ilieva et al. (US 20150074743 A1) teaches at least affecting a subset of parts of an application based on a portion that is different between a first URL pattern and a second URL pattern (e.g. in paragraphs 61-62 and 66-70, “Individual customer resources, such as customer resource 1414, are associated with customer-identifier numbers and are each separately addressable by customer-resource-specific URIs, such as URI "http://www.acme.com/customerInfo/customers/361" 1422 which includes the customer identifier "361" for the customer represented by customer resource 1414… A particular order, such as the order represented by order resource 1424, may be specified by a unique URI associated with that order, such as URI "http://www.acme.com/customerInfo/customers/361/orders/1" 1440, where the final "1" is an order number that specifies a particular order within the set of orders corresponding to the particular customer identified by the customer identifier "361”, etc.; e.g. an order number could be changed in the URL which would show the changed order instead of the previous order)
Lee et al. (US 6944680 B1) teaches “a session object might be an EJB living inside a Web server that serves HTML pages to a user on a browser, and tracks that user's path through the site. When the user leaves the site, or after a specified idle time, the session object will be destroyed… EJBObject interface defines methods that allow the client to do the following operations on an EJB object's reference: Obtain the home interface for the EJB class; remove the EJB object 130; obtain the EJB object's handle; and obtain the EJB object's primary key” (e.g. in column 2 lines 40-56 and column 4 lines 63-65).
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to WILLIAM WONG whose telephone number is (571)270-1399. The examiner can normally be reached Monday-Friday 9am-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, TAMARA KYLE can be reached at (571)272-4241. 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.
/W.W/Examiner, Art Unit 2144 06/13/2026
/TAMARA T KYLE/Supervisory Patent Examiner, Art Unit 2144
Prosecution Insights