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 o n 01 / 17 /202 3 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner. Examiner’s Note (EN) The prior art rejections below cite particular paragraphs, columns, and/or line numbers in the references for the convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant fully consider the references in their entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art. Claim Rejections - 35 USC § 112 The following is a quotation of 35 U.S.C. 112(b): (b) CONCLUSION. —The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention. The following is a quotation of 35 U.S.C. 112 (pre-AIA), second paragraph: The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention. Claim s 7-8 and 17-18 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention. The claims recite defective code however, the specification fails to define what is considered as ‘defective’. It’s customary for code to have bugs, at what point is it considered ‘defective’. Claim Rejections - 35 USC § 103 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, 9-14, and 19- 20 are rejected under 35 U.S.C. 103 as being unpatentable over Grier et al. ( US20020100017A1 ) in view of Dawson et al. ( US20130239128A1 ) Regarding Claim 1 , Grier teaches a computer-implemented method for code component sharing across software product versions for product development, the method comprising: configuring one or more shared code components for functions of a first version of a product to be used by a second version of the product for the functions in the second version ([0004-0005] "For example, both newer and older applications end up sharing the same component, whereby over time, fixing and improving the component becomes increasingly difficult. Moreover, the practical functionality of a component is not easily defined. For example, some applications may utilize unintended side effects in a component that are not considered part of the core function of the component, e.g., an application may become dependent on a bug in a component, and when the component publisher chooses to fix that bug, the application fails. Of course, on the other side, application writers cannot test future versions of components. As a result, problems occur when a component is updated to its newer version, such as when a new application or operating system service pack is installed with updated copies of components, as the newly installed component versions become the ones used by other applications and components on the system. The sheer volume of applications and components that rely on other components magnifies this problem, which is sometimes referred to as “DLL Hell.” [0008] "the present invention provides a method, system and infrastructure that allow an application to run with specified versions of components bound thereto, while allowing the application author and/or component publisher to change the version as desired." [0010-0011] "In this manner, the present invention enables applications to explicitly use different versions of assemblies from what the application as originally shipped had specified. This allows for exact management and control of assemblies during the lifecycle of the application. To determine the correct version, at runtime, in the first mode, the present invention first interprets the application manifest (e.g., released with the application), followed by a publisher configuration, if present, that may redirect (re-map) any assembly versions specified in the application manifest to other assembly versions. Then, if an application configuration is present, the application configuration is interpreted to redirect some or all of the current binding information, e.g., for the current assembly version to another assembly version, as specified therein. In the second alternative mode, the present invention first interprets the application manifest (e.g., released with the application), followed by the application configuration, if present, that may redirect (re-map) any versions specified in the application manifest to other versions. Then, if a publisher configuration is present, and the application configuration does not bypass the publisher configuration via a special safe mode, the publisher configuration is interpreted to (possibly) redirect the current binding information, e.g., for that assembly version to another assembly version, as specified therein. Lastly, any administrator configuration is interpreted to (possibly again) change the bindings to assembly versions." [0049-0050] "In accordance with one aspect of the present invention, the operating system (e.g., including an assembly loading mechanism) can bind the application to another version of a needed assembly in place of one specified in the application manifest 204 . To this end, configuration information that is separate from the shared assembly may be interpreted to determine which version to bind. Note that a configuration is separate from the shared assembly or assemblies to which it refers, for example, in that it is a separable entity therefrom, normally contained as a file, that can be added to or removed from a system at a later time, and so on. In a first alternative mode, as shown in FIG. 2A, an assembly publisher can issue a publisher configuration 220 with data 222 therein that redirects a requested assembly version (e.g., requested via the manifest or the application configuration) to one that is specified by the assembly publisher. In general, a publisher configuration file applies to a single assembly, although a single assembly may have multiple associated publisher configuration files. Note that a publisher configuration applies to any application in the system that uses the corresponding assembly. The publisher configuration enables an assembly publisher to effectively replace one assembly version with another version, such as when a service pack is installed. As described herein, in a first alternative mode, the assembly publisher configuration is interpreted after the manifest is interpreted, and thus can change an assembly initially specified by the application author. For example, in FIG. 2A, the publisher configuration 220 may include data that redirects the binding specified in the manifest (version 1.0.0.0) to version 2.0.0.0 (shared assembly x 208 2 )." Where [0003] defines: "a component is a self-contained software entity, offering a set of functions that can be used by a variety of applications.") routing intercepted use to the shared code component of the first version ([0013] "At runtime, when a program requests creation of a global object, the operating system automatically consults the activation context built from the application and configurations to locate and load the appropriate assembly version. The operating system also maps any uses of this named object to the appropriate version to allow for multiple versions of the code module to run simultaneously without interfering with each other. By the activation context built from the application manifest and the configurations, an application may be efficiently bound to specific assembly versions and thereby be isolated from assembly version changes.") using cross-version communication of a shared operating system between the first version and the second version to use the shared code component on the first version for the intercepted use of the function ([0038] "Assemblies can be shared, such as when more than one application or the like needs an instance of the assembly's code. To provide significant flexibility while being transparent to existing and newly-developed applications, the present invention has been implemented in an operating system, with applications being run via the operating system." [0042] "The application, manifest and assemblies, both privatized and global, are installed to their appropriate file system locations at the time the application or assembly is installed. In general, the application, application manifest and privatized assemblies (those not strongly named) are copied to the application folder, while strongly named assemblies may be copied to the global assembly cache 212 (e.g., one or more folders). Note that to provide side-by-side existence of assembly versions, any existing assembly versions are not overwritten in the assembly cache 212 when another version is installed, (although a version can be removed by other means, at the risk of breaking an application that depends on that version). The assembly cache can be hidden and/or access controlled to prevent assemblies from being easily removed. " [0049] "In accordance with one aspect of the present invention, the operating system (e.g., including an assembly loading mechanism) can bind the application to another version of a needed assembly in place of one specified in the application manifest 204 . To this end, configuration information that is separate from the shared assembly may be interpreted to determine which version to bind." [0014] "At runtime, when a program requests creation of a global object, the operating system automatically consults the activation context built from the application and configurations to locate and load the appropriate assembly version. The operating system also maps any uses of this named object to the appropriate version to allow for multiple versions of the code module to run simultaneously without interfering with each other. By the activation context built from the application manifest and the configurations, an application may be efficiently bound to specific assembly versions and thereby be isolated from assembly version changes." Also see [0012-0013]) However, Grier doesn’t appear to explicitly teach: intercepting a use of a function of the second version equivalent to a function of a shared code component of the first version Dawson teaches intercepting a use of a function of the second version equivalent to a function of a shared code component of the first version ([0020] " in response to a request, from one of the target processes that are brought to the safe point, to access a target function in the shared library, the request may be directed to a special function in the dynamic loader. As mentioned earlier, the shared text section of the shared library may be modified to include a reference to the special function in the shared library. Upon receiving the request, the special function may determine whether a shared patch library, comprising a patched version of the target function or a new function, is loaded for the target process that had made the request. In response to determination that the shared patch library is not loaded for the target process, dynamic loader may load the shared patch library for the target process, and route the request for the target function to the patched version of the target function or the new function, in the shared patch library. Thus, the target function in the shared library is patched. Any subsequent call to the target function by the same process may get directed, by the DLD, to the patched version of the target function or the new function, in the shared patch library. It may be noted that the dynamic loader loads the shared patch library only for the target process that had made the request.") Grier and Dawson are analogous art because they are from the same field of endeavor in cross version code sharing and execution . Before the effective filing date of the invention, it would have been obvious to a person of ordinary skill in the art, to combine Grier and Dawson to incorporate Dawson’s function interception mechanics into Grier’s version binding and sharing architecture with expected results. A PHOSITA would do so to have more granular control of routing to specific functions in the versioned libraries. Regarding Claim 2 , Grier in view of Dawson teaches t he computer-implemented method of claim 1 . Grier teaches further comprising: defining how to call the one or more shared code components that are configured to be used from the first version when required by the intercepted use ([0046] "Each assembly manifest describes the assembly and includes information about its individual assemblies, including, for example, the name and version of the assembly, the items (program files, resources) that make up the assembly, and the binding path to items within the assembly (e.g., for Win32 DLLs this is the location of the DLL relative to the root of the assembly, whereas for COM Servers this is the CLSID (class identifier), ProgID (programmatic identifier) and other COM metadata). The assembly manifest may also include any dependencies on other assemblies, object classes and global names." Also see [0072-0073] and [0079] "To map the application's requests to the proper assembly versions, the activation context 302 includes a DLL redirector section 404 and an object class redirector section 406 . The DLL redirector section 404 includes a record or the like for each DLL dependency that includes fields (e.g., 408 , and 409 1 ) that relate the DLL name used by an application to the exact pathname of the version determined following the above-described configuration-resolution process.") Regarding Claim 3 , Grier in view of Dawson teaches t he computer-implemented method of claim 1 . Grier teaches further comprising: allowing a request from the second version to use equivalent one or more code components at the second version overriding or changing a configuration ([0052] "As also represented in FIG. 2A, an application configuration 216 including updated assembly version dependency data 218 may be stored in the application folder 202 to similarly override some or all of the information in the application manifest 206 and/or any modification by the publisher configuration 220 . For example, as represented in FIG. 2A, the application configuration 218 may include data (e.g., an instruction) that redirects the current binding from version 2.0.0.0 to version 3.0.0.0 (the shared assembly x 208 3 ), e.g., redirect version 2.0.0.0 to version 3.0.0.0. In this manner, an application author can effectively update a manifest and/or override a publisher configuration by distributing such a configuration 216 , without having to actually make changes to the application manifest 204 or have a new one reinstalled. Note that other instructions directed to other dependent assemblies may be in the same configuration, and that there may not be any relevant instruction for a given assembly." Also see [0055-0057]) Regarding Claim 4 , Grier in view of Dawson teaches t he computer-implemented method of claim 1 . Grier teaches further comprising: ensuring a running of a process on the first version of the product ([0013]) monitoring a running of a process on the second version of the product for use of a function of the second version equivalent to a function of a configured shared component of the first version ([0082] "When the application API 300 1 receive the request, the request data (e.g., the application provided name) is passed to a runtime version-matching mechanism 500 (the arrow labeled two ( 2 )). The runtime version-matching mechanism 500 locates the correct activation context 302 (from among a store 502 or the like of those maintained) for the calling application 200 , and accesses the records therein to determine the correct version of the requested assembly (the arrows labeled three ( 3 ) and four ( 4 )). Via the tables in the activation context 302 , the runtime version-matching mechanism 500 will either return (e.g., as a return parameter, with the arrow labeled five (5)) the path and filename of the version-specific assembly, or a not-found status or the like (and/or the path and filename of the default file) to the activation API that called it, in which case the activation API will load the default assembly. As represented in FIG. 5 by the arrows labeled six (6) through eight (8), the activation API 300 1 accesses the assembly cache 212 to load the correct version of the assembly. Note that alternatively, the runtime version-matching mechanism 500 may access the assembly cache 212 on behalf of the calling API 300 1 to obtain and/or load the correct version, which is either the one listed in the records or the default version if none was found. Further, note that privatized assemblies may be loaded from the application directory. In any event, the correct assembly version 510 is loaded and the activation API 300 1 returns from the call to the application 200 , (the arrow labeled nine (9)), and the application can use the loaded assembly 510 (the arrow labeled ten (10))." EN: The system loads and monitors the library is actively loaded before returning the call to the application. ) Regarding Claim 9 , Grier in view of Dawson teaches the computer-implemented method of claim 1 . Grier teaches wherein a shared code component of the first version is equivalent to a missing code component of the second version ([0079-0080] "To map the application's requests to the proper assembly versions, the activation context 302 includes a DLL redirector section 404 and an object class redirector section 406 . The DLL redirector section 404 includes a record or the like for each DLL dependency that includes fields (e.g., 408 , and 409 1 ) that relate the DLL name used by an application to the exact pathname of the version determined following the above-described configuration-resolution process. The object class redirector section 406 includes a record or the like for each object class (e.g., Windows® object class) on which an application depends, wherein each record includes fields (e.g., 412 1 , 413 1 , and 414 1 ) that relate the object class name used by an application to the DLL file it is in and a version specific name. Note that the fields are arranged in a manner that optimizes lookup, e.g., the application-provided request data corresponds to the search key, and the records may be arranged in any way (e.g., alphabetically, by frequency, linearly, binary or so on) to speed searches. Via the activation context, during runtime as described below, an application's requests for assemblies can be efficiently satisfied with the correct version of that assembly. I f a given assembly is not found in the activation context data, the default assembly is used." and [0093] "Beginning at step 900 the activation API receives the application request including the version-independent assembly name, not the version specific name, and passes it as a parameter or the like to the runtime version matching mechanism, where it is received at step 902 . If an entry for the name is in the activation context at step 904 , the runtime version matching mechanism returns the version specific information (e.g., including the path and filename of the correct version) based on the manifest at step 906 . If an entry for the name is not found in the activation context at step 904 , at step 908 the runtime version matching mechanism returns a not found status, (or alternatively can determine and return the path and filename of the default version)." Regarding Claim 10 , Grier in view of Dawson teaches the computer-implemented method of claim 1 . Grier teaches wherein the cross-version communication is cross-memory communication or inter-process communication of the shared operating system of the first and second versions of the software product (C, [0012-0014], [0042], [0049]) Regarding Claims 11 and 20 , Grier teaches a computer system for code component sharing across software product versions for product development, comprising: a processor and a memory configured to provide computer program instructions to the processor to execute functions of components of a component sharing tool provided on a shared operating system of a first and second version of a software product, the component sharing tool including ([0028] “ The invention is operational with numerous other general purpose or special purpose computing system environments or configurations. Examples of well known computing systems, environments, and/or configurations that may be suitable for use with the invention include, but are not limited to, personal computers, server computers, hand-held or laptop devices, multiprocessor systems, microprocessor-based systems, set top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, distributed computing environments that include any of the above systems or devices, and the like. ”) The remaining limitations are similar to claim 1 and are rejected under the same rationale. Claims 12-14 and 19 are system claims reciting limitations similar to claims 2-4 and 10 respectively and are rejected under the same rationale. Claims 5-8 and 1 5 -18 are rejected under 35 U.S.C. 103 as being unpatentable over Grier et al. ( US20020100017A1 ) in view of Dawson et al. ( US20130239128A1 ) and further in view of Yenne et al. ( US20020138788A1 ) Regarding Claim 5 , Grier in view of Dawson teaches the computer-implemented method of claim 1 . Yenne teaches wherein the one or more shared code components of the first version are used in debugging the second version ([0006] “ Debugging is not usually performed in distributed, run-time versions of programs, although debug information beyond the minimal run-time error messages, previously described, could be helpful to isolate and fix bugs that inevitably occur even in release and later versions of software applications. One reason that only the minimal run-time error messages have been included in run-time versions of programs has been the desire for speedy and efficient operations of those programs. Conventional debugger tools are typically complex and computing- and time-intensive to operate, and do not lend themselves to ready operation in run-time circumstances. Nonetheless, more extensive and comprehensive debug information could be helpful to remedy bugs in run-time software, if these problems of conventional debuggers are overcome. ” Also see [0007-0008] [003 8-003 9] “ In the method 600 , the pre-processed code with inserted trace points is hooked to a shared library of function calls in a step 602 . The hook to the shared library is achieved via the insertion of a hook or other coded call at a first line of the code. The hook is inserted, for example, along with insertions of the trace points in the steps 202 , 204 . The shared library is the conventional collection of library routines of the standard compiler for the particular source language of the application software, for example, C++ or other language. As is common, each function call appropriate to the particular source language of the program has a corresponding library routine that executes the function. The shared library is the source of the routines corresponding to the function calls of the program … If the method 600 has previously been performed for the code or a predecessor version of the code, then an existing trace database 500 could be available. Otherwise, the function will not be found in an existing trace database 500 , and the method 600 proceeds to a step 610 of creating the trace database 500 . If there is any existing trace database 500 of the code or predecessor versions which includes the function corresponding to the particular function call, then a step 612 modifies by adding to the trace database 500 if there has been any change to the source code then being handled by the method 600 . ” ) Grier, Dawson, and Yenne are analogous art because they are from the same field of endeavor in resolving errors in versioned program execution. Before the effective filing date of the invention, it would have been obvious to a person of ordinary skill in the art, to combine Grier, Dawson, and Yenne to incorporate Yenne’s tracing and debugging framework into Grier’s version binding and sharing architecture and Dawson’s function interception with expected results. A PHOSITA would do so to identify specific functions causing execution errors in order to fix them especially when rolling out new updates . Regarding Claim 6 , Grier in view of Dawson and further in view of Yenne teaches the computer-implemented method of claim 5 . Yenne teaches wherein the one or more shared code components are message, trace, and dump code components (Fig. 6, [0038-0039] "In the method 600 , the pre-processed code with inserted trace points is hooked to a shared library of function calls in a step 602 . The hook to the shared library is achieved via the insertion of a hook or other coded call at a first line of the code. The hook is inserted, for example, along with insertions of the trace points in the steps 202 , 204 . The shared library is the conventional collection of library routines of the standard compiler for the particular source language of the application software, for example, C++ or other language. As is common, each function call appropriate to the particular source language of the program has a corresponding library routine that executes the function. The shared library is the source of the routines corresponding to the function calls of the program. The method 600 then proceeds with a step 604 in which a next line of the code (i.e., the pre-processed code with inserted trace points) is read. In a step 606 , the line of code is assessed to determine if the line includes a function call. A look-up operation is then performed in a step 608 for the function corresponding to the function call. The look-up is performed in trace database 500 of FIG. 5 created by the method 600 . The trace database 500 associates a unique identifier (i.e., trace id) with each trace point within the code. If the method 600 has previously been performed for the code or a predecessor version of the code, then an existing trace database 500 could be available. Otherwise, the function will not be found in an existing trace database 500 , and the method 600 proceeds to a step 610 of creating the trace database 500 ." [0006] "Debugging is not usually performed in distributed, run-time versions of programs, although debug information beyond the minimal run-time error messages , previously described, could be helpful to isolate and fix bugs that inevitably occur even in release and later versions of software applications." [0037] "The trace database 500 is a relational database that relates the unique trace ids with the particular trace points, and also includes relevant interpretive information regarding occurrences at trace points of the code during run-time execution. As shown in FIG. 5, the trace database 500 communicates with a reporter 502 and a snap output 504 of run-time occurrences at the trace points of the code, in order to relate appropriate trace identification and interpretive information of the database 500 uniquely to each of the trace points then included in the snap detection and the occurrences then encountered at the trace points at the instant of the snap detection." EN: The snap output is a dump.) the computer-implemented method further including formatting a trace and dump from the first version to see diagnostics produced by the second version ([0038] " In this manner, the database 500 together with the output reporter 502 provides readable and understandable trace information for the applicable trace points. The trace information, in such form, is made available from the system by the reporter 502 , such as, for example, a printer or display. The reporter 502 , for example, provides the useable trace information in text, HTML, or other format. ") Regarding Claim 7 , Grier in view of Dawson teaches the computer-implemented method of claim 1 . Grier teaches wherein a shared code component of the first version is equivalent to a defective code component of the second version, the computer-implemented method further including: using the one or more shared code components of the first version in order to install trace options or test programs on the second version ([0004-0005] "For example, both newer and older applications end up sharing the same component, whereby over time, fixing and improving the component becomes increasingly difficult. Moreover, the practical functionality of a component is not easily defined. For example, some applications may utilize unintended side effects in a component that are not considered part of the core function of the component, e.g., an application may become dependent on a bug in a component, and when the component publisher chooses to fix that bug, the application fails. Of course, on the other side, application writers cannot test future versions of components." [0055-0056] "Lastly, in this second mode, an administrator configuration 224 and its version data 226 may have the final decision as to which version of an assembly an application (any application on the machine) will be bound. For example, in FIG. 2B, the administrator configuration 224 is stored as a file in a system folder 228 and includes data 226 that redirects the current binding to an earlier version , version 3.0.0.0 (shared assembly x 208 3 ), as shown in FIG. 2B via the arrow from block 226 to block 208 3 . As can be understood, the administrator configuration 224 allows an administrator or the like to bind any system applications to a new assembly, or a restore a binding to an older assembly, (e.g., version 4.0.0.0 back to version 3.0.0.0 as shown in FIG. 2B), and so on, regardless of what other configurations may specify. With the various configurations, updates to applications via new assemblies are possible, but only in a safe, controlled manner, with the machine administrator having the final determination. Although complete compatibility of a shared assembly should be thoroughly tested, even the smallest change to a shared assembly's code may cause an incompatibility with some applications that consume them. In such an event, in the second alternative mode wherein the publisher configuration data can override the application configuration data, the application configuration file may specify that “safe mode” binding should be applied to the specified assembly. In the safe mode, the publisher configuration resolution stage is avoided, whereby the application operates with no publisher configuration overrides. To use the safe mode, the application configuration 218 (or other system setting, e.g., set by an administrator) can explicitly instruct the operating system to bypass the interpretation of the publisher configuration 220 , whereby the application author (or an administrator) controls the version that is bound to the application." Also see [0057]. EN: Yenne provides the trace mechanisms in [0037-0039] ) For motivation to combine please see claim 5. Regarding Claim 8 , Grier in view of Dawson and further in view of Yenne teaches the computer-implemented method of claim 7 . Grier teaches further including: requesting use of the defective code component of the second version to test it ([0055-0057] teaches requesting the use of the prior version before rolling to the updated one, or loading the updated version. " Lastly, in this second mode, an administrator configuration 224 and its version data 226 may have the final decision as to which version of an assembly an application (any application on the machine) will be bound. For example, in FIG. 2B, the administrator configuration 224 is stored as a file in a system folder 228 and includes data 226 that redirects the current binding to an earlier version , version 3.0.0.0 (shared assembly x 208 3 ), as shown in FIG. 2B via the arrow from block 226 to block 208 3 . As can be understood, the administrator configuration 224 allows an administrator or the like to bind any system applications to a new assembly, or a restore a binding to an older assembly, (e.g., version 4.0.0.0 back to version 3.0.0.0 as shown in FIG. 2B), and so on, regardless of what other configurations may specify … With the various configurations, updates to applications via new assemblies are possible, but only in a safe, controlled manner, with the machine administrator having the final determination. Although complete compatibility of a shared assembly should be thoroughly tested, even the smallest change to a shared assembly's code may cause an incompatibility with some applications that consume them." EN: Yenne’s tracing allows for the detailed testing and debugging. ) Claims 1 5 -1 7 are system claims reciting limitations similar to claims 5-7 respectively and are rejected under the same rationale. Regarding Claim 18 , Grier in view of Dawson teaches the computer system of claim 11. Grier teaches wherein one or more code components of the second version are defective code components in the second version of the product; and the computer system including a defective replacement component for using the one or more shared code components of the first version in place of the one or more defective code components of the second version ([0055-0057] teaches requesting the use of the prior version before rolling to the updated one, or loading the updated version. "With the various configurations, updates to applications via new assemblies are possible, but only in a safe, controlled manner, with the machine administrator having the final determination. Although complete compatibility of a shared assembly should be thoroughly tested, even the smallest change to a shared assembly's code may cause an incompatibility with some applications that consume them.") Yenne teaches in order to install trace or test programs on the second version ( [0037-0039] ) For motivation to combine see claim 5. Conclusion The prior art made of record and not relied upon is considered pertinent to applicant's disclosure . Clark ( US20070261044A1 ) : discloses function substitution across versions for performing predetermined modifications. B r aude ( US20110239194A1 ): discloses cloning functions for instrumentation purposes and dynamically intercepting and directing the execution flow to the instrumented functions. Any inquiry concerning this communication or earlier communications from the examiner should be directed to FILLIN "Enter examiner's name" \* MERGEFORMAT AMIR DARWISH whose telephone number is FILLIN "Phone number" \* MERGEFORMAT (571)272-4779 . The examiner can normally be reached FILLIN "Work schedule?" \* MERGEFORMAT 7:30-5:30 M-Thurs . 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, FILLIN "SPE Name?" \* MERGEFORMAT Lewis Bullock can be reached on FILLIN "SPE Phone?" \* MERGEFORMAT 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. /A.E.D./ Examiner, Art Unit 2187 /LEWIS A BULLOCK JR/ Supervisory Patent Examiner, Art Unit 2199