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 .
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 9-24-2024, 2-23-2026 and 3-26-2026 was filed after the mailing date of the 9-19-2024. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1-20 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Dixon III et al. (U.S. Patent No. 7,257,819).
With regard to claim 1, Dixon teaches a sub-application page processing method performed by a computer device ([abstract] a dispatching system that uses a common interface to interface with all sub-applications), the method comprising:
in response to an event of requesting a sub-application page (Fig. 3; [col. 2, lines 35-45] the dispatching system receives requests (e.g., HTTP requests), identifies the sub-applications that should process the received requests…a match criteria may be a regular expression (e.g., "*.html") that is applied to the uniform resource locator ("URL") of an HTTP request; [col. 3, lines 39-55] The web server includes a server environment 104 and the dispatching system comprising the dispatcher 105, the sub-application configuration file 106, the sub-application definition file 107, and the application comprising sub-applications 108, 109, and 110), obtaining page code of the sub-application page written in a markup language ([col. 2, lines 35-45] a match criteria may be a regular expression (e.g., "*.html") that is applied to the uniform resource locator ("URL") of an HTTP request. The dispatching system processes the sub-applications in an order that may be predefined. The dispatching system selects the first sub-application and applies the match criteria associated with the first sub-application to the received request);
parsing the page code to create a page node tree corresponding to the sub-application page (Fig. 3, 302; [col. 8, lines 1-11] the routine then loops to block 302 to select the next sub-application), the page node tree being a tree structure generated based on a page node of the sub-application page ([col. 4, lines 5-20] The sub-application sequences 210, 220, and 230 illustrate the invocation of sub-applications when a request is received by the dispatcher. The overall application comprises six sub-applications ordered as follows: Authenticate User 1 ("*"), Authenticate User 2 ("*secure*"), Log Request ("*"), Perform Service 1 ("*S1*"), Perform Service 2 ("*S2*"), and Log Response ("*"). The parentheticals indicate the match criteria for each sub-application. The match criteria of "*" indicates that all URLs match, and the match criteria of "*secure*" indicates that only those URLs that include the word "secure" match);
establishing a binding relationship between the sub-application page and a first instance object for converting the page node tree ([col. 4, lines 6-50] The sub-application sequences 210, 220, and 230 illustrate the invocation of sub-applications when a request is received by the dispatcher. The overall application comprises six sub-applications ordered as follows: Authenticate User 1 ("*"), Authenticate User 2 ("*secure*"), Log Request ("*"), Perform Service 1 ("*S1*"), Perform Service 2 ("*S2*"), and Log Response ("*"). The parentheticals indicate the match criteria for each sub-application. The match criteria of "*" indicates that all URLs match, and the match criteria of "*secure*" indicates that only those URLs that include the word "secure" match);
converting the page node tree into interface invocation information corresponding to the page node tree using the first instance object ([abstract] a common interface to interface with all sub-applications…Each sub-application implements the common interface and shares a common context with the other sub-applications. In one embodiment, the dispatching system receives requests (e.g., HTTP requests); [col. 6, lines 17-25] The interface provides access to resources that include registered services, named objects managed by the application environment, the server environment, resource bundles, and the class loaders. Each overall application executes within its own context); and
rendering the sub-application page based on the interface invocation information ([col. 6, lines 17-25] The interface provides access to resources that include registered services, named objects managed by the application environment, the server environment, resource bundles, and the class loaders. Each overall application executes within its own context; [claim 1] wherein the requests are HTTP requests with a URL and the match criteria is a regular expression relating to the URL; wherein a respective service routine is invoked for the request with respect to each of at least two of the sub-applications).
With regard to claim 2, the limitations are addressed above and Dixon teaches wherein the establishing a binding relationship between the sub-application page and a first instance object for converting the page node tree ([col. 4, lines 6-50] The sub-application sequences 210, 220, and 230 illustrate the invocation of sub-applications when a request is received by the dispatcher. The overall application comprises six sub-applications ordered as follows: Authenticate User 1 ("*"), Authenticate User 2 ("*secure*"), Log Request ("*"), Perform Service 1 ("*S1*"), Perform Service 2 ("*S2*"), and Log Response ("*"). The parentheticals indicate the match criteria for each sub-application. The match criteria of "*" indicates that all URLs match, and the match criteria of "*secure*" indicates that only those URLs that include the word "secure" match) comprises:
obtaining, based on a protocol mode of a preconfigured interface protocol ([col. 8, lines 45-55] the sub-application can implement a wide variety of behaviors such as protocol translation, logging, business rules, authentication, and so on), a first interface class for converting the page node tree ([col. 3, lines 1-23] Each entry may identify an object class associated with the sub-application, initialization parameters associated with the sub-application, and the match criteria for the sub-application. During initialization, the dispatching system retrieves each entry and instantiates an object of the object class associated with that the sub-application. The object class defines a "service" method or routine that the dispatching system invokes to have the sub-application process requests);
creating, based on the first interface class, the first instance object for converting the page node tree ([col. 3, lines 1-23] Each entry may identify an object class associated with the sub-application, initialization parameters associated with the sub-application, and the match criteria for the sub-application); and
creating, by using the first instance object as a creation parameter, a root component instance corresponding to the sub-application page to establish the binding relationship between the first instance object and the sub-application page ([col. 3, lines 1-23] Each entry may identify an object class associated with the sub-application, initialization parameters associated with the sub-application, and the match criteria for the sub-application; [col. 3, lines 40-66] The sub-application configuration file contains an entry for each sub-application that includes an indication of the match criteria, object class, and initialization parameters for that sub-application. The sub-application definition file contains the class definitions for the sub-applications).
With regard to claim 3, the limitations are addressed above and Dixon teaches wherein the converting the page node tree into interface invocation information corresponding to the page node tree using the first instance object ([col. 4, lines 6-50] The sub-application sequences 210, 220, and 230 illustrate the invocation of sub-applications when a request is received by the dispatcher. The overall application comprises six sub-applications ordered as follows: Authenticate User 1 ("*"), Authenticate User 2 ("*secure*"), Log Request ("*"), Perform Service 1 ("*S1*"), Perform Service 2 ("*S2*"), and Log Response ("*"). The parentheticals indicate the match criteria for each sub-application. The match criteria of "*" indicates that all URLs match, and the match criteria of "*secure*" indicates that only those URLs that include the word "secure" match) comprises:
starting from a root node of the page node tree, sequentially traversing page nodes in the page node tree based on first interface configuration information provided by the first instance object ([col. 4, lines 5-30] The sub-application sequences 210, 220, and 230 illustrate the invocation of sub-applications when a request is received by the dispatcher), to respectively determine first invocation information corresponding to each page node and obtain second invocation information corresponding to page configuration information of the page node tree ([col. 4, lines 5-30] The sub-application sequences 210, 220, and 230 illustrate the invocation of sub-applications when a request is received by the dispatcher. The overall application comprises six sub-applications ordered as follows: Authenticate User 1 ("*"), Authenticate User 2 ("*secure*"), Log Request ("*"), Perform Service 1 ("*S1*"), Perform Service 2 ("*S2*"), and Log Response ("*")); and
obtaining, based on the first invocation information and the second invocation information, the interface invocation information corresponding to the page node tree ([col. 4, lines 5-30] The sub-application sequences 210, 220, and 230 illustrate the invocation of sub-applications when a request is received by the dispatcher. The overall application comprises six sub-applications ordered as follows: Authenticate User 1 ("*"), Authenticate User 2 ("*secure*"), Log Request ("*"), Perform Service 1 ("*S1*"), Perform Service 2 ("*S2*"), and Log Response ("*"). The parentheticals indicate the match criteria for each sub-application. The match criteria of "*" indicates that all URLs match, and the match criteria of "*secure*" indicates that only those URLs that include the word "secure" match).
With regard to claim 4, the limitations are addressed above and Dixon teaches wherein the starting from a root node of the page node tree, sequentially traversing page nodes in the page node tree based on first interface configuration information provided by the first instance object ([col. 4, lines 5-30] The sub-application sequences 210, 220, and 230 illustrate the invocation of sub-applications when a request is received by the dispatcher), to respectively determine first invocation information corresponding to each page node comprises:
for each page node in the page node tree (Fig. 3, 302; [col. 8, lines 1-11] the routine then loops to block 302 to select the next sub-application),
determining, from the first interface configuration information provided by the first instance object, first interface information matching a page node type of the page node ([col. 4, lines 5-30] The parentheticals indicate the match criteria for each sub-application. The match criteria of "*" indicates that all URLs match, and the match criteria of "*secure*" indicates that only those URLs that include the word "secure" match); and
determining, based on the first interface information, first invocation information corresponding to the page node ([col. 2, lines 2-65] The common interface provides a service method or routine that the dispatching system invokes to effect processing by the sub-application. Each sub-application implements the common interface. In one embodiment, the dispatching system receives requests (e.g., HTTP requests), identifies the sub-applications that should process the received requests, and invokes the service routine of the identified sub-applications to process the received requests).
With regard to claim 5, the limitations are addressed above and Dixon teaches wherein the determining, based on the first interface information ([abstract] a dispatching system that uses a common interface to interface with all sub-applications), first invocation information corresponding to the page node ([col. 4, lines 5-20] The sub-application sequences 210, 220, and 230 illustrate the invocation of sub-applications when a request is received by the dispatcher) comprises:
obtaining a second instance object based on the first interface information ([col. 4, lines 5-30] The sub-application sequences 210, 220, and 230 illustrate the invocation of sub-applications when a request is received by the dispatcher. The overall application comprises six sub-applications ordered as follows: Authenticate User 1 ("*"), Authenticate User 2 ("*secure*"), Log Request ("*"), Perform Service 1 ("*S1*"), Perform Service 2 ("*S2*"), and Log Response ("*")), the second instance object providing second interface configuration information for converting the page node tree ([col. 4, lines 5-30] The sub-application sequences 210, 220, and 230 illustrate the invocation of sub-applications when a request is received by the dispatcher. The overall application comprises six sub-applications ordered as follows: Authenticate User 1 ("*"), Authenticate User 2 ("*secure*"), Log Request ("*"), Perform Service 1 ("*S1*"), Perform Service 2 ("*S2*"), and Log Response ("*"));
obtaining, by using the second interface configuration information provided by the second instance object, second interface information corresponding to the page node ([col. 2, lines 5-66] When the first sub-application completes its processing, the dispatching system then selects the second sub-application and applies the matching criteria associated with the second sub-application to the received request); and
obtaining, based on the first interface information ([abstract] a dispatching system that uses a common interface to interface with all sub-applications) and the second interface information ([col. 4, lines 5-30] The sub-application sequences 210, 220, and 230 illustrate the invocation of sub-applications when a request is received by the dispatcher. The overall application comprises six sub-applications ordered as follows: Authenticate User 1 ("*"), Authenticate User 2 ("*secure*"), Log Request ("*"), Perform Service 1 ("*S1*"), Perform Service 2 ("*S2*"), and Log Response ("*")), the first invocation information corresponding to the page node ([col. 4, lines 5-20] The sub-application sequences 210, 220, and 230 illustrate the invocation of sub-applications when a request is received by the dispatcher).
With regard to claim 6, the limitations are addressed above and Dixon teaches wherein the method further comprises:
creating, by using the first instance object, a second interface class for converting a page node, the second interface class comprising a logical method for converting a page node ([col. 3, lines 1-23] Each entry may identify an object class associated with the sub-application, initialization parameters associated with the sub-application, and the match criteria for the sub-application. During initialization, the dispatching system retrieves each entry and instantiates an object of the object class associated with that the sub-application. The object class defines a "service" method or routine that the dispatching system invokes to have the sub-application process requests);
creating, by using a first keyword for class-based interface implementation ([abstract] Each sub-application implements the common interface and shares a common context with the other sub-applications), a second implementation class corresponding to the second interface class ([col. 3, lines 1-23] Each entry may identify an object class associated with the sub-application, initialization parameters associated with the sub-application, and the match criteria for the sub-application), the second implementation class being configured for implementing the logical method for converting a page node in the second interface class ([col. 3, lines 1-23] Each entry may identify an object class associated with the sub-application, initialization parameters associated with the sub-application, and the match criteria for the sub-application. During initialization, the dispatching system retrieves each entry and instantiates an object of the object class associated with that the sub-application. The object class defines a "service" method or routine that the dispatching system invokes to have the sub-application process requests); and
instantiating, by using a second keyword for class-based instance object creation ([abstract] Each sub-application implements the common interface and shares a common context with the other sub-applications), the second implementation class to create a second instance object corresponding to the second implementation class ([col. 3, lines 1-23] Each entry may identify an object class associated with the sub-application, initialization parameters associated with the sub-application, and the match criteria for the sub-application. During initialization, the dispatching system retrieves each entry and instantiates an object of the object class associated with that the sub-application. The object class defines a "service" method or routine that the dispatching system invokes to have the sub-application process requests).
With regard to claim 7, the limitations are addressed above and Dixon teaches wherein the obtaining, by using the second interface configuration information provided by the second instance object ([col. 3, lines 1-23] Each entry may identify an object class associated with the sub-application, initialization parameters associated with the sub-application, and the match criteria for the sub-application), second interface information corresponding to the page node comprises:
obtaining, based on node configuration information of the page node, the second interface information corresponding to the page node from the second interface configuration information provided by the second instance object ([col. 3, lines 1-23] Each entry may identify an object class associated with the sub-application, initialization parameters associated with the sub-application, and the match criteria for the sub-application. During initialization, the dispatching system retrieves each entry and instantiates an object of the object class associated with that the sub-application. The object class defines a "service" method or routine that the dispatching system invokes to have the sub-application process requests).
With regard to claim 8, the limitations are addressed above and Dixon teaches wherein the obtaining, based on the first interface information ([abstract] a dispatching system that uses a common interface to interface with all sub-applications) and the second interface information ([col. 3, lines 1-23] Each entry may identify an object class associated with the sub-application, initialization parameters associated with the sub-application), the first invocation information corresponding to the page node ([col. 4, lines 5-20] The sub-application sequences 210, 220, and 230 illustrate the invocation of sub-applications when a request is received by the dispatcher) comprises:
when the page node is a component node, obtaining a pre-created third instance object based on the second interface information, the third instance object being an instance object for converting the component node ([col. 4, lines 6-66] The overall application comprises six sub-applications ordered as follows: Authenticate User 1 ("*"), Authenticate User 2 ("*secure*"), Log Request ("*"), Perform Service 1 ("*S1*"), Perform Service 2 ("*S2*"), and Log Response ("*"). The parentheticals indicate the match criteria for each sub-application. The match criteria of "*" indicates that all URLs match, and the match criteria of "*secure*" indicates that only those URLs that include the word "secure" match);
obtaining, by using the third instance object, third interface information corresponding to the component node ([col. 4, lines 6-66] The overall application comprises six sub-applications ordered as follows: Authenticate User 1 ("*"), Authenticate User 2 ("*secure*"), Log Request ("*"), Perform Service 1 ("*S1*"), Perform Service 2 ("*S2*"), and Log Response ("*"). The parentheticals indicate the match criteria for each sub-application. The match criteria of "*" indicates that all URLs match, and the match criteria of "*secure*" indicates that only those URLs that include the word "secure" match); and
obtaining, based on the first interface information ([abstract] a dispatching system that uses a common interface to interface with all sub-applications), the second interface information ([col. 3, lines 1-23] Each entry may identify an object class associated with the sub-application, initialization parameters associated with the sub-application), and
the third interface information that correspond to the component node, first invocation information corresponding to the component node ([col. 4, lines 6-66] The overall application comprises six sub-applications ordered as follows: Authenticate User 1 ("*"), Authenticate User 2 ("*secure*"), Log Request ("*"), Perform Service 1 ("*S1*"), Perform Service 2 ("*S2*"), and Log Response ("*"). The parentheticals indicate the match criteria for each sub-application. The match criteria of "*" indicates that all URLs match, and the match criteria of "*secure*" indicates that only those URLs that include the word "secure" match).
With regard to claim 9, the limitations are addressed above and Dixon teaches wherein the parsing the page code to create a page node tree corresponding to the sub-application page ([abstract] Each sub-application implements the common interface and shares a common context with the other sub-applications) comprises:
compiling the page code by using a markup language compiler corresponding to the markup language to obtain the page parsing result ([abstract] Each sub-application implements the common interface and shares a common context with the other sub-applications. In one embodiment, the dispatching system receives requests (e.g., HTTP requests; [claim 1] wherein the requests are HTTP requests with a URL and the match criteria is a regular expression relating to the URL; wherein a respective service routine is invoked for the request with respect to each of at least two of the sub-applications).
With regard to claim 10, the device claim corresponds to the method claim 1, respectively, and therefore rejected with the same rationale.
With regard to claim 11, the device claim corresponds to the method claim 2, respectively, and therefore rejected with the same rationale.
With regard to claim 12, the device claim corresponds to the method claim 3, respectively, and therefore rejected with the same rationale.
With regard to claim 13, the device claim corresponds to the method claim 4, respectively, and therefore rejected with the same rationale.
With regard to claim 14, the device claim corresponds to the method claim 5, respectively, and therefore rejected with the same rationale.
With regard to claim 15, the device claim corresponds to the method claim 6, respectively, and therefore rejected with the same rationale.
With regard to claim 16, the device claim corresponds to the method claim 7, respectively, and therefore rejected with the same rationale.
With regard to claim 17, the device claim corresponds to the method claim 8, respectively, and therefore rejected with the same rationale.
With regard to claim 18, the device claim corresponds to the method claim 9, respectively, and therefore rejected with the same rationale.
With regard to claim 19, the medium claim corresponds to the method claim 1, respectively, and therefore rejected with the same rationale.
With regard to claim 20, the medium claim corresponds to the method claim 2, respectively, and therefore rejected with the same rationale.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Deng (US 2016/0124914) teaches a system and method for mobile application page that is involved in returning rendered instance to object to generate local object to mobile application pages on client terminal and displaying mobile application page.
. Chang et al. (US 2016/0117408) teaches a system and method for indexing application pages of native applications by generating application page data and application page data for native application in index which is searchable by the search engine.
Chang et al. (US 2014/0201179) teaches a native application operable independent of browser application, generating application pages within native application is instantiated (204) within virtual machine.
Tvorun et al. (US 2013/0227397) teaches a system for forming an instrumented text source document for generating a live web page.
Fanning et al. (US 2012/0331374) teaches linking source code to running elements.
Lin et al. (US 2012/0278427) teaches transmitting information between multiple electronic pages.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ANDREA C. LEGGETT whose telephone number is (571)270-7700. The examiner can normally be reached M-F 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, Kieu Vu can be reached at 571-272-4057. 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.
/ANDREA C LEGGETT/Primary Examiner, Art Unit 2171
Prosecution Insights