Pre-Grant Publication Number: 20070234286
Please help the USPTO examine the application by evaluating the relevance of the publicly submitted prior art to the patent application.
Peer To Patent forwards the Top 10 most relevant prior art submissions and their annotations to the USPTO.
Review this prior art and click on the thumbs up (or down) to indicate whether this submission should be forwarded to the USPTO.
If you login then you can add an annotation by typing in the box at the bottom of the screen to comment on the relevance of the prior art to the claims of the patent application.
Review this prior art and click on the thumbs up (or down) to indicate whether this submission should be forwarded to the USPTO.
If you login then you can add an annotation by typing in the box at the bottom of the screen to comment on the relevance of the prior art to the claims of the patent application.
Prior Art Detail
Summary / Description
| Summary / Description | The reference relates to a method to perform conditional thunking. |
Basic Information
| Type of Prior Art | Issued Patents - US |
| Country | United States of America |
| Patent/Application # | US6553429 |
| Kind Code | United States (US) - Reexamination Certificate Firs... - B1 |
| Patentee Name | MICROSOFT CORP (US) |
| Relevant Pages, Columns, or Lines | |
| URL | http://patft.uspto.gov/netacgi/... |
| Filing Date | April 22, 2003 |
| Additional Information | |
Notes / To Do
| Notes | |
Excerpt
Excerpt Page – 9, Col 8, Lines 47-67; Page -10, Col – 9, Lines 1-25: “FIG. 2A is a functional block diagram that illustrates an argument-selection type conditional thunk utility 100 . In this example, this conditional thunk utility 100 is configured as part of the application program 36 . The conditional thunk utility 100 is employed when the application program 36 accesses an associated API for calling a particular function, shown as function call “A” 102 of the operating system 35 . In this argument-selection embodiment, the conditional thunk utility 100 selects one set of arguments, shown as arguments “X” 104 , for the function call “A” 102 for a first condition. Alternatively, the conditional thunk utility 100 selects another set of arguments, shown as arguments “Y” 106 , for the function call “A” 102 ′ for a second condition. Thus, in this embodiment, the thunk layer is a precursor operation that determines which arguments (arguments “X” 104 or arguments “Y” 106 ) to include in function call “A” 102 or 102 ′.
When making the function call “A” 102 or 102 ′, the application program 36 pushes parameters 108 for the function call onto a stack 109 . These parameters typically include local variables, addresses, data, or other parameters that the operating system 35 uses when performing the called function. The operating system 35 reads the parameters 108 from the stack 109 before performing the called function. The conditional thunk utility 100 implements an assembler-level direct-branch technique, and does not alter the stack 109 from its desired condition while performing the thunk operation. Therefore, the stack 109 does not have to be altered or cleaned up after the thunk operation and before the operating system 35 reads the parameters 108 from the stack 109 .
In a typical application, the conditional thunk utility 100 translates the arguments of the function call “A” 102 based on the type of operating system 35 . For example, the APIs exposed by the MICROSOFT WINDOWS 95 operating system accept only ANSI (8-bit) arguments, whereas the MICROSOFT WINDOWS NT operating system accepts ANSI (8-bit) or UNICODE (16-bit) arguments. As the UNICODE arguments provide additional information and, thus, offer greater potential for functionality, UNICODE arguments are preferred when available. Accordingly, the conditional thunk utility 100 places the arguments “X” 104 in ANSI format if the operating system 35 is MICROSOFT WINDOWS 95, and places the arguments “Y” 106 in UNICODE format if the operating system is MICROSOFT WINDOWS NT.”
|
Relevance
Claims
1
Relevance
The following text describes the feature of performing thunking based on a condition. This is achieved by selecting the set of arguments to be passed along with a function call based on a condition being met or not: Page – 9, Col 8, Lines 47-67; Page -10, Col – 9, Lines 1-25: “FIG. 2A is a functional block diagram that illustrates an argument-selection type conditional thunk utility 100 . In this example, this conditional thunk utility 100 is configured as part of the application program 36 . The conditional thunk utility 100 is employed when the application program 36 accesses an associated API for calling a particular function, shown as function call “A” 102 of the operating system 35 . In this argument-selection embodiment, the conditional thunk utility 100 selects one set of arguments, shown as arguments “X” 104 , for the function call “A” 102 for a first condition. Alternatively, the conditional thunk utility 100 selects another set of arguments, shown as arguments “Y” 106 , for the function call “A” 102 ′ for a second condition. Thus, in this embodiment, the thunk layer is a precursor operation that determines which arguments (arguments “X” 104 or arguments “Y” 106 ) to include in function call “A” 102 or 102 ′.
When making the function call “A” 102 or 102 ′, the application program 36 pushes parameters 108 for the function call onto a stack 109 . These parameters typically include local variables, addresses, data, or other parameters that the operating system 35 uses when performing the called function. The operating system 35 reads the parameters 108 from the stack 109 before performing the called function. The conditional thunk utility 100 implements an assembler-level direct-branch technique, and does not alter the stack 109 from its desired condition while performing the thunk operation. Therefore, the stack 109 does not have to be altered or cleaned up after the thunk operation and before the operating system 35 reads the parameters 108 from the stack 109 .
In a typical application, the conditional thunk utility 100 translates the arguments of the function call “A” 102 based on the type of operating system 35 . For example, the APIs exposed by the MICROSOFT WINDOWS 95 operating system accept only ANSI (8-bit) arguments, whereas the MICROSOFT WINDOWS NT operating system accepts ANSI (8-bit) or UNICODE (16-bit) arguments. As the UNICODE arguments provide additional information and, thus, offer greater potential for functionality, UNICODE arguments are preferred when available. Accordingly, the conditional thunk utility 100 places the arguments “X” 104 in ANSI format if the operating system 35 is MICROSOFT WINDOWS 95, and places the arguments “Y” 106 in UNICODE format if the operating system is MICROSOFT WINDOWS NT.”
The following text describes the feature of performing thunking based on a condition. This is achieved by selecting the set of arguments to be passed along with a function call based on a condition being met or not: Page – 9, Col 8, Lines 47-67; Page -10, Col – 9, Lines 1-25: “FIG. 2A is a functional block diagram that illustrates an argument-selection type conditional thunk utility 100 . In this example, this conditional thunk utility 100 is configured as part of the application program 36 . The conditional thunk utility 100 is employed when the application program 36 accesses an associated API for calling a particular function, shown as function call “A” 102 of the operating system 35 . In this argument-selection embodiment, the conditional thunk utility 100 selects one set of arguments, shown as arguments “X” 104 , for the function call “A” 102 for a first condition. Alternatively, the conditional thunk utility 100 selects another set of arguments, shown as arguments “Y” 106 , for the function call “A” 102 ′ for a second condition. Thus, in this embodiment, the thunk layer is a precursor operation that determines which arguments (arguments “X” 104 or arguments “Y” 106 ) to include in function call “A” 102 or 102 ′.
When making the function call “A” 102 or 102 ′, the application program 36 pushes parameters 108 for the function call onto a stack 109 . These parameters typically include local variables, addresses, data, or other parameters that the operating system 35 uses when performing the called function. The operating system 35 reads the parameters 108 from the stack 109 before performing the called function. The conditional thunk utility 100 implements an assembler-level direct-branch technique, and does not alter the stack 109 from its desired condition while performing the thunk operation. Therefore, the stack 109 does not have to be altered or cleaned up after the thunk operation and before the operating system 35 reads the parameters 108 from the stack 109 .
In a typical application, the conditional thunk utility 100 translates the arguments of the function call “A” 102 based on the type of operating system 35 . For example, the APIs exposed by the MICROSOFT WINDOWS 95 operating system accept only ANSI (8-bit) arguments, whereas the MICROSOFT WINDOWS NT operating system accepts ANSI (8-bit) or UNICODE (16-bit) arguments. As the UNICODE arguments provide additional information and, thus, offer greater potential for functionality, UNICODE arguments are preferred when available. Accordingly, the conditional thunk utility 100 places the arguments “X” 104 in ANSI format if the operating system 35 is MICROSOFT WINDOWS 95, and places the arguments “Y” 106 in UNICODE format if the operating system is MICROSOFT WINDOWS NT.”
Claim Chart
Some
