DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-2, 4-7, 9-13 and 15-19 are rejected under 35 U.S.C. 103 as being unpatentable over Chen et al. US 8,468,516 B1 and further in view of Sun (CN 113110865).
As per claim 1, Chen et al. teaches the invention as claimed including, “An application upgrade methodcomprising:
obtaining upgrade information of an application, wherein the upgrade information comprises a target operator, an operator identifier of the target operator, and an application identifier of the application;
obtaining a physical address allocated to the target operator, wherein the physical address is an address of storage space on the network interface card device; and
storing the target operator in the storage space corresponding to the physical address, and constructing a first mapping relationship based on the operator identifier, the application identifier, and the physical address, wherein the first mapping relationship indicates that there is a mapping relationship between the operator identifier, the application identifier, and the physical address, and the first mapping relationship is used as routing information of the target operator when the application is running.”
Chen et al. teaches, a hot patch is executed, which causes a patch management module to load the hot patch from the memory store to main memory 48 (physical address allocated to the target operator). The executable and linkable format (ELF) occupying main memory maintains a reserve area specifically for future hot patches. The hot patches are loaded into this portion of the memory (physical address) (column 11, lines 39-50). Also see figures 4A and 4B. The patch may be applied to a network router (network interface card device). The patch management module reads the address hook table 322. For each symbol entry in the table, the patch management module finds the memory address for the address field of the entry. If the value at the memory address matches the value of the original code field of the entry, the patch management module copies the value in the new code field of the entry to the memory address (mapping relationship). For function symbols, this will cause the function call chain to redirect to the function in the hot patch that corresponds to the original function symbol (column 11, lines 51 – column 12, lines 1-4). As can be seen in the address hook table in figure 5A an address is listed along with a new code id (operation ID). Each address and respective new code ID map to their respective Patch code (316-360) (target operators) as shown in figure 4B.
Chen et al. does not explicitly teach the use of an application id.
Sun teaches detecting whether the target directory (application identifier) of the target program has a newly added target update file (page 5, S101). When the target directory of the target program is detected to have the newly added target update file, searching the target symbol or target address matching target address matched with the target update file under the target directory (page 6, S102). Also see (page 6, S103).
It would have been obvious to one or ordinary skill in the art before the effective filing date to modify Chen et al. with Sun et al. because both teach the process of hot patching/updating. They both teach the use of symbol table to match the target memory address to the update in order to change the call path so that the newly added target update file is called instead of the original. Chen teaches performing the update however does not explicitly teach how the update will know what application it is updating. Sun teaches a target directory which the examiner is interpreting as the application identifier is monitored to determine if a newly added target update file is added to it. This would allow Chen et al. to determine if a target update file has been created for a specific application and allow Chen et al. to then perform the update for that specific application.
As per claim 2, Chen et al. further teaches, “The method according to claim 1, wherein the storage space is a cache or a flash memory.”
See column 5, lines 48-62 and figure 2.
As per claim 4, Chen et al. further teaches, “The method according to claim 1, wherein the upgrade information further comprises a first hook level of the target operator, the first hook level indicates an importance degree of the target operator, the storage space comprises first subspace allocated to an operator of the first hook level, and the physical address is an address of the first subspace.”
As can be seen in figure 5A the address hook table lists function/object (original code and new code), along with their location (hook level). The address hook table relates to the hot patch in figure 4B stored in the hot patch reserve 311 in figure 4A (physical address). The hot patch is loaded from the memory store to the main memory (physical address) (column 11, lines 45-50).
As can be seen in figure 4B multiple patches 316 Global_Data_3_PATCH, 318 FUNCTION_B_PATCH and 320 FUNCTION_C_PATCH are all saved in a memory location such as HOTPATCH RESERVE 311 in figure 4A. Figure 4B shows each patch has its own section of memory wherein the patch in 316 is above the patch in 318 which is above the patch 320. Figure 5A shows the address hook table 322 for figure 4B. The address hook table contains entries for each of the symbols in the memory map illustrated by figure 4A that are to be modified using the hot patch. See column 10, lines 54- column 11, lines 1-25. Therefore, the address hook table list a order in which the patches are saved in the hot patch. This order is its degree of importance.
As per claim 5, Chen et al. further teaches, “The method according to claim 4, wherein the storage space further comprises second subspace allocated to an operator of a second hook level, the first subspace is used to store the operator of the first hook level, and the second subspace is used to store the operator of the second hook level.”
As can be seen in figure 5A the address hook table lists function/object (original code and new code), along with their location (hook level). The address hook table relates to the hot patch in figure 4B stored in the hot patch reserve 311 in figure 4A (physical address). The hot patch is loaded from the memory store to the main memory (physical address) (column 11, lines 45-50).
As can be seen in figure 4B multiple patches 316 Global_Data_3_PATCH, 318 FUNCTION_B_PATCH and 320 FUNCTION_C_PATCH are all saved in a memory location such as HOTPATCH RESERVE 311 in figure 4A. Figure 4B shows each patch has its own section of memory (level) wherein the patch in 316 is above the patch in 318 which is above the patch 320. Figure 5A shows the address hook table 322 for figure 4B. The address hook table contains entries for each of the symbols in the memory map illustrated by figure 4A that are to be modified using the hot patch. See column 10, lines 54- column 11, lines 1-25. Therefore, the address hook table list a order in which the patches are saved in the hot patch. This order is its degree of importance.
As per claim 6 (Currently Amended), Chen et al. further teaches, “The method according to claim 4, wherein the obtaining of the physical address allocated to the target operator comprises:
obtaining a second mapping relationship, wherein the second mapping relationship comprises a plurality of hook levels and subspace allocated to each hook level;
determining, from the second mapping relationship based on the first hook level and the second mapping relationship, the first subspace allocated to the first hook level; and
obtaining, from the first subspace, the physical address allocated to the target operator.”
A hot patch is executed, which cause patch management module to load the hot patch from the memory store to main memory 48 (second mapping to the physical address allocated to the target operator). The executable and linkable format ELF occupying main memory maintains a reserve area specifically for future hot patches. The hot patches are loaded into this portion of the memory (column 11, lines 39-50). Also see figures 4A and 4B.
As can be seen in figure 5A the address hook table lists function/object (original code and new code), along with their location (hook level). The address hook table relates to the hot patch in figure 4B stored in the hot patch reserve 311 in figure 4A (physical address). The hot patch is loaded from the memory store to the main memory (physical address) (column 11, lines 45-50).
As can be seen in figure 4B multiple patches 316 Global_Data_3_PATCH, 318 FUNCTION_B_PATCH and 320 FUNCTION_C_PATCH are all saved in a memory location such as HOTPATCH RESERVE 311 in figure 4A. Figure 4B shows each patch has its own section of memory wherein the patch in 316 is above the patch in 318 which is above the patch 320. Figure 5A shows the address hook table 322 for figure 4B. The address hook table contains entries for each of the symbols in the memory map illustrated by figure 4A that are to be modified using the hot patch. See column 10, lines 54- column 11, lines 1-25. Therefore, the address hook table list a order in which the patches are saved in the hot patch. This order is its degree of importance.
As per claim 7, Chen et al. further teaches, “The method according to claim 1, wherein the upgrade information further comprises an identifier of a to-be-replaced operator; and the obtaining of the physical address allocated to the target operator comprises:
determining, based on the identifier of the to-be-replaced operator, the physical address of storage space in which the to-be-replaced operator is stored.”
Chen et al. teaches, a hot patch is executed, which causes a patch management module to load the hot patch from the memory store to main memory 48 (physical address allocated to the target operator). The executable and linkable format (ELF) occupying main memory maintains a reserve area specifically for future hot patches. The hot patches are loaded into this portion of the memory (physical address) (column 11, lines 39-50). Also see figures 4A and 4B. The patch may be applied to a network router (network interface card device). The patch management module reads the address hook table 322. For each symbol entry in the table, the patch management module finds the memory address for the address field of the entry. If the value at the memory address matches the value of the original code field of the entry, the patch management module copies the value in the new code field of the entry to the memory address (mapping relationship). For function symbols, this will cause the function call chain to redirect to the function in the hot patch that corresponds to the original function symbol (column 11, lines 51 – column 12, lines 1-4). As can be seen in the address hook table in figure 5A an address is listed along with a new code id (operation ID). Each address and respective new code ID map to their respective Patch code (316-360) (target operators) as shown in figure 4B.
As per claim 9, Chen et al. and Sun further teach, “The method according to claim 4, wherein the constructing a first mapping relationship based on the operator identifier, the application identifier, and the physical address comprises:
constructing the first mapping relationship based on the operator identifier, the first hook level, the application identifier, and the physical address, wherein the first mapping relationship indicates that there is a mapping relationship between the operator identifier, the first hook level, the application identifier, and the physical address.”
Chen et al. teaches, a hot patch is executed, which causes a patch management module to load the hot patch from the memory store to main memory 48 (physical address allocated to the target operator). The executable and linkable format (ELF) occupying main memory maintains a reserve area specifically for future hot patches. The hot patches are loaded into this portion of the memory (physical address) (column 11, lines 39-50). Also see figures 4A and 4B. The patch may be applied to a network router (network interface card device). The patch management module reads the address hook table 322. For each symbol entry in the table, the patch management module finds the memory address for the address field of the entry. If the value at the memory address matches the value of the original code field of the entry, the patch management module copies the value in the new code field of the entry to the memory address (mapping relationship). For function symbols, this will cause the function call chain to redirect to the function in the hot patch that corresponds to the original function symbol (column 11, lines 51 – column 12, lines 1-4). As can be seen in the address hook table in figure 5A an address is listed along with a new code id (operation ID). Each address and respective new code ID map to their respective Patch code (316-360) (target operators) as shown in figure 4B.
Sun teaches detecting whether the target directory (application identifier) of the target program has a newly added target update file (page 5, S101). When the target directory of the target program is detected to have the newly added target update file, searching the target symbol or target address matching target address matched with the target update file under the target directory (page 6, S102). Replacing the calling patch of the object to be updated in the target program to the calling path aiming at the target updating file (page 6, S103). When the target program is running, it is necessary to invoke various functions or variables (objects identifiers). The calling path of the file to be updated is modified into the calling path aiming at the target updating file (page 7, paragraph 3-4).
As per claim 10 (Currently Amended), Chen et al. and Sun further teach, “The method according to claim 1, wherein after the constructing of the first mapping relationship, the method further comprises:
receiving operator hook information sent when the application is running, wherein the operator hook information comprises the application identifier and the operator identifier, and the operator hook information indicates to execute the target operator;
obtaining the physical address based on the operator hook information and the first mapping relationship; and
obtaining the target operator based on the physical address.”
Chen et al. teaches, the patch management module reads the address hook table 322. For each symbol entry in the table, the patch management module finds the memory address for the address field of the entry. If the value at the memory address matches the value of the original code field of the entry, the patch management module copies the value in the new code field of the entry to the memory address (mapping relationship). For function symbols, this will cause the function call chain to redirect to the function in the hot patch that corresponds to the original function symbol (column 11, lines 51 – column 12, lines 1-4). As can be seen in the address hook table in figure 5A, an address is listed along with a new code id (operation ID). Each address and respective new code ID map to their respective Patch code (316-360) (target operators) as shown in figure 4B.
Sun teaches detecting whether the target directory (application identifier) of the target program has a newly added target update file (page 5, S101). When the target directory of the target program is detected to have the newly added target update file, searching the target symbol or target address matching target address matched with the target update file under the target directory (page 6, S102). Replacing the calling patch of the object to be updated in the target program to the calling path aiming at the target updating file (page 6, S103). When the target program is running, it is necessary to invoke various functions or variables (objects identifiers). The calling path of the file to be updated is modified into the calling path aiming at the target updating file (page 7, paragraph 3-4).
Therefore, both references teach when executing the and the call chain/calling path is used to call an object or function, the call will be directed to the new updated file/object/function as its physical address.
As per claim 11, Chen et al. and Sun further teach, “The method according to claim 10, wherein the operator hook information further indicates to execute a software program, the software program comprises a first code segment, a second code segment, and a hook point located between the first code segment and the second code segment, the hook point indicates whether to hook the target operator, and the operator hook information specifically indicates to hook the target operator after the first code segment is executed; and
the method further comprises:
executing the first code segment, the target operator, and the second code segment based on the operator hook information.
Chen et al. teaches, the patch management module reads the address hook table 322. For each symbol entry in the table, the patch management module finds the memory address for the address field of the entry. If the value at the memory address matches the value of the original code field of the entry, the patch management module copies the value in the new code field of the entry to the memory address (mapping relationship). For function symbols, this will cause the function call chain to redirect to the function in the hot patch that corresponds to the original function symbol (column 11, lines 51 – column 12, lines 1-4). As can be seen in the address hook table in figure 5A, an address is listed along with a new code id (operation ID). Each address and respective new code ID map to their respective Patch code (316-360) (target operators) as shown in figure 4B.
As can be seen in figure 4A of Chen et al, there are multiple functions FUNCTION_A, FUNCTION_B AND FUNCTION_C and figure 4b shows a patch that updates both FUNCTION_B and FUNCTION_C. However, Chen et al. is not limited to just this embodiment. It would have been obvious to one of ordinary skill in the art before the effective filing date for just FUNCTION-_B being updated. If so then according to a function call chain, FUNCTION_A can be executed first, then FUNCTION_B which will redirect to the FUNCTION_B_PATCH and then FUNCTION_C could be executed. This is nothing more than a design choice and would have been obvious to try.
Sun teaches detecting whether the target directory (application identifier) of the target program has a newly added target update file (page 5, S101). When the target directory of the target program is detected to have the newly added target update file, searching the target symbol or target address matching target address matched with the target update file under the target directory (page 6, S102). Replacing the calling patch of the object to be updated in the target program to the calling path aiming at the target updating file (page 6, S103). When the target program is running, it is necessary to invoke various functions or variables (objects identifiers). The calling path of the file to be updated is modified into the calling path aiming at the target updating file (page 7, paragraph 3-4).
As per claims 12-13 and 15-19, they contain similar limitations to claims 1-2 and 4-6. Therefore, they are rejected for similar reasons.
Claims 3, 8, 14 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Chen et al. US 8,468,516 B1 and Sun (CN 113110865) as applied to claims 1, 12, and 18 above, and further in view of Chen/Waldspurger et al. (US 8,359,451 B2).
As per claim 3, Chen et al. teaches, a hot patch is executed, which causes a patch management module to load the hot patch from the memory store to main memory 48 (physical address allocated to the target operator). The executable and linkable format (ELF) occupying main memory maintains a reserve area specifically for future hot patches. The hot patches are loaded into this portion of the memory (physical address) (column 11, lines 39-50), however Chen et al. does not explicitly appear to teach, “The method according to claim 1, wherein the upgrade information further comprises a virtual address corresponding to the target operator; and the obtaining of the physical address allocated to the target operator comprises:
mapping the virtual address to a corresponding physical address based on the virtual address.”
Chen/Waldspurger et al. teaches when an application requests memory, the operating system will allocate memory in a first address space, typically called a virtual memory address space. The first memory address space maps to a second memory address space, typically the physical memory of the computer (column 5, lines 4-24). Chen/Waldspurger et al. teaches the use of virtual memory address spaces, wherein if the amount of virtual memory used by the application exceeds the amount of physical memory available on the computer, the system will use a secondary storage medium to store some of the data contained in the virtual memory. When data from some virtual memory page is actually stored on the secondary storage medium, the page table will map some virtual memory address to physical memory addresses, while mapping other virtual memory addresses to locations on the secondary storage medium (column 5, lines 25-57).
It would have been obvious to one of ordinary skill in the art before the effective filing date to modify Chen/Waldspurger et al. Chen et al. teaches when a hot patch is executed the patch is loaded into main memory (physical memory) for execution. Chen/Waldspurger et al. teaches one advantage of using virtual memory address space is that the mount of virtual memory used by the applications may exceed the amount of physical memory available on the computer. When such a situation occurs, the operating system will use a secondary storage medium to store some of the data contained in the virtual memory (column 5, lines 25-25). Therefore, the use of a virtual address mapped to physical memory will allow Chen et al. to not have to worry about the size of the patch during its execution and would have been obvious to try.
As per claim 8, Chen et al. does not explicitly appear to teach, “The method according to claim 1, wherein the storage space comprises first subspace, the target operator comprises a first operator segment and a second operator segment, the first operator segment and the second operator segment each are a part of the target operator, and the first operator segment comprises an entry function of the target operator; and
the storing of the target operator in the storage space corresponding to the physical address comprises:
on a basis that available space in the first subspace is smaller than storage space required for storing the target operator, and the available space in the first subspace is greater than storage space required for storing the first operator segment, storing the first operator segment in the storage space corresponding to the physical address, and transferring the second operator segment to a hostfor storage of the second operator segment.”
Chen/Waldspurger et al. teaches when an application requests memory, the operating system will allocate memory in a first address space, typically called a virtual memory address space. The first memory address space maps to a second memory address space, typically the physical memory of the computer (column 5, lines 4-24). Chen/Waldspurger et al. teaches the use of virtual memory address spaces, wherein if the amount of virtual memory used by the application exceeds the amount of physical memory available on the computer, the system will use a secondary storage medium to store some of the data contained in the virtual memory. When data from some virtual memory page is actually stored on the secondary storage medium, the page table will map some virtual memory address to physical memory addresses, while mapping other virtual memory addresses to locations on the secondary storage medium (column 5, lines 25-57).
It would have been obvious to one of ordinary skill in the art before the effective filing date to modify Chen/Waldspurger et al. Chen et al. teaches when a hot patch is executed the patch is loaded into main memory (physical memory) for execution. Chen/Waldspurger et al. teaches one advantage of using virtual memory address space is that the mount of virtual memory used by the applications may exceed the amount of physical memory available on the computer. When such a situation occurs, the operating system will use a secondary storage medium to store some of the data contained in the virtual memory (column 5, lines 25-25). Therefore, the use of a virtual address mapped to physical memory will allow Chen et al. to not have to worry about the size of the patch during its execution and would have been obvious to try.
As per claims 14 and 20, they contain similar limitations to claims 3 and 8 and are therefore rejected for similar reasons.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MARK A GOORAY whose telephone number is (571)270-7805. The examiner can normally be reached Monday - Friday 10:00am - 6:00pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Lewis Bullock can be reached at 571-272-3759. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like
assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/MARK A GOORAY/ Examiner, Art Unit 2199
/LEWIS A BULLOCK JR/ Supervisory Patent Examiner, Art Unit 2199
Prosecution Insights