Abstract: A storage token has a display and a keyboard, or other input device, that allows a user to view a request to access a memory location and enter a response to the request. The display allows presentation of details of the request, such as a pathname to a requested memory location, metadata describing a cryptographic key for use in a transaction confirmation, and/or transaction details which are awaiting verification by a credential stored on the token. The storage token may also include a cryptographic engine and a secure memory allowing signing data returned in response to the request.

Abstract: Described is a technology by which a transient storage device or secure execution environment-based (e.g., including an embedded processor) device validates a host computer system. The device compares hashes of host system data against valid hashes maintained in protected storage of the device. The host data may be a file, data block, and/or memory contents. The device takes action when the host system data does not match the information in protected storage, such as to log information about the mismatch and/or provide an indication of validation failure, e.g., via an LED and/or display screen output. Further, the comparison may be part of a boot process validation, and the action may prevent the boot process from continuing, or replace an invalid file. Alternatively, the validation may take place at anytime.

Abstract: A token or other storage device uses Internet identities to set file access attribute rights. Subsequently, requests to access a file can be controlled by confirming the Internet identity of the requestor by either validating the request with a known public key or retrieving the public key from an Internet identity provider. Files may be stored encrypted and may be re-encrypted with the public key associated with Internet identity making the request.

Abstract: Described is a technology by which files that are hardware protected on a storage device, such as a USB flash drive, are managed on a host, including by integration with an existing file system. Each file maintained on a storage device is associated with a protection attribute that corresponds to that file's device hardware protection level. Requests directed towards accessing metadata or actual file data are processed based upon the protection attribute and a state of authentication, e.g., to allow or deny access, show file icons along with their level of protection, change levels, and so forth. Also described is splitting a file system file table into multiple file tables, one file table for each level of protection. Entries in the split file tables are maintained based on each file's current level; space allocation tracking entries are also maintained to track the space used by other split tables.

Abstract: A software firewall that may be configured using rules specified for types of network interfaces rather than individual network interfaces. The network types may be specified with type identifiers that have a readily understandable meaning to a user, facilitating ease of configuring the firewall. The network types could include, for example, wired, wireless and remote access. A rule specified based on a network type can be implemented for network interfaces of that network type. The implementation may be performed automatically and may be updated based on network location awareness information.

Abstract: A software firewall that may be configured using rules specified for types of network interfaces rather than individual network interfaces. The network types may be specified with type identifiers that have a readily understandable meaning to a user, facilitating ease of configuring the firewall. The network types could include, for example, wired, wireless and remote access. A rule specified based on a network type can be implemented for network interfaces of that network type. The implementation may be performed automatically and may be updated based on network location awareness information.

Abstract: A system maintains a dormant state in the host, in which no beacons (or “bubbles”) are transmitted from the host when no application or service (collectively, “processes”) of the host is accepting unsolicited traffic via the edge traversal service. When at least one application or service begins to accept unsolicited traffic via the edge traversal service, the host enters a qualified state and begins transmitting the beacons. As each additional application or service begins to accept such traffic, the number of accepting applications and services is maintained. As applications and services terminate acceptance of such traffic, the number of accepting applications and services is decremented. When the last application or service terminates acceptance of unsolicited traffic via the edge traversal service, the host re-enters the dormant state and ceases transmission of its beacons.

Abstract: Some embodiments of the invention are directed to techniques for determining whether a process on a computer system that is sending or receiving data, or is attempting to send or receive data, with another computer system is executing in kernel mode or user mode and providing an indicator of this determination to a security engine. In some embodiments, such an indication is provided to a security engine (e.g., a firewall) that implements a security policy based at least in part on whether the sending or receiving process is in kernel mode or user mode, and filter communications based on a process' operating mode. This enables a security engine to maintain security policies of greater specificity and thus improve security of a computer system.

Abstract: Versioning management provides for efficient and effective handling of varying policy versions, client versions and client platform versions in one system. Software version negotiation provides for simplified, secure policy management in an environment supporting varying versions of the same software product. In conjunction with parameter stripping, which resolves differences among varying minor versions of a software policy, software version negotiation allows for management tools of one version to manage client software, clients and/or client platforms of another version. Policy schema translation, in conjunction with parameter stripping as needed, provides a mechanism for converting policies that normally would be impossible to interpret on varying clients and/or client platforms to policy versions that can be understood by these clients and/or client platforms.

Abstract: Described is a technology by which a transient storage device or secure execution environment-based (e.g., including an embedded processor) device validates a host computer system. The device compares hashes of host system data against valid hashes maintained in protected storage of the device. The host data may be a file, data block, and/or memory contents. The device takes action when the host system data does not match the information in protected storage, such as to log information about the mismatch and/or provide an indication of validation failure, e.g., via an LED and/or display screen output. Further, the comparison may be part of a boot process validation, and the action may prevent the boot process from continuing, or replace an invalid file. Alternatively, the validation may take place at anytime.

Abstract: Embodiments of the present invention are directed to establishing and/or implementing firewall rules that may employ parameters based on connection security levels for a connection between devices. A firewall may thus provide greater granularity of security and integrate more closely with other security methods to provide better overall security with fewer conflicts.

Abstract: In embodiments of HID over simple peripheral buses, a peripheral sensor receives inputs from a peripheral device, and the peripheral sensor implements an HID SPB interface to interface the peripheral device with a computing system via a simple peripheral bus (SPB) in an HID data format. The peripheral sensor can also receive extensibility data for a proprietary function of the peripheral device, and communicate the inputs from the peripheral device and the extensibility data via the simple peripheral bus in the computing system. Alternatively or in addition, a peripheral sensor can generate sensor data and the HID SPB interface interfaces the peripheral sensor with the computing system via the simple peripheral bus. The peripheral sensor can then communicate the sensor data as well as extensibility data for a proprietary function of the peripheral sensor via the simple peripheral bus in the HID data format to the computing system.

Abstract: A method for cooling an electronic device having first and second flow paths for transmitting a coolant. The method includes assessing a merit of impelling the coolant along the first flow path relative to impelling the coolant along the second flow path. When the relative merit is above a threshold, coolant is impelled along the first flow path. When the relative merit is below the threshold, coolant is impelled along the second flow path.

Abstract: Server-side validation of hardware specific software product licenses is described herein.

Abstract: In embodiments of HID over simple peripheral buses, a peripheral sensor receives inputs from a peripheral device, and the peripheral sensor implements an HID SPB interface to interface the peripheral device with a computing system via a simple peripheral bus (SPB) in an HID data format. The peripheral sensor can also receive extensibility data for a proprietary function of the peripheral device, and communicate the inputs from the peripheral device and the extensibility data via the simple peripheral bus in the computing system. Alternatively or in addition, a peripheral sensor can generate sensor data and the HID SPB interface interfaces the peripheral sensor with the computing system via the simple peripheral bus. The peripheral sensor can then communicate the sensor data as well as extensibility data for a proprietary function of the peripheral sensor via the simple peripheral bus in the HID data format to the computing system.

Abstract: A firewall helps a user make a decision regarding network access for an application executing on a computing device by providing “hints” to the user about an appropriate network access policy. If at least one previously set firewall policy for the application exists in a context different from a current context, the user may be presented with information based on a previously set firewall policy. The information may be prioritized based on a source of the previously set firewall policy and other factors, to provide the user with a hint that facilitates making the decision appropriate in the current context. A programming interface to the firewall allows third party applications to specify a format in which hints are provided to the user.

Abstract: In embodiments of human interface device (HID) over simple peripheral buses, a peripheral sensor receives inputs from a peripheral device, and the peripheral sensor implements an HID SPB interface to interface the peripheral device with a computing system via a simple peripheral bus (SPB) in an HID data format. The peripheral sensor can receive extensibility data for a proprietary function of the peripheral device, and communicate the inputs from the peripheral device and the extensibility data via the simple peripheral bus in the computing system. Alternatively or in addition, a peripheral sensor can generate sensor data and the HID SPB interface interfaces the peripheral sensor with the computing system via the simple peripheral bus. The peripheral sensor can then communicate the sensor data as well as extensibility data for a proprietary function of the peripheral sensor via the simple peripheral bus in the HID data format to the computing system.

Abstract: Embodiments of the invention described herein are directed to a mechanism for determining whether at least one operation will be effective in view of at least one security policy. In exemplary implementations, determining whether at least one operation will be effective in view of at least one security policy may comprise determining a merged security policy for a computer system by merging security policies for the computer system from two or more sources. The security policies may be security policies set by a user and/or an administrator of the computer system, may be security policies of a computer network to which the computer system is connected, or may be security policies of one or more other computer systems that are above the computer system in a computer network hierarchy.

Abstract: An information system is provided that uses information derived from real time data sources to identify a potential current relationship between two or more users or entities, including individuals, organizations, and groups of individuals, based on the similarity between the real data sources, and entities associated with the real time data. Given the potential for a relationship, a connection between the users can be initiated.

Abstract: A computing environment in which devices interoperate with a plurality of hardware components. Inconsistencies in user experience when operating devices that may use different components are avoided by generating a signature for the components. The signature may be computed as a function of a first key and one or more parameter values obtainable from the component. The signature and parameter values may be stored in the component's memory, and may be obtainable while the component is in operation as part of the computing device. The device may validate the component by performing at least one function based on the signature, the one or more parameter values obtainable from the component, and a second key, which may or may not be identical to the first key. The device may change its interaction with the component, depending on whether the component was successfully validated.