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 .
Election/Restrictions
Applicant’s election without traverse of Species I (claims 2–7 and 14–19) in the reply filed on August 5th, 2026 is acknowledged. The application has pending claims 1–20 (withdrawn claims 8–12 are withdrawn from further consideration).
Priority
Acknowledgment is made of applicant’s claim for foreign priority under 35 U.S.C. 119 (a)-(d). The certified copy has been filed in parent Application No. 18/908552, filed on 10/16/2023. A translation of said application has not been made of record, an English language translation of a non-English language foreign application is NOT yet required at the time of this Office Action.
Claim Objections
Claims 13 and 20 are objected to because of the following informalities:
Independent claims 13 and 20: change the first occurrence of “the first filter” to “a first filter” and “the iris feature library” to “an iris feature library”.
Independent claim 20: change the first occurrence of “the one or more processors” to “one or more processors”.
Appropriate correction is required.
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1–2, 5–6, 13–14, 17–18, and 20 are rejected under 35 U.S.C. §103 as being unpatentable over Locketz (Locketz et al, US 2020/0396061 A1, 2020), in view of Rathgeb ( Rathgeb, C., Breitinger, F., Busch, C., & Baier, H. (2014). On application of bloom filters to iris biometrics. IET Biometrics, 3(4), 207–218.), further in view of Chen ( Chen, T., Guo, D., He, Y., Chen, H., Liu, X., & Luo, X. (2013). A Bloom filters based dissemination protocol in wireless sensor networks. Ad Hoc Networks, 11(4), 1359–1371).
Regarding claim 1, Locketz teaches
A feature synchronization method, performed by a computer device provided with a first filter and an identification feature library, the method comprising:
( Locketz > [0042–0043], [0120], [Figs. 1 and 7]: The database stores identifying attributes, corresponding to the identification feature library, and the system maintains the Bloom-filter data structure. )
receiving a feature synchronization request, the feature synchronization request carrying an identification feature and identifying the request sender by use of the identification feature;
( Locketz > [0046] and [0070]: The update request supplies identification information. )
determining, through the first filter based on the identification feature contained in the request, a first numerical position corresponding to the feature synchronization request in the first filter, a numerical value at the first numerical position representing whether the identification feature has an updated version in the identification feature library;
( Locketz >[0043], [0046], [0071–0072]: Identification information is hashed to determine filter positions. Checking the stored filter values indicates probable update availability for the request sender. )
accessing the identification feature library through the first filter when the numerical value at the first numerical position represents that the updated version of the identification feature exists in the identification feature library, and obtaining the updated version of the identification feature through the identification feature library; and
( Locketz > [0047–0048], [0073–0074], [Figs. 1 and 4]: A qualifying filter result leads to database confirmation and retrieval of the associated update from the update service. )
delivering the updated version of the identification feature to a request sender of the feature synchronization request for the request sender to store the updated version of the identification feature.
( Locketz > [0039], [0075], [Fig. 4, block 414]: The request sender receives and installs the software or firmware update in memory. )
Locketz does not expressly teach that the identification feature is an iris feature, or that the feature library is an iris feature library. Rathgeb teaches iris-feature vectors and their storage in biometric databases:
A feature synchronization method, performed by a computer device provided with a first filter and an iris feature library
( Rathgeb > [§3.1, p. 209], [Eq. (1) and Fig. 1], [§4.5, p. 215]: Iris-code feature vectors are mapped into adaptive Bloom filters, and Fig. 1 depicts storage of the resulting templates in a database. Identification is performed on a 2.30 GHz computer system with enrolled iris codes loaded for comparison, corresponding to the computer, filter, and iris feature library. )
It would have been obvious to a person of ordinary skill in the art, before the effective filing date of the claimed invention, to apply Locketz’s filtered synchronization process to stored iris-feature records of the type taught by Rathgeb, using iris-feature information to determine filter positions. Such modification would permit screening requests before accessing the iris-feature library, reducing unnecessary library accesses.
Locketz [as modified by Rathgeb] does not expressly establish the claimed use of a first version number of the iris feature in determining the filter position. Chen teaches associating a data item with an identifying key and a version number, representing those metadata pairs in a Bloom filter, and querying the filter using the metadata:
A data synchronization method, performed by a computer device provided with a filter which associating a data item with an identifying key and a version number: the first version number and the updated version.
( Chen > [§3, p.595], [§4.2, p.596], [§4.4, pp.596–597], [Algorithms 1–2]: Each data item has metadata (key, ver), with an unchanged identifying key and a version number incremented when the item’s content is updated. Bloom filters represent these metadata tuples and support membership queries used to identify version differences. Upon receiving newer data, a node updates its older local data item. )
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to further modify Locketz [as modified by Rathgeb]’s iris-feature synchronization process, to use the request sender’s version number together with the iris-feature information in determining filter positions, applying Chen’s teaching of identifying-key/ version metadata queries, in order to distinguish copies requiring an update before accessing the iris feature library. Such a modification would have predictably applied Chen’s known version-sensitive filtering technique to Locketz’s update-screening framework by representing feature/ version pairs for which newer features are available, thereby reducing unnecessary library accesses and redundant update transmissions while retaining Locketz’s confirmation, retrieval, and delivery of available updates.
Regarding claim 2, Locketz [as modified by Rathgeb and Chen] teaches the method according to claim 1, wherein determining the first numerical position corresponding to the feature synchronization request in the first filter comprises:
performing calculation based on the iris feature, the first version number, and a hash function of the first filter, to determine a first hash value and a second hash value that correspond to the feature synchronization request; and
( Locketz > [0043], [0072]; Rathgeb > [§3.1, p.209, Eq.(1), Fig.1]; Chen > [§3, p.595, and §4.2, p.596]: Locketz permits multiple hash functions; Rathgeb maps iris-feature information to filter positions; and Chen represents identifying-key/ version metadata in a Bloom filter. In the proposed combination, two hash functions process the iris-feature/ version input to produce the first and second hash values. )
determining, based on a first numerical set of the first filter, a second numerical position corresponding to the first hash value in the first numerical set and a third numerical position corresponding to the second hash value in the first numerical set.
( Locketz > [0043]; Chen > [§2.2, p.594]: Hash outputs select positions within a common filter array, corresponding to the first numerical set. The first output selects the second numerical position, and the second output selects the third numerical position. )
Regarding claim 3, Locketz [as modified by Rathgeb and Chen] teaches the method according to claim 2, wherein performing the calculation to determine the first hash value and the second hash value that correspond to the feature synchronization request comprises:
performing calculation on the iris feature and the first version number by using k hash functions of the first filter, to determine k first hash values corresponding to the feature synchronization request; and
( Locketz > [0043], [0072]; Rathgeb > [§3.1, p. 209, Eq. (1)]; Chen > [§2.2, p. 594, §3, p. 595, and §4.2, p. 596]: Locketz applies multiple hash functions to identifying information to determine filter positions. Rathgeb supplies iris-feature representations and their mapping to Bloom-filter positions. Chen represents identifying-key/ version metadata in a Bloom filter using k hash functions. In the Locketz [as modified by Rathgeb and Chen]’s system, applying these k hash functions to the received iris feature together with its first version number produces the k first hash values. )
determining a second version number of the updated version based on the first version number, and performing calculation on the iris feature and the second version number by using the k hash functions of the first filter, to determine k second hash values corresponding to the feature synchronization request, wherein
k is an integer greater than 0.
( Chen > [§3, p. 595, §2.2, p. 594, and §4.2, p. 596]; Locketz > [0043], [0072]: Chen increments an item’s version number by one when its content is updated and represents identifying-key/version metadata using k hash functions. In the Locketz [as modified by Rathgeb and Chen]’s system, applying this increment determines the second version number from the first version number, and applying the same k hash functions to the iris feature together with that second version number produces the k second hash values. Locketz expressly exemplifies five hash functions, satisfying k being an integer greater than zero. )
Regarding claim 4, Locketz [as modified by Rathgeb, Chen and Rubin] teaches the method according to claim 3, wherein determining the second version number of the updated version based on the first version number comprises:
obtaining a version-number interval configured for updating a version number, superimposing the version-number interval and the first version number, and determining the second version number of the updated version.
( Chen > [§3, p. 595]: Chen specifies that an item’s version number increases by one when its content is updated. In the Locketz [as modified by Rathgeb and Chen]’s system, implementing this prescribed increment supplies the configured interval of one as the addition operand and adds that interval to the received first version number, thereby determining the second version number as the first version number plus one. )
Regarding claim 5, Locketz [as modified by Rathgeb and Chen] teaches the method according to claim 2, wherein determining, based on the first numerical set of the first filter, the second numerical position corresponding to the first hash value in the first numerical set and the third numerical position corresponding to the second hash value in the first numerical set comprises:
( Locketz > [0043], [0072]: Locketz permits any number of hash functions. The proposed implementation uses two total hash functions, with k = 1 in each claimed group, operating on the same filter array. )
determining k numerical positions corresponding to the k first hash values in the first numerical set of the first filter as the second numerical positions; and
( Locketz > [0043]: For k = 1, the first hash output selects one array position, corresponding to the claimed second numerical position. )
determining k numerical positions corresponding to the k second hash values in the first numerical set of the first filter as the third numerical positions.
( Locketz > [0043]: For k = 1, the second hash output selects one position in the same array, corresponding to the claimed third numerical position. )
Regarding claim 6, Locketz [as modified by Rathgeb and Chen] teaches the method according to claim 2, further comprising:
determining that the iris feature has the updated version in the iris feature library when a numerical value at the second numerical position in the first filter is a preset value and a numerical value at the third numerical position is the preset value.
( Chen > [§2.2, p.594]; Locketz > [0043], [0071–0074]: Chen checks all hash-selected bits for the value 1. With two hash functions, both identified positions must equal that preset value. Under the proposed claim-1 update-eligibility arrangement, this positive result indicates probable availability of an updated iris feature, followed by Locketz’s backend confirmation and retrieval. )
Regarding claims 13–18, and 20, the rationale provided for claims 1–2 and 5–6 over Locketz [as modified by Rathgeb and Chen] is incorporated herein. Further, the methods of claims 1–2 and 5–6 correspond respectively to the computer devices of claims 13–18, and the method of claim 1 corresponds to the non-transitory computer-readable storage medium of claim 20 ( Locketz > [0111–0115], [Fig.7]: Locketz teaches a computing system comprising one or more processors and memory, including non-transitory computer-readable media storing instructions that, when executed, cause the processors to perform the disclosed update-processing methods. ).
Claims 7, and 19 are rejected under 35 U.S.C. §103 as being unpatentable over Locketz [as modified by Rathgeb and Chen], in view of Legler (Legler et al, US 2020/0311139 A1, 2020).
Regarding claim 7, Locketz [as modified by Rathgeb and Chen] teaches the method according to claim 2, further comprising:
However, Locketz [as modified by Rathgeb and Chen] does not expressly teach the recited library access, storage, and filter-update sequence when the numerical value at the second numerical position is not the preset value. Legler teaches:
accessing the iris feature library through the first filter when a numerical value at the second numerical position in the first filter is not a preset value;
( Legler > [0030], [0032], [0043]: Legler determines that a value is absent when any corresponding filter bit remains zero and accesses the database to store that value following the negative result. Applied to the Locketz [as modified by Rathgeb, Chen and Legler], zero at the second numerical position differs from the preset value of one and triggers access to the iris feature library. )
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to further modify Locketz [as modified by Rathgeb and Chen]’s synchronization process, to store an incoming iris-feature/version record when a corresponding filter bit remains absent/ zero and then set the corresponding filter bits to one, as taught by Legler, in order to register unrepresented records without a redundant database existence search. Such a modification would predictably keep the filter consistent with the stored records for subsequent requests.
Locketz [as modified by Rathgeb, Chen and Legler] continue to teach:
storing the iris feature and the first version number by using the iris feature library; and
( Legler >[0030]; Rathgeb > [§3.1, p. 209, Fig. 1]; Chen > [§3, p. 595, and §4.2, p. 596]: Legler stores an absent value in the database. Rathgeb supplies stored iris-feature representations, and Chen associates data items with version metadata. In the proposed combination, Legler’s conditional insertion stores the received iris feature together with its first version number in the iris feature library. )
setting a numerical value at the third numerical position in the first filter to the preset value based on the iris feature library.
( Legler > [0033], [0043]: Following database storage, Legler sets the corresponding filter bits to 1, including the mapped third numerical position. This is the same preset value of 1 used above. )
Regarding claim 19, the rationale provided for claim 7 over Locketz [as modified by Rathgeb, Chen and Legler] is incorporated herein. Further, the methods of claim 7 corresponds to the computer devices of claim 19 ( Locketz > [0111–0115], [Fig.7]: Locketz teaches a computing system comprising one or more processors and memory, including non-transitory computer-readable media storing instructions that, when executed, cause the processors to perform the disclosed update-processing methods. ).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to KEN KUDO whose telephone number is (571)272-4498. The examiner can normally be reached M-F 8am - 5pm.
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, Vincent Rudolph can be reached at 571-272-8243. 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.
KEN KUDO
Examiner
Art Unit 2671
/KEN KUDO/Examiner, Art Unit 2671
/VINCENT RUDOLPH/Supervisory Patent Examiner, Art Unit 2671
Prosecution Insights