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
This Office action is in response to correspondence received February 12, 2026.
Claims 1, 5, 11, 15, and 18 are amended. Claims 1-20 are pending and have been examined.
Claim Objections
Claim 15 is objected to because claim 15 does not follow 37 CFR 1.121(c), wherein the correct parenthetical expression must be used. Here Applicant stated previously presented but the claim is amended. Appropriate correction is required.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 5 and 15 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Per claims 5 and 15, Applicant recites the following: wherein the particular market segment corresponds to hospitality services, and the trust score is calculated based on… reservation activity within … hospitality establishments. The result of the trust score is that people can make reservations but this is the opposite, that a trust score is calculated based on reservation activity. See par 012: “There are many examples of premium services that may be provided to consumes, including self-checkout at non-traditional retail stores, enhanced forms of self-checkout or access to special products at a retail store, ordering or reservations without pre-payment at a restaurant, priority seating at a restaurant or airline, access to enhanced borrowing/lending services at financial institution, decentralized buying, selling, and/or lending at a financial institution, etc.” This describes the premium services that can be provided to a user. However, there is no calculation of a trust score based on a reservation activity within hospitality establishments. Therefore this is new matter.
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-10 and 18 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 1 recites the limitation "the verifiable” in the limitation starting, “provide the verifiable to the decentralized node.” There is insufficient antecedent basis for this limitation in the claim, as it is unclear what “the verifiable” refers back to. If this refers to a verifiable credential, then this must be amended to say “the verifiable credential.” However, the scope is unclear as it is not clear what this refers to. Therefore claim 1 is indefinite.
Claims 2-10 are rejected for being dependent on claim 1.
Claim 18 recites the following: “which when executed, cause the processor to operations: locate a DID document associated with the decentralized identifier in a distributed ledger; and provide the DID document upon request.“
Likely because of a missing term, it is unclear what the processor is doing with operations. Perform, read, write could be three possibilities. If the term is added the scope will be clear.
Therefore claims 1-10, 15, and 18 are rejected under 35 USC 112.
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.
Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. Claims 1 recite(s):
A method of generating a context-based user trust score, comprising: transmit, a request for access to a premium service, the premium service related to a particular market segment; and grant access to a subset of personally identifiable information stored the subset of personally identifiable information related to the particular market segment; access the subset of personally identifiable information and process the accessed subset to calculate a context-based user trust score based thereon; format a verifiable credential representing the calculated context-based user trust score; and provide the verifiable [for recording] wherein the subset of personally identifiable information is not retained after the context-based user trust score is calculated
Claim 11 recites:
generating a context-based user trust score, comprising: transmit, a request for access to a premium service, the premium service associated with a particular market segment; and grant access to a subset of personally identifiable information the subset of personally identifiable information being related to the particular market segment; : access the subset of personally identifiable information process the accessed subset to calculate a context-based user trust score; format a verifiable credential corresponding to the calculated context- based user trust score; and provide the verifiable credential [for recording] ; does not retain the subset of personally identifiable information after calculation of the context-based user trust score;
These limitations, as described above, are an abstract idea that is a certain method of organizing human activity, sales or marketing behaviors. The limitations above describe accessing a premium service, which is a sale (a good or service sold to someone), and it being associated to a market segment, then a trust score being calculated to determine if access is granted. The trust score is simply calculated based on personally identifiable information, which is information, that is analyzed to determine how likely someone is who they say they are. These are sales or marketing activities as they are related to delivering the goods to a correct person, and this is within the scope of the identified abstract idea above. Therefore, for these reasons, Applicant has recited an abstract idea that is a certain method of organizing human activity.
This judicial exception is not integrated into a practical application. The limitations of via a user application running on a personal device; data stored on a decentralized web node of a user; and by a trust score application programming interface running on a processor are instructions both alone and in combination to apply the abstract idea to computers. This is similar to requiring the use of software to tailor information and provide it to the user on a generic computer, Intellectual Ventures I LLC v. Capital One Bank (USA), 792 F.3d 1363, 1370-71, 115 USPQ2d 1636, 1642 (Fed. Cir. 2015), or using a telephone unit and a server to perform operations and store data, TLI Communications LLC v. AV Auto, LLC, 823 F.3d 607, 613, 118 USPQ2d 1744, 1748 (Fed. Cir. 2016) (see MPEP 2106.05(f)(2) for pin cites). Therefore, because the additional elements are apply it instructions, they are not a practical application of an abstract idea.
The additional elements of claim 1 are:
computer-implemented
executing, by a processor of a personal device having a non-transitory computer-readable storage medium storing a user application, instructions that cause the processor to:
via the user application,
accessing/storing on a decentralized web node of a user,
executing, by a processor of a trust-score server having a non-transitory computer- readable storage medium storing a trust-score application programming interface (API), instructions that cause the processor to:
steps performed by the trust-score server
wherein the trust-score server and the personal device communicate via a network in accordance with a decentralized Web 5 model utilizing decentralized identifiers (DIDs).
The additional elements of claim 11 are:
A computer system for
a user device having a processor and a non-transitory computer-readable storage medium, the non-transitory computer-readable storage medium having executable instructions for a user application, which when executed, cause the processor to perform the following operations:
via the user application,
stored on a decentralized web node associated with the user,
And a trust score server having a processor and a non-transitory computer-readable storage medium, the non-transitory computer-readable storage medium having executable instructions for a trust score application programming interface (API), which when executed, cause the processor to perform the following operations
on the decentralized web node of the user via the trust score API;
decentralized web node of the user for storage therein
wherein the trust-score server performs steps
wherein the trust-score server and the user device communicate via a network implementing a decentralized-web protocol utilizing decentralized identifiers (DIDs).
The recitations of a decentralized web node are apply it elements because they are being used in their ordinary capacity. While they are not a generic computing device, Applicant has claimed no more than their applied use. Applicant has not, for example, provided detail as to how data would be sent “to the decentralized web node.” Applicant has claimed, essentially, taking a made product off the shelf, in this instance, Jack Dorsey’s Web 5 model, and using it in its invention exactly as was intended in a highly generic manner. Therefore this is nothing more than an instruction to apply n ordinary machine: here, Web 5, to the abstract idea recited.
The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception because, for the same reason that they are not a practical application, they are not significantly more. As analyzed above, the additional elements both alone and in combination are apply it instructions, and the reasoning above is carried over here. Therefore, the limitations are not significantly more than the abstract idea.
Per the dependent claims:
Claims 2 and 12 recite that the web node is provided locally in other words the user device hosts or loads the web node which would be taught by loading a web page on a user device. The accessing through a decentralized web node is an apply it element nothing more is claimed except that it is accessed through it. This is using the web and as shown in Ultramercial, see also MPEP 2106.05(f)(2), using the internet is not a practical application or significantly more. Likewise with claims 3 and 13 where the api is running on a remote server, this is running software on a server which is an apply it limitation of using computer technology in its ordinary capacity, which is not a practical application or significantly more.
Claims 4-6 and 14-16 recite the applications of the technology to various sales and marketing areas. These non-technical labels are known only for their business or societal use, such as “hospitality businesses.” As this further describes sales and marketing behaviors (which business type is the invention being applied to), this further describes the abstract idea.
Claim 7 and 17 recite that the web node is identified by a decentralized identifier which is reciting that there is a common identifier for the web node that is on peer to peer. This is a part of the abstract idea as it is reciting that the information about the web node is among peers. Alternatively this is an additional element taught by using hashes or other peer to peer technology in its ordinary capacity. Therefore this, if incorporated into the independent claims, would not overcome the 101 rejection.
Claims 8 and 18 recite that the decentralized identifier is provided from a distributed ledger. This teaches using distributed ledger technology in its ordinary capacity, to store or provide information. Therefore, claims 8 and 18 are not a practical application or significantly more than the abstract idea.
Claims 9 and 19 further describe the abstract idea where the user trust score is a verifiable credential. Under a broadest reasonable interpretation in light of the specification, a verifiable credential is something that can be cross checked, which is a part of organizing human activity of verifying a person (see: running a drivers license check). Therefore this further describes the abstract idea.
Claims 10 and 20 describe using homomorphic encryption. As this is recited at a high level and without detail as to how the homomorphic encryption is used (for example, technical steps as to how the homomorphic encryption is performed with the abstract idea elements), it is an apply it limitation that is not a practical application or significantly more than the abstract idea.
Therefore, claims 1-20 are rejected under 35 USC 101.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim(s) 1-9 and 11-19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Mardikar et al., US PGPUB 20230237491 (“Mardikar”) in view of DIF, Decentralized Web Node, [online] available at: < https://web.archive.org/web/20220610201212/https://identity.foundation/decentralized-web-node/spec/ > archived on Jun 10, 2022 (“DIF”), further in view of McDowell, John, “Web 5.0 versus Web 3.0: What’s the Difference?” [online], available at: < https://www.tradingsim.com/blog/web-5.0-versus-web-3.0 >, published on June 23, 2022 (“McDowell”), further in view of Mawji et al., US PGPUB 20160277424 A1 (“Mawji”).
Per claims 1 and 11, which are similar in scope, Mardikar teaches a computer-implemented method of generating a context-based user trust score, comprising: executing, by a processor of a personal device having a non-transitory computer-readable storage medium storing a user application, instructions that cause the processor to in par 016: “In various embodiments, system 100 may comprise one or more of a digital identity database 101, a trust score provider 103, a trust server 105, a trust score database 107, a merchant 109, a third party data provider 111, and a consumer device 113. One or more system 100 components may be configured to interact with digital identity database 101 to review, collect, and/or submit digital identity information. In that respect, each system 100 component may comprise any suitable entity, system, network, or the like desiring to obtain, review, or submit digital identity information.” Storing a user application is taught in par 019: “Each computing device may run applications to interact with DLT network 201, communicate with other devices, perform crypto operations, and otherwise operate within system 200. The computing devices may run a client application that can be a thin client (web), hybrid (i.e. web and native, such as iOS and Android), or native application to make API calls to interact with the digital ledger, such as a web3 API compatible with blockchain databases maintained by ETHEREUM®.”
Mardikar teaches a system with a non-transitory computer readable medium with executable instructions, causing the processor to perform operations in par 025: he processor may be configured to implement various logical operations in response to execution of instructions, for example, instructions stored on a non-transitory, tangible, computer-readable medium, as discussed further herein. Exemplary processors may include any logic device capable of performing the logical operations disclosed herein, such as, for example, a central processing unit (CPU), an accelerated processing unit (APU), a digital signal processor (DSP), a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), or the like.”
Mardikar then teaches transmit, via the user application, a request for access to a premium service, the premium service related to a particular market segment in par 014: “In general, in various embodiments, a consumer may initiate a transaction with a merchant. The transaction may include a request for services, a new account request, a purchase of goods, etc. The consumer may request a dynamic trust score from a trust score provider.” New account request is a particular market segment as well as purchase of goods. This is further taught in par 028: “The merchant 109 may comprise various hardware, software, and/or database components operated by any suitable online or in-person merchant entity such as AIRBNB®, UBER®. YELP®, AMAZON®, EBAY®, WALMART®, TARGET®, or the like.” Walmart is a particular market segment, Airbnb is a particular market segment. Under a broadest reasonable interpretation, a premium service is taught by these retailers as they sell a range of goods with a premium (warranty, other benefits) attached. See also par 029: “For example, the consumer device 113 may comprise a web browser (e.g., MICROSOFT INTERNET EXPLORER®, GOOGLE CHROME®, etc.), an application, a micro-app or mobile application, or the like configured to enable the consumer device 113 to interact with the merchant 109 (e.g., to initiate a transaction, purchase various goods or services, etc.).” This teaches transmit as accessing the web to interact with a merchant (which is done through an application as taught) teaches transmitting as the web requires a transmission (communication over the Internet). See also par 038, a mobile application operated by the merchant.
Mardikar then teaches and grant access to a subset of personally identifiable information, the subset of personally identifiable information related to the particular market segment in pars 031-032: “"The trust score provider 103 may be configured to receive transaction requests. For example, the transaction request may be received in response to a consumer initiating a transaction with the merchant 109. Each transaction request may comprise any suitable transaction related data, such as, for example, a transaction account number, a transaction instrument number, a transaction instrument expiration date, transaction account billing information (e.g., address, city, state, zip code, etc.), a user email address, an IP address (e.g., from an online purchaser), and/or the like.
The trust score provider 103 may be configured to perform an initial authorization assessment on the transaction request. The trust score provider 103 may perform the initial authentication assessment using any suitable technical process known in the art. The initial authentication assessment may determine whether (and to what extent) the consumer is authorized to transfer sufficient funds to the merchant 109 via a transaction account, such as a credit card account, as well as whether there is an unacceptable risk of fraud based on the transaction request. "
See also par 038: “The user may request a dynamic trust score from the trust score provider (step 303). In various embodiments, the merchant may prompt the user to request the dynamic trust score from the trust score provider, such as by allowing the user to click on or select a button which initiates a request for the dynamic trust score. In various embodiments, the user may request the dynamic trust score from the trust score provider without prompting from the merchant, which may occur either prior to, during or after initiating the transaction with the merchant. For example, the user may access a mobile application of the trust score provider, and the user may select a trust score request button.”
Mardikar then teaches executing, by a processor of a trust-score server having a non-transitory computer- readable storage medium storing a trust-score application programming interface (API), instructions that cause the processor to in par 032: “The initial authentication assessment may determine whether (and to what extent) the consumer is authorized to transfer sufficient funds to the merchant 109 via a transaction account, such as a credit card account, as well as whether there is an unacceptable risk of fraud based on the transaction request. The trust score provider 103 may also communicate with the trust server 105 request a dynamic trust score for the transaction request” See also par 040: “The trust server may calculate a dynamic trust score for the transaction (step 305). The dynamic trust score may indicate a likelihood that the user will complete the transaction in a positive manner.” See par 038: “For example, the user may access a mobile application of the trust score provider, and the user may select a trust score request button.” For trust server hardware see par 025: “The trust server 105 may comprise one or more hardware, software, and/or database components configured to communicate with the trust score provider 103, the trust score database 107, and/or the third party data provider 111 to calculate a dynamic trust score. In various embodiments, the trust score provider 103, the trust server 105, and/or the trust score database 107 may be operated by the same entity, such as a transaction account issuer. For example, trust server 105 may comprise one or more network environments, servers, computer-based systems, processors, databases, and/or the like.”
Mardikar then teaches access the subset of personally identifiable information and process the accessed subset to calculate a context-based user trust score based thereon in par 032: “The initial authentication assessment may determine whether (and to what extent) the consumer is authorized to transfer sufficient funds to the merchant 109 via a transaction account, such as a credit card account, as well as whether there is an unacceptable risk of fraud based on the transaction request. The trust score provider 103 may also communicate with the trust server 105 request a dynamic trust score for the transaction request” See also par 040: “The trust server may calculate a dynamic trust score for the transaction (step 305). The dynamic trust score may indicate a likelihood that the user will complete the transaction in a positive manner.” See par 041 for decentralized web node: “To calculate the dynamic trust score, the trust server may evaluate data from the transaction, the digital identity database, from the dynamic trust score database, and from the third party data providers.”
Mardikar then teaches format a verifiable credential representing the calculated context-based user trust score in par 048: “The trust score provider may write a digital identity entry including the dynamic trust score to the digital identity database (step 306). In various embodiments, the trust score provider may create an asymmetric key pair, including a private key and a public key. The trust score provider may generate the asymmetric key pair using any suitable technique and asymmetric algorithm, such as, for example, RSA, DSA, elliptic curve cryptography, or the like. The trust score provider may encrypt and store the private key. The trust score provider may transmit the public key to the consumer device and/or the merchant, which may encrypt and store locally the public key. In various embodiments, the trust score provider may also encrypt and store locally the public key. In various embodiments, the trust score provider may write the digital identity entry to the digital identity management DLT network. In that regard, the public key may comprise a blockchain address.” Writing a digital identity entry that is an assymetric key pair including a public key and a private key, which comprises a blockchain address where the trust score is written teaching representing as it is the address of the trust score, is a verifiable credential under a broadest reasonable interpretation of the claims in light of the specification.
Mardikar then teaches provide the verifiable credential, in par 048: “the trust score provider may encrypt and store the private key. The trust score provider may transmit the public key to the consumer device and/or the merchant, which may encrypt and store locally the public key.”
Mardikar then teaches wherein the trust-score server and the personal device communicate via a network in par 023: “Trust score provider 103 may be in electronic communication with trust server 105, consumer device 113, one or more third party data providers 111, and/or digital identity database 101.” See also par 022: “The various system 200 components (e.g., trust score provider 103, consumer device 113, merchant 109, etc.) may be in electronic communication with DLT network 201 and may run applications to interact with DLT network 201, transfer files over a network with other computing devices, perform crypto operations, and otherwise operate within system 200.”
Mardikar does not teach stored on a decentralized web node of a user; Access [private data] on the decentralized web node of the user; Transmit to the decentralized web node of the user for storage therein;
DIF teaches using a decentralized web node for data storage related to decentralized identifiers. See abstract.
DIF teaches stored on a decentralized web node of a user in page 20: “To maximize decentralized app and service interoperability, the Collections interface of
Decentralized Web Nodes provides a mechanism to store data relative to shared schemas.”
DIF then teaches Access [private data] on the decentralized web node of the user pages 5-6 where the decentralized web node is requested and then in pages 11-12 where encrypted or signed and encrypted data is requested. See also pages 21-22 where queries to the decentralized web node are taught.
DIF then teaches Transmit to the decentralized web node of the user for storage therein in pages 22-23 where write commands are taught to the DWN which teaches transmit for storage.
It would have been obvious to one ordinarily skilled in the art before the effective filing date of the claimed invention to modify the decentralized identity dynamic trust score teaching of Mardikar with the decentralized web node teachings of DIF because DIF teaches in page 20 that: “by storing data in accordance with a given schema, which may be well-known in a given vertical or industry, apps and services can leverage the same datasets across one another, enabling a cohesive, cross-platform, cross-device, cross-app experience for users.” DIF’s teaching would motivate one to combine the teachings because one would want a cohesive cross platform cross device cross app experience for users so that users have more flexibility. For these reasons one would be motivated to modify Mardikar with DIF.
Mardikar does not teach in accordance with a decentralized Web 5 model utilizing decentralized identifiers (DIDs).
McDowell teaches web 5.0. See page 1.
McDowell teaches in accordance with a decentralized Web 5 model utilizing decentralized identifiers (DIDs) in page 3 where using a social media app as taught in pages 2-3, as well as page 4 where “all the apps we love” as well as “financial institutions teach using in accordance with a decentralized Web 5 model.
It would have been obvious to one ordinarily skilled in the art before the effective filing date of the claimed invention to modify the dynamic trust score teaching of Mardikar with the decentralized Web 5 model teaching of McDowell because McDowell teaches “to provide individuals the possibility to truly own their data, knowing exactly how they are managed, who is using their information and deleting (or not showing) it to certain institutions/people.” Page 2. As this would increase data privacy and security one would be motivated to combine Mardikar with McDowell.
Mardikar does not teach wherein the subset of personally identifiable information is not retained by the trust-score server after the context-based user trust score is calculated.
Mawji teaches methods for calculating a contextual trust score, see abstract.
Mawji teaches wherein the subset of personally identifiable information is not retained by the trust-score server after the context-based user trust score is calculated in par 061: “In some embodiments, verification of the data may be achieved by a document that proves the subject of the subcomponent (e.g., a tax return to prove income) or by peer verification. For instance, employment information may be vetted by peers connected to the target user, and as more peers positively vet the employment information, the higher the subcomponent score becomes. In some embodiments, the information may be deleted once verified. For example, images of passports/IDs may be deleted once the information contained therein is validated.” See also Fig 4 Items 404, 402. See par 041 for teaching of a server: “The processing circuitry included in application server 106 and/or the processing circuitry that executes access application 102 may also perform any of the calculations and computations described herein in connection with calculating a trust score. In some embodiments, a computer-readable medium with computer program logic recorded thereon is included within application server 106.”
It would have been obvious to one ordinarily skilled in the art before the effective filing date of the claimed invention to modify the trust score teaching of Mardikar with the not retaining PII teaching of Mawji because one would want additional data security so that inadvertent leaks, for example by social engineering, do not have a chance of letting this information get into the wrong hands. By not having the information that has been essentially turned into the trust score, one would have the purpose of the identifiable information without the risk of leaking that information. Therefore, one would be motivated to modify Mardikar with Mawji.
Per claims 2 and 12, which are similar in scope, Mardikar, DIF, McDowell, and Mawji teach the limitations of claims 1 and 11, above. Mardikar then teaches the node of a user is provided locally via the personal device and accessed through an application programming interface executing on the processor of the personal device in par 048: “The trust score provider may transmit the public key to the consumer device and/or the merchant, which may encrypt and store locally the public key. In various embodiments, the trust score provider may also encrypt and store locally the public key. In various embodiments, the trust score provider may write the digital identity entry to the digital identity management DLT network. In that regard, the public key may comprise a blockchain address.” See also par 049: “The trust score provider may transmit the dynamic trust score to the merchant (step 306). In various embodiments, the trust score provider may transmit the dynamic trust score directly to the merchant, such as via an API between the trust score provider and the merchant. In various embodiments, the trust score provider may transmit the dynamic trust score to the merchant via the consumer device. See also par 025: “For example, trust server 105 may comprise one or more network environments, servers, computer-based systems, processors, databases, and/or the like. Trust server 105 may comprise at least one computing device in the form of a computer or processor, or a set of computers/processors, although other types of computing units or systems may be used such as, for example, a server, web server, pooled servers, or the like. In various embodiments, trust server 105 may also include software, such as services, APIs, and the like, configured to perform various operations discussed herein.” See also par 030: “In various embodiments, and with reference again to FIG. 2, the consumer device 113 may comprise a digital identity wallet. The digital identity wallet may comprise any suitable distributed-ledger based wallet, such as, for example, ETHEREUM® GETH, ETHEREUM® MetaMask, eth-lightwallet, MyEtherWallet, and/or any other suitable blockchain interface technologies. The digital identity wallet may serve as a blockchain interface accessible by users and applications installed on the consumer device 113. For example, the digital identity wallet may be configured to register the consumer device 113 with the blockchain, request public key (e.g., blockchain address) and private key pairs from DLT network 201, and/or otherwise access and interact with blockchain account information.”
Mardikar does not teach the decentralized web node is accessed through a decentralized web-node interface.
DIF teaches the decentralized web node is accessed through a decentralized web-node interface in pages 5-6 where the decentralized web node is requested and then in pages 11-12 where encrypted or signed and encrypted data is requested. See also pages 21-22 where queries to the decentralized web node are taught. See page 19 where interfaces are taught: “The Decentralized Web Node specification defines well-recognized Decentralized Web Node configurations to maximize interoperability (see Configurations), but implementers may wish to support a custom subset of the Interfaces and features. The Feature Detection interface is the means by which a Decentralized Web Node expresses support for the Interfaces and features it implements.”
It would have been obvious to one ordinarily skilled in the art before the effective filing date of the claimed invention to modify the decentralized identity dynamic trust score teaching of Mardikar with the decentralized web node teachings of DIF because DIF teaches in page 20 that: “by storing data in accordance with a given schema, which may be well-known in a given vertical or industry, apps and services can leverage the same datasets across one another, enabling a cohesive, cross-platform, cross-device, cross-app experience for users.” DIF’s teaching would motivate one to combine the teachings because one would want a cohesive cross platform cross device cross app experience for users so that users have more flexibility. For these reasons one would be motivated to modify Mardikar with DIF.
Per claims 3 and 13, which are similar in scope, Mardikar, DIF, McDowell, and Mawji teach the limitations of claims 1 and 11, above. Mardikar then teaches the node of a user is provided remotely via a application programming interface executing on a processor at a remote server in par 018: “In various embodiments, digital identity database 101 may comprise a distributed ledger. For example, and with reference to FIG. 2, a system 200 may be based on one or more digital ledger technologies (“DLT”), as described herein, and may simplify and automate identity management and related processes by using the DLTs as a distributed and tamper-proof data store.” See also par 019: “System 200 may comprise a digital identity management DLT network 201 configured to maintain a digital ledger, such as blockchain or tangle, in accordance with various embodiments. DLT network 201 may be a peer-to-peer network that is private, federated, and/or public in nature (e.g., ETHEREUM®, Bitcoin, Hyperledger® Indy, etc.). Federated and private networks may offer improved control over the content of the digital ledger and public networks may leverage the cumulative computing power of the network to improve security. DLT network 201 may comprise various digital ledger nodes 202 (e.g., consensus participants) in electronic communication with each other, as discussed further herein. Each digital ledger node 202 may comprise a computing device configured to write blocks to the digital ledger and validate blocks of the digital ledger. The computing devices may take the form of a computer or processor, or a set of computers and/or processors or application specific integrated circuits (ASICs), although other types of computing units or systems may also be used. Exemplary computing devices include servers, pooled servers, laptops, notebooks, hand held computers, personal digital assistants, cellular phones, smart phones (e.g., iPhone®, BlackBerry®, Android®, etc.) tablets, wearables (e.g., smart watches and smart glasses), Internet of things (IOT) devices or any other device capable of receiving data over network. Each computing device may run applications to interact with DLT network 201, communicate with other devices, perform crypto operations, and otherwise operate within system 200. The computing devices may run a client application that can be a thin client (web), hybrid (i.e. web and native, such as iOS and Android), or native application to make API calls to interact with the digital ledger, such as a web3 API compatible with blockchain databases maintained by ETHEREUM®.” See also par 022: “ The various system 200 components (e.g., trust score provider 103, consumer device 113, merchant 109, etc.) may be in electronic communication with DLT network 201 and may run applications to interact with DLT network 201, transfer files over a network with other computing devices, perform crypto operations, and otherwise operate within system 200. “
Mardikar does not teach the decentralized web node, a decentralized web-node interface.
DIF teaches the decentralized web node, a decentralized web-node interface in pages 5-6 where the decentralized web node is requested and then in pages 11-12 where encrypted or signed and encrypted data is requested. See also pages 21-22 where queries to the decentralized web node are taught. See page 19 where interfaces are taught: “The Decentralized Web Node specification defines well-recognized Decentralized Web Node configurations to maximize interoperability (see Configurations), but implementers may wish to support a custom subset of the Interfaces and features. The Feature Detection interface is the means by which a Decentralized Web Node expresses support for the Interfaces and features it implements.”
It would have been obvious to one ordinarily skilled in the art before the effective filing date of the claimed invention to modify the decentralized identity dynamic trust score teaching of Mardikar with the decentralized web node teachings of DIF because DIF teaches in page 20 that: “by storing data in accordance with a given schema, which may be well-known in a given vertical or industry, apps and services can leverage the same datasets across one another, enabling a cohesive, cross-platform, cross-device, cross-app experience for users.” DIF’s teaching would motivate one to combine the teachings because one would want a cohesive cross platform cross device cross app experience for users so that users have more flexibility. For these reasons one would be motivated to modify Mardikar with DIF.
Per claims 4 and 14, which are similar in scope, Mardikar, DIF, McDowell, and Mawji teach the limitations of claims 1 and 11, above. Mardikar further teaches wherein the particular market segment corresponds to retail services in par 037: “The user may initiate the transaction by accessing a webpage or mobile application operated by the merchant, and/or by interacting with the merchant at a kiosk, brick-and-mortar store, or similar physical location.” Mardikar then teaches and the trust score is calculated based on a frequency and an amount of transactions associated with retail purchases via the retail services in par 042: “The historical transaction data may he dynamic and may comprise data about past transactions involving the user, such as, for example, line item data (e.g., specific products or services purchased), transaction authorization data, transaction submission data, historical or recent transactions, etc.” Frequency is taught with transaction submission data which teaches among other things when a transaction was submitted and amount of transactions is taught with line item data as there is a quantity of transactions based on the line items that are comprised in the data. Further retail service is taught in par 043 where purchasing paint or drywall repair products is a retail service as the retail establishment has provided the service of selling goods.
Per claims 5 and 15, which are similar in scope, Mardikar, DIF, McDowell, and Mawji teach the limitations of claims 1 and 11, above. Mardikar further teaches wherein the particular market segment corresponds to hospitality services, and the trust score is calculated based on frequency of visits, reservation activity, or amounts spent within hospitality establishments in par 040: “For example, the transaction may be for the user to rent a hotel room, rental house, etc., and the dynamic trust score may indicate a likelihood that the user is who they say they are, that the user will complete payment for the transaction, and that the user will not damage the rental property.” See for reservation or purchase history within hospitality establishments par 045 where reviews that contain the word hotel, where the review of the user see par 044 is for the user staying in a hotel which is both a reservation and a purchase history within a hospitality establishment: “For example, if the current transaction is for a hotel room, the trust server may more heavily weight reviews which contain the word “hotel” or are from a hotel services provider than reviews which are less relevant to hotels, such as reviews of the user's painting skills. In various embodiments, the trust server may utilize a supervised classification model. Machine learning networks and/or subject matter experts may identify words and phrases that should be weighted more or less.” See also par 042 where transaction data including line item data which teaches amounts spent: “The historical transaction data may he dynamic and may comprise data about past transactions involving the user, such as, for example, line item data (e.g., specific products or services purchased), transaction authorization data, transaction submission data, historical or recent transactions, etc.”
Per claims 6 and 16, which are similar in scope, Mardikar, DIF, McDowell, and Mawji teach the limitations of claims 1 and 11, above. Mardikar then teaches the particular market segment corresponds to financial services, and the trust score is calculated based on income, assets, or payment history associated with the financial services in par 040: “In various embodiments, the transaction may be for escrows for houses, home equity financing, sending rental goods nationally and internationally, etc.” See also par 024: “In accordance with various embodiments, the trust score provider 103 may comprise one or more servers operated by a transaction account issuing entity such as, for example, CITIGROUP®, CAPITAL ONE®, BANK OF AMERICA®, DISCOVER®, SYNCHRONY FINANCIAL®, AMERICAN EXPRESS®, WELLS FARGO®, BARCLAYS®, U.S. BANK®, DELTA AIRLINES®, MORGAN STANLEY®, and/or the like.” These teach under a broadest reasonable interpretation financial services. See also par 42: “The transaction account data may be static and may comprise data about the user, such as, for example, demographic data, transaction account data (e.g., savings account, credit card account, type of credit card account, etc.), an initial risk profile underwriting, loan history, timeliness of payments, transaction dispute history, revolving transaction account balances, delinquency history, a fraud score, a credit score, income, education history, tax history based on zip code, etc.”
Per claims 7 and 17, which are similar in scope, Mardikar, DIF, McDowell, and Mawji teach the limitations of claims 1 and 11, above. Mardikar does not teach the decentralized web node is identified by a decentralized identifier (DID).
DIF teaches the decentralized web node is identified by a decentralized identifier (DID) in page 1: “A Decentralized Web Node (DWN) is a data storage and message relay mechanism entities can use to locate public or private permissioned data related to a given Decentralized Identifier (DID).”
It would have been obvious to one ordinarily skilled in the art before the effective filing date of the claimed invention to modify the decentralized identity dynamic trust score teaching of Mardikar with the decentralized web node teachings of DIF because DIF teaches in page 20 that: “by storing data in accordance with a given schema, which may be well-known in a given vertical or industry, apps and services can leverage the same datasets across one another, enabling a cohesive, cross-platform, cross-device, cross-app experience for users.” DIF’s teaching would motivate one to combine the teachings because one would want a cohesive cross platform cross device cross app experience for users so that users have more flexibility. For these reasons one would be motivated to modify Mardikar with DIF.
Per claim 8, Mardikar, DIF, McDowell, and Mawji teach the limitations of claim 7, above. Mardikar then teaches wherein the decentralized identifier is obtained via a decentralized identifier resolver application programming interface executing on an associated processor of a decentralized identifier resolver server in par 021: “In various embodiments, DLT network 201 may use a Hierarchical Deterministic (HD) solution and may use BIP32, BIP39, and/or BIP44, for example, to generate an HD tree of public addresses. System 200 may include various computing devices configured to interact with DLT network 201 either via a blockchain client, such as GETH, or via API calls using a blockchain as a service provider, such as MICROSOFT AZURE® or Blockapps STRATO, for example. The various computing devices of system 200 may be configured to store digital identity related data.” See also par 041: “To calculate the dynamic trust score, the trust server may evaluate data from the transaction, the digital identity database, from the dynamic trust score database, and from the third party data providers. For example, the data from the digital identity database may indicate that the user is who they claim to be based on various data (e.g., identity claims) stored on or available to the digital identity database.” See also par 035: “In various embodiments, the digital identity may be stored in the digital identity database 101. In various embodiments, the digital identity may be stored in the digital identity wallet in the consumer device, and may be in electronic communication with the digital identity management DLT network. The digital identity may comprise one or more identity claims.”
Per claims 9 and 19, which are similar in scope, Mardikar, DIF, McDowell, and Mawji teach the limitations of claims 1 and 11, above. Mardikar further teaches the context-based user trust score is formatted as a verifiable credential in pars 017:” Digital identity database 101 may be configured to store and maintain digital identity data, including, for example identity claims corresponding to one or more users, For example, an employment claim may indicate that an employer has verified that the user works for the employer. The employment claim may comprise data regarding the employment of the user, together with the verification from the employer. As a further example, a college transcript claim may indicate that a college has verified that the user attended the college. The college transcript claim may comprise transcript data (e.g., classes, grades, etc.) together with the verification from the college. As a further example, a government identity claim may indicate that a government agency, such as the social security administration, has verified that the user is who they claim to be. Sensitive data (e.g., social security numbers) may he omitted from the identity claim to increase security of the data. In various embodiments, the digital identity data may include any other identity claim capable of verifying who the user is” and par 046: “The trust server may calculate a dynamic trust score for the transaction. In various embodiments, the dynamic trust score may be calculated on a scale of 0-100. However, many different scales, including non-numerical scales may be used. As one example, one-third of the dynamic trust score may be based on the likelihood that the user is who they claim to be, one-third of the dynamic trust score may be based on the likelihood that the user will complete payment for the transaction, and one-third of the dynamic trust score may be based on the reputational data of the user. However, those skilled in the art will recognize that many different specific algorithms may be used to calculate the dynamic trust score based on similar data. The trust server may return the dynamic trust score to the trust score provider.”
See in particular par 048: “The trust score provider may write a digital identity entry including the dynamic trust score to the digital identity database (step 306). In various embodiments, the trust score provider may create an asymmetric key pair, including a private key and a public key. The trust score provider may generate the asymmetric key pair using any suitable technique and asymmetric algorithm, such as, for example, RSA, DSA, elliptic curve cryptography, or the like. The trust score provider may encrypt and store the private key. The trust score provider may transmit the public key to the consumer device and/or the merchant, which may encrypt and store locally the public key. In various embodiments, the trust score provider may also encrypt and store locally the public key. In various embodiments, the trust score provider may write the digital identity entry to the digital identity management DLT network. In that regard, the public key may comprise a blockchain address.” Under a broadest reasonable interpretation, creating an asymmetric key pair that is related to the digital identity entry (that is written) in the digital identity database teaches formatted as a verifiable credential because it is a certain version of the trust score.
Per claim 18, Mardikar, DIF, McDowell, and Mawji teach the limitations of claim 17, above. Mardikar further teaches comprising a decentralized identifier resolver server having a processor and a non-transitory computer-readable storage medium, the non-transitory computer-readable storage medium having executable instructions for a decentralized identifier resolver application programming interface, which when executed, cause the processor to operations: in pars 035-036: “In various embodiments, the digital identity may be stored in the digital identity database 101. In various embodiments, the digital identity may be stored in the digital identity wallet in the consumer device, and may be in electronic communication with the digital identity management DLT network. The digital identity may comprise one or more identity claims. For example, an employment claim may indicate that an employer has verified that the user works for the employer; a college transcript claim may indicate that a college has verified that the user attended the college; a government identity claim may indicate that a government agency, such as the social security administration, has verified that the user is who they claim to be; and/or the like.
In various embodiments, the verifying entity may write the identity claim to the digital identity database. In various embodiments, the verifying entity may write the identity claim to the user's digital identity block in the blockchain, and the digital identity wallet may store the various identity claims. The identity claim may be written using protocols such as those utilized by Self Sovrin Identity protocols or HYPERLEDGER® Indy protocols. In various embodiments, other DLT systems, such as Tangle, may be used in addition to, or in place of, blockchain systems.”
Mardikar further teaches locate a DID document associated with the decentralized identifier in a distributed ledger in par 017: “Digital identity database 101 may be configured to store and maintain digital identity data, including, for example identity claims corresponding to one or more users, For example, an employment claim may indicate that an employer has verified that the user works for the employer. The employment claim may comprise data regarding the employment of the user, together with the verification from the employer. As a further example, a college transcript claim may indicate that a college has verified that the user attended the college. The college transcript claim may comprise transcript data (e.g., classes, grades, etc.) together with the verification from the college. As a further example, a government identity claim may indicate that a government agency, such as the social security administration, has verified that the user is who they claim to be.”
Mardikar further teaches and provide the DID document upon request in par 016: “In various embodiments, system 100 may comprise one or more of a digital identity database 101, a trust score provider 103, a trust server 105, a trust score database 107, a merchant 109, a third party data provider 111, and a consumer device 113. One or more system 100 components may be configured to interact with digital identity database 101 to review, collect, and/or submit digital identity information. In that respect, each system 100 component may comprise any suitable entity, system, network, or the like desiring to obtain, review, or submit digital identity information.”
Claim(s) 10 and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Mardikar et al., US PGPUB 20230237491 (“Mardikar”) in view of DIF, Decentralized Web Node, [online] available at: < https://web.archive.org/web/20220610201212/https://identity.foundation/decentralized-web-node/spec/ > archived on Jun 10, 2022 (“DIF”), further in view of McDowell, John, “Web 5.0 versus Web 3.0: What’s the Difference?” [online], available at: < https://www.tradingsim.com/blog/web-5.0-versus-web-3.0 >, published on June 23, 2022 (“McDowell”), further in view of Yang et al., US PGPUB 20210326880 (“Yang”).
Per claims 10 and 20, which are similar in scope, Mardikar, DIF, McDowell, and Mawji teaches the limitations of claims 1 and 11, above. Mardikar does not teach the subset of personally identifiable information accessed by the trust score application programming interface is processed using homomorphic encryption such that the subset of personally identifiable information remains encrypted during computation.
Yang teaches encrypting data in a trusted execution environment (abstract) in order to perform data sharing across institutions. See par 003.
Yang teaches the subset of personally identifiable information accessed by the trust score application programming interface is processed using homomorphic encryption such that the subset of personally identifiable information remains encrypted during computation in par 055: “For example, an identity card number or a mobile phone number that is used as the user ID is encrypted and sent to the financial institution, or the previously-mentioned digest value obtained by performing hash processing is encrypted and sent to the financial institution. For sending of the encrypted user ID to the financial institution, the user ID can be encrypted and sent to the financial institution by the sales agency in a symmetric or asymmetric encryption method.” See also par 075: “Privacy protection can be implemented by using a plurality of technologies, such as cryptography technologies (such as homomorphic encryption or zero-knowledge proof), hardware privacy technologies, and network isolation technologies. The hardware privacy protection technologies typically includes a trusted execution environment (TEE).” For teaching that “subset of personally identifiable information” is encrypted during computation, see par 076: “The TEE can function as a hardware black box. Codes and data executed in the TEE cannot be peeped even at an operating system layer, and can be operated only by using an interface predefined in the codes. In terms of efficiency, because of the black box nature of the TEE, an operation in the TEE is performed on plaintext data instead of a complex cryptographic operation in homomorphic encryption, and efficiency of a calculation process is hardly lost. Therefore, by deploying the TEE environment on the blockchain node, privacy needs in the blockchain scenario can be satisfied to a great extent while a performance loss is relatively small.” PII previously taught by Mardikar however privacy protection taught in par 075 of Yang which covers any information desired to keep private.
It would have been obvious to one ordinarily skilled in the art before the effective filing date of the claimed invention to modify the trust score teaching of Mardikar with the homomorphic encryption teaching of Yang because Yang teaches in pars 003-004: “However, privacy protection and trustworthiness of information during data exchange and sharing is always a challenge to industry development. Based on this, how to provide a secure and trustworthy information sharing method becomes an urgent problem that needs to be solved.” And also in par 075 where homomorphic encryption solves a privacy problem related to storing on a blockchain which is a public ledger. As this teaching would enable blockchain to be used but privacy protection ensured, one would be motivated to combine Mardikar with Yang to provide this benefit.
Therefore, claims 1-20 are rejected under 35 USC 103.
Response to remarks:
35 USC 112
Applicant’s arguments have been considered and most of the 112(a) rejections overcome except for one where applicant did not show how reservation activity was used to calculate a trust score, per claims 5 and 15. Applicant must show how this information was used to calculate a trust score, in the original disclosure.
35 USC 101
Applicant respectfully traverses the rejection of claims 1 to 20 under 35 U.S.C. § 101. As amended, independent claims 1 and 11 are directed to specific computer-implemented methods and systems that define how networked computing components handle, transform, and store identity-related data in a decentralized identity infrastructure. When properly construed as a whole, the claims are not directed to an abstract idea, but to a concrete technological solution to problems arising in distributed computer systems, particularly secure handling of personally identifiable information in decentralized identity environments.
Although the claims involve the concept of assessing user trust, the claims do not merely recite trust evaluation as a mental process or business practice. Rather, they recite a particularized technical workflow in which a trust-score server accesses personally identifiable information from a decentralized web node using application programming interfaces, processes that information to derive a context-specific trust value, formats the result as a verifiable credential, and stores that credential back into a user-controlled decentralized web node, while expressly requiring that the personally identifiable information not be retained by the trust-score server after calculation. This sequence of steps cannot be performed mentally and is inseparably tied to the operation of networked computer systems.
Examiner disagrees, these claims only apply technical elements, many of which are generic and recited at a high level, to the concept of calculating a trust score. They are separable under clear guidance from the USPTO which is based on case law, see Alice. Applicant’s arguments are not persuasive because Applicant can’t answer this: Why is it not possible to calculate a trust score separate from the operation of networked computer systems? It can, because a network of computer systems does not need a trust score, this is a certain method of organizing human activity to verify identity of people. Nor does a trust score need a network of computer systems, it is just a decision made to take information (words, numbers) and decide that it means something (a score). Therefore this is unpersuasive.
Under Alice Step 2A, Prong One, even if the Examiner were to characterize the claims as reciting an abstract concept related to trust or authorization, the claims as a whole are not focused on that concept. The focus of the amended claims is the technical manner in which sensitive identity data is accessed, processed, credentialized, and discarded within a decentralized Web 5 architecture using decentralized identifiers and decentralized web nodes. The claims define where data resides, how it is accessed, how long it exists within a given system component, and in what form the output is persisted. These are technical constraints on system behavior, not statements of a business objective.
The characterization is based on steps which verify a user who wants to purchase something. The amended claims are similar to the previous claims and the previous arguments are maintained.
Under Step 2A, Prong Two, the amended claims integrate any alleged abstract concept into a practical application. The claims require that personally identifiable information remain under user control in a decentralized web node, that only a derived credential be stored and shared, and that raw personally identifiable information be transiently processed and not retained by the trust- score server. This configuration alters the conventional operation of trust and identity systems by eliminating centralized storage of sensitive data and by enforcing a specific data lifecycle that reduces attack surface and improves privacy and security in distributed networks. The claimed invention therefore provides a concrete improvement to computer and network functionality, not merely the automation of a preexisting human activity.
Not retaining information that is sensitive is a certain method of organizing human activity. This argument is unpersuasive because it asks the examiner to disregard that information may be ‘not retained’ by shredding paper, or erasing something with an eraser, or eating paper as is done in the movies. There is nothing inherently technical about not retaining information.
Even assuming arguendo that the claims recite an abstract idea, the amended claims recite significantly more than any such idea under Alice Step 2B. The requirement that personally identifiable information is accessed from a decentralized web node via an application programming interface, processed to produce a verifiable credential, stored back into the decentralized web node, and explicitly not retained by the trust-score server imposes meaningful technical limitations that are neither generic nor conventional. The Examiner has not identified, and the record does not establish, that such a decentralized identity workflow with enforced non- retention of sensitive data was well-understood, routine, or conventional at the time of filing.
Applicant is correct that Examiner has not identified that something is well-understood, routine, and conventional. This is not required under the guidance. As was stated above in each rejection, the findings in the practical application section are carried over. See MPEP 2106:
“Thus, in Step 2B, examiners should:
• Carry over their identification of the additional element(s) in the claim from Step 2A Prong Two;
• Carry over their conclusions from Step 2A Prong Two on the considerations discussed in MPEP §§ 2106.05(a) - (c), (e) (f) and (h):”
Examiner’s rejection follows the guidance.
The Examiner previously characterized the recited decentralized web nodes, decentralized identifiers, and verifiable credentials as mere "apply it" elements. That characterization is no longer applicable. The amended claims do not merely invoke these components; they require them to operate in a specific architectural arrangement that governs data access, transformation, persistence, and deletion across distributed computing systems. These limitations materially affect how the system functions at runtime and how data flows between components, and therefore constitute an inventive concept that transforms any alleged abstract idea into patent-eligible subject matter.
Examiner disagrees. These elements are claimed in a high level, apply it manner similar to each prior set of claims. They operate in their ordinary capacity, see MPEP 2106.05(f)(2) because they are claimed only as performing the task they are expected to perform, and no technical detail is included that further limits how they function. Therefore, this rejection is maintained.
35 USC 103
Rather, the Office must identify a teaching, suggestion, or motivation in the prior art itself that would have prompted the particular architectural modifications required by the claims, and must account for differences in system design, data control, and operational objectives that may weigh against such a combination.
This is not correct as motivation may also be found outside of art. See MPEP 2143.01:
“A "motivation to combine may be found explicitly or implicitly in market forces; design incentives; the ‘interrelated teachings of multiple patents’; ‘any need or problem known in the field of endeavor at the time of invention and addressed by the patent’; and the background knowledge, creativity, and common sense of the person of ordinary skill." Zup v. Nash Mfg., 896 F.3d 1365, 1371, 127 USPQ2d 1423, 1427 (Fed. Cir. 2018) (quoting Plantronics, Inc. v. Aliph, Inc., 724 F.3d 1343, 1354 [107 USPQ2d 1706] (Fed. Cir. 2013) (citing Perfect Web Techs., Inc. v. InfoUSA, Inc., 587 F.3d 1324, 1328 [92 USPQ2d 1849] (Fed. Cir. 2009) (quoting KSR, 550 U.S. at 418-21)). See MPEP § 2143 regarding the need to provide a reasoned explanation even in situations involving common sense or ordinary ingenuity. See also MPEP § 2144.05, subsection II, B.”
See also MPEP 2144(II):
“See also Dystar Textilfarben GmbH & Co. Deutschland KG v. C.H. Patrick, 464 F.3d 1356, 1368, 80 USPQ2d 1641, 1651 (Fed. Cir. 2006) ("Indeed, we have repeatedly held that an implicit motivation to combine exists not only when a suggestion may be gleaned from the prior art as a whole, but when the ‘improvement’ is technology-independent and the combination of references results in a product or process that is more desirable, for example because it is stronger, cheaper, cleaner, faster, lighter, smaller, more durable, or more efficient. Because the desire to enhance commercial opportunities by improving a product or process is universal—and even common-sensical—we have held that there exists in these situations a motivation to combine prior art references even absent any hint of suggestion in the references themselves.").” (emphasis added).
A teaching suggestion or motivation within the art is one way of showing motivation but is not a requirement. There does not have to be a suggestion in the art itself. Therefore, as Applicant’s statement is contrary to guidance which is based on case law, it is not persuasive.
The Examiner's rejection does not establish a prima facie case of obviousness because the cited references, either alone or in combination, fail to teach or suggest the claimed architecture and data flow recited in independent claims 1 and 11, and the Examiner does not provide a reasoned explanation as to why a person of ordinary skill in the art would have been motivated to modify Mardikar in the manner required by the claims.
By contrast, claims 1 and 11 require that personally identifiable information be stored on a decentralized web node of the user, that access to a subset of that information be granted in connection with a request for access to a premium service related to a particular market segment, that a trust score be calculated based on that subset, that the resulting trust score be formatted as a verifiable credential, that the verifiable credential be provided back to the user's decentralized web node for storage, and that the trust-score server not retain the personally identifiable information after calculation. This user-centric data model is fundamentally different from the centralized merchant-centric architecture taught by Mardikar.
Neither DIF nor McDowell remedies these deficiencies. DIF describes decentralized identity primitives such as decentralized identifiers, verifiable credentials, and decentralized data storage, but it does not disclose computing context-based trust scores, processing transaction- specific subsets of personally identifiable information to derive such scores, or returning computed trust artifacts to a user-controlled data store. DIF provides architectural building blocks, not an integrated system that combines trust scoring with selective access, credentialization, and non- retention of sensitive data as required by the claims.
McDowell similarly provides high-level discussion of Web 5.0 concepts and motivations, emphasizing user sovereignty over data and decentralized web nodes. McDowell does not disclose any operational workflow for calculating trust scores, formatting computed values as verifiable credentials, or coordinating a trust-score server and a personal device via application programming interfaces to access, process, credentialize, and discard personally identifiable information. McDowell's discussion is aspirational and conceptual, not instructional as to the claimed technical solution.
The Examiner's combination effectively assumes that Mardikar's centralized trust scoring system could simply be relocated into a decentralized identity environment. However, the Examiner does not explain why a person of ordinary skill in the art would have been motivated to fundamentally redesign Mardikar's system to return trust scores to users as verifiable credentials
Applicant’s arguments do not pertain to any part of the rejection and are unpersuasive. For example, Applicant characterizes Mardikar, which shows specifically where most of the limitations are taught, as a “centralized trust scoring system” however Mardikar teaches blockchain throughout and teaches specifically (though one ordinarily skilled would know this) that: “In various embodiments, the blockchain may implement smart contracts that enforce data workflows in a decentralized manner.” Par 070. Therefore Mardikar’s teaching is not “centralized.” Applicant’s argument, which hinges on this, is therefore unpersuasive. Examiner does not assume that it could “simply” be relocated into a decentralized identity environment, because it already is.
Applicant’s arguments about DIF are merely attacking a single reference where a combination is asserted. DIF in combination with Mardikar teach the limitations. Then, The argument that McDowell is “aspirational” is not based on law: the question is, does it teach the Web5 limitation or does it not? Note that cartoons and fictional movies have been cited as prior art: see https://ipcopy.blog/2015/02/12/prior-art-in-strange-places-the-beano-donald-duck-and-2001-as-prior-art/. See also 35 USC 102:
(a) NOVELTY; PRIOR ART.—A person shall be entitled to a patent unless—
(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention; or
Here, Web5 was “described in a printed publication.” It does not have to be in public use, on sale, or otherwise available to the public.
Therefore, the rejection is maintained. Further, the limitation only says the following: “in accordance with a decentralized Web 5 model” And therefore the teaching of McDowell for this “in accordance” limitation is more than sufficient.
However, the Examiner does not explain why a person of ordinary skill in the art would have been motivated to fundamentally redesign Mardikar's system to return trust scores to users as verifiable credentials stored in user-controlled decentralized web nodes, rather than retaining such scores in issuer- or merchant-controlled databases as Mardikar expressly teaches.
As shown and not refuted, Mardikar teaches decentralized systems. So it would not fundamentally redesign Mardikar’s system.
The Examiner therefore relies on impermissible hindsight by using Applicant's disclosure as a roadmap to combine disparate teachings from Mardikar, DIF, and McDowell without an articulated rationale grounded in the references themselves. The cited art does not teach or suggest the claimed coordination of user-controlled decentralized web nodes, selective access to subsets of personally identifiable information, credentialization of a context-based trust score, storage of the credential in the user's decentralized web node, and enforced non-retention of the underlying data by the trust-score server.
Because the motivation may come from different sources, the examiner’s rejection is sound. Applicant narrows the allowable types of motivations to combine, but Applicant has been presented with the guidance by Examiner and therefore the arguments are shown to be unpersuasive. As Examiner has followed the guidance, and has fully articulated this, Applicant’s arguments are fully considered but unpersuasive.
Per 10 and 20, this is based on the independent claims. As Applicant’s arguments were unpersuasive above, the rejections are maintained.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See 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.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to RICHARD W. CRANDALL whose telephone number is (313)446-6562. The examiner can normally be reached M - F, 8:00 AM - 5:00 PM.
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, Anita Coupe can be reached at (571) 270-3614. 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.
/RICHARD W. CRANDALL/ Primary Examiner, Art Unit 3619
Prosecution Insights