DETAILED ACTION
Claims 1, 5, 10, and 14 are amended. Claims 3, 7, 8, 12, 16, and 17 are cancelled. Claims 1-2, 4-6, 9-11, 13-15, and 18 are pending in the application.
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 .
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.
Examiner’s Notes
The Examiner cites particular sections in the references as applied to the claims below for the convenience of the applicant(s). 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(s) 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 or disclosed by the Examiner.
Priority
Receipt is acknowledged of certified copies of papers required by 37 CFR 1.55.
Should applicant desire to obtain the benefit of foreign priority under 35 U.S.C. 119(a)-(d) prior to declaration of an interference, a certified English translation of the foreign application must be submitted in reply to this action. 37 CFR 41.154(b) and 41.202(e).
Failure to provide a certified translation may result in no benefit being accorded for the non-English application.
Response to Amendment
Amendments to claims 5 and 14 are fully considered and are satisfactory to overcome the rejections under 35 U.S.C. §112(b) directed to claims 5-6 and 14-15 in the previous Office Action.
Specification
The use of the term LINUX, which is a trade name or a mark used in commerce, has been noted in this application. The term should be accompanied by the generic terminology; furthermore the term should be capitalized wherever it appears or, where appropriate, include a proper symbol indicating use in commerce such as ™, SM , or ® following the term.
Although the use of trade names and marks used in commerce (i.e., trademarks, service marks, certification marks, and collective marks) are permissible in patent applications, the proprietary nature of the marks should be respected and every effort made to prevent their use in any manner which might adversely affect their validity as commercial marks.
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, 2, 5, 10, 11, and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Cooper et al. (US 6,418,485 B1; hereinafter “Cooper”) in view of Siddappa et al. (US 2021/0034416 A1; hereinafter “Siddappa”).
With respect to claim 1, Cooper teaches: An electronic device (see e.g. Cooper, Fig. 1) comprising:
a memory interface configured to access a memory (see e.g. Cooper, Fig. 1: “RAM 16”, “ROM 14”) storing a plurality of program instructions or codes (see e.g. Cooper, column 6, lines 55-58: “invention can be implemented as sets of instructions resident in the random access memory 16 of one or more computer systems configured generally as described in FIG. 1”) of an operating system (see e.g. Cooper, Fig. 2: “Operating System 50”); and
Since Cooper discloses RAM 16 and ROM 14 (i.e. memory hardware) and a processor 10 connecting and communicating with the RAM 16 and ROM 14 (see e.g. Cooper, Fig. 1; column 3, lines 37-60), Cooper inherently discloses corresponding memory interfaces for the RAM 16 and ROM 14.
a processor (see e.g. Cooper, Fig. 1: “Processor 10”) configured to execute the program instructions or codes to perform following steps (see e.g. Cooper, column 4, lines 29-32: “information handling system depicted in FIG. 1 will have one or more images of an operating system 50 for controlling operation of the processors 10”):
(A) executing the operating system to generate an operation command (see e.g. Cooper, column 5, lines 44-47: “Calling the API causes the operating system to gain control (step 102). The operating system determines which DDI or DDIs need to be called in order to accomplish the desired function”; and Fig. 4, steps 102, 104);
(B) retrieving, from a lookup table (see e.g. Cooper, Fig. 2: “Function Tables 60”) according to the operation command (see e.g. Cooper, column 4, lines 38-40: “function table indicates whether an operating system DDI 61, or a device driver DDI 64, will be passed control to handle the function”), a driver command corresponding to the operation command (see e.g. Cooper, column 5, lines 51-54: “For each DDI that must be called, the operating system checks the device function table to determine if the device driver will handle the DDI function”; from column 5, line 63 to column 6, line 13: “if the device driver is handling the function… The operating system calls the device driver (step 112), passing it any normally passed parameters, and the device driver then handles the DDI function (step 114)… the operating system passes the logical device state information to the DDI (step 116), and the device driver then proceeds to handle the function”; and Fig. 4, steps 106, 112, 116); and
(C) executing the driver command (see e.g. Cooper, column 6, lines 3-13: “The operating system calls the device driver (step 112), passing it any normally passed parameters, and the device driver then handles the DDI function (step 114)… the operating system passes the logical device state information to the DDI (step 116), and the device driver then proceeds to handle the function (step 118)”; and Fig. 4, steps 114, 118); and
wherein when the operating system is a kernel-based operating system (see e.g. Cooper, Fig. 2: “Operating System 50”; and column 4, lines 29-32: “information handling system depicted in FIG. 1 will have one or more images of an operating system 50 for controlling operation of the processors 10”; note that an operating system inherently discloses kernel-level functions of the operating system) and
Cooper discloses an operating system (OS) that receives a device function invocation from an application and determines which device driver interfaces (DDIs) need to be called corresponding to the invoked device function (i.e. The OS generates operational commands corresponding to the invoked function) (see Cooper, Fig. 4, steps 102, 104). The OS checks function tables to determine if a device driver registered to handle the invoked function (i.e. if a driver command corresponding to the invoked function will be issued) (see Cooper, Fig. 4, step 106). If there is a device driver registered for the invoked function, then the OS calls the registered device driver to handle the function (i.e. a driver command is issued and the device driver executes to handle the invoked function) (see e.g. Cooper, Fig. 4, steps 114, 118).
On the other hand, Cooper does not but Siddappa teaches:
the processor further executes a real-time operating system (see e.g. Siddappa, paragraph 41: “a Real Time Operating System (RTOS) for controlling task scheduling in the plurality of cores (such as the source processing core 202a and the destination processing core 202b)”), the processor further performing following steps:
sending the operation command or an identification corresponding to the operation command to the real-time operating system (see e.g. Siddappa, paragraph 41: “a Real Time Operating System (RTOS) for controlling task scheduling in the plurality of cores (such as the source processing core 202a and the destination processing core 202b)”; paragraph 44: “entity suspend list may include identifiers of activities (e.g., tasks) that have been suspended from execution. For example, the tasks ready list may include identifiers of activities (e.g., tasks) that are ready for execution. For example, the tasks in RTOS may need resources and can be in a SUSPEND state (i.e., all such tasks are in Task Suspend List (TSL)/entity suspended list). They are moved to a READY state (the state is stored in a Task Management Unit (TMU)) when the resource becomes available (such tasks are in Task Ready List (TRL))”), wherein step (B) is executed in the real-time operating system (see e.g. Siddappa, paragraph 44: “multi-core processor 202 may include a lookup table. Whenever activities (e.g., tasks) are to be partitioned across cores in the multi-core processor, the lookup table may be used to determine the assignment of the tasks to the cores 202a and 202b… the tasks in RTOS may need resources and can be in a SUSPEND state (i.e., all such tasks are in Task Suspend List (TSL)/entity suspended list). They are moved to a READY state (the state is stored in a Task Management Unit (TMU)) when the resource becomes available (such tasks are in Task Ready List (TRL))”).
Cooper and Siddappa are analogous art because they are in the same field of endeavor: managing function/task executions by utilizing a look up table. Therefore, it would have been obvious to one with ordinary skill in the art before the effective filing date of the claimed invention to modify Cooper with the teachings of Siddappa. The motivation/suggestion would be to better accommodate time-sensitive programs; thus increasing the overall reliability of the system.
With respect to claim 2, Cooper as modified teaches: The electronic device of claim 1, wherein the operation command is generated by an application layer (see e.g. Cooper, Fig. 2: “Application 52”) of the operating system (see e.g. Cooper, column 5, lines 38-47: “Suppose an application program wishes to perform a particular device function. The function may be a simple state change type of function (e.g. changing the font for a document), or may be a complex graphics rendering operation. The application program executes an appropriate API to request that the function be performed (step 100). Calling the API causes the operating system to gain control (step 102). The operating system determines which DDI or DDIs need to be called in order to accomplish the desired function (step 104)”; and Fig. 4, steps 100, 102).
With respect to claim 5, Cooper as modified teaches: The electronic device of claim 1, wherein the operating system is the kernel-based operating system (see e.g. Cooper, Fig. 2: “Operating System 50”; and column 4, lines 29-32: “information handling system depicted in FIG. 1 will have one or more images of an operating system 50 for controlling operation of the processors 10”; note that, an operating system inherently discloses kernel-level functions of the operating system), the processor further performs following steps:
(D) receiving an application layer (see e.g. Cooper, Fig. 2: “Application 52”) command (see e.g. Cooper, column 4, lines 32-35: “Application programs 52 will execute in the system, and will often make calls to operating system 50, through the use of application interface 54, to request operating system 50 to perform certain tasks”; and column 5, lines 38-47: “Suppose an application program wishes to perform a particular device function. The function may be a simple state change type of function (e.g. changing the font for a document), or may be a complex graphics rendering operation. The application program executes an appropriate API to request that the function be performed (step 100). Calling the API causes the operating system to gain control (step 102). The operating system determines which DDI or DDIs need to be called in order to accomplish the desired function (step 104)”; and Fig. 4, steps 100, 102);
(E) creating a device node (see e.g. Cooper, column 4, lines 36-44: “For each device in the system, operating system 50 contains a function table 60… Operating system 50 also includes a logical state information buffer 62 for each device. Logical state information buffer 62 stores the logical device state information for each device, and also stores registration information”);
(F) operating the device node to retrieve a kernel command corresponding to the application layer command (see e.g. Cooper, column 4, lines 36-40: “For each device function (i.e. each device DDI), the function table indicates whether an operating system DDI 61, or a device driver DDI 64, will be passed control to handle the function”; column 5, lines 51-58: “For each DDI that must be called, the operating system checks the device function table to determine if the device driver will handle the DDI function or if the operating system will handle the DDI function (step 106). Note that the operating system can determine this by checking the address that is present in the function table. If the address is within the operating system's memory space, the operating system is handling the function”; and column 5, lines 61-63: “If the operating system is handling the function, the operating system proceeds to call an operating system program to perform the function”); and
(G) retrieving the operation command corresponding to the kernel command (see e.g. Cooper, column 5, lines 61-63: “If the operating system is handling the function, the operating system proceeds to call an operating system program to perform the function (step 108)”).
With respect to claims 10, 11, and 14: Claims 10, 11, and 14 are directed to a method corresponding to the active functions implemented by the electronic device recited in claims 1, 2, and 5, respectively; please see the rejections directed to claims 1, 2, and 5 above which also cover the limitations recited in claims 10, 11, and 14.
Claims 4, 6, 13, and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Cooper in view of Siddappa as applied to claims 1, 5, 10, and 14 above, and further in view of Applicant’s Admitted Prior Art (AAPA).
With respect to claim 4, Cooper as modified teaches: The electronic device of claim 1, wherein the operating system comprises… an application layer (see e.g. Cooper, Fig. 2: “Application 52”), and … an application layer command generated by the application layer (see e.g. Cooper, column 5, lines 38-47: “Suppose an application program wishes to perform a particular device function. The function may be a simple state change type of function (e.g. changing the font for a document), or may be a complex graphics rendering operation. The application program executes an appropriate API to request that the function be performed (step 100). Calling the API causes the operating system to gain control (step 102). The operating system determines which DDI or DDIs need to be called in order to accomplish the desired function (step 104)”; and Fig. 4, steps 100, 102).
Cooper does not but AAPA teaches:
a frame buffer framework (see e.g. AAPA, Fig. 1 (prior art): “frame buffer framework 130”) and
the frame buffer framework generates the operation command in response to (see e.g. AAPA, page 1, paragraph 2: “frame buffer framework 130 is an interface that the Linux system provides for display devices. The frame buffer framework 130 abstracts the display buffer, hides the underlying differences of image hardware, and allows the application layer 110 to perform, in the graphics mode, read and write operations on the display buffer directly or indirectly (e.g., by calling a function of the GUI library 120”)
Cooper and AAPA are analogous art because they are in the same field of endeavor: managing device drivers to handle application calls directed to corresponding devices via an operating system. Therefore, it would have been obvious to one with ordinary skill in the art before the effective filing date of the claimed invention to modify Cooper with the teachings of AAPA. The motivation/suggestion would be to provide an abstraction layer that would simplify the interactions between the application software and the hardware platform; thus improving the overall software development process.
With respect to claim 6, Cooper as modified teaches: The electronic device of claim 5, wherein the kernel command is a command (see e.g. Cooper, column 5, lines 61-63: “If the operating system is handling the function, the operating system proceeds to call an operating system program to perform the function (step 108)”)
Cooper does not but AAPA teaches:
of a frame buffer framework (see e.g. AAPA, page 1, paragraph 2: “frame buffer framework 130 is an interface that the Linux system provides for display devices. The frame buffer framework 130 abstracts the display buffer, hides the underlying differences of image hardware, and allows the application layer 110 to perform, in the graphics mode, read and write operations on the display buffer directly or indirectly (e.g., by calling a function of the GUI library 120”).
Cooper and AAPA are analogous art because they are in the same field of endeavor: managing device drivers to handle application calls directed to corresponding devices via an operating system. Therefore, it would have been obvious to one with ordinary skill in the art before the effective filing date of the claimed invention to modify Cooper with the teachings of AAPA. The motivation/suggestion would be to provide an abstraction layer that would simplify the interactions between the application software and the hardware platform; thus improving the overall software development process.
With respect to claims 13 and 15: Claims 13 and 15 are directed to a method corresponding to the active functions implemented by the electronic device recited in claims 4 and 6, respectively; please see the rejections directed to claims 4 and 6 above which also cover the limitations recited in claims 13 and 15.
Claims 9 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Cooper in view of Siddappa as applied to claims 1 and 10 above, and further in view of Mitamura (US 2014/0085448 A1).
With respect to claim 9, Cooper as modified teaches: The electronic device of claim 1, wherein the operation command is related to creating a storage space in the memory (see e.g. Cooper, column 6, lines 27-41: “A device driver may register for a particular functional DDI (e.g. a graphics primitive DDI), without having to register for the dozens of associated state change DDIs that may be associated with the functional DDI. For example, suppose an application program wanted to both change a font type and print a line of text. The most efficient way to handle this would be to let the operating system handle the state change (i.e. the font change), and let the device driver handle the text output. Thus, the device driver would not register to handle the font change DDI, rather the operating system default DDI would handle it (i.e. step 108 would be taken in FIG. 4). However, the device driver would register to handle the text output DDI function. The device driver would also register to receive logical device state information”), the electronic device further comprising:
a graphics engine configured to generate an image (see e.g. Cooper, column 5, lines 40-43: “The function may be a simple state change type of function (e.g. changing the font for a document), or may be a complex graphics rendering operation”) and
Cooper does not but Mitamura teaches:
store the image in the storage space corresponding to the operation command (see e.g. Mitamura, paragraph 20: “a three-dimensional image storage circuit (storage unit) 103 that records a three-dimensional image of the subject acquired by a three-dimensional observation device”); and
a superposition circuit (see e.g. Mitamura, Fig. 2: “Superposition processing circuit 106”) configured to read the image from the storage space and superpose the image with another image (see e.g. Mitamura, paragraph 20: “a superposition processing circuit (superposition processing unit) 106 that generates a superposed image G5 by superposing the multiplied image G4 on the white-light image G1”).
Cooper and Mitamura are analogous art because they are in the same field of endeavor: managing image processing operations. Therefore, it would have been obvious to one with ordinary skill in the art before the effective filing date of the claimed invention to modify Cooper with the teachings of Mitamura. The motivation/suggestion would be to increase the image processing capabilities; thus improving the overall efficiency of the system.
With respect to claim 18: Claim 18 is directed to a method corresponding to the active functions implemented by the electronic device recited in claim 9; please see the rejection directed to claim 9 above which also cover the limitations recited in claim 18.
Response to Arguments
Applicant's arguments filed 04/23/2026 have been fully considered but they are not persuasive. In detail:
(i) Regarding Applicant’s arguments with respect to the objections directed to the specification (Remarks, page 6), note that the trademark used in the specification should be capitalized wherever it appears, such as in paragraphs [0032], [0033], [0034], etc., in addition to the paragraph [0002]. As such, the corresponding objections are maintained.
Applicant’s arguments with respect to the limitations “the processor further executes a real-time operating system, the processor further performing following steps: sending the operation command or an identification corresponding to the operation command to the real-time operating system, wherein step (B) is executed in the real-time operating system” recited in claim 1, and the similar limitations recited in claim 10, have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
CONCLUSION
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Ehtemam-Haghighi et al. (US 2016/0202673 A1) discloses a multi-core processor that executes a RTOS on a first core and a standard OS on a second core which communicate via a shared memory (see paragraph 49; Fig. 3).
Yu (US 2025/0238065 A1) discloses an electronic device that runs two systems, such as a RTOS and an Android, simultaneously and can switch between the two systems (see paragraph 25).
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.
Contact Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Umut Onat whose telephone number is (571)270-1735. The examiner can normally be reached M-Th 9:00-7:30.
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, Kevin L Young can be reached at (571) 270-3180. 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.
/UMUT ONAT/Primary Examiner, Art Unit 2194
Prosecution Insights