Abstract: A device, such as a terminal device, for example, has an operating system (OS) and an application program that executes on the OS. When executing on the device, the application program configures the device to communicate packet data with a server device, and to handle service-specific traffic, and application-specific traffic, in accordance with a distributed port mapping policy.

Abstract: A client receives sensitive data to be tokenized. The client queries a token table with a portion of the sensitive data to determine if the token table includes a token mapped to the value of the portion of the sensitive data. If the mapping table does not include a token mapped to the value of the portion of the sensitive data, a candidate token is generated. The client queries a central token management system to determine if the candidate token collides with a token generated by or stored at another client. In some embodiments, the candidate token includes a value from a unique set of values assigned by the central token management system to the client, guaranteeing that the candidate token does not cause a collision. The client then tokenizes the sensitive data with the candidate token and stores the candidate token in the token table.

Abstract: Data can be protected in mobile and payment environments through various tokenization operations. A mobile device can tokenize communication data based on device information and session information associated with the mobile device. A payment terminal can tokenize payment information received at the payment terminal during a transaction based on transaction information associated with the transaction. Payment data tokenized first a first set of token tables and according to a first set of tokenization parameters by a first payment entity can be detokenized or re-tokenized with a second set of token tables and according to a second set of tokenization parameters. Payment information can be tokenized and sent to a mobile device as a token card based on one or more selected use rules, and a user can request a transaction based on the token card. The transaction can be authorized if the transaction satisfies the selected use rules.

Abstract: A tokenization system tokenizes sensitive data to prevent unauthorized entities from accessing the sensitive data. The tokenization system accesses sensitive data, and retrieves an initialization vector (IV) from an IV table using a first portion of the sensitive data. A second portion of the sensitive data is modified using the accessed initialization vector. A token table is selected from a set of token tables using a third portion of the sensitive data. The modified second portion of data is used to query the selected token table, and a token associated with the value of the modified second portion of data is accessed. The second portion of the sensitive data is replaced with the accessed token to form tokenized data.

Abstract: A gateway device for implementing data security is described herein. The gateway device is coupled between a client device and a server device, and is configured to receive encoded data and a set of operations from the server device in response to a request for cloud services from the client device. The gateway device is configured to decode the encoded data, and to provide the decoded data and the set of operations to the client device. The client device is configured to perform the set of operations on the decoded data, and to incorporate the operation results into an application or interface corresponding to the requested cloud service. The gateway device is configured to encode the operation result data, and to provide the encoded operation result data to the server device for storage.

Abstract: A system for secure data storage and transmission is provided. The system comprises a first security module for protecting data in a first data at rest system and a second security module for protecting data in a second data at rest system. At least one encryption parameter for the second data at rest system differs from at least one encryption parameter for the first data at rest system so that a datum is reencrypted when the datum is transferred from the first data at rest system to the second data at rest system.

Abstract: The present invention relates to control of downlink data in a packet based telecommunications network and in particular to UE control of downlink data. This is provided in devices and methods for handling such control, for instance a user equipment (101), UE, in a telecommunications network (100). The UE has an associated Internet Protocol, IP, address. The UE comprises at least one processing unit (201), at least one computer readable storage unit (202), at least one communications interface (203), and wherein the processing unit is arranged to execute instructions sets stored in the storage unit for determining that no downlink data is to be received on the communication interface and sending a message using the communication interface to an infrastructure node (103, 104) indicating that no downlink data is to be transferred to the UE.

Abstract: A tokenization system tokenizes sensitive data to prevent unauthorized entities from accessing the sensitive data. The tokenization system accesses sensitive data, and retrieves an initialization vector (IV) from an IV table using a first portion of the sensitive data. A second portion of the sensitive data is modified using the accessed initialization vector. A token table is selected from a set of token tables using a third portion of the sensitive data. The modified second portion of data is used to query the selected token table, and a token associated with the value of the modified second portion of data is accessed. The second portion of the sensitive data is replaced with the accessed token to form tokenized data.

Abstract: Data can be protected in mobile and payment environments through various tokenization operations. A mobile device can tokenize communication data based on device information and session information associated with the mobile device. A payment terminal can tokenize payment information received at the payment terminal during a transaction based on transaction information associated with the transaction. Payment data tokenized first a first set of token tables and according to a first set of tokenization parameters by a first payment entity can be detokenized or re-tokenized with a second set of token tables and according to a second set of tokenization parameters. Payment information can be tokenized and sent to a mobile device as a token card based on one or more selected use rules, and a user can request a transaction based on the token card. The transaction can be authorized if the transaction satisfies the selected use rules.

Abstract: New tokenization tables are derived at intervals in order to increase the security of tokenized data that is transferred between two endpoints. Generation of the new tokenization tables is based on previous tokenization tables, which advantageously allows the generation process to be performed locally at the two endpoints independently of an external tokenization table provider. New tokenization tables can periodically be distributed to the endpoints as a new starting point for derivation.

Abstract: Database entries can be protected by indexing the entries using a plurality of indexes, each associated with a level of access rights. A level of access rights can be determined from a search query, and an index can be selected based on the determined level of access rights. A search key can be generated based on the received query, and the selected index can be searched using the search query. Database entries mapped to the values of the selected index returned in response to the search can be outputted. Each index is associated with a different granularity defining the number and/or ambiguity of search results returned in response to searching an index.

Abstract: A tokenization system includes a vector table and one or more token tables. The tokenization system accesses sensitive data and a vector from a vector table column, and modifies the sensitive data based on the accessed vector. The tokenization system then queries the one or more token tables using a portion of the modified data to identify a token mapped to the portion of the modified data. The portion of the modified data is replaced with the token to create tokenized data. The vector table can be updated by replacing a vector table column with an updated vector table column. The tokenization system can modify subsequent data using the updated vector column prior to tokenization.

Abstract: Data can be protected in mobile and payment environments through various tokenization operations. A mobile device can tokenize communication data based on device information and session information associated with the mobile device. A payment terminal can tokenize payment information received at the payment terminal during a transaction based on transaction information associated with the transaction. Payment data tokenized first a first set of token tables and according to a first set of tokenization parameters by a first payment entity can be detokenized or re-tokenized with a second set of token tables and according to a second set of tokenization parameters. Payment information can be tokenized and sent to a mobile device as a token card based on one or more selected use rules, and a user can request a transaction based on the token card. The transaction can be authorized if the transaction satisfies the selected use rules.

Abstract: Data can be protected in mobile and payment environments through various tokenization operations. A mobile device can tokenize communication data based on device information and session information associated with the mobile device. A payment terminal can tokenize payment information received at the payment terminal during a transaction based on transaction information associated with the transaction. Payment data tokenized first a first set of token tables and according to a first set of tokenization parameters by a first payment entity can be detokenized or re-tokenized with a second set of token tables and according to a second set of tokenization parameters. Payment information can be tokenized and sent to a mobile device as a token card based on one or more selected use rules, and a user can request a transaction based on the token card. The transaction can be authorized if the transaction satisfies the selected use rules.

Abstract: Database entries can be protected by indexing the entries using a plurality of indexes, each associated with a level of access rights. A level of access rights can be determined from a search query, and an index can be selected based on the determined level of access rights. A search key can be generated based on the received query, and the selected index can be searched using the search query. Database entries mapped to the values of the selected index returned in response to the search can be outputted. Each index is associated with a different granularity defining the number and/or ambiguity of search results returned in response to searching an index.

Abstract: New tokenization tables are derived at intervals in order to increase the security of tokenized data that is transferred between two endpoints. Generation of the new tokenization tables is based on previous tokenization tables, which advantageously allows the generation process to be performed locally at the two endpoints independently of an external tokenization table provider. New tokenization tables can periodically be distributed to the endpoints as a new starting point for derivation.

Abstract: A tokenization system includes a vector table and one or more token tables. The tokenization system accesses sensitive data and a vector from a vector table column, and modifies the sensitive data based on the accessed vector. The tokenization system then queries the one or more token tables using a portion of the modified data to identify a token mapped to the portion of the modified data. The portion of the modified data is replaced with the token to create tokenized data. The vector table can be updated by replacing a vector table column with an updated vector table column. The tokenization system can modify subsequent data using the updated vector column prior to tokenization.

Abstract: Systems and methods are provided for the detection and prevention of intrusions in data at rest systems such as file systems and web servers. The systems and methods regulate access to sensitive data with minimal dependency on a communications network. Data access is quantitatively limited to minimize the data breaches resulting from, e.g., a stolen laptop or hard drive.

Abstract: A client receives sensitive data to be tokenized. The client queries a token table with a portion of the sensitive data to determine if the token table includes a token mapped to the value of the portion of the sensitive data. If the mapping table does not include a token mapped to the value of the portion of the sensitive data, a candidate token is generated. The client queries a central token management system to determine if the candidate token collides with a token generated by or stored at another client. In some embodiments, the candidate token includes a value from a unique set of values assigned by the central token management system to the client, guaranteeing that the candidate token does not cause a collision. The client then tokenizes the sensitive data with the candidate token and stores the candidate token in the token table.

Abstract: Data can be protected in mobile and payment environments through various tokenization operations. A mobile device can tokenize communication data based on device information and session information associated with the mobile device. A payment terminal can tokenize payment information received at the payment terminal during a transaction based on transaction information associated with the transaction. Payment data tokenized first a first set of token tables and according to a first set of tokenization parameters by a first payment entity can be detokenized or re-tokenized with a second set of token tables and according to a second set of tokenization parameters. Payment information can be tokenized and sent to a mobile device as a token card based on one or more selected use rules, and a user can request a transaction based on the token card. The transaction can be authorized if the transaction satisfies the selected use rules.