DETAILED ACTION
Claims 21-40 are pending in this application.
Claim 40 is allowed.
Claims 27, 35-37 and 39 are objected to.
Claims 21-26, 28-34 and 38 are rejected.
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 on 12/25/2025, 02/25/2025 and 9/16/2024 are in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statements are being considered by the examiner.
Claim Objections
Claim 39 is objected to because of the following informalities:
Claim 39 states “each for receiving and/or transmitting signals at at least its respective associated frequency”, the repeated “at” should be removed.
Appropriate correction is required.
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.
Claim(s) 21-26, 28-34 and 38 is/are rejected under 35 U.S.C. 103 as being unpatentable over Lee et al. 2006. “Memory Footprint Reduction with Quasi-Static Shared Libraries in MMU-less Embedded Systems” in view of Kempf et al. (U.S. PGPub No. 2020/0192808) in view of Chen et al. (U.S. PGPub No. 2022/0137987)
Claim 21
Lee (2006) teaches:
A memory management unit-less (MMU-less) device comprising:
at least one processing unit; Page 3 Table 1 S5N8947 (ARM7/TDMI core, No MMU)
a random-access memory (RAM); and Page 3 Table 1 16MB SDRAM
a built-in non-volatile memory, Page 3 Table 1 2MB Flash memory
wherein the built-in non-volatile memory or the RAM stores a loader component Page 2, Section 2 In flash memory, there resides not a bootloader and compressed image of uClinux configured to load a plurality of allocatable sections from an executable file into available blocks in the RAM, Page 2, Section 2 An executable code image stored in flash memory is loaded into RAM by uClinux’s loader
to record into the RAM a table of correspondence between the allocatable sections of the plurality […] Page 7, Section 3.1.3 relocation table has relocation entries containing offsets into an application where pseudo-addresses are used, the pseudo-addresses are mapped to absolute addresses; Page 2, Section 2 the relocation table is part of the executable code image, which is loaded into RAM
Lee does not explicitly teach the table of correspondence mapping allocatable sections of the executable file to addresses where allocatable sections are loaded.
Kempf (2020/0192808) teaches:
[…] a table of correspondence between the allocatable sections of the plurality and addresses at which the allocatable sections are loaded, and P. 0040 create a mapping of the virtual addresses V0 to physical addresses H0 corresponding to unallocated memory ranges in physical memory where code C and Data D from the program P are copied (see also P. 0043); P. 0036 code C of program P is loaded to a virtual address
It would have been obvious to a person with ordinary skill in the art before the effective filing date of the application to include the invention of Lee with the table of correspondence mapping allocatable sections of the executable file to addresses where allocatable sections are loaded taught by Kempf.
The motivation being allowing efficient conversion of virtual addresses to physical addresses, while representing all use cases on an embedded system with a virtual address space (See Kempf P. 0054)
The systems of Lee and Kempf do not explicitly teach relocating an invocation based on a table of correspondence.
Chen (2022/0137987) teaches:
[…] to perform at least one relocation for an invocation from a one of the allocatable sections of the plurality to the same or another of the allocatable sections of the plurality based on the table of correspondence. P. 0050 global offset table (GOT) 208 is the mechanism that allows shared libraries (e.g., .so) to be relocated to a different memory address at startup
It would have been obvious to a person with ordinary skill in the art before the effective filing date of the application to include the invention of Lee and Kempf with relocating an invocation based on a table of correspondence taught by Chen
The motivation being to avoid memory address conflicts with the main program or other shared libraries (See Chen P. 0050)
The systems of Lee, Kempf and Chen are analogous because they are from the “same field of
endeavor” and from the same “problem solving area.” Namely, they are both from the field of memory systems.
Therefore it would have been obvious to combine Lee and Kempf with Chen to obtain the invention as recited in claims 21-39.
Claim 22
Chen (2022/0137987) teaches:
The MMU-less device of claim 21, wherein the loader component is configured, for said at least one invocation comprising a relocatable invocation from said one of the allocatable sections to another of the allocatable sections of said plurality, to relocate the relocatable invocation based on said table of correspondence. P. 0059 When the link address field 504 of FIG. 5 for the item in GOT 208 is the initial value 322, dynamic linker 212 resolves the new link address by searching for a match to the new address 324 in an unresolved (relocated) entry table 215
Claim 23
Chen (2022/0137987) teaches:
The MMU-less device of claim 21, wherein the loader component is configured, for said at least one invocation comprising a relocatable invocation from said one of the allocatable sections to the same allocatable section, to relocate the relocatable invocation based on said table of correspondence. P. 0059 When the link address field 504 of FIG. 5 for the item in GOT 208 is the initial value 322, dynamic linker 212 resolves the new link address by searching for a match to the new address 324 in an unresolved (relocated) entry table 215
Claim 24
Chen (2022/0137987) teaches:
The MMU-less device of claim 22, wherein the loader component is configured, for said at least one invocation comprising a relocatable invocation from said one of the allocatable sections to the same allocatable section, to relocate the relocatable invocation based on said table of correspondence. P. 0059 When the link address field 504 of FIG. 5 for the item in GOT 208 is the initial value 322, dynamic linker 212 resolves the new link address by searching for a match to the new address 324 in an unresolved (relocated) entry table 215
Claim 25
Lee (2006) teaches:
The MMU-less device of claim 21, wherein the plurality of allocatable sections belongs to a program, being an application, which the loader component is thereby configured to load for execution into the RAM. Page 2, Section 2 An executable code image of an application is stored in flash memory is loaded into RAM by uClinux’s loader. The loader calculates the symbols’ absolute addresses and modifies the code and data sections using the relocation table
Claim 26
Chen (2022/0137987) teaches:
The MU-less device of claim 25, wherein the MU-less device is configured to provide an application program interface, API, to the program, and API entities of the API are configured to be invoked by their addresses in the built-in non-volatile memory from the program. P. 0051 debugger 240 is configured to invoke and/or communicate with software (APIs) respectively associated with each of static linker 210, dynamic linker 212, GOT 208, and shared library 214 to perform as discussed herein; P. 0035 The debugger is configured to reload updated dynamic library and look through the library index field of the GOT, and then reset the link address. The reset link address in the link address field makes the loader resolve the link address when the application programming interface (API) from the updated shared library is called later
Claim 28
Kempf (2020/0192808) teaches:
The MMU-less device of claim 21, wherein the loader component is configured to load at least one allocatable section thereby occupying a first available byte in the RAM and an at least one allocatable section thereby occupying a second available byte in the RAM, and the loader component is configured to avoid writing into a byte in the RAM between the first and the second available bytes. P. 0036-37 the code section C of program P is 0xb94 bytes in size and is loaded to first virtual address V1 0x40000000, while data D is 0x464 bytes in size and is loaded to the second virtual address V2 0x80000000; FIG. 6 and P. 0057-58 sections with similar sizes (in access length L1) are mapped to physical addresses 0x41000 and 0x1234 respectively, there is a gap between them
Claim 29
Chen (2022/0137987) teaches:
The MMU-less of claim 21, where the loader component is configured to perform the at least one relocation based on a section header index and a value associated symbol in that entry in a symbol table section whose entry index is recorded in a relocation data section located in the executable file and corresponding to the one of the allocatable sections. P. 0053 dynamic linker 212 performs resolution of an unresolved (relocated) entry by searching the unresolved entry table 215 and symbol table 216 for a match to the new address 324. For the entry found in unresolved entry table 215, dynamic linker 212 searches for and retrieves the symbol in a symbol table 216 used to resolve the new address. Using the symbol table 216, dynamic linker 212 works to resolve the symbol. Once the symbol is resolved, dynamic linker 212 updates an entry in index table 218, and updates GOT 208 with the new address 324
Claim 30
Chen (2022/0137987) teaches:
The MMU-less device of claim 21, wherein the loader component is configured to perform said at least one relocation for an invocation from said a one of the allocatable sections which is an executable section. P. 0059 When the link address field 504 of FIG. 5 for the item in GOT 208 is the initial value 322, dynamic linker 212 resolves the new link address by searching for a match to the new address 324 in an unresolved (relocated) entry table 215; P. 0050 a global offset table (GOT) 208 is used to enable computer program code (e.g., compiled as an ELF file) to run correctly
Claim 31
Chen (2022/0137987) teaches:
The MMU-less device of claim 25, wherein the loader component is configured to perform said at least one relocation for an invocation from said a one of the allocatable sections which is an executable section. P. 0059 When the link address field 504 of FIG. 5 for the item in GOT 208 is the initial value 322, dynamic linker 212 resolves the new link address by searching for a match to the new address 324 in an unresolved (relocated) entry table 215; P. 0050 a global offset table (GOT) 208 is used to enable computer program code (e.g., compiled as an ELF file) to run correctly
Claim 32
Chen (2022/0137987) teaches:
The MMU-less device of claim 21, wherein the loader component is configured to perform said at least one relocation for the invocation being an invocation of code. P. 0050 a global offset table (GOT) 208 is used to enable computer program code (e.g., compiled as an ELF file) to run correctly. GOT 208 maps symbols in programming code to their corresponding absolute memory addresses, the runtime memory address is unknown before the program is started when PIC or PIE code is run; P. 0053 dynamic linker 212 performs resolution of an unresolved (relocated) entry by searching the unresolved entry table 215 and symbol table 216 for a match to the new address 324
Claim 33
Chen (2022/0137987) teaches:
The MMU-less device of claim 28, wherein the loader component is configured to perform said at least one relocation for the invocation being an invocation of code. P. 0050 a global offset table (GOT) 208 is used to enable computer program code (e.g., compiled as an ELF file) to run correctly. GOT 208 maps symbols in programming code to their corresponding absolute memory addresses, the runtime memory address is unknown before the program is started when PIC or PIE code is run; P. 0053 dynamic linker 212 performs resolution of an unresolved (relocated) entry by searching the unresolved entry table 215 and symbol table 216 for a match to the new address 324
Claim 34
Kempf (2020/0192808) teaches:
The MMU-less device of claim 25, wherein the loader component is configured to load the plurality of allocatable sections into the RAM from an external communication device or an external memory. P. 0017 According to one embodiment, the step of generating a program is realized by a development system external to the embedded system; P. 0031 The embedded system 10 is configured to receive the program P generated by the development system 100, transmitted via USB or radio interface of the embedded system;
Claim 38
Chen (2022/0137987) teaches:
The MU-less device of claim 21, wherein the executable file is an Executable and Linkable Format (ELF) compatible file, and the executable file is partially-linked. P. 0050 a global offset table (GOT) 208 is used to enable computer program code (e.g., compiled as an ELF file) to run correctly
Allowable Subject Matter
Claim 40 is allowed.
Claims 27 and 35-37 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Claim 39 is objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims, and if informalities are corrected.
The following is an examiner’s statement of reasons for allowance:
Claim 27 recites the limitation “wherein the loader component is configured to load at least one of the plurality of allocatable sections thereby occupying a first available byte in the RAM and an at least one of the plurality of allocatable sections thereby occupying a second available byte in the RAM, wherein the loader component is configured to avoid writing into a byte in the RAM between the first and the second available bytes, wherein this byte is allocated to a program different from the received program”
Said limitation is taught by the specification of the instant application as originally filed at least at [P. 0054, 0301]. Said limitations, in combination with the other recited limitations of claim 27, are not taught or suggested by the prior art of record.
The closest prior art of record includes: Kempf (2020/0192808) which teaches allocating different sections of code to available physical memory addresses, where gaps exist between the bytes of physical memory allocated to different sections of code; and Chen (2022/0137987) which teaches resolving loaded libraries, executable files and other objects initially assigned to default addresses to a new addresses, where all parts do not need to be contained within a single object file and are referred to by symbols mapped to memory addresses. None of the references teach loading different sections of the same program to first and second available bytes of RAM, where memory between the first and second available bytes is allocated to a different program.
Claim 35 recites the limitation “The MMU-less device of claim 34, wherein a total volume of the RAM of the MMU-less device does not exceed 1 MB”
Said limitation is taught by the specification of the instant application as originally filed at least at [P. 0103]. Said limitations, in combination with the other recited limitations of claim 35, are not taught or suggested by the prior art of record.
The closest prior art of record includes: Lee (2006); Kempf (2020/0192808) which teaches transmitting a program generated by an external development system to an embedded system via the embedded system’s radio interface; and Chen (2022/0137987). None of the references teach loading allocatable sections into RAM from an external memory, the RAM being less than 1MB (in combination with all recited limitations of the claim and its parent claims).
Claims 36-37 depend from claim 35, and are considered allowable for at least the same reasons as claim 35.
Claim 39 recites the limitation “The MMU-less device of claim 26, comprising at least two antennas, each for receiving and/or transmitting signals at at least its respective associated frequency, wherein the MU-less device comprises an API entity for transmitting a signal using at least one antenna from the antennas and/or for receiving a signal using the at least one antenna from the antennas, and thereby the MMU-less device is configured to respectively transmit or receive the signal when at least one of the allocatable sections comprises an invocation of the API entity”
Said limitation is taught by the specification of the instant application as originally filed at least at [P. 0047, 0065-66, 0479]. Said limitations, in combination with the other recited limitations of claim 39, are not taught or suggested by the prior art of record.
The closest prior art of record is Kempf (2020/0192808) which teaches transmitting a program generated by an external development system to an embedded system via the embedded system’s radio interface. None of the references teach the MMU-less system including at least two antennas, an API for transmitting or receiving signals using one of the antennas, and transmitting or receiving a signal when an invocation of the API is one of the allocatable sections
Claim 40 recites the limitation “An MMU-less device comprising:
at least one processing unit;
a RAM; and
a built-in non-volatile memory storing a plurality of API entities of the MMU-less device,
wherein the built-in non-volatile memory or the RAM stores a loader component configured to load one or more allocatable sections of a program from an executable file into available blocks in the RAM and to store in the RAM, by static allocation, an allocation address for allocation data configured to store a table of correspondence between one or more allocatable sections and respective one or more addresses at which the one or more allocatable sections are subject to loading or have been loaded into the RAM, and
wherein the loader component is configured to record the allocation data into the RAM based on the allocation address”
Said limitation is taught by the specification of the instant application as originally filed at least at [P. 0229, 0449]. Said limitations, in combination with the other recited limitations of claim 40, are not taught or suggested by the prior art of record.
The closest prior art of record includes: Lee (2006) which teaches a MMU-less system with RAM, non-volatile memory and a loader, and a relocation table in the executable image with entries identifying offsets into the application of those locations where the pseudo-addresses are used, where the pseudo-addresses are eventually replaced with absolute addresses by the loader; Kempf (2020/0192808) which teaches an embedded system without an MMU including a physical memory and loader, where code and data from a program are copied into unallocated ranges of physical memory, and the loader creates a mapping of virtual addresses where code is loaded and physical addresses identifying where code is stored in physical memory. None of the references teach a MMU-less system with a RAM and non-volatile memory, the non-volatile memory storing API entities, the system statically allocating an address in a RAM of the MMU-less system for storing a table of correspondence between sections from an executable file and addresses in RAM at which the sections are to be loaded.
Any comments considered necessary by applicant must be submitted no later than the payment of the issue fee and, to avoid processing delays, should preferably accompany the issue fee. Such submissions should be clearly labeled “Comments on Statement of Reasons for Allowance.”
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Wu (2011/0219363) teaches dynamically linking an application program on an embedded platform.
Chan (2020/0278875) teaches loading a dynamic link library file during a running process of an application, and a global symbol table mapping an index from a file of the application to a symbol address, relocating the logical address of the symbol address into an actual physical address.
Pan (2018/0329725) teaches relocating data and code sections of an ELF file.
Mencias (2009/0187725) a concurrent loader process that loads new program code while original code is currently running, by copying sections of new code to reserved memory sections, and relocating a global data section.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to STEPHANIE WU whose telephone number is (571)272-0257. The examiner can normally be reached 1pm to 6pm, and 10pm to 1am Eastern time (10am to 3pm, and 7pm to 10pm Pacific time).
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, Rocio Del Mar Perez-Velez can be reached at (571) 270-5935. 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.
/STEPHANIE WU/ Primary Examiner, Art Unit 2133
Prosecution Insights