DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claims 1-20 are pending for examination in this application. Claims 1, 7, and 15 are independent claims. This Office Action is Non-Final.
Specification
The disclosure is objected to because of the following informalities: paragraph 0007 “Fig. 5 is a flow diagram of an exemplary method for …” is incomplete description and sentence, please complete the description of Fig. 5. Appropriate correction is required.
Claim Rejections - 35 USC § 102
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.
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.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1-20 are rejected under 35 U.S.C. 102(a)(1) and 35 U.S.C. 102(a)(2) as being anticipated by Weber et al., (U.S. Patent Num.: 7,243,264 B2), hereinafter Weber.
Regarding claim 1, Weber teaches:
A device (Weber, Fig. 3 and Fig. 7 micronetwork 302, col. 2 lines 19-35 “ IP cores (such as 304-1 through 304-n, and 310-1 through 310-m) are classified as either being initiators (such as 304-1 through 304-n) or targets (such as, 310-1 through 310-m)”) comprising:
a control circuit (Weber, Fig. 7, central controller 708 “how the error indications from different agents (704-1 through 704-n, and 706-1 through 706-m) are collected centrally 708 and sent to a specific initiator 710.”) configured to:
mark a thread as isolated in response to an error interrupt corresponding to the thread (Examiner under BRI interprets a thread as corresponding to a processor core. Weber, Fig. 4, Table 1, hardware isolates error core from rest of system. Fig. 5, col. 2, lines 49-67 teaches “FIG. 5A, the initiator 502 has sent a request 504 to the target 510 via the initiator agent 506, microNetwork 512, and target agent 508. The target core 510 may have stopped servicing requests and thus never issues the corresponding responses. The initiator of those requests may now be stuck waiting on the responses. The initiating agent (such as 506) and target agents (one such as 508) together decide when the request has been outstanding for too long, and to declare the target core broken. In FIG. 5B the initiating agent 506 sends a timeout request 520 [i.e. interrupt], and the target agent 508 replies with a timeout acknowledgement 522, thus allowing the timeout. At this point, as shown in FIG. 5C the target agent 508 isolates the target core 510 from the rest of the system (at the isolation boundary 540). It does not allow any new requests to be issued to that target (actions shown as 542) and drops any responses 532 arriving from the target 510, so that they cannot contaminate the rest of the system.”); and
send a notification of isolating the thread to a partner thread of the isolated thread (Weber, Fig. 5, col. 2, lines 49-67 teaches “FIG. 5A, the initiator 502 [i.e. partner thread] has sent a request 504 to the target 510 via the initiator agent 506, microNetwork 512, and target agent 508. The target core 510 may have stopped servicing requests and thus never issues the corresponding responses. The initiator of those requests may now be stuck waiting on the responses. The initiating agent (such as 506) and target agents (one such as 508) together decide when the request has been outstanding for too long, and to declare the target core broken. In FIG. 5B the initiating agent 506 sends a timeout request 520, and the target agent 508 replies with a timeout acknowledgement 522 [i.e. send a notification of isolating the thread], thus allowing the timeout. At this point, as shown in FIG. 5C the target agent 508 isolates the target core 510 from the rest of the system (at the isolation boundary 540). It does not allow any new requests to be issued to that target (actions shown as 542) and drops any responses 532 arriving from the target 510, so that they cannot contaminate the rest of the system. [i.e. send a notification of isolating the thread]”).
Regarding dependent claim 2, Weber teaches further comprising a register for storing an isolation status for threads (Weber, Fig. 8, Extended error log register. Col. 3, lines 27-49 teaches “When an error occurs, information about that error may be logged away in a queue of registers in the detecting agent … FIG. 8 illustrates one embodiment of the present invention showing how an agent stores away information when an error is discovered. …information about the request as possible (such as the command type 802, address 806, initiator ID 804, and type of error 808 encountered)… Ideally, the system designer can configure as much error logging storage as needed.”), wherein the control circuit is configured to mark the isolated thread as isolated in the register (Weber, Fig. 7, central controller 708, Col. 3, lines 27-34 “…how the error indications from different agents (704-1 through 704-n, and 706-1 through 706-m) are collected centrally 708 and sent to a specific initiator 710. The microNetwork 702 may be configurable to allow the user to decide which errors should be reported from each agent (704-1 through 704-n, and 706-1 through 706-m), and which initiator agent (such as 710) to notify of system errors.” Col. 3, lines 35-50 teaches that central controller/agent write information about the isolated thread into extended error log register of Fig. 8. Col. 3, lines 63-67 “if a resource has been locked by an initiator core, and is never freed, a register shows that a resource is locked and which initiator is responsible for the lock.”).
Regarding dependent claim 3, Weber teaches wherein the register corresponds to a windowed register (Weber, Fig. 8 “Extended error log register” and col. 3, lines 35-38 “error may be logged away in a queue of registers” that are windowed registers or a group of registers).
Regarding dependent claim 4, Weber teaches wherein the register is configured to maintain isolation statuses for all threads (Weber, Fig. 7 and Fig. 8, “Extended error log register”, col. 3, lines 24-49 “Fig. 7 shows how the error indications from different agents”, so isolation status for all cores/threads is maintained in error log register).
Regarding dependent claim 5, Weber teaches further comprising a register for storing partner mappings (Weber, Fig. 3, col. 2, lines 19-35 initiator core and target core form a partner mapping. Fig. 9, Col. 3, lines 50-67 and Col. 4, lines 1-23 teaches agents have registers that store partner mappings that allows functionality of 902, 904, 906).
Regarding dependent claim 6, Weber teaches wherein the control circuit is further configured to identify the partner thread based on partner mappings in the register (Weber, Fig. 7, col. 3, lines 24-34 teaches central controller 708 sent to initiator agent 710 initator and target agent core/thread mappings that are stored in register as described in Fig. 4, col. 3, lines 50-67 and col. 4, lines 1-23 for functionality of 902, 904, 906).
Regarding claim 7, Weber teaches:
A system (Weber, Figs. 2-3 and 7) comprising:
a plurality of processor cores corresponding to threads (Examiner under BRI interprets a processor core as corresponding to a thread. Weber, Fig. 3 and Fig. 7 micronetwork 302, col. 2 lines 19-35 “IP cores (such as 304-1 through 304-n, and 310-1 through 310-m) are classified as either being initiators (such as 304-1 through 304-n) or targets (such as, 310-1 through 310-m)”);
a first register for storing an isolation status for the threads (Weber, Fig. 8, Extended error log register. Col. 3, lines 27-49 teaches “When an error occurs, information about that error may be logged away in a queue of registers in the detecting agent … FIG. 8 illustrates one embodiment of the present invention showing how an agent stores away information when an error is discovered. …information about the request as possible (such as the command type 802, address 806, initiator ID 804, and type of error 808 encountered)… Ideally, the system designer can configure as much error logging storage as needed.” Fig. 7 and Fig. 8, “Extended error log register”, col. 3, lines 24-49 “Fig. 7 shows how the error indications from different agents”, so isolation status for all cores/threads is maintained in error log register);
a second register for storing partner mappings for the threads (Weber, Fig. 3, col. 2, lines 19-35 initiator core and target core form a partner mapping. Fig. 9, Col. 3, lines 50-67 and Col. 4, lines 1-23 teaches agents have registers that store partner mappings that allows functionality of 902, 904, 906); and
a control circuit (Weber, Fig. 7, central controller 708 “how the error indications from different agents (704-1 through 704-n, and 706-1 through 706-m) are collected centrally 708 and sent to a specific initiator 710.”) configured to:
mark a thread as isolated in the first register in response to an error interrupt corresponding to the thread (Weber, Fig. 4, Table 1, hardware isolates error core from rest of system. Fig. 5, col. 2, lines 49-67 teaches “FIG. 5A, the initiator 502 has sent a request 504 to the target 510 via the initiator agent 506, microNetwork 512, and target agent 508. The target core 510 may have stopped servicing requests and thus never issues the corresponding responses. The initiator of those requests may now be stuck waiting on the responses. The initiating agent (such as 506) and target agents (one such as 508) together decide when the request has been outstanding for too long, and to declare the target core broken. In FIG. 5B the initiating agent 506 sends a timeout request 520 [i.e. interrupt], and the target agent 508 replies with a timeout acknowledgement 522, thus allowing the timeout. At this point, as shown in FIG. 5C the target agent 508 isolates the target core 510 from the rest of the system (at the isolation boundary 540). It does not allow any new requests to be issued to that target (actions shown as 542) and drops any responses 532 arriving from the target 510, so that they cannot contaminate the rest of the system.” Fig. 8, Extended error log register. Col. 3, lines 27-49 teaches “When an error occurs, information about that error may be logged away in a queue of registers in the detecting agent … FIG. 8 illustrates one embodiment of the present invention showing how an agent stores away information when an error is discovered. …information about the request as possible (such as the command type 802, address 806, initiator ID 804, and type of error 808 encountered)… Ideally, the system designer can configure as much error logging storage as needed.”);
identify a partner thread of the isolated thread based on the second register (Weber, Fig. 7, col. 3, lines 24-34 teaches central controller 708 sent to initiator agent 710 initator and target agent core/thread mappings that are stored in register as described in Fig. 4, col. 3, lines 50-67 and col. 4, lines 1-23 for functionality of 902, 904, 906); and
send a notification of isolating the thread to the partner thread of the isolated thread (Weber, Fig. 5, col. 2, lines 49-67 teaches “FIG. 5A, the initiator 502 [i.e. partner thread] has sent a request 504 to the target 510 via the initiator agent 506, microNetwork 512, and target agent 508. The target core 510 may have stopped servicing requests and thus never issues the corresponding responses. The initiator of those requests may now be stuck waiting on the responses. The initiating agent (such as 506) and target agents (one such as 508) together decide when the request has been outstanding for too long, and to declare the target core broken. In FIG. 5B the initiating agent 506 sends a timeout request 520, and the target agent 508 replies with a timeout acknowledgement 522 [i.e. send a notification of isolating the thread], thus allowing the timeout. At this point, as shown in FIG. 5C the target agent 508 isolates the target core 510 from the rest of the system (at the isolation boundary 540). It does not allow any new requests to be issued to that target (actions shown as 542) and drops any responses 532 arriving from the target 510, so that they cannot contaminate the rest of the system. [i.e. send a notification of isolating the thread]”).
Regarding dependent claim 8, Weber teaches wherein an operating system of the system establishes the partner mappings on a boot of the system (Weber, col 4, lines 15-25 teaches system software performs agent/core reset that reboots faulty initiator cores and target cores and these are placed into partner mappings. Col. 6, lines 46-60 teaches that the computer system software is an operating system or executing within or part of the operating system).
Regarding dependent claim 9, Weber teaches wherein the partner thread is configured to report the isolated thread to the operating system (Weber, col. 3, lines 24-29 “Once an error has been detected, and the agent has isolated the error core from the rest of the system (if needed), system software may be notified of the problem to complete the error handling.” Col. 6, lines 46-60 teaches that the computer system software is an operating system or executing within or part of the operating system).
Regarding dependent claim 10, Weber teaches wherein the control circuit is configured to decline execution-related requests to the isolated thread (Weber, Fig. 9, block 904 Agent reject control “Software write of a register causes the agent to reject new requests”, see col. 4, lines 6-14).
Regarding dependent claim 11, Weber teaches wherein the first register is configured to maintain isolation statuses for all threads (Weber, Fig. 7 and Fig. 8, “Extended error log register”, col. 3, lines 24-49 “Fig. 7 shows how the error indications from different agents”, so isolation status for all cores/threads is maintained in error log register).
Regarding dependent claim 12, Weber teaches wherein the partner thread is configured to identify the isolation status from the first register in response to the notification (Weber, Fig. 5, col. 2, lines 49-67 teaches “FIG. 5A, the initiator 502 [i.e. partner thread] has sent a request 504 to the target 510 via the initiator agent 506, microNetwork 512, and target agent 508. The target core 510 may have stopped servicing requests and thus never issues the corresponding responses. The initiator of those requests may now be stuck waiting on the responses. The initiating agent (such as 506) and target agents (one such as 508) together decide when the request has been outstanding for too long, and to declare the target core broken. In FIG. 5B the initiating agent 506 sends a timeout request 520, and the target agent 508 replies with a timeout acknowledgement 522 [i.e. send a notification of isolating the thread], thus allowing the timeout. At this point, as shown in FIG. 5C the target agent 508 isolates the target core 510 from the rest of the system (at the isolation boundary 540). It does not allow any new requests to be issued to that target (actions shown as 542) and drops any responses 532 arriving from the target 510, so that they cannot contaminate the rest of the system. [i.e. send a notification of isolating the thread]” See also Fig. 8, col. 3, lines 35-50).
Regarding dependent claim 13, Weber teaches wherein the partner thread is further configured to identify the isolation status from the first register based on identifying a partner mapping in the second register (Weber, Fig. 7, col. 3, lines 24-34 teaches central controller 708 sent to initiator agent 710 initator and target agent core/thread mappings that are stored in register as described in Fig. 4, col. 3, lines 50-67 and col. 4, lines 1-23 for functionality of 902, 904, 906).
Regarding dependent claim 14, Weber teaches wherein the first register corresponds to a windowed register (Weber, Fig. 8 “Extended error log register” and col. 3, lines 35-38 “error may be logged away in a queue of registers” that are windowed registers or a group of registers).
Regarding claim 15, Weber teaches:
A method comprising:
receiving an error interrupt for a thread corresponding to a processor core (Examiner under BRI interprets a thread as corresponding to a processor core. Weber, Fig. 4, Table 1, hardware isolates error core from rest of system. Fig. 5, col. 2, lines 49-67 teaches “FIG. 5A, the initiator 502 has sent a request 504 to the target 510 via the initiator agent 506, microNetwork 512, and target agent 508. The target core 510 may have stopped servicing requests and thus never issues the corresponding responses. The initiator of those requests may now be stuck waiting on the responses. The initiating agent (such as 506) and target agents (one such as 508) together decide when the request has been outstanding for too long, and to declare the target core broken. In FIG. 5B the initiating agent 506 sends a timeout request 520 [i.e. interrupt], and the target agent 508 replies with a timeout acknowledgement 522, thus allowing the timeout. At this point, as shown in FIG. 5C the target agent 508 isolates the target core 510 from the rest of the system (at the isolation boundary 540). It does not allow any new requests to be issued to that target (actions shown as 542) and drops any responses 532 arriving from the target 510, so that they cannot contaminate the rest of the system.”);
marking the thread as isolated in response to the error interrupt (Weber, Fig. 4, Table 1, hardware isolates error core from rest of system. Fig. 5, col. 2, lines 49-67 teaches “FIG. 5A, the initiator 502 has sent a request 504 to the target 510 via the initiator agent 506, microNetwork 512, and target agent 508. The target core 510 may have stopped servicing requests and thus never issues the corresponding responses. The initiator of those requests may now be stuck waiting on the responses. The initiating agent (such as 506) and target agents (one such as 508) together decide when the request has been outstanding for too long, and to declare the target core broken. In FIG. 5B the initiating agent 506 sends a timeout request 520 [i.e. interrupt], and the target agent 508 replies with a timeout acknowledgement 522, thus allowing the timeout. At this point, as shown in FIG. 5C the target agent 508 isolates the target core 510 from the rest of the system (at the isolation boundary 540). It does not allow any new requests to be issued to that target (actions shown as 542) and drops any responses 532 arriving from the target 510, so that they cannot contaminate the rest of the system.”);
notifying a partner thread of the isolated thread (Weber, Fig. 5, col. 2, lines 49-67 teaches “FIG. 5A, the initiator 502 [i.e. partner thread] has sent a request 504 to the target 510 via the initiator agent 506, microNetwork 512, and target agent 508. The target core 510 may have stopped servicing requests and thus never issues the corresponding responses. The initiator of those requests may now be stuck waiting on the responses. The initiating agent (such as 506) and target agents (one such as 508) together decide when the request has been outstanding for too long, and to declare the target core broken. In FIG. 5B the initiating agent 506 sends a timeout request 520, and the target agent 508 replies with a timeout acknowledgement 522 [i.e. notifying a partner thread], thus allowing the timeout. At this point, as shown in FIG. 5C the target agent 508 isolates the target core 510 from the rest of the system (at the isolation boundary 540). It does not allow any new requests to be issued to that target (actions shown as 542) and drops any responses 532 arriving from the target 510, so that they cannot contaminate the rest of the system. [i.e. notifying a partner thread]”); and
preventing the isolated thread from performing a context switch (Weber, Fig. 9, block 904 Agent reject control “Software write of a register causes the agent to reject new requests”, see col. 4, lines 6-14)).
Regarding dependent claim 16, Weber teaches further comprising reporting an isolation status of the isolated thread (Weber, Fig. 7, col. 3, lines 24-34 teaches central controller 708 sent to initiator agent 710 initator and target agent core/thread mappings that are stored in register as described in Fig. 4, col. 3, lines 50-67 and col. 4, lines 1-23 for functionality of 902 “Access to Agent Status”, “Makes current status of agent, such as resources locked and requests in progress, available in software readable registers”).
Regarding dependent claim 17, Weber teaches wherein marking the thread as isolated further comprises marking the thread as isolated in a register configured to store isolation statuses of threads (Weber, Fig. 8, Extended error log register. Col. 3, lines 27-49 teaches “When an error occurs, information about that error may be logged away in a queue of registers in the detecting agent … FIG. 8 illustrates one embodiment of the present invention showing how an agent stores away information when an error is discovered. …information about the request as possible (such as the command type 802, address 806, initiator ID 804, and type of error 808 encountered)… Ideally, the system designer can configure as much error logging storage as needed.”).
Regarding dependent claim 18, Weber teaches wherein reporting the isolation status of the isolated thread further comprises identifying, by the partner thread, the isolation status from the register (Weber, Fig. 8, Extended error log register. Col. 3, lines 27-49 teaches “When an error occurs, information about that error may be logged away in a queue of registers in the detecting agent … FIG. 8 illustrates one embodiment of the present invention showing how an agent stores away information when an error is discovered. …information about the request as possible (such as the command type 802, address 806, initiator ID 804, and type of error 808 encountered)… Ideally, the system designer can configure as much error logging storage as needed.” See Fig. 8, error code 808 and Fig. 9, block 902).
Regarding dependent claim 19, Weber teaches wherein notifying the partner thread further comprises identifying the partner thread of the isolated thread from a register configured to store partner mappings for threads (Weber, Fig. 3, col. 2, lines 19-35 initiator core and target core form a partner mapping. Fig. 9, Col. 3, lines 50-67 and Col. 4, lines 1-23 teaches agents have registers that store partner mappings that allows functionality of 902, 904, 906).
Regarding dependent claim 20, Weber teaches wherein reporting the isolation status further comprises identifying, by the partner thread, the isolated thread based on the partner mappings in the register (Weber, Fig. 7, col. 3, lines 24-34 teaches central controller 708 sent to initiator agent 710 initator and target agent core/thread mappings that are stored in register as described in Fig. 4, col. 3, lines 50-67 and col. 4, lines 1-23 for functionality of 902, 904, 906).
Conclusion
The prior art made of record in Form PTO-892 and not relied upon is considered pertinent to Applicants’ disclosure. Applicants are required under 37 C.F.R. § 1.111(c) to consider these references fully when responding to this action.
Raj et al. (U.S. Patent Publn. No. 2013/0007507 A1) teaches a hardware processor including a plurality of machine state registers (MSRs). At least one of the MSRs includes an erroring logical processing (ELP) bit which when set, indicates that a particular thread executing on the hardware processor caused an error.
It is noted that any citation to specific pages, columns, lines, or figures in the prior art references and any interpretation of the references should not be considered to be limiting in any way. A reference is relevant for all it contains and may be relied upon for all that it would have reasonably suggested to one having ordinary skill in the art. In re Heck, 699 F.2d 1331, 1332-33, 216 U.S.P.Q. 1038, 1039 (Fed. Cir. 1983) (quoting In re Lemelson, 397 F.2d 1006, 1009, 158 U.S.P.Q. 275, 277 (C.C.P.A. 1968)).
In the interests of compact prosecution, Applicants are invited to contact the examiner via electronic media pursuant to USPTO policy outlined MPEP § 502.03. All electronic communication must be authorized in writing. Applicants may wish to file an Internet Communications Authorization Form PTO/SB/439. Applicants may wish to request an interview using the Interview Practice website: http://www.uspto.gov/patent/laws-and-regulations/interview-practice.
Applicants are reminded Internet e-mail may not be used for communication for matters under 35 U.S.C. § 132 or which otherwise require a signature. A reply to an Office action may NOT be communicated by Applicants to the USPTO via Internet e-mail. If such a reply is submitted by Applicants via Internet e-mail, a paper copy will be placed in the appropriate patent application file with an indication that the reply is NOT ENTERED. See MPEP § 502.03(II).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to INDRANIL CHOWDHURY whose telephone number is (571)272-0446. The examiner can normally be reached on M-Fri 9:30-7:00 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 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, Ashish Thomas can be reached on 571-272-0631. 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.
/INDRANIL CHOWDHURY/Examiner, Art Unit 2114
/MARK D FEATHERSTONE/Supervisory Patent Examiner, Art Unit 2111