Abstract: A challenge string is sent from a server to an authentication card. The challenge string is encrypted using a private key on the authentication card. Then, the encrypted challenge string is sent as a response from the authentication card to the server. A unique identifier of the authentication card is correlated to a user record residing at the server to obtain an authentication certificate from within the user record. The authentication certificate includes a public key. The public key from the authentication certificate is used to decrypt the response at the server. A determination is then made as to whether the decrypted response matches the challenge string as originally sent from the server to the authentication card. If the decrypted response matches the original challenge string, the authentication is successful. Otherwise, the authentication fails.

Abstract: A patch or set of patches may be deployed, often to a subset of potentially vulnerable systems, to address a particular vulnerability while providing a facility to monitor and, in some cases, characterize post-patch exploit attempts. Often, such a patch will check for an exploit signature and, if an exploit attempt is detected or suspected, take an appropriate action. For example, the patch may include code to log indicative data or trigger such logging. In some exploitations, the patch may generate or contribute to a warning or advisory regarding an additional target (or targets) of the exploit and, if appropriate, initiate a patch or protective measure for the additional target(s). In some exploitations, the patch may simulate responses or behaviors suggestive (to an attacker) of unpatched code. In some exploitations, the patch may direct an exploit attempt to a service (or simulated service) hosted or executing in an isolated protection domain.

Abstract: Processing circuitry is integrated within a hardware security module (HSM) chip card. The processing circuitry is configured to operate in accordance with a set of program instructions stored in a memory integrated within the HSM chip card. The set of program instructions includes program instructions for implementing a public-key cryptography standard (PKCS). The PKCS includes processes for generating and storing a master key. The master key is to be stored in the memory integrated within the HSM chip card. Also, using the master key stored in the memory of the HSM chip card, the HSM chip card enables direct management control of standard chip cards.

Abstract: A system and method provides dynamic and static type support for multiple definitions of individual types in a distributed object environment. Fully scoped object names incorporating prefixes are used to distinguish objects. The fully scoped names are used for both dynamic type determination through an interface repository and for statically compiled types in client and server stub routines. In the interface repository, a prefix naming context is provided for each root interface definition language context, allowing multiple definitions for objects with the same interface definition language object name, where each such definition resides in a separate prefix naming context. In one embodiment, the prefix naming contexts are defined by prefix interface definition objects. In another embodiment, the fully scoped object names are embedded by an interface definition language compiler in stub and skeleton code routines. RRS.

Abstract: A number of methods, apparatus, and data structures are disclosed for managing computer processes. In one aspect, a daemon process which manages server processes includes an active server table and a locator service. The locator service can look up and register server processes in the active server table. Furthermore, the locator service can start up server processes. In some embodiments, the locator service includes a look-up object and a server process registration object which perform the tasks of the locator service. In other embodiments, methods for managing server process such as starting and registering the server processes are taught. In one specific method, a daemon process performs a variety of steps in response to receiving a look-up call for a target object. These steps include obtaining a server identifier for the target object, determining the state of a server process, and returning addressing information corresponding to the server process under which the target object will activate.

Abstract: A variety of methods, apparatus and data structures for managing collections of objects are described. In one aspect of the invention, an object that is intended for use in a distributed object operating environment has a structure including a group designation, a co-activation designation and a co-process designation. The group designation is arranged to identify a group to which the object belongs. The group is defined as a collection of objects which share a common persistent state. The co-activation designation is arranged to identify a co-activation set to which the object belongs. The co-activation set is a collection of objects which are to be activated at the same time. The co-process designation is arranged to identify a co-process set to which the object belongs. The co-process set is a collection of objects which are to be activated within a single process.

Abstract: A number of methods, apparatus, and data structures are disclosed for managing computer processes. In one aspect, a daemon process which manages server processes includes an active server table and a locator service. The locator service can look up and register server processes in the active server table. Furthermore, the locator service can start up server processes. In some embodiments, the locator service includes a look-up object and a server process registration object which perform the tasks of the locator service. In other embodiments, methods for managing server process such as starting and registering the server processes are taught. In one specific method, a daemon process performs a variety of steps in response to receiving a look-up call for a target object. These steps include obtaining a server identifier for the target object, determining the state of a server process, and returning addressing information corresponding to the server process under which the target object will activate.

Abstract: A method of checking the type of an object located on a remote computer in a distributed object environment computing system is disclosed. Initially, a type checking method to determine whether a remotely located object is of a specified type is invoked. In the invocation, a target interface identifier is included as an argument. A determination is then made as to whether the target interface identifier is equal to or a base for an apparent interface identifier held by a proxy object located on the first computer. If the target interface identifier is determined to be equal to or a base for the apparent interface identifier, an affirmative indication to that effect is returned to the client process. If not, then the target interface identifier is then compared to a real interface identifier. In many embodiments, a call to the server host will have to be made in order to determine the real interface identifier.

Abstract: A method and apparatus for extensible inter-application link management is disclosed. The apparatus is independent of the applications that manipulates the anchors linked by the links being managed. Anchors linked may reside on the same or different computers on a network. Links managed comprise navigation links and include links. Links managed may be further extended with application defined links. Application defined links may or may not require support by additional application provided link maker programs. Application defined links may inherit linking operations managed from the navigation link, include link and other existing application defined links with or without override.

Abstract: A method and apparatus for object oriented interprocess message switching between a sender process and a plurality of receiver processes is disclosed. A sender process may address object oriented messages to a plurality of objects without knowing the identities of programs that handle or observe the object operations defined by the object types of the addressee objects, whether these programs are being executed, and how to start their execution if they are not being executed. Object operations defined by object types may be inherited from predecessor object types. Inherited object operations may also be overridden for "pre-processing" and "post-processing". One handler process and any number of observer processes are selected for each object oriented message. Handler processes are selected for object oriented notice messages as well as object oriented request messages and vice versa. Executing as well as non-executing processes (i.e. programs) are selected.

Abstract: A method and apparatus for interprocess message switching between a sender process and a plurality of receiver processes is disclosed. Messages supported comprise request and notice messages. Receiver processes supported comprise handler processes and observer processes. Request messages may be observed as well as handled, and notice messages may be handled as well as observed. Handler and observer processes may be non-executing as well as executing. Sender processes do not need to specify the identity of the receiver processes. The sender process and the receiver processes may be executed on the same computer or on two or more computers in a network.

Abstract: A method and apparatus for scoped interprocess message switching between a sender process and a plurality of receiver processes is disclosed. Messages supported may be scoped to message scopes of a message scope type of "Session" or one of a plurality of non-session message scope types including a message scope type of "File". Messages may also be scoped to message scopes of an intersection or union of message scope types. Intersection and union of message scope types comprise "File in Session" and "File or Session". Scoped messages supported further comprise request and notice messages. Receiver processes supported comprise handler processes and observer processes. Request messages may be observed as well as handled, and notice messages may be handled as well as observed. Handler and observer processes may be non-executing as well as executing. Local receiver processes are selected for session scoped messages. Remote as well as local receiver processes are selected for non-session scoped messages.