CN107220315B - User data protection method for database degradation during APP version updating - Google Patents
User data protection method for database degradation during APP version updating Download PDFInfo
- Publication number
- CN107220315B CN107220315B CN201710343960.1A CN201710343960A CN107220315B CN 107220315 B CN107220315 B CN 107220315B CN 201710343960 A CN201710343960 A CN 201710343960A CN 107220315 B CN107220315 B CN 107220315B
- Authority
- CN
- China
- Prior art keywords
- database
- version
- data
- user data
- degradation
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/23—Updating
- G06F16/2365—Ensuring data consistency and integrity
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/23—Updating
- G06F16/2308—Concurrency control
- G06F16/2315—Optimistic concurrency control
- G06F16/2329—Optimistic concurrency control using versioning
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/25—Integrating or interfacing systems involving database management systems
- G06F16/252—Integrating or interfacing systems involving database management systems between a Database Management System and a front-end application
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/60—Software deployment
- G06F8/65—Updates
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Databases & Information Systems (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Data Mining & Analysis (AREA)
- Computer Security & Cryptography (AREA)
- Software Systems (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
The invention relates to a user data protection method for database degradation during APP version updating, which comprises the following steps: step 1, acquiring a currently installed database name and a database version number; step 2, acquiring a database name and a database version number to be installed; step 3, judging whether the currently installed database name is the same as the database name to be installed; if the two are the same, turning to the step 4; step 4, judging whether the currently installed database version number is different from the database version number to be installed; or the database is not updated, or upgraded or downgraded; tables of the database, wherein the naming rule of the tables is as follows: prefix table name suffix, where suffix is equal to database version number. The invention has simple application, can effectively protect the user data and avoid the problem of user data loss caused by database degradation.
Description
Technical Field
The invention relates to the technical field of user data protection, in particular to a user data protection method for database degradation during APP version updating.
Background
In the Android system, a lightweight database SQLite is built in, even the SQLite does not need to install and start a service process, and the SQLite is a database file with a suffix of db, but supports SQL statements.
The use of the SQLite requires an SQLiteDataBase class, the bottom layer of the class is a database file, one class represents a database, and the operation on the database also passes through the SQLiteDataBase class. The SQLiteDatabase class encapsulates APIs of some operation databases, with which add (Create), query (Retrieve), Update (Update) and Delete (Delete) operations on data can be completed.
The SQLiteOpenhelper class is an abstract class used to assist in managing database creation and version upgrade issues. We can inherit this abstract class, implementing some of its methods to perform custom operations on the database. The following two methods must be rewritten:
public void onCreate（SQLiteDatabase db）
public void onUpgrade（SQLiteDatabase db, int oldVersion, intnewVersion）
onCreate: the calling time is started after the user installs the application for the first time or started after the App database file is cleared. The creation of the initial data table can then be done in this function.
onUpgrade: and the calling time is that the user starts after updating the application and installing the coverage, and the database version number in the new version is higher than the database version number in the old version, so that the user can call the database version number. The compatibility problem of the old version brought by the upgrade of the database version and the data migration problem can be completed in the function.
The reference to the database may be obtained using the getWritableDatabase () and getTadableDatabase () methods in the SQLiteOpenhelper class.
There is also a method onDowngrade that does not need to be rewritten, but must be rewritten when an application is reverse downgraded (e.g., a packet with version number 3 is installed with version number 4 downgrade), which may crash if the application downgrades to override the installation without rewriting.
In addition, the SQLiteOpenhelper subclass must specify the name (name), version number (version) of the current database when constructing an instance. The name here determines the file name of the database when the database is stored, and the version number here has no absolute relation with the version code defined by App in android main. That is, the version number of the database is not increased if the data structure of the database is not changed during the App update.
When the database is upgraded, the database can clearly know what operation we need to do on the old tables to be compatible with the new version. But the situation is not the same if the database is degraded. For example:
when developing version 2 (which is a new version relative to version 1), we cannot know explicitly what the database structure of the later new versions (e.g., version 3, version 4) will go. At this time, when the user falls back from version 3 to version 2, since version 2 cannot predict the table structure of version 3 at the time of development, it is not known whether the data table of version 3 is compatible with version 2 (if a table field that version 2 is always using is deleted at the time of version 3 upgrade, the fall-back data structure may not be compatible).
Thus, the degraded operation is likely to result in the loss of user data, which may result in irreparable loss to the user, and this problem obviously needs to be solved to avoid affecting the user's experience and the security of the user data.
Another possible scenario is: sometimes, an APP automatically performs an upgrade operation, but a user may feel that an old version is good, so that the user also wants to replace the old version but wants to keep the data, and the user does not want to lose the data due to replacing the old version.
Disclosure of Invention
Aiming at the defects in the prior art, the invention aims to provide a user data protection method for database degradation during APP version updating, which is simple to apply, can effectively protect user data and avoids the problem of user data loss caused by database degradation.
In order to achieve the above purposes, the technical scheme adopted by the invention is as follows:
a user data protection method for database degradation during APP version update is characterized by comprising the following steps:
step 1, acquiring a currently installed database name and a database version number;
step 2, acquiring a database name and a database version number to be installed;
step 3, judging whether the currently installed database name is the same as the database name to be installed;
if the two are the same, turning to the step 4;
and if not, then: recording the data obtained in the step 1 and the step 2, and performing corresponding processing;
step 4, judging whether the currently installed database version number is different from the database version number to be installed;
if the data is the same, the database is directly used, and the updating operation is not carried out on the database;
and (3) upgrading the database, namely: turning to step 5;
the database is degraded, then: turning to step 6;
step 5, upgrading the database, and performing data migration in the following way:
step 5.1, a table corresponding to the database of the new version is created in the database, and the naming rule of the table is as follows: prefix table name suffix, where suffix is equal to database version number,
step 5.2, migrating the user data in the table corresponding to the database of the old version to the table corresponding to the database of the new version in a copying mode;
and 6, degrading the database, and performing data migration in the following way:
step 6.1, obtaining the number of tables and the names of the tables corresponding to the database of the old version;
step 6.2, judging whether the tables exist in the database one by one according to the naming of the tables, and creating the tables which do not exist, wherein the naming rule of the tables is as follows: prefix table name suffix, where suffix is equal to database version number.
On the basis of the technical scheme, the APP quickly judges which version of database the table corresponds to according to the suffix.
On the basis of the technical scheme, when each data is stored in the table, the creation time of the data is recorded;
when each data is updated in the table, recording the updating time of the data;
the date and time of the database upgrade is stored in the database,
the date and time of the database degradation is stored in the database.
On the basis of the technical scheme, by combining the date and time of upgrading, judging which data are the new data after upgrading and which data are the old data before upgrading;
and judging which data are new data after degradation and which data are old data before degradation by combining the date and time of degradation.
On the basis of the technical scheme, when user data is acquired:
the method comprises the steps of firstly, according to a currently installed database version number, combining the database version number as a suffix and a table name according to the naming rule of the table to obtain a current version table, and directly obtaining user data from the current version table;
judging whether a table with the same table name and a suffix larger than the currently installed database version number exists or not,
if yes, the table is an updated version table, and at the moment:
further acquiring the list item names in the current version list, inquiring in the updated version list one by one,
if there is a corresponding entry, the user data recorded in the entry is read,
if no corresponding table item exists, returning a default value as user data;
if not, the user data acquisition is finished.
On the basis of the technical scheme, the upgrading date and time or the degrading date and time are compared with the current time to assist in judging whether an updated version table is possible to exist or not.
On the basis of the technical scheme, the exception is captured through try/catch () and corresponding processing is carried out.
The user data protection method for the database degradation during the APP version updating is simple to apply, can effectively protect the user data, and avoids the problem of user data loss caused by the database degradation.
Detailed Description
The invention relates to a user data protection method for database degradation during APP version updating, which comprises the following steps:
step 1, acquiring a currently installed database name and a database version number;
for example: the database name and the database version number of a certain APP installed in the mobile phone are as follows:
DATABASE_NAME = "Xx_crm.db"；
DATABASE_VERSION = 3；
step 2, acquiring a database name and a database version number to be installed;
for example: if the certain APP needs to be reinstalled in the example of step 1, the installation package of the certain APP may have the following situations, and certainly, other situations may exist, which do not belong to the discussion scope of the present invention;
case 1:
DATABASE_NAME = "Xx_crm.db"；
DATABASE_VERSION = 4；
obviously this is the case for database upgrades;
case 2:
DATABASE_NAME = "Xx_crm.db"；
DATABASE_VERSION = 2；
this is obviously the case for database downgrades;
step 3, judging whether the currently installed database name is the same as the database name to be installed;
if the two are the same, turning to the step 4;
and if not, then: recording the data obtained in the step 1 and the step 2, and performing corresponding processing;
the corresponding processing can be set according to actual needs and does not belong to the discussion scope of the invention; for example: the method can simply give an error-reporting prompt, and also can terminate the installation process of the installation package of the certain APP, or perform corresponding fault-tolerant processing, and the like;
step 4, judging whether the currently installed database version number is different from the database version number to be installed;
if the data is the same, the database is directly used, and the updating operation is not carried out on the database;
and (3) upgrading the database, namely: turning to step 5;
the database is degraded, then: turning to step 6;
step 5, upgrading the database, and performing data migration in the following way:
step 5.1, a table corresponding to the database of the new version is created in the database, and the naming rule of the table is as follows: prefix table name suffix, where suffix is equal to database version number,
step 5.2, migrating the user data in the table corresponding to the database of the old version to the table corresponding to the database of the new version in a copying mode;
in this way:
when the database is upgraded, obviously, the table corresponding to the database of the new version does not exist, and needs to be created,
firstly, the table corresponding to the database of the old version can be completely reserved without any change, and the suffix can be used for distinguishing the table, so that the existing user data in the table corresponding to the database of the old version is effectively reserved;
secondly, data is migrated in a copying mode, the table corresponding to the database of the new version perfectly contains original data, and subsequent addition, deletion, modification and check are directly performed in the table corresponding to the database of the new version, so that on one hand, user data in the table corresponding to the database of the old version cannot be influenced, and on the other hand, adverse influence on addition, deletion, modification and check of the data cannot be caused;
thirdly, although the data is migrated in a copying manner, the format of the user data with the old specification is actually upgraded to meet the format requirement of the user data with the new specification;
for example: a table corresponding to the old version of the database, named "T _ table _ 2", which corresponds to the database with database version number 2;
for example: a table corresponding to the new version of the database, named "T _ table _ 3", which corresponds to the database with database version number 3;
in the "T _ table _ 2" and "T _ table _ 3", the fields of the tables are the same or different, but are used for storing some kind of data, for example: all are used for storing the names, the sexes, the grades and the school numbers of the students;
obviously, from the suffix, the APP can also know which version of APP the table is suitable for;
and 6, degrading the database, and performing data migration in the following way:
step 6.1, obtaining the number of tables and the names of the tables corresponding to the database of the old version;
step 6.2, judging whether the tables exist in the database one by one according to the naming of the tables, and creating the tables which do not exist, wherein the naming rule of the tables is as follows: prefix table name suffix, wherein suffix equals database version number;
in this way:
firstly, when the database is degraded, a table corresponding to the database of the old version may exist or be deleted by a user, and whether the table is created or not needs to be determined according to the situation;
second, in a destage operation, user data in a table corresponding to a new version of the database is not written to a table corresponding to an old version of the database,
first, if the updated database, the fields of the table, or the table have been changed, the writing of the user data into the table corresponding to the old version of the database may cause data loss or confusion, since it is still retained in the table corresponding to the new version of the database, and thus it may be left unprocessed;
secondly, once writing is carried out, the user data in the table corresponding to the database of the old version can be generated disadvantageously, the old data is maintained in the table corresponding to the database of the old version, the new data is maintained in the table corresponding to the database of the new version, and the sorting and maintenance of the data are facilitated.
The major consideration of the downgrade operation is that the non-existing table should be created again to avoid incomplete database versions affecting the operation of the APP, and to avoid the mix of user data of the old and new specifications.
In the naming rule of the table, the suffix is equal to the database version number, and the database corresponding to the table can be quickly judged according to the suffix, so that the maintenance and processing of data are facilitated, and the processing efficiency can be effectively improved.
On the basis of the technical scheme, when each data is stored in the table, the creation time of the data is recorded;
when each data is updated in the table, recording the updating time of the data;
the date and time of the database upgrade is stored in the database,
the date and time of the database degradation is stored in the database.
The benefits of this scheme are:
by combining the date and time of upgrading, the data can be judged to be new data after upgrading and old data before upgrading;
and by combining the date and time of the degradation, the data can be judged to be new data after the degradation and old data before the degradation.
For example:
if the data is recorded for the first time, the creation time is equal to the updating time and is equal to the first recording time;
if the modified data exist, the creation time is unchanged, and the updating time is equal to the modification time;
by judging the time node, new and old data can be distinguished quickly, and further, the table from which the data is added or deleted is judged to be appropriate.
On the basis of the technical scheme, when user data is acquired:
the method comprises the steps of firstly, according to a currently installed database version number, combining the database version number as a suffix and a table name according to the naming rule of the table to obtain a current version table, and directly obtaining user data from the current version table;
judging whether a table with the same table name and a suffix larger than the currently installed database version number exists or not,
if yes, the table is an updated version table, and at the moment:
further acquiring the list item names in the current version list, inquiring in the updated version list one by one,
if there is a corresponding entry, the user data recorded in the entry is read,
if no corresponding table item exists, returning a default value as user data;
if not, the user data acquisition is finished.
Furthermore, the date and time of upgrading or the date and time of degrading are compared with the current time to assist in judging whether an updated version table is possible to exist.
On the basis of the technical scheme, the exception is captured through try/catch () and corresponding processing is carried out.
Those not described in detail in this specification are within the skill of the art.
Claims (7)
1. A user data protection method for database degradation during APP version update is characterized by comprising the following steps:
step 1, acquiring a currently installed database name and a database version number;
step 2, acquiring a database name and a database version number to be installed;
step 3, judging whether the currently installed database name is the same as the database name to be installed;
if the two are the same, turning to the step 4;
and if not, then: recording the data obtained in the step 1 and the step 2, and performing corresponding processing;
step 4, judging whether the currently installed database version number is different from the database version number to be installed;
if the data is the same, the database is directly used, and the updating operation is not carried out on the database;
and (3) upgrading the database, namely: turning to step 5;
the database is degraded, then: turning to step 6;
step 5, upgrading the database, and performing data migration in the following way:
step 5.1, a table corresponding to the database of the new version is created in the database, and the naming rule of the table is as follows: prefix table name suffix, where suffix is equal to database version number,
step 5.2, migrating the user data in the table corresponding to the database of the old version to the table corresponding to the database of the new version in a copying mode;
the table corresponding to the database of the old version is completely reserved without any change, and the existing user data in the table is effectively reserved;
the table corresponding to the database of the new version contains original data, and subsequent addition, deletion, modification and check can be directly carried out in the table corresponding to the database of the new version without influencing user data in the table corresponding to the database of the old version;
and 6, degrading the database, and performing data migration in the following way:
step 6.1, obtaining the number of tables and the names of the tables corresponding to the database of the old version;
step 6.2, judging whether the tables exist in the database one by one according to the naming of the tables, and creating the tables which do not exist, wherein the naming rule of the tables is as follows: prefix table name suffix, wherein suffix equals database version number;
re-creating the non-existing table to avoid the incomplete database of the old version from influencing the operation of the APP,
and when the operation is degraded, the user data in the table corresponding to the database of the new version is not written into the table corresponding to the database of the old version.
2. The method for user data protection of database degradation upon update of APP version as claimed in claim 1 wherein: and the APP quickly judges which version of database the table corresponds to according to the suffix.
3. The method for user data protection of database degradation upon update of APP version as claimed in claim 1 wherein: when each data is stored in the table, recording the creation time of the data;
when each data is updated in the table, recording the updating time of the data;
the date and time of the database upgrade is stored in the database,
the date and time of the database degradation is stored in the database.
4. The method of claim 3 for user data protection of database degradation upon update of APP versions, characterized by: judging which data are the new data after upgrading and which data are the old data before upgrading by combining the date and time of upgrading;
and judging which data are new data after degradation and which data are old data before degradation by combining the date and time of degradation.
5. The method of claim 3 for user data protection of database degradation upon update of APP versions, characterized by: when user data is acquired:
the method comprises the steps of firstly, according to a currently installed database version number, combining the database version number as a suffix and a table name according to the naming rule of the table to obtain a current version table, and directly obtaining user data from the current version table;
judging whether a table with the same table name and a suffix larger than the currently installed database version number exists or not,
if yes, the table is an updated version table, and at the moment:
further acquiring the list item names in the current version list, inquiring in the updated version list one by one,
if there is a corresponding entry, the user data recorded in the entry is read,
if no corresponding table item exists, returning a default value as user data;
if not, the user data acquisition is finished.
6. The method for user data protection of database degradation upon update of APP version as claimed in claim 5 wherein: and comparing the current time by using the upgrading date and time or the degrading date and time, and judging whether an updated version table is possible to exist in an auxiliary manner.
7. The method for user data protection of database degradation upon update of APP version as claimed in claim 1 or 2 or 3 or 4 or 5 or 6, characterized by: the exception is captured by try/catch () and the corresponding process is reversed.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201710343960.1A CN107220315B (en) | 2017-05-16 | 2017-05-16 | User data protection method for database degradation during APP version updating |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201710343960.1A CN107220315B (en) | 2017-05-16 | 2017-05-16 | User data protection method for database degradation during APP version updating |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN107220315A CN107220315A (en) | 2017-09-29 |
| CN107220315B true CN107220315B (en) | 2020-08-25 |
Family
ID=59944015
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201710343960.1A Active CN107220315B (en) | 2017-05-16 | 2017-05-16 | User data protection method for database degradation during APP version updating |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN107220315B (en) |
Families Citing this family (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN107729180B (en) * | 2017-09-30 | 2020-07-03 | 珠海市魅族科技有限公司 | Abnormal information processing method and device, computer device and readable storage medium |
| CN108549672A (en) * | 2018-03-29 | 2018-09-18 | 中航技国际经贸发展有限公司 | A kind of intelligent data analysis method and system |
| CN110059096A (en) * | 2019-03-16 | 2019-07-26 | 平安城市建设科技(深圳)有限公司 | Data version management method, apparatus, equipment and storage medium |
| CN112016284B (en) * | 2020-08-27 | 2023-08-01 | 北京字节跳动网络技术有限公司 | Electronic form processing method and equipment |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN103324716A (en) * | 2013-06-25 | 2013-09-25 | 四川九洲电器集团有限责任公司 | Application database updating method based on Android system |
| CN103678532A (en) * | 2013-12-02 | 2014-03-26 | 中国移动（深圳）有限公司 | Alternation statement reverse analysis method, database alternating and backspacing method and database alternating and backspacing system |
| CN105630898A (en) * | 2015-12-18 | 2016-06-01 | 国云科技股份有限公司 | A Method Applicable to Application Database Table Data Version Switching |
| CN105740443A (en) * | 2016-02-01 | 2016-07-06 | 深圳市盛弘电气股份有限公司 | Android database-based data management method and device |
| US9501368B2 (en) * | 2008-09-30 | 2016-11-22 | Veritas Technologies Llc | Backing up and restoring selected versioned objects from a monolithic database backup |
-
2017
- 2017-05-16 CN CN201710343960.1A patent/CN107220315B/en active Active
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US9501368B2 (en) * | 2008-09-30 | 2016-11-22 | Veritas Technologies Llc | Backing up and restoring selected versioned objects from a monolithic database backup |
| CN103324716A (en) * | 2013-06-25 | 2013-09-25 | 四川九洲电器集团有限责任公司 | Application database updating method based on Android system |
| CN103678532A (en) * | 2013-12-02 | 2014-03-26 | 中国移动（深圳）有限公司 | Alternation statement reverse analysis method, database alternating and backspacing method and database alternating and backspacing system |
| CN105630898A (en) * | 2015-12-18 | 2016-06-01 | 国云科技股份有限公司 | A Method Applicable to Application Database Table Data Version Switching |
| CN105740443A (en) * | 2016-02-01 | 2016-07-06 | 深圳市盛弘电气股份有限公司 | Android database-based data management method and device |
Also Published As
| Publication number | Publication date |
|---|---|
| CN107220315A (en) | 2017-09-29 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN107220315B (en) | User data protection method for database degradation during APP version updating | |
| US7703090B2 (en) | Patch un-installation | |
| US10430209B1 (en) | System and method for server customization | |
| CN105373396B (en) | Update of plug-in loading method and device in plug-platform | |
| US7310801B2 (en) | Servicing a component-based software product throughout the software product lifecycle | |
| US8677341B2 (en) | Software-delivered dynamic persistent data | |
| KR101619557B1 (en) | Computer application packages with customizations | |
| CN101416175B (en) | Creating templates of offline resources | |
| CN101931944B (en) | Method, device and system for updating terminal patches on line | |
| US20070143379A1 (en) | Metadata driven deployment of applications | |
| US20070169101A1 (en) | Multi-Branch Management for Updating Software | |
| WO2017113611A1 (en) | Method and system for optimizing operation system | |
| CN104007992A (en) | Methods and devices for program updating and starting | |
| CN107643898A (en) | Terminal staging method and device | |
| CN107368513B (en) | Method and device for updating client database | |
| WO2018177193A1 (en) | Software upgrade method and device | |
| CN111858018A (en) | Method, apparatus, computer equipment and storage medium for Cgroup configuration | |
| CN103309696A (en) | Method and device for updating Java card extended library, and Java card | |
| CN110968569B (en) | Database management method, database management device, and storage medium | |
| CN1315043C (en) | Compatibility upgrading method of embedded programm | |
| CN106815004A (en) | A kind of method of compatibility difference Cocos2d-x versions | |
| JP2005316715A (en) | Document management system, method and program | |
| CN101714089A (en) | Method for installing external member and method for making external member mapping file | |
| CA2493846C (en) | Network delivered dynamic persistent data | |
| JP2002189601A (en) | Program installation method and program installation system |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |