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 .
Status of Claims
Claims 1-4, 6-11, 13-18 and 20-23 are pending in this instant application per remarks and claim amendments filed on 01/28/2026 by Applicant, wherein only Claims 1, 7-8, 11 & 15 have been amended, while Claims 5, 12 & 19 are shown as Cancelled. Claims 1, 8 and 15 are independent claims reciting system, method and non-transitory computer-readable medium claims. Claims 2-4/6-7/23, 9-11/13-14/21 and 16-18/20/22 are respective dependent claims.
This Office Action (OA) is a final rejection in response to the claim amendments and remarks filed by the Applicant on 28 JANUARY 2026 for its original application of 06 JUNE 2023 that is titled: “Decentralized and Anonymized Verification of User Characteristics”.
Accordingly, amended Claims 1-4, 6-11, 13-18 and 20-23 are now being rejected herein.
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.
(NOTE: Latest ‘amendments to the claims’ filed by the Applicant on 01/28/2026 are shown as bold and underlined additions, and all deletions may not be shown. Examiner notes that previously added New Claims 21 and 22 are shown as underlined as they were not rejected fully in the last Non-Final OA of 06/18/2025).
Claims 1-4, 6-11, 13-18 and 20-23 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (abstract idea) without significantly more, wherein Claims 1, 8 and 15 are independent payment system, method and non-transitory computer-readable medium claims respectively.
Exemplary Analysis.
Claim 8: Ineligible.
The claim recites a series of steps. The claim is directed to a method reciting a series of steps, which is a statutory category of invention (Step 1 -- YES).
The claim is analyzed to determine whether it is directed to a judicial exception. The claim recites the limitations of: receiving a first request to verify a characteristic of a user, the first request comprising personally identifying information (PIl) associated with the user; sending a second request for one or more attributes of the user, wherein the second request comprises at least a portion of the PII associated with the user; receiving the one or more attributes of the user; anonymizing the one or more attributes of the user to generate one or more anonymized attributes; and sending a third request to a verifier service, wherein the PII associated with the user is not disclosed to the verifier service and wherein the third request comprises the one or more anonymized attributes and a prompt. In other words, the claim describes approaches for verifying user characteristics in a decentralized and anonymized fashion (per Abstract). These limitations, as drafted, are steps of a method that, under its broadest reasonable interpretation, covers performance of the limitations via a method of organizing human activity such as fundamental economic principles or practices (including hedging, insurance, mitigating risk), and/or commercial or legal interactions (including agreements in the form of contracts; legal obligations; advertising, marketing or sales activities or behaviors; business relations), and/or managing behavior or relationships or interactions between people (including social activities, teaching, and following rules or instructions), but for the recitation of generic computer/s and/or computer component/s such as the devices/ mobile devices. These limitations fall under the “certain methods of organizing human activity” group (Step 2A1--YES).
Next, the claim is analyzed to determine if it is integrated into a practical application. The claim recites additional elements of: a computing device, a client device, an attribute service and a verifier service, recited as sending a prompt to a verifier service, wherein the prompt causes a large language model associated the verifier service to verify the characteristic of the user based at least in part on the one or more anonymized attributes[[; receiving, from the verifier service, a verification of the characteristic; and returning the verification of the characteristic to a smart contract. These additional elements are considered extra-solution activities. The multiple devices, large language model and smart contract in the steps are recited at a high level of generality, i.e., as generic processors performing generic computer/s functions of processing data. These generic processors are no more than mere instructions to the multiple devices to apply the exception using generic computer/s and/or computer component/s. 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. Thus, the claim is directed to the abstract idea (Step 2A2 -- NO).
Next, the claim is analyzed to determine if there are additional elements in this claim that individually, or as an ordered combination, ensure that the claim amounts to significantly more than the abstract ideas (whether claim provides inventive concept). As discussed with respect to Step 2A2 above, the additional elements in the claim amount to no more than mere instructions to apply the exception using generic computer/s and/or computer component/s. The same analysis applies here in Step 2B, i.e., mere instructions to apply an exception using a generic computer and/or computer components over a network cannot integrate a judicial exception into a practical application at Step 2A or provide an inventive concept in Step 2B. Because the additional elements of: a computing device, a client device, an attribute service and a verifier service, plus a large language model and a smart contract, were considered to be extra-solution activities in Step 2A, they are re-evaluated in Step 2B to determine if they are more than what is well-understood, routine and conventional in the field. The disclosure does not provide any indication that these devices (processors) are anything other than generic processors and the Symantec, TLI, and OIP Techs. court decisions (MPEP 2106.05 (d) (II)) indicate that mere collection or receipt of data over a network is a well‐understood, routine, and conventional function when it is claimed in a merely generic manner (as it is here). Also, paras [0011]-[0015] of the Applicant’s own Specification that was published on 12/12/2024 as Pub. No. US 2024/ 0412215 describe their application’s details as ---
{“[0011] The evaluation computing environment 103, a verifier computing environment 106, an attribute computing environment 109, and/or a service provider computing environment 113 can include one or more computing devices that include a processor, a memory, and/or a network interface. For example, the computing devices can be configured to perform computations on behalf of other computing devices or applications. As another example, such computing devices can host and/or provide content to other computing devices in response to requests for content. ……………………………………………………………………………………………………….
[0012] Moreover, the evaluation computing environment 103, the verifier computing environment 106, the attribute computing environment 109, and/or the service provider computing environment 113 can employ a plurality of computing devices that can be arranged in one or more server banks or computer banks or other arrangements. Such computing devices can be located in a single installation or can be distributed among many different geographical locations. For example, the evaluation computing environment 103, the verifier computing environment 106, the attribute computing environment 109, and/or the service provider computing environment 113 can include a plurality of computing devices that together can include a hosted computing resource, a grid computing resource or any other distributed computing arrangement. In some cases, the evaluation computing environment 103, the verifier computing environment 106, the attribute computing environment 109, and/or the service provider computing environment 113 can correspond to an elastic computing resource where the allotted capacity of processing, network, storage, or other computing-related resources can vary over time. …………………………………………………………………………………………
[0013] Various applications or other functionality can be executed in the evaluation computing environment 103, the verifier computing environment 106, the attribute computing environment 109, and/or the service provider computing environment 113. The components executed by the evaluation computing environment 103, the verifier computing environment 106, the attribute computing environment 109, and/or the service provider computing environment 113 include an evaluation service 126, a verifier service 129, an attribute service 133, a service provider service 136 and other applications, services, processes, systems, engines, or functionality not discussed in detail herein. …………………………………………………………
[0014] The evaluation service 126 can be executed to evaluate a request to assess a characteristic of a user associated with the client device 119. For example, the evaluation service 126 could receive a request to evaluate a characteristic of a user (e.g., his or her creditworthiness, his or her identity, etc.). The evaluation service 126 could then retrieve one or more attributes (e.g., credit report, financial history, identity information, etc.) from the attribute service 133 and anonymize them. The evaluation service 126 could then provide the attributes to the verifier service 129 along with a prompt or request for the verifier service 129 to verify the characteristic of the user based at least in part on the attributes. In some implementations, the evaluation service 126 or portions of the evaluation service 126 could be executed by a trusted execution environment (TEE) or other secure area or secure enclave provided by a processor of the computing device that is executing or hosting the evaluation service 126. …………………………………………………………………………………………………………………….
[0015] The verifier service 129 can be executed to verify one or more characteristics of the user associated with the client device 119 based at least in part on one or more attributes provided by the attribute service to the evaluation service 126. In some implementations, the verifier service 129 could act as a front-end for a large language model 139.”} ---
and indicate that the concept described by the extra-solution additional elements is conventional. Accordingly, a conclusion that the aforementioned extra-solution additional elements are well-understood, routine and conventional activity is supported under Berkheimer options 2 and 3, respectively.
Viewing the limitations as an ordered combination does not add anything further than looking at the limitations individually. When viewed either individually, or as an ordered combination, the additional elements do not amount to a claim as a whole that is significantly more than the abstract idea itself. Therefore, the claim does not amount to significantly more than the recited abstract idea (Step 2B -- NO), and the claim is not patent eligible.
The analysis above applies to all statutory categories of the invention including independent system Claim 1 and independent non-transitory computer-readable medium Claim 15, which perform the steps similar to those of the independent method Claim 8. Furthermore, the limitations of dependent method Claims 9-11/13-14/21, further narrow the independent method Claim 8 with additional steps and limitations (e.g., verifying the first request with the smart contract; verifying a signature of the first request; applying a machine learning model to the one or more attributes to identify PII within the one or more attributes; creating a non-fungible token and updating its status; wherein the verification of the characteristic is represented by the smart contract as a non-fungible token (NFT) on a blockchain, etc.), and do not resolve the issues raised in rejection of the independent method Claim 8. Similarly, dependent system Claims 2-7 and dependent non-transitory computer-readable medium Claims 16-18/20/22 also further narrow their independent Claims 1 and 15 respectively, which are rejected as ineligible for patenting under 35 U.S.C. 101 based upon the same analysis.
Therefore, said Claims 1-11, 13-18 and 20-22 are 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 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 set forth in Graham v. John Deere Co., 383 U.S. 1,148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
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-11, 13-18 and 20-22 are rejected under 35 USC 103 as unpatentable over a combination of references (LaFever and Dawson for all claims, plus Mullen for some dependent claims) as described below for each claim/ limitation.
Independent Claim 8 is rejected under 35 USC 103 as unpatentable over Pub. No. US 2023/ 0054446 filed by LaFever et al. (hereinafter “LaFever”) in view of Pub. No. US 2021/ 0312441 filed by Dawson, V et al. (hereinafter “Dawson”), and as described below for each claim/ limitation.
Examiner notes that all claims have been copied as recited by the Applicant to keep them readable and whole, even if the limitations within a claim that are not taught explicitly by the primary/previous reference (are noted in parentheses), but these limitations are noted explicitly as taught by a secondary/new reference whenever a secondary/new reference has been used.
Examiner notes that, for brevity in this rejection, the motivation statement has not been repeated herein every time a secondary reference has been used.
With respect to Claim 8, LaFever teaches ---
8. A method performed by a computing device, comprising:
receiving a first request from a client device to verify a characteristic of a user associated with the client device, the request identifying an attribute service and the request comprising personally identifying information (PIl) associated with the user of the client device;
(see at least: LaFever Abstract and Summary in paras [0019]-[0091]; and para [0050] about {“In one example, a verification module of the privacy server and associated database(s) may provide an authenticated data structure that permits validation and verification of the integrity of information and/or DDIDs embodied in an aggregated data profile, data attributes, attribute combinations and/or TDRs at any point in time through methodologies such as cyclic redundancy checks (“CRCs”), message authentication codes, digital watermarking, linking-based time-stamping or analogous methodologies.”}; and para [0082] about {“...... In another example, the privacy server may include a verification module that verifies the integrity of data attributes, attribute combinations, and DDIDs.”}; and para [0137] about {“FIG. 8 illustrates an example of a process for verifying authority, in accordance with one embodiment of the invention.”}; and para [0363] about {“A verification module 55 that may include validating and verifying the integrity of aggregated data profiles including data attributes, attribute combinations, DDIDs, and TDRs at any point in time.”}; and para [0743] about {“......Such manual override may occur for instance by means of a graphical user interface of a privacy client running on a Data Subject's mobile device. For instance, a Data Subject may use the graphical user interface to override the request for information pertaining to the Data Subject's preferred means of air travel by coach, business class or first class because in one example the Data Subject may be traveling by cruise ship and therefore the Data Subject may desire to specify whether he/she wants a suite, balcony stateroom, outside stateroom, or inside stateroom as attributes. …”}; and para [0843] about {“… In order to protect the privacy/anonymity of sensitive PII/PHI information, output from the registration process may replace PII/PHI user information [A] with TDRs (comprised of dynamically changing and re-assignable DDIDs and the PII/PHI information) without revealing the PII/PHI information so sensitive PII/PHI data is not exposed. This user data (including TDRs in lieu of PII/PHI information) would then be used as input to create, augment or alter the user data file at D1 without revealing PII/PHI information [B]. …………… PII/PHI user information components of output resulting from the step 4.0 user profile search process may be replaced with TDRs (comprised of dynamically changing and re-assignable DDIDs and the PII/PHI information) without revealing the PII/PHI information so sensitive PII/PHI data is not exposed. Lastly, user data at D1 (including TDRs in lieu of PII/PHI information) can be used as input to the step 5.0 reservation record browse process without revealing PII/PHI information by means of access to and use of the temporally unique and purpose limited TDRs only. When access to detailed information from the user data file and/or clinical data file is required for authorized healthcare or ancillary service purposes, association keys (AKs) and/or replacement keys (RKs) may be used to discern the relevant sensitive PII/PHI data associated with applicable TDRs and DDIDs.”}; and para [0924] about {“Example 67 is a non-transitory computer readable medium comprising computer executable instructions stored thereon to cause one or more processing units to: request, over a network, a first temporally unique identifier from a first privacy server; associate the first temporally unique identifier with a first data subject that is a user of a first client device; associate one or more data attributes with the first temporally unique identifier; generate first time period data, wherein the first time period data comprises information defining a first time period during which the first temporally unique identifier may be used to identify the first data subject and retrieve the associated one or more data attributes; store, in a memory of the first client device, the first temporally unique identifier, the one or more data attributes, and the first time period data; and send, in response to a determination that a first condition has been met, the first temporally unique identifier, the first time period data, and the one or more data attributes over the network to the first privacy server.”}; which together are the same as claimed limitations above to include ‘a computing device’, ‘a first request’, ‘a client device’, ‘verify a characteristic’, ‘a/ the user’, ‘personally identifying information (PII)’; as well as paras [0141]--[0143] for claimed ‘an/ the attribute service’)
LaFever teaches ---
sending a second request for one or more attributes of the user to the attribute service, wherein the second request comprises at least a portion of the PII associated with the user of the client device;
(see at least: LaFever ibidem and citations listed above to include ‘request’, ‘a/ the user’, ‘attributes’ and ‘an/ the attribute service’, ‘PII/PHI’, and ‘the client device’; and paras [0861], [0872] and [0883] for the claimed ‘second request’)
LaFever teaches ---
receiving the one or more attributes of the user from the attribute service;
(see at least: LaFever ibidem and citations listed above to include ‘attributes’ and ‘a/the attribute
service’, and ‘a/ the user’)
LaFever teaches ---
anonymizing the one or more attributes of the user to generate one or more anonymized attributes; and
(see at least: LaFever ibidem and citations listed above to include ‘attributes’ and ‘an/ the attribute service’ and ‘a/ the user’; and para [0045] about {“…… The privacy, anonymity and security of data attributes contained or referenced within a TDR may be further improved or enhanced by means of a replacement function, e.g., by replacing one or more of said data attributes contained in one or more TDRs with DDIDs so that access to and use of one or more RKs are necessary to enable use of look-up tables to determine the value of the one or more data elements replaced by said one or more DDIDs. The privacy, anonymity and security of data attributes contained or referenced within a TDR may be further improved or enhanced by using other known protection techniques, such as encrypting, tokenizing, pseudonymizing, eliding and/ or otherwise; and/or by introducing additional layers of abstraction by replacing keys with second-level or n-level DDIDs.”}; and para [0046] about {“…… the effective level of privacy, anonymity and security may be enhanced based on how, and how often, the DDIDs associated with the data attribute or attributes in question are changed and/or are changeable.…”}; and para [0049] about {“…… Thus, the system provides for secure data exchange and non-repudiation of data attributes, attribute combinations and TDRs in order to foster safer data-related collection, use, research and/or analysis while meeting stringent privacy, anonymity and security criteria.”}; and para [0134] about {“FIG. 6A shows an example of a process (from a sample controlling entity and system perspective) to receive attributes from one or more external database, generate TDRs to abstract or anonymize the data, and then re-associate or de-anonymize the data, in accordance with one embodiment of the invention.”}; and para [0238] about {“Dynamic Anonymity may define the following different kinds of data to be protected: (i) primary keys which refer to Data Subjects, actions, activities, processes and/or traits (e.g. employee ID), (ii) attribute data associated with, but not unique to, Data Subjects, actions, activities, processes and/or traits (e.g. employee postal code), and (iii) the indication of a disassociated (obscured) data element's type, itself (an “association key”, or “A_K”).”}; and para [0484] about {“…… Finally, in Step (4), the score/rating calculated in Step (3) above may be used to specify the level of consent/involvement required by the Data Subject to which the anonymized data attributes pertain versus what level of discretion/use a third party may exercise with regard to the anonymized data attributes without requiring consent/involvement by the Data Subject, such as is shown in the example AMS usage reflected in FIG. 1K below.”}; and para [0791] about {“At step 5, in one example, the privacy client then transmits data pertaining to online sessions and offline activity associated with attribute combinations and DDIDs in disaggregated and anonymized format to the privacy server.”}; which together are the same as claimed limitations above to include ‘anonymizing the one or more attributes’ and ‘generate one or more anonymized attributes’)
LaFever teaches ---
sending a third request to a verifier service, wherein the PII (associated with the user is not disclosed to the verifier service) and wherein the third request comprises the one or more anonymized attributes and a prompt, wherein the prompt causes (a large language model) associated with the verifier service to verify the characteristic of the user based at least in part on the one or more anonymized attributes[[;
(see at least: LaFever ibidem and citations listed above to include ‘attributes’ and ‘an/ the attribute service’, ‘a/ the user’, ‘anonymizing the one or more attributes’ and ‘generate one or more anonymized attributes’ and ‘PII/PHI’; and para [0050] about {“In one example, a verification module of the privacy server and associated database(s) may provide an authenticated data structure that permits validation and verification of the integrity of information and/or DDIDs embodied in an aggregated data profile, data attributes, attribute combinations and/or TDRs at any point in time through methodologies such as cyclic redundancy checks (“CRCs”),…”}; and paras [0082] and [0412] about {“.....In another example, the privacy server may include a verification module that verifies the integrity of data attributes, attribute combinations, and DDIDs.…”}; and para [0171] about {“……… Dynamic Anonymity overcomes these shortcomings by employing dynamically changing and re-assignable DDIDs, storing the resulting DDID associations and obscuring keys within Circles of Trust, and providing a unique interaction model enabling participation between and among Data Subjects and Trusted Parties/third-party participants.”}; and paras [0179]--[0182] about {“[0179] However, Dynamic Anonymity improves upon these prior approaches by: [0180] Employing dynamically changing and re-assignable DDIDs to obscure data at the data element (versus data record) level; [0181] Storing resulting DDID associations/obscuring keys within a Circles of Trust; and [0182] Providing a unique interaction model for enabling participation between and among Data Subjects and Trusted Parties/third-party participants.”}; and para [0736] about {“In one example implementation of the system, both Example 1 and Example 2 in FIG. 5 may represent an authenticated data structure that permits the verification module of the privacy server to validate and verify attribute combinations and DDIDs embodied in a TDR and/or data profile at any point in time by method-ologies such as cyclic redundancy checks (“CRCs”), …”}; AND [0802] about {“…… In step 5, if verification is obtained, the authentication module of the privacy server may transmit the authorization status information via the privacy client and in step 6 the authorization status may be used to allow or deny the request for the Data Subject to participate in the explorative study and step 7 would provide access to AK and/or RK key information necessary to interpret TDR content and proceed.”}; and para [0805] about {“In a second example of FIG. 8, in step 1 a physician receiving an encrypted, tokenized or elided TDR containing requested blood pressure information may be required to send a TDR to the authentication module of the privacy server via a privacy client to verify that the physician is authorized to view the requested information. …… If the authentication module of the privacy server verifies that the physician's TDR information matches authorized recipient attribute combinations, …”}; which together are the same as claimed limitations above to include ‘a/the verifier service’ and ‘verify the characteristic’ aka ‘verification of the data attribute/s’; AND ‘a third request to a verifier service’ and ‘a prompt’)
Examiner notes that LaFever teaches about multiple requests – first, second, etc. and that claimed ‘a third request’ is taught by the LaFever reference.
LaFever teaches as disclosed above to include a verifier service and a unique interaction model for enabling participation between and among Data Subjects and Trusted Parties/third-party participants in paras [0171] & [0182], but it may not explicitly disclose about ‘associated with the user is not disclosed to the verifier service’. However, Dawson teaches them explicitly.
(see at least: Dawson Abstract and Summary in paras [0005]-[0007]; and para [0017] about {“The communication environment 100 includes a network 110, an enterprise 120 associated with a client device 130, an enterprise 121 associated with a user device 140, a user device 141, a third-party service system 150, and the context-based verification system 160. As referred to herein, the term “client device” refers to a computing device used by a member of an enterprise receiving identity verification service from the verification system 160 and the term “user device” refers to a computing device used to request an interaction with an enterprise. Likewise, the term “client” refers to a recipient of the services of the verification system 160 and the term “user” refers to a recipient of the services of a client. In alternative configurations, different and/or additional components may be included in the communication environment 100. For example, a database may be communicatively coupled to the context-based verification system 160 such that verification credentials used by the verification system 160 are not necessarily stored locally. …”}; which together are the same as claimed limitations above to include ‘associated with the user is not disclosed to the verifier service’)
It would have been obvious prior to the time of the effective filing date of the claimed invention to have an ordinary person of skill in the art to modify the teachings of LaFever with the teachings of Dawson. The motivation to combine these references would be to provide systems, methods and devices that overcome the limitations of static and/or persistent privacy/anonymity and security systems and improve the accuracy of data for exchange, collection, transactions, analysis and other uses (see para [0018] of LaFever), and to permit users making purchases on website in which digital identification using passwords may be a security policy necessary for making a purchase, the same security policy may not apply to browsing products (see para [0004] of Dawson).
LaFever and Dawson teach ---
receiving, from the verifier service, a verification of the characteristic; and
returning the verification of the characteristic to a smart contract.
(see at least: LaFever ibidem and citations listed above to include ‘attributes’ and ‘an/ the attribute service’, ‘a/ the user’, ‘generate one or more anonymized attributes’, and ‘a/the verifier service’ and ‘verify the characteristic’ aka ‘verification of the data attribute/s’; and paras [0020], [0623]-[0624] and [0635]-[0636] for ‘smart contract’ and ‘smart contracts’ that at least includes paras [0623]-[0624] about {“With DLT (==Distributed Ledger Technologies), there is typically no central administrator or centralized data storage. Examples of the use of DLTs include: blockchains, cryptocurrencies, smart contracts, and even decentralized file storage. ………… While blockchains are best known for their use in enabling cryptocurrencies and cryptocurrency transactions, they have a broad range of other applications, such as in storing medical data, supply chain management, financial transaction management and verification, enabling and implementing so-called “smart contracts,” and social networking.”}; which together are the same as claimed limitations above to include ‘smart contract’)
Examiner notes that La Fever’s teachings of “DLT/s”, “smart contract/s” as well as “blockchain/s” are the same as claimed ‘a smart contract’ per BRI procedures.
(see at least: Dawson ibidem and citations listed above to include ‘associated with the user is not disclosed to the verifier service’)
Dependent Claims 9-11 & 13 are rejected under 35 USC 103 as unpatentable over LaFever and Dawson as applied to the rejection of independent Claim 8 above, and as described below for each claim/ limitation.
With respect to Claim 9, LaFever and Dawson teach ---
9. The method of claim 8, further comprising verifying the first request with the smart contract.
(see at least: LaFever ibidem and citations listed above to include ‘a/the verifier service’ and ‘verify the characteristic’ aka ‘verification of the data attribute/s’, and ‘smart contract’ and ‘smart contracts’; and para [0624] about {“…… While blockchains are best known for their use in enabling cryptocurrencies and cryptocurrency transactions, they have a broad range of other applications, such as in storing medical data, supply chain management, financial transaction management and verification, enabling and implementing so-called “smart contracts,” and social networking.”}; which together are the same as claimed ‘verifying the first request with the smart contract’)
(see at least: Dawson ibidem and citations listed above to include ‘associated with the user is not disclosed to the verifier service’)
With respect to Claim 10, LaFever and Dawson teach ---
10. The method of claim 8, further comprising verifying a signature of the first
request.
(see at least: LaFever ibidem and citations listed above to include ‘a/the verifier service’ and ‘verify the characteristic’ aka ‘verification of the data attribute/s’, and ‘verifying the first request with the smart contract’; and paras [0363]-[0365] about {“A verification module 55 that may include validating and verifying the integrity of aggregated data profiles including data attributes, attribute combinations, DDIDs, and TDRs at any point in time. ………… In one example, data elements pertaining to Data Subjects, actions, activities, processes or traits may be abstracted by linking data elements pertaining to the Data Subject, action, activity, process or trait to independent attributes or dependent attributes and/or separating data elements pertaining to the Data Subject, action, activity, process or trait into independent attributes or dependent attributes. ………………. medical information; biometric data; behavior metric information; genetic information; …”}; which together are the same as claimed limitations above)
(see at least: Dawson ibidem and citations listed above to include ‘associated with the user is not disclosed to the verifier service’)
With respect to Claim 11, LaFever and Dawson teach ---
11. The method of claim 8, wherein anonymizing the one or more attributes of the
user to generate one or more anonymized attributes further comprises:
applying a machine learning model to the one or more attributes to identify personally identifying information within the one or more attributes; and
removing the personally identifying information from the one or more attributes
(see at least: LaFever ibidem and citations listed above to include ‘a/the verifier service’ and ‘verify the characteristic’ aka ‘verification of the data attribute/s’, and ‘verifying the first request with the smart contract’; and para [0720] about {“…… This approach allows the use of machine learning algorithms on the individual paths of many people to generate pseudonymised models—while protecting individuals' identities and then using controlled relinking only for authorized purposes in order to de-pseudonymize the model, e.g., for subsequent use of the insights embedded in the model.”}; which together are the same as claimed limitations above to include ‘a machine learning model’)
(see at least: Dawson ibidem and citations listed above to include ‘associated with the user is not disclosed to the verifier service’)
With respect to Claim 12, LaFever and Dawson teach ---
12. The method of claim 8, further comprising:
receiving, from the verifier service, a verification of the characteristic; and
returning the verification of the characteristic to a smart contract.
(see at least: LaFever ibidem and citations listed above to include ‘a/the verifier service’ and ‘verify the characteristic’ aka ‘verification of the data attribute/s’, and ‘verifying the first request with the smart contract’)
(see at least: Dawson ibidem and citations listed above to include ‘associated with the user is not disclosed to the verifier service’)
With respect to Claim 13, LaFever and Dawson teach ---
13. The method of claim 8, wherein the method is performed within a trusted execution environment provided by a processor of the computing device.
(see at least: LaFever ibidem and citations listed above to include ‘a/the computing device’; and paras [0043] and [0398] for ‘processor’, ‘computer/s’ and ‘devices’; and para [0409] about {“.... In one example, the device may include a processor configured to execute program modules, wherein the program modules include at least a privacy client module; a memory connected to the processor; ……………… reside on a service provider device ………. reside on the same computing device …”}; which together are the same as claimed limitations above to include ‘a processor of the computing device’; AND paras [0090], [1097] and [1117] for ‘Trusted Execution Environment (TEE)’; and para [0699] about {“As discussed briefly above, Confidential Computing Environments (CCE) leverage hardware-based Trusted Execution Environments (TEE), a secure enclave within a CPU to extend the protection provided by encryption for data at-rest and for data in-transit to protection of data in-use. …”}; which together are the same as claimed limitations above to include ‘a trusted execution environment’)
(see at least: Dawson ibidem and citations listed above to include ‘associated with the user is not disclosed to the verifier service’)
Dependent Claims 14/21-22 are rejected under 35 USC 103 as unpatentable over LaFever and Dawson as applied to the rejection of Claims 8-11 & 13 above, and further in view of Pub. No. US 2023/ 0149632 filed by Mullen et al. (hereinafter “Mullen”), and as described below for each claim/ limitation.
With respect to Claim 14, LaFever and Dawson teach ---
14. The method of claim 8, wherein the verification of the characteristic is represented
by the smart contract as (a non-fungible token (NFT) on a blockchain).
(see at least: LaFever ibidem and citations listed above to include ‘a/the verifier service’ and ‘verify the characteristic’ aka ‘verification of the data attribute/s’, ‘smart contract’ and ‘verifying the first request with the smart contract’; and para [0648] about {“……… The same encrypted/ tokenized value of “ABCD” is used in multiple blockchains to refer to “John Smith.” …”}; which together are the same as claimed limitations above to include ‘a non-fungible token (NFT) on a blockchain’)
Examiner notes that claimed NFT is similar to “encrypted/ tokenized value” (i.e., units of data) in “multiple blockchains” as taught by the LaFever reference above.
(see at least: Dawson ibidem and citations listed above to include ‘associated with the user is not disclosed to the verifier service’)
LaFever and Dawson teach as disclosed above, but it has been argued by the Applicant that they may not explicitly disclose about ‘a non-fungible token (NFT) on a blockchain’. However, Mullen teaches them explicitly.
(see at least: Mullen Abstract and Summary of the Invention in para [0003]; and para [0024] about {“In the case of the Dynamics, NFT Smart Contract, there are a series of pre-determined functions/functionality that a Smart Contract provides to have an Ethereum NFT. One important piece of information to know about Ethereum “NFTs” is that a Ethereum NFT is are just a number of a token inside a smart contract and any associated stored information. ……… The following functions may be provided with blockchain calls (e.g., Ethereum NFT calls) (platform includes a metadata NFT). Blockchain calls may include (i) balanceOf—this is used to determine the number of NFTs an owner has inside that smart contract. You pass in an owner address; (ii) ownerOf—this is used to get the address of the owner of a specific NFT. ……”}; and para [0037] about {“A key feature of platform is the ability for owners of NFTs (such as Ethereum NFTs) to import those NFTs into the platform. As previously discussed, an NFT on Ethereum is the ownership of a token in a specific smart contract. … At a minimum, the platform will record information from the originating blockchain, including the smart contract the NFT is from and history information from the related blockchain to allow a full understanding of the NFT. The owner will also need to specify an platform account to load the NFT info, and proper validation will occur on that end as well.”}; and para [0059] about {“If an exportation is desired, an NFT associated with a desired exportation medium (e.g., a public blockchain) may be created (e.g., an NFT with a smart contract may be created). In doing so, no NFT may need to be created until, for example, an exportation is desired. In doing so, for example, a creation/registration date on a public blockchain may take on an exportation date which may be after the NFT is purchased or opened from a pack. …”}; which together are the same as claimed limitations above to include ‘a non-fungible token (NFT) on a blockchain’)
It would have been obvious prior to the time of the effective filing date of the claimed invention to have an ordinary person of skill in the art to modify the teachings of LaFever and Dawson with the teachings of Mullen. The motivation to combine these references would be to provide systems, methods and devices that overcome the limitations of static and/or persistent privacy/anonymity and security systems and improve the accuracy of data for exchange, collection, transactions, analysis and other uses (see para [0018] of LaFever), and to permit users making purchases on website in which digital identification using passwords may be a security policy necessary for making a purchase, the same security policy may not apply to browsing products (see para [0004] of Dawson), and to allow a multiple ledger non-fungible token (NFT) to be provided that includes ledger data that can be read and written by a public processing system such as, for example a public blockchain system and ledger data that can be read and written by a private processing system such as, for example, a private blockchain system (see para [0003] of Mullen).
With respect to Claim 21, LaFever, Dawson and Mullen teach ---
21. (New) The method of claim 8, further comprising:
creating a non-fungible token (NFT) in response to the first request; and
updating a status of the NFT based on the verification of the characteristic returned to the smart contract.
(see at least: LaFever ibidem and citations listed above to include ‘a/the verifier service’ and ‘verify the characteristic’ aka ‘verification of the data attribute/s’, ‘smart contract’ and ‘verifying the first request with the smart contract’)
(see at least: Dawson ibidem and citations listed above to include ‘associated with the user is not disclosed to the verifier service’)
(see at least: Mullen ibidem and citations listed above to include ‘a non-fungible token (NFT) on a blockchain’; and para [0075] for “the NFT was created on the public ledger by BananaNFT.com”; and para [0082] about {“Option 139 may be provided, for example, to validate that an NFT on one ledger is associated with a peer NFT on another ledger ledgers such as, for example, using, for example, the smart contract of a public blockchain (e.g., Ethereum) that may include an intermediate identifier that links the NFTs on the two ledgers together. Accordingly, a collectible NFT may be provided as a relational database NFT in one system and a smart contract may be provided on a public blockchain that lists the relational NFT as being a valid relational NFT that is, or will be, associated with an NFT on the public blockchain. Thus, for example, a public blockchain NFT may not be minted until a relational database NFT is exported from a relational database ledger, an association is preserved via a smart contract on the public blockchain before, and after, the NFT is ultimately minted through an identifier (e.g., token) provided on the smart contract on the public (e.g., or private) blockchain).”}; which together are the same as claimed limitations above)
With respect to Claim 22, LaFever, Dawson and Mullen teach ---
22. (New) The non-transitory, computer-readable medium of claim 15, wherein the machine-readable instructions further cause the computing device to at least:
create a non-fungible token (NFT) in response to the first request; and
update a status of the NFT based on the verification of the characteristic returned to the smart contract.
(see at least: LaFever ibidem and citations listed above to include ‘a/the verifier service’ and ‘verify the characteristic’ aka ‘verification of the data attribute/s’, ‘smart contract’ and ‘verifying the first request with the smart contract’)
(see at least: Dawson ibidem and citations listed above to include ‘associated with the user is not disclosed to the verifier service’)
(see at least: Mullen ibidem and citations listed above to include ‘a non-fungible token (NFT) on a blockchain’; and para [0034] about {“Features may include (i) Ability for each individual owner to provide content for an NFT if they are the owner; (ii) Ability for each previous owner to update their specific owner provided data even if they no longer own the NFT (iii) Ability for NFT creator/minter to add/update NFT data at a global or individual token level; (iv) Ability to “Mint” an NFT, which is the initial assignment of a specific NFT token id to a user; (v) Ability to “Sell” an NFT and require payment be included as part of the sale if wanted. …”}; which together are the same as claimed limitations above to include to ‘create and update a NFT’)
With respect to Claims 1-7/23, the limitations of these system claims are rejected under 35 USC 103 as unpatentable based on the exemplary analysis above for the rejection of method Claims 8-14 as described above using the cited reference of LaFever, Dawson and Mullen, because the limitations of these system Claims 1-7/23 are commensurate in scope to limitations, and thus duplicates, of the above rejected method Claims 8-14 as described above.
With respect to Claims 15-20, the limitations of these non-transitory computer-readable storage medium claims are rejected under 35 USC 103 as unpatentable based on the exemplary analysis above for the rejection of method Claims 8-14 as described above using the cited reference of LaFever, Dawson and Mullen, because the limitations of these non-transitory computer-readable storage medium Claims 15-20 are commensurate in scope to limitations, and thus duplicates, of the above rejected method Claims 8-14 as described above.
Response to Arguments
Applicant’s remarks (on pages 10-27) and claim amendments of 28 JANUARY 2026 with respect to the rejection of amended Claims 1-11, 13-18 and 20-22 have been carefully considered, but they are not persuasive and do not put these amended claims in a condition ready for Allowance. Thus, the rejection of amended Claims 1-11, 13-18 and 20-22 has been maintained as described above. Additionally, Examiner notes that the 35 USC 103 rejection herein has been revised by withdrawing prior Chockalingam reference due to deletion of limitations about [[. Thus, the rejection of amended Claims 1-11, 13-18 and 20-22, as described above, is being maintained herein with some modifications in this Office Action, where needed to provide clarification in response to the Applicant’s claim amendments and remarks of 01/28/2026.
In response to the Applicant’s arguments of 01/28/2026 against the rejection under 35 USC 101 about Prong One that the Claims do not recite an abstract idea, and Examiner respectfully disagrees. Also, upon reviewing the Specification and the claim as whole, independent method Claim 8 (exemplary) is at least directed to one of the ineligible “certain methods of organizing human activity” that include “fundamental economic principles or practices” (based on at least ‘financial transactions’ in para [0018] of Specification as in --- {“Another example of a service provider service 136 could be a financial service application such as banking or brokerage application that allows a user to perform financial transactions (e.g., open a transaction account, line of credit, credit card account or brokerage account; send or receive a payment; pay down a balance on a line of credit or a credit card account; trade financial or equity instruments such as stocks, bonds, mutual funds, exchange traded funds, etc.)”}, and “commercial or legal interactions” (based on at least ‘open a bank account’ and ‘open a credit card account’ in para [0006] of Specification as in {“For example, to lease an apartment, open a bank account, open a credit card account, make a large purchase or obtain credit for a large purchase (e.g., a car, a house, a boat, etc.) a user might be required to provide personally identifiable information such as their name, date of birth, government identification (e.g., driver's license number, social security number, etc.), current residential address, current place of employment, etc., in order for the counterparty to perform a credit check and/or verify the identity of the user.”} as well as “managing personal behavior or relationships or interactions between people” (based on ‘PII’ in claims & at least ‘instructions’ in para [0047] of Specification as in {“If embodied in software, each block can represent a module, segment, or portion of code that includes program instructions to implement the specified logical function(s). The program instructions can be embodied in the form of source code that includes human-readable statements written in a programming language or machine code that includes numerical instructions recognizable by a suitable execution system such as a processor in a computer system.”}. Method Claim 8 describes approaches for verifying user characteristics in a decentralized and anonymized fashion (see Abstract). Thus, like the concept of intermediated settlement in Alice, and the concept of hedging in Bilski, the concept of “generating a set of instructions sequences based on certain criteria from a user for image transaction processing” recited in exemplary independent method Claim 8 “is a fundamental economic practice long prevalent in our system of commerce.” Thus, it is clear that exemplary independent method Claim 8 recites fundamental economic practices and/or commercial transactions that, under the Revised Guidance, fall under the category of abstract ideas related to “certain methods of organizing human activity.” 2019 Revised Guidance, 84 Fed. Reg. at 52. Accordingly, independent method Claim 8 recites an abstract idea.
In response to the Applicant’s arguments of 01/28/2026 against the rejection under 35 USC 101 about Prong Two that the claims integrate the abstract idea into a practical application, and Examiner respectfully disagrees. Also, under the 2019 PEG, Step 2A, prong two, integration into a practical application requires an additional element(s) or a combination of additional elements in the claim to apply, rely on, or use the judicial exception in a manner that imposes a meaningful limit on the judicial exception, such that the claim is more than a drafting effort designed to monopolize the exception. Limitations that are not indicative of integration into a practical application are those that are mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea --- see MPEP 2106.05(f).
In response to the Applicant’s arguments of 01/28/2026 against the rejection under 35 USC 101, Examiner respectfully disagrees. Examiner notes that the instant application provides a business solution and not a technological solution as argued by the Applicant. Also, Examiner clarifies that the instant application is nothing more than an improvement of an abstract idea, wherein using technology/ computers to execute an abstract idea is at most an improvement to the abstract idea.
Applicant's arguments of 01/28/2026 with respect to rejection of Claims 1-11, 13-18 and 20-22 under 35 USC 103 have been considered, but they are moot in view of the new ground/s of rejection by adding new Dawson reference in response to the latest claim amendments, and by withdrawing prior Chockalingam reference, which was necessitated by the Applicant's arguments and/or ‘amendments to the claims’. See MPEP §706.07(a).
In response to the Applicant’s arguments of 09/05/2025 traversing the rejection under 35 USC 101 claiming that In Re: BASCOM applies to the instant application, Examiner respectfully disagrees. Examiner further notes that the instant application is not similar to BASCOM, because the claims in BASCOM are focused on a specific asserted filtering of internet content using a computer, even at an off-site location such as at an ISP location (Internet Service Provider location). The claims herein do not simply recite a similar filtering internet content. The current invention is not related to an improvement in technology as in BASCOM, but it rather uses the computer as a tool to apply the abstract idea.
Examiner relies on what the courts have recognized, or those of ordinary skill in the art would recognize, as elements that describe well-understood, routine, and conventional activity in particular fields. For example, receiving or transmitting data over a network, e.g., using the Internet to gather data, Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362 (utilizing an intermediary computer to forward information); TLI Communications LLC v. AV Auto. LLC, 823 F.3d 607, 610, 118 USPQ2d 1744, 1745 (Fed. Cir. 2016) (using a telephone for image transmission); OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363, 115 USPQ2d 1090, 1093 (Fed. Cir. 2015) (sending messages over a network); buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, 112 USPQ2d 1093, 1096 (Fed. Cir. 2014) (computer receives and sends information over a network); but see DDR Holdings, LLC v. Hotels.com, L.P., 773 F.3d 1245, 1258, 113 USPQ2d 1097, 1106 (Fed. Cir. 2014) (“Unlike the claims in Ultramercial, the claims at issue here specify how interactions with the Internet are manipulated to yield a desired result‐‐a result that overrides the routine and conventional sequence of events ordinarily triggered by the click of a hyperlink.” (emphasis added)). In this case, the use of devices and networks is described at a high level of generality, or as an insignificant extra-solution activity that cannot be considered as an improvement to network/computer technology; for example, para [0010] of the Specification recites – {“Examples of networks 123 can include the Internet, intranets, extranets, virtual private networks (VPNs), and similar networks.”}.
NOTE: Examiner notes that the previous Responses to Arguments from more than one previous Office Action/s are incorporated herein as described below, some of which may be similar to and repeated as arguments on 09/05/2025, for example but not limited to, prong one and prong two, etc.
Applicant's arguments of 03/12/2025 with respect to rejection of Claims 1-11, 13-18 and 20-22 under 35 USC 103 have been considered, but they are moot in view of the new ground/s of rejection (new Chockalingam reference), which was necessitated by the Applicant's arguments and/or ‘amendments to the claims’. See MPEP §706.07(a).
In response to the Applicant’s arguments of 03/12/2025 against the rejection under 35 USC 101, Examiner respectfully disagrees. Also, Examiner clarifies that the instant application is nothing more than an improvement of an abstract idea, wherein using technology/ computers to execute an abstract idea is at most an improvement to the abstract idea.
In further response to the Applicant’s arguments of 03/12/2025 against the rejection under Step 2A, “Prong One”, and Examiner respectfully disagrees. Also, upon reviewing the Specification and the claim as whole, independent Claim 8 (exemplary) is at least directed to one of the ineligible performance of the limitations via a method of organizing human activity such as fundamental economic principles or practices (including hedging, insurance, mitigating risk), and/or commercial or legal interactions (including agreements in the form of contracts; legal obligations; advertising, marketing or sales activities or behaviors; business relations), and/or managing behavior or relationships or interactions between people (including social activities, teaching, and following rules or instructions), but for the recitation of generic computer/s and/or computer component/s such as the devices/ mobile devices based on recitation of at least limitations such as receiving a first request to verify a characteristic of a user, the request comprising personally identifying information (PIl) associated with the user; sending a second request for one or more attributes of the user, wherein the second request comprises at least a portion of the PII associated with the user; receiving the one or more attributes of the user; anonymizing the one or more attributes of the user to generate one or more anonymized attributes; and sending the one or more anonymized attributes. Method Claim 8 describes approaches for verifying user characteristics in a decentralized and anonymized fashion (per Abstract). Thus, like the concept of intermediated settlement in Alice, and the concept of hedging in Bilski, the concept of “generating a set of instructions sequences based on certain criteria from a user for image transaction processing” recited in exemplary independent Claim 8 “is a fundamental economic practice long prevalent in our system of commerce.” Thus, it is clear that exemplary independent Claim 8 recites fundamental economic practices and/or commercial transactions that, under the Revised Guidance, fall under the category of abstract ideas related to “certain methods of organizing human activity.” 2019 Revised Guidance, 84 Fed. Reg. at 52. Accordingly, independent Claim 8 recites an abstract idea.
In further response to the Applicant’s arguments of 03/12/2025 against the rejection under Step 2A, “Prong Two”, and Examiner respectfully disagrees. Also, under the 2019 PEG, Step 2A, prong two, integration into a practical application requires an additional element(s) or a combination of additional elements in the claim to apply, rely on, or use the judicial exception in a manner that imposes a meaningful limit on the judicial exception, such that the claim is more than a drafting effort designed to monopolize the exception. Limitations that are not indicative of integration into a practical application are those that are mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea --- see MPEP 2106.05(f).
In further response to the Applicant’s arguments of 03/12/2025 against the rejection under 35 USC 101 about the instant application’s claims recite significantly more than the judicial exceptions, and Examiner respectfully disagrees. Additionally, Examiner relies on what the courts have recognized, or those of ordinary skill in the art would recognize, as elements that describe well-understood, routine, and conventional activity in particular fields. For example, receiving or transmitting data over a network, e.g., using the Internet to gather data, Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362 (utilizing an intermediary computer to forward information); TLI Communications LLC v. AV Auto. LLC, 823 F.3d 607, 610, 118 USPQ2d 1744, 1745 (Fed. Cir. 2016) (using a telephone for image transmission); OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363, 115 USPQ2d 1090, 1093 (Fed. Cir. 2015) (sending messages over a network); buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, 112 USPQ2d 1093, 1096 (Fed. Cir. 2014) (computer receives and sends information over a network); but see DDR Holdings, LLC v. Hotels.com, L.P., 773 F.3d 1245, 1258, 113 USPQ2d 1097, 1106 (Fed. Cir. 2014) (“Unlike the claims in Ultramercial, the claims at issue here specify how interactions with the Internet are manipulated to yield a desired result‐‐a result that overrides the routine and conventional sequence of events ordinarily triggered by the click of a hyperlink.” (emphasis added)). In the instant application, it recites the use of a computing device, a client device, an attribute service and a verifier service, plus a large language model and a smart contract as additional elements are described at a high level of generality, or as an insignificant extra-solution activity that cannot be considered as an improvement to network/ computer technology.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office Action. Accordingly, THIS ACTION IS MADE FINAL. See at least MPEP §706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
The prior art made of record and not relied upon, listed in Form 892, that is considered pertinent to the Applicant's disclosure and review for not traversing already issued patents and/or claimed inventions by the claims of the current invention of the Applicant. Examiner notes that Form 892 contains more references than those cited in the previous rejection under 35 USC 102/103, and all the references cited on said Form 892 are relevant to this application that form a part of the body of prior art. Examiner notes that US patent no. 9,147,042 filed by Haller et al. has also been specifically cited above in rejection for its teachings and disclosure as a supportive reference.
The Examiner has pointed out particular references contained in the prior art of record in the body of this action 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. The Applicant should consider the entire prior art as applicable as to the limitations of the claims ; and said prior art includes references with synonyms for terms used in the claims that have been interpreted under the BRI (broad reasonable interpretation) procedures of the Office. It is respectfully requested from the Applicant, in preparing the response, to consider fully the entire references 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.
Any inquiry concerning this communication or earlier communications from the Examiner should be directed to Sanjeev Malhotra whose telephone number is (571) 272-7292. The Examiner can normally be reached during Monday-Friday between 8:30-17:00 hours on a Flexible schedule.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an
interview, the Applicant is encouraged to contact the Examiner directly.
If attempts to reach the Examiner by telephone are unsuccessful, the examiner’s
supervisor, Abhishek Vyas, can be reached on (571) 270-1836. The facsimile/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 & 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.
Electronic Communications
Prior to initiating the first e-mail correspondence with an Examiner, Applicant is responsible for filing a written statement with the USPTO in accordance with MPEP §502.03(II). All received e-mail messages including e-mail attachments shall be placed into this application’s record. The Examiner’s e-mail address is provided below at the end of this Office Action.
/S.M./
Examiner, Art Unit 3691
sanjeev.malhotra@uspto.gov
/ABHISHEK VYAS/Supervisory Patent Examiner, Art Unit 3691
Prosecution Insights