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
Claims 1 – 20 are pending.
Any references to applicant’s specification are made by way of applicant’s U.S. pre-grant printed patent publication.
This action is in response to the communication filed on 07/06/26 .
All objections and rejections not set forth below have been withdrawn.
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 7/6/26 has been entered.
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 – 20 are rejected under 35 U.S.C. 103 as being unpatentable over Feinberg, US 2006/0155720 A1 in view of KÜÇÜKEREN, “Data Access Layer Code Generator”.
Regarding claim 1, as best determined in view of the above noted deficiencies of clarity, Feinberg discloses:
A computer-implemented method comprising (e.g. Feinberg, claim 6):
receiving, by a processor (e.g. Feinberg, fig. 6:621; fig. 2:215), a request for a data access [layer class] (e.g. Feinberg, fig. 2:205; par. 13, 35, 36, 37 – customer provides a XML file, i.e. “a request”, for generating a data access layer class), the request indicating a stored procedure (e.g. Feinberg, par. 31, 37 – the customer’s XML file indicates a plurality of stored procedures) stored in a database for accessing data in the database (e.g. Feinberg, fig. 2:210; par. 31, 32 – the stored procedures are stored within the database).
Feinberg teaches a data access generator for generating data access layer classes. Feinberg does not appear to explicitly use the term “file” (i.e. a named collection of data) when characterizing the generated data access layer class.
However, Kucukeren also teaches a data access generator for generating data access layer classes. Furthermore, Kucukeren teaches that the data access layer classes generated by the generator are named collections of data, thus “files” (e.g. Kucukeren, pg. 31, 59).
It would have been obvious to one of ordinary skill in the art recognize the teachings of Kucukeren that data access layer classes are files within the system of Feinberg, because one of ordinary skill in the art would have been motivated by (i.e. a named collection of data) to distinguish one generated data access layer class from that of another.
Thus, the combination enables:
in response to the request for the data access file:
determining, by the processor, based on the stored procedure indicated in the request for the data access file, inputs required by the stored procedure (e.g. Feinberg, par. 37, 38 – i.e. determined parameters);
invoking, by the processor, the stored procedure to retrieve a data record stored in the database (e.g. Feinberg, par. 12, 30), the stored procedure comprising executable database operation instructions for accessing the data record in the database using the inputs required by the stored procedure (e.g. Feinberg, par. 12, 30, 38);
generating, by the processor, the data access file (e.g. Feinberg, fig. 2:220; par. 35) based on the stored procedure (e.g. Feinberg, fig. 2: 204…206 [Wingdings font/0xE0] 215 [Wingdings font/0xE0] 220), the data record retrieved by invoking the stored procedure, and the inputs required by the stored procedure (e.g. Feinberg, par. 12, 33, 42), the data access file including a mapping between a first property in an application associated with the database and a second property of the data record in the database (e.g. Feinberg, par. 5, 6, 38, 40 – 42), and the data access file further including instructions for invoking the stored procedure using the inputs required by the stored procedure to query the database for the data record (e.g. e.g. Feinberg, par. 12, 33, 42);
and in response to receiving a first request for the data record in the database (e.g. Feinberg, par. 28 – 30), translating, by the processor, the first request for the data record into a second request for the data record according to the mapping in the data access file, wherein the second request uses the instructions for invoking the stored procedure in the data access file to invoke the stored procedure to access the data record in the database (e.g. Feinberg, fig. 1:125; par. 12, 29, 30, 46).
Regarding claim 2, combination enables:
in response to an update to the stored procedure (e.g. Feinberg, par. 42, 43), retrieving, by the processor, a second data record from the database based on the updated stored procedure; generating, by the processor, an updated data access file based on the updated stored procedure and the second data record; and translating, by the processor, a third request for the data record in the database into a fourth request for the data record in the database using the updated data access file, wherein the fourth request uses the updated stored procedure to access the second data record in the database (e.g. Feinberg, par. 43). Herein, the data access layer is regenerated, using the same process as taught above, based upon the updated or new database records).
Regarding claim 3, combination enables:
further comprising receiving, by the processor, an indication of the update to the stored procedure from the database (e.g. Feinberg, par. 42, 43).
Regarding claim 4, combination enables:
further comprising periodically polling, by the processor, the database for the update to the stored procedure (e.g. Feinberg, par. 42, 43).
Regarding claim 5, combination enables:
wherein the update to the stored procedure is made by an administrator computer (e.g. Feinberg, par. 42, 43).
Regarding claim 6, combination enables:
wherein the stored procedure is configured to return data from one or more tables of the database based on one or more input parameters (e.g. Feinberg, par. 3, 30, 46).
Regarding claim 7, combination enables:
wherein the first request comprises an application programming interface (API) call (e.g. Feinberg, par. 11, 30, 33, 44, 45; fig. 5).
Regarding claim 8, combination enables:
wherein the second request uses a calling code of the data access file to call the stored procedure (e.g. Feinberg, par. 11, 30, 33, 44, 45; fig. 5).
Regarding claim 9, combination enables:
wherein the first request comprises a database operation … (e.g. Feinberg, par. 12, 30, 31, 46 – identified database operation). Feinberg does not appear to explicitly teach that the data access request comprises “an identifier of the database” to be accessed. However, Feinberg does teach that client’s within an organization make data access requests to a DBMS system that comprises a plurality of different databases (e.g. Feinberg, par. 3 – 5, 55; fig. 7:760). Thus, it would have been obvious to one of ordinary skill in the art to make requests that comprise an identifier of a database, because one of ordinary skill in the art would have been motivated by the need to identify which one of the plurality of databases (e.g. customer data vs. product data vs. organizational data, etc.) from which the client wishes to access data.
Regarding claim 10, combination enables:
wherein the data access file comprises a mapping between the database operation and the stored procedure (e.g. Feinberg, par. par. 12, 29, 30, 46).
Regarding claims 11 – 20, they are system claims essentially corresponding to the method claims above, and they are rejected, at least, for the same reasons. Furthermore because, Feinberg discloses: A system comprising: a database comprising a non-transitory machine-readable storage medium … a server comprising a processor … (e.g. Feinberg, fig. 5; fig. 6; fig. 7).
Response to Arguments
Applicant's arguments filed 7/6/26 have been fully considered but they are not persuasive.
Applicant argues or alleges essentially that:
…
… However, Feinberg is altogether silent as to determining, based on the stored procedure, the inputs required by the stored procedure. In Feinberg, the configuration information is provided externally by the user in the XML configuration file. Feinberg does not determine based on the stored procedure, what inputs the stored procedure requires. Instead, Feinberg relies on the user to specify this information in the configuration file. …
…
(Remarks, pg. 7, 8)
Examiner respectfully responds:
The examiner respectfully disagrees, at least, for any one of the reasons below:
First, Feinberg does teach that the user’s request, comprising the XML file, indicates which stored procedures are to be used for generating a data access file. However, Feinberg clearly and explicitly teaches that the necessary parameters for the identified stored procedures are gathered, i.e. determined, from the database of stored procedures (e.g. Feinberg, fig. 2:210; par. 37, 38).
Second, assuming arguendo, that Feinberg were to teach that the XML file was used when determining parameter information. The examiner points out that such determination of parameter information is performed within a vacuum - separate and distinct from the stored procedures indicated by the XML file - but it is clearly dependent upon (i.e. “based on”) the stored procedures identified within the XML file.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JEFFERY L WILLIAMS whose telephone number is (571)272-7965. The examiner can normally be reached on 7:30 am - 4:00 pm.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Farid Homayounmehr can be reached on 571-272-3739. 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.
/JEFFERY L WILLIAMS/ Primary Examiner, Art Unit 2495
Prosecution Insights