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 .
DETAILED ACTION
1. The pending claims 1-14 are presented for examination.
Claim Rejections - 35 USC § 101
2. 35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
3. Claims 1-14 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter.
4. Claims 1-14 are directed to a follow-up query language as being merely software. The claims lack the necessary physical articles or objects to constitute a machine or a manufacture within the meaning of 35 USC 101. They are clearly not a series of steps or acts to be a process nor are they a combination of chemical compounds to be a composition of matter. As such, they fail to fall within a statutory category. They are, at best, functional descriptive material per se. Descriptive material can be characterized as either “functional descriptive material” or “nonfunc-tional descriptive material.” Both types of “descriptive material” are nonstatu-tory when claimed as descriptive material per se, 33 F.3d at 1360, 31 USPQ2d at 1759. When functional descriptive material is recorded on some computer-readable medium, it becomes structurally and func-tionally interrelated to the medium and will be statu-tory in most cases since use of technology permits the function of the descriptive material to be realized. Compare In re Lowry, 32 F.3d 1579, 1583-84, 32 USPQ2d 1031, 1035 (Fed. Cir. 1994). Merely claiming non-functional descriptive material, i.e., abstract ideas, stored on a computer-readable medium, in a computer, or on an electromagnetic car-rier signal, does not make it statutory. See Diehr, 450 U.S. at 185-86, 209 USPQ at 8 (noting that the claims for an algorithm in Benson were unpatentable as abstract ideas because “[t]he sole practical application of the algorithm was in connection with the program-ming of a general purpose computer.”).
Double Patenting
5. Claims 1-10 are rejected on the ground of nonstatutory obviousness-type double patenting as being unpatentable over claims 1-8 of Sharan (US Patent 12,111,830 B2, hereinafter “Sharan”). Although the conflicting claims are not identical, they are not patentably distinct from each other because the inventions are obvious variants. Claims 1-10 of the instant application substantially recites the limitations of claims 1-8 of the U.S. Patent 12,111,830 B2 as shown in comparison table 1 below.
US Patent 12,111,830 B2 Claims
Application Claims
A parallel and distributed query engine, comprising:
a cloud service;
a proprietary software;
a query planner;
a query executor;
a user interface;
a central configuration database;
wherein said proprietary software is installed on said central configuration database;
wherein said user interface is a web-based interface between a user and said proprietary
software;
wherein said proprietary software is run on said cloud service and displayed to said user via
said user interface;
wherein said proprietary software is granted access by said user to a remote data storage
platform;
wherein said user interface prompts said user for a first input;
wherein said user interface receives said first input from said user;
wherein said query planner converts said first input into a series of parallel and sequential calls;
wherein said series of parallel and sequential calls are in a command language understood by
said remote data storage platform;
wherein said series of parallel and sequential calls are issued to said remote data storage
platform;
wherein said remote data storage platform returns an initial result to said proprietary software;
wherein said query executor aggregates said initial result into a first output;
wherein said first output is displayed to said user via said user interface,
wherein said cloud service further comprises a natural language processor;
wherein said user interface prompts said user for a first natural language input;
wherein said user interface receives said first natural language input from said user;
wherein said first natural language input is converted into a series of parallel and sequential
wherein said series of parallel and sequential calls are in a command language understood by
said remote data storage platform;
wherein said series of parallel and sequential calls are issued to said remote data storage
platform;
wherein said remote data storage platform returns said initial result to said proprietary
software;
wherein said query executor aggregates said initial result into said first output; and
wherein said first output is displayed to said user via said user interface;
wherein said user interface displays said first output and then prompts said user for a
subsequent input;
wherein said subsequent input is converted to said series of parallel and sequential calls and
issued to said remote data storage platform;
wherein said remote data storage platform returns said initial result that is converted to a
subsequent output and displayed to said user;
wherein said prompting for said subsequent input by said user interface is repeated until said
user performs a stop action;
wherein said first input and each of said subsequent inputs are recorded in the order received
by said proprietary software as a sequence of commands; and
wherein said sequence of commands is stored by said proprietary software as a unique
workflow.
A follow-up query language, comprising:
a cloud service;
a proprietary software;
a query planner;
a query executor;
a user interface;
a central configuration database;
wherein said proprietary software is installed on said central configuration database;
wherein said user interface is a web-based interface between a user and said proprietary
software;
wherein said proprietary software is run on said cloud service and displayed to said user via
said user interface;
wherein said proprietary software is granted access by said user to a remote data storage
platform;
wherein said user interface prompts said user for a first input;
wherein said user interface receives said first input from said user;
wherein said query planner converts said first input into a series of parallel and sequential calls;
wherein said series of parallel and sequential calls are in a command language understood by
said remote data storage platform;
wherein said series of parallel and sequential calls are issued to said remote data storage
platform;
wherein said remote data storage platform returns an initial result to said proprietary software;
wherein said query executor aggregates said initial result into a first output;
wherein said first output is displayed to said user via said user interface.
6. 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 obviousness-type 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); and 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 a nonstatutory double patenting ground provided the reference application or patent either is shown to be commonly owned with this 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 §§ 706.02(l)(1) - 706.02(l)(3) 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).
Effective January 1, 1994, a registered attorney or agent of record may sign a terminal disclaimer. A terminal disclaimer signed by the assignee must fully comply with 37 CFR 3.73(b).
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/forms/. The 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 http://www.uspto.gov/patents/process/file/efs/guidance/eTD-info-I.jsp.
Claim Rejections - 35 USC § 103
7. 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.
8. This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
9. 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.
10. The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
11. Claim 1 is rejected under 35 U.S.C. 103 as being unpatentable over Beitchman et al (US 11055352 B1, hereinafter “Beitchman”) in view of KALINOWSKI et al (EP 2343658 hereinafter, “KALINOWSKI”).
12. With respect to claim 1,
Beitchman discloses
a follow-up query language, comprising:
a cloud service (Beitchman col. 4 line 46 – col. 5 line 10, col. 7 lines 24-44 e.g. cloud);
a proprietary software (Beitchman col. 4 line 46 – col. 5 line 10, col. 7 lines 24-44 e.g. private or closed system);
a query planner (Beitchman abstract e.g. query plan);
a query executor;
a user interface (Beitchman col. 8 lines 34-62 e.g. browser);
a central configuration database;
wherein said proprietary software is installed on said central configuration database (Beitchman col. 2 line 57 – col. 3 line 33, 59 – col. 4 line 2 e.g. [col. 2 line 57 – col. 3 line 33] federated other types of distributed processing techniques for queries that utilize multiple different query engines may be optimized for performance independent of any one query engine used to process a query, in some embodiments.;
wherein said user interface is a web-based interface (Beitchman col. 8 lines 34-62 e.g. browser) between a user and said proprietary software;
wherein said proprietary software is run on said cloud service and displayed to said user via said user interface;
wherein said proprietary software is granted access by said user to a remote data storage platform (Beitchman col. 10 lines 17-43 e.g. (45) Managed query service 270 may implement authentication and authorization controls for handling requests received via managed query interface 310. For example, managed query service control plane 320 may validate the identity or authority of a client to access the data set identified in a query received from a client (e.g., by validating an access credential));
wherein said user interface prompts said user for a first input (Beitchman col. 10 lines 17-43 e.g. (45) Managed query service 270 may implement authentication and authorization controls for handling requests received via managed query interface 310. For example, managed query service control plane 320 may validate the identity or authority of a client to access the data set identified in a query received from a client (e.g., by validating an access credential));
wherein said user interface receives said first input from said user;
wherein said query planner converts said first input into federated calls (Beitchman col. 2 line 57 – col. 3 line 33, 59 – col. 4 line 2 e.g. [col. 2 line 57 – col. 3 line 33] (20) Engine independent query plan optimization may be implemented to decouple the performance of query optimization from other query execution operations, allowing for greater numbers of resources to allocated to optimization modeling and decision-making, as well as allowing for rapid iteration and deployment optimization technique improvements, in various embodiments. Moreover, federated other types of distributed processing techniques for queries that utilize multiple different query engines may be optimized for performance independent of any one query engine used to process a query, in some embodiments. [col. 3 line 59 – col. 4 line 2] (23) To process queries 102, query engines 120 may submit requests, 104a, 104b, and 104c, to get an optimized query plan for the query 102 from engine independent query plan optimizer 140, in various embodiments. Engine independent query plan optimizer 140 may implement query engine identification 142 to detect or otherwise identify the type of query engine for which the query is to be performed. In some embodiments, query engine identification 142 may identify multiple query engines types for a query (e.g., if queries 102a, 102b, and 102c were sub queries of a single query) in order to perform federated query processing; referring to the instant applicant’s specification [0009]);
wherein said series of federated calls are in a command language understood by said remote data storage platform (KALINOWSKI [0010], [0047] e.g. [0010] A further embodiment of the invention is that the query generated by the federation process is a sequential federated query or a parallel federated query. Both parallel and sequential execution of a federated query can be realized for example by using process specification techniques. Federation as a process is very similar to the graphical representation execution plan a federated database management system uses to execute federated queries. Therefore processes for sequential and parallel federated queries can be easily designed and implemented. [0047] Figure 3a shows an exemplary sequential federated query FP1 and figure 3b shows an exemplary parallel federated query FP2. Figures 3a and 3b represent examples of global query processing with the Federationas-a-Process method. Query evaluation/execution plan is defined as a lightweight process (constructing processor). The different possibilities of executing a federated query are expressed as process steps CS1 - CS4 (constructing step), L TS1 - L TS5 (local transition step) within a process FP1, FP2. As shown in Figures 3a and 3b both parallel and sequential execution of a federated query can also be realized using the process specification techniques. Federation as a process is very similar to the graphical representation execution plan a federated database management system uses to execute federated queries) (Beitchman abstract e.g. The optimized query plan may be translated into the engine-specific format and sent in response to the request for the optimized query plan.);
wherein said series of federated calls are issued to said remote data storage platform (Beitchman col. 2 line 57 – col. 3 line 33, 59 – col. 4 line 2 e.g. query engine identification 142 may identify multiple query engines types for a query (e.g., if queries 102a, 102b, and 102c were sub queries of a single query) in order to perform federated query processing);
wherein said remote data storage platform returns an initial result to said proprietary software;
wherein said query executor aggregates said initial result into a first output;
wherein said first output is displayed to said user via said user interface (Beitchman col. 4 lines 3-23 e.g. (24) Engine-specific query plan generation 144 may generate initial plan(s) to perform the query (or sub-queries) that is in a format specific to the type of engine to perform the query (or sub-queries). For example, engine-specific plan generation may utilize one format for query engine 120a and a different format for query engine 120b. Plan optimization format translation 146 may translate the initial plan(s) into a plan optimization format that can be analyzed by engine independent plan optimization 148 to perform various types of optimization, such as cost-based optimization, multi-objective optimization, among other optimization techniques, as discussed below with regard to FIGS. 8, 10, 11, and 13, in various embodiments. Plan optimization format translation 146 may then translate back the optimized query plan(s) and provide them to the respective query engines 120, in various embodiments. Query engines 120 may then perform the query according to the optimized query plan, 106a, 106b, and 106c, respectively and return results, 108a, 108b, and 108c for the queries (or sub-queries which may be aggregated into a single result or separately reported), in various embodiments).
Although Beitchman substantially teaches the claimed invention, Beitchman does not explicitly indicate federated calls a series of parallel and sequential calls.
KALINOWSKI teaches the limitations by stating a series of parallel and sequential calls (KALINOWSKI [0010], [0047] e.g. [0010] A further embodiment of the invention is that the query generated by the federation process is a sequential federated query or a parallel federated query. Both parallel and sequential execution of a federated query can be realized for example by using process specification techniques. Federation as a process is very similar to the graphical representation execution plan a federated database management system uses to execute federated queries. Therefore processes for sequential and parallel federated queries can be easily designed and implemented. [0047] Figure 3a shows an exemplary sequential federated query FP1 and figure 3b shows an exemplary parallel federated query FP2. Figures 3a and 3b represent examples of global query processing with the Federationas-a-Process method. Query evaluation/execution plan is defined as a lightweight process (constructing processor). The different possibilities of executing a federated query are expressed as process steps CS1 - CS4 (constructing step), L TS1 - L TS5 (local transition step) within a process FP1, FP2. As shown in Figures 3a and 3b both parallel and sequential execution of a federated query can also be realized using the process specification techniques. Federation as a process is very similar to the graphical representation execution plan a federated database management system uses to execute federated queries).
Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the invention, in view of the teachings of Beitchman and KALINOWSKI, to enables an agile technique of transiently federating dispersed data sources until they are consolidated (KALINOWSKI [0005]).
13. Claim 2 is rejected under 35 U.S.C. 103 as being unpatentable over Beitchman in view of KALINOWSKI, and further in view of Zhang et al (US 20190095531 hereinafter, “Zhang”).
14. With respect to claim 2,
Although Beitchman and KALINOWSKI combination substantially teaches the claimed invention, they do not explicitly indicate wherein said cloud service further comprises a natural language processor;
wherein said user interface prompts said user for a first natural language input;
wherein said user interface receives said first natural language input from said user;
wherein said first natural language input is converted into a series of parallel and sequential calls.
Zhang teaches the limitations by stating
wherein said cloud service further comprises a natural language processor;
wherein said user interface prompts said user for a first natural language input;
wherein said user interface receives said first natural language input from said user;
wherein said first natural language input is converted into a series of parallel and sequential calls (Zhang [0034] – [0035], [0066] e.g. [0034] In some examples embodiments, a search engine front-end 302 receives user input to generate a search query. This search query may be a fill query, such as a member name or company name (e.g. “Apple”), and/or a partial query, such as a string of characters that make up a partially input query (e. g., “A-P-P”). The query could be of several different query types, including natural language queries, structure queries, and so on. Also, in some example embodiments the query may take different forms, such as informational queries, navigational queries, transactional queries, connectivity queries, and so on. [0035] In some example embodiments, the search engine front-end 302 transmits the query via a search engine API 304 to a federated search layer 306. The federated search layer 306 is able to distribute searches to multiple searchable resource simultaneously. In an example embodiment, the federated search layer 306 interacts with a search platform 308 that performs searches on job postings).
Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the invention, in view of the teachings of Beitchman, KALINOWSKI and Zhang, to enables an agile technique of transiently federating dispersed data sources until they are consolidated (KALINOWSKI [0005]).
Allowable Subject Matter
15. Claims 3-14 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims. The prior art of record fails to teach or suggest the limitation “wherein said user interface displays said first output and then prompts said user for a subsequent input; wherein said subsequent input is converted to said series of parallel and sequential calls and issued to said remote data storage platform; wherein said remote data storage platform returns said initial result that is converted to a subsequent output and displayed to said user; wherein said prompting for said subsequent input by said user interface is repeated until said user performs a stop action; wherein said first input and each of said subsequent inputs are recorded in the order received by said proprietary software as a sequence of commands; and wherein said sequence of commands is stored by said proprietary software as a unique workflow” in combination with the remaining elements as cited in claim 3. The closest prior art, Beitchman et al (US 11055352 B1, hereinafter “Beitchman”) describes optimized query plans may be generated independent of the query engine that performs the optimized query plan. A request to generate an optimized query plan for a query may be received and a type of engine for performing the query may be identified. However, Beitchman in view of KALINOWSKI et al (EP 2343658 hereinafter, “KALINOWSKI”) and Zhang et al (US 20190095531 hereinafter, “Zhang”) does not teach or suggest the limitations cited above as being free of any prior art when read in the claims as a whole.
Conclusion
The prior art made of record, listed on form PTO-892, and not relied upon, if any, is considered pertinent to applicant's disclosure.
16. The examiner requests, in response to this office action, support be shown for language added to any original claims on amendment and any new claims. That is, indicate support for newly added claim language by specifically pointing to page(s) and line no(s) in the specification and/or drawing figure(s). This will assist the examiner in prosecuting the application.
17. When responding to this office action, Applicant is advised to clearly point out the patentable novelty which he or she thinks the claims present, in view of the state of the art disclosed by the reference cited or the objections made. He or she must also show how the amendments avoid such references or objections See 37 CFR 1.111(c).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SyLing Yen whose telephone number is 571-270-1306. The examiner can normally be reached on Mon-Fri 8:30am - 5:00pm.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Mark Featherstone can be reached at 571-270-3750. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/SYLING YEN/Primary Examiner, Art Unit 2166
February 9, 2026