DETAILED ACTION
Authorization for Internet Communications
The examiner encourages Applicant to submit an authorization to communicate with the examiner via the Internet by making the following statement (from MPEP 502.03):
“Recognizing that Internet communications are not secure, I hereby authorize the USPTO to communicate with the undersigned and practitioners in accordance with 37 CFR 1.33 and 37 CFR 1.34 concerning any subject matter of this application by video conferencing, instant messaging, or electronic mail. I understand that a copy of these communications will be made of record in the application file.”
Please note that the above statement can only be submitted via Central Fax, Regular postal mail, or EFS Web (PTO/SB/439).
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 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 Notes
Examiner cites particular columns and line numbers in the references as applied to the claims below for the convenience of the applicant. 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 fully consider the references in 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.
Allowable Subject Matter
Claims 1-8, would be allowable if rewritten or amended to overcome the rejection(s) under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), 2nd paragraph, set forth in this Office action.
Claims 15-20, would be allowable if rewritten or amended to overcome the rejection(s) under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), 2nd paragraph, set forth in this Office action and by combining the subject matter of claim 15, 16 and 17 (thereby corresponding to claim 1).
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.
The term “response fidelity” in claims 1-20 are relative terms which renders the claim indefinite. The term “response fidelity” is not defined by the claim, the specification does not provide a standard for ascertaining the requisite degree, and one of ordinary skill in the art would not be reasonably apprised of the scope of the invention. It is not clear how to establish “fidelity” criteria without a specific definition in the specification. The term is unclear.
Claims 9-14 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.
Regarding claim 9, recites “to store instructions” and it is not clear whether the memory actually stores instructions or merely intended to. Correction is required. Claim 10-14 are rejected based on dependency.
Claims 15-20 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being incomplete for omitting essential steps, such omission amounting to a gap between the steps. See MPEP § 2172.01. The omitted steps are the steps seen in claims 16 and 17, Fig. 9, 906, 908, 91-, and 912, described in specification [0113] to [120]. Claims 16 and 17 subject matters should not be omitted from claim 15.
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) 9-16, and 18-20 are rejected under 35 U.S.C. 103 as being unpatentable over Larsen et al, (U.S. PG PUB 2009/0280906) in view of Guedalia et al. (U.S. PG PUB 2003/0088609).
Regarding claim 9, Larsen teaches an electronic system comprising:
one or more processors (see ¶[0058]); and
one or more non-transitory computer-readable memories to store instructions (see ¶[0058]), wherein the instructions, when executed by the one or more processors, cause the one or more processors to:
create a first processing thread (see ¶[0649] “After the file validation driver and kernel free block validation process have been started, additional background processes are started. The first thread is used to insure that no existing files have been modified and no new files have been added. The second one is used to insure that unused areas of the storage media are zero filled and to zero fill unused areas of the modified disk partitions after an authorized change has been made.”);
submit, to a thread watchdog manager, a first request to watch the first processing thread (see ¶[0659] “The EGM contains a hardware watchdog register which is used by the fault management support to insure that all required processes and threads in the gaming software are active and functioning.”); and
queue one or more first tasks to the first processing thread (see ¶[0115] “In one embodiment of the server-client download throttling system 280, Method One 330 consists of two separate threads Part 1 (330A) and Part 2 (330B) that work concurrently. For both threads 330A and 330B of Method One, the Download Task 30 begins a download to the gaming machine 300, upon request. In one embodiment, the Method One Part 1 330A download to the Buffer 350 in the RAM occurs independently from the Method One Part 2 330B data writes from the Buffer 350 to the FLASH 360 (or any attached storage media such as hard disk drive(s), flash memory, or remote server-based storage).”);
wherein: the first request comprises a first response fidelity (see ¶[0661] “The Faultdog support interfaces with the watchdog support to detect if a required thread no longer exists and to restart the EGM after a fault has been detected, reported and acknowledged. The faultdog manager may be the only process in the system that interacts with the watchdog support in order to increase the level of integrity and assurance.”); and
the thread watchdog manager causes a hardware watchdog to reboot the electronic system if the first processing thread fails to meet the first response fidelity (see ¶[0661] “The Faultdog support interfaces with the watchdog support to detect if a required thread no longer exists and to restart the EGM after a fault has been detected, reported and acknowledged. The faultdog manager may be the only process in the system that interacts with the watchdog support in order to increase the level of integrity and assurance.”).
Larsen does not expressly disclose, however, Guedalia teaches create a first processing thread in an operating system of the electronic system (see ¶[0026] “ Modern operating systems support multi-tasking, which is the ability to run many separate applications at the same time. A single software program can take advantage of multi-tasking by creating multiple concurrent "threads." Each thread simulates a separate application. Thus an HTTP server, for example, can use multiple threads to optimize its performance in responding to concurrent requests. Each request can be processed in a separate thread, and while one request is being processed in the CPU, a second request can be transmitted through the network hardware. If only one thread is used, then although the network hardware is buffered, the processing of the second request can become blocked--because the single thread waits for the network to finish sending.”).
Hence, it would have been obvious to one or ordinary skill in the art before the effective filing date was made to modify the teachings of Larsen by adapting Guedalia to manage threads using watchdog for better performance (see ¶[0112] of Guedalia).
Regarding claim 10, Larsen teaches wherein the first request comprises a Boolean flag indicating whether the first processing thread is allowed to terminate (see ¶[0665] “Manual CPU Reset: Writing all zeros to the `NW Watchdog Register` forces a manual hardware reset to the CPU. To prevent glitches inadvertently resetting the system when enabling the watchdog, the timeout value should already be a non-zero value, prior to clearing a reset flag.”).
Regarding claim 11, Larsen teaches wherein the first response fidelity comprises a first response time interval that the first processing thread is to meet to prevent rebooting of the electronic system (see ¶[0667] “Catch kernel panic errors, show detail information about panic and prevent the EGM from automatically rebooting after the panic occurs.”).
Regarding claim 12, Larsen teaches wherein the instructions further cause the one or more processors to: submit, to the thread watchdog manager, a second request to cease watching the first processing thread (see ¶[0663] “These two limitations prevent enabling and disabling the watchdog with different applications, so the watchdog should be initialized at power-up or not at all.”).
Regarding claim 13, Larsen teaches wherein the instructions further cause the one or more processors to: submit, to the thread watchdog manager, a third request to watch the first processing thread, wherein the third request comprises a second response fidelity that is different from the first response fidelity (see ¶[0667] “The basic functions of the faultdog may include: (1) Monitor all registered processes to detect errors or unauthorized removal of them. (2) Manage the hardware watchdog register to avoid system hangs. (3) Display generic user message when a fatal error occurs and turns on top box lights. (4) Log detailed fault description message when fatal error occurs. (5) Display detail fault description message when the attendant key is turned. (6) Display a message when the door is opened after a fault has occurred. (7) Display a message when a Game or OS flash has been removed. (8) Automatically detects cabinet type and port configuration. (9) Automatically reboots the EGM when attendant key is turned for the 2nd time after a fatal error. (10) Independence from any specific video or I/O requirements. (11) Catch kernel panic errors, show detail information about panic and prevent the EGM from automatically rebooting after the panic occurs.”); and queue one or more second tasks to the first processing thread (see ¶[0115] “In one embodiment of the server-client download throttling system 280, Method One 330 consists of two separate threads Part 1 (330A) and Part 2 (330B) that work concurrently. For both threads 330A and 330B of Method One, the Download Task 30 begins a download to the gaming machine 300, upon request. In one embodiment, the Method One Part 1 330A download to the Buffer 350 in the RAM occurs independently from the Method One Part 2 330B data writes from the Buffer 350 to the FLASH 360 (or any attached storage media such as hard disk drive(s), flash memory, or remote server-based storage).”).
Regarding claim 14, Larsen teaches wherein the instructions further cause the one or more processors to: create a second processing thread in the operating system of the electronic system (see [1153] “In one embodiment of the server-client download throttling system 280, Method One 330 consists of two separate threads Part 1 (330A) and Part 2 (330B) that work concurrently. For both threads 330A and 330B of Method One, the Download Task 30 begins a download to the gaming machine 300, upon request. In one embodiment, the Method One Part 1 330A download to the Buffer 350 in the RAM occurs independently from the Method One Part 2 330B data writes from the Buffer 350 to the FLASH 360 (or any attached storage media such as hard disk drive(s), flash memory, or remote server-based storage).”);
submit, to the thread watchdog manager, a fourth request to watch the second processing thread, wherein the fourth request comprises a third response fidelity (see ¶[0667] “The basic functions of the faultdog may include: (1) Monitor all registered processes to detect errors or unauthorized removal of them. (2) Manage the hardware watchdog register to avoid system hangs. (3) Display generic user message when a fatal error occurs and turns on top box lights. (4) Log detailed fault description message when fatal error occurs. (5) Display detail fault description message when the attendant key is turned. (6) Display a message when the door is opened after a fault has occurred. (7) Display a message when a Game or OS flash has been removed. (8) Automatically detects cabinet type and port configuration. (9) Automatically reboots the EGM when attendant key is turned for the 2nd time after a fatal error. (10) Independence from any specific video or I/O requirements. (11) Catch kernel panic errors, show detail information about panic and prevent the EGM from automatically rebooting after the panic occurs.”); and queue one or more third tasks to the second processing thread (see ¶[0115] “In one embodiment of the server-client download throttling system 280, Method One 330 consists of two separate threads Part 1 (330A) and Part 2 (330B) that work concurrently. For both threads 330A and 330B of Method One, the Download Task 30 begins a download to the gaming machine 300, upon request. In one embodiment, the Method One Part 1 330A download to the Buffer 350 in the RAM occurs independently from the Method One Part 2 330B data writes from the Buffer 350 to the FLASH 360 (or any attached storage media such as hard disk drive(s), flash memory, or remote server-based storage).”).
Regarding claim 15, Larsen teaches one or more non-transitory computer-readable media storing instructions that, when executed by one or more processors, cause the one or more processors to: receive a first request to watch a first processing thread (see ¶[0115] “In one embodiment of the server-client download throttling system 280, Method One 330 consists of two separate threads Part 1 (330A) and Part 2 (330B) that work concurrently. For both threads 330A and 330B of Method One, the Download Task 30 begins a download to the gaming machine 300, upon request. In one embodiment, the Method One Part 1 330A download to the Buffer 350 in the RAM occurs independently from the Method One Part 2 330B data writes from the Buffer 350 to the FLASH 360 (or any attached storage media such as hard disk drive(s), flash memory, or remote server-based storage).”), wherein the first request comprises a first response fidelity (see ¶[0661] “The Faultdog support interfaces with the watchdog support to detect if a required thread no longer exists and to restart the EGM after a fault has been detected, reported and acknowledged. The faultdog manager may be the only process in the system that interacts with the watchdog support in order to increase the level of integrity and assurance.”); set a first loop timer to expire at a first expiration time corresponding to the first response fidelity, and to cause a hardware watchdog to execute a reboot of the electronic system upon an expiration of the first loop timer (see ¶[0669] “The faultdog manager also resets the hardware watchdog timer to signal that the system is still alive. If for any reason, the faultdog manager does not reset the hardware watchdog timer, it will expire and cause a system failure. The faultdog driver and process insure that all of the required processes are still active, and the hardware watchdog timer is used to verify that the faultdog code is still active.”); queue a first reverse tickle task to the first processing thread, wherein the first reverse tickle task is executable by a processor of the electronic system (see ¶[0132] “managing the timeout for the keep alive. For example, when a timeout occurs, a communication status event may be sent to the appropriate communications Class so that a keep Alive command can be generated.”); set a queue time to a kernel time of the operating system of the electronic system (see ¶[0079] “All verification failures and related errors may be logged, and the log entry may contain the date and time, the ID of the person running the process at the time, and the specific type of error that occurred. The verification failures may also be displayed on the correct display area.”); and in response to the first loop timer expiring at the first expiration time before the first reverse tickle task executes, cause the hardware watchdog to reboot the electronic system (see ¶[0661] “The Faultdog support interfaces with the watchdog support to detect if a required thread no longer exists and to restart the EGM after a fault has been detected, reported and acknowledged. The faultdog manager may be the only process in the system that interacts with the watchdog support in order to increase the level of integrity and assurance.”).
Larsen does not expressly disclose, however, Guedalia teaches receive a first request to watch a first processing thread in an operating system of an electronic system (see ¶[0026] “ Modern operating systems support multi-tasking, which is the ability to run many separate applications at the same time. A single software program can take advantage of multi-tasking by creating multiple concurrent "threads." Each thread simulates a separate application. Thus an HTTP server, for example, can use multiple threads to optimize its performance in responding to concurrent requests. Each request can be processed in a separate thread, and while one request is being processed in the CPU, a second request can be transmitted through the network hardware. If only one thread is used, then although the network hardware is buffered, the processing of the second request can become blocked--because the single thread waits for the network to finish sending.”).
Hence, it would have been obvious to one or ordinary skill in the art before the effective filing date was made to modify the teachings of Larsen by adapting Guedalia to manage threads using watchdog for better performance (see ¶[0112] of Guedalia).
Regarding claim 16, Larsen teaches wherein the instructions further cause the one or more processors to: in response to the first loop timer expiring at the first expiration time before the first reverse tickle task executes, cause the hardware watchdog to reboot the electronic system upon the expiration of the first loop timer (see ¶[0669] “The faultdog manager also resets the hardware watchdog timer to signal that the system is still alive. If for any reason, the faultdog manager does not reset the hardware watchdog timer, it will expire and cause a system failure. The faultdog driver and process insure that all of the required processes are still active, and the hardware watchdog timer is used to verify that the faultdog code is still active.”).
Regarding claim 18, Larsen does not expressly disclose, however, Guedalia teaches wherein executing the first reverse tickle task further comprises: setting a response time to a further kernel time of the operating system of the electronic system and determining a duration based on the response time and the queue time (see ¶[0246] “The 101 msecs corresponds to a thread that started activity at exactly a watchdog checkpoint time, and the 150 msecs corresponds to a thread that started its activity 1 msec after a watchdog checkpoint time. Since a new thread is created when an active thread is removed from the thread pool, this maximum time is also the maximum time that a request queue can build up without any of the queued requests being handled.”).
Regarding claim 19, Larsen teaches wherein executing the first reverse tickle task further comprises: in response to determining the duration is greater than the first response fidelity (see ¶ [00662] “If the watchdog circuit is enabled, its timeout counter must be regularly cleared before the timeout period. If a timeout does occur, it indicates that the CPU must be locked-up, and the CPU is hardware reset. An enable bit enables both the watchdog and the I/O Halt from the Protection Circuit. One or more bits may set the timeout period. For example a 7-bit field with a resolution of 0.1S and may provide a range of 0.1-12.8 seconds. The incrementing of the timer and writes to the timeout register are not synchronized, so the timeout period has 0.1S of tolerance which may be important for small timeout values.”), causing a hardware watchdog to reboot the electronic system (see ¶[0669] “The faultdog manager also resets the hardware watchdog timer to signal that the system is still alive. If for any reason, the faultdog manager does not reset the hardware watchdog timer, it will expire and cause a system failure. The faultdog driver and process insure that all of the required processes are still active, and the hardware watchdog timer is used to verify that the faultdog code is still active.”).
Regarding claim 20, Larsen teaches wherein executing the first reverse tickle task further comprises: in response to determining the duration is less than the first response fidelity, resetting the first loop timer to queue a second reverse tickle task upon the expiration of the first loop timer instead of causing the hardware watchdog to execute the reboot (see ¶[0669] “The faultdog manager also resets the hardware watchdog timer to signal that the system is still alive. If for any reason, the faultdog manager does not reset the hardware watchdog timer, it will expire and cause a system failure. The faultdog driver and process insure that all of the required processes are still active, and the hardware watchdog timer is used to verify that the faultdog code is still active.”).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Pfohe et al. U.S. PG PUB (2004/0034510) teaches log information by reading a configuration file to determine a destination for sending logging information. The logging information is sent to the destination. Additional logging information is generated. It is determined whether the configuration file has been updated to indicate a new destination instead of the destination. When the configuration file has not been updated to indicate the new destination, the additional logging information is sent to the destination. When the configuration file has been updated to indicate the new destination, the additional logging information is sent to the new destination.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CARINA YUN whose telephone number is (571)270-7848. The examiner can normally be reached Mon, Tues, Thurs, 9-4 (EST).
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 call.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Kevin Young can be reached on (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.
Carina Yun
Patent Examiner
Art Unit 2194
/CARINA YUN/Examiner, Art Unit 2194
Prosecution Insights