DETAILED ACTION
Claims 1-20 are pending in this application.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Objections
Claims 1-20 are objected to because of the following informalities:
Claims 1 and 20 includes typographical error. Specifically, “a caller” occurs twice in this claims. The second occurrence should be “the caller” instead since both occurrence of caller refers to a caller for the second virtual machine.
Claim 11 includes the term “the number of providers of services”.
Appropriate correction is required, for instance, “a number of providers of services”.
Claims 18 and 19 include the term “second virtual processor”, which appears to have been used in error.
Appropriate correction is required, for instance, the “second virtual processor” should be replaced with “second virtual machine”.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1, 2, 5, 6, 16, 17 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over W.O. No. 2015103374 A1 to Ahmed et al. in view of U.S. Pat. No. 8,271,996 B1 issued to Gould et al.
As to claim 1, Ahmed teaches a signal processing device comprising a processor (multi-core processor) configured to perform signal processing for a display located in a vehicle (vehicle user interface (e.g., display or displays and user input devices)) (“…According to an exemplary embodiment, automobile 1 includes a computer system for integration with a vehicle user interface (e.g., display or displays and user input devices) and includes a processing system. The processing system may include a multi-core processor. The processing system may be configured to provide virtualization for a first guest operating system in a first core or cores of the multi-core processor. The processing system may also be configured to provide virtualization for a second guest operating system in a second and different core or cores of the multi-core processor (i.e., any core not allocated to the first guest operating system). The first guest operating system may be configured for high reliability operation. The virtualization prevents operations of the second guest operating system from disrupting the high reliability operation of the first guest operating system…” paragraph 0043), and
wherein the processor is configured to execute a plurality of virtual machines on a hypervisor in the processor (Hypervisor 402), and a first virtual machine (first guest operating system/Domains 408-414/Domain 901-909) and a second virtual machine (second guest operating system/Domains 408-414/Domain 901-909) among the plurality of virtual machines share an mutual sharing area for a remote procedure call (RPC Endpoint 922) in a shared memory (Shared memory 424/916) of the hypervisor (“…According to an exemplary embodiment, automobile 1 includes a computer system for integration with a vehicle user interface (e.g., display or displays and user input devices) and includes a processing system. The processing system may include a multi-core processor. The processing system may be configured to provide virtualization for a first guest operating system in a first core or cores of the multi-core processor. The processing system may also be configured to provide virtualization for a second guest operating system in a second and different core or cores of the multi-core processor (i.e., any core not allocated to the first guest operating system). The first guest operating system may be configured for high reliability operation. The virtualization prevents operations of the second guest operating system from disrupting the high reliability operation of the first guest operating system…Multi-core processing environment 400 is shown to include a hypervisor 402. Hypervisor 402 may be integrated with a bootloader or work in conjunction with the bootloader to help create the multi-core processing environment 400 during boot. The system firmware (not shown) can start the bootloader (e.g., U-Boot) using a first CPU core (core 0). The bootloader can load the kernel images and device trees from a boot partition for the guest OSs. Hypervisor 402 can then initialize the data structures used for the guest OS that will run on core 1. Hypervisor 402 can then boot the guest OS for core 1. Hypervisor 402 can then switch to a hypervisor mode, initialize hypervisor registers, and hand control over to a guest kernel. On core 0, hypervisor 402 can then do the same for the guest that will run on core 0 (i.e., initialize the data structures for the guest, switch to the hypervisor mode, initialize hypervisor registers, and hand off control to the guest kernel for core 0). After bootup, the distinction between a primary core and a secondary core may be ignored and hypervisor 402 may treat the two cores equally. Traps may be handled on the same core as the guest that triggered them… In FIG. 4, multi-core processing environment 400 is shown in a state after setup is conducted by hypervisor 402 and after the guest OSs are booted up to provide domains 408- 414. Domains 408-414 can each be responsible for outputting certain areas or windows of a display system such as cluster display 426. In some embodiments, cluster display 426 may be an ICD. Cluster display 426 is illustrated as having display areas A and B. High reliability domain 408 may be associated with display areas A. Display areas A may be used to display safety-critical information such as vehicle speed, engine status, vehicle alerts, tire status, or other information from the ECU. The information for display areas A may be provided entirely by domain 408. Display area B may represent a music player application user interface provided by display output generated by infotainment core 410. Cloud domain 414 may provide an internet-based weather application user interface in display area B. Advantageously, system instability, crashes, or other unexpected problems, which may exist in the cloud domain 414 or with the music player running in infotainment core 410, may be completely prevented from impacting or interrupting the operation of display area A or any other process provided by the high reliability domain 408… CPU components 902-916 are shown to include a communication layer 914 and GPU components 918-942 are shown to include a communication layer 918. Communications layers 914 and 918 may be configured to communicated with a shared memory 916 and/or using Internet protocols such as TCP/IP or UDP. Communication layers 914, 918 may be configured to communicate with shared memory 916 to send and receive tasks stored in memory 916…” paragraphs 0043/0077/0135).
Ahmed is silent with reference to wherein the first virtual machine is configured to execute a callee, which receives data in response to a caller of the second virtual machine, and a first call interface for access to the mutual sharing area, and
wherein the second virtual machine is configured to execute a caller for the remote procedure call and a second call interface for access to the mutual sharing area, and wherein the first call interface or the second call interface is configured to register or delete a remote procedure call service.
Gould teaches wherein the first virtual machine is configured to execute a callee (container consumers), which receives data in response to a caller of the second virtual machine (container producers), and a first call interface for access to the mutual sharing area (event queue facility), and
wherein the second virtual machine is configured to execute a caller for the remote procedure call (remote procedure call (RPC) facility/RPC mechanism and facility) and a second call interface for access to the mutual sharing area (an inter-container (e.g inter address space) event queue facility) (“…Described in following paragraphs is an API that may be used in connection with an inter-container (e.g inter address space) event queue facility where the producers and consumers of the events may execute in user space or kernel space. That is, each producer may execute in user mode or kernel mode and each consumer may execute in user mode or kernel mode. In one embodiment described herein, the structures 210 for implementing the event queue may be kernel resident and calls between user space and kernel space (including calls made by code of the event queue facility and API described herein) may be facilitated using another facility, remote procedure call (RPC) facility, where a first code module in a first container makes a remote procedure call to a second container. An RPC API may be utilized as described in U.S. patent application Ser. No. 12/286,433, filed on Sep. 29, 2008, REMOTE PROCEDURE CALLS, ("RPC patent application"), which is incorporated by reference herein. The RPC mechanism and facility described in the RPC patent application includes an API with a client interface and a server interface for performing inter-container calls. In accordance with the techniques herein, the RPC mechanism and facility described in the RPC patent application may be utilized in an embodiment in connection with U-K communications, for example, where a container, such as a consumer container or producer container of events, executes in user mode in order to access the event queue structures as needed for different event queue processing operations. This is described in more detail in following paragraphs…” Col. 12 Ln. 57-67, Col. 13 Ln. 1-17), and wherein the first call interface or the second call interface is configured to register (register_event API) or delete a remote procedure call service (unregister_event API) (“…Referring to FIG. 5, shown is an example of register_event and unregister_event APIs that may be used included in an embodiment of an event queue API. Element 380 describes the register_event API and element 390 describes the unregister_event API. As illustrated in 380, the register_event API may include the following parameters:…reference--input parameter specifying a reference value returned from a previous open API call; and…event--input parameter identifying the event for which the reference, as may be used by a consumer container, is being registered…The register API may be used by a consumer to register for a specific event identified by the event parameter. The event parameter may identify the event for which the consumer container is to be notified. The event parameter may be a value, structure, and the like, identifying the particular event. Upon occurrence of an event matching the event parameter, a notification is added to the event notification list identified by the reference parameter. Consumers may register for any number of different events. When a producer adds an event to an event queue (via add_events API call described below), every consumer that has registered for that event receives a copy of the event as notification by placing the notification on the notification list included in the consumer's reference along with any optional additional private data copied to the consumer's ring buffer…As illustrated in 390, the unregister_event API may be used by a consumer to unregister for a specific event identified by the event parameter. Once an event has been unregistered, the consumer no longer receives copies of notifications for that event type in the consumer's ring buffer (as associated with the consumer's reference structure)…A container which is a consumer of events may execute the APIs of FIG. 5 in order to register and unregister regarding particular events for an event queue…” Col. 17 Ln. 25-56).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claim invention to modify the system of Ahmed with the teaching of Gould because the teaching of Gould would improve the system of Ahmed by providing a RPC software communication protocol that allows one program to request a service or execute a function from another program on a different computer, without needing to understand the underlying network details.
As to claim 2., Gould teaches the signal processing device of claim 1, wherein the second virtual machine is configured to write call-related information to the mutual sharing area (add_events API call) and notify the information to the first virtual machine (notification), wherein the first virtual machine is configured to receive data in the mutual sharing area (every consumer that has registered for that event receives a copy of the event as notification) (“…The register API may be used by a consumer to register for a specific event identified by the event parameter. The event parameter may identify the event for which the consumer container is to be notified. The event parameter may be a value, structure, and the like, identifying the particular event. Upon occurrence of an event matching the event parameter, a notification is added to the event notification list identified by the reference parameter. Consumers may register for any number of different events. When a producer adds an event to an event queue (via add_events API call described below), every consumer that has registered for that event receives a copy of the event as notification by placing the notification on the notification list included in the consumer's reference along with any optional additional private data copied to the consumer's ring buffer…” Col. 17 Ln. 36-50).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claim invention to modify the system of Ahmed with the teaching of Gould because the teaching of Gould would improve the system of Ahmed by providing a technique for notifying event consumers of the availability of events in an event queue.
As to claim 5, Gould teaches the signal processing device of claim 1, wherein: in response to parameter data transmitted from the caller, the second call interface is configured to copy the parameter data (Data Portion/Data Area 772) and meta data to the mutual sharing area (Header 770) (“… Referring to FIG. 12, shown is an example illustrating in more detail an event ring buffer structure that may be used in an embodiment in accordance with techniques herein. The example 750 illustrates element 722 in more detail. The example 750 may include a header portion 770 with ring buffer metadata and a data portion or data area 772 including the ring buffer data (e.g., event notifications). The header 770 may include a producer (P) index 752, a consumer (C) index 754, number of list entries 756 and private data size 758. Element 752 may indicate the ring buffer index of the next event notification entry for use by the producer. If the event notification list (e.g., ring buffer) is not full (e.g., has available or free entries), element 752 may indicate the next free entry; otherwise element 752 may indicate the next entry to be used by a producer (in accordance with the qfull policy described elsewhere herein) where the next entry currently contains an unconsumed notification. Element 754 may indicate the ring buffer index of the next event notification in the list for a consumer to consume if the event notification list is not empty. If the event notification list is empty, element 754 may indicate an empty entry or an event notification that has already been consumed. Element 756 may indicate a maximum number of entries in the ring buffer (e.g., maximum number denoting the ring buffer notification capacity). Element 758 may indicate an amount of private data used for storing private data for a single event notification. Each event notification may be included in a portion of storage of 772 as illustrated…” Col. 22 Ln. 29-56); and in response to a pointer parameter, the second call interface is configured to transmit data, corresponding to the pointer, to a call storage area in the shared memory (“…private_data--input parameter that is a pointer to a private data area for the events added…The add_events API may be used by a producer to add one or more events to an event queue. The producer may specify one or more events (as specified using the num_events and events[ ] parameters) and may include a pointer to a contiguous private data area (private_data parameter) containing the private data associated with those events...” Col. 18 Ln. 3-4, 13-18).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claim invention to modify the system of Ahmed with the teaching of Gould because the teaching of Gould would improve the system of Ahmed by providing a technique for notifying event consumers of the availability of events in an event queue.
As to claim 6, Gould teaches the signal processing device of claim 1, wherein the first call interface or the second call interface is configured to generate or manage a control page in the shared memory or generate or manage the mutual sharing area (register_event API/unregister_event API) (“…Referring to FIG. 5, shown is an example of register_event and unregister_event APIs that may be used included in an embodiment of an event queue API. Element 380 describes the register_event API and element 390 describes the unregister_event API. As illustrated in 380, the register_event API may include the following parameters:…reference--input parameter specifying a reference value returned from a previous open API call; and…event--input parameter identifying the event for which the reference, as may be used by a consumer container, is being registered…The register API may be used by a consumer to register for a specific event identified by the event parameter. The event parameter may identify the event for which the consumer container is to be notified. The event parameter may be a value, structure, and the like, identifying the particular event. Upon occurrence of an event matching the event parameter, a notification is added to the event notification list identified by the reference parameter. Consumers may register for any number of different events. When a producer adds an event to an event queue (via add_events API call described below), every consumer that has registered for that event receives a copy of the event as notification by placing the notification on the notification list included in the consumer's reference along with any optional additional private data copied to the consumer's ring buffer…As illustrated in 390, the unregister_event API may be used by a consumer to unregister for a specific event identified by the event parameter. Once an event has been unregistered, the consumer no longer receives copies of notifications for that event type in the consumer's ring buffer (as associated with the consumer's reference structure)…A container which is a consumer of events may execute the APIs of FIG. 5 in order to register and unregister regarding particular events for an event queue…” Col. 17 Ln. 25-56).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claim invention to modify the system of Ahmed with the teaching of Gould because the teaching of Gould would improve the system of Ahmed by providing a technique for reclaiming computing resources for later use.
As to claim 16, Ahmed teaches the signal processing device of claim 1, wherein the first virtual machine (first guest operating system/Domains 408-414/Domain 901-909) is configured to transmit data to the second virtual machine (second guest operating system/Domains 408-414/Domain 901-909) after booting by using the mutual sharing area (Shared memory 424/916).
As to claim 17, Ahmed teaches the signal processing device of claim 1, wherein the first virtual machine is configured to repeatedly receive sensing data, and transmit the sensing data to the second virtual machine by using the mutual sharing area (Shared Memory 424) (“…In some embodiments, vehicle control 315 is connected to one or more Local Interconnect Networks (LIN) 317, vehicle sensors 319, and/or Controller Area Networks (CAN) 321. LIN 317 may follow the LIN protocol and allow communication between vehicle components. Vehicle sensors 319 may include sensors for determining vehicle telemetry. For example, vehicle sensors 319 may be one or more of gyroscopes, accelerometers, three dimensional accelerometers, inclinometers, etc. CAN 321 may be connected to vehicle control 315 by a CAN bus. CAN 321 may control or receive feedback from sensors within the vehicle. CAN 321 may also be in communication with electronic control units of the vehicle. In other embodiments, the functions of vehicle control 315 may be implemented by multi-core processing environment 400. For example, vehicle control 315 may be omitted and multi-core processing environment 400 may connect directly to LIN 317, vehicle sensors 319, CAN 321, or other components of a vehicle…” paragraph 0057).
As to claim 20, see the rejection of claim 20 above.
Claim 3 is rejected under 35 U.S.C. 103 as being unpatentable over W.O. No. 2015103374 A1 to Ahmed et al. in view of U.S. Pat. No. 8,271,996 B1 issued to Gould et al. as applied to claim 2 above, and further in view of U.S. Pub. No. 2020/0136966 A1 to Mishra.
As to claim 3, Ahmed as modified by Gould teaches the signal processing device of claim 2, however it is silent with reference to wherein the first virtual machine is configured to write result data, processed based on the received data, to the mutual sharing area, and notify the result data to the second virtual machine, wherein the second virtual machine is configured to receive the result data written to the mutual sharing area.
Mishra teaches wherein the first virtual machine (Service Virtual Machine 130) is configured to write result data (return a result), processed based on the received data, to the mutual sharing area, and notify (notify) the result data to the second virtual machine (Service Virtual Machine 130), wherein the second virtual machine is configured to receive the result data written to the mutual sharing area (Shared Memory 113) (… If a service machine is service virtual machine 130A, as described in FIG. 1 and shown in FIG. 2A, then, upon determining that a packet requires a service from service virtual machine 130A, service insertion module 111A may use a shared memory mechanism to pass the packet to the service virtual machine. In this case, service insertion module 11A stores the packet in shared memory 113E, which may be shared between service virtual machine 130A and other service virtual machines (not shown). Service virtual machine 130A may detect the packet in shared memory 113E, apply one or more services to the packet, and return a result of the servicing to shared memory 113A and/or notify service insertion module 111A…” paragraph 0038).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claim invention to modify the system of Ahmed and Gould with the teaching of Mishra because the teaching of Mishra would improve the system of Ahmed and Gould by providing a technique for providing result to a requesting client.
Claim 3 is rejected under 35 U.S.C. 103 as being unpatentable over W.O. No. 2015103374 A1 to Ahmed et al. in view of U.S. Pat. No. 8,271,996 B1 issued to Gould et al. as applied to claim 2 above, and further in view of R.U. Pub. No. 2008105660 A to Mbicob et al.
As to claim 3, Ahmed as modified by Gould teaches the signal processing device of claim 2, however it is silent with reference to wherein the first virtual machine is configured to write result data, processed based on the received data, to the mutual sharing area, and notify the result data to the second virtual machine, wherein the second virtual machine is configured to receive the result data written to the mutual sharing area.
Mbicob teaches wherein the first virtual machine (Virtual Machines) is configured to write result data (sending the result), processed based on the received data, to the mutual sharing area, and notify (sending client notifications) the result data to the second virtual machine (Virtual Machines), wherein the second virtual machine is configured to receive the result data written to the mutual sharing area (shared memory) (… MTD virtualization system associated with a hardware-based computer platform with MTD support and running under VMM, on which a VM is installed, containing the server part of the virtual MTD driver and a physical MTD driver associated with MTD, and characterized in that the MTD virtualization system further comprises at least one VM containing the client part of the virtual MTD driver, the client and server parts of the virtual MTD driver being interconnected via shared memory of virtual machines, the server part of the virtual The MTD driver is associated with the physical MTD driver, and the client VM contains the file system and is configured to receive information about the physical partitions of the MTD from the server side of the virtual MTD driver and then register the virtual partitions in the file system, accessed by the file system, creates a chain sending requests to the server part of the virtual MTD driver, which includes entering the client part of the virtual MTD driver data into shared memory, sending a notification in the form of a virtual interrupt the server part of the virtual MTD driver, waiting for a response from the server part of the virtual MTD driver and then sending the result to the file system, and the server part of the virtual MTD driver, using the shared memory and virtual interrupt mechanism provided by VMM, is capable of receiving information contained in the request from shared memory, transferring this information to the physical MTD driver, recording the result received from the physical MTD driver into shared memory, sending client notifications the second part of the virtual MTD driver and then it goes into sleep mode a new request from the client-side virtual MTD driver.…” claim 1).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claim invention to modify the system of Ahmed and Gould with the teaching of Mbicob because the teaching of Mbicob would improve the system of Ahmed and Gould by providing a technique for providing result to a requesting client.
Claim 4 is rejected under 35 U.S.C. 103 as being unpatentable over W.O. No. 2015103374 A1 to Ahmed et al. in view of U.S. Pat. No. 8,271,996 B1 issued to Gould et al. as applied to claim 2 above, and further in view of U.S. Pub. No. 11,615,082 B1 issued to Shrigondekar et al.
As to claim 4, Ahmed as modified by Gould teaches the signal processing device of claim 1, however it is silent with reference to wherein the first virtual machine or the second virtual machine is configured to store data, having a size exceeding a capacity of the mutual sharing area, in a separate area of the shared memory.
Shrigondekar teaches wherein the first application or the second application (Ingestors 252) is configured to store data, having a size exceeding a capacity of the mutual sharing area (larger messages or larger groups of events), in a separate area of the shared memory (Data Store 258) (“…The data store 258 can be used to store larger messages or larger groups of events received from the ingestors 252. In some cases, the size of a message or size of the group of events (in the aggregate) may exceed a message size limit of the message queue 256. For example, the message queue 256 may only have capacity for or be configured to process messages that are no larger than 256 kb. If the group of events (or message payload) for a message exceeds that size alone or in combination with other message data (e.g., a message header) then the ingestor 252 can store the group of events (or message payload) to the data store 258 and obtain a location reference to the group of events. The ingestor 252 can send the location reference to the message queue 256…” Col. 20. Ln. 24-36).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claim invention to modify the system of Ahmed and Gould with the teaching of Shrigondekar because the teaching of Shrigondekar would improve the system of Ahmed and Gould by providing a technique for communicating messages between at least two components without considering the size of the message (no size limit).
Claim 7 is rejected under 35 U.S.C. 103 as being unpatentable over W.O. No. 2015103374 A1 to Ahmed et al. in view of U.S. Pat. No. 8,271,996 B1 issued to Gould et al. as applied to claim 1 above, and further in view of U.S. Pub. No. 20190385078 A1 to Cui et al. and further in view of W.O. No. 2007088581 A1 to Suzuki.
As to claim 7, Ahmed as modified by Gould teaches the signal processing device of claim 1, however it is silent with reference to wherein the first call interface or the second call interface is configured to generate or delete a remote procedure call channel including the mutual sharing area and the call storage area.
Cui teaches wherein the first call interface or the second call interface is configured to generate or delete a remote procedure call channel (a remote procedure call (RPC) channel is created) (“…The clients 102, 104 and 106 expose a virtual dedicated processor interface (not shown in FIG. 1) to a user. When an application program on the clients 102, 104 and 106 requests for calling the virtual dedicated processor interface, a remote procedure call (RPC) channel is created between the clients 102, 104 and 106 and the server 108. The created RPC channel is used to transmit commands representing a dedicated processor function. For example, these commands can include duplicating data on the clients 102, 104 and 106 onto the dedicated processors 110 and 112, running the dedicated processor function, duplicating data on the dedicated processors 110 and 112 onto the clients 102, 104 and 106, and the like…” paragraph 0023).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claim invention to modify the system of Ahmed and Gould with the teaching of Cui because the teaching of Cui would improve the system of Ahmed by providing a technique for reclaiming computing resources for later and optimal use.
Suzuki teaches a remote procedure call channel including the mutual sharing area (Shared Memory 24) and the call storage area (Address Spaces 25/26) (“…FIG. 1 is a schematic diagram showing the concept of a procedure call method in a shared memory type multiprocessor according to the present invention. As shown in Figure 1, in the same machine (computer) 21 The provided first processor 22 and second processor 23 physically share the same shared memory 24. In the shared memory 24, the address space 25 managed by the first processor 22 and the address space 26 managed by the second processor 23 are independent…In this configuration, a procedure call can be performed between the first processor 22 and the second processor 23 by applying the remote procedure call method. At that time, it is not necessary to abstract the memory address with an identifier as in the conventional remote procedure calling method. Therefore, the first processor 22 designates the address of the address space 26 managed by the second processor 23 and makes a remote procedure call via the interprocessor communication 27. By using the bus as the interprocessor communication 27, the communication speed between the processors can be increased as well as the procedure call at a short distance…”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claim invention to modify the system of Ahmed, Gould and Cui with the teaching of Suzuki because the teaching of Suzuki would improve the system of Ahmed, Gould and Cui by providing a technique for tracking addresses to adequately write to or read from a shared memory.
Allowable Subject Matter
Claims 8-15, 18 and 19 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Reasons for allowance
The following is an examiner’s statement of reasons for allowance:
The closest prior art of records, (W.O. No. 2015103374 A1 to Ahmed et al. and U.S. Pat. No. 8,271,996 B1 issued to Gould et al.), taken alone or in combination do not specifically disclose or suggest the claimed recitations (claims 8-15, 18 and 19), when taken in the context of claims as a whole.
Any comments considered necessary by applicant must be submitted no later than the payment of the issue fee and, to avoid processing delays, should preferably accompany the issue fee. Such submissions should be clearly labeled “Comments on Statement of Reasons for Allowance.”
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
U.S. Pub. No. 2015/0012973 A1 to Derrin et al. and directed to methods and apparatus for sharing a service between multiple virtual machines (pp 44-47) + shared memory
C.N. No. 107491354 A Tang and directed to a shared memory-based inter-virtual machine communication method.
U.S. Pat. No. 8,261,268 B1 issued to Forgette and directed to systems and methods for automatic and dynamic virtual machine (VM) allocation for allocating a plurality of VMs to a plurality of servers in a virtual server environment.
U.S. Pub. No. 2020/0219469 A1 to Mittal et al and directed to a system for outputting to a dashboard screen for a vehicle from a plurality of operating systems.
U.S. No. 2015/0012918 A1 to Derrin et al. and directed to methods and apparatus for sharing a physical device between multiple virtual machines.
U.S. Pat. No. 8,739,177 B2 issued to Qian et al. and directed to multiple VMs launchable and executed concurrently, including at least two kinds of VMs, one kind of VM is a Service VM running a Service OS (SOS). The Service OS generally provides services to other OSs running in other VMs, and interacts with VMM to provide those services. A second kind of VM is a Consumer OS (COS) (also called a Guest OS) running in a Consumer VM. The Consumer OS supports application programs interacting with a user of the computing system. The Consumer OS relies on services provided by VMM and Service. Application programs running within a Consumer VM cannot directly interact with the Service OS running in the Service VM. However they interact using a buffer service.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CHARLES E ANYA whose telephone number is (571)272-3757. The examiner can normally be reached Mon-Fir. 9-6pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, KEVIN YOUNG can be reached at 571-270-3180. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/CHARLES E ANYA/Primary Examiner, Art Unit 2194
Prosecution Insights