DETAILED ACTION
Claims 1-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.
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 § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 5-8 and 14-17 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claims 5, 7, 8, 14, 16, and 17 contain the trademark/trade name LINUX. Where a trademark or trade name is used in a claim as a limitation to identify or describe a particular material or product, the claim does not comply with the requirements of 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph. See Ex parte Simpson, 218 USPQ 1020 (Bd. App. 1982). The claim scope is uncertain since the trademark or trade name cannot be used properly to identify any particular material or product. A trademark or trade name is used to identify a source of goods, and not the goods themselves. Thus, a trademark or trade name does not identify or describe the goods associated with the trademark or trade name. In the present case, the trademark/trade name is used to identify/describe an operating system and, accordingly, the identification/description is indefinite.
Claims 6 and 15 are also rejected as being indefinite under 35 U.S.C. §112(b) because they inherit the features of claims 5 and 14, respectively.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1-3 and 10-12 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Cooper et al. (US 6,418,485 B1; hereinafter Cooper).
With respect to claim 1, Cooper teaches: An electronic device (see e.g. Fig. 1) comprising:
a memory interface configured to access a memory (see e.g. Fig. 1: “RAM 16”, “ROM 14”) storing a plurality of program instructions or codes (see e.g. 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. 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. 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. Fig. 1: “Processor 10”) configured to execute the program instructions or codes to perform following steps (see e.g. 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. 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. Fig. 2: “Function Tables 60”) according to the operation command (see e.g. 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. 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. 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).
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 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 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. Fig. 4, steps 114, 118).
With respect to claim 2, Cooper teaches: The electronic device of claim 1, wherein the operation command is generated by an application layer (see e.g. Fig. 2: “Application 52”) of the operating system (see e.g. 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 3, Cooper teaches: The electronic device of claim 2, wherein the operating system is a real-time operating system (see e.g. column 5, lines 43-48: “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”; and Fig. 4).
With respect to claims 10-12: Claims 10-12 are directed to a method corresponding to the active functions implemented by the electronic device recited in claims 1-3, respectively; please see the rejections directed to claims 1-3 above which also cover the limitations recited in claims 10-12.
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 4-8 and 13-17 are rejected under 35 U.S.C. 103 as being unpatentable over Cooper in view of Applicant’s Admitted Prior Art (AAPA).
With respect to claim 4, Cooper 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 5, Cooper teaches: The electronic device of claim 1, wherein…, 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)”).
Cooper does not but AAPA teaches:
when the operating system is a Linux system (see e.g. AAPA, page 1, paragraph 2: “FIG. 1 shows a schematic diagram of an operating system architecture of a conventional embedded device… Linux system”)
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 compatibility with different systems.
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 claim 7, Cooper teaches: The electronic device of claim 1, wherein… the processor further executes a real-time operating system (see e.g. Cooper, column 5, lines 43-48: “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”; and Fig. 4), 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. 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)”), wherein step (B) is executed in the real-time operating system (see e.g. 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”; and 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”).
Cooper does not but AAPA teaches:
when the operating system is a Linux system (see e.g. AAPA, page 1, paragraph 2: “FIG. 1 shows a schematic diagram of an operating system architecture of a conventional embedded device… Linux system”) and
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 compatibility with different systems.
With respect to claim 8, Cooper teaches: The electronic device of claim 1, wherein… step (B) comprises:
retrieving a user command corresponding to the operation 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);
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”);
operating the device node to retrieve a kernel command corresponding to the user 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-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 or if the operating system will handle the DDI function (step 106)”; and 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
retrieving the driver command according to the kernel 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).
Cooper does not but AAPA teaches:
when the operating system is a Linux system (see e.g. AAPA, page 1, paragraph 2: “FIG. 1 shows a schematic diagram of an operating system architecture of a conventional embedded device… Linux system”)
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 compatibility with different systems.
With respect to claims 13-17: Claims 13-17 are directed to a method corresponding to the active functions implemented by the electronic device recited in claims 4-8, respectively; please see the rejections directed to claims 4-8 above which also cover the limitations recited in claims 13-17.
Claims 9 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Cooper in view of Mitamura (US 2014/0085448 A1).
With respect to claim 9, Cooper 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.
CONCLUSION
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Chui et al. (US 2007/0198996 A1) discloses a middleware that generates relationships between standard commands and device driver commands and translates communications between a host and a peripheral device accordingly (see paragraph 22).
Zhou et al. (US 2015/0212832 A1) discloses redirecting device driver functions from kernel space to user space by utilizing a lookup table (see paragraph 59).
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