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 .
Claims 1-20 are pending in this application.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 01/31/2024. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 1-20 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-18 of of U.S. Patent No. US 11,914,723 B2. Although the claims at issue are not identical, they are not patentably distinct from each other because claims 1-18 of of U.S. Patent No. US 11,914,723 B2 contains every element of claims 1-20 of the instant application and thus anticipate the claims of the instant application (see Claim Comparison Table below).
Instant Application 18/427,988
US 11,914,723 B2
Claim 1. An Information Handling System (IHS), comprising: a processor;
a memory having program instructions stored thereon coupled to the processor, and a remote access controller configured to perform a cryptographic verification process on the IHS, the remote access controller comprising:
a second processor;
second memory coupled to the second processor,
a root of trust coupled to the memory, and a secure object store coupled to the root of trust,
the root of trust having second program instructions stored thereon that upon execution by the second processor, cause the remote access controller to perform the cryptographic verification process to verify the program instructions, the processor, the memory, a local management agent, and a workspace privacy agent;
wherein the processor is configured to, upon cryptographic verification of the program instructions, the processor, the memory, the local management agent, and the workspace privacy agent, execute the program instructions to cause the IHS to:
instantiate a first workspace and a second workspace by the local management agent,
instantiate a first local resource service for the first workspace and a second local resource service for the second workspace,
receive, by the workspace privacy agent, a first hardware privacy request from the first local resource service in response to a first application running in the first workspace,
receive, by the workspace privacy agent, a second hardware privacy request from second local resource service in response to a second application running in the second workspace, and
service the first privacy request,
including performing an action that affects a state of a peripheral device coupled to the processor.
Claim 1. An Information Handling System (IHS), comprising: a processor;
a memory having program instructions stored thereon coupled to the processor, and a remote access controller configured to perform a cryptographic verification process on the IHS, the remote access controller comprising:
a second processor;
second memory coupled to the second processor,
a root of trust coupled to the memory, and a secure object store coupled to the root of trust,
the root of trust having second program instructions stored thereon that upon execution by the second processor, cause the remote access controller to perform the cryptographic verification process to verify the program instructions, the processor, the memory, a local management agent, and a workspace privacy agent;
wherein the processor is configured to, upon cryptographic verification of the program instructions, the processor, the memory, a local management agent, and the workspace privacy agent, execute the program instructions to cause the IHS to:
instantiate a first workspace and a second workspace by the local management agent,
instantiate a first local resource service for the first workspace and a second local resource service for the second workspace,
receive, by the workspace privacy agent, a first hardware privacy request from the first local resource service in response to a first application running in the first workspace,
receive, by the workspace privacy agent, a second hardware privacy request from the second local resource service in response to a second application running in the second workspace, arbitrate, by the workspace privacy agent, between the first hardware privacy request and the second hardware privacy request to determine that the first hardware privacy request corresponds to a higher level of a privacy setting than does the second hardware privacy request, and
service the first privacy request, which corresponds to the higher level of the privacy setting,
including performing an action that affects a state of a peripheral device coupled to the processor.
Claim 2. The IHS of claim 1, wherein the first hardware privacy request comprises a request to keep a camera shutter on or off.
Claim 2. The IHS of claim 1, wherein the first hardware privacy request comprises a request to keep a camera shutter on or off.
Claim 3. The IHS of claim 1, wherein the first hardware privacy request comprises a request to turn an audio device on or off.
Claim 3. The IHS of claim 1, wherein the first hardware privacy request comprises a request to turn an audio device on or off.
Claim 4. The IHS of claim 1, wherein the first hardware privacy request comprises a request to turn a display privacy or blur state on or off.
Claim 4. The IHS of claim 1, wherein the first hardware privacy request comprises a request to turn a display privacy or blur state on or off.
Claim 5. The IHS of claim 1, wherein the program instructions, upon execution, further cause the IHS to: receive, at the workspace privacy agent, a second hardware privacy request; determine that the second hardware privacy request conflicts with the first hardware privacy request; and abstain from executing the second privacy request in response to the determination.
Claim 5. The IHS of claim 1, wherein the program instructions, upon execution, further cause the IHS to: receive, at the workspace privacy agent, a second hardware privacy request; determine that the second hardware privacy request conflicts with the first hardware privacy request; and abstain from executing the second privacy request in response to the determination.
Claim 6. The IHS of claim 5, wherein the first and second hardware privacy requests are issued by different applications executed within the first workspace.
Claim 6. The IHS of claim 5, wherein the first and second hardware privacy requests are issued by different applications executed within the first workspace.
Claim 7. The IHS of claim 5, wherein the second hardware privacy request is issued by a second application executed in a second workspace.
Claim 7. The IHS of claim 5, wherein the second hardware privacy request is issued by a second application executed in a second workspace.
Claim 8. The IHS of claim 1, wherein the program instructions, upon execution, further cause the IHS to execute the first hardware privacy request based upon context information.
Claim 8. The IHS of claim 1, wherein the program instructions, upon execution, further cause the IHS to execute the first hardware privacy request based upon context information.
Claim 9. The IHS of claim 8, wherein the context information comprises at least one of: an identity or a type of the first application.
Claim 9. The IHS of claim 8, wherein the context information comprises at least one of: an identity or a type of the first application.
Claim 10. The IHS of claim 8, wherein the context information comprises at least one of: whether the first application is in a foreground, or whether the first application is in a background.
Claim 10. The IHS of claim 8, wherein the context information comprises at least one of: whether the first application is in a foreground, or whether the first application is in a background.
Claim 11. The IHS of claim 8, wherein the context information comprises at least one of: a presence state of a user, or a proximity of the user.
Claim 11. The IHS of claim 8, wherein the context information comprises at least one of: a presence state of a user, or a proximity of the user.
Claim 12. The IHS of claim 8, wherein the context information comprises a location of the IHS.
Claim 12. The IHS of claim 8, wherein the context information comprises a location of the IHS.
Claim 13. The IHS of claim 8, wherein the context information comprises a posture of the IHS.
Claim 13. The IHS of claim 8, wherein the context information comprises a posture of the IHS.
Claim 14. The IHS of claim 8, wherein the context information comprises calendar or meeting information.
Claim 14. The IHS of claim 8, wherein the context information comprises calendar or meeting information.
Claim 15. The IHS of claim 8, wherein the context information comprises at least one of: an identification of the user, an identification of a network of the IHS, an identification of hardware of the IHS, an identification of a requested datafile, or an identification of a storage system of the requested datafile.
Claims 15. The IHS of claim 8, wherein the context information comprises at least one of: an identification of the user, an identification of a network of the IHS, an identification of hardware of the IHS, an identification of a requested datafile, or an identification of a storage system of the requested datafile.
Claim 16. The IHS of claim 8, wherein the program instructions, upon execution, further cause the IHS to execute the first hardware privacy request based, at least in part, upon an application of a hardware privacy policy received from a workspace orchestration service to the context information.
Claim 16. The IHS of claim 8, wherein the program instructions, upon execution, further cause the IHS to execute the first hardware privacy request based, at least in part, upon an application of a hardware privacy policy received from a workspace orchestration service to the context information.
Claim 17. The IHS of claim 16, wherein the local management agent is configured to receive, from the workspace orchestration service, data configured to enable the local management agent to instantiate each of a plurality of workspaces based upon a respective one of a plurality of workspace definitions, and wherein each workspace definition identifies whether a respective workspace is subject to the hardware privacy policy.
Claim 17. The IHS of claim 16, wherein the local management agent is configured to receive, from the workspace orchestration service, data configured to enable the local management agent to instantiate each of a plurality of workspaces based upon a respective one of a plurality of workspace definitions, and wherein each workspace definition identifies whether a respective workspace is subject to the hardware privacy policy.
Claim 18. The IHS of claim 17, wherein the workspace orchestration service is configured to, for each of the plurality of workspaces: (i) calculate a security target based in part upon context information, and (ii) create a workspace definition based in part upon the security target, and wherein the security target is calculated by the workspace orchestration service based upon at least one of: a risk metric associated with a locale of the IHS, a risk metric associated with the user, a risk metric associated with a network of the IHS, a risk metric associated with hardware of the IHS, a risk metric associated with a requested datafile, or a regulatory risk metric associated with the user, the locale, and the requested datafile.
Claim 18. The IHS of claim 17, wherein the workspace orchestration service is configured to, for each of the plurality of workspaces: (i) calculate a security target based in part upon context information, and (ii) create a workspace definition based in part upon the security target, and wherein the security target is calculated by the workspace orchestration service based upon at least one of: a risk metric associated with a locale of the IHS, a risk metric associated with the user, a risk metric associated with a network of the IHS, a risk metric associated with hardware of the IHS, a risk metric associated with a requested datafile, or a regulatory risk metric associated with the user, the locale, and the requested datafile.
As to claims 19 and 20 of the instant application, these claims are rejected using the similar rationale as for the rejection of claim 1 of the instant application. Claim 1-18 of U.S. Patent No. US 11,914,723 B2 contains every element of claims 1-20 of the instant application and thus anticipate the claims of the instant application.
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, 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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 19 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Konanka et al. (US 7,725,737 B2) (hereinafter, “Konanka”) in view of Plagemann et al. (US 9,317,721 B2) (hereinafter, “Plagemann”).
As to claim 19, Konanka discloses a memory storage device having program instructions stored thereon that, upon execution by an Information Handling System (IHS), cause the IHS to, upon cryptographic verification of the program instructions, a processor of the IHS, a local management agent, and a workspace privacy agent (“FIG. 2A is a high-level block diagram illustrating the Secure Workspace System (SWS) of the present invention. As shown, the SWS 200 is a secure workspace or desktop environment that includes (main) application(s) 210; secure workspace hook(s) 220, hooks engine 225, and secure workspace manager 227.” -e.g., see, col. 10, lines 13-21; see also: “When such a new process has been created, the hooks engine (cpSws.dll) writes a secure token to its memory. A child process may use this as an authorization password for the pipe server.” -e.g., see, col. 13, lines 20-25; see also: “The server expects a secure token as the first data sent from a given client via pipe. If it receives any other data, it closes the pipe connection after waiting a prescribed period of time (as an anti-hacker delay). A secure token is written directly to secured process memory on its creation, so no one else can use the IPC channel/engine.” -e.g., see, col. 28, lines 20-25; herein, secure token verification constitutes cryptographic verification of the program instructions, processor; workspace manger constitutes local management, and hooks engine constitutes workspace privacy agent; note: limitations should be rewritten outside preamble to get patentable weight):
instantiate a first workspace and a second workspace by the local management agent (“… the manager 227 creates a new “secure' desktop and secure user profile, and initializes them according to a secure workspace policy. The policy (cpSws.xml) file allows one to specify the SWS look and feel (e.g., start menu, short cuts, and the like), the list of applications that can be started on the secure workspace, and security settings for individual applications (e.g., access rights for folders, WinNT kernel objects, and the like).” -e.g., see, col. 10, lines 20-27; herein, the manager 227 creates/instantiates workspaces),
instantiate a first local resource service for the first workspace and a second local resource service for the second workspace (“… the manager 227 starts a usual Windows shell (e.g., explorer.exe) with an injection of the hooks engine 225 (cpSws.dll) on the created desktop. The injected hooks engine 225 in turn hooks “process creation' routines and automatically injects itself into all newly created processes. In this manner, each application 210 on the secure desktop receives a workspace hook 220. In the Microsoft Windows environment, for example, the injected DLL hooks API calls (invocations) by overwriting hooked NTDLL routines entry points with JMP instructions, thus redirecting them to code inside the cpSws.dll.” -e.g., see, col. 10, lines 32-42; herein, per-workspace hooks constitute local resource service),
receive, by the workspace privacy agent, a first hardware privacy request from the first local resource service in response to a first application running in the first workspace (“The SWS creates a new secured, virtual desktop, which the user can work on, and intercepts file/registry operations for all applications started on this desktop.” -e.g., see, col. 10, lines 7-10; see also: “… the cpSws.dll can dispatch all files-related functions, including those used by the application. The cpsws.dll encrypts all data on-the-fly, and stores it to the target persistent storage in encrypted form.” -col. 11, lines 64-67; herein, hooks engine (privacy agent) receives requests from per-workspace service triggered by an application),
receive, by the workspace privacy agent, a second hardware privacy request from second local resource service in response to a second application running in the second workspace (“The SWS creates a new secured, virtual desktop, which the user can work on, and intercepts file/registry operations for all applications started on this desktop.” -e.g., see, col. 10, lines 7-10; see also: “… the cpSws.dll can dispatch all files-related functions, including those used by the application. The cpsws.dll encrypts all data on-the-fly, and stores it to the target persistent storage in encrypted form.” -col. 11, lines 64-67; herein, hooks engine (privacy agent) receives requests from per-workspace service triggered by an application; identical operation for second workspace/application),
service the first privacy request, including performing a first action that affects … a first peripheral device coupled to the processor, and service the second privacy request, including performing a second action that … a second peripheral device coupled to the processor (“In response to a proper request, the SWS of the present invention may be shutdown. Before closing, it optionally queries all running applications for shutdown, terminates all secured application(s), and then deletes all secured data from local storages, …” -e.g., see, col. 14, lines 5-9; see also: “The underlying operating system (OS) may save memory pages of applications running on secure desktop into a global system swap file.” -e.g., see, col. 14, lines 16-19; herein, servicing includes actions that affect peripheral/storage device.
Konanka doesn’t explicitly disclose servicing of hardware privacy requests by performing precise state-changing actions on peripherals.
However, in an analogous art, Plagemann discloses service the first privacy request, including performing a first action that affects a state of a first peripheral device coupled to the processor, and service the second privacy request, including performing a second action that affects a state of a second peripheral device coupled to the processor (“… a command to access data generated by a sensor may be received. The command may be determined to be impermissible by a privacy policy. Based on this determination, the state of a privacy indicator may be changed.” -e.g., see, col. 1, lines 30-33; see also: “…the privacy module … may receive a request …The privacy module may determine that the gesture data are permissible in accordance with a privacy policy or because a gesture is found in a library of known commands.” -e.g., see, col. 13, lines 9-16; see also: “If the privacy module determines that a command 55 has been issued that may be incompatible with the library of known commands, then it may change the status of a privacy indicator on the sensor to alert a user and it may close the stream pip responsible for transmission of sensor data.” -e.g., see, col. 13, lines 55-60; see also: “A message pipe may be used to update a sensor status and a stream pipe may transfer sensor data to the host controller of the device. Some sensors may have multiple stream pipes. For example, a web camera may have a microphone and a camera that utilize separate stream pipes. Each pipe may be individually controlled. Addressing endpoints and regulating pipes are understood by a skilled practitioner.” -e.g., see, col. 13, lines 40-47; herein, the privacy module (workspace privacy agent) receives the hardware privacy requests and services them by performing explicit actions that affect the state of peripherals (first action on one peripheral such as camera shutter; second action on another such as microphone or display privacy)).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention was to modify the teaching of Konanka by including additional feature of Plagemann in order to provide fine-grained, per-workspace hardware privacy controls on shared HIS peripherals.
As to claim 20, Konanka discloses a method performed by an Information Handling System (IHS), the method comprising:
performing a cryptographic verification process to verify program instructions, a processor of the IHS, a memory storing the program instructions, a local management agent, and a workspace privacy agent; executing the program instructions upon cryptographic verification of the program instructions, the processor, the memory, the local management agent, and the workspace privacy agent (“FIG. 2A is a high-level block diagram illustrating the Secure Workspace System (SWS) of the present invention. As shown, the SWS 200 is a secure workspace or desktop environment that includes (main) application(s) 210; secure workspace hook(s) 220, hooks engine 225, and secure workspace manager 227.” -e.g., see, col. 10, lines 13-21; see also: “When such a new process has been created, the hooks engine (cpSws.dll) writes a secure token to its memory. A child process may use this as an authorization password for the pipe server.” -e.g., see, col. 13, lines 20-25; see also: “The server expects a secure token as the first data sent from a given client via pipe. If it receives any other data, it closes the pipe connection after waiting a prescribed period of time (as an anti-hacker delay). A secure token is written directly to secured process memory on its creation, so no one else can use the IPC channel/engine.” -e.g., see, col. 28, lines 20-25; herein, secure token verification constitutes cryptographic verification of the program instructions, processor; workspace manger constitutes local management, and hooks engine constitutes workspace privacy agent),
instantiating a first workspace and a second workspace by the local management agent (“… the manager 227 creates a new “secure' desktop and secure user profile, and initializes them according to a secure workspace policy. The policy (cpSws.xml) file allows one to specify the SWS look and feel (e.g., start menu, short cuts, and the like), the list of applications that can be started on the secure workspace, and security settings for individual applications (e.g., access rights for folders, WinNT kernel objects, and the like).” -e.g., see, col. 10, lines 20-27; herein, the manager 227 creates/instantiates workspaces),
instantiating a first local resource service for the first workspace and a second local resource service for the second workspace (“… the manager 227 starts a usual Windows shell (e.g., explorer.exe) with an injection of the hooks engine 225 (cpSws.dll) on the created desktop. The injected hooks engine 225 in turn hooks “process creation' routines and automatically injects itself into all newly created processes. In this manner, each application 210 on the secure desktop receives a workspace hook 220. In the Microsoft Windows environment, for example, the injected DLL hooks API calls (invocations) by overwriting hooked NTDLL routines entry points with JMP instructions, thus redirecting them to code inside the cpSws.dll.” -e.g., see, col. 10, lines 32-42; herein, per-workspace hooks constitute local resource service),
receive, by the workspace privacy agent, a first hardware privacy request from the first local resource service in response to a first application running in the first workspace (“The SWS creates a new secured, virtual desktop, which the user can work on, and intercepts file/registry operations for all applications started on this desktop.” -e.g., see, col. 10, lines 7-10; see also: “… the cpSws.dll can dispatch all files-related functions, including those used by the application. The cpsws.dll encrypts all data on-the-fly, and stores it to the target persistent storage in encrypted form.” -col. 11, lines 64-67; herein, hooks engine (privacy agent) receives requests from per-workspace service triggered by an application),
receive, by the workspace privacy agent, a second hardware privacy request from second local resource service in response to a second application running in the second workspace (“The SWS creates a new secured, virtual desktop, which the user can work on, and intercepts file/registry operations for all applications started on this desktop.” -e.g., see, col. 10, lines 7-10; see also: “… the cpSws.dll can dispatch all files-related functions, including those used by the application. The cpsws.dll encrypts all data on-the-fly, and stores it to the target persistent storage in encrypted form.” -col. 11, lines 64-67; herein, hooks engine (privacy agent) receives requests from per-workspace service triggered by an application; identical operation for second workspace/application),
service the first privacy request, including performing a first action that affects … a first peripheral device coupled to the processor, and service the second privacy request, including performing a second action that … a second peripheral device coupled to the processor (“In response to a proper request, the SWS of the present invention may be shutdown. Before closing, it optionally queries all running applications for shutdown, terminates all secured application(s), and then deletes all secured data from local storages, …” -e.g., see, col. 14, lines 5-9; see also: “The underlying operating system (OS) may save memory pages of applications running on secure desktop into a global system swap file.” -e.g., see, col. 14, lines 16-19; herein, servicing includes actions that affect peripheral/storage device.
Konanka doesn’t explicitly disclose servicing of hardware privacy requests by performing precise state-changing actions on peripherals.
However, in an analogous art, Plagemann discloses service the first privacy request, including performing a first action that affects a state of a first peripheral device coupled to the processor, and service the second privacy request, including performing a second action that affects a state of a second peripheral device coupled to the processor (“… a command to access data generated by a sensor may be received. The command may be determined to be impermissible by a privacy policy. Based on this determination, the state of a privacy indicator may be changed.” -e.g., see, col. 1, lines 30-33; see also: “…the privacy module … may receive a request …The privacy module may determine that the gesture data are permissible in accordance with a privacy policy or because a gesture is found in a library of known commands.” -e.g., see, col. 13, lines 9-16; see also: “If the privacy module determines that a command 55 has been issued that may be incompatible with the library of known commands, then it may change the status of a privacy indicator on the sensor to alert a user and it may close the stream pip responsible for transmission of sensor data.” -e.g., see, col. 13, lines 55-60; see also: “A message pipe may be used to update a sensor status and a stream pipe may transfer sensor data to the host controller of the device. Some sensors may have multiple stream pipes. For example, a web camera may have a microphone and a camera that utilize separate stream pipes. Each pipe may be individually controlled. Addressing endpoints and regulating pipes are understood by a skilled practitioner.” -e.g., see, col. 13, lines 40-47; herein, the privacy module (workspace privacy agent) receives the hardware privacy requests and services them by performing explicit actions that affect the state of peripherals (first action on one peripheral such as camera shutter; second action on another such as microphone or display privacy)).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention was to modify the teaching of Konanka by including additional feature of Plagemann in order to provide fine-grained, per-workspace hardware privacy controls on shared HIS peripherals.
Claims 1-18 are rejected under 35 U.S.C. 103 as being unpatentable over Konanka in view of Plagemann and further in view of Gopal et al. (US 2020/0371695 A1) (hereinafter, “Gopal”).
As to claim 1, Konanka discloses an Information Handling System (IHS), comprising:
a processor; a memory having program instructions stored thereon coupled to the processor, and a remote access controller configured to perform a cryptographic verification process on the HIS (“FIG. 2A is a high-level block diagram illustrating the Secure Workspace System (SWS) of the present invention. As shown, the SWS 200 is a secure workspace or desktop environment that includes (main) application(s) 210; secure workspace hook(s) 220, hooks engine 225, and secure workspace manager 227.” -e.g., see, col. 10, lines 13-21; see also: “When such a new process has been created, the hooks engine (cpSws.dll) writes a secure token to its memory. A child process may use this as an authorization password for the pipe server.” -e.g., see, col. 13, lines 20-25; see also: “The server expects a secure token as the first data sent from a given client via pipe. If it receives any other data, it closes the pipe connection after waiting a prescribed period of time (as an anti-hacker delay). A secure token is written directly to secured process memory on its creation, so no one else can use the IPC channel/engine.” -e.g., see, col. 28, lines 20-25; herein, secure token verification constitutes cryptographic verification of the program instructions, processor), the remote access controller comprising:
… cause the remote access controller to perform the cryptographic verification process to verify the program instructions, the processor, the memory, a local management agent, and a workspace privacy agent; wherein the processor is configured to, upon cryptographic verification of the program instructions, the processor, the memory, the local management agent, and the workspace privacy agent, execute the program instructions to cause the IHS to (“FIG. 2A is a high-level block diagram illustrating the Secure Workspace System (SWS) of the present invention. As shown, the SWS 200 is a secure workspace or desktop environment that includes (main) application(s) 210; secure workspace hook(s) 220, hooks engine 225, and secure workspace manager 227.” -e.g., see, col. 10, lines 13-21; see also: “When such a new process has been created, the hooks engine (cpSws.dll) writes a secure token to its memory. A child process may use this as an authorization password for the pipe server.” -e.g., see, col. 13, lines 20-25; see also: “The server expects a secure token as the first data sent from a given client via pipe. If it receives any other data, it closes the pipe connection after waiting a prescribed period of time (as an anti-hacker delay). A secure token is written directly to secured process memory on its creation, so no one else can use the IPC channel/engine.” -e.g., see, col. 28, lines 20-25; herein, secure token verification constitutes cryptographic verification of the program instructions, processor; workspace manger constitutes local management, and hooks engine constitutes workspace privacy agent):
instantiate a first workspace and a second workspace by the local management agent (“… the manager 227 creates a new “secure' desktop and secure user profile, and initializes them according to a secure workspace policy. The policy (cpSws.xml) file allows one to specify the SWS look and feel (e.g., start menu, short cuts, and the like), the list of applications that can be started on the secure workspace, and security settings for individual applications (e.g., access rights for folders, WinNT kernel objects, and the like).” -e.g., see, col. 10, lines 20-27; herein, the manager 227 creates/instantiates workspaces),
instantiate a first local resource service for the first workspace and a second local resource service for the second workspace (“… the manager 227 starts a usual Windows shell (e.g., explorer.exe) with an injection of the hooks engine 225 (cpSws.dll) on the created desktop. The injected hooks engine 225 in turn hooks “process creation' routines and automatically injects itself into all newly created processes. In this manner, each application 210 on the secure desktop receives a workspace hook 220. In the Microsoft Windows environment, for example, the injected DLL hooks API calls (invocations) by overwriting hooked NTDLL routines entry points with JMP instructions, thus redirecting them to code inside the cpSws.dll.” -e.g., see, col. 10, lines 32-42; herein, per-workspace hooks constitute local resource service),
receive, by the workspace privacy agent, a first hardware privacy request from the first local resource service in response to a first application running in the first workspace (“The SWS creates a new secured, virtual desktop, which the user can work on, and intercepts file/registry operations for all applications started on this desktop.” -e.g., see, col. 10, lines 7-10; see also: “… the cpSws.dll can dispatch all files-related functions, including those used by the application. The cpsws.dll encrypts all data on-the-fly, and stores it to the target persistent storage in encrypted form.” -col. 11, lines 64-67; herein, hooks engine (privacy agent) receives requests from per-workspace service triggered by an application),
receive, by the workspace privacy agent, a second hardware privacy request from second local resource service in response to a second application running in the second workspace (“The SWS creates a new secured, virtual desktop, which the user can work on, and intercepts file/registry operations for all applications started on this desktop.” -e.g., see, col. 10, lines 7-10; see also: “… the cpSws.dll can dispatch all files-related functions, including those used by the application. The cpsws.dll encrypts all data on-the-fly, and stores it to the target persistent storage in encrypted form.” -col. 11, lines 64-67; herein, hooks engine (privacy agent) receives requests from per-workspace service triggered by an application; identical operation for second workspace/application), and
service the first privacy request, including performing a first action that affects … a first peripheral device coupled to the processor (“In response to a proper request, the SWS of the present invention may be shutdown. Before closing, it optionally queries all running applications for shutdown, terminates all secured application(s), and then deletes all secured data from local storages, …” -e.g., see, col. 14, lines 5-9; see also: “The underlying operating system (OS) may save memory pages of applications running on secure desktop into a global system swap file.” -e.g., see, col. 14, lines 16-19; herein, servicing includes actions that affect peripheral/storage device.
Konanka doesn’t explicitly disclose servicing of hardware privacy requests by performing precise state-changing actions on peripherals.
However, in an analogous art, Plagemann discloses service the first privacy request, including performing a first action that affects a state of a first peripheral device coupled to the processor (“… a command to access data generated by a sensor may be received. The command may be determined to be impermissible by a privacy policy. Based on this determination, the state of a privacy indicator may be changed.” -e.g., see, col. 1, lines 30-33; see also: “…the privacy module … may receive a request …The privacy module may determine that the gesture data are permissible in accordance with a privacy policy or because a gesture is found in a library of known commands.” -e.g., see, col. 13, lines 9-16; see also: “If the privacy module determines that a command 55 has been issued that may be incompatible with the library of known commands, then it may change the status of a privacy indicator on the sensor to alert a user and it may close the stream pip responsible for transmission of sensor data.” -e.g., see, col. 13, lines 55-60; see also: “A message pipe may be used to update a sensor status and a stream pipe may transfer sensor data to the host controller of the device. Some sensors may have multiple stream pipes. For example, a web camera may have a microphone and a camera that utilize separate stream pipes. Each pipe may be individually controlled. Addressing endpoints and regulating pipes are understood by a skilled practitioner.” -e.g., see, col. 13, lines 40-47; herein, the privacy module (workspace privacy agent) receives the hardware privacy requests and services them by performing explicit actions that affect the state of peripherals (first action on one peripheral such as camera shutter)).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention was to modify the teaching of Konanka by including additional feature of Plagemann in order to provide fine-grained, per-workspace hardware privacy controls on shared HIS peripherals.
Konanka in view of Plagemann does not explicitly disclose the specific hardware components of a remote access controller (second processor, second memory coupled to the second processor, a root of trust coupled to the memory, a secure object store coupled to the root of trust) or the root of trust having second program instructions stored thereon that upon execution by the second processor, cause the remote access controller to perform the cryptographic verification process to verify the program instructions, the processor, the memory, a local management agent, and a workspace privacy agent (herein, the root-of-trust driven cryptographic verification process for listed components);
However, in an analogous art, Gopal discloses a remote access controller configured to perform a cryptographic verification process on the IHS, the remote access controller (“BMC 190 is configured to provide out-of-band and/or side-band access to devices at information handling system 100.” -e.g., see, [0015]; herein, BMC functions as the remote access controller for out-of-band management and verification on the IHS) comprising: a second processor (“BMC 190 can be referred to as a service processor, and embedded controller (EC), and the like.” -e.g., see, [0015]; herein, embedded controller/processor separate from the main CPU for out-of-band operations); second memory coupled to the second processor (“The BMC payloads can be installed at the non-volatile memory device included at an NVDIMM via manageability tools having access to network recourses, making use of cryptographic methods available at BMC 180 to ensure that the payload being installed is trusted.” -e.g., see, [00030]; herein, BMC uses dedicated memory for its operation), a root of trust coupled to the memory (“… BMC 180 is configured to provide a root-of-trust at system 100, thereby ensuring secure authentication of the payload.” -e.g., see, [0029]; see also: “… to BMC 180 can provide security advantages, especially if BMC 180 provides a hardware level root-of-trust.” -e.g., see, [0025]; herein, root of trust hardware component provided by the BMC and coupled to system memory), and a secure object store coupled to the root of trust (“ Method 500 continues at block 502 where the BMC provides cryptography services to authenticate information prior to storing the information at a non-volatile memory device included at an NVDIMM. For example, BMC 180 can be used to verify a cryptographic signature associated with a payload or with other encapsulated information prior to the BMC storing the payload at non-volatile memory device included at an NVDIMM. In an embodiment, BMC 180 is configured to provide a root-of-trust at system 100, thereby ensuring secure authentication of the payload.” -e.g., see, [0029]; herein, NVDIMM servers as secure storage writable only by the BMC/root of trust for protected data), the root of trust having second program instructions stored thereon that upon execution by the second processor, cause the remote access controller to perform the cryptographic verification process to verify the program instructions, the processor, the memory, a local management agent, and a workspace privacy agent (“… , BMC 180 can verify that data or firmware passes cryptographic validation before storing the information at non-volatile memory 205. In a specific embodiment, a portion of non-volatile memory 205 that is available for access by BMC 182 can be configured as writable only by BMC 182, so that no other device or software process can modify the information stored at these locations. In one embodiment, information stored at non-volatile memory 205 can only be accessed by BMC 182, while in another embodiment; information stored at non-volatile memory 205 by BMC 182 can be retrieved via DDR interface 220. One of skill will appreciate that read and write access privileges at non-volatile memory 205 can be configured to provide a desired degree of access control. However, limiting write access exclusively to BMC 180 can provide security advantages, especially if BMC 180 provides a hardware level root-of-trust.” -e.g., see, [0025]; see also: “… BMC 180 is configured to provide a root-of-trust at system 100, thereby ensuring secure authentication of the payload.” -e.g., see, [0029]; herein, root of trust instructions executed by the BMC’s second processor perform cryptographic verification of firmware/program instructions (and by extension agents) before allowing execution/storage);
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention was to modify the teaching of Konanka and Plagemann by including additional feature of Gopal in order to protect user privacy and prevent unauthorized access to sensitive hardware resources in a multi-workspace environment.
As to claim 2, Konanka in view of Plagemann and Gopal discloses the IHS of claim 1, Plagemann further discloses wherein the first hardware privacy request comprises a request to keep a camera shutter on or off (“… a command to access data generated by a sensor may be received. The command may be determined to be impermissible by a privacy policy. Based on this determination, the state of a privacy indicator may be changed.” -e.g., see, col. 1, lines 30-33; see also: “…the privacy module … may receive a request …The privacy module may determine that the gesture data are permissible in accordance with a privacy policy or because a gesture is found in a library of known commands.” -e.g., see, col. 13, lines 9-16; see also: “If the privacy module determines that a command 55 has been issued that may be incompatible with the library of known commands, then it may change the status of a privacy indicator on the sensor to alert a user and it may close the stream pip responsible for transmission of sensor data.” -e.g., see, col. 13, lines 55-60; see also: “A message pipe may be used to update a sensor status and a stream pipe may transfer sensor data to the host controller of the device. Some sensors may have multiple stream pipes. For example, a web camera may have a microphone and a camera that utilize separate stream pipes. Each pipe may be individually controlled. Addressing endpoints and regulating pipes are understood by a skilled practitioner.” -e.g., see, col. 13, lines 40-47; herein, privacy module executes the exact camera shutter on/off action; see also, col. 7, lines 22-25).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention was to modify the teaching of Konanka by including additional feature of Plagemann in order to provide fine-grained, per-workspace hardware privacy controls on shared HIS peripherals.
As to claim 3, Konanka in view of Plagemann and Gopal discloses the IHS of claim 1, Plagemann further discloses wherein the first hardware privacy request comprises a request to turn an audio device on or off (“… a command generated by a sensor may be compared to the library of known commands and determined not to match. The command destination or memory to which the command may be stored may also be compared to a privacy policy to determine if the command is compatible with the privacy policy. The command may be determined to not match the library of known commands or to be incompatible with the privacy policy. The command may be prevented from accessing sensor databased on the determination that the command does not match the library of known commands or is incompatible with the privacy policy.” -e.g., see, col. 10, liens 54-66; see also: “Some sensors may have multiple stream pipes. For example, a web camera may have a microphone and a camera that utilize separate stream pipes. Each pipe may be individually controlled. Addressing endpoints and regulating pipes are understood by a skilled practitioner.” -e.g., see, col. 13, lines 40-47).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention was to modify the teaching of Konanka by including additional feature of Plagemann in order to provide fine-grained, per-workspace hardware privacy controls on shared HIS peripherals.
As to claim 4, Konanka in view of Plagemann and Gopal discloses the IHS of claim 1, Plagemann further discloses wherein the first hardware privacy request comprises a request to turn a display privacy or blur state on or off (“In an implementation, a privacy mode may be received. A privacy mode may refer to a private or non-private state. For example, a user may toggle a hardware Switch on a webcam to instruct the device to which the camera is connected and the camera itself to deny access to the camera's data except for those applications, devices, or services that are compliant with a privacy policy or a library of known commands or that are otherwise Verified.” -e.g., see, col. 10, lines 22-31).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention was to modify the teaching of Konanka by including additional feature of Plagemann in order to provide fine-grained, per-workspace hardware privacy controls on shared HIS peripherals.
As to clam 5, Konanka in view of Plagemann and Gopal discloses the IHS of claim 1, Plagemann further discloses wherein the program instructions, upon execution, further cause the IHS to: receive, at the workspace privacy agent, a second hardware privacy request; determine that the second hardware privacy request conflicts with the first hardware privacy request; and abstain from executing the second privacy request in response to the determination (“In some configurations, the privacy module 671 may determine that the command received from the sensor 600 (e.g., gesture) failed to match a known gesture in the database 681. If no match is detected, then the gesture may be deemed impermissible by the privacy module 671.” -e.g., see, col. 11, lines 63-67).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention was to modify the teaching of Konanka by including additional feature of Plagemann in order to provide fine-grained, per-workspace hardware privacy controls on shared HIS peripherals.
As to claim 6, Konanka in view of Plagemann and Gopal discloses the IHS of claim 5, Konanka further discloses wherein the first and second hardware privacy requests are issued by different applications executed within the first workspace (“The SWS creates a new secured, virtual desktop, which the user can work on, and intercepts file/registry operations for all applications started on this desktop.” -e.g., see, col. 10, lines 7-11).
As to claim 7, Konanka in view of Plagemann and Gopal discloses the IHS of claim 5, Konanka further discloses wherein the second hardware privacy request is issued by a second application executed in a second workspace (“The SWS creates a new secured, virtual desktop, which the user can work on, and intercepts file/registry operations for all applications started on this desktop.” -e.g., see, col. 10, lines 7-10; see also: “… the cpsws.dll can dispatch all files-related functions, including those used by the application. The cpsws.dll encrypts all data on-the-fly, and stores it to the target persistent storage in encrypted form.” -col. 11, lines 64-67; herein, hooks engine (privacy agent) receives requests from per-workspace service triggered by an application; independent per-workspace enforcement).
As to claim 8, Konanka in view of Plagemann and Gopal discloses the IHS of claim 1, Plagemann further discloses wherein the program instructions, upon execution, further cause the IHS to execute the first hardware privacy request based upon context information (“… the command may be determined to be impermissible by the privacy module. The privacy module may change the sensor's state to indicate to the user that the sensor is in a non-private state.” -e.g., see, col. 12, line 67 to col. 13, lines 1-3; herein, execution based on policy driven context).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention was to modify the teaching of Konanka by including additional feature of Plagemann in order to provide fine-grained, per-workspace hardware privacy controls on shared HIS peripherals.
As to claim 9, Konanka in view of Plagemann and Gopal discloses the IHS of claim 8, Plagemann further discloses wherein the context information comprises at least one of: an identity or a type of the first application (“A command to access data generated by a user may be received. The command may be determined to be associated with an application. A digital signature associated with the application may be verified. The digital signature may be determined to be invalid base on the verification of the digital signature associated with the application.” -e.g., see, col. 1, lines 58-63; herein, the privacy policy uses the identity or type of the requesting application via digital signature as context information when deciding how to service the hardware privacy request).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention was to modify the teaching of Konanka by including additional feature of Plagemann in order to provide fine-grained, per-workspace hardware privacy controls on shared HIS peripherals.
As to claim 10, Konanka in view of Plagemann and Gopal discloses the IHS of claim 8, Konanka further discloses wherein the context information comprises at least one of: whether the first application is in a foreground, or whether the first application is in a background (“The Secure Workspace System (SWS) works at the application level on the client side and prevents unauthorized access to a user's confidential information. The SWS creates a new secured, virtual desktop, which the user can work on, and intercepts file/registry operations for all applications started on this desktop. The system saves all sensitive user data on the user's local machine in encrypted form and deletes it when the session is terminated.” -e.g., see, col. 10, lines 5-12).
As to claim 11, Konanka in view of Plagemann and Gopal discloses the IHS of claim 8, Plagemann further discloses wherein the context information comprises at least one of: a presence state of a user, or a proximity of the user (“… a user may request a particular privacy state be maintained. In some instances, the request may be received by a physical Switch on a sensor Such as a camera. The request may also be made by a Software input or input that is received from a sensor. For example, a user may signal with a gesture that the user would like the camera to maintain a private state. Any Subsequent command to have a sensor Store or transmit data to an unverified memory or destination in a non-private manner may be blocked. For example a command to launch a Video chat application may be blocked or the application may be denied access to camera and/or microphone data” -e.g., see, col. 10, lines 4-14).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention was to modify the teaching of Konanka by including additional feature of Plagemann in order to provide fine-grained, per-workspace hardware privacy controls on shared HIS peripherals.
As to claim 12, Konanka in view of Plagemann and Gopal discloses the IHS of claim 8, Plagemann further discloses wherein the context information comprises a location of the HIS (“… the camera driver may receive the raw camera data. The data may be in two forms. One form may be camera data may be privacy irrelevant, that is, it may contain gesture data (e.g., command) as indicated at 651. The other data form of camera data may be privacy sensitive, that is, it may be stored, forwarded, or transmitted to a device that may compromise a user's privacy as indicated at 641.” -e.g., see, col.11, liens 17-23).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention was to modify the teaching of Konanka by including additional feature of Plagemann in order to provide fine-grained, per-workspace hardware privacy controls on shared HIS peripherals.
As to claim 13, Konanka in view of Plagemann and Gopal discloses the IHS of claim 8, Plagemann further discloses wherein the context information comprises a posture of the HIS (“The command may be determined to be not compatible with a privacy policy. The state of a privacy indicator may be changed based on based on the determination that the digital signature is invalid and that the command is not compatible with a privacy policy.” -e.g., see, col. 1, lines 63-67).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention was to modify the teaching of Konanka by including additional feature of Plagemann in order to provide fine-grained, per-workspace hardware privacy controls on shared HIS peripherals.
As to claim 14, Konanka in view of Plagemann and Gopal discloses the IHS of claim 8, Plagemann further discloses wherein the context information comprises calendar or meeting information (“… the command may be determined to be impermissible by the privacy module. The privacy module may change the sensor's state to indicate to the user that the sensor is in a non-private state.” -e.g., see, col. 12, line 67 to col. 13, lines 1-3; herein, execution based on policy driven context).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention was to modify the teaching of Konanka by including additional feature of Plagemann in order to provide fine-grained, per-workspace hardware privacy controls on shared HIS peripherals.
As to claim 15, Konanka in view of Plagemann and Gopal discloses the IHS of claim 8, Plagemann further discloses wherein the context information comprises at least one of: an identification of the user, an identification of a network of the IHS, an identification of hardware of the IHS, an identification of a requested datafile, or an identification of a storage system of the requested datafile (“A command to access data generated by a user may be received. The command may be determined to be associated with an application. A digital signature associated with the application may be verified. The digital signature may be determined to be invalid base on the verification of the digital signature associated with the application.” -e.g., see, col. 1, lines 58-63; herein, the privacy policy uses the identity or type of the requesting application via digital signature as context information when deciding how to service the hardware privacy request).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention was to modify the teaching of Konanka by including additional feature of Plagemann in order to provide fine-grained, per-workspace hardware privacy controls on shared HIS peripherals.
As to claim 16, Konanka in view of Plagemann and Gopal discloses the IHS of claim 8, Plagemann further discloses wherein the program instructions, upon execution, further cause the IHS to execute the first hardware privacy request based, at least in part, upon an application of a hardware privacy policy received from a workspace orchestration service to the context information (“… the command may be determined to be impermissible by the privacy module. The privacy module may change the sensor's state to indicate to the user that the sensor is in a non-private state.” -e.g., see, col. 12, line 67 to col. 13, lines 1-3; herein, privacy module applies hardware privacy policy (configured for workspace environment) to context).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention was to modify the teaching of Konanka by including additional feature of Plagemann in order to provide fine-grained, per-workspace hardware privacy controls on shared HIS peripherals.
.
As to claim 17, Konanka in view of Plagemann and Gopal discloses the IHS of claim 16, Konanka further discloses wherein the local management agent is configured to receive, from the workspace orchestration service, data configured to enable the local management agent to instantiate each of a plurality of workspaces based upon a respective one of a plurality of workspace definitions, and wherein each workspace definition identifies whether a respective workspace is subject to the hardware privacy policy (“… the manager 227 starts a usual Windows shell (e.g., explorer.exe) with an injection of the hooks engine 225 (cpSws.dll) on the created desktop. The injected hooks engine 225 in turn hooks “process creation' routines and automatically injects itself into all newly created processes. In this manner, each application 210 on the secure desktop receives a workspace hook 220. In the Microsoft Windows environment, for example, the injected DLL hooks API calls (invocations) by overwriting hooked NTDLL routines entry points with JMP instructions, thus redirecting them to code inside the cpSws.dll.” -e.g., see, col. 10, lines 32-42; herein, local management agent receives data/definitions for instantiation with policy applicability).
As to claim 18, Konanka in view of Plagemann and Gopal discloses the IHS of claim 17, Plagemann further discloses wherein the workspace orchestration service is configured to, for each of the plurality of workspaces: (i) calculate a security target based in part upon context information, and (ii) create a workspace definition based in part upon the security target, and wherein the security target is calculated by the workspace orchestration service based upon at least one of: a risk metric associated with a locale of the IHS, a risk metric associated with the user, a risk metric associated with a network of the IHS, a risk metric associated with hardware of the IHS, a risk metric associated with a requested datafile, or a regulatory risk metric associated with the user, the locale, and the requested datafile (“… the camera driver may receive the raw camera data. The data may be in two forms. One form may be camera data may be privacy irrelevant, that is, it may contain gesture data (e.g., command) as indicated at 651. The other data form of camera data may be privacy sensitive, that is, it may be stored, forwarded, or transmitted to a device that may compromise a user's privacy as indicated at 641.” -e.g., see, col.11, liens 17-23; herein, the evaluates risk based on context including data sensitivity).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention was to modify the teaching of Konanka by including additional feature of Plagemann in order to provide fine-grained, per-workspace hardware privacy controls on shared HIS peripherals.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SUMAN DEBNATH whose telephone number is (571)270-1256. The examiner can normally be reached Mon-Fri; 9:00am-5:00pm.
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, Farid Homayounmehr can be reached at 571-272-3739. 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.
SUMAN DEBNATH
Patent Examiner
Art Unit 2495
/S.D/Examiner, Art Unit 2495
/JEFFERY L WILLIAMS/Primary Examiner, Art Unit 2495
Prosecution Insights