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 .
DETAILED ACTION
Claims 20 and 31 are amended. Claims 20 – 34 dated by 05/27/2026 are presently pending in the application and have been examined below.
Examiner Notes
Examiner cites particular paragraphs, columns and line numbers in the references as applied to the claims below for the convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant fully consider the references in entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the examiner.
Response to Arguments
Applicant's arguments in Arguments/Remarks filed on 05/27/2026 (hereafter Remarks) referring to the Office Action on 01/27/2026 (hereafter OA) have been fully considered but they are not persuasive.
Regarding rejection under 101 Applicant disputes the claim rejection in OA directed to non-statutory subject matter.
The instant application is a continuation of the application 17/403576 filed on 08/16/2021 now patent US 12063310 (hereafter Reference-paten-2 or RP2), which is a continuation of application 16/290590 filed on 03/01/2019 now patent US 11102008 (hereafter Reference-patent-1 or RP1). Applications related to RP1 and RP2 claimed the same inventive concepts; the application RP2 was allowed after filing terminal disclaimer. However, the instant application discloses new inventive concept based on the same SPECS. The new proposed concept discloses implementation of multi-step hashing within the distributed trusted ledger technology with respective hash-operations management to improve a method of digital data compression that should justify practical application requirement of MPEP. Applicant presented new arguments in support of patentability of the new proposed concept.
As a first argument Applicant stated that claims “do not recite to an ineligible judicial exception” but “merely involve an exception” that should make claims eligible for patenting.
Examiner respectfully disagrees. Referring to claim 20, the claim discloses the following operations:
generating … a first hash…; a second hash …; a third hash; (claim 20);
receiving … a domain query comprising a query hash… (claims 20, 31);
recording … the first hash … (claim 20);
sending … an indication … (claims 20, 31);
The above instructions disclose important steps of the proposed concept, i.e., claims obviously recite limitations disclosing generation and management of up to four hash values. The recited limitations represent mathematical operations on the system data which were identified in OA as abstract idea thus undergo judicial exception in step 2A prong 1 of the rejection under 35 U.S.C. 101. For a one with ordinary skills in the art is obvious that the recited mathematical operations may be performed by a human being using a standard computer equipped with known encryption package, in other word, disclosed is a mental process assisted by standard equipment. According to MPEP § 2106.04(a)(2), subsection III, where it examples a claim to "performing a mental process on a computer environment” as a Mental Process.
Second, on p. 7 of Remarks Applicant stated that “the combination of elements in the claim apply any associated abstract concepts in a meaningful way and are therefore eligible”. In support of this statement Applicant refers to para. [0007, 0078] of SPECS, indicating improvement of the IP-v6 protocol security by implementing the suggested multi-step hashing technology.
Examiner respectfully submits that the above disclosure is given in SPECS but not in claims. However, in OA the claim set is examined only, not the SPECS. Further, the above statement is obviously true. However, the multi-step hashing (or hash chain) method implemented for IP-v6 security improvement as disclosed by Applicant, is not original and is well-known for decades. For example, it is disclosed in details and in more general form by A. Broader, M. Mitzenmacher “Using Multiple Hash Functions to Improve IP Lookups”, IEEE, Infocom, 2001, that was used before in patent literature as a reference.
Regarding 112b issue, based on the amendment the rejection under 112b withdrawn.
Regarding rejection by Applicant of the reference of Novotny, as not a prior art due to the claimed priority, this reference is replaced by a new ground of rejection and another OA of non-final rejection is presented.
Based on the above the rejection under 35 U.S.C. 101 maintained and claims are rejected under 102.
Claim Rejections - 35 USC § 101, Nonstatutory
(Directed to a Judicial Exception without an Inventive Concept/Significantly More)
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
therefore, subject to the conditions and requirements of this title.
Claims 20 – 34 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Step 1 Statutory Category:
Independent claim 20 is directed to a computing device domains management method and independent claim 31 is directed to another computing domain management method. Therefore, claims 20 - 34 fall within the four statutory categories of invention, and thus must be further analyzed at Step 2A to determine if the claims are directed to a judicial exception (See MPEP 2106.03, subsection II).
Step 2A Prong 1 Judicial exception:
Limitations of independent claims 20 and 31 have been identified as elements or part of the abstract idea itself. The claims recite a series of steps instructing
generating … a first hash…; a second hash …; a third hash; (claim 20);
receiving … a domain query comprising a query hash… (claims 20, 31);
recording … the first hash … (claim 20);
sending … an indication … (claims 20, 31);
The above system steps appear to recite operations which may be performed by a human being. using a standard computer equipped with known encryption package using relevant cryptographic key. According to MPEP § 2106.04(a)(2), subsection III, where it examples a claim to "performing a mental process on a computer environment” as a Mental Process.
A human being may mentally perform data reception and/or data encryption, i.e., generation hashes, using a standard computer equipped with known encryption package comprising hashing functions as well as data recording and sending in a network using standard computing equipment. MPEP states that it is still a Mental Process if the action is aided by devices (emphases added).
Step 2A Prong 2 Integration into a practical application:
The following claim limitations are identified as additional elements not part of the abstract idea itself:
determining … that the query hash is the same value as the first hash recorded… (claim 20);
determining that the query hash is not recorded in a …ledger (claim 31);
The above recited claim limitations are interpreted as known computing actions providing merely well-documented extra-solution activity. The recited operations correspond to routine analysis of databases for existence and similarities of recorded elements or files within a computing system (see e.g., “Cryptography Engineering, Design Principles and Practical Applications” (copyright 2010) by Niels Ferguson, Bruce Schneier, and Tadayoshi Kohno). Although not explicitly recited, these additional limitations are interpreted as being implemented on a generic computing device or system. These limitations appear to recite general purpose computer machines which are merely implementing the abstract idea within a computer environment and merely displaying the results of the abstract idea using generic computing equipment for communication. See General purposes machine MPEP 2106.05(b)(I).
This judicial exception is not integrated into a practical application because the combination of data encryption and analysis for existence and similarities of recorded elements or files within a database without further details fails to integrate the judicial exception into a practical application.
Step 2B Significantly more: The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception.
The above identified claim limitations have been identified as General-Purpose Machine which are merely implementing the abstract idea within a computer environment. See MPEP 2106.05(b)(I). When taken individually or viewed as an ordered combination the claims as a whole do not appear to amount to significantly more (also known as an “inventive concept”) than the abstract idea.
Based on the above rational the claims have been deemed to ineligible subject matter under 35 USC 101.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that
form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless – (a)(2) the claimed invention was described in a
patent issued under section 151, or in an application for patent published or deemed
published under section 122(b), in which the patent or application, as the case may be, names
another inventor and was effectively filed before the effective filing date of the claimed
invention
Claims 20 – 34 are rejected under 35 U.S.C. 102(a) (2) as being anticipated by Davies (US 20200186355) (hereafter Davies).
As per claim 20 Davies discloses: A method of securely managing device domain associations, (Davies in para. [0099-0103] discloses a method of hash chain implementation for digital transactions management in a network)
the method comprising: generating, by a trusted domain management system, a first hash based on a second hash and a third hash, (Davies, in para. [0110, 0162] discloses Tereon electronic transaction processing engine using trusted management [0173] that may calculate a final hash value based on a previous one or two hash values [0291] as depicted in Fig. 5)
the second hash being generated based on a device address identifier associated with a device and a domain identifier associated with the device, (Davies, in para. [0036] and in Fig. 5 discloses processing of multiple hashes in the system, i.e., hash chain) the third hash being generated based on a public key associated with the device and the domain identifier (Davies, in para. [0103, 0120] discloses hash chain implementation for authentication purposes using Tereon authentication engine [0110], i.e., identification-based processing)
recording, by the trusted domain management system, the first hash in a first trusted ledger maintained by the trusted domain management system (Davies, in para. [0257] discloses a modular transaction system managing data records in several databases across multiple distributed ledgers [0266]);
receiving, by the trusted domain management system from a querying system, a domain query request relating to the device, (Davies, in para. [0011-0013] discloses reception of requests and management of respective data for processing),
the domain query request comprising a fourth hash; determining, by the trusted domain management system, that the fourth hash is the same value as the first hash recorded in the first trusted ledger (Davies, in para. [0029] discloses a comparative analysis of the generated hash values to determine a match); and sending, by the trusted domain management system to the querying system an indication that a value corresponding to the fourth hash is recorded in the first trusted ledger. (Davies, in para. [0015] discloses sending of respective communication withing the system).
As per claim 21 Davies discloses: The method of claim 20, wherein the first trusted ledger is a ledger instance of a trusted immutable distributed assertion ledger (Examiner note: the trusted immutable distributed assertion ledger, TIDAL, is disclosed by applicant in para [0023] of SPECS as a distributed ledger with trusted database managing various assertions, i.e., attributes, of different entities; this broad definition of the trust distributed ledger is met in Davies by the blockchain system comprising trusted instances, e.g., distributed hash or ledgers, Davies [0266]) (Davies, in para. [0257] discloses a modular transaction system managing data records in several databases across multiple distributed ledgers [0266])
As per claim 22 Davies discloses: The method of claim 20, wherein the method further comprises accessing, by the trusted domain management system, the second hash from a first trusted assertion management system (Davies, in para. [0013, 0036] discloses access control by respective processing servers to the hash chains, i.e., first, second etc. hashes).
As per claim 23 Davies discloses: The method of claim 22, wherein the second hash is recorded in a second ledger maintained by the first trusted assertion management system (Davies, in para. [0024] discloses recording of respective hash in relevant database)
As per claim 24 Davies discloses: The method of claim 20, wherein the second trusted ledger is a ledger instance of a trusted immutable distributed assertion ledger (Davies, in para. [0257] discloses a modular transaction system managing data records in several databases across multiple trusted distributed ledgers [0266])
As per claim 25 Davies discloses: The method of claim 20, wherein the method further comprises accessing, by the trusted domain management system, the third hash from a second trusted assertion management system (Davies, in para. [443] discloses operations in a system of multiple private, trusted distributed ledgers).
As per claim 26 Davies discloses: The method of claim 25, wherein the third hash is recorded in a third trusted ledger maintained by the second trusted assertion management system (Davies, in para. [0257] discloses a modular transaction system managing data records in several databases across multiple trusted distributed ledgers [0266]).
As per claim 27 Davies discloses: The method of claim 26, wherein the third trusted ledger is a ledger instance of a trusted immutable distributed assertion ledger (Davies, in para. [443] discloses operations in a system of multiple private, trusted distributed ledgers).
As per claim 28 Davies modified discloses: The method of claim 20, wherein the device address identifier comprises an Internet protocol address associated with the device (Davies, in para. [0111] discloses Tereon engine managing system interaction within specified Internet protocols)
As per claim 29 Davies modified discloses: The method of claim 20, wherein the domain identifier comprises a domain name (Davies, in para. [0120] and in Fig. 1 discloses modular concept of identifying and operating different functional domains).
As per claim 30 Davies modified discloses: The method of claim 20, wherein the domain query request is issued to the trusted domain management system by the querying system in response to a query to send a secure message to the device within a domain associated with the domain identifier (Davies, in para. [0120] and in Fig. 1 discloses modular concept of identifying and operating different functional domains).
As per claim 31 Davies discloses: A method of securely managing device domain associations (Davies in para. [0099-0103] discloses a method of hash chain implementation for digital transactions management in a network), the method comprising: receiving, by a trusted domain management system, a domain query associated with a device from a querying system (Davies, in para. [0120] and in Fig. 1 discloses modular concept of identifying and operating different functional domains),
the domain query comprising a first Davies, in para. [0029] discloses a comparative analysis of the recorded hash values to determine a match in ledger system);
in response to determining that the first second second Davies, in para. [0103, 0120] discloses hash chain implementation for authentication purposes using Tereon authentication engine [0110], i.e., identification-based processing),
and a second trusted ledger to determine whether the second trusted ledger comprises a third third Davies, in para. [0110, 0162] discloses Tereon electronic transaction processing engine using trusted management [0173] that may calculate a final hash value based on a previous one or two hash values [0291] as depicted in Fig. 5); generating, a domain query response to the domain query based on determining whether the first trusted ledger comprises the second Davies, in para. [0120] and in Fig. 1 discloses modular concept of identifying and operating different functional domains).
As per claims 32 – 34, claims 32 – 34 encompass same or similar scope as claims 28 – 30, respectively. Therefore, claims 32 – 34 are rejected based on the same reasons set forth above in rejecting claim 28 – 30.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure: A. Broader, M. Mitzenmacher “Using Multiple Hash Functions to Improve IP Lookups”, IEEE, Infocom, 2001.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to VLADIMIR IVANOVICH GAVRILENKO whose telephone number is (313)446-6530. The examiner can normally be reached on Monday-Friday 7:30-4:30 EST.
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, Lynn Feild can be reached on (571) 272-2092. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see https://ppair-my.uspto.gov/pair/PrivatePair. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/VLADIMIR I GAVRILENKO/Examiner, Art Unit 2431
Prosecution Insights