DETAILED ACTION
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 .
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-10 and 23-24 are rejected under 35 U.S.C. 101 because the claimed invention is directed to (an) abstract idea(s) without significantly more.
Claim 1 recites:
A computer program product comprising:
a set of one or more computer-readable storage media; and
program instructions, collectively stored in the set of one or more computer-readable storage media, for causing at least one computing device to perform computer operations including:
performing interpretative execution by a physical processor of a computing environment for a virtual processor executing on the physical processor, the performing interpretative execution including:
obtaining an order code indicating an action to be taken for the virtual processor;
accessing a shadow state description of the virtual processor to obtain an original state description origin, the original state description origin indicating a location of an original state description of the virtual processor, the original state description including state information of the virtual processor; and
performing an action using an indicator of the state information of the virtual processor, the indicator selected based on the order code, and wherein the action is performed by the physical processor on behalf of the virtual processor.
Step 1: Is the claim to a process, machine, manufacture, or composition of matter?
No.
Claim 1 is directing to one or more computer-readable storage media. The specification does define the computer-readable storage medium in paragraph [0049] as not to be construed as storage in the form transitory signals per se, however, it is unclear exactly what the one or more computer-readable storage media are. Thus, under BRI, the CRSM would reasonably interpret the one or more computer-readable storage media to cover both transitory mediums and non-transitory mediums wherein transitory mediums are not statutory subject matter.
Claims 2-9 are directing to one or more computer-readable storage media which are dependent on claim 1. Therefore, claims 1-10 are directed to non-statutory subject matter and do not fall within at least one of the four categories of patent eligible subject matter.
Claim 23 recites:
A computer program product comprising:
a set of one or more computer-readable storage media; and
program instructions, collectively stored in the set of one or more computer-readable storage media, for causing at least one computing device to perform computer operations including:
performing interpretative execution by a physical processor of a computing environment for a virtual processor executing on the physical processor, the performing interpretative execution including:
accessing a shadow control structure of the virtual processor to obtain addressability to an original control structure of the virtual processor, the original control structure including state information of the virtual processor; and
performing an action using the state information of the virtual processor, wherein the action is performed by the physical processor on behalf of the virtual processor.
Step 1: Is the claim to a process, machine, manufacture, or composition of matter?
No.
Claim 23 is directing to one or more computer-readable storage media. The specification does define the computer-readable storage medium in paragraph [0049] as not to be construed as storage in the form transitory signals per se, however, it is unclear exactly what the one or more computer-readable storage media are. Thus, under BRI, the CRSM would reasonably interpret the one or more computer-readable storage media to cover both transitory mediums and non-transitory mediums wherein transitory mediums are not statutory subject matter.
Claim 24 is directing to one or more computer-readable storage media which is dependent on claim 23. Therefore, claims 23-24 are directed to non-statutory subject matter and do not fall within at least one of the four categories of patent eligible subject matter.
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) 1, 7-9, 11, 16-17, 22-23 and 25 are rejected under 35 U.S.C. 103 as being unpatentable over Tallman et al. (U.S. Publication No. US 4792895 A), hereinafter “Tallman” in view of Osisek et al. (“ESAl390 interpretive execution architecture, foundation for VM/ESA”), hereinafter “Osisek.”
With regards to claim 1, Tallman teaches:
A computer program product comprising:
a set of one or more computer-readable storage media (Fig. 1, Col. 3, lines 26-34, “The VM system includes real (host) machine 12 and a plurality of virtual machines (guests) 14 supported by the real machine. The real machine includes central processing unit (CPU) 16 that executes a system control program (SCP), referred to as the host program or virtual machine monitor (VMM), which manages real machine resources (CPU, memory) and provides services to the guests via line 22.” The VM system including a real host machine which includes real machine resources including memory correlates to a computer program product comprising: a set of one or more computer-readable storage media); and
program instructions, collectively stored in the set of one or more computer-readable storage media (Fig. 1, Col. 3, lines 26-41, “The VM system includes real (host) machine 12 and a plurality of virtual machines (guests) 14 supported by the real machine. The real machine includes central processing unit (CPU) 16 that executes a system control program (SCP), referred to as the host program or virtual machine monitor (VMM), which manages real machine resources (CPU, memory) and provides services to the guests via line 22. An example of the virtual machine monitor is the VM/XA control program (program number 5664-169). In particular, the host program controls the resources of the real machine while providing each user with a virtual machine environment that includes virtual machine resources such as (virtual) storage 18, i.e. virtual machine address space, and a (virtual) CPU 20.” The VM system including a host program which controls the resources of the real machine would be stored in the real host machine memory and therefore correlates to program instructions, collectively stored in the set of one or more computer-readable storage media), for causing at least one computing device to perform computer operations including:
performing interpretative execution by a physical processor of a computing environment for a virtual processor executing on the physical processor (Col. 3, lines 58-65, “In the embodiment of this invention, a method of operation is provided in which the host machine, while in an interpretive-execution mode, performs the functions of a guest (an interpreted machine). In other words, the real machine supports the virtual machine environment by executing (processing) the instructions of programs in a guest while the real machine is in the interpretive execution mode.” The real machine correlates to the physical processor, and the virtual machines or guests in the virtual machine environment correlates to the virtual processor. The real machine in an interpretive execution mode supporting the virtual machine environment by executing the instructions of programs in a guest correlates to performing interpretative execution by a physical processor of a computing environment for a virtual processor executing on the physical processor), the performing interpretative execution including:
obtaining an order code indicating an action to be taken for the virtual processor (Col. 3, lines 65-68 and Col. 4, lines 1-8, “The interpretive excecution of one of several guest machines begins when the host executes a start interpretive execution (SIE) instruction. The SIE instruction initiates interpretive execution hardware to provide for the host machine to enter the interpretive execution mode and to commence execution of a guest program. The operand of the SIE instruction is referred to as the state description. The state description, which is located in real storage, includes parameters that describe the logical condition of the guest whose instructions are to be executed (interpreted).” The SIE instruction which includes operands describing the logical condition of the guest whose instructions are to be executed correlates to the order code. The host machine executing a start interpretive execution instruction to commence execution of a guest program correlates to obtaining an order code indicating an action to be taken for the virtual processor); and
performing an action using an indicator of the state information of the virtual processor, the indicator selected based on the order code, and wherein the action is performed by the physical processor on behalf of the virtual processor (Col. 3, lines 65-68, Col. 4, lines 1-14, Col. 6, line 68 and Col. 7, lines 1-4 and 12-22, “The interpretive excecution of one of several guest machines begins when the host executes a start interpretive execution (SIE) instruction. The SIE instruction initiates interpretive execution hardware to provide for the host machine to enter the interpretive execution mode and to commence execution of a guest program. The operand of the SIE instruction is referred to as the state description. The state description, which is located in real storage, includes parameters that describe the logical condition of the guest whose instructions are to be executed (interpreted). In particular, fields in the state description specify the architecture of the guest, the contents of some of the program-addressable guest registers, the addresses of related control tables, the initial state of the guest CPU, and information about other aspects of the operation to include how host storage is to be used to represent guest main storage (guest storage mode) … The host executes an SIE instruction which causes the host to enter the interpretive-execution mode and to begin performing the functions of the level 2 guest, i.e. instruction stream 31… The intercepted SIE instruction issued by the level 2 guest indicates that level 3 guest instruction processing is required. V/SIE support in the host machine simulates the interpretive execution mode and the SIE instruction by the real machine. (Level 3 guest state description 34 is provided in the level 2 guest real address space for specifying the type of level 3 guest for which instructions are to be processed. State description 34 is the operand of intercepted SIE instruction 32.” The SIE instruction containing an operand which includes information such as parameters describing the logical condition of the guest whose instructions are to be executed correlates to an indicator of the state information of the virtual processor. The SIE instruction commencing execution of a guest program would require details describing the logical condition of the guest in order to commence execution of a guest program, and therefore correlates to the indicator selected based on the order code. The execution of a guest program being commenced by the host machine, which performs the functions of the level 2 guest using the state description, correlates to performing an action using an indicator of the state information of the virtual processor, and wherein the action is performed by the physical processor on behalf of the virtual processor).
Tallman does not explicitly teach:
accessing a shadow state description of the virtual processor to obtain an original state description origin, the original state description origin indicating a location of an original state description of the virtual processor, the original state description including state information of the virtual processor;
However, Osisek teaches:
accessing a shadow state description of the virtual processor to obtain an original state description origin, the original state description origin indicating a location of an original state description of the virtual processor, the original state description including state information of the virtual processor (Page 49, paragraph 8 and page 50, paragraphs 1-2, “First, the state description itself must be shadowed. CP's vSIE support copies the state description specified as the operand of the RGuest SIE instruction and edits it to represent the host's view of the VGuest, for example, by translating RGuest real addresses of control structures into the host real addresses expected by the machine. Then, vSIE must create shadow translation tables to apply the composition of RGuest and host address translation… Whenever an interception or interruption is to be presented to the RGuest, the contents of the shadow state description, representing the current VGuest state, must be transcribed into the state description in RGuest storage.” The Rguest being presented with the shadow state description correlates to accessing a shadow state description of the virtual processor. The shadow state description representing the current VGuest state through real addresses of control structures correlates to accessing a shadow state description of the virtual processor to obtain an original state description origin. The contents of the shadow state description such as the real addresses of control structures being transcribed into the state description in RGuest storage correlates to the original state description origin indicating a location of an original state description of the virtual processor);
Therefore, it would have been obvious to one of ordinary skill in the art to which said subject matter pertains before the effective filing date of the claimed invention to combine Tallman with accessing a shadow state description of the virtual processor to obtain an original state description origin, the original state description origin indicating a location of an original state description of the virtual processor, the original state description including state information of the virtual processor as taught by Osisek because shadowing is a time-honored virtualization technique which allows SIE instructions to simulate SIE and prevent VMs from paying huge, continuing costs to maintain simulation routines for every instruction. While SIE recognizes two levels of programs, if three levels of address translated are required, translating guest real addresses of control structures into host real addresses expected by the machine allows SIE to be performed against the shadow state description (Osisek: page 49, paragraphs 6-8 and page 50, paragraphs 1-2).
With regards to Claims 11 and 17, the manufacture of Claim 1 performs the same steps as the machine and method of Claims 11 and 17 respectively, and Claims 11 and 17 are therefore rejected using the same rationale set forth above in the rejection of Claim 1.
With regards to claim 7, Tallman in view of Osisek teaches the manufacture of claim 1 above. Tallman further teaches:
wherein the virtual processor is a nested virtual processor (Col. 3, lines 25-29, Col. 6, lines 43-56, “FIG. 1 shows the structure of computer system 10 referred to as a virtual machine (VM) system. The VM system includes real (host) machine 12 and a plurality of virtual machines (guests) 14 supported by the real machine… FIG. 2a also shows a level two virtual machine (level 2 guest) which can execute a second copy of the same version of the host (VM/XA) system control program or other programs which include the SIE and other privileged instructions. Level three contains a virtual machine (level 3 guest) which can execute guest programs that include SIE and other privileged instructions. In this case, programs running at higher levels, i.e. level three, could also be considered guest programs of the lower level two virtual machine which itself could be considered as a "host". In FIG. 2a, the level 2 guest includes virtual address space 30 in which instructions (instruction stream 31) are being processed up to SIE instruction 32.” The real host machine supporting a plurality of virtual machine guests, which are level 2 and level 3 guests, correlates to wherein the virtual processor is a nested virtual processor).
With regards to Claims 16 and 22, the manufacture of Claim 7 performs the same steps as the machine and method of Claims 16 and 22 respectively, and Claims 16 and 22 are therefore rejected using the same rationale set forth above in the rejection of Claim 7.
With regards to claim 8, Tallman in view of Osisek teaches the manufacture of claim 1 above. Tallman further teaches:
wherein the virtual processor is initiated via a start interpretative execution instruction (Col. 3, lines 65-68, Col. 4, lines 1-3, “The interpretive excecution of one of several guest machines begins when the host executes a start interpretive execution (SIE) instruction. The SIE instruction initiates interpretive execution hardware to provide for the host machine to enter the interpretive execution mode and to commence execution of a guest program.” The interpretive execution of a guest machine and execution of a guest program beginning from the host executing a start interpretive execution instruction correlates to wherein the virtual processor is initiated via a start interpretative execution instruction), the start interpretative execution instruction including an operand that specifies the original state description of the virtual processor (Col. 3, lines 65-68, Col. 4, lines 1-3, “The interpretive excecution of one of several guest machines begins when the host executes a start interpretive execution (SIE) instruction. The SIE instruction initiates interpretive execution hardware to provide for the host machine to enter the interpretive execution mode and to commence execution of a guest program. The operand of the SIE instruction is referred to as the state description. The state description, which is located in real storage, includes parameters that describe the logical condition of the guest whose instructions are to be executed (interpreted). In particular, fields in the state description specify the architecture of the guest, the contents of some of the program-addressable guest registers, the addresses of related control tables, the initial state of the guest CPU, and information about other aspects of the operation to include how host storage is to be used to represent guest main storage (guest storage mode).” The operand of the SIE instruction including the initial state of the guest CPU correlates to the start interpretative execution instruction including an operand that specifies the original state description of the virtual processor).
Tallman does not explicitly teach that operand specifies the location of the original state description of the virtual processor. However, obtaining the location of the original state description of the virtual processor is a popular method of accessing the original state description of the virtual processor as evidenced by Osisek (Page 49, paragraph 8 and page 50, paragraphs 1-2, “First, the state description itself must be shadowed. CP's vSIE support copies the state description specified as the operand of the RGuest SIE instruction and edits it to represent the host's view of the VGuest, for example, by translating RGuest real addresses of control structures into the host real addresses expected by the machine. Then, vSIE must create shadow translation tables to apply the composition of RGuest and host address translation… Whenever an interception or interruption is to be presented to the RGuest, the contents of the shadow state description, representing the current VGuest state, must be transcribed into the state description in RGuest storage.” The real addresses of control structures being transcribed into the state description in RGuest storage correlates to obtaining the location of the original state description of the virtual processor);
Therefore, it would have been obvious to one of ordinary skill in the art to which said subject matter pertains before the effective filing date of the claimed invention to combine Tallman with the start interpretative execution instruction including an operand that specifies a location of the original state description of the virtual processor as taught by Osisek because shadowing is a time-honored virtualization technique which allows SIE instructions to simulate SIE and prevent VMs from paying huge, continuing costs to maintain simulation routines for every instruction. While SIE recognizes two levels of programs, if three levels of address translated are required, translating guest real addresses of control structures into host real addresses expected by the machine allows SIE to be performed against the shadow state description (Osisek: page 49, paragraphs 6-8 and page 50, paragraphs 1-2).
With regards to claim 9, Tallman in view of Osisek teaches the manufacture of claim 1 above. Osisek further teaches:
wherein the original state description of the virtual processor is accessible to the physical processor via the shadow state description and directly inaccessible to the physical processor (Page 49, paragraph 8 and page 50, paragraphs 1-2, “First, the state description itself must be shadowed. CP's vSIE support copies the state description specified as the operand of the RGuest SIE instruction and edits it to represent the host's view of the VGuest, for example, by translating RGuest real addresses of control structures into the host real addresses expected by the machine. Then, vSIE must create shadow translation tables to apply the composition of RGuest and host address translation… Whenever an interception or interruption is to be presented to the RGuest, the contents of the shadow state description, representing the current VGuest state, must be transcribed into the state description in RGuest storage.” The shadow state description correlates to the shadow state description, and current VGuest state correlates to the original state description of the virtual processor. The contents of the shadow state description including RGuest real addresses needing to be transcribed into the state description in RGuest storage requires a transcription process before the RGuest can access the current VGuest state and therefore correlates to wherein the original state description of the virtual processor is accessible to the physical processor via the shadow state description and directly inaccessible to the physical processor).
Therefore, it would have been obvious to one of ordinary skill in the art to which said subject matter pertains before the effective filing date of the claimed invention to combine Tallman with wherein the original state description of the virtual processor is accessible to the physical processor via the shadow state description and directly inaccessible to the physical processor as taught by Osisek because shadowing is a time-honored virtualization technique which allows SIE instructions to simulate SIE and prevent VMs from paying huge, continuing costs to maintain simulation routines for every instruction. While SIE recognizes two levels of programs, if three levels of address translated are required, translating guest real addresses of control structures into host real addresses expected by the machine allows SIE to be performed against the shadow state description (Osisek: page 49, paragraphs 6-8 and page 50, paragraphs 1-2).
With regards to claim 23, Tallman teaches:
A computer program product comprising: a set of one or more computer-readable storage media (Fig. 1, Col. 3, lines 26-34, “The VM system includes real (host) machine 12 and a plurality of virtual machines (guests) 14 supported by the real machine. The real machine includes central processing unit (CPU) 16 that executes a system control program (SCP), referred to as the host program or virtual machine monitor (VMM), which manages real machine resources (CPU, memory) and provides services to the guests via line 22.” The VM system including a real host machine which includes real machine resources including memory correlates to a computer program product comprising: a set of one or more computer-readable storage media); and program instructions, collectively stored in the set of one or more computer-readable storage media (Fig. 1, Col. 3, lines 26-41, “The VM system includes real (host) machine 12 and a plurality of virtual machines (guests) 14 supported by the real machine. The real machine includes central processing unit (CPU) 16 that executes a system control program (SCP), referred to as the host program or virtual machine monitor (VMM), which manages real machine resources (CPU, memory) and provides services to the guests via line 22. An example of the virtual machine monitor is the VM/XA control program (program number 5664-169). In particular, the host program controls the resources of the real machine while providing each user with a virtual machine environment that includes virtual machine resources such as (virtual) storage 18, i.e. virtual machine address space, and a (virtual) CPU 20.” The VM system including a host program which controls the resources of the real machine would be stored in the real host machine memory and therefore correlates to program instructions, collectively stored in the set of one or more computer-readable storage media), for causing at least one computing device to perform computer operations including: performing interpretative execution by a physical processor of a computing environment for a virtual processor executing on the physical processor (Col. 3, lines 58-65, “In the embodiment of this invention, a method of operation is provided in which the host machine, while in an interpretive-execution mode, performs the functions of a guest (an interpreted machine). In other words, the real machine supports the virtual machine environment by executing (processing) the instructions of programs in a guest while the real machine is in the interpretive execution mode.” The real machine correlates to the physical processor, and the virtual machines or guests in the virtual machine environment correlates to the virtual processor. The real machine in an interpretive execution mode supporting the virtual machine environment by executing the instructions of programs in a guest correlates to performing interpretative execution by a physical processor of a computing environment for a virtual processor executing on the physical processor), the performing interpretative execution including:
and performing an action using the state information of the virtual processor, wherein the action is performed by the physical processor on behalf of the virtual processor (Col. 3, lines 65-68, Col. 4, lines 1-14, Col. 6, line 68 and Col. 7, lines 1-4 and 12-22, “The interpretive excecution of one of several guest machines begins when the host executes a start interpretive execution (SIE) instruction. The SIE instruction initiates interpretive execution hardware to provide for the host machine to enter the interpretive execution mode and to commence execution of a guest program. The operand of the SIE instruction is referred to as the state description. The state description, which is located in real storage, includes parameters that describe the logical condition of the guest whose instructions are to be executed (interpreted). In particular, fields in the state description specify the architecture of the guest, the contents of some of the program-addressable guest registers, the addresses of related control tables, the initial state of the guest CPU, and information about other aspects of the operation to include how host storage is to be used to represent guest main storage (guest storage mode) … The host executes an SIE instruction which causes the host to enter the interpretive-execution mode and to begin performing the functions of the level 2 guest, i.e. instruction stream 31… The intercepted SIE instruction issued by the level 2 guest indicates that level 3 guest instruction processing is required. V/SIE support in the host machine simulates the interpretive execution mode and the SIE instruction by the real machine. (Level 3 guest state description 34 is provided in the level 2 guest real address space for specifying the type of level 3 guest for which instructions are to be processed. State description 34 is the operand of intercepted SIE instruction 32.” The execution of a guest program being commenced by the host machine, which performs the functions of the level 2 guest using the state description, correlates to performing an action using the state information of the virtual processor, wherein the action is performed by the physical processor on behalf of the virtual processor).
Tallman does not explicitly teach:
accessing a shadow control structure of the virtual processor to obtain addressability to an original control structure of the virtual processor, the original control structure including state information of the virtual processor;
However, Osisek teaches:
accessing a shadow control structure of the virtual processor to obtain addressability to an original control structure of the virtual processor, the original control structure including state information of the virtual processor (Page 49, paragraph 8 and page 50, paragraphs 1-2, “First, the state description itself must be shadowed. CP's vSIE support copies the state description specified as the operand of the RGuest SIE instruction and edits it to represent the host's view of the VGuest, for example, by translating RGuest real addresses of control structures into the host real addresses expected by the machine. Then, vSIE must create shadow translation tables to apply the composition of RGuest and host address translation… Whenever an interception or interruption is to be presented to the RGuest, the contents of the shadow state description, representing the current VGuest state, must be transcribed into the state description in RGuest storage.” The shadow state description correlates to the shadow control structure of the virtual processor, and the real address of the RGuest control structures correlates to the addressability to an original control structure of the virtual processor. Therefore, the shadow state description representing the current VGuest state through real addresses of control structures being transcribed correlates to accessing a shadow control structure of the virtual processor to obtain addressability to an original control structure of the virtual processor. The contents of the shadow state description such as the real addresses of control structures being transcribed into the state description in RGuest storage correlates to the original control structure including state information of the virtual processor);
Therefore, it would have been obvious to one of ordinary skill in the art to which said subject matter pertains before the effective filing date of the claimed invention to combine Tallman with accessing a shadow control structure of the virtual processor to obtain addressability to an original control structure of the virtual processor, the original control structure including state information of the virtual processor as taught by Osisek because shadowing is a time-honored virtualization technique which allows SIE instructions to simulate SIE and prevent VMs from paying huge, continuing costs to maintain simulation routines for every instruction. While SIE recognizes two levels of programs, if three levels of address translated are required, translating guest real addresses of control structures into host real addresses expected by the machine allows SIE to be performed against the shadow state description (Osisek: page 49, paragraphs 6-8 and page 50, paragraphs 1-2).
With regards to Claim 25, the manufacture of Claim 23 performs the same steps as the method of Claim 25, and Claim 25 is therefore rejected using the same rationale set forth above in the rejection of Claim 23.
Claim(s) 2-4, 12-13, 18-19 and 24 are rejected under 35 U.S.C. 103 as being unpatentable over Tallman in view of Osisek and Moriki et al. (U.S. Publication No. US 20100115513 A1), hereinafter “Moriki.”
With regards to claim 2, Tallman in view of Osisek teaches the manufacture of claim 1 above. Tallman in view of Osisek does not explicitly teach:
wherein the accessing the shadow state description includes accessing a shadow signal processor entry of a shadow system control area to obtain a shadow state description address of the shadow state description.
However, Moriki teaches:
wherein the accessing the shadow state description includes accessing a shadow signal processor entry of a shadow system control area to obtain the shadow state description (Paragraphs 91-92 and 134, “Each of the shadow VMCSs 130 includes a guest-state area 131, a host-state area 132, a VM-execution control field 133, a VM-exit control field 134, a VM-entry control field 135, and a VM-exit information field 136. As illustrated in FIG. 4, the guest-state area 131 stores statuses such as register states and non-register states of the virtual CPUs 108a to 108n... When the physical CPU 104 receives the VM-entry instruction, the physical CPU 104 reads the guest-state area 131 of the shadow VMCS #0 pointed by the pointer 115, and executes the guest VMM 109 or the user program 110a of the virtual server 102a selected by the state area selection module 121.” The shadow VMCS correlates to a shadow system control area. Each virtual CPU status stored in the guest-state area correlates to a shadow signal processor entry of a shadow system control area. The pointer pointing to a particular guest-state area of the shadow VMCS, which stores statuses of virtual CPUs, correlates to accessing a shadow signal processor entry of a shadow system control area to obtain the shadow state description).
Moriki does not explicitly teach that the shadow state description address is obtained from the shadow signal processor entry. However, shadow state description addresses are a popular method of referencing shadow state descriptions as evidenced by Osisek (Page 49, paragraph 8, “First, the state description itself must be shadowed. CP's vSIE support copies the state description specified as the operand of the RGuest SIE instruction and edits it to represent the host's view of the VGuest, for example, by translating RGuest real addresses of control structures into the host real addresses expected by the machine. Then, vSIE must create shadow translation tables to apply the composition of RGuest and host address translation.” The shadow state description being represented by translating the RGuest real address of control structures correlates to a shadow state description address).
Therefore, it would have been obvious to one of ordinary skill in the art to which said subject matter pertains before the effective filing date of the claimed invention to combine Tallman with a shadow state description address of the shadow state description as taught by Osisek because shadowing is a time-honored virtualization technique which allows SIE instructions to simulate SIE and prevent VMs from paying huge, continuing costs to maintain simulation routines for every instruction. While SIE recognizes two levels of programs, if three levels of address translated are required, translating guest real addresses of control structures into host real addresses expected by the machine allows SIE to be performed against the shadow state description (Osisek: page 49, paragraphs 6-8 and page 50, paragraphs 1-2).
Additionally, it would have been obvious to one of ordinary skill in the art to which said subject matter pertains before the effective filing date of the claimed invention to combine Tallman with wherein the accessing the shadow state description includes accessing a shadow signal processor entry of a shadow system control area to obtain the shadow state description as taught by Moriki because shadow VMCS can be used to coordinate operations in switching from modes such as VMX root mode to a VMX non-root mode, where the shadow VMCS is updated with the guest VMCS information during a process of a VM exit. Information read from the shadow VMCS’s guest-state area can be used to start the VM entry instruction and resume execution following the switch in operation mode (Moriki: paragraphs 131-133).
With regards to claim 3, Tallman in view of Osisek and Moriki teaches the manufacture of claim 2 above. Osisek further teaches:
wherein the shadow state description further includes an original signal processor entry address of an original signal processor entry of an original system control area of the virtual processor (Page 49, paragraph 8 and page 50, paragraphs 1-2, “First, the state description itself must be shadowed. CP's vSIE support copies the state description specified as the operand of the RGuest SIE instruction and edits it to represent the host's view of the VGuest, for example, by translating RGuest real addresses of control structures into the host real addresses expected by the machine. Then, vSIE must create shadow translation tables to apply the composition of RGuest and host address translation… Whenever an interception or interruption is to be presented to the RGuest, the contents of the shadow state description, representing the current VGuest state, must be transcribed into the state description in RGuest storage.” The Rguest being presented with the shadow state description correlates to a shadow state description. The real addresses of control structures which represent the current VGuest state correlates to the original signal processor entry address. The shadow state description representing the current VGuest state through real addresses of control structures correlates to the shadow state description including an original signal processor entry address. The contents of the shadow state description such as the real addresses of control structures being transcribed into the state description in RGuest storage correlates to an original signal processor entry address of an original signal processor entry of an original system control area of the virtual processor).
Osisek does not explicitly teach that the shadow signal processor entry further includes an original signal processor entry address. However, shadow state descriptions are a popular component included in shadow signal processor entries as evidenced by Moriki (Paragraphs 91-92 and 134, “Each of the shadow VMCSs 130 includes a guest-state area 131, a host-state area 132, a VM-execution control field 133, a VM-exit control field 134, a VM-entry control field 135, and a VM-exit information field 136. As illustrated in FIG. 4, the guest-state area 131 stores statuses such as register states and non-register states of the virtual CPUs 108a to 108n... When the physical CPU 104 receives the VM-entry instruction, the physical CPU 104 reads the guest-state area 131 of the shadow VMCS #0 pointed by the pointer 115, and executes the guest VMM 109 or the user program 110a of the virtual server 102a selected by the state area selection module 121.” Each virtual CPU status stored in the guest-state area correlates to a shadow signal processor entry of a shadow system control area. The pointer pointing to a particular guest-state area of the shadow VMCS, which stores statuses of virtual CPUs, correlates to a shadow signal processor entry including the shadow state description).
Therefore, it would have been obvious to one of ordinary skill in the art to which said subject matter pertains before the effective filing date of the claimed invention to combine Tallman with accessing a shadow state description of the virtual processor to obtain an original state description origin, the original state description origin indicating a location of an original state description of the virtual processor, the original state description including state information of the virtual processor as taught by Osisek because shadowing is a time-honored virtualization technique which allows SIE instructions to simulate SIE and prevent VMs from paying huge, continuing costs to maintain simulation routines for every instruction. While SIE recognizes two levels of programs, if three levels of address translated are required, translating guest real addresses of control structures into host real addresses expected by the machine allows SIE to be performed against the shadow state description (Osisek: page 49, paragraphs 6-8 and page 50, paragraphs 1-2).
Additionally, it would have been obvious to one of ordinary skill in the art to which said subject matter pertains before the effective filing date of the claimed invention to combine Tallman with wherein the accessing the shadow state description includes accessing a shadow signal processor entry of a shadow system control area to obtain the shadow state description as taught by Moriki because shadow VMCS can be used to coordinate operations in switching from modes such as VMX root mode to a VMX non-root mode, where the shadow VMCS is updated with the guest VMCS information during a process of a VM exit. Information read from the shadow VMCS’s guest-state area can be used to start the VM entry instruction and resume execution following the switch in operation mode (Moriki: paragraphs 131-133).
With regards to Claims 12 and 18, the manufacture of Claims 2 and 3 perform the same steps as the machine and method of Claims 12 and 18 respectively, and Claims 12 and 18 are therefore rejected using the same rationale set forth above in the rejection of Claims 2 and 3.
With regards to claim 4, Tallman in view of Osisek and Moriki teaches the manufacture of claim 3 above. Moriki further teaches:
wherein the original signal processor entry and the shadow signal processor entry include information for the virtual processor, (Paragraphs 91-92, 110-112 and 134, “Each of the shadow VMCSs 130 includes a guest-state area 131, a host-state area 132, a VM-execution control field 133, a VM-exit control field 134, a VM-entry control field 135, and a VM-exit information field 136. As illustrated in FIG. 4, the guest-state area 131 stores statuses such as register states and non-register states of the virtual CPUs 108a to 108n... On the other hand, the virtual CPU control data 114 managed by the guest VMM 109 of the virtual server 102a stores the guest VMCS 22 having the same data structure as the shadow VMCS #0 of the above-mentioned physical CPU control data 13. The guest VMM 109 includes the guest-state area 221 for storing statuses such as register states of the virtual CPU 108a executing the user program 110a (grandchild OS 111a or application program 112a) … Similarly to FIG. 4, the guest-state area 221 stores the statuses such as the register states of the virtual CPU 108a. In other words, as described later, the status of the grandchild OS 111a or the status of the application program 112a is selectively stored… When the physical CPU 104 receives the VM-entry instruction, the physical CPU 104 reads the guest-state area 131 of the shadow VMCS #0 pointed by the pointer 115, and executes the guest VMM 109 or the user program 110a of the virtual server 102a selected by the state area selection module 121.” Each virtual CPU status stored in the guest-state area of the shadow VMCS and guest VMCS correlates to a shadow signal processor entry and the original signal processor entry respectively. The pointer pointing to a particular guest-state area of the shadow VMCS, which stores statuses of virtual CPUs, correlates to wherein the shadow signal processor entry includes information for the virtual processor. The guest-state area of the guest VMCS storing statuses such as register states of the virtual CPU correlates to wherein the original signal processor entry includes information for the virtual processor), and wherein selected information is accessible from the original signal processor entry rather than the shadow signal processor entry (Paragraph 131, “When the CPU control module 12 has completed the read from the guest VMCS 22, the CPU control module 12 starts the shadow VMCS reference/update module 123. The shadow VMCS reference/update module 123 writes the information in the guest VMCS 22 read by the state area selection module 121 to the guest-state area 131 of the shadow VMCS #0 corresponding to the virtual CPU 108a, which is subject to the process of the VM-exit, thereby updating the shadow VMCS.” The shadow VMCS reference/update module identifying information in the guest VMCS state area to be written to the shadow VMCS guest-state area would involve identifying information in the guest VMCS that is not identical to the current information in the shadow VMCS. Therefore, there would be at least a point in time prior to the update module running in which the guest VMCS state area includes information that is not in the shadow VMCS which correlates to wherein selected information is accessible from the original signal processor entry rather than the shadow signal processor entry).
Therefore, it would have been obvious to one of ordinary skill in the art to which said subject matter pertains before the effective filing date of the claimed invention to combine Tallman with wherein the original signal processor entry and the shadow signal processor entry include information for the virtual processor, and wherein selected information is accessible from the original signal processor entry rather than the shadow signal processor entry as taught by Moriki because shadow VMCS can be used to coordinate operations in switching from modes such as VMX root mode to a VMX non-root mode, where the shadow VMCS is updated with the guest VMCS information during a process of a VM exit. Information read from the shadow VMCS’s guest-state area can be used to start the VM entry instruction and resume execution following the switch in operation mode. VM-entry instructions can update only the fields having dirty states in the update bitmap to quickly update the guest-state area of a shadow VMCS with the read information of the guest VMCS guest-state area (Moriki: paragraphs 131-133 and 147).
With regards to Claims 13 and 19, the manufacture of Claim 4 performs the same steps as the machine and method of Claims 13 and 19 respectively, and Claims 13 and 19 are therefore rejected using the same rationale set forth above in the rejection of Claim 4.
With regards to claim 24, Tallman in view of Osisek teaches the manufacture of claim 23 above. Tallman in view of Osisek does not explicitly teach:
wherein the shadow control structure is a control structure selected from set of control structures, the set of control structures including a shadow state description of the virtual processor and a shadow system control area of the virtual processor, and wherein the original control structure is another control structure selected from another set of control structures, the another set of control structures including an original state description of the virtual processor and an original system control area of the virtual processor.
However, Moriki teaches:
wherein the shadow control structure is a control structure selected from set of control structures, the set of control structures including a shadow state description of the virtual processor and a shadow system control area of the virtual processor (Paragraphs 91-92 and 134, “Each of the shadow VMCSs 130 includes a guest-state area 131, a host-state area 132, a VM-execution control field 133, a VM-exit control field 134, a VM-entry control field 135, and a VM-exit information field 136. As illustrated in FIG. 4, the guest-state area 131 stores statuses such as register states and non-register states of the virtual CPUs 108a to 108n... When the physical CPU 104 receives the VM-entry instruction, the physical CPU 104 reads the guest-state area 131 of the shadow VMCS #0 pointed by the pointer 115, and executes the guest VMM 109 or the user program 110a of the virtual server 102a selected by the state area selection module 121.” The shadow VMCS correlates to a shadow system control area. Each virtual CPU status stored in the guest-state area correlates wherein the shadow control structure is a control structure selected from set of control structures, the set of control structures including a shadow system control area of the virtual processor. The pointer pointing to a particular guest-state area of the shadow VMCS, which stores statuses of virtual CPUs, correlates to wherein the shadow control structure is a control structure selected from set of control structures, the set of control structures including a shadow state description of the virtual processor), and wherein the original control structure is another control structure selected from another set of control structures, the another set of control structures including an original state description of the virtual processor and an original system control area of the virtual processor (Paragraphs 110-111, “On the other hand, the virtual CPU control data 114 managed by the guest VMM 109 of the virtual server 102a stores the guest VMCS 22 having the same data structure as the shadow VMCS #0 of the above-mentioned physical CPU control data 13. The guest VMM 109 includes the guest-state area 221 for storing statuses such as register states of the virtual CPU 108a executing the user program 110a (grandchild OS 111a or application program 112a),” The guest VMCS correlates to the another set of control structures including an original system control area. The guest-state area in the guest VMCS storing statuses of the virtual CPU correlates to wherein the original control structure is another control structure selected from another set of control structures, the another set of control structures including an original state description of the virtual processor).
Therefore, it would have been obvious to one of ordinary skill in the art to which said subject matter pertains before the effective filing date of the claimed invention to combine Tallman with wherein the shadow control structure is a control structure selected from set of control structures, the set of control structures including a shadow state description of the virtual processor and a shadow system control area of the virtual processor, and wherein the original control structure is another control structure selected from another set of control structures, the another set of control structures including an original state description of the virtual processor and an original system control area of the virtual processor as taught by Moriki because shadow VMCS can be used to coordinate operations in switching from modes such as VMX root mode to a VMX non-root mode, where the shadow VMCS is updated with the guest VMCS information during a process of a VM exit. Information read from the shadow VMCS’s guest-state area can be used to start the VM entry instruction and resume execution following the switch in operation mode. VM-entry instructions can update only the fields having dirty states in the update bitmap to quickly update the guest-state area of a shadow VMCS with the read information of the guest VMCS guest-state area (Moriki: paragraphs 131-133 and 147).
Claim(s) 5-6, 10, 14-15 and 20-21 are rejected under 35 U.S.C. 103 as being unpatentable over Tallman in view of Osisek and Bradbury et al. (U.S. Publication No. US 20150277913 A1), hereinafter “Bradbury.”
With regards to claim 5, Tallman in view of Osisek teaches the manufacture of claim 1 above. Tallman in view of Osisek does not explicitly teach:
wherein the order code includes obtaining a sense running status of the virtual processor that specifies whether the virtual processor is running.
However, Bradbury teaches:
wherein the order code includes obtaining a sense running status of the virtual processor that specifies whether the virtual processor is running (Paragraphs 63 and 65, “A number of signal processor orders can provide orders to CPUs including, for example, start, stop, restart, stop and store status, initial CPU reset, CPU reset, store status at address, set architecture, sense running status, set multithreading, store additional status at address, and the like… A sense running status order can indicate whether an addressed CPU is running.” The signal processor order including a sense running status, which indicates whether an addressed CPU is running, correlates to wherein the order code includes obtaining a sense running status of the virtual processor that specifies whether the virtual processor is running).
Therefore, it would have been obvious to one of ordinary skill in the art to which said subject matter pertains before the effective filing date of the claimed invention to combine Tallman with wherein the order code includes obtaining a sense running status of the virtual processor that specifies whether the virtual processor is running as taught by Bradbury because various signal processor orders can provide orders to CPUs such as start, stop, restart, stop and store status, initial CPU reset, CPU reset, store status at address, set architecture, sense running status, set multithreading, store additional status at address, and the like. CPU resets can be initiated using signal processor instructions which do not affect the architectural mode or other CPUs, disable multithreading, or cause the I/O to be reset (Bradbury: paragraph 63).
With regards to Claims 14 and 20, the manufacture of Claim 5 performs the same steps as the machine and method of Claims 14 and 20 respectively, and Claims 14 and 20 are therefore rejected using the same rationale set forth above in the rejection of Claim 5.
With regards to claim 6, Tallman in view of Osisek and Bradbury teaches the manufacture of claim 1 above. Bradbury further teaches:
wherein the order code includes an external call external interruption (Paragraph 55, “A CPU is designated by specifying this address in a CPU-address field of a SIGP instruction. A CPU signaling a malfunction alert, emergency signal, or external call can be identified by storing this address in the CPU-address field with the interruption.” The signal processing instruction (SIGP) correlates to the order code. The CPU signaling an external call being identified by the CPU-address field of an SIGP interruption correlates to wherein the order code includes an external call external interruption).
Therefore, it would have been obvious to one of ordinary skill in the art to which said subject matter pertains before the effective filing date of the claimed invention to combine Tallman with wherein the order code includes an external call external interruption as taught by Bradbury because CPUs can signal a malfunction alert, emergency signal, or external call and be identified through a CPU-address field in an interruption from a SIGP instruction. This CPU address does not change from reconfiguration and allows a CPU to be identified in a multiprocessing configuration (Bradbury: paragraph 55).
With regards to Claims 15 and 21, the manufacture of Claim 6 performs the same steps as the machine and method of Claims 15 and 21 respectively, and Claims 15 and 21 are therefore rejected using the same rationale set forth above in the rejection of Claim 6.
With regards to claim 10, Tallman in view of Osisek teaches the manufacture of claim 1 above. Tallman in view of Osisek does not explicitly teach:
wherein the obtaining the order code includes obtaining the order code based on execution of a signal processor instruction by another virtual processor, the signal processor instruction specifying the order code and the virtual processor.
However, Bradbury teaches:
wherein the obtaining the order code includes obtaining the order code based on execution of a signal processor instruction by another virtual processor, the signal processor instruction specifying the order code and the virtual processor (Paragraphs 53, 55, 63, “If multithreading is enabled when an initial CPU reset is caused by activation of the load-normal or load-with-dump key, the initial-CPU-reset functions can be performed for the lowest-numbered CPU of a core, and the CPU reset is performed for all other CPUs in the core… In exemplary embodiments, each CPU has a number assigned, called its CPU address. A CPU address uniquely identifies one CPU within a configuration. A CPU is designated by specifying this address in a CPU-address field of a SIGP instruction… A number of signal processor orders can provide orders to CPUs including, for example, start, stop, restart, stop and store status, initial CPU reset, CPU reset, store status at address, set architecture, sense running status, set multithreading, store additional status at address, and the like.” The signal processing order including orders such as start, stop, and initial CPU reset correlates to signal processor instruction specifying the order code. The SIGP instruction including a CPU address field uniquely identifying a CPU correlates to the signal processor instruction specifying the virtual processor. The initial CPU reset function being performed for the lowest-numbered CPU of a core and all other CPUs in the core would involve passing the SIGP instruction with the initial CPU reset order to the other CPUs and therefore correlates to wherein the obtaining the order code includes obtaining the order code based on execution of a signal processor instruction by another virtual processor).
Therefore, it would have been obvious to one of ordinary skill in the art to which said subject matter pertains before the effective filing date of the claimed invention to combine Tallman with wherein the obtaining the order code includes obtaining the order code based on execution of a signal processor instruction by another virtual processor, the signal processor instruction specifying the order code and the virtual processor as taught by Bradbury because CPUs can signal a malfunction alert, emergency signal, or external call and be identified through a CPU-address field in an interruption from a SIGP instruction. This CPU address does not change from reconfiguration and allows a CPU to be identified in a multiprocessing configuration. Initial CPU resets provide functions of a CPU reset together with initialization of the current PSW, CPU timer, clock comparator, and other registers, and can set the architectural mode to the default mode if it is caused by activation of the load-normal or load-with-dump key. In multithreading scenarios, the initial-CPU-reset functions can be performed for the lowest-numbered CPU of a core, and the CPU reset is performed for all other CPUs in the core (Bradbury: paragraphs 53-55).
Prior Art Made of Record
The prior art made of record and not relied upon is considered pertinent to applicant’s disclosure.
Hattori et al. (U.S. Publication No. US 20110197190 A1); teaching a method of a virtual machine manager enabling a shadowing function when an instruction for enabling the shadowing function caused the call. The shadowing setting stores information for controlling the shadowing function, such as information indicating whether or not to enable the shadowing function for manipulating the privilege register and information about shadow data to be read when the shadowing function is enabled. The shadowing setting further stores a shadowing function setting table and shadow data setting tables, which contain shadow data names and shadow data addresses.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SELINA HU whose telephone number is (571)272-5428. The examiner can normally be reached Monday-Friday 8:30-5:30.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Chat Do can be reached at (571) 272-3721. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
The publicPAIR and privatePAIR systems are no longer available. 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.
SELINA HU
Examiner
Art Unit 2193
/Chat C Do/Supervisory Patent Examiner, Art Unit 2193
Prosecution Insights