DETAILED 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 .
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 2/12/2026 has been entered.
As per instant Amendment claims 1 and 14 have been amended; claims 1 and 14 are independent claims. Claims 1-20 have been examined and are pending. This Action is made Non-Final.
Response to Arguments
Applicant's arguments filed 2/12/2026 with respect to the 35 U.S.C. 101 rejection have been fully considered but they are not persuasive.
Applicant Argues: ...Applicant respectfully disagrees for at least the following reasons.
The rejection alleges that the claims are directed to the abstract idea of "determining a classification and performing an action based on the classification." The rejection further alleges that the additional elements of "blockchain(s),""bridging... blockchain(s),""stored in memory of a security platform computing system," and "network interface/memory/processor" are generic computer components recited at a high level of generality that do not integrate the abstract idea into a practical application or amount to significantly more.
The amended claims are not directed to an abstract idea because they recite specific technical fraud detection methods that cannot be performed mentally. Specifically, claim 1 as amended recites "wherein the determining of the classification is performed at least in part using a detection of fraud, wherein the detection of fraud uses at least one of: (a) evidence collected by anti-virus software associated with a wallet of a victim of abuse, and (b) a report generated based on user input from an entity from which a token was transferred." These specific fraud detection mechanisms, collecting evidence via anti-virus software or generating reports based on user input regarding abuse, are technical processes that cannot practically be performed in the human mind or with pencil and paper. Anti-virus software is a specific technical tool that monitors and collects evidence of malicious activity, and user-generated abuse reports through wallet interfaces involve specific technical implementations for receiving and processing user input.
Even if the claims were found to recite an abstract idea, which Applicant disputes, the claims integrate any alleged abstract idea into a practical application. The claims provide a specific technological improvement to the field of blockchain bridging security by using fraud detection mechanisms to determine entry classifications. This addresses the technical problem of preventing fraudulent blockchain transactions from being confirmed during bridging operations. The combination of fraud detection using anti-virus software evidence or user abuse reports with blockchain entry classification provides a concrete technical solution that improves the security and integrity of blockchain bridging systems.
Furthermore, the claims amount to significantly more than any alleged abstract idea. Incorporating specific fraud detection mechanisms as recited in the amended claims are not routine or conventional in blockchain bridging. These specific mechanisms represent an inventive concept that goes beyond generally linking the use of an abstract idea to a particular technological environment.
In view of the above, Applicant respectfully requests withdrawal of the rejection under 35 U.S.C. §101..
Examiner’s Response: The examiner respectfully disagrees. The examiner respectfully notes that the human mind is capable of “determining a classification of the at least one entry based on a certainty level of abuse associated with the entry wherein the detection of fraud uses at least one of: (a) evidence collected by anti-virus software associated with a wallet of a victim of abuse, and (b) a report generated based on user input from an entity from which a token was transferred”, “performing an action based on the classification of the entry;” and “wherein the action comprises at least one action selected from a group comprising: determining the classification is confirmed and recording..., determining the classification is blocked and removing..., and determining the classification is delayed and keeping...”, as limitations encompass steps that a user can manually perform with the aid of pencil/paper. The examiner respectfully notes “...evidence collected by anti-virus software” and/or “...a report generated based on user input...” are noted to be additional elements that are recited at a high-level of generality (i.e., as a generic computing device performing a generic computer functions) such that it amounts no more than mere instructions to apply the exception or abstract idea using generic computer components. These, additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. Further, said elements taken individually or as a combination, do not result in the claim amounting to significantly more than the abstract idea because as the additional elements perform generic computer content distributing functions routinely used in information technology field. As discussed above, the additional elements recited at a high-level of generality such that they amount no more than mere instructions to apply the exception using a generic computer component. Thus, the claim is directed to non-statutory subject matter.
Therefore, the examiner finds this argument not persuasive.
Applicant's arguments filed 2/12/2026 with respect to the 35 U.S.C. 103 rejection have been fully considered but they are not persuasive and/or are moot in view of new grounds of rejection.
Applicant Argues: Claim 1 recites, in relevant part, "determining a classification of the at least one entry based on a certainty level of abuse associated with the entry, wherein the classification comprises at least one of confirmed, delayed, and blocked, wherein the determining of the classification is performed at least in part using a detection of fraud, wherein the detection of fraud uses at least one of: (a) evidence collected by anti-virus software associated with a wallet of a victim of abuse, and (b) a report generated based on user input from an entity from which a token was transferred." Independent claim 14 recites corresponding limitations.
[...]
This is a data integrity verification mechanism, not fraud detection using anti-virus software or user-generated abuse reports as recited in claim 1.
Examiner’s Response: The examiner respectfully disagrees. The examiner notes that Harding discloses “determining a classification of the at least one entry based on a certainty level of abuse associated with the entry, wherein the classification comprises at least one of confirmed, delayed, and blocked,” see rejection below. Therefore, the examiner finds this argument not persuasive as the substance of the augment is directed towards the new claim amendment. The examiner notes features related to “wherein the classification comprises at least one of confirmed, delayed, and blocked, wherein the determining of the classification is performed at least in part using a detection of fraud, wherein the detection of fraud uses at least one of: (a) evidence collected by anti-virus software associated with a wallet of a victim of abuse, and (b) a report generated based on user input from an entity from which a token was transferred” is moot in view of new grounds of rejection.
Applicant Argues: ...Moreover, there is no teaching, suggestion, or motivation in the cited references to combine them to arrive at the claimed elements. The references are directed to different technical problems, database extraction (Harding et al.), blockchain transaction reflection (Cho et al.), and data integrity verification (Ateniese), and do not suggest incorporating anti-virus software evidence collection or user abuse reporting into blockchain bridging classification systems.
Examiner’s Response: In response to applicant’s argument that there is no teaching, suggestion, or motivation to combine the references, the examiner recognizes that obviousness may be established by combining or modifying the teachings of the prior art to produce the claimed invention where there is some teaching, suggestion, or motivation to do so found either in the references themselves or in the knowledge generally available to one of ordinary skill in the art. See In re Fine, 837 F.2d 1071, 5 USPQ2d 1596 (Fed. Cir. 1988), In re Jones, 958 F.2d 347, 21 USPQ2d 1941 (Fed. Cir. 1992), and KSR International Co. v. Teleflex, Inc., 550 U.S. 398, 82 USPQ2d 1385 (2007). In this case ,the examiner respectfully notes that the Graham factual inquiries have been satisfied (1) a finding that the prior art contained a device (method, product, etc.) which differed from the claimed device by the substitution of some components (step, element, etc.) with other components; (2) a finding that the substituted components and their functions were known in the art; (3) a finding that one of ordinary skill in the art could have substituted one known element for another, and the results of the substitution would have been predictable. The examiner respectfully notes a person of ordinary skill in the art would have the technical skills to make the mere substitution and the outcome would be predictable. Mainly, substituting one for the other achieves a predictable result because Cho uses a first and second blockchain(s) in the same role as Harding’s first and second database(s) in order to store entries. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to substitute the first and second blockchain(s) of Cho for the first and second database(s) of Harding to arrive at the claimed invention because such a step is known and results of the substitution would have been predictable (i.e., for storing entries). Cho discusses such storage in [0007] and [0059] – recording transaction data, which includes the execution result of the target transaction, in a new block in a second blockchain network.
Further, examiner respectfully notes it would have been obvious to one of ordinarily skill in the art before the effective filing date of the claimed invention to combine the teachings of Ateniese to the blockchain(s) of Harding and Cho to include determining... [at least one entry] based on a certainty level of abuse associated with the entity and ...[removing the at least one entry from the plurality of entries] within the first blockchain. Motivation was provided in the form as Ateniese discuses it provides / allows a blockchain rewrite [which] dramatically improves system efficiency (Ateniese, col. 4, lines 2-4).
Therefore, the examiner that the combination of Harding in view of Cho and Anteniese is supported. Therefore, the examiner finds this argument not persuasive.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claim(s) 1-20 is/are rejected under 35 U.S.C. 101 as being directed to an abstract idea without being integrated into a practical application or being significantly more.
Regarding claim 1, and representative claim(s) 14, the claim recites the limitations “determining a classification of the at least one entry based on a certainty level of abuse associated with the entry...”, “performing an action based on the classification of the entry;” and “wherein the action comprises at least one action selected from a group comprising: determining the classification is confirmed and recording..., determining the classification is blocked and removing..., and determining the classification is delayed and keeping...”. Broadly interpreted, the aforementioned steps are directed to mental processes as said steps could be performed in the human mind. Therefore, the claims recite an abstract idea.
Said abstract idea and/or judicial exception is not integrated into a practical application as the claim does not recite any other active steps that could be considered that the abstract idea is being integrated into a practical application. It is noted that the claim recites the operations “bridging at least one entry from a plurality of entries, stored in memory on a security platform computing system, from a first blockchain to a second blockchain”, “...evidence collected by anti-virus software” and/or “...a report generated based on user input...” However, said additional elements are recited at a high-level of generality (i.e., as a generic computing device performing a generic computer functions) such that it amounts no more than mere instructions to apply the exception or abstract idea using generic computer components. Accordingly, these additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea.
The claims do not include additional elements/limitations/embodiments that are sufficient to amount to significantly more than the judicial exception because the additional elements when considered both individually and as an ordered combination do not amount to significantly more than the abstract idea. As mentioned above, although the claims recite additional elements, said elements taken individually or as a combination, do not result in the claim amounting to significantly more than the abstract idea because as the additional elements perform generic computer content distributing functions routinely used in information technology field. As discussed above, the additional elements recited at a high-level of generality such that they amount no more than mere instructions to apply the exception using a generic computer component. Therefore, the claim is directed to non-statutory subject matter.
Regarding Claims 2-13 and 15-20; claims 2-13 and 15-20 further defines the abstract idea that is present in their respective independent claims and hence are abstract for at least the reasons presented above w/ respect to mental processes. These dependent claims do not positively recite any other operations that could be considered as the abstract idea being integrated into a practical application or significantly more. Said steps are either directed to mental processes and/or are in a form of insignificant extra-solution activities and/or are recited at a high-level of generality. The aforementioned steps are not sufficient to consider that the abstract idea is being integrated into a practical application or significantly more. Therefore, claims 2-13 and 15-20, are also rejected under 35 U.S.C. 101 as being directed to non-statutory subject matter.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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.
Claim(s) 1, 4-8, 11, 14, and 17-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Harding et al. (US 2019/0341133 A1) in view of Cho et al. (US 2020/0364212 A1) and Ateniese et al. (US 9,774,578 B1) and Bravick et al. (US 2019/0370813 A1).
Regarding Claim 1;
Harding discloses a method for bridging between [databases] ([0015] - Some embodiments provide an Operational Intelligence Platform (“OIP”) that is configured to manage the extraction of electronic health records obtained from a source health care system. In some embodiments, the OIP is configured to extract electronic health record data from a source customer database that represents health records in a hierarchical format, such as a MUMPS-based representation. The OIP may then translate the extracted data into a relational representation that that logically preserves the hierarchical format. The OIP can then store the translated data in a database that provides relational access), comprising:
bridging at least one entry from a plurality of entries, stored in memory on a ... platform computing system, from a first [database] to a second [database] (FIG. 1 - [0015] and [0021]) and, wherein the at least one entry is associated with an event ([0026] - In the context of electronic health records, for example, the record can comprise many sub-parts, including patient information, condition updates, chart entries, and the like and [0043] - In another embodiment, real-time extraction, on-demand extraction, and delay queues interact as follows. A real-time extractor is configured to extract one or more categories of data from the source customer data 3. As one example, the real-time extractor is configured to extract patient vital sign data (e.g., blood pressure, pulse, oxygen level). In operation, the real-time extractor processes all updates to the source customer data 3, and forwards just those updates for the relevant categories (vital sign data, in this example) to be stored in the clinical data engine 114. As noted above, these updates can be obtained from journal files associated with the source customer data 3. These journal files thus naturally include both updates that are relevant and not relevant to the real-time extractor. In some embodiments, the platform 100 stores the journal files (or copies thereof) in (possibly compressed form) in cloud storage);
determining a classification of the at least one entry, wherein the classification comprises at least one of confirmed, delayed, and blocked ([0027] - In some cases, at least some of the queued updates may be duplicative of updates already performed or reflected by the extraction of the record. Thus, care may need to be taken to assure that those updates are either not performed, or that if they are performed, they will not result in an inconsistency between the source customer data 3 and the clinical data engine 114 (i.e., as construed a classification of blocked) and [0043]-[0045] - In another embodiment, real-time extraction, on-demand extraction, and delay queues interact as follows. A real-time extractor is configured to extract one or more categories of data from the source customer data 3. As one example, the real-time extractor is configured to extract patient vital sign data (e.g., blood pressure, pulse, oxygen level). In operation, the real-time extractor processes all updates to the source customer data 3, and forwards just those updates for the relevant categories (vital sign data, in this example) to be stored in the clinical data engine 114... (i.e., as construed a classification of confirmed) During operation of the platform 100, a need may arise to extract a category of data that is different from those currently being extracted. To continue the above example, a human user, application, or other program code may initiate extraction of a second category of data, such as patient location data. The following steps are performed to integrate this new, second category of data (i.e., as construed classification of delayed) into the extraction workflow. First, previously stored patient location data is fully extracted, such as by reference to a backup database, database clone, tape, or the like. This extraction pulls data up to a certain point in time. Next, the delay queue is processed to extract patient location data. In practice, this entails processing all journal files written since the time point reached by the full extraction. During this time, the real-time extractor continues to extract the first category of data but not the second... Once the delay queue is fully processed, the delay queue processing has “caught up” to real time, at which time the real-time extractor is configured to additionally ingest the second category of data (i.e., as construed as a classification of delayed). Such reconfiguration may occur dynamically and programmatically); and
performing an action based on the classification of the entry ([0027] and [0043]-[0045]);
wherein the action comprises at least one action selected from a group comprising: determining the classification is confirmed and recording on the second database the at least one entry and removing the at least one entry from the plurality of entries, determining the classification is blocked and removing the at least one entry from the plurality of entries, and determining the classification is delayed and keeping the at least one entry for an additional time period ([0021] - Such events or operations may include user interface events (e.g., mouse clicks, button presses), application-level events/operations (e.g., open form, log in), data access events/operations (e.g., save preferences, modify record, delete file), or the like and [0027] - In some cases, at least some of the queued updates may be duplicative of updates already performed or reflected by the extraction of the record. Thus, care may need to be taken to assure that those updates are either not performed, or that if they are performed, they will not result in an inconsistency between the source customer data 3 and the clinical data engine 114 (i.e., as construed Blocked) and [0043]-[0045] - In another embodiment, real-time extraction, on-demand extraction, and delay queues interact as follows. A real-time extractor is configured to extract one or more categories of data from the source customer data 3. As one example, the real-time extractor is configured to extract patient vital sign data (e.g., blood pressure, pulse, oxygen level). In operation, the real-time extractor processes all updates to the source customer data 3, and forwards just those updates for the relevant categories (vital sign data, in this example) to be stored in the clinical data engine 114... (i.e., as construed confirmed) During operation of the platform 100, a need may arise to extract a category of data that is different from those currently being extracted. To continue the above example, a human user, application, or other program code may initiate extraction of a second category of data, such as patient location data. The following steps are performed to integrate this new, second category of data (i.e., as construed Delayed) into the extraction workflow. First, previously stored patient location data is fully extracted, such as by reference to a backup database, database clone, tape, or the like. This extraction pulls data up to a certain point in time. Next, the delay queue is processed to extract patient location data. In practice, this entails processing all journal files written since the time point reached by the full extraction. During this time, the real-time extractor continues to extract the first category of data but not the second... Once the delay queue is fully processed, the delay queue processing has “caught up” to real time, at which time the real-time extractor is configured to additionally ingest the second category of data (i.e., as construed Delayed). Such reconfiguration may occur dynamically and programmatically);
Harding fails to explicitly disclose: A method for bridging between blockchains, comprising: bridging at least one entry from a plurality of entries, stored in a memory on a security platform system, from a first blockchain to a second blockchain...;
determining... [at least one entry] based on a certainty level of abuse associated with the entity..., wherein the determining of the classification is performed at least in part using a detection of fraud, wherein the detection of fraud uses at least one of: (a) evidence collected by anti-virus software associated with a wallet of a victim of abuse, and (b) a report generated based on user input from an entity from which a token was transferred; and
...recording on the second blockchain the at least one entry.... and ...[removing the at least one entry from the plurality of entries] within the first blockchain.
However, in an analogous art, Cho teaches A method for bridging between blockchains, comprising: bridging at least one entry from a plurality of entries, stored in memory on a security platform computing system, from a first blockchain to a second blockchain... and recording on the second blockchain ... at least one entry... ([0003] - Blockchain technology can ensure the integrity and security of transactions through a consensus process in which all blockchain nodes belonging to a network verify and record every transaction and [0007] - According to an aspect of the present disclosure, a system for supporting reflection of transactions between blockchain networks is provided. The system comprises a first bridge node which receives transaction data as to a first transaction within a source blockchain network, generates a transaction reflection message based on the received transaction data, and sends the generated transaction reflection message to a second bridge node related to a target blockchain network, and the second bridge node which generates a second transaction corresponding to the first transaction based on the generated transaction reflection message and processes the generated second transaction within the target blockchain network.).
A person of ordinary skill in the art would have the technical skills to make the mere substitution and the outcome would be predictable. Mainly, substituting one for the other achieves a predictable result because Cho uses a first and second blockchain(s) in the same role as Harding’s first and second database(s) in order to store entries. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to substitute the first and second blockchain(s) of Cho for the first and second database(s) of Harding to arrive at the claimed invention because such a step is known and results of the substitution would have been predictable (i.e., for storing entries).
Further, in an analogous art, Ateniese teaches
determining... [at least one entry] based on a certainty level of abuse associated with the entity... (col. 2, lines 39-51 - A blockchain may be secured by an integrity code. An integrity code may produce a particular integrity output when particular data is provided as input to the integrity code. In some cases, when data different than the particular data is provided to the integrity code as input, the integrity code may produce a different integrity output. In an example scenario an integrity output from the integrity code generated from particular input data from a data block is stored and the data block is later changed. If the changed data is provided to the integrity code as input, the integrity code may produce an integrity output that is different or otherwise coding-inconsistent with the stored integrity output. Therefore, the change may be detected in this example scenario and col. 2, lines 65-col. 3, lines 17 - When secured by an integrity code, a tamper-evident change may include virtually any change for which a coding-inconsistency between the integrity outputs of the integrity code for a blockchain and the data within the blockchain can be detected. For example, the data in a block of the blockchain may be hashed, run through a checksum, or have another integrity code applied. If the data in the block is later found to conflict with the integrity output of the hash, checksum, or other integrity code, the change may be identified as tamper-evident. ) and
...[removing the at least one entry from the plurality of entries] within the first blockchain (col. 3, lines 17-37 - Accordingly, a trusted party, for example a neutral third party, a governing party, or a group of individually untrusted parties, may rewrite, remove, or supplement data included in the blocks in a non-tamper-evident fashion. The systems and techniques described below implement technical solutions for rewriting blocks in the blockchain to allow trusted parties to redact information from the blockchain, without causing the blockchain to fail for its intended purpose. For example, the parties may use a modified blockchain as if it was the earlier, and unmodified, blockchain)
Therefore, it would have been obvious to one of ordinarily skill in the art before the effective filing date of the claimed invention to combine the teachings of Ateniese to the blockchain(s) of Harding and Cho to include determining... [at least one entry] based on a certainty level of abuse associated with the entity and
...[removing the at least one entry from the plurality of entries] within the first blockchain
One would have been motivated to combine the teachings of Ateniese to Harding and Cho to do so as it provides / allows a blockchain rewrite [which] dramatically improves system efficiency (Ateniese, col. 4, lines 2-4).
Further, in an analogous art, Bravick teaches wherein the determining of the classification is performed at least in part using a detection of fraud, wherein the detection of fraud uses at least one of: (a) evidence collected by anti-virus software associated with a wallet of a victim of abuse, and (b) a report generated based on user input from an entity from which a token was transferred ([0104] - For example, other types of payments/tokens may be used for acquiring trust scores, acquiring fraud reports, paying rewards, and staking and [0191] - For example, scoring features for a blockchain address may be based on 1) amounts associated with transactions, 2) timing data associated with transactions (e.g., dormancy), 3) graph-based values (e.g., one or more importance values) associated with the blockchain address, and/or 4) behavior-based data associated with the blockchain address. and [0193] - The trust module 300 includes a scoring model generation module 1108 (referred to herein as a “model generation module 1108”) that can generate scoring models 1600 that are used to generate local trust scores for a blockchain address... The set of scoring features a model uses as input may be referred to herein as a “feature vector.” In some implementations, the trust module 300 can use a deep neural net to score, where the classification is determined by known good/bad addresses).
Therefore, it would have been obvious to one of ordinarily skill in the art before the effective filing date of the claimed invention to combine the teachings of Bravick to classification of Harding and Cho to include wherein the determining of the classification is performed at least in part using a detection of fraud, wherein the detection of fraud uses at least one of: (a) evidence collected by anti-virus software associated with a wallet of a victim of abuse, and (b) a report generated based on user input from an entity from which a token was transferred
One would have been motivated to combine the teachings of Bravick to Harding and Cho and Ateniese to do so as it provides / allows safeguards against fraud in blockchain transactions (Bravick, [0002]).
Regarding Claim 4;
Harding and Cho and Ateniese and Bravick disclose the method to Claim 1.
Harding further discloses further comprising determining the classification indicates that the at least one entry is delayed ([0027] and [0043]-[0045] - In another embodiment, real-time extraction, on-demand extraction, and delay queues interact as follows. A real-time extractor is configured to extract one or more categories of data from the source customer data 3. As one example, the real-time extractor is configured to extract patient vital sign data (e.g., blood pressure, pulse, oxygen level). In operation, the real-time extractor processes all updates to the source customer data 3, and forwards just those updates for the relevant categories (vital sign data, in this example) to be stored in the clinical data engine 114... (i.e., as construed confirmed) During operation of the platform 100, a need may arise to extract a category of data that is different from those currently being extracted. To continue the above example, a human user, application, or other program code may initiate extraction of a second category of data, such as patient location data. The following steps are performed to integrate this new, second category of data (i.e., as construed Delayed) into the extraction workflow. First, previously stored patient location data is fully extracted, such as by reference to a backup database, database clone, tape, or the like. This extraction pulls data up to a certain point in time. Next, the delay queue is processed to extract patient location data. In practice, this entails processing all journal files written since the time point reached by the full extraction. During this time, the real-time extractor continues to extract the first category of data but not the second... Once the delay queue is fully processed, the delay queue processing has “caught up” to real time, at which time the real-time extractor is configured to additionally ingest the second category of data (i.e., as construed Delayed). Such reconfiguration may occur dynamically and programmatically)
Cho further teaches transferring the at least one entry to a third blockchain, the third blockchain being of the same level as the first blockchain ([0025] - The bridge network 20 is a network that supports reflection of transactions between a plurality of blockchain networks 10-1 through 10-n. The bridge network 20 may include a plurality of nodes, and each bridge node may be implemented as a computing device and [0034] - However, since embodiments to be described below are easily applicable even to transaction reflection performed between three or more blockchain network, the technical scope of the present disclosure is not limited by the number of interoperating blockchain networks and [0038] - Referring to FIG. 5, the transaction reflection rule sharing process may begin with operation S 110 in which the first bridge node 21 checks the state of the second bridge node 22 (e.g., health check). If the result of state checking indicates that the second bridge node 22 is not in a normal state (e.g., a failure state), the rule sharing process may be terminated.). As constructed a normal state represents a blockchain of the same level.
Similar rationale and motivation is noted for the combination of Cho in view of Harding and Cho and Ateniese and Bravick, as per Claim 1, above.
Regarding Claim 5;
Harding and Cho and Ateniese and Bravick disclose the method to Claim 1.
Harding further discloses further comprising determining the classification indicates that the at least one entry is delayed, and identifying the at least one entry and an entry that is to remain on the first [database] and to be bridged to the second [database] at a later point of time ([0027] and [0043]-[0045] - In another embodiment, real-time extraction, on-demand extraction, and delay queues interact as follows. A real-time extractor is configured to extract one or more categories of data from the source customer data 3. As one example, the real-time extractor is configured to extract patient vital sign data (e.g., blood pressure, pulse, oxygen level). In operation, the real-time extractor processes all updates to the source customer data 3, and forwards just those updates for the relevant categories (vital sign data, in this example) to be stored in the clinical data engine 114... (i.e., as construed confirmed) During operation of the platform 100, a need may arise to extract a category of data that is different from those currently being extracted. To continue the above example, a human user, application, or other program code may initiate extraction of a second category of data, such as patient location data. The following steps are performed to integrate this new, second category of data (i.e., as construed Delayed) into the extraction workflow. First, previously stored patient location data is fully extracted, such as by reference to a backup database, database clone, tape, or the like. This extraction pulls data up to a certain point in time. Next, the delay queue is processed to extract patient location data. In practice, this entails processing all journal files written since the time point reached by the full extraction. During this time, the real-time extractor continues to extract the first category of data but not the second... Once the delay queue is fully processed, the delay queue processing has “caught up” to real time, at which time the real-time extractor is configured to additionally ingest the second category of data (i.e., as construed Delayed). Such reconfiguration may occur dynamically and programmatically)
Cho further teaches ...identifying the at least one entry and an entry that is to remain on the first blockchain and to be bridged to the second blockchain... ([0025] - The bridge network 20 is a network that supports reflection of transactions between a plurality of blockchain networks 10-1 through 10-n. The bridge network 20 may include a plurality of nodes, and each bridge node may be implemented as a computing device and [0034] - However, since embodiments to be described below are easily applicable even to transaction reflection performed between three or more blockchain network, the technical scope of the present disclosure is not limited by the number of interoperating blockchain networks).
Similar rationale and motivation is noted for the combination of Cho in view of Harding and Cho and Ateniese and Bravick, as per Claim 1, above.
Regarding Claim 6;
Harding and Cho and Ateniese and Bravick disclose the method to Claim 1.
Harding further discloses wherein the determining of the classification is based information received from the second [database] (FIG. 1 and [0027] and [0043]-[0045] - In another embodiment, real-time extraction, on-demand extraction, and delay queues interact as follows. A real-time extractor is configured to extract one or more categories of data from the source customer data 3. As one example, the real-time extractor is configured to extract patient vital sign data (e.g., blood pressure, pulse, oxygen level). In operation, the real-time extractor processes all updates to the source customer data 3, and forwards just those updates for the relevant categories (vital sign data, in this example) to be stored in the clinical data engine 114... (i.e., as construed confirmed). During operation of the platform 100, a need may arise to extract a category of data that is different from those currently being extracted. To continue the above example, a human user, application, or other program code may initiate extraction of a second category of data, such as patient location data. The following steps are performed to integrate this new, second category of data (i.e., as construed Delayed) into the extraction workflow. First, previously stored patient location data is fully extracted, such as by reference to a backup database, database clone, tape, or the like. This extraction pulls data up to a certain point in time. Next, the delay queue is processed to extract patient location data. In practice, this entails processing all journal files written since the time point reached by the full extraction. During this time, the real-time extractor continues to extract the first category of data but not the second... Once the delay queue is fully processed, the delay queue processing has “caught up” to real time, at which time the real-time extractor is configured to additionally ingest the second category of data (i.e., as construed Delayed). Such reconfiguration may occur dynamically and programmatically). As construed the extractor will either confirm (i.e., form of classification) and/or delay (i.e., form of classification).
Cho further teaches ...the second blockchain ([0025] - The bridge network 20 is a network that supports reflection of transactions between a plurality of blockchain networks 10-1 through 10-n. The bridge network 20 may include a plurality of nodes, and each bridge node may be implemented as a computing device and [0034] - However, since embodiments to be described below are easily applicable even to transaction reflection performed between three or more blockchain network, the technical scope of the present disclosure is not limited by the number of interoperating blockchain networks).
Similar rationale and motivation is noted for the combination of Cho in view of Harding and Cho and Ateniese and Bravick, as per Claim 1, above.
Regarding Claim 7;
Harding and Cho and Ateniese and Bravick disclose the method to Claim 1.
Harding further discloses further comprising determining the classification indicates that the at least one entry is confirmed after a predetermined amount of time has elapsed since the entry was recorded on the first [database] ([0022] - The records in the source customer data 3 which are consumed by the OIP 100 may be obtained from various sources and/or represented in different ways. For example, the records may be obtained directly from the a production server/database (e.g., a live database that is serving clinicians and patients), a report shadow database (e.g., a utility copy utility copy for running reports), a production shadow database (e.g., near live, service as a backup of production), and/or a production mirror database (e.g., live, service as a disaster recovery, fail-over instance of production data). In some embodiments, the source for the records of the source customer data 3 may be specified and/or determined automatically by rule and/or conditions (e.g., to use a shadow or mirror database at certain times of day or when traffic or load on the production database increases beyond a specified level) and [0027] and [0043]-[0045] - In another embodiment, real-time extraction, on-demand extraction, and delay queues interact as follows. A real-time extractor is configured to extract one or more categories of data from the source customer data 3. As one example, the real-time extractor is configured to extract patient vital sign data (e.g., blood pressure, pulse, oxygen level). In operation, the real-time extractor processes all updates to the source customer data 3, and forwards just those updates for the relevant categories (vital sign data, in this example) to be stored in the clinical data engine 114... (i.e., as construed confirmed) During operation of the platform 100, a need may arise to extract a category of data that is different from those currently being extracted. To continue the above example, a human user, application, or other program code may initiate extraction of a second category of data, such as patient location data. The following steps are performed to integrate this new, second category of data (i.e., as construed Delayed) into the extraction workflow. First, previously stored patient location data is fully extracted, such as by reference to a backup database, database clone, tape, or the like. This extraction pulls data up to a certain point in time. Next, the delay queue is processed to extract patient location data. In practice, this entails processing all journal files written since the time point reached by the full extraction. During this time, the real-time extractor continues to extract the first category of data but not the second... Once the delay queue is fully processed, the delay queue processing has “caught up” to real time, at which time the real-time extractor is configured to additionally ingest the second category of data (i.e., as construed Delayed). Such reconfiguration may occur dynamically and programmatically).
Cho further teaches ...the first block chain ([0025] - The bridge network 20 is a network that supports reflection of transactions between a plurality of blockchain networks 10-1 through 10-n. The bridge network 20 may include a plurality of nodes, and each bridge node may be implemented as a computing device and [0034] - However, since embodiments to be described below are easily applicable even to transaction reflection performed between three or more blockchain network, the technical scope of the present disclosure is not limited by the number of interoperating blockchain networks).
Similar rationale and motivation is noted for the combination of Cho in view of Harding and Cho and Ateniese and Bravick, as per Claim 1, above.
Regarding Claim 8;
Harding and Cho and Ateniese and Bravick disclose the method to Claim 1.
Harding further discloses the classification of the at least one entry ([0027] and [0043]-[0045]).
Cho further teaches ...further comprising obtaining a vote between a plurality of entities regarding the [transaction] ([0031] - For example, the first blockchain network 10-1 may process a first transaction through a consensus process between blockchain nodes and record data related to the first transaction in a first blockchain. In addition, independently of the first blockchain network 10-1, the second blockchain network 10-2 may process a second transaction and record data related to the second transaction in a second blockchain).
Similar rationale and motivation is noted for the combination of Cho in view of Harding and Cho and Ateniese and Bravick, as per Claim 1, above.
Regarding Claim 11;
Harding and Cho and Ateniese and Bravick disclose the method to Claim 1.
Harding further discloses further comprising determining the classification indicates that the at least one entry is delayed and recording the at least one entry... ([0027] and [0043]-[0045] - In another embodiment, real-time extraction, on-demand extraction, and delay queues interact as follows. A real-time extractor is configured to extract one or more categories of data from the source customer data 3. As one example, the real-time extractor is configured to extract patient vital sign data (e.g., blood pressure, pulse, oxygen level). In operation, the real-time extractor processes all updates to the source customer data 3, and forwards just those updates for the relevant categories (vital sign data, in this example) to be stored in the clinical data engine 114... (i.e., as construed confirmed) During operation of the platform 100, a need may arise to extract a category of data that is different from those currently being extracted. To continue the above example, a human user, application, or other program code may initiate extraction of a second category of data, such as patient location data. The following steps are performed to integrate this new, second category of data (i.e., as construed Delayed) into the extraction workflow. First, previously stored patient location data is fully extracted, such as by reference to a backup database, database clone, tape, or the like. This extraction pulls data up to a certain point in time. Next, the delay queue is processed to extract patient location data. In practice, this entails processing all journal files written since the time point reached by the full extraction. During this time, the real-time extractor continues to extract the first category of data but not the second... Once the delay queue is fully processed, the delay queue processing has “caught up” to real time, at which time the real-time extractor is configured to additionally ingest the second category of data (i.e., as construed Delayed). Such reconfiguration may occur dynamically and programmatically)
Cho further teaches ...recording the at least one entry on a new third blockchain ([0025] - The bridge network 20 is a network that supports reflection of transactions between a plurality of blockchain networks 10-1 through 10-n. The bridge network 20 may include a plurality of nodes, and each bridge node may be implemented as a computing device and [0034] - However, since embodiments to be described below are easily applicable even to transaction reflection performed between three or more blockchain network, the technical scope of the present disclosure is not limited by the number of interoperating blockchain networks)
Similar rationale and motivation is noted for the combination of Cho in view of Harding and Cho and Ateniese and Bravick, as per Claim 1, above.
Regarding Claim(s) 14 and 17-20; claim(s) 14 and 17-20 is/are directed to a/an platform associated with the method claimed in claim(s) 1 and 4-7. Claim(s) 14 and 17-20 is/are similar in scope to claim(s) 1 and 4-7, and is/are therefore rejected under similar rationale.
Claim(s) 2-3 and 15-16 is/are rejected under 35 U.S.C. 103 as being unpatentable over Harding et al. (US 2019/0341133 A1) in view of Cho et al. (US 2020/0364212 A1) and Ateniese et al. (US 9,774,578 B1) and Bravick et al. (US 2019/0370813 A1) and further in view of Hernacki et al. (US 8,561,181 B1).
Regarding Claim 2;
Harding and Cho and Ateniese and Bravick disclose the method to Claim 1.
Harding further discloses further comprising determining the classification indicates that the at least one entry is blocked ([0027] - In some cases, at least some of the queued updates may be duplicative of updates already performed or reflected by the extraction of the record. Thus, care may need to be taken to assure that those updates are either not performed, or that if they are performed, they will not result in an inconsistency between the source customer data 3 and the clinical data engine 114 (i.e., as construed a classification of blocked) and [0043]-[0045]).
Harding and Cho and Ateniese and Bravick fail to explicitly disclose setting a flag associated with the entry to a value representing that the at least one entry is blocked.
However, in an analogous art, Hernacki teaches setting a flag associated with the [action] to a value representing that the at least one [action] is blocked (col. 8, lines 35-55 - The security module 124 additionally comprises the response module 315, which performs a remedial action in response to a failure to verify that a current page transition at the web site 110 has the expected security level. As noted above, such a failure could be, for example, a failure to obtain the requested site list 132, page list 355, or site-specific page list 114, a failure to authenticate the list even if received, or a transition security level lower than that specified in the applicable page list as expected when transitioning from web page 112A to web page 112B. The remedial action of the response module 315 could be, for example, to block the communication with the target web page 112B. The remedial action could additionally or alternatively be to issue an alert such as a displayed dialog box warning a user that a security breach may be being attempted, or to display a status flag in the browser 122 noting that certain data was blocked for security reasons. The remedial action might also be to send a report, e.g. a message describing the failure or summarizing the failure and other related failures, to the client 110 or to the security server 130 over the network 140, which could log the report for future analysis).
Therefore, it would have been obvious to one of ordinarily skill in the art before the effective filing date of the claimed invention to combine the teachings of Hernacki to the blocked entry of Harding and Cho and Ateniese and Bravick to include setting a flag associated with the entry to a value representing that the at least one entry is blocked
One would have been motivated to combine the teachings of Hernacki to Harding and Cho and Ateniese and Bravick to do so as it provides / allows means to display, report, and/or log [actions] being attempted (Hernacki, as gleaned from, col. 8, lines 35-55).
Regarding Claim 3;
Harding and Cho and Ateniese and Bravick disclose the method to Claim 1.
Harding further discloses further comprising determining the classification indicates that the at least one entry is blocked and [concepts of classification] ([0027] - In some cases, at least some of the queued updates may be duplicative of updates already performed or reflected by the extraction of the record. Thus, care may need to be taken to assure that those updates are either not performed, or that if they are performed, they will not result in an inconsistency between the source customer data 3 and the clinical data engine 114 (i.e., as construed a classification of blocked) and [0043]-[0045]).
Harding and Cho and Ateniese and Bravick fail to explicitly disclose logging data related to a reason for determining the classification of the at least one entry is blocked.
However, in an analogous art, Hernacki teaches logging data related to a reason for determining ... of the at least one [action] is blocked. (col. 8, lines 35-55 - The security module 124 additionally comprises the response module 315, which performs a remedial action in response to a failure to verify that a current page transition at the web site 110 has the expected security level. As noted above, such a failure could be, for example, a failure to obtain the requested site list 132, page list 355, or site-specific page list 114, a failure to authenticate the list even if received, or a transition security level lower than that specified in the applicable page list as expected when transitioning from web page 112A to web page 112B. The remedial action of the response module 315 could be, for example, to block the communication with the target web page 112B. The remedial action could additionally or alternatively be to issue an alert such as a displayed dialog box warning a user that a security breach may be being attempted, or to display a status flag in the browser 122 noting that certain data was blocked for security reasons. The remedial action might also be to send a report, e.g. a message describing the failure or summarizing the failure and other related failures, to the client 110 or to the security server 130 over the network 140, which could log the report for future analysis).
Therefore, it would have been obvious to one of ordinarily skill in the art before the effective filing date of the claimed invention to combine the teachings of Hernacki to the classification of the blocked entry of Harding and Cho and Ateniese and Bravick to include logging data related to a reasoned for determining ... of the at least one entry is blocked.
One would have been motivated to combine the teachings of Hernacki to Harding and Cho and Ateniese and Bravick to do so as it provides / allows means to display, report, and/or log [actions] being attempted (Hernacki, as gleaned from, col. 8, lines 35-55).
Regarding Claim(s) 15 and 16; claim(s) 15 and 16 is/are directed to a/an platform associated with the method claimed in claim(s) 2 and 3. Claim(s) 15 and 16 is/are similar in scope to claim(s) 2 and 3, and is/are therefore rejected under similar rationale.
Claim(s) 9 is/are rejected under 35 U.S.C. 103 as being unpatentable over Harding et al. (US 2019/0341133 A1) in view of Cho et al. (US 2020/0364212 A1) and Ateniese et al. (US 9,774,578 B1) and Bravick et al. (US 2019/0370813 A1) and further in view of Hamasni et al. (US 2019/0058595 A1).
Regarding Claim 9;
Harding and Cho and Ateniese and Bravick disclose the method to Claim 1.
Cho further teaches ...the second blockchain... the first blockchain.
Similar rationale and motivation is noted for the combination of Cho in view of Harding and Cho and Ateniese and Bravick, as per Claim 1, above.
Harding and Cho and Ateniese and Bravick fail to explicitly disclose wherein the second block chain has a different security protections that provide greater security than the first block chain.
However, in an analogous art, Hamasni teaches disclose wherein a second block chain has a different security protections that provide greater security than a first block chain.
([0108] - There may be interactions between the first and second distributed ledgers, and their stored data structures, for example, for verification of digital signatures of trusted individuals, etc. The first and the second distributed ledgers can be configured differently, for example, the encryption can be stored in sequential order of the digital signatures (e.g., each signing causing the generation of a new block) so that the order and sequence of signatures can be reconstructed. When a verification request is required, second distributed ledger can be used for a “first pass” verification, and the first distributed ledger can be used for a deeper verification against individual signatures. Accordingly, different levels of performance and security can be implemented on each of the distributed ledgers (as the requirements, number of transactions, trustworthiness of actors, etc. are different).
Therefore, it would have been obvious to one of ordinarily skill in the art before the effective filing date of the claimed invention to combine the teachings of Hamasni to the blockchain(s) of Harding and Cho and Ateniese and Bravick to include wherein a second block chain has a different security protections that provide greater security than a first block chain.
One would have been motivated to combine the teachings of Hamasni to Harding and Cho and Ateniese and Bravick to do so as it provides / allows different levels of performance and security (Hamasni, [0108]).
Claim(s) 10 is/are rejected under 35 U.S.C. 103 as being unpatentable over Harding et al. (US 2019/0341133 A1) in view of Cho et al. (US 2020/0364212 A1) and Ateniese et al. (US 9,774,578 B1) and Bravick et al. (US 2019/0370813 A1) and further in view of Ley (US 2021/0209596 A1).
Regarding Claim 10;
Harding and Cho and Ateniese and Bravick disclose the method to Claim 1.
Harding further discloses wherein the action comprises determining the classification is delayed ([0027] and [0043]-[0045] - In another embodiment, real-time extraction, on-demand extraction, and delay queues interact as follows. A real-time extractor is configured to extract one or more categories of data from the source customer data 3. As one example, the real-time extractor is configured to extract patient vital sign data (e.g., blood pressure, pulse, oxygen level). In operation, the real-time extractor processes all updates to the source customer data 3, and forwards just those updates for the relevant categories (vital sign data, in this example) to be stored in the clinical data engine 114... (i.e., as construed confirmed) During operation of the platform 100, a need may arise to extract a category of data that is different from those currently being extracted. To continue the above example, a human user, application, or other program code may initiate extraction of a second category of data, such as patient location data. The following steps are performed to integrate this new, second category of data (i.e., as construed Delayed) into the extraction workflow. First, previously stored patient location data is fully extracted, such as by reference to a backup database, database clone, tape, or the like. This extraction pulls data up to a certain point in time. Next, the delay queue is processed to extract patient location data. In practice, this entails processing all journal files written since the time point reached by the full extraction. During this time, the real-time extractor continues to extract the first category of data but not the second... Once the delay queue is fully processed, the delay queue processing has “caught up” to real time, at which time the real-time extractor is configured to additionally ingest the second category of data (i.e., as construed Delayed). Such reconfiguration may occur dynamically and programmatically)
Harding in view of Cho and Ateniese and Bravick fail to explicitly disclose re-recording the at least one entry on the first blockchain with a time stamp associated with an original time that the at least one entry was record on the first blockchain.
However, in an analogous art, Ley teaches disclose re-recording the at least one entry on the first blockchain with a time stamp associated with an original time that the at least one entry was record on the first blockchain ([0012] - The distributed database of the decentralized computer network 101 may be a blockchain. The blockchain may be a distributed ledger enabling the storage of data records as unique blocks connected by one or more secure links. The decentralized computer network containing a blockchain may be cryptographically secured. A given block in a blockchain may associate transaction data with a timestamp. In the blockchain, duplicate data can be recorded as unique blocks instead of as identical copies of data. A given block may comprise data of a previous block to the given block (e.g., wherein the data of the previous block is hashed), making the blockchain essentially immutable, as data once recorded in a block in the distributed ledger cannot be modified or removed without triggering inconsistency with the linked blocks. This immutable property can provide particular benefits to implementing digital tokens, such as to prevent forgery or other frauds in processing digital credits. A blockchain may comprise or implement one or more smart contracts (implementing token standards), as described elsewhere herein.).
Therefore, it would have been obvious to one of ordinarily skill in the art before the effective filing date of the claimed invention to combine the teachings of Ley to the blockchain(s) of Harding and Cho and Ateniese and Bravick to include disclose re-recording the at least one entry on the first blockchain with a time stamp associated with an original time that the at least one entry was record on the first blockchain
One would have been motivated to combine the teachings of Ley to Harding and Cho and Ateniese and Bravick to do so as it provides / allows a block in the distributed ledger [that] cannot be modified or removed without triggering inconsistency with the linked blocks (Hamasni, [0108]).
Claim(s) 12 is/are rejected under 35 U.S.C. 103 as being unpatentable over Harding et al. (US 2019/0341133 A1) in view of Cho et al. (US 2020/0364212 A1) and Ateniese et al. (US 9,774,578 B1) and Bravick et al. (US 2019/0370813 A1) and further in view of Yamauchi et al (US 5,649,102 A).
Regarding Claim 12;
Harding and Cho and Ateniese and Bravick disclose the method to Claim 1.
Harding further discloses ...the plurality of entries... that determines entries that are bridged on the first [database] and entries that are bridged on the second [database] ([0015] and [0021]).
Cho further teaches ...entries that are bridged on the first blockchain and entries that are bridged on the second blockchain ([0007] - According to an aspect of the present disclosure, a system for supporting reflection of transactions between blockchain networks is provided. The system comprises a first bridge node which receives transaction data as to a first transaction within a source blockchain network, generates a transaction reflection message based on the received transaction data, and sends the generated transaction reflection message to a second bridge node related to a target blockchain network, and the second bridge node which generates a second transaction corresponding to the first transaction based on the generated transaction reflection message and processes the generated second transaction within the target blockchain network.).
Similar rationale and motivation is noted for the combination of Cho in view of Harding and Cho and Ateniese and Bravick, as per Claim 1, above.
Harding and Cho and Ateniese and Bravick fail to explicitly disclose further comprising setting, for each entry of the plurality of entries... a flag to generate a flag array that determines entries that are bridged on the first [blockchain] and entries that are bridged on the second [blockchain].
However, in an analogous art, Yamauchi teaches further comprising setting, for each entry of the plurality of entries... a flag to generate a flag array that determines entries that are bridged on the first [storage] and entries that are bridged on the second [storage] (FIG. 5 and FIG. 6 – Scattering Flag (i.e., array) and col. 10, lines 9-24 – A copy of shared data (shared data replica) generated upon a shared data declaration of the invention is stored in the main storage at an area 512. As shown, the copied shared data is disposed in the main storage at continuous locations. The correspondence between the shared data at the area 511 and the copied shared data at the area 512 is managed by the shared data management table 405 and col. 14, lines 51-60 - If "1" is set to the scattering flag 606 of the shared data management table 405 when the source shared data is copied at Step 1305, the storage type at the area 512 shown in FIG. 5 is changed to the storage type 511).
Therefore, it would have been obvious to one of ordinarily skill in the art before the effective filing date of the claimed invention to combine the teachings of Yamauchi to the entries and blockchain(s) of Harding and Cho and Ateniese and Bravick to include setting, for each entry of the plurality of entries... a flag to generate a flag array that determines entries that are bridged on the first [storage] and entries that are bridged on the second [storage]
One would have been motivated to combine the teachings Yamauchi to Harding and Cho and Ateniese and Bravick to do so as it provides / allows shared “storage” which is capable of efficiently using network resources and providing a high access performance (Yamauchi, col. 3, lines 5-11).
Claim(s) 13 is/are rejected under 35 U.S.C. 103 as being unpatentable over Harding et al. (US 2019/0341133 A1) in view of Cho et al. (US 2020/0364212 A1) and Ateniese et al. (US 9,774,578 B1) and Bravick et al. (US 2019/0370813 A1) and Yamauchi et al (US 5,649,102 A) and further in view of Ebrahimi et al. (US 2018/0227131 A1).
Regarding Claim 13;
Harding and Cho and Ateniese and Bravick and Yamauchi disclose the method to Claim 12.
Harding further discloses ...the plurality of entries... ([0015] and [0021]).
Cho further teaches ...the second blockchain ([0007]).
Similar rationale and motivation is noted for the combination of Cho in view of Harding and Cho and Ateniese and Bravick, as per Claim 1, above.
Yamauchi further teaches ...appending the flag array to the concatenated plurality of entries... (FIG. 5 and FIG. 6 – Scattering Flag (i.e., array) and col. 10, lines 9-24 – A copy of shared data (shared data replica) generated upon a shared data declaration of the invention is stored in the main storage at an area 512. As shown, the copied shared data is disposed in the main storage at continuous locations. The correspondence between the shared data at the area 511 and the copied shared data at the area 512 is managed by the shared data management table 405 and col. 14, lines 51-60 - If "1" is set to the scattering flag 606 of the shared data management table 405 when the source shared data is copied at Step 1305, the storage type at the area 512 shown in FIG. 5 is changed to the storage type 511).
Similar rationale and motivation is noted for the combination of Yamauchi in view of Harding and Cho and Ateniese and Bravick and Yamauchi, as per Claim 12, above.
Harding in view of Cho and Ateniese and Bravick and Yamauchi fail to explicitly disclose further comprising concatenating the plurality of entries together...to generate a string; hashing the string; and recording the hash on [a] blockchain.
However, in an analogous art, Ebrahimi teaches concatenating the plurality of entries together...to generate a string; hashing the string; and recording the hash on [a] blockchain ([0089] - FIG. 5A is a diagram of the generation of a certification record from data taken as a whole, and the application of a salt value to the certification record, in accordance with one embodiment of the present disclosure. In that manner, the certification record may be further obfuscated from discovery, such as through brute force, dictionary, and other discovery tactics on the signed data. As previously described, a certifying entity generates a certification record of data, wherein the data was previously registered to a blockchain. As shown, the data may be PII, such as that obtained from a government agency ID card (e.g., driver's license). The combined data 505 may include the PII and other optional data (e.g., the registration tx-ID of the PII on the blockchain). Block 510 creates a JSON string 515 from the combined data 505, in one embodiment, though other types of data strings may be used in other embodiments. The Name/Value fields (e.g., key/value pairs) can be passed in any number of methods, such as a JavaScript Object Notation (JSON) data structure, name=value strings with a separator, or any other structural form that passes the data. The JSON string 515 may include a universal unique identifier (e.g., registration tx-ID that is generated by the client), a timestamp representing the time the record was created, and other data, in one embodiment. The JSON string 515 and a unique salt value 521 are combined (e.g., appended to, concatenated, added, etc.) and hashed using a hash algorithm 520 (e.g., SHA256) to generate a hashed value 525 (that includes the salt value). Thereafter the hashed value 525 is signed with the private key 531 of the certifying entity to generate a signed value 535. As previously described, the signed value may comprise or form part of a certification record 537 that may be stored to a blockchain).
Therefore, it would have been obvious to one of ordinarily skill in the art before the effective filing date of the claimed invention to combine the teachings of Ebrahimi to the blockchain of Harding and Cho and Ateniese and Bravick and Yamauchi to further comprising concatenating the plurality of entries together...to generate a string; hashing the string; and recording the hash on [a] blockchain.
One would have been motivated to combine the teachings Ebrahimi to Harding and Cho and Ateniese and Bravick and Yamauchi to do so as it provides / allows a record... [that is] obfuscated from discovery, such as through brute force, dictionary, and other discovery tactics on the signed data (Ebrahimi, [0089]).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to KARI L SCHMIDT whose telephone number is (571)270-1385. The examiner can normally be reached Monday-Friday 10am - 6pm (MDT).
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Luu Pham can be reached at (571)270-5002. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/KARI L SCHMIDT/Primary Examiner, Art Unit 2439