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 .
Specification
Applicant’s abstract is objected to. Applicant’s Abstract is on a WO 2023/172884A1 document.
Applicant is reminded of the proper language and format for an abstract of the disclosure.
The abstract should be in narrative form and generally limited to a single paragraph on a separate sheet within the range of 50 to 150 words in length. The abstract should describe the disclosure sufficiently to assist readers in deciding whether there is a need for consulting the full patent text for details.
The language should be clear and concise and should not repeat information given in the title. It should avoid using phrases which can be implied, such as, “The disclosure concerns,” “The disclosure defined by this invention,” “The disclosure describes,” etc. In addition, the form and legal phraseology often used in patent claims, such as “means” and “said,” should be avoided.
See MPEP § 608.01(b) for guidelines for the preparation of patent abstracts.
Claim Objections
Claim 1-15 are objected to because of the following informalities.
In claim 1, applicant recites “wherein said software application further comprises another module,” where, for clarity and consistency, this should read: “wherein said software application further comprises a second module.”
Applicant later recites “wherein the module of said host server computer system thereby also enables the realtor users to use the another module of said software application,” where, for clarity and consistency, this should read: “wherein the module of said host server computer system thereby also enables the realtor users to use the second module of said software application.”
Applicant later recites “wherein said software application further comprises yet another module for enabling the users to create chat invites,” where, for clarity and consistency, this should read: “wherein said software application further comprises a third module for enabling the users to create chat invites.”
The dependent claims are objected to by virtue of their dependency. Appropriate correction is required.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) are:
Claim 1: a module for enabling registration of realtor users and other users, enabling use and storage of a username and a password for each user, and the creation and using of a digital wallet for allowing revocable authentication of users' access to the system using the DID network,
Claim 1: another module for enabling realtor users to issue and revoke credentials to other users as one or more of, a bona fide neighbor, a bona fide owner, a bona fide potential buyer, and a bona fide seller, of the subject property of the anticipated real estate transaction;
Claim 1: a module for validating the realtor users and the other users' login user identifications and passwords to enable opening of said software application by the users on their mobile
Claim 1: the module of said host server computer system thereby also enables the realtor users to use another module of said software application on their mobile smartphones to issue and revoke the credentials;
Claim 1: yet another module for enabling the users to create chat invites, for users to accept the chat invites, and to thus enable the users to chat peer-to-peer with one another,
Claim 6: a software application module for verifying at least one of a valid email address or a valid phone number of each user;
See [0026 – 0029] and [0051] for support, for example.
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
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 -15 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception without significantly more.
Step 1 (The Statutory Categories): Is the claim to a process, machine, manufacture, or composition of matter? MPEP 2106.03.
Per Step 1, claim 1-5 is to a system (i.e., a machine), claim 6 -15 to a method (i.e., a process). Thus, the claims are directed to statutory categories of invention. However, the claims are rejected under 35 U.S.C. 101 because they are directed to an abstract idea, a judicial exception, without reciting additional elements that integrate the judicial exception into a practical application.
The analysis proceeds to Step 2A Prong One.
Step 2A Prong One: Does the claim recite an abstract idea, law of nature, or natural phenomenon? MPEP 2106.04.
The abstract idea of claim 1 is:
A system for enabling secure communications between system users regarding a subject property of a specific anticipated real estate transaction, the system being adapted for accessing and using a blockchain decentralized identifier (DID) network for confirming the users' identities, the system being further adapted for accessing and using a mediator subsystem network on the Internet for the receiving of chat messages and the delivery of chat messages,
comprising:
a software application for download to users' mobile smartphones and comprising a module for enabling registration of realtor users and other users, enabling use and storage of a username and a password for each user, and the creation and using of a digital wallet for allowing revocable authentication of users' access to the system using the DID network,
wherein said software application further comprises another module for enabling realtor users to issue and revoke credentials to other users as one or more of, a bona fide neighbor, a bona fide owner, a bona fide potential buyer, and a bona fide seller, of the subject property of the anticipated real estate transaction;
a host server computer system having a module for validating the realtor users and the other users' login user identifications and passwords to enable opening of said software application by the users on their mobile smartphones to enable the opening of the users' digital wallets on their mobile smartphones, wherein the module of said host server computer system thereby also enables the realtor users to use the another module of said software application on their mobile smartphones to issue and revoke the credentials;
wherein said software application further comprises yet another module for enabling the users to create chat invites, for users to accept the chat invites, and to thus enable the users to chat peer-to-peer with one another, wherein the chats are communicated asynchronously via the mediator subsystem network on the Internet, and wherein the chats are secured since the users have logged in to the software applications on the users' smartphones and the users' identities have already been confirmed via the users' blockchain-secured wallets on the DID network.
The abstract idea of claim 6 is:
A method of authenticating users and issuing of credentials pertaining to a subject property of a specific anticipated real estate transaction, the method being adapted for accessing and using a blockchain decentralized identifier (DID) network for confirming the users' identities, comprising the steps of:
providing a software application for users to download and install on their mobile smartphones;
accessing a host server network with a software application module for verifying at least one of a valid email address or a valid phone number of each user;
registering each verified user on a host server computer system;
issuing a blockchain secured digital wallet to each user's smartphone;
creating in the user's digital wallet a revocable authentication for use in verifying a user's identity, enabling granting of trusted status, and replicating the user's public digital identity to be publicly available in the distributed ledger on the DID network; and
enabling issuing of a credential by a realtor user to the digital wallet of another user of one or more of, a bona fide neighbor, a bona fide owner, a bona fide buyer, or a bona fide seller, as to the subject property of the specific anticipated real estate transaction.
The abstract idea steps italicized above are those which could be performed mentally, including with pen and paper. The steps describe, at a high level, of enabling and validating a secure communication. If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the mind, including observations, evaluations, judgements, and/or opinions, then it falls within the Mental Processes – Concepts Performed in the Human Mind grouping of abstract ideas. Accordingly, the claim recites an abstract idea.
Additionally, and alternatively, the abstract idea steps italicized above relate to rules and instructions of creating, registering, confirming and securing communication between people, which constitutes a process that, under its broadest reasonable interpretation, covers managing personal behavior relationships, interactions between people. This is further supported by [0031-0033] of applicant’s specification as filed. If a claim limitation, under its broadest reasonable interpretation, covers managing personal behavior relationships, interactions between people, including social activities, teaching, and/or following rules or instructions, then it falls within the Certain Methods of Organizing Human Activity – Managing Personal Behavior Relationships, Interactions Between People grouping of abstract ideas. Accordingly, the claim recites an abstract idea.
Step 2A Prong Two: Does the claim recite additional elements that integrate the judicial exception into a practical application? MPEP 2106.04.
This judicial exception is not integrated into a practical application because the additional elements are merely instructions to apply the abstract idea to a computer, as described in MPEP 2106.05(f).
Claim(s) 1 recites the following additional elements: A system; the system being adapted for, using a blockchain decentralized identifier (DID) network for confirming the users' identities, the system being further adapted for accessing and using a mediator subsystem network on the Internet for; a software application for download to users' mobile smartphones and comprising a module for; to enable opening of said software application by the users on their mobile smartphones to enable the opening of the users' digital wallets on their mobile smartphones, wherein the module of said host server computer system thereby also; to use the another module of said software application on their mobile smartphones; wherein said software application further comprises yet another module; wherein the chats are communicated asynchronously via the mediator subsystem network on the Internet, and wherein the chats are secured since the users have logged in to the software applications on the users' smartphones and the users' identities have already been confirmed via the users' blockchain-secured wallets on the DID network.
Claim(s) 6 recites the following additional elements: the method being adapted for accessing and using a blockchain decentralized identifier (DID) network; providing a software application for users to download and install on their mobile smartphones; a host server network with a software application module; on a host server computer system; issuing a blockchain secured digital wallet to each user's smartphone; creating in the user's digital wallet a revocable authentication for use in; in the distributed ledger on the DID network;
Examiner notes that these additional elements, beyond being used to facilitate the tasks of the abstract idea, are claimed in a results-oriented manner that lacks detail of the mechanism for accomplishing the result and is equivalent to the words “apply it”, per MPEP 2106.05(f).
These elements are merely instructions to apply the abstract idea to a computer, per MPEP 2106.05(f). Applicant has only described generic computing elements in their specification, as seen in [0015] of applicant’s specification as filed for example.
Further, the combination of these elements is nothing more than a generic computing system applied to the tasks of the abstract idea. Because the additional elements are merely instructions to apply the abstract idea to a generic computing system, they do not integrate the abstract idea into a practical application, when viewed in combination. See MPEP 2106.05(f).
Therefore, per Step 2A Prong Two, the additional elements, alone and in combination, do not integrate the judicial exception into a practical application. The claim is directed to an abstract idea.
Step 2B (The Inventive Concept): Does the claim recite additional elements that amount to significantly more than the judicial exception? MPEP 2106.05.
Step 2B involves evaluating the additional elements to determine whether they amount to significantly more than the judicial exception itself.
The examination process involves carrying over identification of the additional element(s) in the claim from Step 2A Prong Two and carrying over conclusions from Step 2A Prong Two pertaining to MPEP 2106.05(f).
The additional elements and their analysis are therefore carried over: applicant has merely recited elements that facilitate the tasks of the abstract idea, as described in MPEP 2106.05(f).
Further, the combination of these elements is nothing more than a generic computing system with machine learning models. When the claim elements above are considered, alone and in combination, they do not amount to significantly more.
Therefore, per Step 2B, the additional elements, alone and in combination, are not significantly more. The claims are not patent eligible.
The analysis takes into consideration all dependent claims as well:
Dependent claims 2-3, 5, 7 - 9 contains additional steps that further narrow the abstract idea above.
Claim 2, 3 and 5 recites the following additional elements: the User digital wallet
Claim 7 recites the following additional elements: further adapted for accessing and using a mediator subsystem network on the Internet; mediator subsystem network the chat request invitation
Claim 8 recites the following additional elements: the mediator subsystem network
Claim 9 recites the following additional elements: mobile smartphone software applications.
Similar to above, these additional elements are simply facilitating the tasks of the abstract idea, per MPEP 2106.05(f). Whether viewed alone or in combination, this does not integrate the abstract idea into practical application and/or add significantly more. The claims are ineligible.
Accordingly, claims 1-15 are rejected under 35 USC § 101 as being directed to non-statutory subject matter.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
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- 5 and 7-15 are rejected under 35 U.S.C. 103 as being unpatentable over Smith et al [2017/0317997], hereafter Smith, in view of Friedman et al [2014/0089126], hereafter Friedman, in further view of Leavy et al [2018/0019981], hereafter Leavy.
As per claim 1;
Smith discloses;
A system for enabling secure communications between system users
A computer system that provides a secure and decentralized portal to enable secure communication
{[0166] The attestation transaction that an attestor and user creates using these protocols may be used to provide a prospective communication partner or transaction partner with positive identification of a digital entity, such as a merchant website or financial institution, in lieu of a central authority. As a result, participants in a transaction or communication using the protocols described herein may be able to use key exchange techniques as known in the art and thus establish encrypted communication without relying on a CA vendor.
[0177] The system 100 having one or more communication networks 190 may utilize any data network(s) or internetwork(s) suitable for communicating data and control information among participants in the system 100.
[0126] A communication channel is any method of exchanging information between two parties. This could include a wired link, a wireless link, a person to person wireless link such as Bluetooth or NFC, or an in-person exchange. It is understood that there is a plethora of different protocols that can be used to exchange information over a communication channel. A preferred communication channel is the communication channel that a user chooses to use before trying other communication channels. The preferred communication channel may be context or circumstance dependent.}
the system being adapted for accessing and using a blockchain decentralized identifier (DID) network for confirming the users' identities,
Verification of user identity using a decentralized identifier
{[0121] A merchant may include without limitation a place of business or commerce that offers products or services to users or other merchants, and who has a need to know with certainty that the user is authentic, and/or that the information presented by the user is authentic and belongs to that user, and/or that the property that the user claims to be their own actually belongs to the user. An identity validation service provider may include without limitation a person or object or business that provides the service of confirming a user's information that the attestor will attest to is valid and real and belongs to the user.
[0165] In another aspect, any of the attestation protocol, validation protocol, or verification protocol described herein may be used instead of a traditional certificate authority (CA) vendor. More broadly, these methods and protocols are generally used for attesting to the authenticity of a company and putting this attestation on a centralized or distributed ledger. Issuing an identity for a company does not have to be purely for replacing CAs. The process of validating a company and putting it on the blockchain could have many applications which include but are not limited to using the attested company data in web transactions in place of a standard certificate.
the system being further adapted for accessing and using a mediator subsystem network on the Internet for the receiving of chat messages and the delivery of chat messages, comprising:
a software application for download to users' mobile smartphones and comprising a module for enabling registration of realtor users and other users,
Mediator subsystem (third-party connection) for registration and creation of identity for secure transaction
{[0121] A merchant may include without limitation a place of business or commerce that offers products or services to users or other merchants, and who has a need to know with certainty that the user is authentic, and/or that the information presented by the user is authentic and belongs to that user, and/or that the property that the user claims to be their own actually belongs to the user. An identity validation service provider may include without limitation a person or object or business that provides the service of confirming a user's information that the attestor will attest to is valid and real and belongs to the user…..
[0123] Additionally, the user's own digital wallet can be backed up to a third-party website or service. A third-party cosigner is a party that participates in making a transaction with a multisig wallet that requires signatures from M of N keys before the attestation is finalized and broadcast to the blockchain network…..
[0162] The attestor may also perform a validation protocol to ascertain that the user is not fraudulent and that the submitted information is authentic. The validation protocol may use third party Identity Validation Service Providers such as ThreatMetrix® to authenticate the user's information. An attestation site website, or application controlled by an attestor, performing a validation protocol, may call, text, phone, message, or send physical mail to addresses provided by the user……}
{[0162] An attestation site, website, or application controlled by an attestor may allow a user to register and create an identity and to submit their information such as a social security number. The attestor may perform an attestation protocol in order to authenticate the user's information and to create an attestation transaction on a centralized or distributed ledger, which serves as a certification that the user's information has been authenticated……
[0169] The attestor kiosk or station may present a QR code or other motion code to the user, prompting the user to download an attestor's application on the user's mobile device. The user may then use the attestor application on their mobile phone or device to scan additional QR or motion codes in order to receive any generated public keys, private keys, or public or private attest keys related to the one or more attestation transactions of their information…}
Examiner notes that terms like realtor are mere labeling terms for the user and don't distinguish structurally and/or functionally from the prior art and therefore accorded little patentable weight. See MPEP 2111.05 and explanation regarding nonfunctional descriptive material. This interpretation holds for other mentions of the term realtor in the claim.
enabling use and storage of a username and a password for each user,
a user registers in the secured system using a username and a password
{[0224] The method of FIG. 13b shows a further embodiment of the method described in FIG. 13a. As before, in step 1350, with the attempt to receive service, the individual 1310 sends to the organization information and their public key. In step 1352, when the organization receives information and the public key from an individual 1310 that is seeking to make a transaction or receive a service, the organization can send this information to the attestor 1330. In one embodiment, the attestor may verify that the user indicated in the information sent by the organization is a registered user that holds a valid account at an attestor. …}
and the creation and using of a digital wallet for allowing revocable authentication of users' access to the system using the DID network,
connecting to the digital wallet by the user for attestation and revocation of rights
{[0205] In one embodiment, the merchant application may facilitate the indicating of the user to start processing the transaction through an electronic display. In one embodiment, the electronic display or presentation has a login or entry screen corresponding to the merchant's website and receiving an indication from a user to start processing a transaction comprises receiving login information from the user and validating the login information.
[0122-123] A digital wallet is a collection of keys that controls digital assets or funds. It may allow a user to make electronic commerce transactions easily and securely. A digital wallet may support a multisig script, in other words the wallet may be able to take multiple keys to create an attestation address….
[0123] A digital wallet provider is a provider that stores a user's digital wallet on the user's behalf, usually on a remote server, so that the information is easily accessed from anywhere. For the purposes of this application the user can also have their own custom digital wallet that can exist on their own phone or device and not on a remote server. Additionally, the user's own digital wallet can be backed up to a third-party website or service….}
Revoking
{[0133] A transaction is used to transfer an amount of cryptocurrency (e.g. dust) that contains all necessary attestations, moving data between different keys or different digital wallets. A transaction is always for the purpose of creating new hashes and putting them in a user's digital wallet, or for revoking previously-attested data and removing such data from a user's digital wallet….
[0145-146] Similarly, if the user wanted to revoke only part of the attested information, then the transaction may be revoked by spending the dust, and a new transaction with updated user information may be written. This allows attested information to change, for instance, if the user moves and has a new home address, or changes their telephone number…}
wherein said software application further comprises another module for enabling realtor users to issue and revoke credentials to other users as one or more of, a bona fide neighbor, a bona fide owner, a bona fide potential buyer, and a bona fide seller;
enabling of software applications on user phones and revocation of ownership
{[0120] A validator may include without limitation a validation site or device, any user or attestor, a border agent, a peace officer, a military post, an officer, a Transportation Security Administration (TSA) agent, a hotel clerk, a merchant, a transaction partner, a seller, a buyer, a credit verification agency, a bank, a store, a partner, a companion, an employee, an employer, and the like. …
Bona fide owner represented by user’s digital wallet
[0122-124] A digital wallet is a collection of keys that controls digital assets or funds. It may allow a user to make electronic commerce transactions easily and securely. A digital wallet may support a multisig script, in other words the wallet may be able to take multiple keys to create an attestation address.}
Revoke credentials
{[0145-146] Similarly, if the user wanted to revoke only part of the attested information, then the transaction may be revoked by spending the dust, and a new transaction with updated user information may be written. This allows attested information to change, for instance, if the user moves and has a new home address, or changes their telephone number….
[0159] In another aspect, an attestor may, in cooperation with a user, or in cooperation with a third-party cosigner to the user's attested information but not alone, use the revocation protocol to revoke an attestation for a user's information. A user can do this with cooperation of an attestor or a third party, and a third party can do it with cooperation of the user or the attestor….}
a host server computer system having a module for validating the realtor users and the other users' login user identifications and passwords to enable opening of said software application by the users on their mobile smartphones to enable the opening of the users' digital wallets on their mobile smartphones,
enabling the connection of user’s mobile smartphones by a decentralized software application
{[0123-125] A digital wallet provider is a provider that stores a user's digital wallet on the user's behalf, usually on a remote server, so that the information is easily accessed from anywhere. For the purposes of this application the user can also have their own custom digital wallet that can exist on their own phone or device and not on a remote server. Additionally, the user's own digital wallet can be backed up to a third-party website or service. A third-party cosigner is a party that participates in making a transaction with a multisig wallet that requires signatures from M of N keys before the attestation is finalized and broadcast to the blockchain network.
[0125] An application, also called an app, may include without limitation any mobile, desktop, kiosk-based, cloud-based, home, enterprise, server, client-server, SaaS, embedded, neural, microcontroller-based, firmware-based, chip-based, chemically-executed algorithms, software, procedures, methods, or techniques or the like running on a computing platform that can execute instructions and process inputs to produce outputs….}
Validating the user:
{[0162] An attestation site, website, or application controlled by an attestor may allow a user to register and create an identity and to submit their information such as a social security number. The attestor may perform an attestation protocol in order to authenticate the user's information and to create an attestation transaction on a centralized or distributed ledger, which serves as a certification that the user's information has been authenticated. The attestor may also perform a validation protocol to ascertain that the user is not fraudulent and that the submitted information is authentic. The validation protocol may use third party Identity Validation Service Providers such as ThreatMetrix® to authenticate the user's information.
[0200] A user is directed to an attestor's website or app (step 602 of FIG. 6). The attestor site prompts the user to apply for new account and to provide information (e.g. PII) (step 603 of FIG. 6). The attestor site receives from the user an indication to create the new account and receives from the user the information (e.g. PII) to be attested, as well as any supporting documents and/or other evidence that helps verify the information (step 604 of FIG. 6).}
wherein the module of said host server computer system thereby also enables the realtor users to use the another module of said software application on their mobile smartphones to issue and revoke the credentials; and
enabling the connection of user’s mobile smartphones by a decentralized software application
{[0124] … A site may also include a location or destination in a virtual world, or may exist in an overlay created with an augmented reality system. A site may move with the motion of a user or be stationary and fixed with respect to a map. A site could be anything or anywhere you want to be identified, for instance a place, real or virtual, where you need to show identity or use identity….
[0145-146] Similarly, if the user wanted to revoke only part of the attested information, then the transaction may be revoked by spending the dust, and a new transaction with updated user information may be written. This allows attested information to change, for instance, if the user moves and has a new home address, or changes their telephone number.
[0159] In another aspect, an attestor may, in cooperation with a user, or in cooperation with a third-party cosigner to the user's attested information but not alone, use the revocation protocol to revoke an attestation for a user's information. A user can do this with cooperation of an attestor or a third party, and a third party can do it with cooperation of the user or the attestor…}
Enabling the users to use another module
{[0189] The revocation protocol 212 may utilize a third party digital wallet provider or other third party cosigner, or it may be performed solely by the user 110 or attestor 120, or by the user 110 and the attestor 120. The revocation protocol 212 may be performed using a mobile application or a web-based client or cloud service, as examples. A participant may be allowed to revoke an attestation they have made in the past by signing a new transaction, spending the dust corresponding to the original attestation….}
wherein the chats are secured since the users have logged in to the software applications on the users' smartphones and the users' identities have already been confirmed via the users' blockchain-secured wallets on the DID network.
Enabling a decentralized application using blockchain network to be linked to a digital wallet for accessing the network.
{[0122-126] A digital wallet is a collection of keys that controls digital assets or funds. It may allow a user to make electronic commerce transactions easily and securely. A digital wallet may support a multisig script, in other words the wallet may be able to take multiple keys to create an attestation address. A digital wallet that will support multiple keys can be called an M-of-N digital wallet…
[0123] A digital wallet provider is a provider that stores a user's digital wallet on the user's behalf, usually on a remote server, so that the information is easily accessed from anywhere. For the purposes of this application the user can also have their own custom digital wallet that can exist on their own phone or device and not on a remote server. Additionally, the user's own digital wallet can be backed up to a third-party website or service….}
Smith does not disclose the real estate transaction with the realtor, However Friedman discloses:
regarding a subject property of a specific anticipated real estate transaction; of the subject property of the anticipated real estate transaction.
{[0003] With the advance of the Internet, the business of online auctions has expanded considerably. Numerous online auction forums exist that enable consumers and sellers to transact for various kinds of items, such as collectibles, electronics and other goods or services.
{0042] According to some embodiments, an interactive computing environment provides various online auction services, such as auction services for transacting real-property. In some embodiments, the computing environment is partitioned into a first partition comprising a set of interactive services and data, and into a second partition comprising a second set of interactive services.
[0045] Some embodiments described herein relate to the auctioning of real-estate. Embodiments recognize that transactions for real estate post several challenges. Among the challenges, embodiments recognize that real estate has numerous statutory requirements before it can be transacted. For example, unlike consumer electronics or goods, a seller cannot just decide to upload images and description for real estate property before there is a transaction. Still further, estate transactions often require various verifications, including (i) verification of a property that is to be sold, (ii) verification that the seller owns the property in question, and (iii) verification that the buyer has funds to purchase the property…..
[0050] FIG. 1 illustrates a system for providing real-time, network-based (e.g., online) auctions, according to one or more embodiments. An example system of FIG. 1 illustrates a layered architecture for enabling scalability, partitioning, and extensibility, among other benefits. Examples such as described with FIG. 1 can support multiple presentation types utilizing a common underlying application, infrastructure and data. Additionally, the underlying location, resources, and technology of the system 100 may be made transparent to the users of the auction system….}
Motivation: It would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to modify the online transaction system as disclosed by Smith, with the inclusion of real-estate agents and users in the real-estate transaction as taught by Friedman, for the purpose of enhancing the user experience and secure transaction, in a real-estate context{see [0050] of Friedman}.
The combination of Smith and Friedman does not disclose the decentralized communication system, However Leavy discloses:
wherein said software application further comprises yet another module for enabling the users to create chat invites, for users to accept the chat invites, and to thus enable the users to chat peer-to-peer with one another, wherein the chats are communicated asynchronously via the mediator subsystem network on the Internet,
A decentralized blockchain network configured to enable a secure peer-peer communication between users.
{[0019] In response to receiving the encrypted message, the participants' secure messaging app may decrypt the message and begin creating and configuring the secure chat room in accordance with the information provided by the room creator. In particular, the participants' secure message app may use the one or more parameters set by the room creator to set the room title, the room description, the Time-to-Live for messages, and display the list of participants. After creating the secure chat room, the receivers' secure messaging app may store the secure room information and transaction information for the secure chat room in the receivers' local databases. The secure room information and transaction information may be stored in a block chain format, such that each participant of the secure chat room documents all commands and communications. In this regard, the secure chat room is managed in a distributed manner by all the participants of the room, and not centrally on a server.}
Communicated asynchronously
{[0028] As will further be described in more detail below, using the techniques described herein, message participants can maintain a forward secret secure messaging channel, whether communicating synchronously (e.g., where all participants are online or otherwise able to communicate with platform 120) or asynchronously (e.g., where at least one participant is offline or otherwise not in communication with platform 120).}
Users to chat peer-to-peer
{[0065-0066] ...Icon 660 may be used to distinguish room administrators from other participants. In this regard, icon 660 may appear next to all users who have been delegated room administrator privileges. Field 665 may be a directory listing all users in alphabetical order. In this regard, users may use field 665 to select participants for the secure chat room. Once the user has set all the chat room preferences and selected the chat room participants, the user may select button 670 to create the secure chat room. In response to selecting button 670, the “Create a Secure Room” message will be sent to all chat room participants.
[0066] In response to receiving the “Create a Secure Room” message, a receiver's app may create a secure room based on the information contained therein. FIG. 7 illustrates an exemplary process for receiving an invitation to a secure chat room. In block 710, the participant receives the “Create Secure Room” message from the room creator. As noted above, receiving the “Create Secure Room” message may be in response to the participant receiving an alert, such as a push notification, from the security platform. In response to receiving the alert, the participant's app may connect to the security platform and download the “Create Secure Room” message. Alternatively, the receiver's app may receive the “Create Secure Room” message directly from the sender via a peer-to-peer communication. In block 720, the receiver's app decrypts the received “Create Secure Room” message using the techniques described above with respect to FIG. 4.}
Motivation: It would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to modify the communication system as disclosed by Smith and Friedman, with the inclusion of a secured asynchronous peer-to-peer communications as taught by Leavy, for the purpose of enhancing the user experience and securing transactions.
As per claim 2;
Smith further discloses:
The system of claim 1, wherein a user is identified and verified by a realtor provided credential to the user's digital wallet confirming to the system.
The secure system is configured to establish a digital wallet linked to a decentralized network which validates user identity. See [0120] [0122-124]; [0167] and [0193]
{[0120] A validator may include without limitation a validation site or device, any user or attestor, a border agent, a peace officer, a military post, an officer, a Transportation Security Administration (TSA) agent, a hotel clerk, a merchant, a transaction partner, a seller, a buyer, a credit verification agency, a bank, a store, a partner, a companion, an employee, an employer, and the like. A validator may include someone or something into which a relationship has been entered. A validator may include someone or something into which a relationship is still prospective. A validator may include a potential personal partner or mate. A validator may include without limitation an identity validation service provider, a biometric device, any entity who knows a user personally, a notary, a credit reporting agency, a government, a school, a relative, another user, and the like….}
Neighbor
[0119] An attestor may include without limitation an attestation site or device, a company, a person, a computer-implemented algorithm, a decentralized computing system, and the like. An attestor may include a country, a government, a society, a tribe, a hospital, a birthing center, a census bureau, a parent, a creator, a source, a witness, a neighborhood, a district, a town, a county, a state, a prefecture, a state, a province, a nation-state, a nation, a parliament, a military organization, a family, a community, a government, a militia, a police force, a group, a faction, a club, an ambassador, an embassy, a home, and the like. An attestor may also or instead include an independent third party observer, a natural person, an artificial person, a machine, an online service, a software service, an online application program interface (API), a client-server application, a desktop application, a mobile application, and the like.
Digital wallet system
[0122-124] A digital wallet is a collection of keys that controls digital assets or funds. It may allow a user to make electronic commerce transactions easily and securely. A digital wallet may support a multisig script, in other words the wallet may be able to take multiple keys to create an attestation address….
[0123] A digital wallet provider is a provider that stores a user's digital wallet on the user's behalf, usually on a remote server, so that the information is easily accessed from anywhere. For the purposes of this application the user can also have their own custom digital wallet that can exist on their own phone or device and not on a remote server. Additionally, the user's own digital wallet can be backed up to a third-party website or service. A third-party cosigner is a party that participates in making a transaction with a multisig wallet that requires signatures from M of N keys before the attestation is finalized and broadcast to the blockchain network.
[0167] In another aspect, any of the attestation protocol, validation protocol, or verification protocol described herein may be used in conjunction with established centralized or distributed ledger features of cryptocurrency and blockchain to record attestation transactions. Two parties wishing to exchange a good or service or title might ordinarily wish to record such a transfer in a centralized or distributed ledger, but the parties lack certainty or assurance that the other party are who they say they are, or that the other party actual owns the good or can offer the service or possesses the title. A user may use the protocols described herein to provide attested proof of their identity and to further provide attested proof of ownership or control, thereby satisfying all the conditions required for the exchange to proceed.}
Friedman further discloses:
hence visually confirming to other users, that the user is a bona fide neighbor of the subject property of the specific anticipated real estate transaction.
The user is identified and verified by the realtor for the real-estate transaction.
{[0050] FIG. 1 illustrates a system for providing real-time, network-based (e.g., online) auctions, according to one or more embodiments. An example system of FIG. 1 illustrates a layered architecture for enabling scalability, partitioning, and extensibility, among other benefits. Examples such as described with FIG. 1 can support multiple presentation types utilizing a common underlying application, infrastructure and data. Additionally, the underlying location, resources, and technology of the system 100 may be made transparent to the users of the auction system. Furthermore, multiple classes of users can be provided for with a system such as shown by FIG. 1. In particular, system 100 can be made available for use by buyers, sellers, specialized vendors or users (e.g., realtors, investment entities, commercial entities etc.).
[0056] According to some embodiments, the production subsystem 120 can access or use auction data 130. The auction data 130 can be maintained in one or more databases, and can include customer data 132, catalog data 134, and/or transaction data 136. The transaction data 136 can include state information for particular auctions, including maintaining real-time information about a current bid or auction activity. The customer data 132 can include information about buyers, sellers (individuals or financial institutions), and realtors or agents were involved in the transactions. The catalog data 134 can include information that uniquely identifies items of real estate or real estate products that are auctioned (or have been auctioned) to system 100.
[0058] Various application services 126 can be provided through the production subsystem 120 to support auction services 122. The application services can include, for example, functionality for on-boarding assets (on-boarding component 125). The on-boarding process 125 includes rules 135 for on-boarding assets, rules that are specific to different types of assets, and rules for on-boarding assets for different types of auctions. Among the functionality that is performed, the on-boarding process 125 can include processes to (i) standardize 137 information provided by a seller, (ii) identify the asset that is being submitted for auctioning (e.g., unique address), and/or (iii) verify information about the seller, including that the seller is the title owner or has authority to submit the asset for auctioning. Other examples of application services 126 can include programmatic bidding (e.g., programmatic personas that act as virtual bidders), bidder verification, dashboard interfaces for auction operators, sellers, brokers and/or bidders, etc.
[0059] Still further, the application services 126 can include portal services 129. The portal services 129 can be provided for the various entities that utilize system 100. These can include, for example, sellers, buyers, and other interested participants. For real estate, the various parties can include individuals, institutions (e.g. banks), realtors, etc. An example of a seller portal is illustrated below.}
Motivation: It would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to modify the combination of Smith, Friedman, and Leavy, with the additional features of Friedman, for the purpose of enhancing the user experience and secure transaction, in a real-estate context{see [0050] of Friedman}.
As per claim 3;
Smith further discloses:
The secure system of claim 1, wherein a user is identified and verified by a realtor provided credential to the user's digital wallet confirming to the system.
The secure system is configured to establish a digital wallet linked to a decentralized network which validates user identity. See [0120] [0122-124]; [0167] and [0193]
{[0120] A validator may include without limitation a validation site or device, any user or attestor, a border agent, a peace officer, a military post, an officer, a Transportation Security Administration (TSA) agent, a hotel clerk, a merchant, a transaction partner, a seller, a buyer, a credit verification agency, a bank, a store, a partner, a companion, an employee, an employer, and the like. A validator may include someone or something into which a relationship has been entered. A validator may include someone or something into which a relationship is still prospective. A validator may include a potential personal partner or mate. A validator may include without limitation an identity validation service provider, a biometric device, any entity who knows a user personally, a notary, a credit reporting agency, a government, a school, a relative, another user, and the like….}
Digital wallet system
{[0122-124] A digital wallet is a collection of keys that controls digital assets or funds. It may allow a user to make electronic commerce transactions easily and securely. A digital wallet may support a multisig script, in other words the wallet may be able to take multiple keys to create an attestation address….
[0123] A digital wallet provider is a provider that stores a user's digital wallet on the user's behalf, usually on a remote server, so that the information is easily accessed from anywhere. For the purposes of this application the user can also have their own custom digital wallet that can exist on their own phone or device and not on a remote server. Additionally, the user's own digital wallet can be backed up to a third-party website or service. A third-party cosigner is a party that participates in making a transaction with a multisig wallet that requires signatures from M of N keys before the attestation is finalized and broadcast to the blockchain network.
[0167] In another aspect, any of the attestation protocol, validation protocol, or verification protocol described herein may be used in conjunction with established centralized or distributed ledger features of cryptocurrency and blockchain to record attestation transactions. Two parties wishing to exchange a good or service or title might ordinarily wish to record such a transfer in a centralized or distributed ledger, but the parties lack certainty or assurance that the other party are who they say they are, or that the other party actual owns the good or can offer the service or possesses the title. A user may use the protocols described herein to provide attested proof of their identity and to further provide attested proof of ownership or control, thereby satisfying all the conditions required for the exchange to proceed.}
Friedman further discloses:
hence visually confirming to other users, that the user is a bona fide potential buyer of the subject property of the specific anticipated real estate transaction.
The user is identified and verified by the realtor for the real-estate transaction.
{[0050] FIG. 1 illustrates a system for providing real-time, network-based (e.g., online) auctions, according to one or more embodiments. An example system of FIG. 1 illustrates a layered architecture for enabling scalability, partitioning, and extensibility, among other benefits. Examples such as described with FIG. 1 can support multiple presentation types utilizing a common underlying application, infrastructure and data. Additionally, the underlying location, resources, and technology of the system 100 may be made transparent to the users of the auction system. Furthermore, multiple classes of users can be provided for with a system such as shown by FIG. 1. In particular, system 100 can be made available for use by buyers, sellers, specialized vendors or users (e.g., realtors, investment entities, commercial entities etc.).
[0056] According to some embodiments, the production subsystem 120 can access or use auction data 130. The auction data 130 can be maintained in one or more databases, and can include customer data 132, catalog data 134, and/or transaction data 136. The transaction data 136 can include state information for particular auctions, including maintaining real-time information about a current bid or auction activity. The customer data 132 can include information about buyers, sellers (individuals or financial institutions), and realtors or agents were involved in the transactions. The catalog data 134 can include information that uniquely identifies items of real estate or real estate products that are auctioned (or have been auctioned) to system 100.
[0058] Various application services 126 can be provided through the production subsystem 120 to support auction services 122. The application services can include, for example, functionality for on-boarding assets (on-boarding component 125). The on-boarding process 125 includes rules 135 for on-boarding assets, rules that are specific to different types of assets, and rules for on-boarding assets for different types of auctions. Among the functionality that is performed, the on-boarding process 125 can include processes to (i) standardize 137 information provided by a seller, (ii) identify the asset that is being submitted for auctioning (e.g., unique address), and/or (iii) verify information about the seller, including that the seller is the title owner or has authority to submit the asset for auctioning. Other examples of application services 126 can include programmatic bidding (e.g., programmatic personas that act as virtual bidders), bidder verification, dashboard interfaces for auction operators, sellers, brokers and/or bidders, etc.
[0059] Still further, the application services 126 can include portal services 129. The portal services 129 can be provided for the various entities that utilize system 100. These can include, for example, sellers, buyers, and other interested participants. For real estate, the various parties can include individuals, institutions (e.g. banks), realtors, etc. An example of a seller portal is illustrated below.}
Motivation: It would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to modify the combination of Smith, Friedman, and Leavy, with the additional features of Friedman, for the purpose of enhancing the user experience and secure transaction, in a real-estate context{see [0050] of Friedman}.
As per claim 4;
Smith further discloses:
The secure system of claim 1, wherein a user is identified and verified by a realtor provided credential to the user's digital wallet confirming to the system.
The secure system is configured to establish a digital wallet linked to a decentralized network which validates user identity and ownership of property.
{[0120] A validator may include without limitation a validation site or device, any user or attestor, a border agent, a peace officer, a military post, an officer, a Transportation Security Administration (TSA) agent, a hotel clerk, a merchant, a transaction partner, a seller, a buyer, a credit verification agency, a bank, a store, a partner, a companion, an employee, an employer, and the like. A validator may include someone or something into which a relationship has been entered. A validator may include someone or something into which a relationship is still prospective. A validator may include a potential personal partner or mate. A validator may include without limitation an identity validation service provider, a biometric device, any entity who knows a user personally, a notary, a credit reporting agency, a government, a school, a relative, another user, and the like….}
Digital wallet system
[0122-124] A digital wallet is a collection of keys that controls digital assets or funds. It may allow a user to make electronic commerce transactions easily and securely. A digital wallet may support a multisig script, in other words the wallet may be able to take multiple keys to create an attestation address….
[0123] A digital wallet provider is a provider that stores a user's digital wallet on the user's behalf, usually on a remote server, so that the information is easily accessed from anywhere. For the purposes of this application the user can also have their own custom digital wallet that can exist on their own phone or device and not on a remote server. Additionally, the user's own digital wallet can be backed up to a third-party website or service. A third-party cosigner is a party that participates in making a transaction with a multisig wallet that requires signatures from M of N keys before the attestation is finalized and broadcast to the blockchain network.
[0167] In another aspect, any of the attestation protocol, validation protocol, or verification protocol described herein may be used in conjunction with established centralized or distributed ledger features of cryptocurrency and blockchain to record attestation transactions. Two parties wishing to exchange a good or service or title might ordinarily wish to record such a transfer in a centralized or distributed ledger, but the parties lack certainty or assurance that the other party are who they say they are, or that the other party actual owns the good or can offer the service or possesses the title. A user may use the protocols described herein to provide attested proof of their identity and to further provide attested proof of ownership or control, thereby satisfying all the conditions required for the exchange to proceed.}
Friedman further discloses:
hence visually confirming to other users, that the user is a bona fide seller of the subject property of the specific anticipated real estate transaction.
The user is identified and verified by the realtor for the real-estate transaction.
{[0050] FIG. 1 illustrates a system for providing real-time, network-based (e.g., online) auctions, according to one or more embodiments. An example system of FIG. 1 illustrates a layered architecture for enabling scalability, partitioning, and extensibility, among other benefits. Examples such as described with FIG. 1 can support multiple presentation types utilizing a common underlying application, infrastructure and data. Additionally, the underlying location, resources, and technology of the system 100 may be made transparent to the users of the auction system. Furthermore, multiple classes of users can be provided for with a system such as shown by FIG. 1. In particular, system 100 can be made available for use by buyers, sellers, specialized vendors or users (e.g., realtors, investment entities, commercial entities etc.).
[0056] According to some embodiments, the production subsystem 120 can access or use auction data 130. The auction data 130 can be maintained in one or more databases, and can include customer data 132, catalog data 134, and/or transaction data 136. The transaction data 136 can include state information for particular auctions, including maintaining real-time information about a current bid or auction activity. The customer data 132 can include information about buyers, sellers (individuals or financial institutions), and realtors or agents were involved in the transactions. The catalog data 134 can include information that uniquely identifies items of real estate or real estate products that are auctioned (or have been auctioned) to system 100.
[0058] Various application services 126 can be provided through the production subsystem 120 to support auction services 122. The application services can include, for example, functionality for on-boarding assets (on-boarding component 125). The on-boarding process 125 includes rules 135 for on-boarding assets, rules that are specific to different types of assets, and rules for on-boarding assets for different types of auctions. Among the functionality that is performed, the on-boarding process 125 can include processes to (i) standardize 137 information provided by a seller, (ii) identify the asset that is being submitted for auctioning (e.g., unique address), and/or (iii) verify information about the seller, including that the seller is the title owner or has authority to submit the asset for auctioning. Other examples of application services 126 can include programmatic bidding (e.g., programmatic personas that act as virtual bidders), bidder verification, dashboard interfaces for auction operators, sellers, brokers and/or bidders, etc.
[0059] Still further, the application services 126 can include portal services 129. The portal services 129 can be provided for the various entities that utilize system 100. These can include, for example, sellers, buyers, and other interested participants. For real estate, the various parties can include individuals, institutions (e.g. banks), realtors, etc. An example of a seller portal is illustrated below.}
Motivation: It would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to modify the combination of Smith, Friedman, and Leavy, with the additional features of Friedman, for the purpose of enhancing the user experience and secure transaction, in a real-estate context{see [0050] of Friedman}.
As per claim 5;
Smith further discloses;
The secure system of claim 1, wherein a user is identified and verified by a realtor provided credential to the user's digital wallet confirming to the system.
The secure system is configured to establish a digital wallet linked to a decentralized network which validates user identity and ownership of property.
{[0120] A validator may include without limitation a validation site or device, any user or attestor, a border agent, a peace officer, a military post, an officer, a Transportation Security Administration (TSA) agent, a hotel clerk, a merchant, a transaction partner, a seller, a buyer, a credit verification agency, a bank, a store, a partner, a companion, an employee, an employer, and the like. A validator may include someone or something into which a relationship has been entered. A validator may include someone or something into which a relationship is still prospective. A validator may include a potential personal partner or mate. A validator may include without limitation an identity validation service provider, a biometric device, any entity who knows a user personally, a notary, a credit reporting agency, a government, a school, a relative, another user, and the like….}
Digital wallet system
{[0122-124] A digital wallet is a collection of keys that controls digital assets or funds. It may allow a user to make electronic commerce transactions easily and securely. A digital wallet may support a multisig script, in other words the wallet may be able to take multiple keys to create an attestation address….
[0123] A digital wallet provider is a provider that stores a user's digital wallet on the user's behalf, usually on a remote server, so that the information is easily accessed from anywhere. For the purposes of this application the user can also have their own custom digital wallet that can exist on their own phone or device and not on a remote server. Additionally, the user's own digital wallet can be backed up to a third-party website or service. A third-party cosigner is a party that participates in making a transaction with a multisig wallet that requires signatures from M of N keys before the attestation is finalized and broadcast to the blockchain network.
[0167] In another aspect, any of the attestation protocol, validation protocol, or verification protocol described herein may be used in conjunction with established centralized or distributed ledger features of cryptocurrency and blockchain to record attestation transactions. Two parties wishing to exchange a good or service or title might ordinarily wish to record such a transfer in a centralized or distributed ledger, but the parties lack certainty or assurance that the other party are who they say they are, or that the other party actual owns the good or can offer the service or possesses the title. A user may use the protocols described herein to provide attested proof of their identity and to further provide attested proof of ownership or control, thereby satisfying all the conditions required for the exchange to proceed.}
Friedman further discloses:
hence visually confirming to other users, that the user is a bona fide owner of the subject property of the specific anticipated real estate transaction.
The user is identified and verified by the realtor for the real-estate transaction.
{[0050] FIG. 1 illustrates a system for providing real-time, network-based (e.g., online) auctions, according to one or more embodiments. An example system of FIG. 1 illustrates a layered architecture for enabling scalability, partitioning, and extensibility, among other benefits. Examples such as described with FIG. 1 can support multiple presentation types utilizing a common underlying application, infrastructure and data. Additionally, the underlying location, resources, and technology of the system 100 may be made transparent to the users of the auction system. Furthermore, multiple classes of users can be provided for with a system such as shown by FIG. 1. In particular, system 100 can be made available for use by buyers, sellers, specialized vendors or users (e.g., realtors, investment entities, commercial entities etc.).
[0056] According to some embodiments, the production subsystem 120 can access or use auction data 130. The auction data 130 can be maintained in one or more databases, and can include customer data 132, catalog data 134, and/or transaction data 136. The transaction data 136 can include state information for particular auctions, including maintaining real-time information about a current bid or auction activity. The customer data 132 can include information about buyers, sellers (individuals or financial institutions), and realtors or agents were involved in the transactions. The catalog data 134 can include information that uniquely identifies items of real estate or real estate products that are auctioned (or have been auctioned) to system 100.
[0058] Various application services 126 can be provided through the production subsystem 120 to support auction services 122. The application services can include, for example, functionality for on-boarding assets (on-boarding component 125). The on-boarding process 125 includes rules 135 for on-boarding assets, rules that are specific to different types of assets, and rules for on-boarding assets for different types of auctions. Among the functionality that is performed, the on-boarding process 125 can include processes to (i) standardize 137 information provided by a seller, (ii) identify the asset that is being submitted for auctioning (e.g., unique address), and/or (iii) verify information about the seller, including that the seller is the title owner or has authority to submit the asset for auctioning. Other examples of application services 126 can include programmatic bidding (e.g., programmatic personas that act as virtual bidders), bidder verification, dashboard interfaces for auction operators, sellers, brokers and/or bidders, etc.
[0059] Still further, the application services 126 can include portal services 129. The portal services 129 can be provided for the various entities that utilize system 100. These can include, for example, sellers, buyers, and other interested participants. For real estate, the various parties can include individuals, institutions (e.g. banks), realtors, etc. An example of a seller portal is illustrated below.}
Motivation: It would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to modify the combination of Smith, Friedman, and Leavy, with the additional features of Friedman, for the purpose of enhancing the user experience and secure transaction, in a real-estate context{see [0050] of Friedman}.
As per claim 7;
The combination of Smith and Friedman does not disclose the secure invitation and privatized chat messaging between authenticated and credentialed users, however Leavy discloses the decentralized communication systems and the invitation and secure and privatized chat;
The method of claim 6, the method further being adapted for inviting secure and privatized chat messaging between the authenticated and credentialed users, the method being further adapted for accessing and using a mediator subsystem network on the Internet for the receiving of chat messages and the delivery of chat messages, further comprising:
{[0019] In response to receiving the encrypted message, the participants' secure messaging app may decrypt the message and begin creating and configuring the secure chat room in accordance with the information provided by the room creator. In particular, the participants' secure message app may use the one or more parameters set by the room creator to set the room title, the room description, the Time-to-Live for messages, and display the list of participants. After creating the secure chat room, the receivers' secure messaging app may store the secure room information and transaction information for the secure chat room in the receivers' local databases. The secure room information and transaction information may be stored in a block chain format, such that each participant of the secure chat room documents all commands and communications. In this regard, the secure chat room is managed in a distributed manner by all the participants of the room, and not centrally on a server.}
enabling creation of a chat request invitation from a first user to a second user; -
{[0065] In this regard, icon 660 may appear next to all users who have been delegated room administrator privileges. Field 665 may be a directory listing all users in alphabetical order. In this regard, users may use field 665 to select participants for the secure chat room. Once the user has set all the chat room preferences and selected the chat room participants, the user may select button 670 to create the secure chat room. In response to selecting button 670, the “Create a Secure Room” message will be sent to all chat room participants.}
submitting to the mediator subsystem network the chat request invitation together with the first user's public digital identity and directed to the public digital identity of the second user; and
{[0047] In order to send and receive secure communications, both the sender and receiver need to have a copy of the app running on their respective devices. In this regard, FIG. 3 illustrates an exemplary process for transmitting encrypted communications using the app 224. The method begins in bock 305, with the sender's app obtaining the intended receiver's public information.
In response to receiving the request, the security platform or secure directory responds with the intended receiver's public information. In this regard, the public information may include at least one of the receiver's app ID, user-level signing public key, signed app-level signing public key, a signed ephemeral ECDH public component, an identifier of the ephemeral ECDH public component, and the receiver's device key. In preferred embodiments, the security platform may randomly select one of the signed ephemeral ECDH public components from a pool of public components that the receiver has previously uploaded to security platform 120. Further, the security platform will delete the selected ephemeral ECDH public component so it is not used for any subsequent communications. If the receiver has multiple instances of the app installed on different devices, the sender's app will receive a unique signed app-level signing public key, signed ephemeral ECDH public component, identifier of the ephemeral ECDH public component, and device key for each instance of app in block 305. The multiple instance information may be provided in an arrayed response by the security platform.}
listening for an acceptance of the request invitation and indicating the second user as available for chat.
{[0019] In response to receiving the encrypted message, the participants' secure messaging app may decrypt the message and begin creating and configuring the secure chat room in accordance with the information provided by the room creator. In particular, the participants' secure message app may use the one or more parameters set by the room creator to set the room title, the room description, the Time-to-Live for messages, and display the list of participants. After creating the secure chat room, the receivers' secure messaging app may store the secure room information and transaction information for the secure chat room in the receivers' local databases. The secure room information and transaction information may be stored in a block chain format, such that each participant of the secure chat room documents all commands and communications. In this regard, the secure chat room is managed in a distributed manner by all the participants of the room, and not centrally on a server.
[0075] If the message is destined for a secure chat room, then the receiver's app determines whether the received message belongs to an existing room or group in block 925. In this regard, the receiver's app may compare the received group identifier to group identifiers maintained in the device's local database to determine which group, if any, the message belongs to. If the receiver's app determines that the message does not belong to an existing room or group in block 925, the process proceeds to block 945 where the receiver's app may send a request to the sender's app for additional information. The request for additional information may include identifying information for the sender's reference, such as the group identifier and message identifier.}
Motivation: It would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to modify the combination of Smith and Friedman, with the inclusion of a secured chat invites to establish a peer-to-peer communication as taught by Leavy, for the purpose of enhancing privacy and security in communication.
As per claim 8;
Leavy further discloses:
The method of claim 7, the method further being adapted for receiving and responding to a chat request invitation, between the authenticated and credentialed users, the method being further adapted for accessing and using a mediator subsystem network on the Internet for the receiving of chat messages and the delivery of chat messages, further comprising:-
The mediator subsystem enables a secure peer-to-peer communications between users
{[0065 – 0066] In this regard, icon 660 may appear next to all users who have been delegated room administrator privileges. Field 665 may be a directory listing all users in alphabetical order. In this regard, users may use field 665 to select participants for the secure chat room. Once the user has set all the chat room preferences and selected the chat room participants, the user may select button 670 to create the secure chat room. In response to selecting button 670, the “Create a Secure Room” message will be sent to all chat room participants.
[0075] If the message is destined for a secure chat room, then the receiver's app determines whether the received message belongs to an existing room or group in block 925. In this regard, the receiver's app may compare the received group identifier to group identifiers maintained in the device's local database to determine which group, if any, the message belongs to. If the receiver's app determines that the message does not belong to an existing room or group in block 925, the process proceeds to block 945 where the receiver's app may send a request to the sender's app for additional information. The request for additional information may include identifying information for the sender's reference, such as the group identifier and message identifier.
checking the mediator subsystem network, downloading, and displaying any available chat request invitations;-
{[0055] FIG. 4 illustrates an exemplary process for receiving and decrypting a datagram received from a sender. In block 410, the receiver receives the sender's datagram. As noted above, retrieving the sender's datagram may be in response to receiving an alert, such as a push notification, from the security platform. The receiver's secure messaging app may connect to the security platform and download the sender's datagram. Alternatively, the receiver's secure messaging app may receive the sender's datagram directly from the sender via a peer-to-peer communication.
[0066] In response to receiving the alert, the participant's app may connect to the security platform and download the “Create Secure Room” message. Alternatively, the receiver's app may receive the “Create Secure Room” message directly from the sender via a peer-to-peer communication. In block 720, the receiver's app decrypts the received “Create Secure Room” message using the techniques described above with respect to FIG. 4.}
enabling acceptance or denial of a chat request invitation, comprising submitting to the mediator subsystem network the second user's
{[0060] After setting the room preferences, the room administrator may add participants to the secure room in block 530. Adding participants to the secure room may include selecting usernames from a directory. For example, if the app is used by an enterprise, participants may be added to a group chat from the enterprise's corporate directory. Alternatively, the participants may be added based on an external unique identifier, such as a telephone number or an email address. If the external users do not have a copy of the app, they may be prompted to obtain a copy from a third party.
[0066] In response to receiving the “Create a Secure Room” message, a receiver's app may create a secure room based on the information contained therein. FIG. 7 illustrates an exemplary process for receiving an invitation to a secure chat room. In block 710, the participant receives the “Create Secure Room” message from the room creator. As noted above, receiving the “Create Secure Room” message may be in response to the participant receiving an alert, such as a push notification, from the security platform. In response to receiving the alert, the participant's app may connect to the security platform and download the “Create Secure Room” message. Alternatively, the receiver's app may receive the “Create Secure Room” message directly from the sender via a peer-to-peer communication. In block 720, the receiver's app decrypts the received “Create Secure Room” message using the techniques described above with respect to FIG. 4.}
acceptance, together with the second user's public digital identity and directed to the public digital identity of the first user; and-
{[0047] In order to send and receive secure communications, both the sender and receiver need to have a copy of the app running on their respective devices. In this regard, FIG. 3 illustrates an exemplary process for transmitting encrypted communications using the app 224. The method begins in bock 305, with the sender's app obtaining the intended receiver's public information.
[0047] In response to receiving the request, the security platform or secure directory responds with the intended receiver's public information. In this regard, the public information may include at least one of the receiver's app ID, user-level signing public key, signed app-level signing public key, a signed ephemeral ECDH public component, an identifier of the ephemeral ECDH public component, and the receiver's device key. In preferred embodiments, the security platform may randomly select one of the signed ephemeral ECDH public components from a pool of public components that the receiver has previously uploaded to security platform 120. Further, the security platform will delete the selected ephemeral ECDH public component so it is not used for any subsequent communications. If the receiver has multiple instances of the app installed on different devices, the sender's app will receive a unique signed app-level signing public key, signed ephemeral ECDH public component, identifier of the ephemeral ECDH public component, and device key for each instance of app in block 305. The multiple instance information may be provided in an arrayed response by the security platform.}
listening for an acceptance of the request invitation and indicating the second user as available for chat.
{[0019] In response to receiving the encrypted message, the participants' secure messaging app may decrypt the message and begin creating and configuring the secure chat room in accordance with the information provided by the room creator. In particular, the participants' secure message app may use the one or more parameters set by the room creator to set the room title, the room description, the Time-to-Live for messages, and display the list of participants. After creating the secure chat room, the receivers' secure messaging app may store the secure room information and transaction information for the secure chat room in the receivers' local databases. The secure room information and transaction information may be stored in a block chain format, such that each participant of the secure chat room documents all commands and communications. In this regard, the secure chat room is managed in a distributed manner by all the participants of the room, and not centrally on a server.
[0075] If the message is destined for a secure chat room, then the receiver's app determines whether the received message belongs to an existing room or group in block 925. In this regard, the receiver's app may compare the received group identifier to group identifiers maintained in the device's local database to determine which group, if any, the message belongs to. If the receiver's app determines that the message does not belong to an existing room or group in block 925, the process proceeds to block 945 where the receiver's app may send a request to the sender's app for additional information. The request for additional information may include identifying information for the sender's reference, such as the group identifier and message identifier.}
Motivation: It would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to modify the combination of Smith, Friedman, and Leavy, with the additional features of Leavy, for the purpose of enhancing privacy and security in communication.
As per claim 9;
Leavy further discloses:
The method of claim 8, wherein peer-to-peer asynchronous chat communication is freely enabled between the first user and the second user on their mobile smartphone software applications.
Communicated asynchronously
{[0028] As will further be described in more detail below, using the techniques described herein, message participants can maintain a forward secret secure messaging channel, whether communicating synchronously (e.g., where all participants are online or otherwise able to communicate with platform 120) or asynchronously (e.g., where at least one participant is offline or otherwise not in communication with platform 120).}
Users to chat peer-to-peer
{[0065-0066] ...Icon 660 may be used to distinguish room administrators from other participants. In this regard, icon 660 may appear next to all users who have been delegated room administrator privileges. Field 665 may be a directory listing all users in alphabetical order. In this regard, users may use field 665 to select participants for the secure chat room. Once the user has set all the chat room preferences and selected the chat room participants, the user may select button 670 to create the secure chat room. In response to selecting button 670, the “Create a Secure Room” message will be sent to all chat room participants.
[0066] In response to receiving the “Create a Secure Room” message, a receiver's app may create a secure room based on the information contained therein. FIG. 7 illustrates an exemplary process for receiving an invitation to a secure chat room. In block 710, the participant receives the “Create Secure Room” message from the room creator. As noted above, receiving the “Create Secure Room” message may be in response to the participant receiving an alert, such as a push notification, from the security platform. In response to receiving the alert, the participant's app may connect to the security platform and download the “Create Secure Room” message. Alternatively, the receiver's app may receive the “Create Secure Room” message directly from the sender via a peer-to-peer communication. In block 720, the receiver's app decrypts the received “Create Secure Room” message using the techniques described above with respect to FIG. 4.}
Motivation: It would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to modify the combination of Smith, Friedman, and Leavy, with the additional features of Leavy, for the purpose of enhancing privacy and security in communication.
As per claim 10;
Leavy further discloses:
The method of claim 7, wherein the first user's chat invitation request may include the name of the first user.
{[0062] Further, the “Create Secure Room” message may include the secure room information and metadata that identifies the participants of the secure chat room. In preferred embodiments, hashed usernames of the secure chat room's participants are included in the metadata. The “Create Secure Room” command, the secure room information, and the metadata are transmitted to room participants in the payload of the secure datagram described above. That is, the “Create Secure Room” command, the secure room information, and the metadata may be encrypted with a random message key, which is encrypted using information unique to each room participant. Accordingly, participants of the secure chat room may be able to decrypt the random “Create Secure Room” message using the techniques described above.}
Motivation: It would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to modify the combination of Smith, Friedman, and Leavy, with the additional features of Leavy, for the purpose of enhancing privacy and security in communication.
As per claim 11;
Leavy further discloses:
The method of claim 7, wherein the first user's chat invitation request may include the address of the first user.
{[0032] User directory 106 may be any database or table capable of providing directory services. For example, user directory may include a corporate directory that include employees' first and last names, usernames, email address, phone numbers, department information, etc. Alternatively, user directory 106 may be a database or table to maintain user information for users of security platform 120. In this regard, user directory 106 may be encrypted. In some embodiments, user directory 106 may serve as a secure directory that includes a table of hashed usernames, a table of appIDs, and a table of deviceIDs for a secure messaging app. Accordingly, user directory 106 may be used to share information about users, systems, networks, services and applications. According to some embodiments, the user directory 106 may include a Lightweight Directory Access Protocol (LDAP).
[0062] In preferred embodiments, hashed usernames of the secure chat room's participants are included in the metadata. The “Create Secure Room” command, the secure room information, and the metadata are transmitted to room participants in the payload of the secure datagram described above. That is, the “Create Secure Room” command, the secure room information, and the metadata may be encrypted with a random message key, which is encrypted using information unique to each room participant. Accordingly, participants of the secure chat room may be able to decrypt the random “Create Secure Room” message using the techniques described above.
[0065- 66] In this regard, icon 660 may appear next to all users who have been delegated room administrator privileges. Field 665 may be a directory listing all users in alphabetical order. In this regard, users may use field 665 to select participants for the secure chat room. Once the user has set all the chat room preferences and selected the chat room participants, the user may select button 670 to create the secure chat room. In response to selecting button 670, the “Create a Secure Room” message will be sent to all chat room participants……}
Motivation: It would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to modify the combination of Smith, Friedman, and Leavy, with the additional features of Leavy, for the purpose of enhancing privacy and security in communication.
As per claim 12;
Leavy further discloses:
The method of claim 8, wherein the second user's chat acceptance may include the name of the second user.
{[0063] FIGS. 6A and 6B illustrate an exemplary interface for creating a secure room. In particular, FIGS. 6A and 6B show an interface 600 for the app 224. Interface 600 displays user information in field 605. The user information may include the user's name, their username, and an avatar that may be displayed to other users. The avatar may be the user's initials, the initials of their username, a photo, or an image that the user selected.
[0067] Next, in block 740, the receiver's app obtains a list of participants from the metadata included in “Create Secure Room” message. As noted above, the list of participants may include hashed usernames for the participants of the secure chat room. Accordingly, the receiver's app may compare the hashed username to usernames stored in the directory to display the participant's actual name. If the hashed username does not appear in the directory, the receiver's app may just display the username or other identifying information until the app is able to resolve the user's name to the username.}
Motivation: It would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to modify the combination of Smith, Friedman, and Leavy, with the additional features of Leavy, for the purpose of enhancing privacy and security in communication.
As per claim 13;
Smith further discloses:
The method of claim 8, wherein the second user's chat acceptance may include the address of the second user.
{[0127-128] Information may be or include personal information, personal identification information (PII), data or user data, and may include without limitation any personally identifying data or representations of personal information. Personally identifiable information (PII), or sensitive personal information, especially as used in U.S. privacy law and information security, is information that can be used on its own or with other information to identify, contact, or locate a single person, or to identify an individual in context. Personally identifiable information may include one or more information items, including full name, home address, telephone number, social security number (SSN), credit card numbers, date of birth, birthplace, driver's license number, e-mail address, national identification number, passport number, user ID, login name or usernames in messaging, social media, and other applications, passwords or personal identification numbers (PINs), IP addresses, vehicle registration plate number, face, fingerprints, retinal scan, handwriting samples, biometric data, digital identity, and genetic information.}
As per claim 14;
Smith further discloses;
The method of claim 9, wherein messages are secure and privatized using the user's private and public keys.
{[0231] In step 1510, the attestor creates an attestation address based on the public attest key, as previously described. In step 1512, the generates a signed transaction using their private key, and broadcasts the transaction to the centralized or distributed network. The method ends at finish block 1514.
[0232] In one embodiment, the information that the user requests includes the digital entity's public key. In one embodiment the digital entity's public key is displayed on the website of the digital entity. In step 1606, the user receives information from the digital entity including the cryptographic challenge nonce signed with the digital entity's private key. In step 1608, the user creates an attestation address using the information received from the digital entity and the digital entity's public key using the protocols previously described herein.}
As per claim 15,
Smith further discloses;
The method of claim 9, wherein the content of the chat messages are encrypted by the private key of the user sending a particular chat message and decrypted by the public key of the user sending the chat message.
{[0129] As is known in the art, asymmetric or public key cryptography uses public and private keys to encrypt and decrypt data. The keys are large numbers that have been paired together, but are not identical, and are called a cryptographic asymmetric key pair. One key can be shared with everyone, and this is called the public key. The other key in the pair is kept secret, and is called the private key. Either of the keys can be used to encrypt a message; the opposite key is used to for decryption. Different system participants all may have a public key. For example, an attestor may have a public key, a verifier may have a public key, and a third-party cosigner may have a public key.}
Claim(s) 6 is rejected under 35 U.S.C. 103 as being unpatentable over Smith in view of Friedman.
As per claim 6;
Smith discloses:
A method of authenticating users and issuing of credentials
Validation of user identity and ownership of property
{[0120 - 124] A validator may include without limitation a validation site or device, any user or attestor, a border agent, a peace officer, a military post, an officer, a Transportation Security Administration (TSA) agent, a hotel clerk, a merchant, a transaction partner, a seller, a buyer, a credit verification agency, a bank, a store, a partner, a companion, an employee, an employer, and the like. A validator may include someone or something into which a relationship has been entered. A validator may include someone or something into which a relationship is still prospective. A validator may include a potential personal partner or mate. A validator may include without limitation an identity validation service provider, a biometric device, any entity who knows a user personally, a notary, a credit reporting agency, a government, a school, a relative, another user, and the like…..[0121] A merchant may include without limitation a place of business or commerce that offers products or services to users or other merchants, and who has a need to know with certainty that the user is authentic, and/or that the information presented by the user is authentic and belongs to that user, and/or that the property that the user claims to be their own actually belongs to the user. An identity validation service provider may include without limitation a person or object or business that provides the service of confirming a user's information that the attestor will attest to is valid and real and belongs to the user….[0123] A digital wallet provider is a provider that stores a user's digital wallet on the user's behalf, usually on a remote server, so that the information is easily accessed from anywhere. For the purposes of this application the user can also have their own custom digital wallet that can exist on their own phone or device and not on a remote server.
[0167] In another aspect, any of the attestation protocol, validation protocol, or verification protocol described herein may be used in conjunction with established centralized or distributed ledger features of cryptocurrency and blockchain to record attestation transactions. Two parties wishing to exchange a good or service or title might ordinarily wish to record such a transfer in a centralized or distributed ledger, but the parties lack certainty or assurance that the other party are who they say they are, or that the other party actual owns the good or can offer the service or possesses the title. A user may use the protocols described herein to provide attested proof of their identity and to further provide attested proof of ownership or control, thereby satisfying all the conditions required for the exchange to proceed.
the method being adapted for accessing and using a blockchain decentralized identifier (DID) network for confirming the users' identities, comprising the steps of:-
Verification of user identity using a blockchain identifier
{[0121] A merchant may include without limitation a place of business or commerce that offers products or services to users or other merchants, and who has a need to know with certainty that the user is authentic, and/or that the information presented by the user is authentic and belongs to that user, and/or that the property that the user claims to be their own actually belongs to the user. An identity validation service provider may include without limitation a person or object or business that provides the service of confirming a user's information that the attestor will attest to is valid and real and belongs to the user.
[0165] … The process of validating a company and putting it on the blockchain could have many applications which include but are not limited to using the attested company data in web transactions in place of a standard certificate. More generally, any entity can have information validated and attested to and stored on a centralized or distributed ledger in this way, and any two entities can use the verification protocol as a way to communicate information to each other in a way that can be trusted....
[0176] Some or all of the participants may have access to a centralized or distributed ledger 150. Centralized or distributed ledger 150 is an electronic ledger which contains a list of verified transactions of digital cryptocurrency. In Bitcoin, centralized or distributed ledger 150 is a distributed ledger which is referred to as a blockchain. Although transactions are communicated over the Bitcoin network for entry into the blockchain, participants referred to as “miners” may ultimately be the entities that perform transaction verification and blockchain entry….}
providing a software application for users to download and install on their mobile smartphones; -
{[0169] The attestor kiosk or station may present a QR code or other motion code to the user, prompting the user to download an attestor's application on the user's mobile device. The user may then use the attestor application on their mobile phone or device to scan additional QR or motion codes in order to receive any generated public keys, private keys, or public or private attest keys related to the one or more attestation transactions of their information…
[0145] Similarly, if the user wanted to revoke only part of the attested information, then the transaction may be revoked by spending the dust, and a new transaction with updated user information may be written. This allows attested information to change, for instance, if the user moves and has a new home address, or changes their telephone number.}
accessing a host server network with a software application module for verifying at least one of a valid email address or a valid phone number of each user;
Enabling users to use mobile smartphones to register their personal information
{[0123 - 125] A digital wallet provider is a provider that stores a user's digital wallet on the user's behalf, usually on a remote server, so that the information is easily accessed from anywhere. For the purposes of this application the user can also have their own custom digital wallet that can exist on their own phone or device and not on a remote server.…
[0127] Information may be or include personal information, personal identification information (PII), data or user data, and may include without limitation any personally identifying data or representations of personal information. Personally identifiable information (PII), or sensitive personal information, especially as used in U.S. privacy law and information security, is information that can be used on its own or with other information to identify, contact, or locate a single person, or to identify an individual in context. Personally identifiable information may include one or more information items, including full name, home address, telephone number, social security number (SSN), credit card numbers, date of birth, birthplace, driver's license number, e-mail address, national identification number, passport number, user ID, login name or usernames in messaging, social media, and other applications, passwords or personal identification numbers (PINs), IP addresses, vehicle registration plate number, face, fingerprints, retinal scan, handwriting samples, biometric data, digital identity, and genetic information.
[0162] The validation protocol may use third party Identity Validation Service Providers such as ThreatMetrix® to authenticate the user's information. An attestation site website, or application controlled by an attestor, performing a validation protocol, may call, text, phone, message, or send physical mail to addresses provided by the user. The attestation site, website, or application controlled by an attestor performing a validation protocol may receive pictures or scans or radio frequency identification (RFID) readouts or infrared captures of user's identifying documents. An attestor performing a validation protocol may receive authenticated information or biometric information from a device, which could be a user device, or perhaps a fingerprint reader at an FBI certified fingerprint collection point, which may be an attestor.}
registering each verified user on a host server computer system;
Enabling user to register to the secure system
{[0224] …. In one embodiment, the attestor may verify that the user indicated in the information sent by the organization is a registered user that holds a valid account at an attestor. As previously discussed, in one embodiment, the attestor 1330 may look for the information or the public key or the attest key in an existing database of attested users using standard database search functionality. In one embodiment, the attestor 1330 may positively identify an existing authenticated and registered user that holds a valid account at the attestor (a registered user) using the information and/or the public key of the individual that has been received. If the user is not a registered user and does not hold a valid account, the attestor 1330 informs the organization 1320 and the organization falls back to traditional individual verification. If the user is registered and does hold a valid account, in step 1354, the attestor 1330 uses the information and the public key to generate the attest key and uses the attest key to generate the attestation address, and verifies that the attestation transaction is present at the attestation address and that the attestation transaction has not been revoked. If the attestor 1330 determines that there is not a valid attestation transaction representing the user information, then the attestor 1330 alerts the organization 1320 that they are not able to verify the information of the individual 1310 and in step 1355 c, the organization falls back to traditional methods of verifying the individual 1310 in order to process or decline the business transaction….}
issuing a blockchain secured digital wallet to each user's smartphone; creating in the user's digital wallet a revocable authentication for use in verifying a user's identity,
Enabling user to connect to the digital wallets using the mobile phones
{[0123] A digital wallet provider is a provider that stores a user's digital wallet on the user's behalf, usually on a remote server, so that the information is easily accessed from anywhere. For the purposes of this application the user can also have their own custom digital wallet that can exist on their own phone or device and not on a remote server….
[0224] …. In one embodiment, the attestor may verify that the user indicated in the information sent by the organization is a registered user that holds a valid account at an attestor. As previously discussed, in one embodiment, the attestor 1330 may look for the information or the public key or the attest key in an existing database of attested users using standard database search functionality. In one embodiment, the attestor 1330 may positively identify an existing authenticated and registered user that holds a valid account at the attestor (a registered user) using the information and/or the public key of the individual that has been received. If the user is not a registered user and does not hold a valid account, the attestor 1330 informs the organization 1320 and the organization falls back to traditional individual verification. If the user is registered and does hold a valid account, in step 1354, the attestor 1330 uses the information and the public key to generate the attest key and uses the attest key to generate the attestation address, and verifies that the attestation transaction is present at the attestation address and that the attestation transaction has not been revoked. If the attestor 1330 determines that there is not a valid attestation transaction representing the user information, then the attestor 1330 alerts the organization 1320 that they are not able to verify the information of the individual 1310 and in step 1355 c, the organization falls back to traditional methods of verifying the individual 1310 in order to process or decline the business transaction….}
enabling granting of trusted status, and
{[0161].…The verifier may, without a need to contact a central provider of trust, employ a verification protocol to verify information provided by a user, where the user has previously had the information attested to by an attestor as part of an attestation protocol. Using for example, one or more of an application, a website, and an attestor API, the verifier may satisfy itself that the information provided by the user is authentic by re-deriving the attestation address of an attestation transaction, and seeing that the attestation transaction exists in the centralized or distributed ledger at the attestation address. A verifier may provide unique, time-sensitive information, such as a cryptographic nonce, to the user who then may sign the information using the signing protocol with the user's private key as may be required. The verifier may, in this way, ascertain that this attested information belongs to the user or that the user's private key is in the current control of the user…}
replicating the user's public digital identity to be publicly available in the distributed ledger on the DID network; and-
Grants user verification and trust and identification
{[0161].…The verifier may, without a need to contact a central provider of trust, employ a verification protocol to verify information provided by a user, where the user has previously had the information attested to by an attestor as part of an attestation protocol. Using for example, one or more of an application, a website, and an attestor API, the verifier may satisfy itself that the information provided by the user is authentic by re-deriving the attestation address of an attestation transaction, and seeing that the attestation transaction exists in the centralized or distributed ledger at the attestation address. A verifier may provide unique, time-sensitive information, such as a cryptographic nonce, to the user who then may sign the information using the signing protocol with the user's private key as may be required. The verifier may, in this way, ascertain that this attested information belongs to the user or that the user's private key is in the current control of the user…...
[0225-0227] A user interface screen on the user's mobile device may simulate an identification card 1400. The identification card 1400 may present Personal Identification information, which may include a photograph of the user, their age, their employer, their home address, their sex, height, eye color, weight, phone number, messaging address, email address, social media address/username/handle, etc. It may also show their digital crypto-currency recipient address 1430. The identification card 1400 may include a series of checkboxes 1410 (e.g., on the bottom left of the figure) showing what sources of information are authenticated by the attestor.…[0226] In order to communicate to a verifier, the identification card 1400 may present an animated image 1440 that conveys information to a verifier application or an attestor application running on another smartphone or using a camera attached to a computer. The identification card 1400 may be placed so that the moving image 1440 can be viewed by the receiving application. The data transfer may be used to send authenticated information as described in FIG. 2-FIGS. 5a /5 b and herein. [0227] The user may also use the identification card 1400 to log into a site such as a website. In this case, the site may display a moving graphic as in 1440 but in this case the attestor application may use a smartphone camera to record and interpret the information being transmitted from the site. An application for the identification card 1400 may then transmit appropriate attested credentials to the site as described herein.
enabling issuing of a credential by a realtor user to the digital wallet of another user of one or more of, a bona fide neighbor, a bona fide owner, a bona fide buyer, or a bona fide seller.
Establishing secure digital wallet linked to a decentralized network that validates user identity and ownership of property.
{[0120] A validator may include without limitation a validation site or device, any user or attestor, a border agent, a peace officer, a military post, an officer, a Transportation Security Administration (TSA) agent, a hotel clerk, a merchant, a transaction partner, a seller, a buyer, a credit verification agency, a bank, a store, a partner, a companion, an employee, an employer, and the like. A validator may include someone or something into which a relationship has been entered. A validator may include someone or something into which a relationship is still prospective. A validator may include a potential personal partner or mate. A validator may include without limitation an identity validation service provider, a biometric device, any entity who knows a user personally, a notary, a credit reporting agency, a government, a school, a relative, another user, and the like…
Bona fide owner represented by user’s digital wallet
[0122-124] A digital wallet is a collection of keys that controls digital assets or funds. It may allow a user to make electronic commerce transactions easily and securely. A digital wallet may support a multisig script, in other words the wallet may be able to take multiple keys to create an attestation address…. [0123] A digital wallet provider is a provider that stores a user's digital wallet on the user's behalf, usually on a remote server, so that the information is easily accessed from anywhere. For the purposes of this application the user can also have their own custom digital wallet that can exist on their own phone or device and not on a remote server. Additionally, the user's own digital wallet can be backed up to a third-party website or service. A third-party cosigner is a party that participates in making a transaction with a multisig wallet that requires signatures from M of N keys before the attestation is finalized and broadcast to the blockchain network. [0124] …. A site may include without limitation a website, a cloud service, a server, a distributed cloud service, a SaaS application, a decentralized application, a hosted service, an application, a mobile application, or the like. A site may include a banking site, an e-commerce site, a merchant site, a governmental site, a personal site, a social networking site, a messaging site, a search site, a news site, an information site, or the like.
Examiner notes that terms like realtor are mere labeling terms for the user and don't distinguish structurally and/or functionally from the prior art and therefore accorded little patentable weight. See MPEP 2111.05 and explanation regarding nonfunctional descriptive material. This interpretation holds for other mentions of the term realtor in the claim.
Smith doesn’t disclose the real estate transaction with realtor users; however, Friedman discloses:
pertaining to a subject property of a specific anticipated real estate transaction; as to the subject property of the specific anticipated real estate transaction
{[0042] According to some embodiments, an interactive computing environment provides various online auction services, such as auction services for transacting real-property. In some embodiments, the computing environment is partitioned into a first partition comprising a set of interactive services and data, and into a second partition comprising a second set of interactive services. [0045] Some embodiments described herein relate to the auctioning of real-estate. Embodiments recognize that transactions for real estate post several challenges. Among the challenges, embodiments recognize that real estate has numerous statutory requirements before it can be transacted. For example, unlike consumer electronics or goods, a seller cannot just decide to upload images and description for real estate property before there is a transaction. Still further, estate transactions often require various verifications, including (i) verification of a property that is to be sold, (ii) verification that the seller owns the property in question, and (iii) verification that the buyer has funds to purchase the property.
[0050] In particular, system 100 can be made available for use by buyers, sellers, specialized vendors or users (e.g., realtors, investment entities, commercial entities etc.). Additionally, system 100 can be partitioned to system-level customers or users who can segment resources of system 100 for hosting auctioning services independent of other customers or users. These and other benefits are described in greater detail below.}
Motivation: It would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to modify the online transaction system as disclosed by Smith, with the inclusion of real-estate agents and users in the real-estate transaction as taught by Friedman, for the purpose of enhancing the user experience and secure transaction, in a real-estate context{see [0050] of Friedman}.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Gordon et al (US2022/0058706), which teaches: A system and method, that has a protective cryptographic transaction ledger that enables property owners to require subsequent holders of interests in its property to verify the property owner's informed consent to any transaction that creates or created an interest in its property in any other party. The method includes using an automated agent in a computing device to receive request from a property owners to prepare a record of a contract for verifying and authenticating title-modifying transactions according to a protective scheme included in the contract and which are stored as digital records in a cryptographically protected ledger. A digital certificate is used to verify authenticity of the digital records and confirm consent to the title-modifying transaction.
Genner et al (US2017/0134366), which teaches: Verification for online users combined with methodologies for evaluating or demonstrating trustworthiness using.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to VICTOR CHIGOZIRIM ESONU whose telephone number is (571)272-4883. The examiner can normally be reached Monday - Friday 9:00 am - 5pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, SARAH MONFELDT can be reached on (571) 270-1833. 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, vis it: 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.
/VICTOR CHIGOZIRIM ESONU/
Examiner, Art Unit 3629
/JOHN S. WASAFF/Primary Examiner, Art Unit 3629
Prosecution Insights