Shape tables are a feature of the Apple II ROMs which allows for manipulation of small images encoded as a series of vectors. An image (or shape) can be drawn in the high-resolution graphics mode—with scaling and rotation—via software routines in the ROM. Shape tables are supported via Applesoft BASIC and from machine code in the "Programmer's Aid" package that was bundled with the original Integer BASIC ROMs for that computer. Applesoft's high-resolution graphics routines were not optimized for speed, so shape tables were not typically used for performance-critical software such as games, which were typically written in assembly language and used pre-shifted bitmap shapes. Shape tables were used primarily for static shapes and sometimes for fancy text; Beagle Bros offered a number of fonts in Font Mechanic as Applesoft shape tables. == Technical details == The vectors of a two-dimensional graphic, each encoding a direction from the previous pixel along with a flag indicating whether the new pixel should be illuminated or not, were encoded up to three in a byte. These were stored in a table via the Monitor or the POKE command. From there, the graphic could be referenced by number (a table could contain up to 255 shapes), and built-in Applesoft routines permitted scaling, rotating, and drawing or erasing the shape. An XOR mode was also available to allow the shape to be visible on any color background; this had the advantage, also, of allowing the shape to be easily erased by redrawing it. Apple did not provide any utilities for creating shape tables; they had to be created by hand, usually by plotting on graph paper, then calculating the hexadecimal values and entering them into the computer. Beagle Bros created a shape table editing program, which eliminated the "number crunching", called Apple Mechanic, and a related program, Font Mechanic.
Kuwahara filter
The Kuwahara filter is a non-linear smoothing filter used in image processing for adaptive noise reduction. Most filters that are used for image smoothing are linear low-pass filters that effectively reduce noise but also blur out the edges. However the Kuwahara filter is able to apply smoothing on the image while preserving the edges. It is named after Michiyoshi Kuwahara, Ph.D., who worked at Kyoto and Osaka Sangyo Universities in Japan, developing early medical imaging of dynamic heart muscle in the 1970s and 80s. == The Kuwahara operator == Suppose that I ( x , y ) {\displaystyle I(x,y)} is a grey scale image and that we take a square window of size 2 a + 1 {\displaystyle 2a+1} centered around a point ( x , y ) {\displaystyle (x,y)} in the image. This square can be divided into four smaller square regions Q i = 1 ⋯ 4 {\displaystyle Q_{i=1\cdots 4}} each of which will be Q i ( x , y ) = { [ x , x + a ] × [ y , y + a ] if i = 1 [ x − a , x ] × [ y , y + a ] if i = 2 [ x − a , x ] × [ y − a , y ] if i = 3 [ x , x + a ] × [ y − a , y ] if i = 4 {\displaystyle Q_{i}(x,y)={\begin{cases}\left[x,x+a\right]\times \left[y,y+a\right]&{\mbox{ if }}i=1\\\left[x-a,x\right]\times \left[y,y+a\right]&{\mbox{ if }}i=2\\\left[x-a,x\right]\times \left[y-a,y\right]&{\mbox{ if }}i=3\\\left[x,x+a\right]\times \left[y-a,y\right]&{\mbox{ if }}i=4\\\end{cases}}} where × {\displaystyle \times } is the cartesian product. Pixels located on the borders between two regions belong to both regions so there is a slight overlap between subregions. The arithmetic mean m i ( x , y ) {\displaystyle m_{i}(x,y)} and standard deviation σ i ( x , y ) {\displaystyle \sigma _{i}(x,y)} of the four regions centered around a pixel (x,y) are calculated and used to determine the value of the central pixel. The output of the Kuwahara filter Φ ( x , y ) {\displaystyle \Phi (x,y)} for any point ( x , y ) {\displaystyle (x,y)} is then given by Φ ( x , y ) = m i ( x , y ) {\textstyle \Phi (x,y)=m_{i}(x,y)} where i = a r g min j σ j ( x , y ) {\displaystyle i=\operatorname {arg\min } _{j}\sigma _{j}(x,y)} . This means that the central pixel will take the mean value of the area that is most homogenous. The location of the pixel in relation to an edge plays a great role in determining which region will have the greater standard deviation. If for example the pixel is located on a dark side of an edge it will most probably take the mean value of the dark region. On the other hand, should the pixel be on the lighter side of an edge it will most probably take a light value. On the event that the pixel is located on the edge it will take the value of the more smooth, least textured region. The fact that the filter takes into account the homogeneity of the regions ensures that it will preserve the edges while using the mean creates the blurring effect. Similarly to the median filter, the Kuwahara filter uses a sliding window approach to access every pixel in the image. The size of the window is chosen in advance and may vary depending on the desired level of blur in the final image. Bigger windows typically result in the creation of more abstract images whereas small windows produce images that retain their detail. Typically windows are chosen to be square with sides that have an odd number of pixels for symmetry. However, there are variations of the Kuwahara filter that use rectangular windows. Additionally, the subregions do not need to overlap or have the same size as long as they cover all of the window. == Color images == For color images, the filter should not be performed by applying the filter to each RGB channel separately, and then recombining the three filtered color channels to form the filtered RGB image. The main problem with that is that the quadrants will have different standard deviations for each of the channels. For example, the upper left quadrant may have the lowest standard deviation in the red channel, but the lower right quadrant may have the lowest standard deviation in the green channel. This situation would result in the color of the central pixel to be determined by different regions, which might result in color artifacts or blurrier edges. To overcome this problem, for color images a slightly modified Kuwahara filter must be used. The image is first converted into another color space, the HSV color space. The modified filter then operates on only the "brightness" channel, the Value coordinate in the HSV model. The variance of the "brightness" of each quadrant is calculated to determine the quadrant from which the final filtered color should be taken from. The filter will produce an output for each channel which will correspond to the mean of that channel from the quadrant that had the lowest standard deviation in "brightness". This ensures that only one region will determine the RGB values of the central pixel. ImageMagick uses a similar approach, but using the Rec. 709 Luma as the brightness metric. === Julia Implementation === == Applications == Originally the Kuwahara filter was proposed for use in processing RI-angiocardiographic images of the cardiovascular system. The fact that any edges are preserved when smoothing makes it especially useful for feature extraction and segmentation and explains why it is used in medical imaging. The Kuwahara filter however also finds many applications in artistic imaging and fine-art photography due to its ability to remove textures and sharpen the edges of photographs. The level of abstraction helps create a desirable painting-like effect in artistic photographs especially in the case of the colored image version of the filter. These applications have known great success and have encouraged similar research in the field of image processing for the arts. Although the vast majority of applications have been in the field of image processing there have been cases that use modifications of the Kuwahara filter for machine learning tasks such as clustering. The Kuwahara filter has been implemented in CVIPtools. The Kuwahara filter is present as a shader node in Blender. == Drawbacks and restrictions == The Kuwahara filter despite its capabilities in edge preservation has certain drawbacks. At a first glance it is noticeable that the Kuwahara filter does not take into account the case where two regions have equal standard deviations. This is not often the case in real images since it is rather hard to find two regions with exactly the same standard deviation due to the noise that is always present. In cases where two regions have similar standard deviations the value of the center pixel could be decided at random by the noise in these regions. Again this would not be a problem if the regions had the same mean. However, it is not unusual for regions of very different means to have the same standard deviation. This makes the Kuwahara filter susceptible to noise. Different ways have been proposed for dealing with this issue, one of which is to set the value of the center pixel to ( m 1 + m 2 ) / 2 {\textstyle (m_{1}+m_{2})/2} in cases where the standard deviation of two regions do not differ more than a certain value D {\displaystyle D} . The Kuwahara filter is also known to create block artifacts in the images especially in regions of the image that are highly textured. These blocks disrupt the smoothness of the image and are considered to have a negative effect in the aesthetics of the image. This phenomenon occurs due to the division of the window into square regions. A way to overcome this effect is to take windows that are not rectangular(i.e. circular windows) and separate them into more non-rectangular regions. There have also been approaches where the filter adapts its window depending on the input image. == Extensions of the Kuwahara filter == The success of the Kuwahara filter has spurred an increase the development of edge-enhancing smoothing filters. Several variations have been proposed for similar use most of which attempt to deal with the drawbacks of the original Kuwahara filter. The "Generalized Kuwahara filter" proposed by P. Bakker considers several windows that contain a fixed pixel. Each window is then assigned an estimate and a confidence value. The value of the fixed pixel then takes the value of the estimate of the window with the highest confidence. This filter is not characterized by the same ambiguity in the presence of noise and manages to eliminate the block artifacts. The "Mean of Least Variance"(MLV) filter, proposed by M.A. Schulze also produces edge-enhancing smoothing results in images. Similarly to the Kuwahara filter it assumes a window of size 2 d − 1 × 2 d − 1 {\displaystyle 2d-1\times 2d-1} but instead of searching amongst four subregions of size d × d {\displaystyle d\times d} for the one with minimum variance it searches amongst all possible d × d {\displaystyle d\times d} subregions. This means the central pixel of the window will be assigned the mean of the one subregion out of a poss
Foreign key
A foreign key is a set of attributes in a table that refers to the primary key of another table, linking these two tables. In the context of relational databases, a foreign key is subject to an inclusion dependency constraint that the tuples consisting of the foreign key attributes in one relation, R, must also exist in some other (not necessarily distinct) relation, S; furthermore that those attributes must also be a candidate key in S. In other words, a foreign key is a set of attributes that references a candidate key. For example, a table called TEAM may have an attribute, MEMBER_NAME, which is a foreign key referencing a candidate key, PERSON_NAME, in the PERSON table. Since MEMBER_NAME is a foreign key, any value existing as the name of a member in TEAM must also exist as a person's name in the PERSON table; in other words, every member of a TEAM is also a PERSON. == Summary == The table containing the foreign key is called the child table, and the table containing the candidate key is called the referenced or parent table. In database relational modeling and implementation, a candidate key is a set of zero or more attributes, the values of which are guaranteed to be unique for each tuple (row) in a relation. The value or combination of values of candidate key attributes for any tuple cannot be duplicated for any other tuple in that relation. Since the purpose of the foreign key is to identify a particular row of referenced table, it is generally required that the foreign key is equal to the candidate key in some row of the primary table, or else have no value (the NULL value.). This rule is called a referential integrity constraint between the two tables. Because violations of these constraints can be the source of many database problems, most database management systems provide mechanisms to ensure that every non-null foreign key corresponds to a row of the referenced table. For example, consider a database with two tables: a CUSTOMER table that includes all customer data and an ORDER table that includes all customer orders. Suppose the business requires that each order must refer to a single customer. To reflect this in the database, a foreign key column is added to the ORDER table (e.g., CUSTOMERID), which references the primary key of CUSTOMER (e.g. ID). Because the primary key of a table must be unique, and because CUSTOMERID only contains values from that primary key field, we may assume that, when it has a value, CUSTOMERID will identify the particular customer which placed the order. However, this can no longer be assumed if the ORDER table is not kept up to date when rows of the CUSTOMER table are deleted or the ID column altered, and working with these tables may become more difficult. Many real world databases work around this problem by 'inactivating' rather than physically deleting master table foreign keys, or by complex update programs that modify all references to a foreign key when a change is needed. Foreign keys play an essential role in database design. One important part of database design is making sure that relationships between real-world entities are reflected in the database by references, using foreign keys to refer from one table to another. Another important part of database design is database normalization, in which tables are broken apart and foreign keys make it possible for them to be reconstructed. Multiple rows in the referencing (or child) table may refer to the same row in the referenced (or parent) table. In this case, the relationship between the two tables is called a one to many relationship between the referencing table and the referenced table. In addition, the child and parent table may, in fact, be the same table, i.e. the foreign key refers back to the same table. Such a foreign key is known in SQL:2003 as a self-referencing or recursive foreign key. In database management systems, this is often accomplished by linking a first and second reference to the same table. A table may have multiple foreign keys, and each foreign key can have a different parent table. Each foreign key is enforced independently by the database system. Therefore, cascading relationships between tables can be established using foreign keys. A foreign key is defined as an attribute or set of attributes in a relation whose values match a primary key in another relation. The syntax to add such a constraint to an existing table is defined in SQL:2003 as shown below. Omitting the column list in the REFERENCES clause implies that the foreign key shall reference the primary key of the referenced table. Likewise, foreign keys can be defined as part of the CREATE TABLE SQL statement. If the foreign key is a single column only, the column can be marked as such using the following syntax: Foreign keys can be defined with a stored procedure statement. child_table: the name of the table or view that contains the foreign key to be defined. parent_table: the name of the table or view that has the primary key to which the foreign key applies. The primary key must already be defined. col3 and col4: the name of the columns that make up the foreign key. The foreign key must have at least one column and at most eight columns. == Referential actions == Because the database management system enforces referential constraints, it must ensure data integrity if rows in a referenced table are to be deleted (or updated). If dependent rows in referencing tables still exist, those references have to be considered. SQL:2003 specifies 5 different referential actions that shall take place in such occurrences: CASCADE RESTRICT NO ACTION SET NULL SET DEFAULT === CASCADE === Whenever rows in the parent (referenced) table are deleted (or updated), the respective rows of the child (referencing) table with a matching foreign key column will be deleted (or updated) as well. This is called a cascade delete (or update). === RESTRICT === A value cannot be updated or deleted when a row exists in a referencing or child table that references the value in the referenced table. Similarly, a row cannot be deleted as long as there is a reference to it from a referencing or child table. To understand RESTRICT (and CASCADE) better, it may be helpful to notice the following difference, which might not be immediately clear. The referential action CASCADE modifies the "behavior" of the (child) table itself where the word CASCADE is used. For example, ON DELETE CASCADE effectively says "When the referenced row is deleted from the other table (master table), then delete also from me". However, the referential action RESTRICT modifies the "behavior" of the master table, not the child table, although the word RESTRICT appears in the child table and not in the master table! So, ON DELETE RESTRICT effectively says: "When someone tries to delete the row from the other table (master table), prevent deletion from that other table (and of course, also don't delete from me, but that's not the main point here)." RESTRICT is not supported by Microsoft SQL 2012 and earlier. === NO ACTION === NO ACTION and RESTRICT are very much alike. The main difference between NO ACTION and RESTRICT is that with NO ACTION the referential integrity check is done after trying to alter the table. RESTRICT does the check before trying to execute the UPDATE or DELETE statement. Both referential actions act the same if the referential integrity check fails: the UPDATE or DELETE statement will result in an error. In other words, when an UPDATE or DELETE statement is executed on the referenced table using the referential action NO ACTION, the DBMS verifies at the end of the statement execution that none of the referential relationships are violated. This is different from RESTRICT, which assumes at the outset that the operation will violate the constraint. Using NO ACTION, the triggers or the semantics of the statement itself may yield an end state in which no foreign key relationships are violated by the time the constraint is finally checked, thus allowing the statement to complete successfully. === SET NULL, SET DEFAULT === In general, the action taken by the DBMS for SET NULL or SET DEFAULT is the same for both ON DELETE or ON UPDATE: the value of the affected referencing attributes is changed to NULL for SET NULL, and to the specified default value for SET DEFAULT. === Triggers === Referential actions are generally implemented as implied triggers (i.e. triggers with system-generated names, often hidden.) As such, they are subject to the same limitations as user-defined triggers, and their order of execution relative to other triggers may need to be considered; in some cases it may become necessary to replace the referential action with its equivalent user-defined trigger to ensure proper execution order, or to work around mutating-table limitations. Another important limitation appears with transaction isolation: your changes to a row may not be able to fully cascade because the row is ref
TiDB
TiDB (; "Ti" stands for Titanium) is an open-source NewSQL database that supports Hybrid Transactional and Analytical Processing (HTAP) workloads. Designed to be MySQL compatible, it is developed and supported primarily by PingCAP and licensed under Apache 2.0. It is also available as a paid product. TiDB drew its initial design inspiration from Google's Spanner and F1 papers. == Release history == See all TiDB release notes. On December 19, 2024, TiDB 8.5 GA was released. On May 24, 2024, TiDB 8.1 GA was released. On December 1, 2023, TiDB 7.5 GA was released. On May 31, 2023, TiDB 7.1 GA was released. On April 7, 2022, TiDB 6.0 GA was released. On April 7, 2021 TiDB 5.0 GA was released. On May 28, 2020, TiDB 4.0 GA was released. On June 28, 2019, TiDB 3.0 GA was released. On April 27, 2018, TiDB 2.0 GA was released. On October 16, 2017, TiDB 1.0 GA was released. == Main features == === Horizontal scalability === TiDB can expand both SQL processing and storage capacity by adding new nodes. === MySQL compatibility === TiDB acts like it is a MySQL 8.0 server to applications. A user can continue to use all of the existing MySQL client libraries. Because TiDB's SQL processing layer is built from scratch, it is not a MySQL fork. === Distributed transactions with strong consistency === TiDB internally shards a table into small range-based chunks that are referred to as "Regions". Each Region defaults to approximately 100 MB in size, and TiDB uses a two-phase commit internally to ensure that regions are maintained in a transactionally consistent way. === Cloud native === TiDB is designed to work in the cloud. The storage layer of TiDB, called TiKV, became a Cloud Native Computing Foundation (CNCF) member project in August 2018, as a Sandbox level project, and became an incubation-level hosted project in May 2019. TiKV graduated from CNCF in September 2020. === Real-time HTAP === TiDB can support both online transaction processing (OLTP) and online analytical processing (OLAP) workloads. TiDB has two storage engines: TiKV, a rowstore, and TiFlash, a columnstore. === High availability === TiDB uses the Raft consensus algorithm to ensure that data is available and replicated throughout storage in Raft groups. In the event of failure, a Raft group will automatically elect a new leader for the failed member, and self-heal the TiDB cluster. === Vector Search === TiDB has a vector data type and vector indexes. This allows TiDB to be used as Vector database in AI Retrieval-augmented generation applications. == Deployment methods == === Kubernetes with Operator === TiDB can be deployed in a Kubernetes-enabled cloud environment by using TiDB Operator. An Operator is a method of packaging, deploying, and managing a Kubernetes application. It is designed for running stateful workloads and was first introduced by CoreOS in 2016. TiDB Operator was originally developed by PingCAP and open-sourced in August, 2018. TiDB Operator can be used to deploy TiDB on a laptop, Google Cloud Platform’s Google Kubernetes Engine, and Amazon Web Services’ Elastic Container Service for Kubernetes. === TiUP === TiDB 4.0 introduces TiUP, a cluster operation and maintenance tool. It helps users quickly install and configure a TiDB cluster with a few commands. == Tools == TiDB has a series of open-source tools built around it to help with data replication and migration for existing MySQL and MariaDB users. === TiDB Data Migration (DM) === TiDB Data Migration (DM) is suited for replicating data from already sharded MySQL or MariaDB tables to TiDB. A common use case of DM is to connect MySQL or MariaDB tables to TiDB, treating TiDB almost as a slave, then directly run analytical workloads on this TiDB cluster in near real-time. === Backup & Restore === Backup & Restore (BR) is a distributed backup and restore tool for TiDB cluster data. === Dumpling === Dumpling is a data export tool that exports data stored in TiDB or MySQL. It lets users make logical full backups or full dumps from TiDB or MySQL. === TiDB Lightning === TiDB Lightning is a tool that supports high speed full-import of a large MySQL dump into a new TiDB cluster. This tool is used to populate an initially empty TiDB cluster with much data, in order to speed up testing or production migration. The import speed improvement is achieved by parsing SQL statements into key-value pairs, then directly generate Sorted String Table (SST) files to RocksDB. === TiCDC === TiCDC is a change data capture tool which streams data from TiDB to other systems like Apache Kafka.
Hedgeable
Hedgeable, Inc. was a U.S. based financial services company and digital wealth management platform headquartered in New York City. Hedgeable was known for not following set allocations, and instead actively managing accounts in response to market movements. On August 9, 2018, Hedgeable closed its doors to new investors, with existing investors required to transfer out of the company. The company claimed that it was not shutting down but simply removing its SEC registration. == History == Hedgeable was founded in 2009 by twin brothers Michael and Matthew Kane, who previously worked at high-net worth investment managers such as Bridgewater Associates and Spruce Private Investors. Both Michael and Matthew graduated from Penn State University with degrees in finance. Hedgeable is a Registered Investment Advisor with the U.S. Securities and Exchange Commission. The company has received funding from SixThirty and Route 66 Ventures as well as various other angel investors. On August 9, 2018, Hedgeable closed its doors to new investors. == Investing Strategies == Hedgeable did not follow a buy-and-hold approach, but instead actively manages accounts in response to market movements focusing on downside protection in bear markets. Their strategy was different from other robo-advisors, which use Modern Portfolio Theory. Hedgeable offered investment options including Exchange Traded Funds (ETFs) to individual stocks, master limited partnerships, private equity and bitcoin. Mutual funds were not used in portfolios. Although the firm's focus was to provide a direct-to-consumer service, Hedgeable's investment strategies were available to financial advisors and institutions as well through a variety of platforms. == Product Features == When it was open to external clients, Hedgeable aimed to gamify their personal finance experience. Clients could open a new account or transfer an existing account. Hedgeable accepted retirement accounts, taxable accounts, business accounts and various other account types. Hedgeable offered the following features: Downside protection Account aggregation Alternative investments Alpha rewards API Mobile app It was awarded 4/5 for client transparency by Paladin Research. Hedgeable was the winner of the Finovate Fall 2015 Best of Show Award and the GREAT 2015 Tech Award (FinTech Category). In 2016, Hedgeable launched its first iOS mobile app in order to expand their product offerings.
SeaTable
SeaTable is a no-code platform that allows users to develop and implement business processes. The cloud collaboration service SeaTable is marketed by the GmbH of the same name with headquarters in Mainz and additional offices in Berlin and Beijing, and developed by the same company as Seafile. == History == SeaTable is a collaborative database and low-code application platform developed as part of a joint venture between Seafile Ltd., a software company based in Guangzhou, China, and SeaTable GmbH, a German firm headquartered in Mainz. Founded in 2020, the project represents the international expansion of Seafile, a Chinese developer originally known for its file synchronization and sharing software. While SeaTable's cloud services and European client operations are managed by the German entity, the platform itself is developed in China by Seafile's engineering team. This cross-border structure, described by TechCrunch as an “unconventional path” for a Chinese startup expanding abroad, reflects Seafile's effort to maintain its product development in China while addressing growing scrutiny in Western markets over data governance and corporate control. In 2021, an innovation project led by the Cyber Innovation Hub at the IT School of the German Armed Forces started to evaluate the possibilities of a large-scale deployment at the German Armed Forces. The evaluation project is currently still ongoing. In 2022, SeaTable is optimizing its database backend to allow millions of records within one base in the future. The focus of development is increasingly on automation and visualization. In 2025, SeaTable introduced AI-powered automations with version 6. The update enabled the integration of large language models (LLMs) for text analysis and automated decision-making. SeaTable operates a self-hosted LLM on servers provided by Hetzner (Germany), while self-hosted deployments can connect to any compatible model. == Features == SeaTable combines the traditional capabilities of a spreadsheet such as Excel and supplements them with a wide range of functions for process automation and visualization as well as a fully comprehensive API. SeaTable is not a pure cloud solution, but can alternatively be installed on a private server and operated completely autonomously. In this way, the owner retains full control over their own data. The installation is done via Docker on a Linux server. == Security and privacy == While most no-code platforms exist only as SaaS solutions, SeaTable describes itself as a data-sparse European solution. While initially the SeaTable Cloud was hosted on Amazon AWS, the move to the German data centers of Swiss provider Exoscale then took place in May 2021. This was followed by the replacement of the Freshdesk cloud ticketing system with a self-hosted Zammad instance, and since April 2022 SeaTable has completely dispensed with all tracking cookies on its website.
Secure element
A secure element (SE) is a secure operating system (OS) in a tamper-resistant processor chip or secure component. It can protect assets (root of trust, sensitive data, keys, certificates, applications) against high-level software and hardware attacks. Applications that process this sensitive data on an SE are isolated and so operate within a controlled environment not affected by software (including possible malware) found elsewhere on the OS. The hardware and embedded software meet the requirements of the Security IC Platform Protection Profile [PP 0084] including resistance to physical tampering scenarios described within it. More than 96 billion secure elements were produced and shipped between 2010 and 2021. SEs exist in various form factors, as devices such as smart cards, UICCs, or smart microSD cards, or embedded, or integrated, as parts of larger devices. SEs are an evolution of the chips in earlier smart cards, which have been adapted to suit the needs of numerous use cases, such as smartphones, tablets, set-top boxes, wearables, connected cars, and other internet of things (IoT) devices. The technology is widely used by technology firms such as Oracle, Apple and Samsung. SEs provide secure isolation, storage and processing for applications (called applets) they host while being isolated from the external world (e.g. rich OS and application processor when embedded in a smartphone) and from other applications running on the SE. Java Card and MULTOS are the most deployed standardized multi-application operating systems currently used to develop applications running on SEs. Since 1999, GlobalPlatform has been the body responsible for standardizing secure element technologies to support a dynamic model of application management in a multi-actor model. GlobalPlatform also runs Functional and Security Certification programmes for secure elements, and hosts a list of Functional Certified and Security Certified products. GlobalPlatform technology is also embedded in other standards such as ETSI SCP (now SET) since release 7. A Common Criteria Secure Element Protection Profile has been released targeting EAL4+ level with ALC_DVS.2 and AVA_VAN.5 extension to standardize the security features of a secure element across markets.