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 action filed on 3/24/2026. This action is Non-Final.
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,7,9,11-12, 14-17 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Kwon et al. (US 2011/0283366 A1) and further in view of Fyles et al. (US 5,491,780).
As per claim 1 (Amended), Kwon et al. teaches the invention as claimed including, “ A method for monitoring usage of a dynamically bound method of a software object, comprising:
saving, to a memory of a computing device, a copy of a virtual method table for the software object, wherein the virtual method table includes a plurality of method pointers to different dynamically bound methods of the software object including a method pointer to the dynamically bound method;”
Kwon et al. teaches that a COM-based object may have a virtual function table that includes addresses of functions (method pointer) of the browser object. The virtual function table stores addresses of functions provided by the object to an external location (0061). An abuse prevention module may store and back up an address of the original function (copy of virtual method table). The abuse prevention module may store and back up an address of the original function corresponding to a position of the original function desired to be intercepted, using the virtual function table (0062). Also see 0066, 0072, 0128 and figure 4.
“modifying, by the computing device, the virtual method table to change the method pointer to an address of a hook function; and…
…calling the hook function using the changed method pointer in the modified virtual method table,”
The abuse prevention module declares (designates) a new function (hook function) having the same format, as the original function. The address of the new function is declared at the portion in the vtable of the original function. This will allow the browser function extension module to call the hook function, when the browser function extension module calls the original function (0068). Also see 0073-0074. The browser function extension module may request the hook function using the address of the hook function recorded at the position of the original function in the virtual function table (0075).
“in response to a call on the computing device to the dynamically bound method,
determining, by the hook function, an address of the software object using a reference variable that refers to a current object of the dynamically bound method to resolve to an address of the software object,
using, by the hook function, the address of the software object to locate and access the saved copy of the virtual method table and looking up the method pointer from among the plurality of method pointers in the saved copy of the virtual method table, and
calling, by the hook function, the dynamically bound method using the method pointer from the saved copy of the virtual method table.”
When a normal module calls the original function, the abuse prevention module may request the original function though the backed up address of the original function (0072). The abuse prevention module 403 may check a browser function extension module requesting the hook function (software object), using information of the browser function extension module placed at an address where the hook function returns, in the hook function. The abuse prevention module may determine whether the module requesting the hook function is a normal module and when it is a normal module, the abuse prevention module may request the backed up original function (0078). As stated above the address of the original function is saved. Therefore, to request the backed up original function the save address (vtable) must be accessed/used.
Kwon et al. does not explicitly appear to teach, “the virtual method table includes a plurality of method pointers to different dynamically bound methods of the software object…” and “determining, by the hook function, an address of the software object using a reference variable that refers to a current object of the dynamically bound method to resolve to an address of the software object,
using, by the hook function, the address of the software object to locate and access the saved copy of the virtual method table and looking up the method pointer from among the plurality of method points in the save copy of the virtual method table”
Fyles et al. teaches a known process of using, a vector table that is modified to use a hook. The hook (hook function) maintains a copy of the original vector table 114, while the entries in the display driver’s vector table 24 are changed to point to routines in the hook. The vector table in the hook only needs entries for the modified routines, although in practice it is often simpler to copy the whole vector table from the display driver. When a routine is called, the pointer associated with it now points not to the entry point in the display driver, but rather to the corresponding routine in the hook (hook function). The routine in the hook (hook functions) then references the vector table 114 (resolves address of software object to locate and access the saved copy of table) in the hook to determine the entry point looking up the method pointer) in the display driver of the routine which was actually called by the application. The display driver routine is then invoked (calling by the hook functions, the dynamically bound method) to ensure the correct action on the screen occurs (column 3, lines 46 – column 4, lines 1-20). Also see figure 3. The examiner states that it would be inherent to one of ordinary skill in the art at that when the hook function of Fyles et al. maintains a copy of the original vector table, that copy will be saved within a memory location. Therefore, when a routine is called, the pointer in the vector table now points to the hook and the routine in the hook is able to then reference (resolves address of the software object to locate and access the saved copy of table) the vector table in the hook (location at a specific address) to determine the entry point in the display drive of the routine which was actually called by the application, which is then invoked. The hook routine must be able to determine/resolve the location/reference in order to perform the intent of the original call that will now use the copy of the table to determine the entry point of the called routine and invoke it.
As proper under MPEP 2143, It would have been obvious to one of ordinary skill in the art before the effective filing date to modify Kwon et al. with a known technique as taught by Fyles et al. because both teach the concept of using a hook within a pointer table and making a copy of at least the called address replaced by the hook. Fyles et al. teaches the vector table in the hook only needs entries for the modified routines, although in practice it is simpler to copy the whole vector table form the display driver (column 3, lines 65 – column 4, lines 1-2_. Therefore, it would have been obvious for Kwon et al. to store not just a copy of the address of the original function but the entire virtual table. It would be simpler as stated in Fyles et al. and is nothing more than a design choice and would have been obvious to try or to apply a known work in one field of endeavor that may prompt variations of it for use in either the same field or a different one to utilize the hooking concept in storing hooked tables. Fyles et al. further teaches that the routine/function of the Hook references the saved vector table and determines the correct routine to invoke. This is also nothing more than a design choice and would have been obvious to try.
As per claim 2, Kwon et al. further teaches, “The method of claim 1, further comprising:
recording, by the hook function, one or more parameters of the call to the dynamically bound method; and
providing the one or more parameters to a threat management facility.
The abuse prevention module 403 may check a browser function extension module requesting the hook function (software object), using information of the browser function extension module placed at an address where the hook function returns, in the hook function. The abuse prevention module may determine whether the module requesting the hook function is a normal module and when it is a normal module, the abuse prevention module may request the backed up original function (0078).
As per claim 3, Kwon et al. further teaches, “The method of claim 1, wherein the software object is a Component Object Model (COM) object, and the dynamically bound method is a COM interface method of the COM object.
The browser object may include an object based on a component object model (COM). The COM-based object has a virtual function table that store addressed of functions (com interface methods) provided by the object to an external location (0061). Also see 0070.
As per claim 4, Kwon et al. further teaches, “The method of claim 1, further comprising:
determining an address of the hook function for the changed method pointer by,
creating an additional software object that includes the hook function, the additional software object having an additional virtual method table, and
reading the address of the hook function from the additional virtual method table.”
Kwon et al. teaches that the abuse prevention module may declare a new function having the same format as the original function and may record an address of the declared new function at the position of the original function in the virtual function table (0073). Kwon et al. also teaches that the abuse prevention module may acquire address information of functions associated with a browser object. The abuse prevention module may acquire the virtual function table, which store addresses of functions associated with the browser object (0070). Therefore, function addresses are read from a virtual function table. The examiner states that it would have been obvious to one of ordinary skill in the art before the effective filing date for Kwon et al. to also record the address of the declared new function from a virtual function table. This is nothing more than a design choice and would have been obvious to try.
As per claim 7, Kwon et al. and Fyles et al. further teach, “The method of claim 1, wherein the modified virtual method table retains a method pointer to at least one other dynamically bound method whose usage is not monitored.”
Kwon et al. teaches that the abuse prevention table may acquire address information of functions associated with a browser object. The abuse prevention module may acquire the virtual function table, which stores addresses of functions associated with the browser object of an internet browser. Kwon et al. teaches that the abuse prevention module may declare a new function having the same format as the original function and may record an address of the declared new function at the position of the original function in the virtual function table (0073).
Fyles et al. teaches, a vector table that is modified to use a hook. The hook maintains a copy of the original vector table 114, while the entries in the display driver’s vector table 24 are changed to point to routines in the hook. The vector table in the hook only needs entries for the modified routines, although in practice it is often simpler to copy the whole vector table from the display driver. When a routine is called, the pointer associated with it now points not to the entry point in the display driver, but rather to the corresponding routine in the hook. The routine in the hook then references the vector table 114 in the hook to determine the entry point in the display driver of the routine which was actually called by the application. The display driver routine is then invoked to ensure the correct action on the screen occurs (column 3, lines 46 – column 4, lines 1-20). Also see figure 3.
As per claims 9, 11, 14-16 and 20, they contain similar limitations to claims 1-3 and 7. Therefore, they are rejected for the same reasons.
As per claims 12 and 17, they contain similar limitations to claim 4 and are therefore rejected for the same reasons.
Claims 5-6, 10, 13 and 18-19 are rejected under 35 U.S.C. 103 as being unpatentable over Kwon et al. (US 2011/0283366 A1) and Fyles et al. (US 5,491,780) as applied to claims 1, 4, 9, 12, 14 and 17 above, and further in view of Ohrt (US 7,389,246 B1).
As per claim 5, Kwon et al. does not explicitly appear to teach, “The method of claim 4, wherein the additional software object is a C++ object.”
Ohrt teaches the most common type of interface implemented in the COM/DCOM software component architectures is the virtual function table (vtable) interface. COM defines a standard way to layout vtables in memory, and a standard way to call functions through vtables. Thus, any lanauge that can call functions via pointers (C, C++, Small Talk.RTM., Ada, and even Basic) can be used to write components that can interoperation with other components written in the same binary standard (column 4, lines 27-33).
It would have been obvious to one of ordinary skill in the art before the effective filing date to modify Kwon et al. with Ohrt et al. because both teach the use of COM objects and vtables. Ohrt teaches that any lanauge such as C++ can be used to call pointers and to write components that can interoperate with other components. This is nothing but a design choice and would have been obvious to try.
As per claim 6, Fyles et al. further teaches, “The method of claim 1, wherein the hook function is a member function of a C++ class and the reference variable is a C++ this keyword that returns the address of the current object of the dynamically bound method, and the hook function uses the address of the current object retuned by the C++ “this” keyword to access the saved copy of the virtual method table.
Fyles et al. teaches, when a routine is called, the pointer associated with it now points not to the entry point in the display driver, but rather to the corresponding routine in the hook. The routine in the hook then references the vector table 114 in the hook to determine the entry point in the display driver of the routine which was actually called by the application. The display driver routine is then invoked to ensure the correct action on the screen occurs (column 3, lines 46 – column 4, lines 1-20). Also see figure 3.
However Kwon et al. and Fyles et al. do not explicitly appear to teach, the use of C++.
Ohrt teaches the most common type of interface implemented in the COM/DCOM software component architectures is the virtual function table (vtable) interface. COM defines a standard way to layout vtables in memory, and a standard way to call functions through vtables. Thus, any lanauge that can call functions via pointers (C, C++, Small Talk.RTM., Ada, and even Basic) can be used to write components that can interoperation with other components written in the same binary standard (column 4, lines 27-33). The examiner states that “C++ this” is a well known C++ pointer to an object.
It would have been obvious to one of ordinary skill in the art before the effective filing date to modify Kwon et al. and Fyles et al. with Ohrt et al. Both Kwon et al. and Ohrt et al. teach the use of COM objects and vtables. Ohrt teaches that any language such as C++ can be used to call pointers and to write components that can interoperate with other components. This is nothing but a design choice and would have been obvious to try.
As per claim 10, 13 and 18-19, contain similar limitations to claims 5-6 and are therefore rejected for the same reasons.
Claims 8 are rejected under 35 U.S.C. 103 as being unpatentable over Kwon et al. (US 2011/0283366 A1) and Fyles et al. (US 5,491,780) as applied to claim 1 above, and further in view of Hunt (US 6983463 B1)
As per claim 8, Kwon et al. does not explicitly appear to teach, “The method of claim 1, wherein the software object includes an interface pointer to an interface, and the interface includes a virtual method table pointer to the virtual method table.”
Hunt teaches by standard, an interface is a pointer to a virtual function table (VTBL). A component client (software object) always accesses an interface though an interface pointer (a pointer to the pointer to a virtual function table) (column 47, lines 23-36).
It would have been obvious to one of ordinary skill in the art before the effective filing date to modify Kwon et al. with Hunt because both teach the use of pointers to a virtual function table. Hunt teaches a known standard in which a pointer points to a interface pointer that points to a virtual function table that points to a function. This is a known standard and would have been obvious to try.
Response to Arguments
Applicant's arguments filed 3/24/2026 have been fully considered but they are not persuasive.
Applicant argues “that Kwon and Fyles do not suggest at least the claimed “determining, by the hook function, an address of the software object using a reference variable that refers to a current object of the dynamically bound method to resolve to an address of the software object” and “using, by the hook function, the address of the software object to locate and access the saved copy of the virtual method table” of claim 1.
Rather than have a hook function determine the address of the software object that includes the dynamically bound method, and then use the address of that software object to locate and access a saved copy of the virtual method table, Kwon lacks a saved copy of a virtual method table, and Fyles suggests that a copy of an original vector table is stored internal to the hook routine, Fyles does not envision the hook routine performing operations to locate and access it, much less suggest the specific operations claimed.
Looking to Kwon in more detail, the reference states that an "abuse prevention module may substitute a hook function for the original function.... Even though the browser function extension module attempts to call the original function, the hook function is substituted for the original function by the abuse prevention module." Kwon at para. 0051-0052 and 0067. In addition, "[t]he abuse prevention module 403 may store and back up an address of the original function." Kwon at para.0072. "When the browser function extension module 404 requesting the hook function is a normal module, the abuse prevention module 403 may request the backed up original function...." Kwon at para. 0078.
Kwon simply states that the "abuse prevention module 403" stores an address of the original function. There is no mention of storing a copy of a virtual method table, much less a teaching that after one is stored it should be located and accessed by determining the address of the software object that includes the dynamically bound method, and then using the address of the software object to locate and access the saved copy of the virtual method table. In relation to this aspect of the claim, the Final Office Action cites to paragraphs 0072 and 0078 of Kwon. However, such portions of Kwon describe storing and accessing the address of Kwon's original function (which has been likened by the Examiner to the claimed dynamically bound method). They do not involve the address of any software object that includes the original function, nor suggest using the address of such software object to locate and access a saved copy of a virtual method table.”
The examiner respectfully disagrees. Applicant states that Kwon lacks a saved copy of the virtual method table. The examiner disagrees. As stated above, Kwon teaches a COM-based object may have a virtual function table that includes addresses of functions (method pointer) of the browser object. The virtual function table stores addresses of functions provided by the object to an external location (0061). An abuse prevention module may store and back up an address of the original function (copy of virtual method table). The abuse prevention module may store and back up an address of the original function corresponding to a position of the original function desired to be intercepted, using the virtual function table (0062). As stated above a virtual function table includes address of functions and Kwon teaches storing and backing up an address of the original function to be called later. Therefore, Kwon only teaches copying just the address of the original function and therefore is only copying part of the function table and not the whole table. The saving of a copy of the entire virtual method is taught by Kwon in view of Fyles. Applicant further argues that Fyles suggests that a copy of an original vector table should be stored internal to a hook routine and that Fyles does not envision the hook routine performing operations to locate and access it, much less suggest the specific operation as claimed. The examiner first states, that where the copy of an original vector table is stored is not claimed, this allows it to be anywhere, including inside the hook routine of Fyles. Regarding Fyles not envisioning the hook routine performing operations to locate and access it, much less suggest the specific operation as claimed, the examiner disagrees. Please see above rejection regarding these new limitations.
Applicant further argues, “The deficiencies of Kwon are not addressed by combination with Fyles. Fyles states that a "vector table is modified ... by the use of a hook 110.... The hook maintains a copy of the original vector table 114, while the entries in the display driver's vector table 24 are changed to point to routines in the hook." Fyles at col. 3, lines 56-60. When a routine is called, "the pointer associated with it ('LOC*') 104 now points not to the entry point in the display driver, but rather to a corresponding routine ('XXX') 118 in the hook." Fyles at col. 4, lines 9-15. The corresponding routine 118 in the hook uses the copy of the original vector table 114 in the hook "to determine the entry point ('LOC') 116 in the display driver" so it can be run as well. Fyles at col. 4, lines 16-19.
Fyles simply describes that a copy of an "original vector table 114" is stored internal to a "hook 110." Since the copy of the "original vector table 114" is stored internal to the hook routine, Fyles does not envision performing operations to locate and access it, much less specifically having the "hook 110" determine an address of the software object that includes the vector table, and then using that address to locate and access the copy of the "original vector table 114."
The examiner disagrees. Nothing in Fyles states that “since a copy of the “original vector table 114” is stored internal to the hook routine, Fyles does not envision performing operations to locate and access it, much less specifically having the “hook 110” determine an address of the software object that includes the vector table, and then using that address to location and access the copy of the “original vector table 114”. This seems to be nothing more than a opinion. Please see the examiners rejection regarding this new limitation above.
Applicant's arguments fail to comply with 37 CFR 1.111(b) because they amount to a general allegation that the claims define a patentable invention without specifically pointing out how the language of the claims patentably distinguishes them from the references.
For these reasons the current rejection stands.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MARK A GOORAY whose telephone number is (571)270-7805. The examiner can normally be reached Monday - Friday 10:00am - 6:00pm.
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, Lewis Bullock can be reached at 571-272-3759. 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.
/MARK A GOORAY/ Examiner, Art Unit 2199
/LEWIS A BULLOCK JR/ Supervisory Patent Examiner, Art Unit 2199
Prosecution Insights