DETAILED ACTION
Claims 1-3, 5, 7, 9-10, and 20-32 are presented for examination.
Claims 1-3, 5, 7, 9-10, and 20 have been amended.
Claims 4, 6, 8 and 12-19 have been cancelled.
Claims 21-32 are new.
This office action is in response to the amendment submitted on 25-JUN-2026.
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 .
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.
Response to Arguments – 35 USC 103
Applicant’s arguments with respect to the 103 rejections have been considered, but are moot in view of the new ground(s) of rejection provided below.
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-3, 9-10, 20-22, 24, 26 and 28-30 are rejected under 35 U.S.C. 103 as being unpatentable over Grier et al. (US20020100017A1) in view of Saboff et al. US6154878A)
Regarding Claim 1, Grier teaches a method comprising:
Ensuring a first running of a first version of a software product ([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.")
Monitoring a second running of a second version of the software product ([0013] and [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.)
configuring one or more shared code components for multiple functions of the first version to be used by the second version of the software product ([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 assemblyx 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 based on the modified address entry, execution control from the second version to the one or more shared code components of the first version ([0012-0013] "In an alternative mode such as the second alternative mode, the tables or other binding data may be dynamically recalculated. 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 [0077-0079])
in response to the routing, using cross-version communication of a shared operating system between the first version and the second version to use the one or more shared code components on the first version so that the first version performs the multiple functions ([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 is not relied upon for:
modifying an address entry in a control table used by the second version to redirect execution of the multiple functions to the first version; during running of the second version
Saboff modifying an address entry in a control table used by the second version to redirect execution of the multiple functions to the first version; during running of the second version (Col 16-17, Ln. 62-40 "The preferred embodiment of the present invention optimizes the process described above by keeping a pointer for most current version of the implementation library, if possible, therefore eliminating the need to branch to the proxy interface except when the implementation library has been updated. This optimization eliminates unnecessary jumps in software and therefore, makes calling the implementation library more efficient. In the preferred embodiment, a pointer linkage table, keeps an address pointer of the desired location for the application to branch to, to find the most recent version of the implementation library.
As shown in FIG. 17, the application 600, upon executing code calling a function in the implementation library 604, retrieves an address for the function from the pointer linkage table 602. The pointer linkage table has an entry for every function in an implementation library 604. If the implementation library 604 has not changed since the last time it was called, the entry in the pointer linkage table 602 will still have the address as of the last call to the function. The application will then call the existing implementation library 604 directly without branching to the interface library.
However, if the implementation library has changed, the library and memory management libraries 606 will receive a signal indicating the change. As shown in FIG. 18, the library management library will need to determine if the old version of the implementation library is in use. If it is, the pointer linkage table 602, is updated to point to the proxy interface in the interface library 601, leading to the application 600 calling the proxy interface in the interface library 601, which will handle the change of the implementation library 624 as described above. Upon completion of the update, the pointer linkage table is updated to point to the new version of the implementation library 624. If the implementation library is not currently in use, the new interface library 624 will be loaded, the old library destroyed and the pointer linkage table 602 then updated to point to the new implementation library 624, once again bypassing the proxy interface in the interface library 601." Also see Grier [0063-0082])
Grier and Saboff 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 Saboff to incorporate Saboff’s known method of using address pointers and updating them dynamically into Grier’s version binding and sharing architecture with expected results. A PHOSITA would do so to dynamically update references to various components at run time.
Regarding Claim 2, 21, and 29, Grier in view of Saboff teaches the 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 routing ([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, 22, and 30, Grier in view of Saboff teaches the 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 that required the routing to the first version ([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 assemblyx 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 9 and 24, Grier in view of Saboff teaches the method of claim 1. Grier teaches wherein a shared code component of the one or more shared code components 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. If 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 and 26, Grier in view of Saboff teaches the method of claim 1. Grier teaches wherein the cross-version communication is 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 20 and 28, Grier teaches a computer program product comprising:
a computer readable storage medium; and program instructions embodied with the computer readable storage medium and for causing operations to be performed comprising ([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 5, 7, 23, 25, 27 and 31-32 are rejected under 35 U.S.C. 103 as being unpatentable over Grier et al. (US20020100017A1) in view of Saboff (US6154878A) and further in view of Yenne et al. (US20020138788A1)
Regarding Claim 5 and 23, Grier in view of Saboff teaches the 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] [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…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, Saboff, 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, Saboff, and Yenne to incorporate Yenne’s tracing and debugging framework into Grier’s version binding and sharing architecture 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 7 and 25, Grier in view of Saboff teaches the method of claim 1. Yenne teaches wherein the cross-version communication is cross-memory communication of the shared operating system of the first and second versions of the software product ([0014] “Another embodiment of the invention is a method of sharing memory for run-time tracing. The method includes executing a program. The program includes a function call to a function routine and a trace id corresponding to and identifying the function call. The method also includes addressing the shared memory at an offset of an address of a dedicated memory and replicating a state of the dedicated memory in the shared memory as dictated by the step of addressing.” Also see [0042-0046])
For motivation to combine see claim 5.
Regarding Claim 27, 31, and 32, Grier in view of Saboff and further in view of Yenne teaches the method of claim 20. Yenne teaches wherein the multiple functions comprise message, trace, and dump functions (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.)
wherein the performing comprises the first version formatting a trace and a dump to generate diagnostics for 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. " EN: The first version executes, capturing trace and dump of the second version)
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.
Braude (US20110239194A1): discloses cloning functions for instrumentation purposes and dynamically intercepting and directing the execution flow to the instrumented functions.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to AMIR DARWISH whose telephone number is (571)272-4779. The examiner can normally be reached 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, Lewis Bullock can be reached on 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 2199
/DUY KHUONG T NGUYEN/Primary Examiner, Art Unit 2199
Prosecution Insights