DETAILED ACTION
This communication is responsive to the applicant’s arguments filed on 04/23/2026. Claim(s) 1,8 have been currently amended. Claims 1,3-6, 8-14 and 21 are pending examination.
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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114.
Response to arguments
Rejections based on 35 U.S.C. § 103
Applicant’s arguments with respect to claim(s) 1,3,8,9 and 21 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
A new reference Dive et al. (US 20050166064 A1), hereinafter referred to as Dive is introduced to disclose the secure input architecture and objective as the invention. Protecting sensitive keyboard input so that it reaches only intended trusted destination and cannot be intercepted by other applications is disclosed. Dive teaches that keyboard events are collected by the kernel and sent to the window server only and that the window server dispatches those events to the appropriate window’s process owner. In trusted UI mode, no input events can be globally captured or redirected, specifically to prevent an untrusted application from obtaining sensitive information typed by the user. Thus, the keyboard events correspond to the input data and trusted dialog/application process receiving those events corresponds to the input destination.
Dive also teaches the distinction between an ordinary operating system input path and a secure alternative path. Ordinarily, keyboard events travel through the OS input pipeline i.e., keyboard input is collected by the kernel, passed to the window server and dispatched to the appropriate application’s window. In the trusted mode, the same input is placed under a special protected routing regime in which other applications cannot globally capture, redirect or retrieve it. This arrangement is a trusted path between the user and the OS kernel that prevents untrusted applications from retrieving or compromising data from a trusted dialog. This trusted, access-restricted route corresponds to the secure alternative communication channel, while normal kernel or window server event dispatch corresponds to the default operating system keystroke channel.
Additionally, the trusted UI mode provides that the sensitive keyboard input is securely routed to a particular trusted destination, other applications are excluded from that input, the system distinguishes trusted operation from ordinary operation and the user can be given a visual indication when the trusted mode is active. The indicator such as an LED, screen icon or message, controlled by trusted system components to show that the trusted interface is active.
Claim Rejections - 35 USC § 103
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.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1,3,8,9 and 21 are rejected under 35 U.S.C 103 as being unpatentable over Fernandez et al. (US 20220245287 A1) hereinafter referred to as Fernandez, in view of Dive et al. (US 20050166064 A1), hereinafter referred to as Dive.
As per claim 1, Fernandez discloses one or more computer storage media comprising computer-executable instructions that when executed by a keyboard perform a method of securing communication of input data between an input destination on a computing device and the keyboard, the method comprising:
receiving, at the keyboard, a secure-mode initiation request from the input destination on the computing device, wherein the input destination is a container that is in-focus and running on the computing device; (Generating, at the computing device, a randomized keymap, and sending, from the computing device, session information data. The session information data includes first data that identifies the user, second data that identifies a communication session between the keyboard and the computing device, and third data that identifies the randomized key map, Fernandez, para [0010]).
in response to the secure-mode initiation request, activating, at the keyboard, a secure mode of communication between the keyboard and the input destination; (After the computer receives the activation notification and user ID, the computer generates a session token, Fernandez, para [0012]. Once the keyboard receives the session information (token, map), it activates the secure encrypted mode of communication).
generating, by the keyboard, input data in response to a user input; (The keyboard includes a processor that encrypts generated keystroke signals according to a key map, and transmits the encrypted keystroke signals, Fernandez, para [0011])
encrypting, by the keyboard, the input data to generate encrypted input data; (The processor translates the keystroke data into encrypted keystroke data using the encryption key. The encrypted keystroke data is then sent to the computer 170 via a serial connection 150 between the keyboard 10 and the computer 170, Fernandez, para [0019]- [0020]).
However, Fernandez does not explicitly disclose the limitations:
communicating, by the keyboard, the encrypted input data to the input destination over
receiving, at the keyboard, a secure mode termination request from the input destination in response to the container losing focus;
in response to the secure-mode termination request, activating, at the keyboard, a standard mode of communication between the keyboard and the computing device;
generating, by the keyboard, new input data in response to a new user input; and
communicating, by the keyboard, the new input data to the computing device over
Dive discloses:
communicating, by the keyboard, the encrypted input data to the input destination over (Input events such as keyboard, mouse and pen are collected by the kernel and sent to the window server only. The window server is responsible for dispatching events to the appropriate window’s process owner. The architecture provides a trusted path between the user and the OS kernel. In trusted UI mode no input events can be globally captured or redirected. User generated keyboard events are retrieved from the kernel only by the window server and in the trusted UI cannot be retrieved by a process other than he trusted dialog owner, Dive, para [0024], [0028])
receiving, at the keyboard, a secure mode termination request from the input destination in response to the container losing focus; (TApp asks WSERV to close its trusted session, Dive, para [0160]. Here, the TApp is an input destination or container. TApp’s request to WSERV to close the trusted UI session is analogous to a termination request).
in response to the secure-mode termination request, activating, at the keyboard, a standard mode of communication between the keyboard and the computing device; (WSERV closes TApp’s trusted session upon receiving the closing request and input events such as keyboard events are collected by the kernel, Dive, para [0161]. After the trusted application requests closure, WSERV closes the secure session and instructs the kernel to restore the ordinary frame buffer and turn off the secure indicator. The standard mode is an ordinary input event handling outside the trusted UI session).
generating, by the keyboard, new input data in response to a new user input; and (Input events generated by the user, Dive, claim 11. Keyboard, mouse and pen events are identified as user generated input events retrievable from the kernel only by the window server. Accordingly, a user’s keypress produces a new keyboard input event which aligns with the new input data)
communicating, by the keyboard, the new input data to the computing device over (Dispatching events to the appropriate window's process owner, Dive, para [0024]. The OS kernel collects keyboard events, sends them to the window server and the window server dispatches the, to the appropriate application’s window owner. After trusted mode terminates, keyboard events flow through the OS mediated input architecture without the trusted dialog restrictions)
A person of ordinary skill in the art before the effective filing date of the claimed invention would have combined Fernandez and Dive by encrypted human interface keyboard (Fernandez) and trusted UI for a secure device (Dive). It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine Fernandez with Dive in order to effectively prevent interception of sensitive keystrokes and provide predictable end to end protection of user input (See Dive, para [0024]).
As per claim 3, Fernandez and Dive disclose the media of claim [[2]]1 wherein
Furthermore, Fernandez discloses:
the input destination has a decryption key for the encrypted input data (The computing device includes: a processor operable to decrypt the encrypted keystroke signals transmitted from the keyboard to the computing device using the key map and a display device operable to display the decrypted keystroke signals, Fernandez, claim 2).
As per claim 8, Fernandez discloses a method of securing communication of input data between a input destination on a computing device and a keyboard, the method comprising:
communicating, from the input destination on the computing device, a secure-mode initiation request to a security application running on the keyboard, wherein the input destination is a container that is in-focus and running on the computing device; (Generating, at the computing device, a randomized keymap, and sending, from the computing device, session information data. The session information data includes first data that identifies the user, second data that identifies a communication session between the keyboard and the computing device, and third data that identifies the randomized key map, Fernandez, para [0010])
decrypting, by the input destination and using the secret key, the encrypted input data to generate a usable input to the input destination (The computing device includes: a processor operable to decrypt the encrypted keystroke signals transmitted from the keyboard to the computing device using the key map and a display device operable to display the decrypted keystroke signals, Fernandez, claim 2).
communicating, from the container, a secret key to use in encryption to the security application running on the keyboard; (The computing device includes: a processor operable to decrypt the encrypted keystroke signals transmitted from the keyboard to the computing device using the key map and a display device operable to display the decrypted keystroke signals, Fernandez, claim 2).
However, Fernandez does not explicitly disclose the limitations:
in response to the secure-mode initiation request, receiving over an alternative communication channel that is different from a default operating-system keystroke channel, by the input destination, encrypted input data from the keyboard, wherein the encrypted input data was encrypted on the keyboard; and
Dive discloses:
in response to the secure-mode initiation request, receiving over an alternative communication channel that is different from a default operating-system keystroke channel, by the input destination, encrypted input data from the keyboard, wherein the encrypted input data was encrypted on the keyboard; and (Input events such as keyboard, mouse and pen are collected by the kernel and sent to the window server only. The window server is responsible for dispatching events to the appropriate window’s process owner. The architecture provides a trusted path between the user and the OS kernel. In trusted UI mode no input events can be globally captured or redirected. User generated keyboard events are retrieved from the kernel only by the window server and in the trusted UI cannot be retrieved by a process other than he trusted dialog owner, Dive, para [0024], [0028])
A person of ordinary skill in the art before the effective filing date of the claimed invention would have combined Fernandez and Dive by encrypted human interface keyboard (Fernandez) and trusted UI for a secure device (Dive). It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine Fernandez with Dive in order to effectively prevent interception of sensitive keystrokes and provide predictable end to end protection of user input (See Dive, para [0024]).
As per claim 9, Fernandez and Dive disclose the method of claim 8, further comprising
Furthermore, Dive discloses:
outputting through a user interface, associated with the input destination, an attestation that a secure mode is active (A particular symbol/logo on trusted dialogs, Dive, para [0117]. Symbol or logo displayed on the trusted dialog is analogous to the attestation. The trusted UI is active and the visual indication of trusted UI status including a screen icon or message is disclosed. A visual indication of trusted UI status, including a screen icon or message changed when trusted UI is enabled or disabled, is disclosed).
A person of ordinary skill in the art before the effective filing date of the claimed invention would have combined Fernandez and Dive by encrypted human interface keyboard (Fernandez) and trusted UI for a secure device (Dive). It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine Fernandez with Dive in order to effectively prevent interception of sensitive keystrokes and provide predictable end to end protection of user input (See Dive, para [0024]).
As per claim 21, Fernandez and Dive disclose the media of claim 1, wherein the method further comprises
Furthermore, Dive discloses:
outputting, by the keyboard, a visual attestation on the keyboard that the secure mode is active (A trusted LED which goes on when a trusted user interface interaction occurs, Dive, para [0116]. The trusted LED is the visual attestation. The LED is turned on during a trusted UI interaction and switched off at its end which indicates the secure mode is active).
A person of ordinary skill in the art before the effective filing date of the claimed invention would have combined Fernandez and Dive by encrypted human interface keyboard (Fernandez) and trusted UI for a secure device (Dive). It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine Fernandez with Dive in order to effectively prevent interception of sensitive keystrokes and provide predictable end to end protection of user input (See Dive, para [0024]).
Claim(s) 4 are rejected under 35 U.S.C 103 as being unpatentable over Fernandez et al. (US 20220245287 A1) hereinafter referred to as Fernandez, in view of Dive et al. (US 20050166064 A1) in further view of Ozolins et al. (US 11403379 B2), hereinafter referred to as Ozolins
As per claim 4, Fernandez and Dive disclose the media of claim 1,
However, Fernandez in view of Dive does not explicitly disclose the limitation:
in response to the secure-mode initiation request, communicating, by the input device, authentication data to the input destination
Ozolins discloses:
in response to the secure-mode initiation request, communicating, by the input device, authentication data to the input destination (A client computer may transmit request and the security device communicates with the computing device to authenticate the user, Ozolins, col 1, lines 49-52).
A person of ordinary skill in the art before the effective filing date of the claimed invention would have combined Fernandez with Dive by encrypted human interface keyboard (Fernandez) and trusted UI for a secure device (Dive) with computer keyboard with secure authentication features (Ozolins). It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine Fernandez and Dive with Ozolins in order to secure user authentication integrating hardware-based security into keyboard (See Ozolins, col 1, lines 49-52)
Claim 5 is rejected under 35 U.S.C 103 as being unpatentable over Fernandez et al. (US 20220245287 A1) hereinafter referred to as Fernandez, in view of Dive et al. (US 20050166064 A1) in further view of Matthews et al (US 20160344717 A1).
As per claim 5, Fernandez and Dive discloses the media of claim 4, wherein
However, Fernandez in view of Dive does not explicitly disclose the limitation:
the authentication data includes an authentication certificate.
Matthews discloses:
the authentication data includes an authentication certificate (The server authentication data, such as a certificate (as an example), is data that is used by the candidate node 150 to configure the node 150 for authentication by the server 122-1 when the server 122-1 communicates with the node 150 over a secured temporary network 170, Matthews, para [0014]).
A person of ordinary skill in the art before the effective filing date of the claimed invention would have combined Fernandez and Dive with Matthews by encrypted human interface keyboard (Fernandez) and trusted UI for a secure device (Dive) with communicating a cluster and a node (Matthews). It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine Fernandez and Sikka with Matthews in order to use an authentication certificate to authentication a device (See Matthews, para [0014])
Claim(s) 10, 14 are rejected under 35 U.S.C 103 as being unpatentable over Fernandez et al. (US 20220245287 A1) hereinafter referred to as Fernandez, in view of Dive et al. (US 20050166064 A1) in further view of Pemmaraju et al (US 20140040635 A1), hereinafter referred to as Pemmaraju.
As per claim 10, Fernandez and Dive disclose the method of claim 8, wherein
However, Fernandez in view of Dive does not explicitly disclose the limitation:
the input destination is an application in control focus.
Pemmaraju discloses:
the input destination is an application in control focus (When a user presses a key on the keyboard, the keyboard device driver receives scan codes from the keyboard, which are sent to the keyboard layout where they are translated into messages and posted to the appropriate window in the application, Pemmaraju, claim 10 and para [0009]. Securing keystrokes between a keyboard and an application on a computing device).
A person of ordinary skill in the art before the effective filing date of the claimed invention would have combined Fernandez and Dive with Pemmaraju by encrypted human interface keyboard (Fernandez) and trusted UI for a secure device (Dive) with securing keystrokes from being intercepted between a keyboard and browser (Pemmaraju).It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine Fernandez and Dive with Matthews in order to in order to enable the user to enter sensitive information without the keystrokes being intercepted (See Pemmaraju, para [0009]).
As per claim 14, Fernandez and Dive disclose the method of claim 8, wherein
However, Fernandez in view of Dive does not explicitly disclose the limitation:
the security application for the keyboard is installed on the keyboard
Pemmaraju discloses:
the security application for the keyboard is installed on the keyboard (Keylogger is a software program that runs in the background and they can be bundled as a part of software that a user downloads for free, Pemmaraju, para [0006]- [0008]).
A person of ordinary skill in the art before the effective filing date of the claimed invention would have combined Fernandez and Dive with Pemmaraju by encrypted human interface keyboard (Fernandez) and trusted UI for a secure device (Dive) with securing keystrokes from being intercepted between a keyboard and browser (Pemmaraju).It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine Fernandez and Dive with Matthews in order to in order to enable the user to enter sensitive information without the keystrokes being intercepted (See Pemmaraju, para [0009]).
Claim(s) 11,12 and 13 are rejected under 35 U.S.C 103 as being unpatentable over Fernandez et al. (US 20220245287 A1) hereinafter referred to as Fernandez, in view of Dive et al. (US 20050166064 A1) in further view of Mathur et al. (US 20150379287 A1), hereinafter referred to as Mathur.
As per claim 11, Fernandez and Dive disclose the method of claim 8,
wherein
However, Fernandez in view of Dive does not explicitly disclose the limitation:
Mathur discloses:
the input destination is a container that leverages a host operating system, wherein the host operating system is installed on the computing device (A security layer is deployed with the container and mediates access between the container and the host OS, Mathur, para [0032]. This is an idea of an input destination being a container and the container is described as leveraging the host OS by depending on OS services through the mediated layer).
A person of ordinary skill in the art before the effective filing date of the claimed invention would have combined Fernandez and Dive with Mathur by encrypted human interface keyboard (Fernandez) and trusted UI for a secure device (Dive) with provision of secure application containers (Mathur). It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine Fernandez and Dive with Mathur in order to in order to in order to effectively reduce data security threats (See Mathur, para [0032])
As per claim 12, Fernandez and Dive disclose the method of claim 8, further
comprising
However, Fernandez in view of Dive does not explicitly disclose the limitation:
receiving, in response to the secure-mode initiation request, a validation certificate for the keyboard
Mathur discloses:
receiving, in response to the secure-mode initiation request, a validation certificate for the keyboard (During the configuration of the application container, the application may be authorized and given a unique and secure identifier such as a digital certificate, Mathur, para [0023]).
A person of ordinary skill in the art before the effective filing date of the claimed invention would have combined Fernandez and Dive with Mathur by encrypted human interface keyboard (Fernandez) and trusted UI for a secure device (Dive) with provision of secure application containers (Mathur). It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine Fernandez and Dive with Mathur in order to in order to in order to effectively reduce data security threats (See Mathur, para [0032])
As per claim 13, Fernandez and Dive disclose the method of claim 8, wherein
However, Fernandez in view of Dive does not explicitly disclose the limitation:
the security application for the keyboard is associated with a driver for the keyboard, wherein the driver and the security application are installed at a driver layer of an operating system installed on the computing device
Mathur discloses:
the security application for the keyboard is associated with a driver for the keyboard, wherein the driver and the security application are installed at a driver layer of an operating system installed on the computing device (The security layer may be implemented as part of the OS as a kernel module or at a virtualization layer, Mathur, para [0059]).
A person of ordinary skill in the art before the effective filing date of the claimed invention would have combined Fernandez and Dive with Mathur by encrypted human interface keyboard (Fernandez) and trusted UI for a secure device (Dive) with provision of secure application containers (Mathur). It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine Fernandez and Dive with Mathur in order to in order to in order to effectively reduce data security threats (See Mathur, para [0032])
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to RAGHAVENDER CHOLLETI whose telephone number is (703) 756-1065. The examiner can normally be reached M-F 9am-5pm ET.
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, RUPAL DHARIA can be reached on (571) 272-3880. 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.
Respectfully submitted,
/RAGHAVENDER NMN CHOLLETI/Examiner, Art Unit 2492
/RUPAL DHARIA/Supervisory Patent Examiner, Art Unit 2492
