Method for asymmetric security
Summary by NHIP
Asymmetric message security method
The method processes incoming messages at one security level and replies with a different level based on message sensitivity. It selects these levels from available options to minimize security resource use while keeping both messages in a single session.
Claim Score by NHIP
Abstract
A method is disclosed for asymmetric security in data communications between two or more nodes. Asymmetric security within data communications refers to sending and receiving messages at different security levels. The method includes a receiving module, a transmission module, and a communication module. The receiving module receives a first message at a first security level from a first node. A security level may be defined by implementation of one or more security features, including encryption, digital signatures, and/or other security features. The transmission module transmits a second message at a second security level to the first node in response to receiving the first message. The first and second messages may be communicated during a single communication session. The communication module communicates the second security level to the first node. The communication may be directly between two nodes or may occur via a broker or other intermediate node.

Term
Projected expiry 31 October 2027.
- Priority and filed
- Granted
- Today
- Projected expiry
8 claims: 1 independent, 7 dependent
- 1Broadest claimClaim Score 36, narrow(NHIP)A method for asymmetric message security, the method comprising:receiving a first message at a second node, the first message received from a first node, the first message secured at a first security level, the first security level actively selected from a plurality of available security levels, the first security level selected in accordance with a sensitivity level of the first message, wherein the first node and the second node comprise a central processing unit and an electronic storage device;processing the first message according to the first security level to make the first message usable by the second node;selecting a second security level for a second message, the second security level is a different security level than the first security level, the second security level selected from the plurality of available security levels, the second security level selected in accordance with a sensitivity level of the second message, wherein the first security level and the second security level are selected to minimize use of security resources;applying the selected second security level to the second message;transmitting the second message at the second security level to the first node in response to receiving the first message, the first message and the second message together communicated within a single communication session;and communicating the second security level to the first node.
86 paragraphs in 4 sections, as filed
BACKGROUND OF THE INVENTION
1. Field of the Invention
This invention relates to data communications and more particularly relates to asymmetric security of data communications.
2. Description of the Related Art
Node-to-node security, also referred to as link level security, guarantees that data is secure while being transferred from one node to another within a communication system. Data security can encompass multiple aspects. Two common aspects of data security are integrity and privacy considerations. Integrity security employs a technology, such as digital signatures, to prevent data from being tampered with or forged by an unauthorized party. By using a digital signature, a receiver or destination node may be able to verify the sender's identity and know if the data has been altered or forged. Privacy security employs a technology, such as encryption, to restrict access to sensitive data and, thereby, prevent disclosure to or collection by an unauthorized party. One, both, or neither of these security technologies may be employed for the transmission of data.
A common implementation of link level security is secure socket layer (SSL), which is a transport layer security technology that encrypts data during data transmission between two nodes. Additionally, SSL does not provide end-to-end security for asynchronous communications.
<figref idrefs="DRAWINGS">FIG. 1</figref> shows a communication system that includes three nodes. When the source node sends a communication to the destination node, the data may pass through the intermediate node. The communication between the source node and the intermediate node is a synchronous communication because the intermediate node is actively participating in the communication. Once the intermediate node receives the data from the source node, the intermediate node may store the data on a storage device, such as a hard disk drive. The intermediate node subsequently initiates a synchronous communication with the destination node to deliver the data. In this way, the data may be communicated from the source node to the destination node.
By implementing SSL for the data communication, the data is secure during the transmission from the source node to the intermediate node and from the intermediate node to the source node. However, the data is not secure while stored on the electronic storage device or other data retention device on the intermediate node. This insecure storage of the data on the intermediate node provides an opportunity for an unauthorized party to access and potentially tamper with the insecure data. Although SSL provides link level security, it cannot ensure end-to-end security of the data communication. End-to-end security guarantees that data is secure during the entire communication process from the source node to the destination node.
The conventional SSL technology also fails to address the issue of performance on the communication system. By implementing a transport layer security technology such as SSL, the communication system cannot discriminate between data communications that should be protected and those that do not need to be protected. Rather, the communication system simply protects all communications to the extent possible. However, this protection has a very high operating cost due to the time and processing that is required to ensure privacy of the data communications.
Another conventional security technology that was introduced for internet communications is secure hypertext transfer protocol (S-HTTP). S-HTTP, similar to SSL, implements encryption technology to secure the privacy of a data communication. Additionally, although S-HTTP is an application layer security technology, S-HTTP is not widely accepted because it has many disadvantages.
One of the disadvantages of S-HTTP is that it is protocol-specific—it is designed specifically for the HTTP protocol and is not used with any other protocols. Also, S-HTTP does not provide true end-to-end security in a multi-node communication system having intermediate nodes. Rather, S-HTTP is a link level security technology that provides security between an HTTP client and an HTTP server. S-HTTP is also limited, similar to SSL, to synchronous communications because it is a request-response communication protocol. Additionally, S-HTTP also fails to address the performance of the communication system—S-HTTP applies security features to all messages, regardless of the nature of the message.
In additional to the several disadvantages of SSL and S-HTTP listed above, conventional data security technologies operate within symmetric security environments. Symmetric security within data communications refers to sending and receiving messages at the same security levels. For example, within a single communication session either all of the incoming and outgoing messages are encrypted or none of the messages are encrypted. Additionally, when the security features are applied to the data communications, the same security features are applied to all of the data communications, regardless of the need for or usefulness of such security features for some of the non-critical data. In this way, conventional security technologies fail to address the performance of the system for the various messages communicated each way within a communication session.
For example, referring to <figref idrefs="DRAWINGS">FIG. 1</figref>, the source node may communicate various types of messages (shown by different shapes) to the destination node. Some of these messages may require security in the way of encryption and/or integrity. Other messages may not require security during the transmission to the destination node. Likewise, some of the messages may only require one-way security or, in other words, security when transferred to the destination node but not when transferred from the destination node to the source node. Implementation of one-way security is not possible in a symmetric communication system in which all of the communications between the source node and the destination node are sent at a single security level.
There are overhead costs for generally applying security features to data communications, such as encrypting all data, no matter whether the data is critical or not. In some cases, only data flowing in one direction needs to be secure. In other situations, certain message types may need to be secure while others do not. Still further, some types of messages may need to be secure in one direction and not in the other direction. For example, a client in a client-server system may request some large documents from the server. The server may need some sensitive user information to authenticate the user and, hence, the client request needs to be secure. However, if the response from the server to the client contains large documents that are neither sensitive nor critical, the performance of the server may be improved by not encrypting or otherwise securing the large documents. Unfortunately, symmetric security technologies do not allow for this enhanced performance due to the general application of security features to all data communications.
From the foregoing discussion, it should be apparent that a need exists for a method for asymmetric security, in which incoming and outgoing messages may be at different security levels, in order to address the security cost/performance balance of the communication system. Beneficially, such method would additionally allow a security level definition to be dynamically updated during a communication session.
SUMMARY OF THE INVENTION
The several embodiments of the present invention have been developed in response to the present state of the art, and in particular, in response to the problems and needs in the art that have not yet been fully solved by currently available data communication systems. Accordingly, the present invention has been developed to provide a method for asymmetric security that overcome many or all of the above-discussed shortcomings in the art.
The apparatus to facilitate asymmetric security is provided with a logic unit containing a plurality of modules configured to functionally execute the necessary operations for asymmetric security. These modules in the described embodiments include a receiving module, a transmission module, a communication module, a detection module, a security module, a definition module, an encryption module, a signature module, and a processing module.
In one embodiment, the receiving module receives a message at the node. The message may be received directly from the source node or from an intermediate node. The detection module, in one embodiment, detects the security level of the message received. The security level of the message may be communicated from the source node with the message or independent of the message. In one embodiment, the security level of the message may be defined in a security level definition.
The security module, in one embodiment, applies security, such as encryption or authentication, to an outgoing message that may be sent from the node to another node. In one embodiment, the security module applies the security to the message at an application layer, as opposed to a transport layer or another layer within a networking framework. The security technology that the security module implements to secure the message may vary depending on the message type or class to which the message belongs. Each message type or class may correspond to a security level with a security level definition.
The transmission module, in one embodiment, communicates the message from the node to another node. The transmission module may facilitate a direct or indirect communication between the nodes. In one embodiment, the message transmitted by the transmission module is associated with the received message. For example, the transmitted message may be a response, a handshaking operation, a request, or another type of data communication between the nodes. Furthermore, the transmission module may communicate the message in either a synchronous or an asynchronous communication system.
The communication module, in one embodiment, communicates the security level of the transmitted message to the receiving node. The communication module may communicate the security level of the message to the source node either by communicating the security level together with the message or independently of the message.
The definition module, in one embodiment, maintains the security level definition, which is descriptive of several potential security levels of the internode messages. The definition module also may dynamically update the security level definition. In one embodiment, the encryption module encrypts the outgoing message at the node according to the security level of the message assigned by the security module. Similarly, the signature module, in one embodiment, digitally signs the internode message at the node according to the security level of the message. The processing module, in one embodiment, processes one or more messages received at the node.
A system of the present invention is also presented to facilitate asymmetric security. The system may be embodied in a single node, in one embodiment, or in a communication system having a plurality of nodes. In particular, the system, in one embodiment, may include an electronic storage device, a security apparatus, and a network interface. The electronic storage device, in one embodiment, stores a security level definition descriptive of a plurality of security levels. The security apparatus, in one embodiment, receives a first message at a first security level from a first node and transmits a second message at a second security level to the first node within a current communication session. The network interface, in one embodiment, communicates the second security level of the second message to the first node.
Another embodiment of the system may include a first node and a second node. The first node, in one embodiment, transmits a first message at a first security level to the second node. The first security level may be descriptive of a first encryption level and/or a first digital signature level. The second node, in one embodiment, receives the first message from the first node and transmits a second message at a second security level to the first node in response to receiving the first message. The second security level may be descriptive of a second encryption level and/or a second digital signature level. In a further embodiment, the system also may include one or more intermediate nodes, such as a broker node.
A signal bearing medium is also presented to store a program that, when executed, performs operations to facilitate asymmetric security. In one embodiment, the operations include receiving a first message at a first security level from a first node, transmitting a second message at a second security level to the first node in response to receiving the first message, and communicating the second security level to the first node. In another embodiment, the operations also may include coupling a security level indicator to the second message, communicating the security level indicator to the first node, detecting the first security level of the first message, processing the first message, and/or applying a security feature to the second message according to the second security level.
In further embodiments, the operations may include defining a security level definition descriptive of the first security level and the second security level, dynamically updating the security level definition during a current communication session, and/or communicating the updated security level definition to the second node during the current communication session. In further embodiments, the operations may include communicating the second message in a synchronous or an asynchronous communication environment, communicating the second security level to the first node during a handshaking operation between the first node and a second node, encrypting the message, and/or digitally signing the message.
A method of the present invention is also presented for asymmetric security. The method in the disclosed embodiments substantially includes the operations necessary to carry out the functions presented above with respect to the operation of the described apparatus and system. Furthermore, some or all of the operations of the method may be substantially similar to the operations that are performed when the program on the signal bearing medium is executed.
Reference throughout this specification to features, advantages, or similar language does not imply that all of the features and advantages that may be realized with the present invention should be or are in any single embodiment of the invention. Rather, language referring to the features and advantages is understood to mean that a specific feature, advantage, or characteristic described in connection with an embodiment is included in at least one embodiment of the present invention. Thus, discussion of the features and advantages, and similar language, throughout this specification may, but do not necessarily, refer to the same embodiment.
Furthermore, the described features, advantages, and characteristics of the invention may be combined in any suitable manner in one or more embodiments. One skilled in the relevant art will recognize that the invention may be practiced without one or more of the specific features or advantages of a particular embodiment. In other instances, additional features and advantages may be recognized in certain embodiments that may not be present in all embodiments of the invention.
These features and advantages of the present invention will become more fully apparent from the following description and appended claims, or may be learned by the practice of the invention as set forth hereinafter.
BRIEF DESCRIPTION OF THE DRAWINGS
In order that the advantages of the invention will be readily understood, a more particular description of the invention briefly described above will be rendered by reference to specific embodiments that are illustrated in the appended drawings. Understanding that these drawings depict only typical embodiments of the invention and are not therefore to be considered to be limiting of its scope, the invention will be described and explained with additional specificity and detail through the use of the accompanying drawings, in which:
<figref idrefs="DRAWINGS">FIG. 1</figref> is a schematic block diagram illustrating a conventional communication system;
<figref idrefs="DRAWINGS">FIG. 2</figref> is a schematic block diagram illustrating one embodiment of communication system for end-to-end security;
<figref idrefs="DRAWINGS">FIG. 3</figref> is a schematic block diagram illustrating one embodiment of a communication system for asymmetric security;
<figref idrefs="DRAWINGS">FIG. 4</figref> is a schematic block diagram illustrating another embodiment of a communication system for asymmetric security;
<figref idrefs="DRAWINGS">FIG. 5</figref> is a schematic block diagram illustrating another embodiment of a communication system for asymmetric security;
<figref idrefs="DRAWINGS">FIG. 6</figref> is a schematic block diagram illustrating one embodiment of a node that may be used for asymmetric security;
<figref idrefs="DRAWINGS">FIG. 7A</figref> is a schematic diagram illustrating one embodiment of a security level definition;
<figref idrefs="DRAWINGS">FIG. 7B</figref> is a schematic diagram illustrating one embodiment of a message data structure;
<figref idrefs="DRAWINGS">FIG. 8</figref> is a schematic flow chart diagram illustrating one embodiment of a security method that may be implemented on an asymmetric communication system;
<figref idrefs="DRAWINGS">FIG. 9</figref> is a schematic flow chart diagram illustrating one embodiment of a receiving method that may be implemented during the security method of <figref idrefs="DRAWINGS">FIG. 8</figref>; and
<figref idrefs="DRAWINGS">FIG. 10</figref> is a schematic flow chart diagram illustrating one embodiment of a transmission method that may be implemented during the security method of <figref idrefs="DRAWINGS">FIG. 8</figref>.
DETAILED DESCRIPTION OF THE INVENTION
Many of the functional units described in this specification have been labeled as modules, in order to more particularly emphasize their implementation independence. For example, a module may be implemented as a hardware circuit comprising custom VLSI circuits or gate arrays, off-the-shelf semiconductors such as logic chips, transistors, or other discrete components. A module may also be implemented in programmable hardware devices such as field programmable gate arrays, programmable array logic, programmable logic devices or the like.
Modules may also be implemented in software for execution by various types of processors. An identified module of executable code may, for instance, comprise one or more physical or logical blocks of computer instructions which may, for instance, be organized as an object, procedure, or function. Nevertheless, the executables of an identified module need not be physically located together, but may comprise disparate instructions stored in different locations which, when joined logically together, comprise the module and achieve the stated purpose for the module.
Indeed, a module of executable code may be a single instruction, or many instructions, and may even be distributed over several different code segments, among different programs, and across several memory devices. Similarly, operational data may be identified and illustrated herein within modules, and may be embodied in any suitable form and organized within any suitable type of data structure. The operational data may be collected as a single data set, or may be distributed over different locations including over different storage devices, and may exist, at least partially, merely as electronic signals on a system or network.
<figref idrefs="DRAWINGS">FIG. 2</figref> depicts one embodiment of communication system <b>200</b> for end-to-end message level security. The illustrated communication system <b>200</b> includes a source node <b>202</b>, a destination node <b>204</b>, and an intermediate node <b>206</b>. The source node <b>202</b> is configured to send one or more messages <b>208</b> to the destination node <b>204</b>. The source node <b>202</b> may communicate the messages <b>208</b> to the destination node <b>204</b> via the intermediate node <b>206</b>, as shown, or directly without the intermediate node <b>206</b>. If the messages <b>208</b> are sent via an intermediate node <b>206</b>, such as a broker, the intermediate node <b>206</b> may store the messages <b>208</b>, at least temporarily, on an electronic storage device <b>210</b>. In one embodiment, the electronic storage device <b>210</b> may be a hard disk drive or another data storage device. Alternatively, the intermediate node <b>206</b> may store the messages <b>208</b> on an electronic memory device (not shown), such as random access memory (RAM) or another data memory device.
In one embodiment, the messages <b>208</b> originate at the source node <b>202</b>. The source node <b>202</b> includes a security apparatus <b>220</b> that is described in more detail with reference to <figref idrefs="DRAWINGS">FIG. 6</figref>. In one embodiment, the security apparatus <b>220</b> may be implemented as an application program interface (API) within the source node <b>202</b>. Generally, the security apparatus <b>220</b> identifies a pre-transmission message <b>222</b> and may apply one or more security features to the message <b>222</b> before transmitting the secure message <b>208</b> to the destination node <b>204</b>. In certain embodiments, the security features may include one or more of the following: encryption, authentication, message integrity, and/or other security features.
In order to provide end-to-end message security and ensure that the message is secure (both privacy and integrity), the security features may be implemented in the application layer that supports application-specific, end-user processes. By applying security to the pre-transmission message <b>222</b> at the application layer and transmitting the secure message <b>208</b> to the destination node <b>204</b>, the secure message <b>208</b> remains secure throughout the communication. Additionally, the security of the message <b>208</b> is preserved even while the message <b>208</b> is temporarily stored on the electronic storage device <b>210</b> of the intermediate node <b>206</b>. In this way, the message <b>208</b> may be retrieved by the destination node <b>204</b> from the intermediate node <b>206</b> with the security of the message <b>208</b> preserved from the source node <b>202</b> all the way to the destination node <b>204</b>. The security apparatus <b>230</b> on the destination node <b>204</b> then may authenticate and/or decrypt the secure messages <b>208</b> in order to process the received messages <b>232</b>. As depicted by the various shapes, the pre-transmission messages <b>222</b> and the corresponding received messages <b>232</b> may be of different types and may require different levels of security during transmission. Additionally, the security level of a particular message may depend on the direction in which the message is being transmitted.
<figref idrefs="DRAWINGS">FIG. 3</figref> depicts one embodiment of a communication system <b>300</b> for asymmetric security. In addition to asymmetric security, the communication system <b>300</b> also may implement end-to-end security as described with reference to <figref idrefs="DRAWINGS">FIG. 2</figref>. The illustrated communication system <b>300</b> for asymmetric security includes a source node <b>302</b> and a destination node <b>304</b>. Although not shown, the communication system <b>300</b> also may include one or more intermediate nodes, as described in more detail with reference to <figref idrefs="DRAWINGS">FIG. 4</figref>.
The source node <b>302</b> includes a security apparatus <b>320</b> that may apply security to outgoing messages <b>322</b> before transmitting secure messages <b>324</b> to the destination node <b>304</b>. The destination node <b>304</b> also includes a security apparatus <b>330</b> that may be substantially similar to the security apparatus <b>320</b> on the source node <b>302</b>. The security apparatus <b>330</b> on the destination node <b>304</b> may decode or otherwise use the security features of the secure messages <b>324</b> to make the incoming messages <b>326</b> usable by the destination node <b>304</b>.
In contrast to the secure messages <b>324</b> transmitted from the source node <b>302</b> to the destination node <b>304</b>, the security apparatus <b>330</b> on the destination node <b>304</b> may transmit certain outgoing messages <b>332</b> as non-secure messages <b>334</b> to be received by the source node <b>302</b>. Once received at the source node <b>302</b>, the security apparatus <b>320</b> may process the incoming messages <b>336</b> without performing any security processing. By transmitting the secure messages <b>324</b> and non-secure messages <b>334</b> in the manner described above—security in one direction, but not in the other direction—the communication system <b>300</b> implements asymmetric security.
In another embodiment, the communication system <b>300</b> may implement asymmetric security by transmitting non-secure messages <b>334</b> in one direction from the source node <b>302</b> to the destination node <b>304</b> and secure messages <b>324</b> from the destination node <b>304</b> to the source node <b>302</b>. In a further embodiment, the communication system <b>300</b> may implement asymmetric security by sending messages at one security level in one direction (e.g., source node <b>302</b> to destination node <b>304</b>) and sending messages at a different security level in another direction (e.g., destination node <b>304</b> to source node <b>302</b>). Additionally, the communication system <b>300</b> may implement asymmetric security by transmitting messages are various security levels in one direction and transmitting messages at other security levels in the other direction. Not all of the messages sent in one direction need to be at the same security level. Also, some of the messages sent in both directions may be at the same security level and others may be at different security levels.
<figref idrefs="DRAWINGS">FIG. 4</figref> depicts another embodiment of a communication system <b>400</b> for asymmetric security. The illustrated communication system <b>400</b> includes a source node <b>404</b> and a destination node <b>404</b> that may be substantially similar to the source node <b>302</b> and destination node <b>304</b>, respectively, of <figref idrefs="DRAWINGS">FIG. 3</figref>. Similarly, the security apparatus <b>420</b> of the source node <b>402</b> and the security apparatus <b>430</b> of the destination node <b>404</b> may be substantially similar to each other and to the security apparatuses <b>320</b>, <b>330</b> of <figref idrefs="DRAWINGS">FIG. 3</figref>.
The illustrated communication system <b>400</b> also includes an intermediate node <b>406</b> through which some or all of the communications between the source node <b>402</b> and the communication node <b>404</b> may pass. The intermediate node <b>406</b> includes an electronic storage device <b>410</b> to temporarily store the secure messages <b>424</b> and non-secure messages <b>434</b>, which are substantially similar to the messages described with reference to <figref idrefs="DRAWINGS">FIG. 3</figref>. Alternatively, the intermediate node <b>406</b> may include an electronic memory device or other storage device in place of or in addition to the electronic storage device <b>410</b> shown.
<figref idrefs="DRAWINGS">FIG. 5</figref> depicts another embodiment of a communication system <b>500</b> that implements a related type of asymmetric security. In particular, the communication system <b>500</b> includes a source node <b>502</b>, a destination node <b>504</b>, and an intermediate node <b>506</b>. Each of these nodes <b>502</b>, <b>504</b>, <b>506</b> includes a corresponding security apparatus <b>520</b>, <b>530</b>, <b>540</b>. In one embodiment, the intermediate node <b>506</b> and the destination node <b>504</b> communicate secure messages <b>508</b> between one another. The intermediate node <b>506</b> and the source node <b>502</b> may communicate non-secure messages <b>510</b> between one another at substantially the same time. In this way, the intermediate node <b>506</b> communicates secure messages <b>508</b> to the destination node <b>504</b> and non-secure messages <b>510</b> to the source node <b>502</b> at approximately the same time. The origin of the messages from the intermediate node <b>506</b> to either the source node <b>502</b> or the destination node <b>504</b> may be inconsequential in certain embodiments.
<figref idrefs="DRAWINGS">FIG. 6</figref> depicts one embodiment of a node <b>600</b> that may be used for asymmetric security. In one embodiment, the node <b>600</b> may be representative of a source node, a destination node, or an intermediate node. The illustrated node <b>600</b> includes a central processing unit (CPU) <b>602</b>, an electronic storage device <b>604</b>, an electronic memory device <b>606</b>, a network interface device <b>608</b>, and a security apparatus <b>610</b>.
In one embodiment, the CPU <b>602</b> is configured to process data requests, operations, and commands to manage the node <b>600</b>. The electronic storage device <b>604</b> is configured, in one embodiment, to electronically store data that is related to the management and operation of the node <b>600</b>. In one embodiment, the electronic storage device <b>604</b> may be persistent memory or another type of persistent data storage. Similarly, the electronic memory device <b>606</b> is configured, in one embodiment, to electronically store data that may be used for management and operation of the node <b>600</b> and/or application programs that may be executed on the node <b>600</b>.
In one embodiment, the electronic storage device <b>604</b> may store a security level definition <b>612</b>. Alternatively, the security level definition <b>612</b> may be stored on the electronic memory device <b>606</b> or on another data storage device. One example of a security level definition <b>612</b> is described in more detail with reference to <figref idrefs="DRAWINGS">FIG. 7A</figref>.
The network interface device <b>608</b> allows communications to occur between the node <b>600</b> and other nodes within a communication system. Alternatively, the network interface device <b>608</b> may allow communications between, for example, the source node <b>302</b> and the destination node <b>304</b>. For purposes of this description, references to the source node <b>302</b> and the destination node <b>304</b> are understood to refer to one or more of the source nodes <b>302</b>, <b>402</b>, <b>502</b> and destination nodes <b>304</b>, <b>404</b>, <b>504</b>, respectively, that are described above with reference to <figref idrefs="DRAWINGS">FIGS. 3</figref>, <b>4</b>, and/or <b>5</b>, unless otherwise noted.
The security apparatus <b>610</b>, in one embodiment, may be substantially similar to the various security apparatuses depicted in and described with reference to <figref idrefs="DRAWINGS">FIGS. 3</figref>, <b>4</b>, and <b>5</b>. The illustrated security apparatus <b>610</b> includes a receiving module <b>614</b>, a detection module <b>616</b>, a security module <b>618</b>, a transmission module <b>620</b>, and a communication module <b>622</b>. The illustrated security apparatus <b>610</b> also includes a definition module <b>624</b>, an encryption module <b>626</b>, a signature module <b>628</b>, and a processing module <b>630</b>.
In one embodiment, the receiving module <b>614</b> receives a message at the node <b>600</b>. The message may be from a source node <b>302</b> and the node <b>600</b> may function in the capacity of a destination node <b>304</b>. The message may be received directly from the source node <b>302</b>, in one embodiment, or may be received from an intermediate node, such as the intermediate node <b>406</b> of <figref idrefs="DRAWINGS">FIG. 4</figref>. In an asynchronous communication environment, for example, the node <b>600</b> may retrieve the message from a queue on a broker node.
The detection module <b>616</b>, in one embodiment, detects the security level of the message received at the node <b>600</b> by the receiving module <b>614</b>. The security level of the message may be communicated with the message or independent of the message from the source node <b>302</b>. In one embodiment, the security level of the message may be defined in the security level definition <b>612</b>.
The security module <b>618</b>, in one embodiment, applies security, such as encryption or authentication, to an outgoing message that may be sent from the node <b>600</b> to another node. For example, the security module <b>618</b> may apply security to an internode message that is communicated or intended to be communicated between two nodes. In one embodiment, the security module <b>618</b> applies the security to the message at an application layer, as opposed to a transport layer or another layer within a networking framework. The security technology that the security module <b>618</b> implements to secure the message may vary depending on the message type or class to which the message <b>222</b> belongs. Each message type or class may correspond to a security level with the security level definition <b>612</b>.
In one embodiment, the transmission module <b>620</b> communicates a message from the node <b>600</b> to another node. The transmission module <b>620</b> may facilitate a communication that is directly between two nodes or that is communicated via one or more intermediate nodes, such as a broker. In one embodiment, the message transmitted by the transmission module <b>620</b> is associated with the received message. For example, the transmitted message may be a response, a handshaking operation, a request, or another type of data communication between the nodes.
Furthermore, the transmission module <b>620</b> may communicate the message in either a synchronous or an asynchronous communication system. A synchronous communication environment includes a communication environment that is time-dependent in which data processing relies, at least in part, on the availability of the sending and receiving nodes and/or the network. An asynchronous communication environment includes a communication environment that is time-independent in which data processing does not rely on the availability of the nodes or the network. In other words, asynchronous messaging decouples applications on each of the nodes from each other and from the network.
The communication module <b>622</b>, in one embodiment, communicates the security level of the transmitted message to the receiving node (originally the source node <b>302</b>). In other words, after the node <b>600</b> receives a first message from the source node <b>302</b> and the node <b>600</b> sends a corresponding message back to the source node <b>302</b>, the communication module <b>622</b> communicates the security level of the response message to the source node <b>302</b>.
Similar to above, the communication module <b>622</b> may communicate the security level of the response message to the source node <b>302</b> either by communicating the security level together with the message or independently of the message. In one example, the communication module <b>622</b> may communicate the security level independently of the message by communicating the security level during a handshaking operation between the node <b>600</b> and the source node <b>302</b> to which the response message is sent. In another example, the communication module <b>622</b> may communicate the security level to the source node <b>302</b> during a current communication session, in which the messages are sent and received, or similar communication cycle.
In one embodiment, the definition module <b>624</b> maintains the security level definition <b>612</b> descriptive of the security level of the internode messages. In fact, the security level definition <b>612</b> may define a plurality of security levels, as described in more detail with reference to <figref idrefs="DRAWINGS">FIG. 7A</figref>. In one embodiment, the definition module <b>624</b> maintains the security level definition <b>612</b> on the electronic storage device <b>604</b>. Alternatively, the definition module <b>624</b> maintains the security level definition <b>612</b>, or a copy thereof, on the electronic memory device <b>606</b> or on another storage or memory device.
The definition module <b>624</b> also may maintain other definitions such as a message class definition descriptive of a message type within a message class. The definition module <b>624</b> also may maintain a security level map to map the security levels to one or more message types or classes defined within the message class definition.
In one embodiment, the encryption module <b>626</b> encrypts the outgoing message at the node <b>600</b> according to the security level of the message assigned by the security module <b>618</b>. Similarly, the signature module <b>628</b>, in one embodiment, digitally signs the internode message at the node <b>600</b> according to the security level of the message. The processing module <b>630</b>, in one embodiment, processes one or more messages received at the node <b>600</b>.
<figref idrefs="DRAWINGS">FIG. 7A</figref> depicts one embodiment of a security level definition <b>700</b> that is substantially similar to the security level definition <b>612</b> of <figref idrefs="DRAWINGS">FIG. 6</figref>. In one embodiment, the security level definition <b>700</b> defines one or more security levels and, in particular, which security features are to be implemented for each of the security levels. As described above, the security features may include, but are not necessarily limited to, encryption, authentication, and message integrity technologies. In one embodiment, the security level definition <b>700</b> may include a security level indicator <b>702</b>, an encryption indicator <b>704</b>, and a digital signature indicator <b>706</b>. For each security level indicated by a security level indicator <b>702</b>, the corresponding encryption indicator <b>704</b> may define whether or not encryption is implemented for the given security level. Similarly, the digital signature indicator <b>706</b> may define whether or not a digital signature is implemented for the given security level. Additionally, the encryption indicator <b>704</b> and digital signature indicator <b>706</b> may define additional parameters, including what type of encryption or digital signature technology, respectively, may be implemented.
In the illustrated example, the security level definition <b>700</b> defines four security levels: none, integrity, privacy, and integrity+privacy. In another embodiment, the security level definition <b>700</b> may define fewer or more security levels. Additionally, the security level definition <b>700</b> may use different security level indicators <b>702</b> to identify each security level within the security level definition <b>700</b>. In the depicted embodiment, the none security level does not implement either encryption or authentication. The integrity security level implements authentication, but does not implement encryption. The privacy security level implements encryption, but does not implement authentication. The integrity+privacy security level implements both encryption and authentication.
Although the present example is described in terms of four particular security levels, the security levels and various indicators <b>702</b>, <b>704</b>, <b>706</b> may vary and the security level definition <b>700</b> may be modified to adapt to such security levels and to various security technologies. In fact, the definition module <b>624</b>, in one embodiment, may be configured to dynamically update the security level definition <b>612</b> before, after, or during a communication session.
<figref idrefs="DRAWINGS">FIG. 7B</figref> depicts one embodiment of a message data structure <b>720</b>. The illustrated message data structure includes a security level indicator <b>722</b> and message data <b>724</b>. The message data is the data communicated between the nodes. The security level indicator <b>722</b> is descriptive of the security level of the message data <b>724</b>. In other words, the security level indicator <b>722</b> indicates what security features, if any, are applied to the message data <b>724</b>. In an alternative embodiment, the message data structure <b>720</b> may include only the message data <b>724</b>, in which case the security level indicator <b>722</b> may be communicated separately between the nodes. If the security level indicator <b>722</b> is communicated separately, a message indicator (not shown) or session indicator (not shown) or another indicator may be attached to the security level indicator <b>722</b> in order to indicate the data object or objects that are at the specified security level.
<figref idrefs="DRAWINGS">FIG. 8</figref> depicts one embodiment of a security method <b>800</b> that may used to implement asymmetric security. The security method <b>800</b> is described to suggest one embodiment in which certain operations may be performed on certain system components, for example, the source node <b>302</b> and/or the destination node <b>304</b>. However, the separation of operations among various system components, including system components not described, may be facilitated in other manners not shown or described herein. In particular, the security method <b>800</b> is described with reference to two nodes referred to as a first node and a second node. The security method <b>800</b> is also described in terms of a first message and a second message. In one embodiment, the first message is sent from the first node to the second node. Similarly, the second message is sent from the second node to the first node.
The illustrated security method <b>800</b> begins when the second node receives <b>802</b> the first message from the first node. The second node may employ the receiving module <b>614</b> to receive the first message from the first node. In one embodiment, the first message is at a first security level, which may include encryption, a digital signature, and/or other security features. In one embodiment, the security level of the first message may be communicated by the first node to the second node. For example, the first security level may be communicated with the first message data structure or may be communicated in an independent communication from the first node. Alternatively, the first security level may be determined by the second node according to the message type of the first message and the security level definition <b>612</b> on the second node.
In response to receiving the first message, the second node subsequently sends <b>804</b> a second message to the first node. In one embodiment, the second node may employ the transmission module <b>620</b> to send <b>804</b> the second message to the first node. The second message is at a second security level, which may include encryption, a digital signature, and/or other security features. In one embodiment, the second security level is different from the first security level. Additionally, the second message may be sent during the current communication session in which the first message was received.
In addition to sending the second message, the second node also communicates <b>806</b> the second security level to the first node. In one embodiment, the second node may employ the communication module <b>622</b> to communicate the second security level to the first node. In this way, the first node may be able to verify the authenticity of the second message and decode the second message for processing. In one embodiment, the second node may communicate <b>806</b> the second security level to the first node by appending or otherwise coupling a security level indicator to the data of the second message. Alternatively, the second node may communicate the second security level to the first node separately from the second message data. After the second node sends <b>804</b> the second message and communicates <b>806</b> the second security level to the first node, the depicted security method <b>800</b> then ends.
<figref idrefs="DRAWINGS">FIG. 9</figref> depicts one embodiment of a receiving method <b>900</b> that is given by way of example of the receiving operation <b>802</b> of the security method <b>800</b> of <figref idrefs="DRAWINGS">FIG. 8</figref>. Specifically, the depicted receiving method <b>900</b> begins when the second node gets <b>902</b> the first message from a message queue on a message broker (intermediate node). In alternative embodiments, the second node may directly receive the first message from the first node or receive the first message in another manner. The second node then detects <b>904</b> the first security level of the first message. The first security level may be defined by a security level indicator received with or independent of the first message data, as described above.
If the second node determines <b>906</b> that the first node implemented a digital signature on the first message then the second node may verify <b>908</b> the digital signature and determine <b>910</b> if the signature is correct. If the signature is not correct, then the second node may send <b>912</b> a transmission failure notification to the first node to indicate the failure of the transmission. If the first message is not signed or if the digital signature is correct, the second node then determines <b>914</b> if the first message is encrypted and, if so, decrypts <b>916</b> the first message. After the first message is decrypted <b>916</b>, or if the first message was not encrypted, the second node may process <b>918</b> the first message. The depicted security method <b>900</b> then ends.
<figref idrefs="DRAWINGS">FIG. 10</figref> depicts one embodiment of a transmission method <b>1000</b> that is given by way of example of the transmission operation <b>804</b> of the security method <b>800</b> of <figref idrefs="DRAWINGS">FIG. 8</figref>. The depicted transmission method <b>1000</b> begins when the second node recognizes <b>1002</b> a second message to be transmitted to the first node. In one embodiment, the second message is related to the first message received by the second node. The second node then determines <b>1004</b> the security level of the second message. In one embodiment, the second node may employ the security module <b>618</b> to determine <b>1004</b> the second security level of the second message by referencing a security level map and/or the security level definition <b>612</b>. The second node also may determine the security actions to be applied to the second message as defined by the security level definition <b>612</b>.
In one embodiment, the second node determines <b>1006</b> if privacy security features should be implemented according to the security level definition <b>612</b>. If so, the encryption module <b>626</b> encrypts <b>1008</b> the second message. The second node also determines <b>1010</b> if integrity security features should be implemented according to the security level definition <b>612</b>. If so, the second node digitally signs <b>1012</b> the second message. The second node then transmits <b>1014</b> the second message to the first node and the depicted transmission method <b>10</b> then ends.
The schematic flow chart diagrams included herein are generally set forth as logical flow chart diagrams. As such, the depicted order and labeled operations are indicative of one embodiment of the presented method. Other operations and methods may be conceived that are equivalent in function, logic, or effect to one or more operations, or portions thereof, of the illustrated method. Additionally, the format and symbols employed are provided to explain the logical operations of the method and are understood not to limit the scope of the method. Although various arrow types and line types may be employed in the flow chart diagrams, they are understood not to limit the scope of the corresponding method. Indeed, some arrows or other connectors may be used to indicate only the logical flow of the method. For instance, an arrow may indicate a waiting or monitoring period of unspecified duration between enumerated operations of the depicted method. Additionally, the order in which a particular method occurs may or may not strictly adhere to the order of the corresponding operations shown.
Reference throughout this specification to “one embodiment,” “an embodiment,” or similar language means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present invention. Thus, appearances of the phrases “in one embodiment,” “in an embodiment,” and similar language throughout this specification may, but do not necessarily, all refer to the same embodiment.
Reference to a signal bearing medium may take any form capable of generating a signal, causing a signal to be generated, or causing execution of a program of machine-readable instructions on a digital processing apparatus. A signal bearing medium may be embodied by a transmission line, a compact disk, digital-video disk, a magnetic tape, a Bernoulli drive, a magnetic disk, a punch card, flash memory, integrated circuits, or other digital processing apparatus memory device.
Furthermore, the described features, structures, or characteristics of the invention may be combined in any suitable manner in one or more embodiments. In the following description, numerous specific details are provided, such as examples of cat programming, software modules, user selections, network transactions, database queries, database structures, hardware modules, hardware circuits, hardware chips, etc., to provide a thorough understanding of embodiments of the invention. One skilled in the relevant art will recognize, however, that the invention may be practiced without one or more of the specific details, or with other methods, components, materials, and so forth. In other instances, well-known structures, materials, or operations are not shown or described in detail to avoid obscuring aspects of the invention.
The present invention may be embodied in other specific forms without departing from its spirit or essential characteristics. The described embodiments are to be considered in all respect only as illustrative and not restrictive. The scope of the invention is, therefore, indicated by the appended claims rather than by the foregoing description. All changes which come within the meaning and range of equivalency of the claims are to be embraced within their scope.
Contents4
11 sheets
Sheet 1 Sheet 2 Sheet 3 Sheet 4 Sheet 5 Sheet 6 Sheet 7 Sheet 8 Sheet 9 Sheet 10 Sheet 11
Every citation, both waysCites: the store holds 34 of 35
| Document | Relation | Office | Cited during |
|---|---|---|---|
| US8156536B2 | Cited by | United States of America | Search report |
| US2008133761A1 | Cited by | United States of America | Pre-grant |
| US9226139B2 | Cited by | United States of America | Applicant |
| US8843111B2 | Cited by | United States of America | Search report |
| US2009052370A1 | Cited by | United States of America | Pre-grant |
| EP0409397A2 | Cites | European Patent Office (EPO) | Applicant |
| US2001005883A1 | Cites | United States of America | Applicant |
| US2002073313A1 | Cites | United States of America | Search report |
| US2002116619A1 | Cites | United States of America | Search report |
| US2002123325A1 | Cites | United States of America | Applicant |
| US2003033349A1 | Cites | United States of America | Applicant |
| US2003074579A1 | Cites | United States of America | Applicant |
| US2003131245A1 | Cites | United States of America | Applicant |
| US2003172167A1 | Cites | United States of America | Applicant |
| US2004071137A1 | Cites | United States of America | Search report |
| US2004078334A1 | Cites | United States of America | Applicant |
| US2004139314A1 | Cites | United States of America | Search report |
| US2004223615A1 | Cites | United States of America | Search report |
| US2005015592A1 | Cites | United States of America | Applicant |
| US2006015932A1 | Cites | United States of America | Applicant |
| US2006015933A1 | Cites | United States of America | Applicant |
| US2006064736A1 | Cites | United States of America | Applicant |
| US2006106938A1 | Cites | United States of America | Search report |
| US5602916A | Cites | United States of America | Search report |
| US5615261A | Cites | United States of America | Search report |
| US5784463A | Cites | United States of America | Applicant |
| US5935248A | Cites | United States of America | Applicant |
| US5940187A | Cites | United States of America | Applicant |
| US5960086A | Cites | United States of America | Applicant |
| US6021203A | Cites | United States of America | Applicant |
| US6185612B1 | Cites | United States of America | Search report |
| US6490679B1 | Cites | United States of America | Applicant |
| US6567913B1 | Cites | United States of America | Applicant |
| US7137099B2 | Cites | United States of America | Applicant |
| US7165179B2 | Cites | United States of America | Search report |
| US7236597B2 | Cites | United States of America | Search report |
| US7257843B2 | Cites | United States of America | Search report |
| US7269260B2 | Cites | United States of America | Search report |
| US7350212B2 | Cites | United States of America | Applicant |
| Son et al., abstract of "An adaptable security manager for real-time transactions", 2000, Real-Time Systems, 2000. Euromicro RTS 2000. 12th Euromicro Conference. | Non-patent | – | Search report |
| By James Hart, IBM Software Group, "Connecting your applications without complex programming", WebSphere Software, Sep. 2003. | Non-patent | – | Applicant |
| Son, Zimmerman, Hansson "An adaptable security manager for real-time transactions", p. 1-8. | Non-patent | – | Applicant |
| By Anita Karve, "SSL and S-HTTP" Jan. 1, 1997; http://www.networkmagazine.com/shared/article/showArticle.jhtml?articleID=17601054. | Non-patent | – | Applicant |
| By Dirk Reinshagen, "XML Messaging, Part 2, XML messaging the SOAP way", http://www.javaworld.com/javaworld/jw-06-2001/jw-0622-xmlmessaging2-p.html. | Non-patent | – | Applicant |
| "The 7 layers of the OSI model", webopedia, http://webopedia.internet.com/quick-ref/OSI-Layers.asp. | Non-patent | – | Applicant |
| "IBM Tivoli Access Manager for Business Integration Administration Guide" Overview, Version 5.1 SC23-4831-01, http://publib.boulder.ibm.com/trividd/td/ITAMFBI/SC23-4831-01/en-US/HTML/ADM51.... | Non-patent | – | Applicant |
| "IBM Tivoli Access Manager for Business Integration Administration Guide" Product Concepts, Version 5.1 SC23-4831-01, http://publib.boulder.ibm.com/trividd/td/ITAMFBI/SC23-4831-01/en-US/HTML/ADM51.... | Non-patent | – | Applicant |
| Reiner Sailer and Matthias Kabatnik "History Based Distributed Filtering-A Tagging Approach to Network-Level Access Control" IEEE (2000) pp. 373-382. | Non-patent | – | Applicant |
7 members in 3 offices
Priority claims2
| Document | Office | Kind | Date |
|---|---|---|---|
| 94800004 | United States of America | A | |
| US20040948000 | – | – | – |
Members7
| Document | Office | Kind | |
|---|---|---|---|
| US2006064736A1 | United States of America | A1 | |
| WO2006032647A1 | World Intellectual Property Organization (WIPO) | A1 | |
| CN1989753A | China | A | |
| US2008285752A1 | United States of America | A1 | |
| US7607006B2This record | United States of America | B2 | |
| CN1989753B | China | B | |
| US8392700B2 | United States of America | B2 |
86 transactions on the USPTO file
Allowed after 1 non-final rejection and 2 RCEs.
- Non-final rejections
- 1
- Final rejections
- 0
- RCEs
- 2
- Appeals
- 0
Over time
Point at a mark for the transactionTransactions
| Event | Code | |
|---|---|---|
| Expire PatentEXP. | EXP. | |
| Correspondence Address ChangeC.AD | C.AD | |
| Application Is Considered for C of CCOFC | COFC | |
| Mail Post CardPST_CRD | PST_CRD | |
| Email NotificationEML_NTF | EML_NTF | |
| Mail-Petition Decision - GrantedMP034 | MP034 | |
| Petition Decision - GrantedP034 | P034 | |
| Petition EnteredPET. | PET. | |
| Recordation of Patent Grant MailedPGM/ | PGM/ | |
| Patent Issue Date Used in PTA CalculationAllowedPTAC | PTAC | |
| Issue Notification MailedAllowedWPIR | WPIR | |
| Dispatch to FDCD1935 | D1935 | |
| Dispatch to FDCD1935 | D1935 | |
| Application Is Considered Ready for IssuePILS | PILS | |
| Issue Fee Payment VerifiedN084 | N084 | |
| Issue Fee Payment ReceivedIFEE | IFEE | |
| Issue Fee Payment VerifiedN084 | N084 | |
| Mail Examiner's AmendmentMEX.A | MEX.A | |
| Mail Notice of AllowanceAllowedMN/=. | MN/=. | |
| Notice of Allowance Data Verification CompletedAllowedN/=. | N/=. | |
| Case Docketed to Examiner in GAUDOCK | DOCK | |
| Date Forwarded to ExaminerFWDX | FWDX | |
| Date Forwarded to ExaminerFWDX | FWDX | |
| Disposal for a RCE / CPA / R129AbandonedABN9 | ABN9 | |
| Information Disclosure Statement consideredIDSC | IDSC | |
| Electronic Information Disclosure StatementEIDS. | EIDS. | |
| Request for Continued Examination (RCE)RCEX | RCEX | |
| Information Disclosure Statement (IDS) FiledWIDS | WIDS | |
| Workflow - Request for RCE - BeginBRCE | BRCE | |
| Reverse Issue FeeVFEE | VFEE | |
| Issue Fee Payment ReceivedIFEE | IFEE | |
| Response to Reasons for AllowanceREAS | REAS | |
| Mail Examiner Interview Summary (PTOL - 413)MEXIN | MEXIN | |
| Examiner Interview Summary Record (PTOL - 413)EXIN | EXIN | |
| Mail Notice of AllowanceAllowedMN/=. | MN/=. | |
| Notice of Allowance Data Verification CompletedAllowedN/=. | N/=. | |
| Examiner's Amendment CommunicationEX.A | EX.A | |
| Date Forwarded to ExaminerFWDX | FWDX | |
| Disposal for a RCE / CPA / R129AbandonedABN9 | ABN9 | |
| Information Disclosure Statement consideredIDSC | IDSC | |
| Request for Continued Examination (RCE)RCEX | RCEX | |
| Electronic Information Disclosure StatementEIDS. | EIDS. | |
| Information Disclosure Statement (IDS) FiledWIDS | WIDS | |
| Workflow - Request for RCE - BeginBRCE | BRCE | |
| Mail Examiner's AmendmentMEX.A | MEX.A | |
| Mail Notice of AllowanceAllowedMN/=. | MN/=. | |
| Notice of Allowance Data Verification CompletedAllowedN/=. | N/=. | |
| Examiner's Amendment CommunicationEX.A | EX.A | |
| Case Docketed to Examiner in GAUDOCK | DOCK | |
| Date Forwarded to ExaminerFWDX | FWDX | |
| Response after Non-Final ActionA... | A... | |
| Mail Examiner Interview Summary (PTOL - 413)MEXIN | MEXIN | |
| Examiner Interview Summary Record (PTOL - 413)EXIN | EXIN | |
| Mail Notice of Restarted Response PeriodMNRES | MNRES | |
| Letter Restarting Period for Response (i.e. Letter re References)NRES | NRES | |
| Mail Examiner Interview Summary (PTOL - 413)MEXIN | MEXIN | |
| Examiner Interview Summary Record (PTOL - 413)EXIN | EXIN | |
| Mail Non-Final RejectionNon-final rejectionMCTNF | MCTNF | |
| Non-Final RejectionNon-final rejectionCTNF | CTNF | |
| Date Forwarded to ExaminerFWDX | FWDX | |
| Response to Election / Restriction FiledELC. | ELC. | |
| Mail Restriction RequirementMCTRS | MCTRS | |
| Restriction/Election RequirementCTRS | CTRS | |
| Withdraw Flagged for 5/25W525 | W525 | |
| Flagged for 5/25F525 | F525 | |
| Case Docketed to Examiner in GAUDOCK | DOCK | |
| Information Disclosure Statement consideredIDSC | IDSC | |
| Information Disclosure Statement (IDS) FiledM844 | M844 | |
| Information Disclosure Statement (IDS) FiledWIDS | WIDS | |
| IFW TSS Processing by Tech Center CompleteTSSCOMP | TSSCOMP | |
| Case Docketed to Examiner in GAUDOCK | DOCK | |
| Application Is Now CompleteCOMP | COMP | |
| Application Return from OIPEWROIPE | WROIPE | |
| Application Return TO OIPEROIPE | ROIPE | |
| Application Return from OIPEWROIPE | WROIPE | |
| Application Return TO OIPEROIPE | ROIPE | |
| Application Is Now CompleteCOMP | COMP | |
| Application Dispatched from OIPEOIPE | OIPE | |
| Cleared by L&R (LARS)L128 | L128 | |
| Referred to Level 2 (LARS) by OIPE CSRL198 | L198 | |
| IFW Scan & PACR Auto Security ReviewSCAN | SCAN | |
| Information Disclosure Statement consideredIDSC | IDSC | |
| Reference capture on IDSRCAP | RCAP | |
| Information Disclosure Statement (IDS) FiledM844 | M844 | |
| Information Disclosure Statement (IDS) FiledWIDS | WIDS | |
| Initial Exam Team nnIEXX | IEXX |
8 legal events, as the office reported them to INPADOC
Over the term
Point at a mark for the eventEvents
| Event | Code | |
|---|---|---|
| Lapsed due to failure to pay maintenance feeLapsedFP | FP | |
| Information on status: patent discontinuationPATENT EXPIRED DUE TO NONPAYMENT OF MAINTENANCE FEES UNDER 37 CFR 1.362STCH | STCH | |
| Information on status: patent discontinuationPATENT EXPIRED DUE TO NONPAYMENT OF MAINTENANCE FEES UNDER 37 CFR 1.362STCH | STCH | |
| Lapse for failure to pay maintenance feesLapsedLAPS | LAPS | |
| Maintenance fee reminder mailedREMI | REMI | |
| Certificate of correctionCC | CC | |
| Fee payment procedurePAYOR NUMBER ASSIGNED (ORIGINAL EVENT CODE: ASPN); ENTITY STATUS OF PATENT OWNER: LARGE ENTITYFEPP | FEPP | |
| AssignmentAS | AS |
Numbers
- Publication, DOCDB
- 7607006
- Publication, EPODOC
- US7607006
- Application
- 10948000
- Application, DOCDB
- 94800004
- Application, EPODOC
- US20040948000
Titles
- English
- Method for asymmetric security
Patent term adjustment
- A delay
- +856 daysthe office missed an examination deadline
- B delay
- +466 dayspendency past three years
- Overlap
- −187 daysdelays counted once
- Applicant delay
- −2 days
- Net adjustment
- 1,133 days
Classification
- CPC, 2
- H04L63/105
- G06Q20/027
- IPC, 1
- H04L9 00
- USPC, 5
- 713151000
- 705079000
- 709220000
- 713150000
- 726004000