| This was interesting!
The first action from the Canadian Examiner was as follows:
|
| This looks pretty awful. Nearly all the claims are rejected. To a layman this sounds terrifying. Imagine our surprise to read the accompanying letter from our attorneys, in which they state that none of the issues were substantive. |
|
Here are the amendments we had to sell to the examiner: C0110315
IN THE CANADIAN PATENT OFFICE Applicant: REC Software, Inc.
To:
Dear Sir:
In response to the Office Action dated 14 December, 1995 please substitute the enclosed replacement pages 15, 15/2, 15/3, and 15/4 containing amended and new claims for the corresponding pages presently on file in the Patent Office. REMARKS The Examiner rejected claim 9, under Section 34(2), as being indefinite because the term "association" recited in element (d) is not elaborated upon and is not connected to the other recited elements, and it is not clear if "module informa-tion" recited in element (b) is the same as the one in recited element (c) . Claim 9, section (d), has been amended to relate the term association to the preamble which further defines the term association. Association is also defined in applicant's specification at page 6, lines 34-37 and page 7, lines 12-22. Claim 9, section (c), has been amended to clarify that "module information" recited in element (b) is the same as the one in recited element (c). The Examiner rejected~claim 23, under Section 34(2), as being indefinite because the term "the search order" has no antecedent. Claim 23 has been amended by adding a new element (e) to provide antecedent for the "search order". The Examiner rejected claim 23, under Section 34(2), as indefinite because the term "means for said updating module information table" has no antecedent, and element (c) has an extra word "to." Claim 24 has been amended to remove the term "said" in the above identified phrase, and eliminate the additional word "to." Pursuant to Rule 40, corresponding United States and European Patent applications are currently pending. Additional prior art cited in corresponding applications, together with the IBM technical Disclosure Bulletin, is provided herewith. The code server is used in combination with an operating system and an environment which processes coded programs comprised of discrete code modules which may have embedded references therein to other discrete modules (multi-module system). More specifically, the code server assists the operating system by providing module information which is used by the operating system to define the interrelationships between various code modules prior to execution of the coded program. The code server maintains its own set of module information independent of that which the operating system creates between various code modules for forming an association for the loading and execution of such code modules. ("Association, as defined in applicant's specification [page 6, lines 34-37; page 7, lines 12-22] and as used in his claims, generally refers to linkages used in operating systems such as OS/2 from IBM or Windows 3.x from Microsoft for the loading and execution of code modules.) This module information is located and stored in a module inform-ation table by the code server as the operating system makes requests to the code server for the requested code modules. The module information is also provided to the operating system for its own creation of an internal linkage table. Once the module information has been located the first time by the code server, an operating system that later requests the same module informa-tion from the code server that is now contained in the latter's module information table is quickly retrieved by reading the module information therein, thereby eliminating the time-consuming task of searching the network to obtain the module information. The code server therefore provides a central server for the distribution and storage of code module information specifically for an operating system that processes discrete modules containing references to other discrete modules. "Dynamic linking" is a process performed by an operating system in a multi-module environment and traditionally refers to a two-stage process. Stage one of the process involves the operating system inspecting a code module for embedded references to other discrete modules. If the operating system does not already possess the linkage information for the referenced coded modules in its linkage table it will initiate a search for those unresolved code modules and extract linkage information from each. This process continues recursively until the operating system has formed a complete association and has thereby created entries regarding the individual code modules in its linkage table. Stage two of the dynamic linking process involves actually loading into memory a code module during execution-time of the program, which may involve the use of descriptor tables, as described in Horn, European Patent Publication No. 0,336,552 A2. This can be done either by loading all referenced code modules at the beginning of execution-time or loading each code module as it is referenced by another code module. After a code module is loaded, the calling code module or the table that it points to may be modified so that it now calls the address of the loaded code module. Horn, European Patent Publication No. 0,336,552 A2 discloses a method used by an operating system suitable for applications executing multiple loadable program units, generally related to stage 2 as described above. The operating system permits the application to externally reference segments not included in the application's executable code through "dynamic linking", as previously described. These external references include application program interface codes to special program dynamic link libraries, DLLs, which contain run-time API function codes. The part of the operating system's kernel responsible for loading programs from other media, such as a hard file, into memory is called the loader. A loader portion of the system kernel resolves intersegment references to segments in the dynamic link libraries during loading. The loader resolves these references to segments by using special program libraries called dynamic link libraries. When a program is loaded that contains an external reference to a dynamic link library the loader resolves inter segment references. This resolving which occurs during the execution of a program includes assigning the segment a selector and storing the actual segment in the global descrip-tor table and local descriptor table and resolves the address of the function to its selector and offset. Each application has its own descriptor table, called a local descriptor table containing segments private to the application, as well as a replica of the global descriptor table, containing the applica-tion access to system segments. Subsequent applications referencing the same function have their external references resolved to the same selector and offset. This method of using a dynamic link library, selectors, and descriptor tables, all occurs during the execution of a program to result in the benefit of requiring only one copy of the API code for the entire application program. The local and global descriptor tables allocate system memory for the location of code modules during execution of the program. Horn addresses issues relating to the actual loading and execution of the code modules, which is a process that occurs during the execution of a multimodule program. However, Horn does not address the issue of defining the interrelationships between the discrete code modules of the multimodule program, which is generally referred to as stage one, as previously described. The code server of claims 1 and 25 patentably distinguish over Horn by claiming a module information table containing module information to assist in the formation of an association within the operating system at a point prior to execution time of the multimodule program being associated. This limitation is not found nor suggested by Horn. Claims 2-8 depend from claim 1, either directly or indirectly, and are patentable for the same reasons as asserted for claim 1. New claim 26 has been added, which is dependent on independent claim 9, to further patentably distinguish the present invention over Horn. Claim 26 claims module information relating to the discrete module includes at least one embedded reference to another discrete module of the multimodule program The descriptor tables taught by Horn provide information for mapping logical to physical memory addresses to manage the loading and execution of the program. Horn does not teach, nor suggest the use of a module information table containing module information that includes at least one embedded reference to another discrete module, all of which is to assist in the formation of an association within the operating system at a point prior to execution time of the multimodule program being associated. Accordingly, the Examiner is respectfully requested to allow claims 1-26 and pass the application to issue. Respectfully submitted,
By: ___________________
Vancouver, B.C.
|
| Amazingly enough (to us laypersons at any rate!) they bought it :)
The patent issued on 5th May, 1998
|