Systems and methods for a secure recording environment

Information

  • Patent Grant
  • 7853800
  • Patent Number
    7,853,800
  • Date Filed
    Friday, June 30, 2006
    18 years ago
  • Date Issued
    Tuesday, December 14, 2010
    13 years ago
Abstract
Systems and methods are disclosed for retrieving and playing back a secure, captured data in a customer center. In another embodiment, the method comprises: transmitting a request by a retrieval component to retrieve stored, encrypted data from a recording subsystem; establishing a secure communication between the retrieval component and the recording subsystem to retrieve the stored, encrypted data; receiving the stored, encrypted data by the retrieval component; transmitting a request to retrieve electronic keys for decrypting the stored, encrypted data; receiving the electronic keys by the retrieval component; decrypting the stored, encrypted data using the electronic keys; and playing back the decrypted data.
Description
TECHNICAL FIELD

The present disclosure is generally related to methods and systems that provide secure, captured data in a customer center.


BACKGROUND

Security is fast becoming a primary concern as private information is communicated during interactions between a customer and a business, particularly at a customer center. Some interactions are captured and stored in a recording system for evaluation of an agent and visualization of performance of the customer center, for example. Some captured interactions have private information such as credit card information, social security number, and date of birth. Clearly, this type of information could be subject to identity theft and unlawful access.


SUMMARY

Systems and methods are disclosed for providing secure, captured data in a customer center. In one embodiment, the method comprises: capturing data with a recording system; receiving a request to retrieve electronic keys for encrypting the data; responsive to receiving the request, transmitting the electronic keys to the recording system; encrypting the data using the electronic keys; associating the electronic keys with the encrypted data; and storing the encrypted data in the recording system.


Systems and methods are disclosed for retrieving and playing back a secure, captured data in a customer center. In another embodiment, the method comprises: transmitting a request by a retrieval component to retrieve stored, encrypted data from a recording subsystem; establishing a secure communication between the retrieval component and the recording subsystem to retrieve the stored, encrypted data; receiving the stored, encrypted data by the retrieval component; transmitting a request to retrieve electronic keys for decrypting the stored, encrypted data; receiving the electronic keys by the retrieval component; decrypting the stored, encrypted data using the electronic keys; and playing back the decrypted data.





BRIEF DESCRIPTION OF THE DRAWINGS

Many aspects of the invention can be better understood with reference to the following drawings. The components in the drawings are not necessarily to scale, emphasis instead being placed upon clearly illustrating the principles of the present invention. Moreover, in the drawings, like reference numerals designate corresponding parts throughout the several views.



FIG. 1 is a schematic diagram of an embodiment of an encrypted recording environment using a centralized key management system in a company premises.



FIG. 2 is a schematic diagram of an embodiment of an encrypted recording environment using a local key management system of a recording system.



FIG. 3 illustrates an exemplary database of electronic keys.



FIG. 4 illustrates an exemplary database of stored data and metadata associated with the stored data.



FIG. 5 is a flow diagram that illustrates operation of an embodiment of an encrypted recording environment such as shown in FIGS. 1 and 2.



FIGS. 6A-B are flow diagrams that illustrate operation of an embodiment of an encrypted recording system environment, such as shown in FIGS. 1 and 2.



FIG. 7 is a flow diagram that illustrates operation of an embodiment of a key management system.



FIG. 8 is a flow diagram that illustrates operation of an embodiment of a cache.



FIG. 9 is a flow diagram that illustrates operation of an embodiment of a recording subsystem.



FIG. 10 is a flow diagram that illustrates operation of an embodiment of a playback component.





DETAILED DESCRIPTION

Disclosed herein are systems and methods for providing secure, captured data in a customer center. Customer center includes, but is not limited to, outsourced contact centers, outsourced customer relationship management, customer relationship management, voice of the customer, customer interaction, contact center, multi-media contact center, remote office, distributed enterprise, work-at-home agents, remote agents, branch office, back office, performance optimization, workforce optimization, hosted contact centers, and speech analytics, for example. In particular, embodiments of such a system incorporate a key management system, which can be located at the customer center, that provides secure, captured data during collection, recording and transmission of the captured data. The key management system provides electronic keys for encrypting and decrypting data. By encrypting the data, even if a hacker breaks through all other protection mechanisms (e.g., firewalls) and gains access to encrypted data, the hacker is prevented from being able to read the data without further breaking the encryption.



FIG. 1 is a schematic diagram of an embodiment of an encrypted recording environment 100 using a centralized key management system in a company premises. Communication device 105 is coupled to a telephone network 106, which is coupled to a gateway 107. The gateway 107 is coupled to a company premises 112, particularly to a switch 108. The switch 108 can be a voice over Internet Protocol (VoIP) switch and includes a switch management system 109 that encrypts data from an interaction between, for example, users of communication device 105 and communication device 117 or users of the communication devices 117. The switch management system 109 associates electronic keys with the encrypted data. The switch management system 109 transmits the encrypted data to an IP/data network 110. Additionally or alternatively, the switch 108 can be a time-division multiplexing (TDM) switch, which transmits unencrypted data associated with the interaction.


The communication devices 105, 117 can include, but not limited to, an Internet Protocol (IP) soft phone, a TDM phone, and a computing device. The communication device 117 can communicate with the communication devices 105 or other communication devices 117 via the IP/data network 110 and switch 108. If the communication devices are IP soft phones or computing devices, the communication devices 105, 117 can decrypt incoming data from the switch 108 and transmits outgoing data to the switch 108.


Additionally or alternatively, the communication device 117 can encrypt its outgoing data and transmit the outgoing data to the switch 108. The switch 108 decrypts the outgoing data for the communication device 105. The encryption of the data at the switch 108 and the communication device 117 provides security to the data of the interactions between users of the communication devices 105, 117 or users of the communication device 117 in the company premises 112.


The switch 108 and/or the communication device 117 transmit encrypted or unencrypted data to one or more recording systems 120. The data is related to, but is not limited to, TDM, conferencing, duplicative, and passive, for example. Each recording system 120 includes a centralized key management system 115, one or more recording subsystems, and one or more playback components, all of which are coupled to a network 133. The recording subsystem 135 includes, but is not limited to, an active-recording buffer, an online-network storage, and an archival system, for example. The recording subsystem 135 receives captured data from the switch 108 and/or the communication device 117. The recording subsystem 135 further receives metadata that includes information related to the interaction, such as agent identification and call time, for example. In general, the metadata is transmitted with the data to the recording subsystem 135. In this regard, “data” includes metadata of an interaction along with the captured audio, video, screen capture, and text messaging signals.


If the data are encrypted, the recording subsystem 135 decrypts the data from the switch 108 and/or the communication device 117 using electronic keys from the switch 108 and/or the communication device 117, respectively. Either the recording subsystem 135 decrypts the data or receives unencrypted data, the recording subsystem 135 then transmits a request to the centralized key management system 115 for an electronic key to encrypt the data. The recording subsystem 135 generates a unique identifier, which can be calculated based on a checksum or hash value of the data, for example. The recording subsystem 135 associates the unique identifier with the captured data. The request can include, but not limited to, unique identifiers associated with the captured data and authentication information.


Unique identifiers are codes used to identify the captured data that are unique within a given context. There are three ways, among others, of generating unique identifiers: 1) serial numbers, allocated in sequence, 2) random numbers selected from a number space much larger than the expected number of objects to be identified, and 3) meaningful names or codes allocated by choice which are forced to be unique by keeping a central registry. All of the above methods can be combined hierarchically, singly or in combination with one another, to create scalable schemes for creating unique identifiers. In many cases, the captured data may have more than one unique identifier, each of which identifies it for a different purpose.


Hash value is computed from a base input number using a hashing algorithm. Essentially, the hash value is a summary of the original value. The hash value is nearly impossible to derive the original input number without knowing the data used to create the hash value.


The centralized key management system 115 receives the request from the recording subsystem 135 and determines whether the recording subsystem 135 has authentication via an authentication system 128 to retrieve electronic keys. The centralized key management system 115 generates electronic keys for decrypting and encrypting data. The electronic keys can be used as active keys, inactive keys, and random, semi-random, and sequential rotations of keys. The centralized key management system 115 can generate key identification associated with the generated electronic keys based on a checksum or hash value of the data.


Responsive to the recording subsystem 135 having authentication, the centralized key management system 115 selects an electronic key for encrypting the captured data. The centralized key management system 115 generates a key identification for each electronic key and associates the key identification with the electronic key. Additionally or alternatively, the centralized key management system 115 associates the electronic keys with the unique identifier. The generated keys are maintained until the associated data are removed from the encrypted recording environment 100. The unique identifier can be used to obtain the electronic key from the centralized key management system 115. The structure of the electronic key is described in relation to FIG. 3.


The centralized key management system 115 transmits the electronic keys to the recording subsystem 135. The recording subsystem 135 receives the electronic keys and encrypts the captured data using the electronic keys. Alternatively or additionally, the recording subsystem 135 can associate the key identification with the encrypted data. The key identification can be used to obtain the electronic key from the centralized key management system 115. The encrypted data are stored in the recording subsystem 135. Additionally or alternatively, the recording subsystem includes 135 a database of metadata and key identifications. The recording subsystem 135 uses the metadata to retrieve the stored, encrypted data. The metadata is associated with the key identifications, which the recording subsystem 135 uses to retrieve the electronic keys from the centralized key management system 115. The structures of the encrypted data and metadata are described in relation to FIG. 4.


Additionally or alternatively, the centralized key management system 115 can transmit the electronic keys maintained in the centralized key management system 115 to a cache 134 located in the recording subsystem 135. The cache 134 is a secure non-volatile component. The cache 134 can store active keys and inactive keys. The keys stored in the cache 134 can be updated via the centralized key management system 115. The cache 134 can be receive a request for the electronic key from a retrieval system, such as the recording subsystem 135, the playback component 130, or a third party playback component 140. The request includes a unique identifier associated with the data and/or key identification associated with the electronic key. The cache 134 uses the unique identifier and/or key identification to provide the electronic keys to the retrieval system. The cache 134 transmits the electronic key via the network 133 and/or IP/data network 110. The encryption of the data by the recording subsystem 135 provides security during the transmission and storage of the data in the recording system 120. The retrieval process of the electronic keys allows the encrypted data to migrate to different retrieval systems using the associated electronic keys for decrypting the data.


There are various encryption methods. For example, in symmetric-key encryption, each computer has a secret key (code) that the computer use to encrypt a packet of information before the packet is sent over the network to another computer. Symmetric-keys are installed into computers that communicate with each other. Symmetric-key encryption is essentially the same as a secret code that each computer knows to decode the information. The code provides the key for decoding the message. An analogy of the encryption is that a first person creates a coded message and sends the message to a second person. To decrypt the message, each letter is substituted with the letter that is two down from it in the alphabet. So “A” becomes “C,” and “B” becomes “D”. The second person knows the encryption method that the code is “Shift by 2”. The second person receives the message and decodes it. Anyone else who sees the message will see only nonsense.


Another encryption method is public-key encryption that uses a combination of a private key and a public key. Each private key is assigned to a first computer, while the public key is given by the first computer to any other computers that wants to communicate securely with the first computer. To decode an encrypted message, the other computers use the public key, provided by the first computer, and their own private keys. One public-key encryption utility is called Pretty Good Privacy (PGP).


Public-key encryption takes a lot of computing, so many systems use a combination of public-key and symmetry-key encryption. When two computers initiate a secure session, one computer creates a symmetric key and sends it to the other computer using public-key encryption. The two computers can then communicate using symmetric-key encryption. Once the session is finished, each computer discards the symmetric key used for that session. Any additional sessions require that a new symmetric key be created, and the process is repeated.


Additionally or alternatively, the recording system 120 encrypts incoming and outgoing data from multiple respective communication devices 117 associated with multiple respective interactions. Additionally or alternatively, the recording system 120 can instruct the communication device 117 to transmit incoming and outgoing data to a conference bridge 125. Responsive to receiving the instruction, the communication device 117 transmits incoming and outgoing data to the conference bridge 125, which duplicates and transmits the data to the recording system 120. In other words, the recording system 120 “observes” the calls/extensions of the interactions via the conference bridge to get a copy of the data. The conference bridge 125 can “camp” on a specific extension if the switch 108 permits and receive the data from the communication device 117 for the interactions as long as the recording system 120 is observing the extension.


Additionally or alternatively, the recording system 120 communicating with a VoIP switch 108 can also get the decryption information for active VoIP streams, which can be used for real-time or post call decryption of the data. Additionally or alternatively, the centralized key management system 115 continues to use associated electronic keys from the switch management system 109 for the transmission and storage of the data in the recording system 120. However, the manufacturer of the switch management system 109 currently discourages the use of this security method because this increases the risk of hackers cracking their security through the centralized key management system 115. Hackers (external and internal to a company) can use vendor default passwords and other vendor default settings to compromise systems. These passwords and settings can be easily discovered in hacker communities and easily determined via public information.


The playback component 130, a third-party playback component 140, or another recording subsystem 135 can retrieve the stored data from the recording subsystem 135. The retrieval components 130, 135, 140 can be, for example, a desktop computer that plays and/or displays audio, video, screen capture, and text messaging data on the speaker and monitor, respectively. Responsive to receiving a request from the retrieval components, an authorization process may be required for the retrieval components 130, 135, 140 before communicating with each other. For example, the recording subsystem 135 determines whether the retrieval components 130, 135, 140 have authentication via the authentication system 128 to receive the requested data. If the retrieval components 130, 135, 140 have authentication, the recording subsystem 135 transmits the stored data to the retrieval components 130, 135, 140. If the retrieval components 130, 140 play back the stored data, the retrieval components 130, 140 can retrieve the electronic keys from the centralized key management system 115 and/or cache 134, 137 using key identification associated with the encrypted data or the unique identifier of the encrypted data that is associated with the electronic key. The retrieval components 130, 140 decrypt the requested data using the associated electronic key and play back the requested data.


Additionally or alternatively, a secure tunnel may be established among the retrieval components before stored data and electronic keys are transmitted and received among the retrieval components. For example, a secure sockets layer (SSL) is a cryptographic protocol which provide secure communications on the network (e.g., Internet) for data, such things as e-mail and internet faxing. The SSL protocol exchanges data. Each data can be optionally compressed, encrypted and packed with a message authentication code (MAC). Each data can have a content_type field that specifies which upper level protocol is being used. When the retrieval components 130, 140 connect with the recording subsystem 135 connection, the data level encapsulates another protocol, the handshake protocol, which has the content_type.


Several handshake structures are transmitted and received via the network. For example, a ClientHello message is transmitted specifying the list of cipher suites, compression methods and the highest protocol version being supported. Random bytes can be transmitted. A ServerHello message is received, in which the server chooses the connection parameters from the choices offered by the client earlier. When the connection parameters are known, the retrieval components 130, 135, 140 exchange certificates (depending on the selected public key cipher). These certificates are currently X.509, which is an international Telecommunication union (ITU) standard. The retrieval components 130, 135, 140 can request a certificate from another retrieval component so that the connection can be mutually authenticated. the retrieval components 130, 135, 140 negotiate a common secret called “master secret”, possibly using the result of a Diffie-Hellman exchange, or simply encrypting a secret with a public key that is decrypted with the peer's private key. All other key data is derived from this “master secret” (and the client- and server-generated random values), which is passed through a “Pseudo Random Function”. Once the retrieval components 130, 135, 140 have authentication, the stored data are secure to be passed among the retrieval components 130, 135, 140.


Additionally or alternatively, the recording subsystem 135 transmits the requested data to the centralized key management system 115 for decryption and instructs the system 115 to transmit the decrypted data to the playback components 130, 140. Additionally or alternatively, the recording subsystem uses the key identification associated with the encrypted data to obtain the electronic key from the cache 134 and transmits the requested data along with the associated electronic key to the retrieval components 130, 135, 140. Additionally or alternatively, the recording subsystem uses the key identification associated with the encrypted data to obtain the electronic key from the cache 134 and transmits the requested data along with the associated electronic key to the retrieval components 130, 135, 140. In the various alternative embodiments mentioned above, the transmission of the data to the playback component 130 from the recording system 120 are secure by providing encrypted data via a secure tunnel or an authentication process.



FIG. 2 is a schematic diagram of an embodiment of an encrypted recording environment using a local key management system of a recording system. The encrypted recording environment 200 is similar to the encrypted recording environment 100 in FIG. 1 as described above. That is, system 200 includes communication devices 205, 217, telephony network 206, gateway 207, switch 208, switch management system 209, a company premises 212, IP/data network 210, recording system 220, playback component 230, third-party playback component 240, and authentication system 228.


The company premises 212 receives encrypted or unencrypted data from the switch 208 and/or the communication device 217. The received data are transmitted to the recording subsystem 235, which includes a local key management system (LKMS) 213. Similar to the centralized key management system 115 of FIG. 1, the LKMS 213 provides electronic keys for encrypting the received data. The recording subsystem 235 encrypts the received data using the electronic keys and stores the encrypted data. The LKMS 213 can transmit a duplicate copy of the electronic keys to LKMS 215 and LKMS 217 located in the playback component 230 and third-party playback component 240 via the network 233 and IP/data network 210, respectively. The playback components 230, 240 can transmit a request for the electronic keys to the LKMSs 215, 217 to decrypt the encrypted data.


For example, the recording subsystem 235 encrypts and stores data from the company premises 212 using an electronic key from the LKMS 213. The LKMS 213 communicates with the LKMSs 215, 217 via a secure method. The playback components 230, 240 can retrieve the stored, encrypted data from the recording subsystem 235. In addition, the playback components 230, 240 can retrieve the associated electronic key from the LKMSs 215, 217, respectively, using associated key identifications and/or unique identifiers.



FIG. 3 illustrates an exemplary database of electronic keys. The key management system or cache stores the database 301 of the electronic keys. Each electronic key 310 has a key identification 305 and is associated with at least one unique identifier 315 of the encrypted data. For example, data with unique identifiers 0103 and 0106 can be encrypted and decrypted using the electronic key 0033. Retrieval components can retrieve the electronic keys using the unique identifier.



FIG. 4 illustrates an exemplary database of stored data and metadata associated with the stored data. The recording subsystem stores the database 401 of the stored data. Each stored data 410 has a key identification 405. The recording subsystem can use the key identification to retrieve the electronic key for decryption. Additionally or alternatively, retrieval components can use metadata to retrieve the stored, encrypted data. The metadata is associated with the key identifications, which the retrieval components use to retrieve the electronic keys from the key management system or cache.



FIG. 5 is a flow diagram that illustrates operation of an embodiment of an encrypted recording environment such as shown in FIGS. 1 and 2. Beginning with block 505, data associated with an interaction are received, such as at a company premises. In block 510, an electronic key is generated for encrypting the data of the interaction. In block 515, the data are associated with the electronic key. In block 520, the data are encrypted using the electronic key. In block 525, the encrypted data are stored in a recording system.



FIGS. 6A-B are flow diagrams that illustrate operation of an embodiment of an encrypted recording system environment, such as shown in FIGS. 1 and 2. In blocks 605 and 610, a switch receives data associated with an interaction and transmits the data via an IP/data network, respectively. In block 615, a recording system receives the data from the switch. In block 620, the recording system transmits a request to a key management system for an electronic key for encrypting the data of an interaction. In block 625, the key management system generates an electronic key to encrypt the data. In block 630, the key management system associates the electronic key with the data. Alternatively or additionally, the request can be transmitted to a cache that provides an electronic key for encryption of the data. As mentioned above, the cache stores a duplicate copy of at least one electronic keys from the key management system.


In block 635, either the key management system or cache transmits generated electronic keys via a network. In block 640, the recording system encrypts the data using the transmitted keys. In some embodiments, the data are encrypted to include the key identifications of the transmitted keys. In block 645, the recording system stores the encrypted data. In block 650, the recording system receives a request for stored data. The recording system can determine whether a retrieval component has authentication to retrieve the stored data. In block 655, responsive to the determining that the retrieval component has authentication, the recording system transmits the stored data via the network. In block 660, the recording system transmits a request to the key management system or cache to retrieve the associated electronic key for decrypting the stored data. The request for decryption includes the key identification or the unique identifier, or both, which the key management system or cache uses to determine the proper electronic key for decryption of the encrypted data. In block 665, the stored data are decrypted using the electronic keys.



FIG. 7 is a flow diagram that illustrates operation of an embodiment of a key management system. Beginning with block 705, the key management system receives a request to retrieve electronic keys and in block 710, determines whether the request has authentication information to retrieve the electronic keys. In block 715, responsive to determining that the retrieval component has authentication, the key management system generates the electronic keys. Alternatively or additionally, the key management system can maintain a database of electronic keys and select the electronic keys from the database using random, semi-random, and sequential rotation of the electronic keys. Alternatively or additionally, the keys can be active or inactive keys.


In blocks 720 and 725, the key management system associates the generated or selected electronic keys with unique identifiers of the data and transmits the electronic keys for encrypting and decrypting the data, respectively. Alternatively or additionally, the request can include a key identification that the key management system uses to select the electronic key for decryption of the stored data. In block 730, the key management system manages the electronic keys for at least the life of the associated data.



FIG. 8 is a flow diagram that illustrates operation of an embodiment of a cache. In block 805, the cache communicates with a key management system to obtain a duplicate copy of at least one electronic key. In block 810, the cache receives a request to retrieve the electronic keys for encrypting and decrypting data. In block 820, the cache provides an electronic key based on the request. The cache determines whether an electronic key has been associated with the unique identifier. If not, the cache associates an electronic key with the unique identifier, as shown in block 820.


Alternatively or additionally, if a recording subsystem transmits a request for encryption, the cache transmits the electronic key along with the key identification to the retrieval component. The recording subsystem encrypts the data and associates the key identification with the encrypted data. To decrypt the data, the retrieval component can request to the cache for the electronic key that is associated with the key identification and/or the unique identifier. In block 825, the cache transmits the associated electronic keys for encrypting and decrypting the data. In block 830, the cache manages the electronic keys for at least the life of the data.



FIG. 9 is a flow diagram that illustrates operation of an embodiment of a recording subsystem. In block 905, the recording subsystem receives captured data. In block 910, the recording subsystem transmits a request to retrieve electronic keys for encrypting the data. In block 915, the recording subsystem receives the electronic keys for encrypting the data. In block 920, the recording subsystem encrypts the data using the electronic keys.


Alternatively or additionally, in blocks 925 and 930, the recording subsystem receives a request to move stored data to a second recording subsystem and determines whether the second recording subsystem has authentication to store the data, respectively. In block 935, the recording subsystem moves the data to the second recording subsystem.


In block 940, both recording subsystems can receive a request from a playback component for the stored data. In block 945, each recording subsystem determines whether the playback component has authentication to retrieve stored data. In block 950, each recording subsystem transmits a request to a key management system or cache to retrieve associated electronic keys for decrypting the stored data. In blocks 955, each recording subsystem transmits stored data.



FIG. 10 is a flow diagram that illustrates operation of an embodiment of a playback component. In blocks 1005 and 1010, the playback component transmits a request to a recording system to retrieve stored data and provides authentication information to determine whether the playback component has authentication to retrieve stored data, respectively. In block 1015, responsive to determining that the playback component has authentication, the playback component receives stored data from the recording system and associates electronic key from a key management system or cache. In block 1020, the stored data are decrypted using the received key. In block 1025, the playback component plays back the stored data.


It should be emphasized that the above-described embodiments are merely possible examples of implementations, merely set forth for a clear understanding of the principles of the invention. Many variations and modifications may be made to the above-described embodiments without departing substantially from the spirit and principles of the invention. All such modifications and variations are intended to be included herein within the scope of this disclosure and the present invention and protected by the following claims.

Claims
  • 1. A method for retrieving and playing back a secure, captured data in a customer center, comprising the steps of: transmitting a request by a playback component at a customer center to retrieve stored, encrypted data from a recording subsystem, the request to retrieve an electronic key for decrypting the data including a key identification associated with the electronic key and a unique identifier associated with the stored encrypted data in accordance with a context;establishing a secure communication between the playback component and the recording subsystem to retrieve the stored, encrypted data;receiving the stored, encrypted data by the playback component from the recording subsystem;transmitting a request to the recording subsystem to retrieve the electronic key for decrypting the stored, encrypted data;receiving the electronic key by the playback component from the recording subsystem, wherein the electronic key is received electronically via a network, further wherein the electronic key was retrieved by the recording subsystem from a cache operative to receive the request to retrieve the electronic key for decrypting the data;decrypting the stored, encrypted data associated with the unique identifier using the electronic key, wherein other stored, encrypted data not associated with the unique identifier remain encrypted; andplaying back the decrypted data.
  • 2. The method as defined in claim 1, wherein establishing the secure communication comprises transmitting authentication information by the playback component via a network.
  • 3. The method as defined in claim 2, wherein establishing the secure communication further comprises receiving the authentication information by the recording subsystem and determining whether the playback component has authentication based on the authentication information.
  • 4. The method as defined in claim 1, wherein establishing a secure communication comprises establishing a secure tunnel between the playback component and the recording subsystem.
  • 5. The method as defined in claim 4, wherein the secure tunnel is achieved by a cryptographic protocol which provide secure communications on the network.
  • 6. The method as defined in claim 5, wherein the cryptographic protocol is a secure sockets layer.
  • 7. The method as defined in claim 1, wherein decrypting the encrypted data by one of a key management system, a recording subsystem and playback component.
  • 8. A system for retrieving and playing back a secure, captured data in a customer center comprising: a secure communication over a network between a playback component at a customer center, a key management system, a recording subsystem to retrieve stored, encrypted data, and a cache;the recording subsystem operative to:receive the request to retrieve the stored, encrypted data via the network from the playback component,transmit a request to retrieve an electronic key for decrypting the stored, encrypted data via the network, andtransmit the stored data and electronic key electronically via the network to the playback component;the key management system operative to transmit a duplicate copy of the electronic key electronically via the network to the cache;the playback component operative to:transmit a request to retrieve the stored, encrypted data via the network to the recording subsystem,receive the stored, encrypted data and electronic key via the network from the recording subsystem,decrypt the stored, encrypted data associated with the unique identifier using the electronic key, wherein other stored, encrypted data not associated with the unique identifier remain encrypted, andplay back the decrypted data; andthe cache operative to receive the request to retrieve the electronic key for decrypting the data, the request including a key identification associated with the electronic key and unique identifiers associated with the stored data.
  • 9. The system as defined in claim 8, wherein the secure communication is established by transmitting authentication information by the playback component via a network.
  • 10. The system as defined in claim 9, wherein establishing the secure communication further comprises receiving the authentication information by the recording subsystem and determining whether the playback component has authentication based on the authentication information.
  • 11. The system as defined in claim 8, wherein the secure communication is established by establishing a secure tunnel between the playback component and the recording subsystem.
  • 12. The system as defined in claim 11, wherein the secure tunnel is achieved by a cryptographic protocol which provide secure communications on the network.
  • 13. The system as defined in claim 12, wherein the cryptographic protocol is a secure sockets layer.
  • 14. The system as defined in claim 8, wherein the key management system is further operative to decrypt the stored, encrypted data and transmit the decrypted data to the playback component for play back.
  • 15. The system as defined in claim 8, wherein the recording subsystem is further operative to decrypt the stored, encrypted data and transmit the decrypted data to the playback component for play back.
  • 16. A system for retrieving and playing back a secure, captured data in a customer center comprising: a secure communication over a network between a playback component at a customer center, a key management system operative to receive a request to retrieve the electronic key for decrypting the data and a recording subsystem to retrieve stored, encrypted data;the recording subsystem operative to:receive the request to retrieve the stored, encrypted data via the network from the playback component, the request to retrieve the electronic key for decrypting the data including a key identification associated with the electronic key and a unique identifier associated with the stored encrypted data in accordance with a context,transmit a request to retrieve an electronic key for decrypting the stored, encrypted data via the network to a cache;receive the electronic key electronically via the network;decrypt the stored, encrypted data associated with the unique identifier using the electronic key, wherein other stored, encrypted data not associated with the unique identifier remain encrypted, andtransmit the decrypted data via the network,the cache operative to receive the request to retrieve the electronic key for decrypting the data, the request including a key identification associated with the electronic key and unique identifiers associated with the stored data; andthe playback component operative to:transmit a request to retrieve the stored, encrypted data via the network to the recording subsystem,receive the decrypted data via the network from the recording subsystem, and play back the decrypted data.
  • 17. The system as defined in claim 16, further comprising a key management system operative to transmit a duplicate copy of at least one key to the cache.
US Referenced Citations (203)
Number Name Date Kind
3594919 De Bell et al. Jul 1971 A
3705271 De Bell et al. Dec 1972 A
4510351 Costello et al. Apr 1985 A
4684349 Ferguson et al. Aug 1987 A
4694483 Cheung Sep 1987 A
4763353 Canale et al. Aug 1988 A
4815120 Kosich Mar 1989 A
4924488 Kosich May 1990 A
4953159 Hayden et al. Aug 1990 A
5016272 Stubbs et al. May 1991 A
5101402 Chiu et al. Mar 1992 A
5117225 Wang May 1992 A
5210789 Jeffus et al. May 1993 A
5239460 LaRoche Aug 1993 A
5241625 Epard et al. Aug 1993 A
5267865 Lee et al. Dec 1993 A
5299260 Shaio Mar 1994 A
5311422 Loftin et al. May 1994 A
5315711 Barone et al. May 1994 A
5317628 Misholi et al. May 1994 A
5347306 Nitta Sep 1994 A
5388252 Dreste et al. Feb 1995 A
5396371 Henits et al. Mar 1995 A
5432715 Shigematsu et al. Jul 1995 A
5465286 Clare et al. Nov 1995 A
5475625 Glaschick Dec 1995 A
5485569 Goldman et al. Jan 1996 A
5491780 Fyles et al. Feb 1996 A
5499291 Kepley Mar 1996 A
5535256 Maloney et al. Jul 1996 A
5572652 Robusto et al. Nov 1996 A
5577112 Cambray et al. Nov 1996 A
5590171 Howe et al. Dec 1996 A
5597312 Bloom et al. Jan 1997 A
5619183 Ziegra et al. Apr 1997 A
5696906 Peters et al. Dec 1997 A
5717879 Moran et al. Feb 1998 A
5721842 Beasley et al. Feb 1998 A
5742670 Bennett Apr 1998 A
5748499 Trueblood May 1998 A
5778182 Cathey et al. Jul 1998 A
5784452 Carney Jul 1998 A
5790798 Beckett, II et al. Aug 1998 A
5796952 Davis et al. Aug 1998 A
5809247 Richardson et al. Sep 1998 A
5809250 Kisor Sep 1998 A
5825869 Brooks et al. Oct 1998 A
5835572 Richardson, Jr. et al. Nov 1998 A
5862330 Anupam et al. Jan 1999 A
5864772 Alvarado et al. Jan 1999 A
5884032 Bateman et al. Mar 1999 A
5907680 Nielsen May 1999 A
5918214 Perkowski Jun 1999 A
5923746 Baker et al. Jul 1999 A
5933811 Angles et al. Aug 1999 A
5944791 Scherpbier Aug 1999 A
5948061 Merriman et al. Sep 1999 A
5958016 Chang et al. Sep 1999 A
5964836 Rowe et al. Oct 1999 A
5978648 George et al. Nov 1999 A
5982857 Brady Nov 1999 A
5987466 Greer et al. Nov 1999 A
5990852 Szamrej Nov 1999 A
5991373 Pattison et al. Nov 1999 A
5991796 Anupam et al. Nov 1999 A
6005932 Bloom Dec 1999 A
6009429 Greer et al. Dec 1999 A
6014134 Bell et al. Jan 2000 A
6014647 Nizzari et al. Jan 2000 A
6018619 Allard et al. Jan 2000 A
6035332 Ingrassia et al. Mar 2000 A
6038544 Machin et al. Mar 2000 A
6039575 L'Allier et al. Mar 2000 A
6055314 Spies et al. Apr 2000 A
6057841 Thurlow et al. May 2000 A
6058163 Pattison et al. May 2000 A
6061798 Coley et al. May 2000 A
6072860 Kek et al. Jun 2000 A
6076099 Chen et al. Jun 2000 A
6078894 Clawson et al. Jun 2000 A
6091712 Pope et al. Jul 2000 A
6108711 Beck et al. Aug 2000 A
6122665 Bar et al. Sep 2000 A
6122668 Teng et al. Sep 2000 A
6130668 Stein Oct 2000 A
6138139 Beck et al. Oct 2000 A
6144991 England Nov 2000 A
6146148 Stuppy Nov 2000 A
6151622 Fraenkel et al. Nov 2000 A
6154771 Rangan et al. Nov 2000 A
6157808 Hollingsworth Dec 2000 A
6171109 Ohsuga Jan 2001 B1
6182094 Humpleman et al. Jan 2001 B1
6195679 Bauersfeld et al. Feb 2001 B1
6201948 Cook et al. Mar 2001 B1
6211451 Tohgi et al. Apr 2001 B1
6225993 Lindblad et al. May 2001 B1
6230197 Beck et al. May 2001 B1
6236977 Verba et al. May 2001 B1
6244758 Solymar et al. Jun 2001 B1
6282548 Burner et al. Aug 2001 B1
6286030 Wenig et al. Sep 2001 B1
6286046 Bryant Sep 2001 B1
6288753 DeNicola et al. Sep 2001 B1
6289340 Puram et al. Sep 2001 B1
6301462 Freeman et al. Oct 2001 B1
6301573 McIlwaine et al. Oct 2001 B1
6324282 McIlwaine et al. Nov 2001 B1
6347374 Drake et al. Feb 2002 B1
6351467 Dillon Feb 2002 B1
6353851 Anupam et al. Mar 2002 B1
6360250 Anupam et al. Mar 2002 B1
6370574 House et al. Apr 2002 B1
6398245 Gruse et al. Jun 2002 B1
6404857 Blair et al. Jun 2002 B1
6411989 Anupam et al. Jun 2002 B1
6418471 Shelton et al. Jul 2002 B1
6459787 McIlwaine et al. Oct 2002 B2
6487195 Choung et al. Nov 2002 B1
6493758 McLain Dec 2002 B1
6502131 Vaid et al. Dec 2002 B1
6510220 Beckett, II et al. Jan 2003 B1
6523113 Wehrenberg Feb 2003 B1
6535909 Rust Mar 2003 B1
6542602 Elazar Apr 2003 B1
6546405 Gupta et al. Apr 2003 B2
6560328 Bondarenko et al. May 2003 B1
6574609 Downs et al. Jun 2003 B1
6583806 Ludwig et al. Jun 2003 B2
6606657 Zilberstein et al. Aug 2003 B1
6625734 Marvit et al. Sep 2003 B1
6665644 Kanevsky et al. Dec 2003 B1
6674447 Chiang et al. Jan 2004 B1
6683633 Holtzblatt et al. Jan 2004 B2
6697858 Ezerzer et al. Feb 2004 B1
6724887 Eilbacher et al. Apr 2004 B1
6738456 Wrona et al. May 2004 B2
6757361 Blair et al. Jun 2004 B2
6772396 Cronin et al. Aug 2004 B1
6775377 McIlwaine et al. Aug 2004 B2
6792575 Samaniego et al. Sep 2004 B1
6810414 Brittain Oct 2004 B1
6820083 Nagy et al. Nov 2004 B1
6823384 Wilson et al. Nov 2004 B1
6870916 Henrikson et al. Mar 2005 B2
6876986 Currans et al. Apr 2005 B1
6901438 Davis et al. May 2005 B1
6912513 Candelore Jun 2005 B1
6954854 Miura et al. Oct 2005 B1
6959078 Eilbacher et al. Oct 2005 B1
6965886 Govrin et al. Nov 2005 B2
6981138 Douceur et al. Dec 2005 B2
7047422 Benaloh May 2006 B2
7073063 Peinado Jul 2006 B2
7111005 Wessman Sep 2006 B1
7124304 Bel et al. Oct 2006 B2
7130426 Cha et al. Oct 2006 B1
7242771 Shiragami et al. Jul 2007 B2
7266691 Ishiguro et al. Sep 2007 B1
7272229 Nakano et al. Sep 2007 B2
7272230 Sasaki Sep 2007 B2
7275159 Hull et al. Sep 2007 B2
7346774 Douceur et al. Mar 2008 B2
7352867 Medvinsky Apr 2008 B2
7362870 Okaue Apr 2008 B2
7472280 Giobbi Dec 2008 B2
7503073 Kawamoto et al. Mar 2009 B2
7624412 McEvilly et al. Nov 2009 B2
20010000962 Rajan May 2001 A1
20010032335 Jones Oct 2001 A1
20010043697 Cox et al. Nov 2001 A1
20020038363 MacLean Mar 2002 A1
20020052948 Baudu et al. May 2002 A1
20020064283 Parenty May 2002 A1
20020065911 Von Klopp et al. May 2002 A1
20020065912 Catchpole et al. May 2002 A1
20020128925 Angeles Sep 2002 A1
20020143925 Pricer et al. Oct 2002 A1
20020144116 Giobbi Oct 2002 A1
20020165954 Eshghi et al. Nov 2002 A1
20020194492 Choi et al. Dec 2002 A1
20030055883 Wiles et al. Mar 2003 A1
20030079020 Gourraud et al. Apr 2003 A1
20030144900 Whitmer Jul 2003 A1
20030154240 Nygren et al. Aug 2003 A1
20040010468 Abe et al. Jan 2004 A1
20040100507 Hayner et al. May 2004 A1
20040165717 McIlwaine et al. Aug 2004 A1
20050050345 Dowdy et al. Mar 2005 A1
20050138560 Lee et al. Jun 2005 A1
20050144459 Qureshi et al. Jun 2005 A1
20050190947 Dulac Sep 2005 A1
20050213767 Matsukawa et al. Sep 2005 A1
20050249350 Kahn et al. Nov 2005 A1
20050271211 Takemura Dec 2005 A1
20060026425 Douceur et al. Feb 2006 A1
20060158737 Hu et al. Jul 2006 A1
20060200415 Lu Sep 2006 A1
20060206945 Kato et al. Sep 2006 A1
20060242069 Peterka et al. Oct 2006 A1
20070174067 Ito et al. Jul 2007 A1
20070230703 Barrus et al. Oct 2007 A1
20070297610 Chen et al. Dec 2007 A1
Foreign Referenced Citations (6)
Number Date Country
0453128 Oct 1991 EP
0773687 May 1997 EP
0989720 Mar 2000 EP
2369263 May 2002 GB
WO 9843380 Nov 1998 WO
WO 0016207 Mar 2000 WO
Related Publications (1)
Number Date Country
20080005588 A1 Jan 2008 US