DETAILED ACTION
Notice of Pre-AIA or AIA Status
1. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
2. Claims 1–17 are presented for examination in a non-provisional application filed on 8/14/2023. Claims 18–20 are cancelled.
Priority
3. Acknowledgment is made of applicant’s claim for foreign priority based on an application filed in CHINA (CN) on Aug. 12, 2022 (202210969365.X).
Receipt is acknowledged of certified copies of papers required by 37 CFR 1.55.
Drawings
4. The drawings were received on 8/14/2023 (in the filings). These drawings are acceptable.
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.
5. Claims 5–7 and 9–10 are rejected under 35 U.S.C. 112(b) as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor regards as the invention.
a. Specifically, the following term(s) and/or phrase(s) in the claim language is/are indefinite.
i. As to claims 5–7 and 9–10, the term “DDR” renders the claim indefinite.
The term “DDR” is not spelled out in or defined by the claims, and 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.
To proceed in examination, the term “DDR” is interpreted to be a “Double Data Rate” memory location or address.
b. Appropriate corrections are therefore required.
Examiner’s Remarks
6. Examiner refers to and explicitly cites particular pages, sections, figures, paragraphs or columns and lines in the references as applied to Applicant’s claims to the extent practicable to streamline prosecution.
Although the cited portions of the references are representative of the best teachings in the art and are applied to meet the specific limitations of the claims, other uncited but related teachings of the references may be equally applicable as well. It is respectfully requested that, in preparing responses to the rejections, the Applicant fully considers not only the cited portions of the references, but also the references in their entirety, as potentially teaching, suggesting or rendering obvious all or one or more aspects of the claimed invention.
Abbreviations
7. Where appropriate, the following abbreviations will be used when referencing Applicant’s submissions and specific teachings of the reference(s):
i. figure / figures: Fig. / Figs.
ii. column / columns: Col. / Cols.
iii. page / pages: p. / pp.
References Cited
8. (A) Kumabe, US 2020/0210222 A1 (“Kumabe”).
(B) McKelvie et al., US 9,767,015 B1 (“McKelvie”).
(C) Tosa et al., US 2015/0199514 A1 (“Tosa”).
(D) Rothman et al., US 2006/0277546 A1 (“Rothman”).
(E) PikeOS – Wikipedia, edited version dated 04/28/2022 (hereinafter “PikeOS”)
Notice re prior art available under both pre-AIA and AIA
9. 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.
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 of this title, 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.
A.
10. Claims 1, 8, 11, and 15–16 are rejected under 35 U.S.C. 103 as being unpatentable over (A) Kumabe in view of (B) McKelvie.
See “References Cited” section, above, for full citations of references.
11. Regarding claim 1, (A) Kumabe teaches/suggests the invention substantially as claimed, including:
“A method for processing inter-core communication, applied to a VIRTUAL MACHINE MONITOR, wherein the virtual machine monitor runs between a physical server and an operating system, and the method comprises:
(¶ 11: The hypervisor operates directly on the hardware and controls allocation of computational resources to the guest OS and access to the hardware (so-called peripheral) by the guest OS;
¶ 14: software for controlling an access from the guest OS to the hardware without distinguishing between a virtualization application for providing a virtualization system of a host-type system and a hypervisor for providing a hypervisor-type virtualization system will be referred to as a hypervisor);
“acquiring inter-core communication data sent by a target operating system”
(Fig. 4 and ¶ 49: As shown in FIG. 4, the hardware control core 11x includes an inter-core communication unit Fl and a device driver unit F2. The inter-core communication unit Fl includes a read unit F11 and a storage processing unit F12 as finer functional blocks. The inter-core communication unit F1 is a configuration for the hardware control core 11x to communicate with each of the VM cores 11 (for example, the VM core 11a;
¶ 50: A communication between the hardware control core 11x and the VM core 11a is realized through the shared memory unit 12;
¶ 60: The inter-core communication unit G1 is configured such that the VM core 11a BI-DIRECTIONALLY COMMUNICATES with the hardware control core 11x;
¶ 70: the data for the virtual machine output from the hardware 13 is provided to the VM core 11 to be output by the device driver unit F2 and the inter-core communication unit F1 through the shared memory unit;
¶ 29: The shared memory unit 12 is realized with the use of a random access memory (hereinafter, RAM: Random Access Memory) or the like. The shared memory unit 12 is connected to each of the cores 11;
¶ 75: Incidentally, in a related virtualization system using the hypervisor, as a configuration for sharing one hardware 13 by multiple virtual machines, a configuration may be conceivable in which the virtual machines and the hypervisor are mutually communicably connected to each other by a virtual communication pipe in conformity with a predetermined communication standard (hereinafter referred to as an assumed configuration).
The hypervisor in the assumed configuration controls the hardware based on the data received from the virtual machine, and performs processing for providing the data received from the hardware to the virtual machine;
¶ 76: in the assumed configuration, when the virtual machine communicates with the hardware, there is a need to execute processing (hereinafter referred to as bridge processing) for converting data/signals exchanged between the virtual machine and the hardware once into a format according to the communication standard between the virtual machine and the hypervisor;
¶ 77: For example, when the virtual machine outputs data for a certain hardware, the virtual machine converts the data into a format in accordance with a communication standard between the guest OS and the hypervisor once and outputs the converted data to the hypervisor. When the hypervisor outputs the data acquired from a certain hardware to the virtual machine, the hypervisor once converts the data into a format in accordance with the communication standard between the guest OS and the hypervisor and outputs the converted data);
“writing a communication data content in the inter-core communication data into a preset memory, and triggering a target CPU core to read the communication data content from the preset memory”
(see Fig. 4 and ¶ 49, ¶ 50, ¶ 60, ¶ 70, and ¶ 29, as applied above, teaching performing inter-core communications using shared memory;
¶ 75 to ¶ 77, as applied above, teaching bridge processing and virtual machines and the hypervisor are mutually communicably connected to each other by a virtual communication pipe;
¶ 60: The read unit G11 is configured to read the stored data with reference to the uplink memory M2 based on the reception of the interrupt signal output from the storage processing unit F12 of the hardware control core 11x. The read unit G11 outputs the data read out from the uplink memory M2 TO the processing execution unit G2;
¶ 61: stores the data input FROM the processing execution unit G2 as it is in the downlink memory M1, and outputs an interrupt signal to the hardware control core 11x. The hardware control core 11x (more specifically, the read unit F11) reads the stored data with reference to the downlink memory M1 based on the reception of the interrupt signal output)
feeding back the … data to the target operating system”
(see Fig. 4 and ¶ 49, ¶ 50, ¶ 60, ¶ 70, and ¶ 29, as applied above, teaching performing inter-core communications using shared memory;
¶ 75 to ¶ 77, as applied above, teaching bridge processing and virtual machines and the hypervisor are mutually communicably connected to each other by a virtual communication pipe;
¶ 60, as applied above, teaching reading the stored data based on the reception of the interrupt signal output from the storage processing (uplink);
¶ 61: as applied above, teaching storing the data input and outputting an interrupt signal to the hardware control core and the hardware control core reads the stored data with based on the reception of the interrupt signal output (downlink)).
The Examiner notes that it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to further modify and implement Kumabe’s invention using the related/alternate embodiment in which the virtual machines and the hypervisor are mutually communicably connected to each other by a virtual communication pipe in conformity with a predetermined communication standard. The motivation or advantage to do so to provide for bridge processing and conversion of data communications/exchanges between the virtual machine and the hardware across different communication protocols or formats.
Kumabe do not teach acquiring communication feedback data, wherein the communication feedback data is feedback data corresponding to the communication data content and sent by the target CPU core.”
(B) McKelvie, in the context of Kumabe’s teachings, however teaches or suggest:
“acquiring communication feedback data, wherein the communication feedback data is feedback data corresponding to the communication data content and sent by the target CPU core”
(Col. 24, lines 49–55: a shared-memory based inter-process communication protocol (such as any of various types of store-and-forward protocols) may be implemented, in accordance with which a source or sender program is expected to write message contents directly into the system memory of the receiver;
Col. 6, lines 49–55: Message transfers are implemented by the sender writing to a specified address at the receiver’s memory, and the receiver reading the data from that address. According to at least some protocols, the sender may receive an acknowledgement of the completion of the write;
Col. 19, lines 37–44: as soon as process 812A completes writing a message directed at process 812B into buffer 824B (with the successful return code from the write serving as an acknowledgement, or with an explicit write acknowledgement being received from host 802B).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of (B) McKelvie with those of (A) Kumabe to provide write completion acknowledgement to the sender (target OS). The motivation or advantage to do so is to enhance the integrity and security of the shared memory/communication protocol.
12. Regarding claim 8 (independent), Kumabe teaches/suggests:
“A method for processing inter-core communication, applied to a CPU CORE, comprising:
reading a communication data content from a preset memory in response to a triggering operation of a virtual machine monitor, wherein the communication data content is a communication data content written into the preset memory by the virtual machine monitor after inter-core communication data sent by a target operating system is acquired by the virtual machine monitor”
(Kumabe, see Fig. 4 and ¶ 49, ¶ 50, ¶ 60, ¶ 70, and ¶ 29, as applied in rejecting claim 1 above, teaching performing inter-core communications using shared memory;
¶ 75 to ¶ 77, as applied in rejecting claim 1 above, teaching bridge processing and virtual machines and the hypervisor are mutually communicably connected to each other by a virtual communication pipe;
¶ 61: as applied in rejecting claim 1 above, teaching stores the data input and outputs an interrupt signal to the hardware control core and the hardware control core reads the stored data with based on the reception of the interrupt signal output (downlink)).
“writing the [[communication feedback]] data into the preset memory, and triggering the virtual machine monitor to acquire the … data, so as to make the virtual machine monitor feed back the … data to the target operating system”
(Kumabe, see Fig. 4 and ¶ 49, ¶ 50, ¶ 60, ¶ 70, and ¶ 29, as applied in rejecting claim 1 above, teaching performing inter-core communications using shared memory;
¶ 75 to ¶ 77, as applied in rejecting claim 1 above, teaching bridge processing and virtual machines and the hypervisor are mutually communicably connected to each other by a virtual communication pipe;
¶ 60, as applied above, teaching reading the stored data based on the reception of the interrupt signal output from the storage processing (uplink);
¶ 61: as applied above, teaching storing the data input and outputting an interrupt signal to the hardware control core and the hardware control core reads the stored data with based on the reception of the interrupt signal output (downlink));
Kumabe do not teach “generating communication feedback data corresponding to the communication data content.”
(B) McKelvie, in the context of Kumabe’s teachings, however teaches or suggest:
“generating communication feedback data corresponding to the communication data content”
(McKelvie, Col. 24, lines 49–55: a shared-memory based inter-process communication protocol (such as any of various types of store-and-forward protocols) may be implemented, in accordance with which a source or sender program is expected to write message contents directly into the system memory of the receiver;
Col. 6, lines 49–55: Message transfers are implemented by the sender writing to a specified address at the receiver’s memory, and the receiver reading the data from that address. According to at least some protocols, the sender may receive an acknowledgement of the completion of the write;
Col. 19, lines 37–44: as soon as process 812A completes writing a message directed at process 812B into buffer 824B (with the successful return code from the write serving as an acknowledgement, or with an explicit write acknowledgement being received from host 802B);
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to further modify and implement Kumabe’s invention using the related/alternate embodiment, and to combine the teachings of (B) McKelvie with those of (A) Kumabe for reasons noted and applied in rejecting claim 1 above.
13. Regarding claim 11 (independent), Kumabe teaches/suggests:
“A method for processing inter-core communication, applied to an OPERATING SYSTEM, wherein the operating system runs based on a physical server resource allocated by a virtual machine monitor, and the method comprises”
(Kumabe, ¶ 11: The hypervisor operates directly on the hardware and controls allocation of computational resources to the guest OS and access to the hardware (so-called peripheral) by the guest OS;
¶ 14: software for controlling an access from the guest OS to the hardware without distinguishing between a virtualization application for providing a virtualization system of a host-type system and a hypervisor for providing a hypervisor-type virtualization system will be referred to as a hypervisor);
“sending inter-core communication data to the virtual machine monitor, so as to make the virtual machine monitor write a communication data content in the inter-core communication data into a preset memory, trigger a target CPU core to read the communication data content from the preset memory …”
(Kumabe, see Fig. 4 and ¶ 49, ¶ 50, ¶ 60, ¶ 70, and ¶ 29, as applied in rejecting claim 1 above, teaching performing inter-core communications using shared memory;
¶ 75 to ¶ 77, as applied in rejecting claim 1 above, teaching bridge processing and virtual machines and the hypervisor are mutually communicably connected to each other by a virtual communication pipe;
¶ 61: as applied in rejecting claim 1 above, teaching storing the data input and outputting an interrupt signal to the hardware control core and the hardware control core reads the stored data with based on the reception of the interrupt signal output (downlink));
“acquiring [[the communication feedback]] data acquired by the virtual machine monitor”
(Kumabe, see Fig. 4 and ¶ 49, ¶ 50, ¶ 60, ¶ 70, and ¶ 29, as applied in rejecting claim 1 above, teaching performing inter-core communications using shared memory;
¶ 75 to ¶ 77, as applied in rejecting claim 1 above, teaching bridge processing and virtual machines and the hypervisor are mutually communicably connected to each other by a virtual communication pipe;
¶ 60, as applied in rejecting claim 1 above, teaching reading the stored data based on the reception of the interrupt signal output from the storage processing (uplink)).
Kumabe do not teach “acquire communication feedback data, wherein the communication feedback data is feedback data corresponding to the communication data content and sent by the target CPU core.”
(B) McKelvie, in the context of Kumabe’s teachings, however teaches or suggest:
“acquire communication feedback data, wherein the communication feedback data is feedback data corresponding to the communication data content and sent by the target CPU core”
(McKelvie, Col. 24, lines 49–55: a shared-memory based inter-process communication protocol (such as any of various types of store-and-forward protocols) may be implemented, in accordance with which a source or sender program is expected to write message contents directly into the system memory of the receiver;
Col. 6, lines 49–55: Message transfers are implemented by the sender writing to a specified address at the receiver’s memory, and the receiver reading the data from that address. According to at least some protocols, the sender may receive an acknowledgement of the completion of the write;
Col. 19, lines 37–44: as soon as process 812A completes writing a message directed at process 812B into buffer 824B (with the successful return code from the write serving as an acknowledgement, or with an explicit write acknowledgement being received from host 802B);
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to further modify and implement Kumabe’s invention using the related/alternate embodiment, and to combine the teachings of (B) McKelvie with those of (A) Kumabe for reasons noted and applied in rejecting claim 1 above.
14. Regarding claim 15 (independent), it is a system claim reciting similar limitations of commensurate scope as the method of claim 1 (virtual machine monitor), claim 8 (CPU core) and claim 11 (operating system) in combination . Therefore, it is rejected on the same basis as claims 1, 8, and 11 above, including the following:
Kumabe and McKelvie teach/suggest:
“A computer system, comprising:
an operating system, a virtual machine monitor, and a physical server,
wherein the virtual machine monitor is configured to run between the operating system and the physical server, and allocate a hardware resource of the physical server to the operating system, and the operating system is configured to run based on a physical server resource allocated by the virtual machine monitor”
(Kumabe, ¶ 11: The hypervisor operates directly on the hardware and controls allocation of computational resources to the guest OS and access to the hardware (so-called peripheral) by the guest OS;
¶ 14: software for controlling an access from the guest OS to the hardware without distinguishing between a virtualization application for providing a virtualization system of a host-type system and a hypervisor for providing a hypervisor-type virtualization system will be referred to as a hypervisor;
Fig. 1 and ¶ 26: a processor having four cores 11).
“the operating system is further configured to send inter-core communication data to the virtual machine monitor, and acquire communication feedback data acquired by the virtual machine monitor”
(see teachings of Kumabe and McKelvie, as applied in rejecting claim 11 above, directed to the operating system).
“the virtual machine monitor is further configured to write a communication data content in the inter-core communication data sent by the operating system into a preset memory, trigger a target CPU core in the physical server to read the communication data content from the preset memory, acquire the communication feedback data, and feed back the communication feedback data to the operating system, wherein the communication feedback data is feedback data corresponding to the communication data content and sent by the target CPU core”
(see teachings of Kumabe and McKelvie, as applied in rejecting claim 1 above, directed to the virtual machine monitor).
“the target CPU core in the physical server is configured to read the communication data content from the preset memory in response to a triggering operation of the virtual machine monitor, generate the communication feedback data corresponding to the communication data content, write the communication feedback data into the preset memory, and trigger the virtual machine monitor to acquire the communication feedback data”
(see teachings of Kumabe and McKelvie, as applied in rejecting claim 8 above, directed to the CPU core).
15. Regarding claim 16, Kumabe teaches or suggests:
“wherein the operating system comprises at least one guest operating system, and the virtual machine monitor provides a service interface for each guest operating system, and allocates different physical server hardware resources to each guest operating system; and
the physical server comprises a plurality of CPU cores”
(¶ 11: The hypervisor operates directly on the hardware and controls allocation of computational resources to the guest OS and access to the hardware (so-called peripheral) by the guest OS;
¶ 14: software for controlling an access from the guest OS to the hardware without distinguishing between a virtualization application for providing a virtualization system of a host-type system and a hypervisor for providing a hypervisor-type virtualization system will be referred to as a hypervisor;
Fig. 1 and ¶ 26: a processor having four cores 11).
B.
16. Claims 2, 4, 12, and 14 are rejected under 35 U.S.C. 103 as being unpatentable over (A) Kumabe in view of (B) McKelvie, as applied to claims 1 and 11 above, and further in view of (C) Tosa.
17. Regarding claim 2, Kumabe and McKelvie do not teach: .
“reading the inter-core communication data to be written into a preset RAM by the target operating system, when a read/write error signal is collected, wherein the preset RAM is a RAM that is not readable or writable by the target operating system, and when the inter-core communication data is written into the preset RAM by the target operating system, the preset RAM triggers generation of the read/write error signal.”
(C) Tosa, in the context of Kumabe and McKelvie’s teachings, however teaches or suggests implementing:
“wherein the acquiring inter-core communication data sent by a target operating system comprises:
reading the inter-core communication data to be written into a preset RAM by the target operating system, when a read/write error signal is collected”
(¶ 38: TO COMMUNICATE DATA FROM WITHIN GUEST VM 32 TO HYPERVISOR 30 (e.g. as part of carrying out step 306), some embodiments may use an inter-process communication method known in the art of virtualization. In one example, security application 40 may write the respective data to a pre-determined section of memory, and issue a particular function call (e.g., VMCALL on Intel platforms) which triggers a processor event ( e.g., VMExit on Intel platforms) configured to suspend execution of guest VM 32 and transfer control of processor 12 to hypervisor 30. Hypervisor 30 may include a handler routine configured to intercept the processor event, thus receiving notification from security application 40 that data is being transmitted from within guest VM 32. In response, hypervisor 30 may read the respective data from the pre-determined memory section shared with application 40, and return execution to guest VM 32;
¶ 43: hypervisor may configure processor to generate a processor event, herein termed virtualization exception, in response to detecting an attempt by software executing within guest VM 32 to violate a memory access permission … Processor exceptions are anomalous or exceptional events changing the normal flow of program execution and requiring special processing);
“wherein the preset RAM is a RAM that is not readable or writable by the target operating system, and when the inter-core communication data is written into the preset RAM by the target operating system, the preset RAM triggers generation of the read/write error signal”
(¶ 43: hypervisor may configure processor to generate a processor event, herein termed virtualization exception, in response to detecting an attempt by software executing within guest VM 32 to violate a memory access permission … Processor exceptions are anomalous or exceptional events changing the normal flow of program execution and requiring special processing;
¶ 49: Some hardware configurations allow hypervisor 30 to selectively control access to data stored in memory, for instance, by setting read, write, and/or execute access rights to a section of memory. Hypervisor 30 may thus select which software object may access data stored within the respective memory section, and/or may indicate which operations are allowed with the respective data, e.g., read, write, execute. An attempt by a software object executing within guest VM 32 to perform an illegal operation such as writing data to a section marked as non-writable, or executing code from a section marked as non-executable, may be interpreted as a memory access violation, and may trigger a virtualization exception;
¶ 45: hypervisor 30 may mark the respective memory section as non-readable (read-protection). In such embodiments, a virtualization exception may be triggered by an attempt to fetch an executable instruction from a read-protected section of memory).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of (C) Tosa with those of (A) Kumabe and (B) McKelvie to provide hypervisor control over share memory access rights. The motivation or advantage to do so is to protect unintended, unauthorized and/or malicious access of data thereby improving data security.
18. Regarding claim 4, Kumabe and McKelvie teach or suggest:
“wherein the feeding back the communication feedback data to the target operating system comprises:
writing the communication feedback data into the preset RAM; and
triggering the target operating system to read the communication feedback data from the preset RAM”
(Kumabe, Fig. 4 and ¶ 49, ¶ 50, ¶ 60, ¶ 70, and ¶ 29, as applied in rejecting claim 1 above, teaching performing inter-core communications using shared memory;
¶ 75 to ¶ 77, as applied in rejecting claim 1 above, teaching bridge processing and virtual machines and the hypervisor are mutually communicably connected to each other by a virtual communication pipe;
¶ 61: as applied in rejecting claim 1 above, teaching storing the data input and outputting an interrupt signal to the hardware control core and the hardware control core reads the stored data with based on the reception of the interrupt signal output (downlink);
¶ 60, as applied in rejecting claim 1 above, teaching reading the stored data based on the reception of the interrupt signal output from the storage processing (uplink);
McKelvie, Col. 24, lines 49–55; Col. 6, lines 49–55; Col. 19, lines 37–44, teaching sender receiving an acknowledgement of the completion of the write).
19. Regarding claim 12, Kumabe and Tosa teach or suggest:
“wherein the sending inter-core communication data to the virtual machine monitor comprises:
writing the inter-core communication data into a preset RAM, releasing a CPU, and interrupting a program currently being executed, wherein the preset RAM is a RAM that is not readable or writable by the operating system”
(Kumabe, see Fig. 4 and ¶ 49, ¶ 50, ¶ 60, ¶ 70, and ¶ 29, as applied in rejecting claim 1 above, teaching performing inter-core communications using shared memory;
¶ 75 to ¶ 77, as applied in rejecting claim 1 above, teaching bridge processing and virtual machines and the hypervisor are mutually communicably connected to each other by a virtual communication pipe;
¶ 61: as applied in rejecting claim 1 above, teaching storing the data input and outputting an interrupt signal to the hardware control core and the hardware control core reads the stored data with based on the reception of the interrupt signal output (downlink);
Tosa, ¶ 38: TO COMMUNICATE DATA FROM WITHIN GUEST VM 32 TO HYPERVISOR 30 (e.g. as part of carrying out step 306), some embodiments may use an inter-process communication method known in the art of virtualization. In one example, security application 40 may write the respective data to a pre-determined section of memory, and issue a particular function call (e.g., VMCALL on Intel platforms) which triggers a processor event ( e.g., VMExit on Intel platforms) configured to suspend execution of guest VM 32 and transfer control of processor 12 to hypervisor 30. Hypervisor 30 may include a handler routine configured to intercept the processor event, thus receiving notification from security application 40 that data is being transmitted from within guest VM 32. In response, hypervisor 30 may read the respective data from the pre-determined memory section shared with application 40, and return execution to guest VM 32;
¶ 43: hypervisor may configure processor to generate a processor event, herein termed virtualization exception, in response to detecting an attempt by software executing within guest VM 32 to violate a memory access permission … Processor exceptions are anomalous or exceptional events changing the normal flow of program execution and requiring special processing;
¶ 43: an exception is handled by halting execution of the instruction triggering the exception, saving the current processor state to a predefined location and switching execution to a specific subroutine known as an exception handler. In some embodiments, virtualization exceptions suspend the execution of the current instruction (the instruction executing within guest VM 32;
¶ 49: Some hardware configurations allow hypervisor 30 to selectively control access to data stored in memory, for instance, by setting read, write, and/or execute access rights to a section of memory. Hypervisor 30 may thus select which software object may access data stored within the respective memory section, and/or may indicate which operations are allowed with the respective data, e.g., read, write, execute. An attempt by a software object executing within guest VM 32 to perform an illegal operation such as writing data to a section marked as non-writable, or executing code from a section marked as non-executable, may be interpreted as a memory access violation, and may trigger a virtualization exception;
¶ 45: hypervisor 30 may mark the respective memory section as non-readable (read-protection). In such embodiments, a virtualization exception may be triggered by an attempt to fetch an executable instruction from a read-protected section of memory).
20. Regarding claim 14, Kumabe, McKelvie, and Tosa teach or suggest:
“wherein after acquiring the communication feedback data, the virtual machine monitor writes the communication feedback data into a preset RAM, and the preset RAM is a RAM that is not readable or writable by the operating system; and
the acquiring the communication feedback data acquired by the virtual machine monitor comprises:
reading the communication feedback data from the preset RAM”
(Kumabe, see Fig. 4 and ¶ 49, ¶ 50, ¶ 60, ¶ 70, and ¶ 29, as applied in rejecting claim 1 above, teaching performing inter-core communications using shared memory;
¶ 75 to ¶ 77, as applied in rejecting claim 1 above, teaching bridge processing and virtual machines and the hypervisor are mutually communicably connected to each other by a virtual communication pipe;
¶ 61: as applied in rejecting claim 1 above, teaching storing the data input and outputting an interrupt signal to the hardware control core and the hardware control core reads the stored data with based on the reception of the interrupt signal output (downlink);
¶ 60, as applied in rejecting claim 1 above, teaching reading the stored data based on the reception of the interrupt signal output from the storage processing (uplink);
McKelvie, Col. 24, lines 49–55; Col. 6, lines 49–55; Col. 19, lines 37–44, teaching sender receiving an acknowledgement of the completion of the write).
Tosa, ¶ 43: hypervisor may configure processor to generate a processor event, herein termed virtualization exception, in response to detecting an attempt by software executing within guest VM 32 to violate a memory access permission … Processor exceptions are anomalous or exceptional events changing the normal flow of program execution and requiring special processing;
¶ 49: Some hardware configurations allow hypervisor 30 to selectively control access to data stored in memory, for instance, by setting read, write, and/or execute access rights to a section of memory. Hypervisor 30 may thus select which software object may access data stored within the respective memory section, and/or may indicate which operations are allowed with the respective data, e.g., read, write, execute. An attempt by a software object executing within guest VM 32 to perform an illegal operation such as writing data to a section marked as non-writable, or executing code from a section marked as non-executable, may be interpreted as a memory access violation, and may trigger a virtualization exception;
¶ 45: hypervisor 30 may mark the respective memory section as non-readable (read-protection). In such embodiments, a virtualization exception may be triggered by an attempt to fetch an executable instruction from a read-protected section of memory).
C.
21. Claims 3 and 13 are rejected under 35 U.S.C. 103 as being unpatentable over (A) Kumabe in view of (B) McKelvie and (C) Tosa, as applied to claims 2 and 12 above, and further in view of (D) Rothman.
22. Regarding claim 3, Tosa teaches or suggests:
“when the read/write error signal is collected, the method further comprises: acquiring and storing context information of an execution program of the target operating system”
(¶ 43: an exception is handled by halting execution of the instruction triggering the exception, saving the current processor state to a predefined location and switching execution to a specific subroutine known as an exception handler. In some embodiments, virtualization exceptions suspend the execution of the current instruction (the instruction executing within guest VM 32;
¶ 32: receive for execution processor instructions forming part of software such as operating system 34 and applications 36a-b).
Kumabe, McKelvie, and Tosa do not teach but —
(D) Rothman, however teaches or suggests:
“so as to make the target operating system recover the execution program according to the context information of the execution program”
(¶¶ 20–21: when a virtual machine exit occurs, components of the processor state used by guest software are saved, 210, components of the processor state required by the VMM 112 are loaded, and the execution resumes in the VMM 112 at 220. In one embodiment, the components of the processor state used by guest software are stored in a guest-state area of VMCS 124 and the components of the processor state required by the VMM 112 are stored in a monitor-state area of VMCS 124. In one embodiment, when a transition from the VMM 112 to guest software occurs, components of the processor state that were saved at the virtual machine exit (and may have been modified by the VMM 112 while processing the virtual machine exit) are restored 225 and control is returned to the virtual machine 102 or 114 at 230).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of (D) Rothman with those of (A) Kumabe, (B) McKelvie, and (C) Tosa to halt, save, and resume guest VM execution state. The motivation or advantage to do so is to enable restoring processing context and execution to the guest VM (after exception handling).
23. Regarding claim 13, Kumabe, McKelvie, Tosa, and Rothman teach or suggest:
“wherein after the inter-core communication data is sent to the virtual machine monitor by the operating system, the virtual machine monitor further acquires and stores context information of an execution program of the operating system
(Kumabe, see Fig. 4 and ¶ 49, ¶ 50, ¶ 60, ¶ 70, and ¶ 29, as applied in rejecting claim 1 above, teaching performing inter-core communications using shared memory;
¶ 75 to ¶ 77, as applied in rejecting claim 1 above, teaching bridge processing and virtual machines and the hypervisor are mutually communicably connected to each other by a virtual communication pipe;
¶ 61: as applied in rejecting claim 1 above, teaching storing the data input and outputting an interrupt signal to the hardware control core and the hardware control core reads the stored data with based on the reception of the interrupt signal output (downlink);
¶ 60, as applied in rejecting claim 1 above, teaching reading the stored data based on the reception of the interrupt signal output from the storage processing (uplink);
Tosa, ¶ 43: an exception is handled by halting execution of the instruction triggering the exception, saving the current processor state to a predefined location and switching execution to a specific subroutine known as an exception handler. In some embodiments, virtualization exceptions suspend the execution of the current instruction (the instruction executing within guest VM 32;
Rothman, ¶¶ 20–21: when a virtual machine exit occurs, components of the processor state used by guest software are saved, 210, components of the processor state required by the VMM 112 are loaded, and the execution resumes in the VMM 112 at 220. In one embodiment, the components of the processor state used by guest software are stored in a guest-state area of VMCS 124 and the components of the processor state required by the VMM 112 are stored in a monitor-state area of VMCS 124. In one embodiment, when a transition from the VMM 112 to guest software occurs, components of the processor state that were saved at the virtual machine exit (and may have been modified by the VMM 112 while processing the virtual machine exit) are restored 225 and control is returned to the virtual machine 102 or 114 at 230);
before the acquiring the communication feedback data obtained by the virtual machine monitor, the method further comprises:
reading the context information of the execution program stored in the virtual machine monitor, and recovering the execution program based on the context information of the execution program”
(Kumabe, see Fig. 4 and ¶ 49, ¶ 50, ¶ 60, ¶ 70, and ¶ 29, as applied in rejecting claim 1 above, teaching performing inter-core communications using shared memory;
¶ 75 to ¶ 77, as applied in rejecting claim 1 above, teaching bridge processing and virtual machines and the hypervisor are mutually communicably connected to each other by a virtual communication pipe;
¶ 61: as applied in rejecting claim 1 above, teaching storing the data input and outputting an interrupt signal to the hardware control core and the hardware control core reads the stored data with based on the reception of the interrupt signal output (downlink);
¶ 60, as applied in rejecting claim 1 above, teaching reading the stored data based on the reception of the interrupt signal output from the storage processing (uplink);
McKelvie, Col. 24, lines 49–55; Col. 6, lines 49–55; Col. 19, lines 37–44, teaching sender receiving an acknowledgement of the completion of the write).
Tosa, ¶ 43: hypervisor may configure processor to generate a processor event, herein termed virtualization exception, in response to detecting an attempt by software executing within guest VM 32 to violate a memory access permission … Processor exceptions are anomalous or exceptional events changing the normal flow of program execution and requiring special processing;
¶ 49: Some hardware configurations allow hypervisor 30 to selectively control access to data stored in memory, for instance, by setting read, write, and/or execute access rights to a section of memory. Hypervisor 30 may thus select which software object may access data stored within the respective memory section, and/or may indicate which operations are allowed with the respective data, e.g., read, write, execute. An attempt by a software object executing within guest VM 32 to perform an illegal operation such as writing data to a section marked as non-writable, or executing code from a section marked as non-executable, may be interpreted as a memory access violation, and may trigger a virtualization exception;
¶ 45: hypervisor 30 may mark the respective memory section as non-readable (read-protection). In such embodiments, a virtualization exception may be triggered by an attempt to fetch an executable instruction from a read-protected section of memory;
Rothman, ¶¶ 20–21: when a virtual machine exit occurs, components of the processor state used by guest software are saved, 210, components of the processor state required by the VMM 112 are loaded, and the execution resumes in the VMM 112 at 220. In one embodiment, the components of the processor state used by guest software are stored in a guest-state area of VMCS 124 and the components of the processor state required by the VMM 112 are stored in a monitor-state area of VMCS 124. In one embodiment, when a transition from the VMM 112 to guest software occurs, components of the processor state that were saved at the virtual machine exit (and may have been modified by the VMM 112 while processing the virtual machine exit) are restored 225 and control is returned to the virtual machine 102 or 114 at 230).
D.
24. Claim 17 is rejected under 35 U.S.C. 103 as being unpatentable over (A) Kumabe in view of (B) McKelvie, as applied to claim 15 above, and further in view of (E) PikeOS.
25. Regarding claim 17, Kumabe, McKelvie, and Tosa do not teach “wherein the virtual machine monitor is built by a microkemel-based real-time operating system”
(E) PikeOS however teaches or suggests:
“wherein the virtual machine monitor is built by a microkemel-based real-time operating system”
(pg. 1: PikeOS is a commercial, hard real-time operating system (RTOS) that offers a separation kernel based hypervisor with multiple logical partition types for many other operating systems (OS), each called a GuestOS, and applications;
pg. 1, Overview: PikeOS combines a real-time operating system (RTOS) with a virtualization platform and Eclipse-based integrated development environment (IDE) for embedded systems. It is a commercial clone of L4 microkernel family;
pg. 2: PikeOS can be seen as a Type 1 hypervisor).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of (E) PikeOS with those of (A) Kumabe and (B) McKelvie to build or incorporate a microkernel-based, RTOS hypervisor. The motivation or advantage to do so is to support and run security critical real-time applications on a virtualization platform.
Allowable Subject Matter
26. Claims 5–7 and 9–10 are objected to as being dependent upon a rejected base claim, but would be allowable if 1) rewritten in independent form including all of the limitations of the base claim and any intervening claims, and 2) rewritten to overcome the applied 112(b) indefiniteness rejections.
The following is the Examiner’s statement of reasons for allowance:
The prior art of record, when viewed individually or in combination, does not expressly teach nor render obvious the features of dependent claims 5 and 9 when viewed as a whole, specific to the limitation(s) of:
“wherein the inter-core communication data comprises communication source core information, communication destination core information, and the communication data content; and
the writing a communication data content in the inter-core communication data into a preset memory, and triggering a target CPU core to read the communication data content from the preset memory comprises:
writing the communication data content in the inter-core communication data into a preset communication address in a preset DDR, and writing the communication source core information in the inter-core communication data into a preset interrupt flag bit register, wherein the preset communication address in the preset DDR is a set communication address in a DDR bound to the target CPU core …” (claim 5), and
“wherein the inter-core communication data comprises communication source core information, communication destination core information, and the communication data content; the virtual machine monitor writes the communication data content in the inter-core communication data into a preset communication address in a preset DDR before triggering the CPU core to read the communication data content from the preset memory, and writes the communication source core information in the inter-core communication data into a preset interrupt flag bit register; the preset communication address in the preset DDR is a set communication address in a DDR bound to the target CPU core” (claim 9).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to BENJAMIN C WU whose telephone number is (571)270-5906. The examiner can normally be reached Monday through Friday, 8:30 A.M. to 5:00 P.M..
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, Aimee J. Li can be reached on (571)272-4169. 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.
/BENJAMIN C WU/Primary Examiner, Art Unit 2195
March 21, 2026
Prosecution Insights