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 .
DETAILED ACTION
Claims 1-15 are presented for examination.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale or otherwise available to the public before the effective filing date of the claimed invention.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1,2,4,5,13 and 14 are rejected under 35 U.S.C. 102(a)(1) as anticipated by Poess (US 2021/0073147 A1)
As per claim 1, Poess teaches A method of operating a microkernel-based operating system, the method comprising:
operating the microkernel-based operating system in a first criticality mode of a plurality of supported criticality modes; (Poess Fig 2 and [0013] In particular embodiments, to limit the scope of an attack in the example architecture, it may be necessary to further isolate services at a more granular level. To do so, services may be separated out into different levels on top of the micro-kernel. As an example, on top of the micro-kernel, there may be a level of privileged services (e.g., service registry, launcher, loader, etc.), driver services (e.g., driver block, USB, PCI), protocol services (e.g., volume services, network services, etc.), application services (e.g., K/V store, event service, etc.), and applications. All of these may be isolated processes that can only communicate with each other with the help of the micro-kernel [0015] Referring to FIG. 2, another example operating system environment 200 is shown. The operating system environment may comprise an application 102, an application services layer 214, a protocol services layer 216, a driver services layer 218, a privileged services 220, and a microkernel 204. In particular embodiments, the services layers 214, 216, 218, 220 may include services 206, 208, 210, 212 in the user space and the microkernel 204 may be the only component of the operating system environment 200 in the kernel space.).
The examiner is treating this criticality level to be the level in Fig 2 of Poess that is operating at any point in time. For example when the application (level 214 in Fig 2) is requesting communication with any lower level (example level 218 drivers), the microkernel (Block 204) is running the application and is operating at that level.
determining a condition that requires a transition to a second criticality mode of the plurality of supported criticality modes; (Poess [0017] In particular embodiments, the services 206, 208, 210, 212 may only communicate with certain services 206, 208, 210, 212. As an example and not by way of limitation, a service 206 of the application services layer 214 may only send a system call to the microkernel 204 to request to communicate with a driver service 210 of the driver services layer 218. However, the application service 210 may be restricted in communicating with a privileged service 212 of the privileged services layer 220. In particular embodiments [0020] In particular embodiments, the process 300 may start with the application 302 sending a first system call requesting to communicate with the service registry 304 to perform an operation. In particular embodiments, the application 302 may send the system call to a microkernel (not shown) to request a hardware resource to perform an operation, where the microkernel may help facilitate communication by sending the request from the application 302 to the service registry 304. The microkernel may facilitate communication between each of the components 302, 304, 306, 308 of the process 300. In particular embodiments, after the first system call is sent to the microkernel, an instruction 310 may be sent to the service registry 304. As an example and not by way of limitation, the instruction 310 may be a request to access a camera. As another example and not by way of limitation, the instruction 310 may be a request to access a network protocol service. In particular embodiments, the application 302 may identify a particular service it wants to access. Also see Fig 5 Blocks 510 and 550)
adapting settings of the microkernel-based operating system in accordance with the second criticality mode; (Poess [0018] The service registry 212a may map the services 206, 208, 210, 212 in order to identify which service 206, 208, 210, 212 is being requested when an application 102 is requesting to perform an operation. As an example and not by way of limitation, if the application 102 is requesting to take a picture, the application 102 may send a camera operation request (e.g., take a picture) to the service registry 212a. The service registry 212a may determine to send an instruction to a camera service to connect to the application 102. The determination may be based on the mapping where the service registry 212a identifies a service based on the received operation request. Additionally, the service registry 212a may enforce the permissions on whether the application 102 is permitted to access a particular service. If the service registry 212a determines the application 102 is not permitted to access the particular service, the service registry 212a may send back an error message [0021] In particular embodiments, after the service registry 304 receives the instruction 310, the service registry 304 may map the request to a service, such as the camera service 306. The service registry 304 may identify the service that is associated with the requested hardware resource or operation that the application 302 is requesting to perform. In particular embodiments, after the service registry 304 determines the application 302 needs to access a particular service, the service registry 304 may send a system call to the microkernel to request to communicate with the particular service.)
The term “adapting settings” will be interpreted under broadest reasonable standards to be looking up the registry and identifying the service being called (i.e. mapping to it) and deciding whether to grant permission for inter-process communication. This is consistent with what is disclosed in the specification ([0033] In an advantageous embodiment, settings of the microkernel-based operating system that are adapted are related to one or more of scheduling of threads, control and handling of interrupts, handling of exceptions, use of memory, handling of caches, and interprocess communication).
operating the microkernel-based operating system in the second criticality mode. (Poess [0021] The service registry 304 may send a second system call to the microkernel to request to communicate with the network protocol service. In particular embodiments, the service registry 304 may determine whether the application 302 has permission to access a particular service. As an example and not by way of limitation, the service registry 304 may determine that the application 302 has permission to access the camera service 306. The service registry 304 may send the system call to the microkernel in response to determining the application 302 has permission to access the service. In particular embodiments, the service registry 304 may determine the application 302 wants to connect to a particular service, the service registry 304 may send a system call to the microkernel to establish a communication channel between the application 302 and the particular service. As an example and not by way of limitation, the microkernel may send the instruction 312 to the camera service 306 [second criticality mode] to connect to the application 302).
Examiner believes the teachings Poess shown above is consistent with what is disclosed in the specification ([0043] In an advantageous embodiment, interprocess communication is adapted by distinguishing at least between two or more of allowed interprocess communication, forbidden interprocess communication, and limited interprocess communication. Interprocess communication may simply be considered as a special case of interrupt control. For example, different interrupts can be used to distinguish between allowed interprocess communication, forbidden interprocess communication, and limited interprocess communication).
Poes is directed mostly to directed to communication among different level of security (as shown in Fig 2 see abstract which states “The microkemel receives, from at least one of the application service or the protocol service, a third system call requesting to communicate with a driver service”).
As per claim 2, Poess teaches wherein the plurality of supported criticality modes comprises a normal mode and at least one of a safe mode and a trusted mode. (Poess Fig 2 and [0015] Referring to FIG. 2, another example operating system environment 200 is shown. The operating system environment may comprise an application 102, an application services layer 214 [normal mode], a protocol services layer 216, a driver services layer 218 [safe mode], a privileged services 220 [trusted mode], and a microkernel 204. In particular embodiments, the services layers 214, 216, 218, 220 may include services 206, 208, 210, 212 in the user space and the microkernel 204 may be the only component of the operating system environment 200 in the kernel space).
As per claim 4, Poess teaches wherein transitions between the criticality modes are driven by events. (Poess [0020] In particular embodiments, the process 300 may start with the application 302 sending a first system call requesting to communicate with the service registry 304 to perform an operation. In particular embodiments, the application 302 may send the system call to a microkernel (not shown) to request a hardware resource to perform an operation, where the microkernel may help facilitate communication by sending the request from the application 302 to the service registry 304. The microkernel may facilitate communication between each of the components 302, 304, 306, 308 of the process 300. In particular embodiments, after the first system call is sent to the microkernel, an instruction 310 may be sent to the service registry 304. As an example and not by way of limitation, the instruction 310 may be a request to access a camera. As another example and not by way of limitation, the instruction 310 may be a request to access a network protocol service. In particular embodiments, the application 302 may identify a particular service it wants to access).
As per claim 5, Poess teaches wherein events are related to one or more of interrupts, exceptions, completion of threads, and absence of threads to be scheduled. (Poess [0020] In particular embodiments, the process 300 may start with the application 302 sending a first system call requesting to communicate with the service registry 304 to perform an operation. In particular embodiments, the application 302 may send the system call to a microkernel (not shown) to request a hardware resource to perform an operation [example of an interrupt], where the microkernel may help facilitate communication by sending the request from the application 302 to the service registry 304. The microkernel may facilitate communication between each of the components 302, 304, 306, 308 of the process 300. In particular embodiments, after the first system call is sent to the microkernel, an instruction 310 may be sent to the service registry 304. As an example and not by way of limitation, the instruction 310 may be a request to access a camera. As another example and not by way of limitation, the instruction 310 may be a request to access a network protocol service. In particular embodiments, the application 302 may identify a particular service it wants to access).
As to claims 13 and 14, they are rejected based on the same reason as claim 1.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102 of this title, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim 3 is rejected under 35 U.S.C. 103 as being unpatentable over Poess (US 2021/0073147 A1) in view of Seshadri (US 2010/0031360 A1).
As per claim 3, Poess does not teach wherein conditions that define transitions between criticality modes are statically defined by configuration settings of the microkernel-based operating system.
However, Seshadri teaches wherein conditions that define transitions between criticality modes are statically defined by configuration settings of the microkernel-based operating system. (Seshadri [0008] Another aspect of the present invention is directed to a method of maintaining kernel code integrity in an operating system, the method comprising detecting a request that an execution mode be changed to kernel mode at an address, determining whether the address is within approved kernel code, setting the execution mode to kernel mode if the address is within approved kernel code [statically defined], setting an instruction pointer to the address if the address is within approved kernel code, executing instructions in kernel mode as long as the instruction pointer remains within approved kernel code, detecting a request that the execution mode be changed to user mode, and setting the execution mode to user mode upon detection of a request that the execution mode be changed to user mode).
Statically will be taken to be not driven by events. This is consistent with what is disclosed in the specification ([0031] In an advantageous embodiment, conditions that define transitions between criticality modes are statically defined by configuration settings of the microkernel-based operating system. The use of configuration settings, preferably static configuration settings, allows achieving a configurable level of freedom from interference in each criticality mode)
It would have been obvious to a person in the ordinary skill in the art before the effective filing date of the claimed invention to combine Seshadri with the system of Poess to define transitions statically. One having ordinary skill in the art would have been motivated to use Seshadri into the system of Poess for the purpose of using an agent that can maintain the integrity of existing kernels (Seshadri paragraph 04).
Claims 6 and 7 are rejected under 35 U.S.C. 103 as being unpatentable over Poess (US 2021/0073147 A1) in view of Francois (US 9,229,716 B2).
As per claim 6, Poess does not teach wherein settings of the microkernel-based operating system that are adapted are related to one or more of scheduling of threads, control and handling of interrupts, handling of exceptions, use of memory, handling of caches, and interprocess communication.
However, Francois teaches wherein settings of the microkernel-based operating system that are adapted are related to one or more of scheduling of threads, control and handling of interrupts, handling of exceptions, use of memory, handling of caches, and interprocess communication. (Francois [claim 9] ; an operating system controlling access by an executing thread to the processor, the operating system comprising priority logic for controlling a priority boost of the thread, the priority logic configured to: responsive to the thread executing in user mode an instruction to boost a priority of the thread, access a boost register, the boost register accessible only by a kernel of the operating system in kernel mode; determine a value of the boost register, the value indicating a time period that the thread may execute in a boosted priority state; and responsive to determining that the boost register holds a non-zero value, boost the priority of the thread).
It would have been obvious to a person in the ordinary skill in the art before the effective filing date of the claimed invention to combine Francois with the system of Poess to schedule threads. One having ordinary skill in the art would have been motivated to use Francois into the system of Poess for the purpose of boosting the priority of the thread. (col 1, line 40).
As per claim 7, Francois teaches wherein scheduling of threads is adapted based on one or more of information about the criticality modes in which a thread is allowed to be scheduled and thread priorities for the criticality modes that are included in a thread control block. (Francois [claim 9] ; an operating system controlling access by an executing thread to the processor, the operating system comprising priority logic for controlling a priority boost of the thread, the priority logic configured to: responsive to the thread executing in user mode an instruction to boost a priority of the thread, access a boost register, the boost register accessible only by a kernel of the operating system in kernel mode; determine a value of the boost register, the value indicating a time period that the thread may execute in a boosted priority state; and responsive to determining that the boost register holds a non-zero value, boost the priority of the thread).
Claim 8 is rejected under 35 U.S.C. 103 as being unpatentable over Poess (US 2021/0073147 A1) in view of Francois (US 9,229,716 B2) in further view of Kanai (US 2014/0372651 A1).
As per claim 8, Poess and Francois do not teach wherein control and handling of interrupts is adapted by configuring, in software or supported by hardware, which interrupts are allowed to be handled or processed in a particular criticality mode and which not.
However, Kanai teaches wherein control and handling of interrupts is adapted by configuring, in software or supported by hardware, which interrupts are allowed to be handled or processed in a particular criticality mode and which not. (Kanai [claim 3] an interrupt state manager configured to store settings regarding whether an interrupt is allowed or not for each mode of the operating system, and a state of an interrupt for each mode; an interrupt detector configured to detect occurrence of the interrupt and notify the interrupt state manager of start of an interrupt process at the operating system that is an interrupt input destination, and detect end of the interrupt and notify the interrupt state manager of end of the interrupt process at the operating system that is the interrupt input destination; and an interrupt policy determiner configured to detect a change in the settings regarding whether an interrupt is allowed or not, and update the interrupt state of the operating system that is the interrupt input destination, wherein the saving register determiner is configured to acquire, from the interrupt state manager, the interrupt state of a mode for performing an interrupt process at the operating system that is currently being processed, determine that saving of the banked register is unnecessary when an interrupt is being processed and when an interrupt by another operating system in the same mode is impossible, and determine that saving of the banked register is necessary when the mode is other than the mode for performing an interrupt process or when the operating system is processing an interrupt and another operating system in the same mode is allowed to perform an interrupt)
The examine believes this is consistent with what is disclosed in the specification ([0037] In an advantageous embodiment, control and handling of interrupts is adapted by configuring, in software or supported by hardware, which interrupts are allowed to be handled or processed in a particular criticality mode and which not. For each of the supported criticality modes it is preferably configured which interrupts are allowed to be handled or processed in a particular mode and which are not. As it is expected that most of the interrupts are handled by normal mode threads, for normal mode it is advantageous to list all interrupts that are not allowed in normal mode, while for safe mode and trusted mode it is preferable to list the interrupts that are allowed).
It would have been obvious to a person in the ordinary skill in the art before the effective filing date of the claimed invention to combine Kanai with the system of Poess and Francois to handle interrupts. One having ordinary skill in the art would have been motivated to use Kanai into the system of Poess and Francois for the purpose of speeding up the process of OS switching (Kanai paragraph 04).
Claim 9 is rejected under 35 U.S.C. 103 as being unpatentable over Poess (US 2021/0073147 A1) in view of Francois (US 9,229,716 B2) in further view of Gong (US 2023/0214245 A1).
As per claim 9, Poess and Francois do not teach wherein handling of exceptions is adapted to individual criticality modes.
However, Gong teaches wherein handling of exceptions is adapted to individual criticality modes. (Gong [0069] An EL3 mode is an execution mode of an ARM processor, and has a highest privilege level. Therefore, various privileged instructions and I/O operations may be executed in the EL3 mode. When the processor receives a secure monitor call (SMC) or a secure interrupt, the processor enters the EL3 mode. After entering the EL3 mode, the processor stops running of a current operating system, stores a CPU register status of the current operating system into a secure memory region (SMR), disables another interrupt and exception, and executes, in the SMR, code specified by SMC exception processing program. After receiving an exception return (ERET) instruction, the processor exits from the EL3 mode. After exiting from the EL3 mode, the processor stops executing, in the SMR, the code specified by the SMC exception processing program, reads the CPU register status of the current operating system from the SMR and restores the CPU register status, and starts another interrupt and exception. The EL3 mode is transparent to the operating system, the operating system does not know specific time at which the processor enters the EL3 mode, a specific operation performed in the EL3 mode, and specific time at which the processor exits from the EL3 mode).
The examiner has found prior art for this claim based on what is disclosed in the specification (0040] In an advantageous embodiment, handling of exceptions is adapted to individual criticality modes. In this way, each possible exception is handled appropriately in each of the criticality modes. For example, handling of page fault type of exceptions preferably considers whether the affected memory page is allowed to be accessed at all in the present criticality mode. Another aspect of exceptions is that e.g., in case of using ARMv8-A CPU cores, a transition to trusted mode is usually triggered by software executing a secure monitor call (SMC) instruction, leading to an SMC exception on the same core. Furthermore, particular memory pages may be defined for triggering a criticality mode switch when being accessed. Also other specific exceptions may be used to trigger a criticality mode switch)
It would have been obvious to a person in the ordinary skill in the art before the effective filing date of the claimed invention to combine Gong with the system of Poess and Francois to handle exceptions. One having ordinary skill in the art would have been motivated to use Gong into the system of Poess and Francois for the purpose of avoiding service interruption (Gong paragraph 04).
Claim 10 is rejected under 35 U.S.C. 103 as being unpatentable over Poess (US 2021/0073147 A1) in view of Francois (US 9,229,716 B2) in further view of Gaddam (US 2022/0131845 A1).
As per claim 10, Poess and Francois do not teach wherein use of memory is adapted by allowing access only to memory that is reserved in advance for a particular criticality mode.
However, Gaddam teaches wherein use of memory is adapted by allowing access only to memory that is reserved in advance for a particular criticality mode. (Gaddam [0044] A “trusted execution environment” (TEE) can be a secure area (e.g., reserved memory) within a computing environment. Specifically, a trusted execution environment provides an isolated execution environment (e.g., running in parallel with the OS executing in the computing environment) which ensures the integrity of applications executing within the trusted execution environment, along with the confidentiality of data that is processed within the trusted execution environment. In other words, the OS and/or untrusted applications not executing within the trusted execution environment cannot tamper with code that is executing with the trusted execution environment)
Examiner believes this is consistent with what is disclosed in the specification ([0041] In an advantageous embodiment, use of memory is adapted by allowing access only to memory that is reserved in advance for a particular criticality mode. Advantageously, all memory, including I/O memory and shared memory, that is needed by safe applications or trusted applications is reserved in advance).
It would have been obvious to a person in the ordinary skill in the art before the effective filing date of the claimed invention to combine Gaddam with the system of Poess and Francois to reserve memeory for a criticality mode. One having ordinary skill in the art would have been motivated to use Gaddam into the system of Poess and Francois for the purpose of implementing improved interaction (e.g., payment) on delivery transactions. (Gaddam paragraph 05)
Claim 11 is rejected under 35 U.S.C. 103 as being unpatentable over Poess (US 2021/0073147 A1) in view of Francois (US 9,229,716 B2) in further view of Sundaresan (US 2021/0073355 A1).
As per claim 11, Poess and Francois do not teach wherein handling of caches is adapted by flushing caches when switching between particular criticality modes.
However, Sundaresan teaches wherein handling of caches is adapted by flushing caches when switching between particular criticality modes. (Sundaresan [0030] FIG. 2 provides a flowchart 200, illustrating exemplary activities associated with the practice of the disclosure. Reference is made to system elements depicted in FIG. 1 as well. After program start, at 210, the processor set 154, receives code for execution from memory 158 and program 175 in persistent storage 170. The code includes an associated security classification. At 220, the security classification is checked. At 230, trusted code is executed without remediation and without a cache flush prior to starting. At 240, a cache flush instruction is inserted prior to starting the execution of the untrusted code. At 250 the untrusted code executes with remediation. The cache flush refers to clearing the contents of cache 162 of memory 158)
Examiner believes this is consistent with what is disclosed in the specification ([0042] In an advantageous embodiment, handling of caches is adapted by flushing caches when switching between particular criticality modes. Flushing of caches may be necessary when switching between certain criticality modes, e.g., to make sure that sensitive data is not leaking outside trusted mode.)
It would have been obvious to a person in the ordinary skill in the art before the effective filing date of the claimed invention to combine Sundaresan with the system of Poess and Francois to flush caches. One having ordinary skill in the art would have been motivated to use Sundaresan into the system of Poess and Francois for the purpose of **general statement about the eventual positive outcome from all of this combining**.
Claim 12 is rejected under 35 U.S.C. 103 as being unpatentable over Poess (US 2021/0073147 A1) in view of Francois (US 9,229,716 B2) in further view of Shardin (US 2021/0397724 A1).
As per claim 12, Poess and Francois do not teach wherein interprocess communication is adapted by distinguishing at least between two or more of allowed interprocess communication, forbidden interprocess communication, and limited interprocess communication.
However, Shardin teaches wherein interprocess communication is adapted by distinguishing at least between two or more of allowed interprocess communication, forbidden interprocess communication, and limited interprocess communication. (Shadrin [0010] In one aspect, a method is proposed for providing an interprocess interaction in an electronic control unit having an operating system defining a kernel space, wherein the method involves steps in which: the kernel of the operating system intercepts a request for an interprocess communication between a first application and a second application of the electronic control unit. A verdict is requested, from an access control component of the operating system, with respect to granting access for the requested interprocess communication between the first application and the second application of the electronic control unit. The access control component generates the verdict for the requested interprocess communication based on a security policy. The kernel of the operating system selectively allows the requested interprocess communication between the first application and the second application based on the generated verdict. [0014] In one aspect, the kernel allows the requested interprocess communication based on the affirmative verdict generated by the access control component. The kernel blocks the requested interprocess communication based on the negative verdict generated by the access control component).
It would have been obvious to a person in the ordinary skill in the art before the effective filing date of the claimed invention to combine Shadrin with the system of Poess and Francois to adapt interprocess communication. One having ordinary skill in the art would have been motivated to use Shadrin into the system of Poess and Francois for the purpose of enabling an interprocess communication in electronic control units of vehicles. (Shardin paragraph 02)
Claim 15 is rejected under 35 U.S.C. 103 as being unpatentable over Poess (US 2021/0073147 A1) in view of Bohm (US 2010/0292867 A1).
As per claim 15, Poess does not teach wherein the processing system is part of a motor vehicle.
However, Bohm teaches wherein the processing system is part of a motor vehicle. (Bohm [0020] According to the invention, a motor vehicle control device is provided, comprising: a microkernel, several entities; and a software bus, via which the entities can communicate with each other and with the kernel, wherein one or more of the entities respectively represent one or more modules of the AUTOSAR base software. [0021] According to the invention in addition a motor vehicle control device is provided, comprising software for controlling a plurality of applications, wherein the software has the following layers: an application layer with a plurality of applications; a base software layer with a first plurality of AUTOSAR-based base services and a second plurality of AUTOSAR-independent base services, to carry out the applications; an adaption layer with at least a first run time environment, which is assigned to the first plurality of base services, and a second run time environment, which is assigned to the second plurality of base services, wherein the adaption layer connects the application layer with the base software layer; and an operating system layer with a microkernel).
It would have been obvious to a person in the ordinary skill in the art before the effective filing date of the claimed invention to combine Bohm with the system of Poess to process in a vehicle. One having ordinary skill in the art would have been motivated to use Bohm into the system of Poess for the purpose of establishing a microkernel for a vehicle (Bohm paragraph 12)
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US 20170300719 A1 – discloses a microprocessor computer system for secure/high assurance/safety critical computing includes a hardware subsystem having a plurality of cache controller and cache bank modules including cache bank and memory cell hardware permission bits for managing and controlling access to system resources. A computer security framework subsystem includes a hierarchy of access layers comprising top layers and lower layers. The permission bits provide hardware level computer security primitives for a computer operating system. The top layers are completely trusted and the lower layers are moderately trusted to completely untrusted. The top layers include a trusted operating system layer that executes management and control of the system resources and permission bits. The permission bits define limits for a hardware execution security mechanism for less trusted to completely untrusted software. Exceeding bounds of the security mechanism results in a hardware exception thereby blocking all attempts to access or modify resources outside the security mechanism.
US 20200012507 A1 – discloses a microkernel architecture control system of an industrial server and an industrial server, which relate to the technical field of industrial servers. According to the microkernel architecture control system, scheduling configuration information is customized on the basis of an architecture including a plurality of microkernels and a virtual machine monitor prior to startup of a system, each microkernel including industrial control middleware and a real-time operating system.
US 9471533 B1 – discloses validating objects stored in a web cache. In one embodiment, a computing device caches objects received while accessing networked content over a network. The computing device generates a description of conditions associated with the caching of the objects. When the computing device accesses networked content via a second network, the computing device or a remote server connected thereto utilizes the description to determine whether an object in the cache is trusted or untrusted. The server manages a policy that defines rules for making the determination. The policy can be generated based on descriptions received from a plurality of devices.
US 20160041923 A1 – discloses a microkernel operating system for shared memory, and mapping shared memory, which is allocated by the microkernel operating system, to virtual address space of the service manager process; receiving and recording a service identifier of a system service process and a second shared memory address that corresponds to the service identifier; searching, according to a service identifier carried by a system service request, for the second shared memory address that corresponds to the service identifier carried by the system service request; and sending the service identifier carried by the system service request, a first shared memory address, and the second shared memory address that corresponds to the service identifier to a user process. According to the method, a problem that communication between a user process and a system service process needs multiple context switches can be solved.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MEHRAN KAMRAN whose telephone number is (571)272-3401. The examiner can normally be reached on 9-5.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, April Blair can be reached on (571)270-1014. 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.
/MEHRAN KAMRAN/ Primary Examiner, Art Unit 2196
Prosecution Insights