DETAILED ACTION
Responsive to the Applicant reply filed on 08/04/2025, Applicant' s amendments to claims have been entered and respective arguments carefully considered and responded in following:
On this Office Action, claims 1-11 and 13-22, consisting of independent claims 1 and 16.
Claims 1-11 and 13-22 are pending.
Claims 1-11 and 13-22 are rejected under the 35 USC § 112.
Claims 1-11 and 13-15 are rejected under the 35 USC § 103.
Claims 16-22 would be allowable if rewritten to overcome the rejection(s) under 35 U.S.C. 112 set forth in this Office action.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Amendment
The amendment filed 08/04/2025 has been entered.
Claims 1 and 16 have been amended, claim 16 was previously dependent claim, but it is now an independent claim.
Claims 12 has been canceled.
Response to Arguments
With respect to Specification Objection:
Applicant’s reply does not include an amendment or argument responsive to the objection regarding the title of the invention. Accordingly, the objection is maintained.
With respect to Claim Rejections - 35 USC § 112:
Applicant’s reply does not include an amendment or argument responsive to the rejection under 35 USC § 112 (b). Accordingly, the rejection is maintained.
With respect to Claim Rejections - 35 USC § 103:
With respect to independent claim 1, Applicants arguments filed on 08/04/2025 (see amended independent claim 1 and Applicant’s Remarks) regarding the incorporation a limitation from the previously objected claim 12 have been fully considered but are not persuasive. Contrary to Applicant’s Remarks stating that objected claim 12 was incorporated into independent claim 1, instead, the limitation of claim 13 was actually incorporated into claim 1. Therefore, the argument is unpersuasive.
With respect to independent claim 16, Applicants arguments filed on 08/04/2025 (see amended independent claim 16, which was previously dependent claim, and Applicant’s Remarks) have been fully considered and are persuasive. Therefore, the previous rejection has been withdrawn.
Specification
The title of the invention, “Method of migrating an IT applicatkion,” is not sufficiently descriptive. A new title is required that is clearly reflects the subject matter of the claims.
Additionally, the title is objected to due to the following informalities: “Method of migrating an IT applicatkion.”
The title recite “an IT applicatkion.” The abbreviation needs to be spelled out (e.g., Information Technology).
Claim Objections
Claims 1-3 and 14-15 are objected to because of the following informalities:
Claims 1 and 16 state “information-technology” to spell out the abbreviation (e.g., Information Technology), however, they do not define the abbreviation “IT.”
Claim 3 recites “about all nodes authorization blocks with all relevant authorizations authorizations.”
Appropriate correction is required.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(d):
(d) REFERENCE IN DEPENDENT FORMS.—Subject to subsection (e), a claim in dependent form shall contain a reference to a claim previously set forth and then specify a further limitation of the subject matter claimed. A claim in dependent form shall be construed to incorporate by reference all the limitations of the claim to which it refers.
Claim 13 is rejected under 35 U.S.C. 112(d), as being of improper dependent form for failing to further limit the subject matter of the claim upon which it depends, or for failing to include all the limitations of the claim upon which it depends.
Applicant may cancel the claim(s), amend the claim(s) to place the claim(s) in proper dependent form, rewrite the claim(s) in independent form, or present a sufficient showing that the dependent claim(s) complies with the statutory requirements.
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
Claims 1-11 and 13-22 are rejected under 35 U.S.C. 112(b), as failing to set forth the subject matter which the inventor or a joint inventor, the applicant regards as the invention. Evidence that claims 1-11 and 13-22 fail to correspond in scope with that which the inventor or a joint inventor regards as the invention can be found in the reply because the claims are generally narrative and indefinite, failing to conform with current U.S. practice. They appear to be a literal translation into English from a foreign document and are replete with grammatical and idiomatic errors.
Additionally, claims 1-11 and 13-22 are rejected under 35 U.S.C. 112(b) because of insufficient antecedent basis issues provided below.
Claim 1 recites the limitation "the respective node." There is insufficient antecedent basis for this limitation in the claim.
Claim 1 recites the limitation "the entire processing of the IT application." There is insufficient antecedent basis for this limitation in the claim.
Claim 1 recites the limitation "the nodes including all relevant data." There is insufficient antecedent basis for this limitation in the claim.
Claim 1 recites the limitation "the nodes exchange the required data." There is insufficient antecedent basis for this limitation in the claim.
Claim 1 recites the limitation "the operating system." There is insufficient antecedent basis for this limitation in the claim.
Claim 1 recites the limitation "the IT application." There is insufficient antecedent basis for this limitation in the claim because claim 1 defines “an information-technology application of a central system” and “an IT application with blockchain technology or Distributed Ledger Technology.”
Claim 1 recites the limitation "the authorizations and thus the relevant read protection." There is insufficient antecedent basis for this limitation in the claim.
Claim 1 recites the limitation "the data or parts." There is insufficient antecedent basis for this limitation in the claim.
Claim 1 recites the limitation " the central authorization systems." There is insufficient antecedent basis for this limitation in the claim.
Claim 1 recites the limitation " the central systems." There is insufficient antecedent basis for this limitation in the claim.
Claim 2 recites the limitation "created from the data of the authorization systems." There is insufficient antecedent basis for this limitation in the claim.
Claim 2 recites the limitation "the central authorization systems." There is insufficient antecedent basis for this limitation in the claim.
Claim 3 recites the limitation "the form of node blocks." There is insufficient antecedent basis for this limitation in the claim.
Claim 3 recites the limitation "the key management and/or the data encryption/data decryption and/or the data conversion and/or the root key calculation." There is insufficient antecedent basis for this limitation in the claim.
Claim 4 recites the limitation "secure traceability of the processing." There is insufficient antecedent basis for this limitation in the claim.
Claim 5 recites the limitation "the concatenation of the data blocks." There is insufficient antecedent basis for this limitation in the claim.
Claim 6 recites the limitation "the cryptographic encryption and decryption and calculation of electronic signatures." There is insufficient antecedent basis for this limitation in the claim.
Claim 7 recites the limitation "in the encryption of data for database systems." There is insufficient antecedent basis for this limitation in the claim.
Claim 7 recites the limitation "the database in encrypted form." There is insufficient antecedent basis for this limitation in the claim.
Claim 7 recites the limitation "the authorizations of users and/or roles and/or other subjects." There is insufficient antecedent basis for this limitation in the claim.
Claim 8 recites the limitation "have the same encryption or decryption key." There is insufficient antecedent basis for this limitation in the claim.
Claim 8 recites the limitation "after the encryption or decryption, are converted back into the original data types." There is insufficient antecedent basis for this limitation in the claim.
Claim 9 recites the limitation "the data type and length." There is insufficient antecedent basis for this limitation in the claim.
Claim 10 recites the limitation "all older calculations of the read key are calculated from the current cryptographic read key." There is insufficient antecedent basis for this limitation in the claim.
Claim 11 recites the limitation " on the upper level with validity in the entire system." There is insufficient antecedent basis for this limitation in the claim.
Claim 11 recites the limitation "the lowest and/or middle level." There is insufficient antecedent basis for this limitation in the claim.
Claim 11 recites the limitation "files only the hash values." There is insufficient antecedent basis for this limitation in the claim.
Claim 13 recites the limitation " the central authorization systems." There is insufficient antecedent basis for this limitation in the claim.
Claim 13 recites the limitation " the central systems." There is insufficient antecedent basis for this limitation in the claim.
Claim 14 recites the limitation "the security requirements." There is insufficient antecedent basis for this limitation in the claim.
Claim 14 recites the limitation "reports deviations to the other nodes." There is insufficient antecedent basis for this limitation in the claim.
Claim 15 recites the limitation "storage of the cryptographic keys and/or the encryption and decryption of the data blocks in the nodes take place either unprotected in the node or in a hardware-protected sandbox in the node or in external hardware tokens, depending on the security level." There is insufficient antecedent basis for this limitation in the claim.
Claim 15 recites the limitation "storage of the cryptographic keys and/or the encryption and decryption of the data blocks in the nodes take place either unprotected in the node or in a hardware-protected sandbox in the node or in external hardware tokens, depending on the security level, and, if required, the IT security system checks the security level in the node and reports any deviations to the other nodes." There is insufficient antecedent basis for this limitation in the claim.
Claim 16 recites the limitation "the respective node." There is insufficient antecedent basis for this limitation in the claim.
Claim 16 recites the limitation "the entire processing of the IT application." There is insufficient antecedent basis for this limitation in the claim.
Claim 16 recites the limitation "the nodes including all relevant data." There is insufficient antecedent basis for this limitation in the claim.
Claim 16 recites the limitation "the nodes exchange the required data." There is insufficient antecedent basis for this limitation in the claim.
Claim 16 recites the limitation "the operating system." There is insufficient antecedent basis for this limitation in the claim.
Claim 16 recites the limitation "the IT application." There is insufficient antecedent basis for this limitation in the claim because claim 1 defines “an information-technology application of a central system” and “an IT application with blockchain technology or Distributed Ledger Technology.”
Claim 16 recites the limitation "the authorizations and thus the relevant read protection." There is insufficient antecedent basis for this limitation in the claim.
Claim 16 recites the limitation "the data or parts." There is insufficient antecedent basis for this limitation in the claim.
Claim 16 recites the limitation "a commutative asymmetric encryption method is used for the calculation of a root key and the start value “x” is first encrypted in a main node using this encryption method and its own root key part as the key, then the result is sent step by step to all the other main nodes, and there the respective current result is further encrypted in the individual main nodes using the respective root key part until encryption has taken place in all the main nodes using its own root key part, as a result of which the root key is obtained at the last main node." There is insufficient antecedent basis for this limitation in the claim.
Claim 17 recites the limitation " for the encrypted transmission of the root key to a new node in the system, this new node also determines its own root key-part as a random number and first the start value “x” is encrypted in the new node using this encryption method and its own root key-part as a key, then the result is sent step by step to all main nodes and there in the individual main nodes the respective current result is encrypted again with the respective root key-part until in all main nodes an encryption with the respective own root key-part took place, and finally the result is sent again to the new node and is decrypted there with the own root key-part, whereby the root key results." There is insufficient antecedent basis for this limitation in the claim.
Claim 18 recites the limitation " external high-security hardware tokens of the individual nodes and all root key parts are located exclusively in these external hardware tokens of the nodes, and the result of the encryption is also electronically signed in the hardware token of each node, the signature is sent to the next node, all hardware tokens of the main nodes and, if applicable, of the new node check this signature before their encryption process and perform the encryption only if the result is positive, so that all encryptions for root key calculation in hardware tokens are thereby guaranteed." There is insufficient antecedent basis for this limitation in the claim.
Claim 19 recites the limitation "the main nodes." There is insufficient antecedent basis for this limitation in the claim.
Claim 20 recites the limitation " the read database commands and/or file commands are checked with respect to the read authorization of the relevant user or role or other relevant subject, and the write database commands and/or file commands are checked with respect to the write authorization of the relevant user or of the relevant role or of another relevant subject, respectively, are checked by the own node and, in the case of data replication to all other nodes, are checked by the other nodes with the aid of the management unit according to the management blockchain and, if valid, are passed on to the relevant database system or file system, respectively." There is insufficient antecedent basis for this limitation in the claim.
Claim 21 recites the limitation " wherein during data replication at the other nodes, the validity start time of the write authorization is also compared with the time stamp and the plausibility of the time stamp is checked." There is insufficient antecedent basis for this limitation in the claim.
Claim 22 recites the limitation "the own node." There is insufficient antecedent basis for this limitation in the claim.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-7, 11 and 13-15 are rejected under 35 U.S.C. 103 as being unpatentable over Zhou et al. (US 20210089497 A1, hereinafter “Zhou”) in view of Liu (US 20220229577 A1) in view of Padmanabhan (US 20210243193 A1).
Regarding independent claim 1, Zhou discloses a method of migrating an IT application of a central system to an information-technology application with blockchain technology or Distributed Ledger Technology and that runs on several nodes, including all or certain data desired by the respective node, so that the entire processing of the IT application takes place in the nodes including all relevant data, and the nodes exchange the required data via a network (Zhou: [0019] As shown in FIG. 1, an application environment may include a plurality of application systems (“a central system”), i.e., an application system 110, an application system 120, . . . , and an application system 130. The application systems here can be configured to provide a variety of services for a user, and each application system may include one or more data objects; [0020] The data object 112 can be migrated from one application system to another application system for a variety of reasons (“migrating an IT application”); [0021] A metadata blockchain 140 may be included in the application environment, for storing metadata related to various data objects (“IT application with blockchain technology”). The metadata here may include digest information of a data object. For example, digest information 142 of the data object 112 can be generated, and the digest information 142 is stored in the metadata blockchain 140), wherein
a program is integrated into the operating system and/or before and/or in and/or after database system and/or IT applications as middleware (Zhou: [0019] Technical solutions for data protection have long focused on managing data objects more reliably (“as middleware”). FIG. 1 schematically illustrates a block diagram 100 of a process for managing a data object 112 according to a technical solution (“program”); [0020-0021] the data object 112 here may also include other types of data, such as text files, images, audio, video, and other file types (“a program is integrated into the operating system”). For example, the data object 112 may also include images of an operating system, an application system, and so on at the application system 110. The data object 112 can be migrated from one application system to another application system for a variety of reasons. A metadata blockchain 140 may be included in the application environment, for storing metadata related to various data objects), so that the IT application does not have to be modified or only slightly modified (Zhou: [0020] The data object 112 can be migrated from one application system to another application system for a variety of reasons; [0021] For example, a malicious program may tamper with content of the data object 112, causing the data object 112 to be inconsistent with original raw data. During data migration 150, metadata can be generated for a migrated data object 122, and the generated metadata is compared with the metadata 142 in the metadata blockchain to see whether they are consistent, thereby ensuring the security of the data object).
Although, Zhou teaches, in paragraph 0024, the data flow blockchain, Zhou does not teach “in accordance with the authorizations and thus the relevant read protection and preferably also write protection, the data or parts thereof are cryptographically encrypted before being written to a nonvolatile data memory and/or database system and/or file system and after being read from a nonvolatile data memory and/or database system and/or file system, the data or parts thereof are cryptographically decrypted.”
In a same filed of endeavor, Liu discloses the method, wherein in accordance with the authorizations and thus the relevant read protection and preferably also write protection (Liu: [0028] As shown in FIG. 1, the first blockchain node system may specifically include a node 100 a, a node 100 b, a node 100 c, . . . , and a node 100 n. The second blockchain node system may specifically include a node 200A, a node 200B, a node 200C, . . . , and a node 200N; [0031] Currently, types of blockchains may include: a public blockchain, a private blockchain, or a consortium blockchain. The private blockchain is a blockchain that can be used within a private organization, where read and write permissions (“the relevant read and write protection in accordance with the authorizations”) and a permission to participate in accounting are specified according to rules of the private organization),
the data or parts thereof are cryptographically encrypted before being written to a nonvolatile data memory and/or database system and/or file system and (Liu: [0076] As shown in FIG. 5, a node 10 may be a first node (e.g., node 100 a) in a first blockchain network (e.g., the first blockchain network shown in FIG. 1), and a node 20 may be a second node (e.g., node 200A) in a second blockchain network (e.g., the second blockchain network shown in FIG. 1). It is to be understood that the node 10 may encrypt second service data information based on a public key of the node 20 to obtain encrypted data information corresponding to the second service data information (“data or parts thereof are cryptographically encrypted”); [0138] Further, FIG. 11 is a schematic diagram of a node device according to an embodiment of this disclosure. The memory 1005 may be a high-speed random access memory (RAM), or may be a non-volatile memory, for example, at least one magnetic disk memory (“nonvolatile data memory and/or database system and/or file system”)),
after being read from a nonvolatile data memory and/or database system and/or file system, the data or parts thereof are cryptographically decrypted (Liu: [0076] the node 20 may receive the encrypted data information migrated by the node 10, and decrypt the encrypted data information based on a private key of the node 20 to obtain the second service data information (“cryptographically decrypted”); [0138] Further, FIG. 11 is a schematic diagram of a node device according to an embodiment of this disclosure. The memory 1005 may be a high-speed random access memory (RAM), or may be a non-volatile memory, for example, at least one magnetic disk memory).
Before the effective filing date of the claimed invention, it would have been obvious for one of ordinary skill in the art to have modified the application environment disclosed by Zhou with the teachings of Liu to include relevant read protection and preferably also write protection in accordance with the authorizations, the data or parts thereof are cryptographically encrypted before being written to a nonvolatile data memory and/or database system and/or file system and, after being read from a nonvolatile data memory and/or database system and/or file system, the data or parts thereof are cryptographically decrypted. One of ordinary skill in the art would have been motivated to make this modification because this disclosure can realize that the data migration efficiency can be improved and the security of migrated data can be increased (para. 0115).
However, the combination does not teach, Padmanabhan in a same field of endeavor discloses the method according to claim 1, wherein the central authorization systems for supplying the current authorizations are retained (Padmanabhan: [0078] Because most of the early blockchains were permissionless, there is some debate about the specific accepted definition of a so called “blockchain,” such as, whether a private system with verifiers tasked and authorized (permissioned) by a central authority is considered a blockchain)
and/or in that the central systems for processing applications for users are also retained and in this case act as separate nodes and in this case the data encrypted in the nodes are used unencrypted in the central systems and therefore the data are suitably decrypted before being transferred to a central system and suitably encrypted after leaving the central system.
Before the effective filing date of the claimed invention, it would have been obvious for one of ordinary skill in the art to have modified the application environment disclosed by Zhou with the teachings of Padmanabhan to include the central authorization systems for supplying the current authorizations are retained. One of ordinary skill in the art would have been motivated to make this modification because permissioned (e.g., private) blockchains use an access control layer to govern who has access to the network (para. 0079).
Regarding claim 2, the combination of Zhou, Liu and Padmanabhan teaches all elements of the current invention as stated above. Zhou discloses the method according to claim 1, wherein
in nodes this management unit is connected in the middleware to the IT applications and/or the operating system and/or the database systems and/or the central authorization systems (Zhou: [0019] FIG. 1 schematically illustrates a block diagram 100 of a process for managing a data object 112 according to a technical solution. The data object 112 here may be a data block for storing music data (“management unit connected in middleware”); [0020] the data object 112 may also include images of an operating system, an application system, and so on at the application system 110; [0024] The migration record 212 may include a variety of information associated with the data object 112).
Liu in a same field of endeavor discloses the method according to claim 1, wherein the access authorizations to data in database systems and files are stored in a management blockchain accessible to all nodes, created from the data of the authorization systems present in the central system and/or other data from a management unit in service nodes (Liu: [0112] any one of hash1, hash2, hash3, or hash4 has a unique authentication path (“access authorizations to data in database systems and files are stored in a management blockchain accessible to all nodes”). For example, if the target hash value corresponding to the initial hash value of the target service data information is hash3 corresponding to transaction 3 in FIG. 8, the authentication path of hash3 (i.e., the target hash value) belongs may be hash3-hash34-hash1234, so that it may be determined that hash1234 (that is, the root hash value) is the first root hash value).
Before the effective filing date of the claimed invention, it would have been obvious for one of ordinary skill in the art to have modified the application environment disclosed by Zhou with the teachings of Liu to include the access authorizations to data in database systems and files are stored in a management blockchain accessible to all nodes, created from the data of the authorization systems present in the central system and/or other data from a management unit in service nodes. One of ordinary skill in the art would have been motivated to make this modification because the authenticity of the service data information can be ensured, to prevent malicious tampering by others (para. 0106). Therefore, the data migration efficiency can be improved and the security of migrated data can be increased.
Regarding claim 3, the combination of Zhou, Liu and Padmanabhan teaches all elements of the current invention as stated above. Liu discloses the method according to claim 2, wherein
the management blockchain contains different block types in the form of node blocks, namely node blocks with important information about all nodes authorization blocks with all relevant authorizations authorizations (Liu: [0107] The target block may include a block header. The block header may include a hash value of the parent block, a version number, a timestamp, a difficulty value, a random number, and a Merkle root (“different block types in the form of node blocks”); [0112] any one of hash1, hash2, hash3, or hash4 has a unique authentication path (“authorization blocks with all relevant authorizations”)), determined from one or more conditions certificate blocks with all necessary certificates and/or parameter blocks with all necessary values for the key management and/or the data encryption/data decryption and/or the data conversion and/or the root key calculation (Liu: [0112] any one of hash1, hash2, hash3, or hash4 has a unique authentication path. For example, if the target hash value corresponding to the initial hash value of the target service data information is hash3 corresponding to transaction 3 in FIG. 8, the authentication path of hash3 (i.e., the target hash value) belongs may be hash3-hash34-hash1234, so that it may be determined that hash1234 (that is, the root hash value) is the first root hash value (“root key calculation”)).
Before the effective filing date of the claimed invention, it would have been obvious for one of ordinary skill in the art to have modified the application environment disclosed by Zhou with the teachings of Liu to include the management blockchain that contains different block types in the form of node blocks, namely node blocks with important information about all nodes authorization blocks with all relevant authorizations, determined from one or more conditions certificate blocks with all necessary certificates and/or parameter blocks with all necessary values for the key management and/or the data encryption/data decryption and/or the data conversion and/or the root key calculation. One of ordinary skill in the art would have been motivated to make this modification because the authenticity of the service data information can be ensured, to prevent malicious tampering by others (para. 0106). Therefore, the data migration efficiency can be improved and the security of migrated data can be increased.
Regarding claim 4, the combination of Zhou, Liu and Padmanabhan teaches all elements of the current invention as stated above. Liu discloses the method according to claim 1, wherein for secure traceability of the processing, data required are concatenated by a concatenation to form a data blockchain (Liu: [0112] any one of hash1, hash2, hash3, or hash4 has a unique authentication path. For example, if the target hash value corresponding to the initial hash value of the target service data information is hash3 corresponding to transaction 3 in FIG. 8, the authentication path of hash3 (i.e., the target hash value) belongs may be hash3-hash34-hash1234, so that it may be determined that hash1234 (that is, the root hash value) is the first root hash value).
Before the effective filing date of the claimed invention, it would have been obvious for one of ordinary skill in the art to have modified the application environment disclosed by Zhou with the teachings of Liu to include data required that are concatenated by a concatenation to form a data blockchain for secure traceability of the processing. One of ordinary skill in the art would have been motivated to make this modification because the authenticity of the service data information can be ensured, to prevent malicious tampering by others (para. 0106). Therefore, the data migration efficiency can be improved and the security of migrated data can be increased.
Regarding claim 5, the combination of Zhou, Liu and Padmanabhan teaches all elements of the current invention as stated above. Padmanabhan in a same field of endeavor discloses the method according to claim 4,
wherein data is made unreadable despite the concatenation of the data blocks by deleting the key in all nodes (Padmanabhan: [0306] These functions together provide the ability for a blockchain to ‘forget’ data by encrypting the private data and then deleting the encryption key upon request of the controlling entity to ensure the data cannot be accessed again).
Before the effective filing date of the claimed invention, it would have been obvious for one of ordinary skill in the art to have modified the application environment disclosed by Zhou with the teachings of Padmanabhan to include data that is made unreadable despite the concatenation of the data blocks by deleting the key in all nodes. One of ordinary skill in the art would have been motivated to make this modification because the right to forget function is effectively able to designate data as ‘forgotten’ by the blockchain since it cannot be subsequently accessed even though the data is present in an encrypted form on the blockchain (para. 0306).
Regarding claim 6, the combination of Zhou, Liu and Padmanabhan teaches all elements of the current invention as stated above. Zhou discloses the method according to claim 1,
wherein for the cryptographic encryption and decryption and calculation of electronic signatures only lattice-based and/or code-based and/or hash-based and/or multivariant cryptography and/or cryptography based on supersingular isogenic curves and/or AES algorithm for symmetric cryptography are used (Zhou: [0039] The <signature> in the script represents a signature for performing encryption, <pubkey> represents a public key for performing decryption, and [DFOP_VERIFYSIG], [DFOP_HASH], and [DFOP_EQ] can represent different actions respectively, such as a validation action, a hash action (“hash-based”), and a push action).
Regarding claim 7, the combination of Zhou, Liu and Padmanabhan teaches all elements of the current invention as stated above. Liu discloses the method according to claim 1, wherein
in the encryption of data for database systems, rows and/or columns or data fields of rows of tables supplied to the database in encrypted form are cryptographically encrypted according to the authorizations of users and/or roles and/or other subjects (Liu: [0076] The private key of the node 20 is used for decrypting the encrypted data information corresponding to the second service data information; [0106] by writing the second service data information into the blockchain 2 (i.e., the second blockchain), the authenticity of the second service data information can be ensured, to prevent malicious tampering by others (“encrypted form are cryptographically encrypted according to the authorizations of users and/or other subjects”)).
Before the effective filing date of the claimed invention, it would have been obvious for one of ordinary skill in the art to have modified the application environment disclosed by Zhou with the teachings of Liu to include, in the encryption of data for database systems, rows and/or columns or data fields of rows of tables supplied to the database in encrypted form are cryptographically encrypted according to the authorizations of users and/or roles and/or other subjects. One of ordinary skill in the art would have been motivated to make this modification because the authenticity of the service data information can be ensured, to prevent malicious tampering by others (para. 0106). Therefore, the data migration efficiency can be improved and the security of migrated data can be increased.
Regarding claim 11, the combination of Zhou, Liu and Padmanabhan teaches all elements of the current invention as stated above. Liu disclose the method according to claim 1, wherein
the cryptographic concatenation of the data blocks is separated into a multistage level and that on the lowest level no concatenation takes place and this only applies to the node and that on the middle level a temporary concatenation takes place and this only applies to the node (Liu: [0107] As shown in FIG. 8 (“a multistage level”, refer to Fig.8), the target block may be a block with a largest timestamp in a blockchain 8. It can be understood that hash12 may be obtained by combining hash1 and hash2 into a character string and performing a hash operation on the character string. hash1 may be a hash value corresponding to transaction 1, and hash2 (“middle level no concatenation takes”) may be a hash value corresponding to transaction 2 (“lowest level no concatenation”)) and
that on the upper level with validity in the entire system a final concatenation takes place and that the lowest and/or middle level and/or upper level can also be omitted (Liu: [0107] The genesis block in the blockchain 8 may also be referred to as a parent block. It is to be understood that the Merkle root (i.e., hash1234, also known as the root hash value (“final concatenation”)) may be obtained by combining hash12 and hash34 (“upper level”) into a character string and performing a hash operation on the character string; [0112] it may be determined that hash1234 (that is, the root hash value) is the first root hash value; [0114] It can be understood that the second node may traverse all the root hash value information in the root hash value information B, search for the root hash value information that matches the first root hash value, and then determine that the root hash value b matches the first root hash value (“lowest and/or middle level and/or upper level can also be omitted”))
and that storage can thereby still be released during processing in the node and before distribution to all other nodes and storage space can be saved and that instead of data, of database commands or files only the hash values thereof including header data are concatenated (Liu: [0107] The target block may include a block header. The block header (“header data are concatenated”) may include a hash value of the parent block, a version number, a timestamp, a difficulty value, a random number, and a Merkle root. It is to be understood that the Merkle root (i.e., hash1234, also known as the root hash value) may be obtained by combining hash12 and hash34 into a character string and performing a hash operation on the character string (“hash values”)).
Before the effective filing date of the claimed invention, it would have been obvious for one of ordinary skill in the art to have modified the application environment disclosed by Zhou with the teachings of Liu to include the cryptographic concatenation of the data blocks is separated into a multistage level and that on the lowest level no concatenation takes place and this only applies to the node and that on the middle level a temporary concatenation takes place and this only applies to the node and that on the upper level with validity in the entire system a final concatenation takes place and that the lowest and/or middle level and/or upper level can also be omitted and that storage can thereby still be released during processing in the node and before distribution to all other nodes and storage space can be saved and that instead of data, of database commands or files only the hash values thereof including header data are concatenated. One of ordinary skill in the art would have been motivated to make this modification because the authenticity of the service data information can be ensured, to prevent malicious tampering by others (para. 0106). Therefore, the data migration efficiency can be improved and the security of migrated data can be increased.
Regarding claim 13, the combination of Zhou, Liu and Padmanabhan teaches all elements of the current invention as stated above. Padmanabhan in a same field of endeavor discloses the method according to claim 1, wherein
the central authorization systems for supplying the current authorizations are retained (Padmanabhan: [0078] Because most of the early blockchains were permissionless, there is some debate about the specific accepted definition of a so called “blockchain,” such as, whether a private system with verifiers tasked and authorized (permissioned) by a central authority is considered a blockchain)
and/or in that the central systems for processing applications for users are also retained and in this case act as separate nodes and in this case the data encrypted in the nodes are used unencrypted in the central systems and therefore the data are suitably decrypted before being transferred to a central system and suitably encrypted after leaving the central system.
Before the effective filing date of the claimed invention, it would have been obvious for one of ordinary skill in the art to have modified the application environment disclosed by Zhou with the teachings of Padmanabhan to include the central authorization systems for supplying the current authorizations are retained. One of ordinary skill in the art would have been motivated to make this modification because permissioned (e.g., private) blockchains use an access control layer to govern who has access to the network (para. 0079).
Regarding claim 14, the combination of Zhou, Liu and Padmanabhan teaches all elements of the current invention as stated above. Liu discloses the method according to claim 1, wherein
the middleware contains an IT security system and this IT security system specifies the security requirements and/or cryptographic methods of each individual node, checks them in all nodes and reports deviations to the other nodes (Liu: [0076] As shown in FIG. 5, a node 10 may be a first node (e.g., node 100 a) in a first blockchain network (e.g., the first blockchain network shown in FIG. 1), and a node 20 may be a second node (e.g., node 200A) in a second blockchain network (e.g., the second blockchain network shown in FIG. 1). It is to be understood that the node 10 may encrypt second service data information based on a public key of the node 20 to obtain encrypted data information corresponding to the second service data information (“cryptographic methods”)).
Before the effective filing date of the claimed invention, it would have been obvious for one of ordinary skill in the art to have modified the application environment disclosed by Zhou with the teachings of Liu to include IT security system specifies cryptographic methods of each individual node, checks them in all nodes and reports deviations to the other nodes. One of ordinary skill in the art would have been motivated to make this modification because this disclosure can realize that the data migration efficiency can be improved and the security of migrated data can be increased (para. 0115).
Regarding claim 15, the combination of Zhou, Liu and Padmanabhan teaches all elements of the current invention as stated above. Liu discloses the method according to claim 1, wherein
the calculation and storage of the cryptographic keys (Liu: [0131] The third obtaining unit 401 is configured to obtain a public key of the second node in the second blockchain network) and/or
the encryption and decryption of the data blocks in the nodes take place either unprotected in the node or in a hardware-protected sandbox in the node or in external hardware tokens, depending on the security level, and, if required, the IT security system checks the security level in the node and reports any deviations to the other nodes.
Before the effective filing date of the claimed invention, it would have been obvious for one of ordinary skill in the art to have modified the application environment disclosed by Zhou with the teachings of Liu to include the calculation and storage of the cryptographic keys. One of ordinary skill in the art would have been motivated to make this modification because this disclosure can realize that the data migration efficiency can be improved and the security of migrated data can be increased (para. 0115).
Claims 8-9 are rejected under 35 U.S.C. 103 as being unpatentable over Zhou et al. (US 20210089497 A1, hereinafter “Zhou”) in view of Liu (US 20220229577 A1) in view of Padmanabhan (US 20210243193 A1) as applied to claim 7 above, and further in view of Arnold et al. (US 20160224795 A1, hereinafter “Arnold”).
Regarding claim 8, the combination of Zhou, Liu and Padmanabhan teaches all elements of the current invention as stated above. However, the combination does not teach, Arnold in a same field of endeavor disclose the method according to claim 7, wherein
several individual data fields of rows of tables of databases and/or entire rows/columns of tables that have the same encryption or decryption key are combined into a single data field and this combined data field is encrypted or decrypted (Arnold: [0032] key derivation data may be extracted from a row of the data (“individual data fields”) to be encrypted and stored in the database 110. At block 420, the key derivation data may be combined with a static key to generate an encryption subkey unique to the row. At block 430, the sensitive data in the row may be encrypted using the encryption subkey (“a single data field with encryption or decryption key”); [0033] at block 510, key derivation data may be extracted from a row (“a single data field”) of the data read from the database 110. At block 520, the key derivation data may be combined with a static key (“a special uniform dense”) to determine the encryption subkey unique to the row), and
before this combination of data fields, the individual data fields are converted into a special uniform dense without gaps, data type and, after the encryption or decryption, are converted back into the original data types (Arnold: [0032] At block 420, the key derivation data may be combined with a static key to generate an encryption subkey unique to the row. At block 430, the sensitive data in the row may be encrypted using the encryption subkey (“a single data field”); [0033] at block 510, key derivation data may be extracted from a row of the data read from the database 110. At block 520, the key derivation data may be combined with a static key (“a special uniform dense”) to determine the encryption subkey unique to the row. At block 530, the encrypted sensitive fields of the row may be decrypted using the encryption subkey (“converted back into the original data types”). Various decryption algorithms may be used, including, for example, VFPE, as long as the decryption algorithm used is the same as the encryption algorithm being used).
Before the effective filing date of the claimed invention, it would have been obvious for one of ordinary skill in the art to have modified the application environment disclosed by Zhou with the teachings of Arnold to include several individual data fields of rows of tables of databases and/or entire rows/columns of tables that have the same encryption or decryption key are combined into a single data field and this combined data field is encrypted or decrypted, and before this combination of data fields, the individual data fields are converted into a special uniform dense without gaps, data type and, after the encryption or decryption, are converted back into the original data types. One of ordinary skill in the art would have been motivated to make this modification because each encryption subkey may be based on row data that is unique for the applicable row, the encryption subkey may likewise be unique for each row (para. 0028).
Regarding claim 9, the combination of Zhou, Liu and Padmanabhan teaches all elements of the current invention as stated above. However, the combination does not teach, Arnold in a same field of endeavor disclose the method according to claim 7, wherein
during the encryption and decryption of these rows and/or columns or data fields of rows of tables, format-preserving cryptography is used so that the data type and length are preserved and date information remains valid information even after encryption (Arnold: [0004] Format-preserving encryption (FPE) exists to address the above issue. FPE encrypts data in place without changing the size or character set of the data being encrypted).
Before the effective filing date of the claimed invention, it would have been obvious for one of ordinary skill in the art to have modified the application environment disclosed by Zhou with the teachings of Arnold to include format-preserving cryptography that is used so that the data type and length are preserved and date information remains valid information even after encryption during the encryption and decryption of these rows and/or columns or data fields of rows of tables. One of ordinary skill in the art would have been motivated to make this modification because the one or more sensitive fields in the first row of data are encrypted with format-preserving encryption using the first encryption subkey (para. 0008).
Claim 10 is rejected under 35 U.S.C. 103 as being unpatentable over Zhou et al. (US 20210089497 A1, hereinafter “Zhou”) in view of Liu (US 20220229577 A1) in view of Padmanabhan (US 20210243193 A1) as applied to claim 1 above, and further in view of Tanaka (US 20110142242 A1).
Regarding claim 10, the combination of Zhou, Liu and Padmanabhan teaches all elements of the current invention as stated above. However, the combination does not teach, Tanaka in a same field of endeavor discloses the method according to claim 1, wherein
in each node, all older calculations of the read key are calculated from the current cryptographic read key by asymmetric quantum computer-secure decryption, and new key calculations are calculated in service nodes or hardware tokens as part of the service nodes by asymmetric quantum computer-secure encryption (Tanaka: [0075] In the following, a key generation method, an encryption method and a decryption method in the quantum public key encryption system according to the present embodiment will be sequentially described in detail; [0077] A public key and a private key generated by the key generation method according to the present e