Patent Application
20200404054
The present invention relates generally to software, and more particularly to mobile applications (aka mobile apps).
PubNub aka “pubnub” herein is intended to include PubNub.com's realtime publish/subscribe messaging API, built on the pubnub global data stream network which comprises a replicated network of data centers on several networks and provides realtime infrastructure-as-a-service.
PubNub technology utilizes a Publish/Subscribe model for realtime data streaming and device signaling and supports streaming protocol capabilities such as those of the following streaming protocols: WebSockets, Socket.IO, SignalR, WebRTC Data Channel PubNub provides SDKs for various programming languages and environments such as JavaScript, iOS, and Android, as well as JavaScript frameworks such as AngularJS, Ember.js, and Backbone.js. PubNub provides client libraries for board platforms such as Raspberry Pi, Arduino, Tex. instruments, and Microchip.
Pubnub provides, inter alia:
Functions: a set of customizable microservices that give developers a simple way to add code and deploy features for realtime apps
Publish/Subscribe Messaging: provides realtime data streaming and device signaling, and includes built in AES encryption and optional TLS/SSL encryption. The atomic components that make up a data stream are API Keys, Messages, and Channels. This feature handles channels in a lightweight manner, allowing software developers to create an unlimited number of channels for any set of API keys without first declaring the channel.
Online Presence Detection: provides tracking of online and offline status of users and devices in realtime. Presence events are triggered when a connected device subscribes or unsubscribes from a channel, or times out. The Presence API also includes a “state” feature allowing for the persistent tracking of any name/value pair a software developer specifies, such as a “typing” event indicator in a basic chat application.
Access Management: provides fine grain read and write access control on a per user, device, or channel basis. This adds an extra layer of security and enables the syndication of streams by providing authorization to individual users, as well as grant/revoke permissions at the channel or key level.
Data Stream Controller: multiplexes individual data streams as a single persistent connection, and centralizes control of the creation and modification of groups of data channels at the server level.
Storage & Playback: stores messages as they are published to a data channel, and retrieves them from high-availability storage clusters at a later time. Data streams can also be replayed as they were broadcast in realtime.
Mobile Push Notifications bridges native Pub/Sub Messaging API publishing with third-party push notification services including Google Android GCM, Apple iOS APNS, and Microsoft Windows Phone MSNP. The developing, configuring, and maintaining of server side components for third-party providers is provided by the PubNub API.
ChatEngine: open source, object oriented, event emitter based framework for building chat applications in JavaScript. provides chat application components such as typing indicators, online presence monitoring, and message history. built with connectors to PubNub's APIs, e.g. Publish/Subscribe Messaging and Storage & Playback.
It is appreciated that pubnub technology is only one possible alternative implementation; alternative p2p services or any data stream network and/or real-time infrastructure-as-a-service may be employed such as but not limited to other publish/subscribe alternatives e.g. Pusher or Socket.io or a service based on a real-time communication service for connecting online devices, e.g. with a Publish-Subscribe messaging API, such as for example Emitter.io.
Jira is referred to herein as an example of a software development tool for bug tracking and/or project management.
Zeplin is referred to herein as an example of software which facilitates moving files back and forth between designers and engineers.
Echo is referred to herein as an example of web application framework software. Echo is an example of software that supports writing applications in either server-side Java or client-side JavaScript.
Deep linking may use a hyperlink or URL that links to a typically searchable or indexed item of web content on a website rather than, say, to the website's home page. While the Hypertext Transfer Protocol (HTTP), does not distinguish between “deep” and other links, In mobile apps, deep linking typically involves using a uniform resource identifier (URI) that links to a specific location within a mobile app.
A splash screen is intended to include any graphical control element which may comprise a window containing all or any subset of an image, a logo, or a current version of software. A splash screen may appear while a program is launching.
The disclosures of all publications and patent documents mentioned in the specification, and of the publications and patent documents cited therein directly or indirectly, are hereby incorporated by reference other than subject matter disclaimers or disavowals. If the incorporated material is inconsistent with the express disclosure herein, the interpretation is that the express disclosure herein describes certain embodiments, whereas the incorporated material describes other embodiments. Definition/s within the incorporated material may be regarded as one possible definition for the term/s in question.
Certain embodiments of the present invention seek to provide a computerized system and/or method and/or compute program product, facilitating transactions, such as but not limited to real estate transactions, between end-users.
Certain embodiments of the present invention seek to provide circuitry typically comprising at least one processor in communication with at least one memory, with instructions stored in such memory executed by the processor to provide functionalities which are described herein in detail. Any functionality described herein may be firmware-implemented or processor-implemented as appropriate.
It is appreciated that any reference herein to, or recitation of, an operation being performed is, e.g. if the operation is performed at least partly in software, intended to include both an embodiment Where the operation is performed in its entirety by a server A, and also to include any type of “outsourcing” or “cloud” embodiments in which the operation, or portions thereof, is or are performed by a remote processor P (or several such), which may be deployed off-shore or “on a cloud”, and an output of the operation is then communicated to, e.g. over a suitable computer network, and used by, server A. Analogously, the remote processor P may not, itself, perform the entire operation, and, instead, the remote processor P itself may receive output/s of portion's of the operation from yet another processor/s P′, may be deployed off-shore relative to P, or “on a cloud”, and so forth.
The present invention typically includes at least the following embodiments:
Embodiment 1. A software system comprising all or any subset of: a mobile app typically having a backend including a processor, whose logic supports plural functionalities typically used by end-users/clients of the mobile app; logic presenting, to each of a population of end users of the mobile app, a linear list of the functionalities, thereby defining an ordering of the functionalities; logic presenting an indication (aka journey status change aka journey status update), e.g. to each individual end-user, typically in at least near-real time, of how far along the list s/he has progressed in using the functionalities, wherein typically the mobile app logic allows at least one individual end user to use the functionalities repeatedly and/or in a sequence other than defined by the ordering, at least once, or after, the individual end-user has used all of the functionalities at least once.
Embodiment 2. A system according to any of the preceding embodiments wherein the backend provides at least one p2p (peer to peer) notification, including a journey status change of an end-user, to a p2p processor aka p2p subsystem aka p2p logic which gets messages indicating journey status changes, and stores them.
Embodiment 3. A system according to any of the preceding embodiments wherein the p2p subsystem comprises a pubnub server which gets pubnub messages indicating journey status changes, and stores them.
Embodiment 4. A system according to any of the preceding embodiments wherein the indication comprises a graphic indication e.g. checkmark associated with each of the functionalities on the linear list, which the individual end-user has already used and wherein no graphic indication is associated with functionalities on the linear list, which the individual end-user has not yet used.
Embodiment 5. A system according to any of the preceding embodiments wherein the p2p notification includes a journey data flat map storing a user journey steps and/or tasks, and wherein at least one client uses a journey payload to update at least one journey task on each p2p notification.
Embodiment 6. A system according to any of the preceding embodiments wherein when a client receives a journey status update, the update may be represented in a flat (not relational) map which includes a representation of the user journey including, in a single list, steps and/or tasks included in the journey, and wherein the update also includes a step/task key and/or a display name
Embodiment 7. A system according to any of the preceding embodiments wherein a single p2p channel and infrastructure is used to pass, as p2p messages, chat messages including text for the end-user to view; and journey status update.
Embodiment 8. A system according to any of the preceding embodiments wherein at least one chat message includes metadata which includes an identification of the chat message's sender and/or a media download key and/or a timestamp.
Embodiment 9. A system according to any of the preceding embodiments wherein the p2p processor uses sockets rather than API polling to receive a real time indication of journey status changes.
Embodiment 10. A system according to any of the preceding embodiments wherein the metadata is stored in the p2p side, in association with messages history.
Embodiment 11. A system according to any of the preceding embodiments wherein the metadata is stored locally, on the end users smartphone's local storage.
Embodiment 12. A system according to any of the preceding embodiments wherein at least one mobile client saves at least some properties in order to subsequently display the properties later including retrieving the properties from the local storage rather than requesting the properties from the p2p service.
Embodiment 13. A system according to any of the preceding embodiments and also comprising at least one ‘get history’ API via which chat and status update messages stored by the p2p subsystem are retrieved.
Embodiment 14. A system according to any of the preceding embodiments wherein a server, upon identifying a journey status change relating to a given end-user, sends a message to a dedicated p2p channel extending to that end-user's client and wherein the end-user's client asks the history of the dedicated channel at a subsequent time, and if the client identifies a status change type message, the client makes a journey status change.
Embodiment 15. A system according to any of the preceding embodiments wherein the client includes logic which prioritizes asking the history during client-idle time over asking the history at a time t which is not client-idle time.
Embodiment 16. A system according to any of the preceding embodiments wherein the client includes logic which prioritizes asking the history during channel-idle time over asking the history at a time t which is not channel-idle time.
Embodiment 17. A system according to any of the preceding embodiments e.g. 15 or 16 wherein the client includes logic which always asks the history during idle time.
Embodiment 18. A method for facilitating use of a mobile app by end-users, the method comprising:
providing a mobile app having a backend including a processor, whose logic supports plural functionalities used by end-users/clients of the mobile app;
presenting, to each of a population of end users of the mobile app, a linear list of the functionalities, thereby defining an ordering of the functionalities;
presenting an indication (aka journey status change aka journey status update), to each individual end-user, in at least near-real time, of how far along the list s/he has progressed in using the functionalities,
wherein the mobile app logic allows at least one individual end user to use the functionalities repeatedly and in a sequence other than defined by the ordering, at least once the individual end-user has used all of the functionalities at least once.
Embodiment 19. A method according to any of the preceding embodiments wherein the end-users include buyer end-users and seller end-users and the mobile app supports creation and managing by an individual buyer end-user, of plural draft offers to plural seller end-users wherein the managing comprises defining branching logic for sending the draft offers to the seller end-users thereby to enable a buyer interested in more than one property offered by more than one respective seller end-user, to create a main offer and at least one additional draft offer/s and to define, even before the main offer has been accepted or refused, an actionable backup plan defining, via the branching logic, how the additional draft offers are to be engaged if the main offer is refused.
Embodiment 20. A method according to any of the preceding embodiments wherein the end-users include buyer end-users and seller end-users and the mobile app supports creation and managing by an individual buyer end-user, of at least one draft offer to at least one respective seller end-user and wherein the managing includes modifying at least one parameter of a draft offer, responsive to a counter-offer proposed by the seller end-user.
Embodiment 21. A method according to any of the preceding embodiments wherein the end-users include buyer end-users and seller end-users and the mobile app supports creation and managing by an individual buyer end-user, of at least one offer to at least one respective seller end-user and wherein a virtual assistant is used to generate the offer.
Embodiment 22. A method according to any of the preceding embodiments wherein the offer includes a proposed buyer-seller transaction whose value is generated automatically, thereby to allow buyer end-users to benefit from automatically generated real estate value predictions.
Embodiment 23. A method according to any of the preceding embodiments wherein at least one market report is retrieved during creation of at least one offer.
Embodiment 24. A method according to any of the preceding embodiments wherein creation of at least one offer is expedited by holding a chat between the buyer end-user of the app and an expert end-user of the app.
Embodiment 25. A computer program product, comprising a non-transitory tangible computer readable medium having computer readable program code embodied therein, the computer readable program code adapted to be executed to implement a method for facilitating use of a mobile app by end-users, the method comprising:
providing a mobile app having a backend including a processor, whose logic supports plural functionalities used by end-users/clients of the mobile app;
presenting, to each of a population of end users of the mobile app, a linear list of the functionalities, thereby defining an ordering of the functionalities;
presenting an indication (aka journey status change aka journey status update), to each individual end-user, in at least near-real time, of how far along the list s/he has progressed in using the functionalities,
wherein the mobile app logic allows at least one individual end user to use the functionalities repeatedly and in a sequence other than defined by the ordering, at least once the individual end-user has used all of the functionalities at least once.
Also provided, excluding signals, is a computer program comprising computer program code means for performing any of the methods shown and described herein when the program is run on at least one computer; and a computer program product, comprising a typically non-transitory computer-usable or -readable medium e.g. non-transitory computer-usable or -readable storage medium, typically tangible, having a computer readable program code embodied therein, the computer readable program code adapted to be executed to implement any or all of the methods shown and described herein. The operations in accordance with the teachings herein may be performed by at least one computer specially constructed for the desired purposes or general purpose computer specially configured for the desired purpose by at least one computer program stored in a typically non-transitory computer readable storage medium. The term “non-transitory” is used herein to exclude transitory, propagating signals or waves, but to otherwise include any volatile or non-volatile computer memory technology suitable to the application.
Any suitable processor's, display and input means may be used to process, display e.g. on a computer screen or other computer output device, store, and accept information such as information used by or generated by any of the methods and apparatus shown and described herein; the above processor's, display and input means including computer programs, in accordance with all or any subset of the embodiments of the present invention. Any or all functionalities of the invention shown and described herein, such as but not limited to operations within flowcharts, may be performed by any one or more of: at least one conventional personal computer processor, workstation or other programmable device or computer or electronic computing device or processor, either general-purpose or specifically constructed, used for processing; a computer display screen and/or printer and/or speaker for displaying; machine-readable memory such as flash drives, optical disks, CDROMs, DVDs, BluRays, magnetic-optical discs or other discs; RAMS, ROMs, EPROMs, EEPROMs, magnetic or optical or other cards, for storing, and keyboard or mouse for accepting. Modules illustrated and described herein may include any one or combination or plurality of: a server, a data processor, a memory/computer storage, a communication interface (wireless (e.g. BLE) or wired (e.g. USB)), a computer program stored in memory/computer storage.
The term “process” as used above is intended to include any type of computation or manipulation or transformation of data represented as physical, e.g. electronic, phenomena which may occur or reside e.g. within registers and/or memories of at least one computer or processor. Use of nouns in singular form is not intended to be limiting; thus the term processor is intended to include a plurality of processing units which may be distributed or remote, the term server is intended to include plural typically interconnected modules running on plural respective servers, and so forth.
The above devices may communicate via any conventional wired or wireless digital communication means, e.g. via a wired or cellular telephone network or a computer network such as the Internet.
The apparatus of the present invention may include, according to certain embodiments of the invention, machine readable memory containing or otherwise storing a program of instructions which, when executed by the machine, implements all or any subset of the apparatus, methods, features and functionalities of the invention shown and described herein. Alternatively or in addition, the apparatus of the present invention may include, according to certain embodiments of the invention, a program as above which may be written in any conventional programming language, and optionally a machine for executing the program such as but not limited to a general purpose computer which may optionally be configured or activated in accordance with the teachings of the present invention. Any of the teachings incorporated herein may, wherever suitable, operate on signals representative of physical objects or substances.
The embodiments referred to above, and other embodiments, are described in detail in the next section.
Any trademark occurring in the text or drawings is the property of its owner and occurs herein merely to explain or illustrate one example of how an embodiment of the invention may be implemented.
Unless stated otherwise, terms such as, “processing”, “computing”, “estimating”, “selecting”, “ranking”, “grading”, “calculating”, “determining”, “generating”, “reassessing”, “classifying”, “generating”, “producing”, “stereo-matching”, “registering”, “detecting”, “associating”, “superimposing”, “obtaining”, “providing”, “accessing”, “setting” or the like, refer to the action and/or processes of at least one computer/s or computing system/s, or processorls or similar electronic computing device/s or circuitry, that manipulate and/or transform data which may be represented as physical, such as electronic, quantities e.g. within the computing system's registers and/or memories, and/or may be provided on-the-fly, into other data which may be similarly represented as physical quantities within the computing system's memories, registers or other such information storage, transmission or display devices or may be provided to external factors e.g. via a suitable data network. The term “computer” should be broadly construed to cover any kind of electronic device with data processing capabilities, including, by way of non-limiting example, personal computers, servers, embedded cores, computing system, communication devices, processors (e.g. digital signal processor (DSP), microcontrollers, field programmable gate array (FPGA), application specific integrated circuit (ASIC), etc.) and other electronic computing devices. Any reference to a computer, controller or processor is intended to include one or more hardware devices e.g. chips, which may be co-located or remote from one another. Any controller or processor may for example comprise at least one CPU, DSP, FPGA or ASIC, suitably configured in accordance with the logic and functionalities described herein.
Any feature or logic or functionality described herein may be implemented by processor/s or controller/s configured as per the described feature or logic or functionality, even if the processes or controller/s are not specifically illustrated for simplicity. The controller or processor may be implemented in hardware, e.g., using one or more Application-Specific Integrated. Circuits (ASICs) or Field-Programmable Gate Arrays (FPGAs) or may comprise a microprocessor that runs suitable software, or a combination of hardware and software elements.
The present invention may be described, merely for clarity, in terms of terminology specific to, or references to, particular programming languages, operating systems, browsers, system versions, individual products, protocols and the like. It will be appreciated that this terminology or such reference/s is intended to convey general principles of operation dearly and briefly, by way of example, and is not intended to limit the scope of the invention solely to a particular programming language, operating system, browser, system version, or individual product or protocol. Nonetheless, the disclosure of the standard or other professional literature defining the programming language, operating system, browser, system version, or individual product or protocol in question, is incorporated by reference herein in its entirety.
Elements separately listed herein need not be distinct components and alternatively may be the same structure. A statement that an element or feature may exist is intended to include (a) embodiments in which the element or feature exists; (h) embodiments in which the element or feature does not exist; and (c) embodiments in which the element or feature exist selectably e.g. a user may configure or select whether the element or feature does or does not exist.
Any suitable input device, such as but not limited to a sensor, may be used to generate or otherwise provide information received by the apparatus and methods shown and described herein. Any suitable output device or display may be used to display or output information generated by the apparatus and methods shown and described herein. Any suitable processor/s may be employed to compute or generate information as described herein and/or to perform functionalities described herein and/or to implement any engine, interface or other system illustrated or described herein. Any suitable computerized data storage e.g. computer memory may be used to store information received by or generated by the systems shown and described herein. Functionalities shown and described herein may be divided between a server computer and a plurality of client computers. These or any other computerized components shown and described herein may communicate between themselves via a suitable computer network.
The system shown and described herein may include user interface/s e.g. as described herein which may for example include all or any subset of: an interactive voice response interface, automated response tool, speech-to-text transcription system, automated digital or electronic interface having interactive visual components, web portal, visual interface loaded as web page/s or screen/s from server/s via communication network/s to a web browser or other application downloaded onto a user's device, automated speech-to-text conversion tool, including a front-end interface portion thereof and back-end logic interacting therewith. Thus the term user interface or “ui” as used herein includes also the underlying logic which controls the data presented to the user e.g. by the system display and receives and processes and/or provides to other modules herein, data entered by a user e.g. using her or his workstation/device.
Example embodiments are illustrated in the various drawings and tables; arrows between modules may be implemented as APIs, and any suitable technology may be used for interconnecting functional components or modules illustrated herein in a suitable sequence or order e.g. via a suitable API/Interface. For example, state of the art tools may be employed, such as but not limited to Apache Thrift and Avro which provide remote call support. Or, a standard communication protocol may be employed, such as but not limited to HTTP or MQTT, and may be combined with a standard data format, such as but not limited to JSON or XML.
Specifically:
Tables I-xv are described herein merely by way of example; inter alia, it is appreciated that in each table herein, all or any subset of the rows, columns and cells shown, may actually be provided.
Methods and systems included in the scope of the present invention may include any subset or all of the functional blocks shown in the specifically illustrated implementations by way of example, in any suitable order e.g. as shown. Flows may include all or any subset of the illustrated operations, suitably ordered e.g. as shown. Tables herein may include all or any subset of the fields and/or records and/or cells and/or rows and/or columns described.
In the swim-lane diagrams, it is appreciated that any order of the operations shown may be employed rather than the order shown, however preferably, the order is such as to allow utilization of results of certain operations by other operations by performing the former before the latter, as shown in the diagram.
In the flow diagrams, the method typically comprises all or any subset of the illustrated operations, suitably ordered e.g. as shown:
Computational, functional or logical components described and illustrated herein can be implemented in various forms, for example, as hardware circuits such as but not limited to custom VLSI circuits or gate arrays or programmable hardware devices such as but not limited to FPGAs, or as software program code stored on at least one tangible or intangible computer readable medium and executable by at least one processor, or any suitable combination thereof. A specific functional component may be formed by one particular sequence of software code, or by a plurality of such, which collectively act or behave or act as described herein with reference to the functional component in question. For example, the component may be distributed over several code sequences such as but not limited to objects, procedures, functions, routines and programs and may originate from several computer files which typically operate synergistically.
Each functionality or method herein may be implemented in software (e.g. for execution on suitable processing hardware such as a microprocessor or digital signal processor), firmware, hardware (using any conventional hardware technology such as Integrated Circuit technology) or any combination thereof.
Functionality or operations stipulated as being software-implemented may alternatively be wholly or fully implemented by an equivalent hardware or firmware module and vice-versa. Firmware implementing functionality described herein, if provided, may be held in any suitable memory device and a suitable processing unit (aka processor) may be configured for executing firmware code. Alternatively, certain embodiments described herein may be implemented partly or exclusively in hardware in which case all or any subset of the variables, parameters, and computations described herein may be in hardware.
Any module or functionality described herein may comprise a suitably configured hardware component or circuitry. Alternatively or in addition, modules or functionality described herein may be performed by a general purpose computer or more generally by a suitable microprocessor or as a virtual instance (locally configured or in a cloud based computing environment), configured in accordance with methods shown and described herein, or any suitable subset, in any suitable order, of the operations included in such methods, or in accordance with methods known in the art.
Any logical functionality described herein may be implemented as a real time application, if and as appropriate, and which may employ any suitable architectural option such as but not limited to FPGA, ASIC or DSP or any suitable combination thereof.
Any hardware component mentioned herein may in fact include either one or more hardware devices e.g. chips, which may be co-located or remote from one another.
Any method described herein is intended to include within the scope of the embodiments of the present invention also any software or computer program performing all or any subset of the method's operations, including a mobile application, platform or operating system e.g. as stored in a medium, as well as combining the computer program with a hardware device to perform all or any subset of the operations of the method.
Data can be stored on one or more tangible or intangible computer readable media stored at one or more different locations, different network nodes or different storage devices at a single node or location.
It is appreciated that any computer data storage technology, including any type of storage or memory and any type of computer components and recording media that retain digital data used for computing for an interval of time, and any type of information retention technology, may be used to store the various data provided and employed herein. Suitable computer data storage or information retention apparatus may include apparatus which is primary, secondary, tertiary or off-line; which is of any type or level or amount or category of volatility, differentiation, mutability, accessibility, addressability, capacity, performance and energy use; and which is based on any suitable technologies such as semiconductor, magnetic, optical, paper and others.
Typically, the first display screen displays checkmarks indicating to the end-user which mobile app functionalities s/he has succeeded in activating at least once; for example, in the illustrated embodiment, the end-user has completed the first two functionalities or menu items (find favorites and take tour) but has not yet completed the following 2 mobile app functionalities namely seeing market value of at least one home, and getting verified, in terms of identity and/or financially. Typically, the first display screen includes only functionality pertaining to the home finding stage of an end-user's journey, and typically does not include functionalities pertaining to the offer-making stage, or closing stage.
The second, Dashboard screen may serve as a springboard into a journey through the app, particularly for experienced end-users, and typically helps users find their verification status, documents, visits and team members (end-users of the system herein, such as lead a expert, local expert, transaction expert, back office expert, mortgage expert, which are associated with a given buyer). The dashboard screen menu includes all or any subset of the following menu items: Verification, Documents, Schedule, Team, and Offer (not shown). The “documents” menu item may, if selected, display to a user statuses of various property reports for various respective properties. The status may for example be “requested”, “in progress”, “incomplete”, “complete” etc. Each such status may include a link leading the end user to a pdf property report document. “Schedule” may, if selected, display to a user statuses, which may be arranged in date order, of various appointments to visit properties; each such status typically includes the property's address, date and time of appointment for the end-user to see this property, and status of that appointment e.g. complete, incomplete, confirmed, pending, cancelled, rescheduled, requested. The journey tab navigation mobile app screen typically includes all or any subset of the following menu items: Find favorites (aka wishlist), take tour (which may be “scheduled” as described herein), see market value, or get verified. Verification may, for example, comprise uploading, by an end-user of suitable documents such as pre-approval and proof of funds letters for financial verification by system logic and/or ID documents of buyer and/or of signatories on a contract for ID verification by system logic.
‘Verification” may include an end-user uploading scanned documents such as a Letter of Pre-Approval from a bank stating how much the end-user can afford and Proof of Funds.
Second column in
A layman's description of an example user experience, all or any subset of which may be generated by the methods of
Pick your favorites, schedule visits, get comps and review disclosures. Chat with Reali experts the whole way.
As you look through the listings, you can pick your favorites, schedule visits, and even make an offer.
Before visiting a home with one of our experts, we ask that you verify your identity. This helps us check that you're really you, keep our experts safe, fight fraud, and more.
Found your favorites? Schedule a visit and check it out in person. Make notes, take photos, and share with others.
Reali Experts will do a comparative market analysis (Comps) to help you understand the value of the home. We'll pull data on all things that might affect the property's value like the supply and demand, the neighborhood, proximity to schools, and entertainment.
We will check your ID, (So we've got the right person) and confirm how much you're qualified for (so we can get you in the right home).
Together we will process, submit, and win your home for the best price. Found your dream home? It's offer time. select the home you want to focus on and place your offer.
Ready to sign! We've reviewed your offer, it just needs your signature. Once signed, we will package your offer, pre-approval documents, and any additional documents and send them to the Listing Agent. We will let you know once the Listing Agent has confirmed receipt of your offer.
The seller has submitted a counter offer. You now have to review it and: Accept it, submit a counter offer, or reject it.
Your offer has been accepted! Time to move into escrow.
Submit your Earnest. Money Deposit (EMD) and you're in escrow! Your EMD is a good faith deposit and will be applied to closing costs.
If you had any contingencies in your offer, the clock is ticking. Now is the time to secure your mortgage and work with your Expert to get inspections completed so contingencies can be removed.
Complete your final walkthrough within 5 days of closing (unless you waived it). This gives you a last chance to look over the house and make sure repairs were made and there is no new damage.
Closing is the final step. Both parties sign the final paperwork, and the buyer becomes the legal owner of the home. Once the home sale is recorded, your Expert will meet you and give you the keys to your new home.
Since Reali represented you in your transaction, you get that cash back. You should receive your cash back within 10 days of closing.”
Any suitable solution may be implemented, for client awareness for Journey status changes. Given a dedicated API and defined structure for receiving each user's Journey status (e.g. completeness & actions restrictions), a user request for current status may occur anywhere in the flow, e.g. when the app is in the foreground, a user may get a chat notification indicating the change, and, at this point, the client corresponding to that user, may get the Journey status.
The flow is typically designed to avoid overloading the server with unnecessary status requests that may cause redundant DB access. For example, given a user with notifications turned off and an app in the background, while coming to the foreground, a request for status change may be redundant, resulting in redundant server work.
Any suitable protocol may be employed by a client requesting its end-users Journey status from the server.
p2p functionality e.g. Pubnub may be employed to yield a client-server mechanism operative to sustain changes in the journey structure, action restrictions, and action definitions. The server, upon identifying journey status change per user which may be triggered by any suitable trigger/s e.g. an Echo or an app action, may then send a message (e.g. dedicated channel or actual chat text messages to be presented to an end-user, with associated meta data) to a channel. The client may ask the history of this channel (typically, whenever it likes, e.g. during client- or channel- idle time), and upon identifying a status change type message, a journey status change may be made, typically each time the client identifies a status change type message. Statuses indications, e.g. indicating to a client that a task has been completed, yield an advantageous near real time responsiveness.
The following entities which may be defined (typically depending on the action/task) e.g. in the back end aka main server and/or on the mobile client, may include all or any subset of the following content respectively:
Journey Map: list of steps, Id, Name, Type, Steps
Step: Name, list of tasks
Task: Task_Key, Name, Status
User_Action: Action Key
Re Mobile clients and echo clients, the steps and tasks status can be triggered either by Echo or an app action.
Typically, the p2p notification contains the journey data (flat map) which is reliable in that the success rate of receiving p2p notifications is acceptably high, given demands of the situation. The client may use a journey payload (e.g. user journey representation in a JSON form) to update the journey tasks on each p2p notification. The flat map typically includes a representation of the user journey (e.g. steps and/or tasks) e.g. in a single list which typically contains a step/task key and/or a display name. When a client receives a journey status update, the update may be represented in a flat map (not relational).
In
In step 1, any suitable action's of an expert may trigger a change from one status to another. Typically, the expert processes and confirms a request (e.g. request for a visit, or a verification) that changes the status of that request. For example, perhaps a user submits a request for a visit (status requested), then an expert begins confirming availability of appointment (status pending), then finally confirms visit (status confirmed). The expert, processing and moving a request through the process, typically automatically triggers respective status updates, as the backend (e.g. in step 2)“processes” the expert's action to identify a journey status change.
Typically, when there is a first request for a specific type request (comps, visit, offer, etc.) the action of changing the status from pending or requested, to confirmed or complete, marks a journey step as complete. For example, when a user requests a visit for the first time and an expert confirms the visit, the journey step ‘Schedule a Visit’ may be marked as complete e.g. with a ticked mark. Any additional requests of the same type typically do not affect the journey.
In operation 3, ‘Status change chat message’ typically comprises a p2p (peer to peer) message. Typically, the same p2p channel and infrastructure is used to pass both chat messages and ‘status update’ messages.
A chat message's metadata may include all or any subset of sender, media download key, timestamp and/or other properties unrelated to the text the consumer views. Metadata is typically stored in the p2p side, typically along with messages history and/or on the device (e.g. local storage). Typically, the mobile client saves at least some properties in order to display them later from the local storage, without having to request from the p2p service.
In operation 4—the journey status may be requested from the pubnub (or p2p) server or from the backend server. This request may include a unique client ID used by the server to uniquely distinguish one end-user from another. Typically, each user, or Journey, has a unique ID. Upon launch, the client checks with the backend to determine the status for that journey.
In operation 6—the status response may indicate that end-user x has reached a given point within the linear list, e.g. has used the first “find your favorites” functionality in the linear list, and the “take a tour” functionality, but has yet to use the subsequent “see market value” and “get system verified” functionalities in the list. The backend may respond with the journey status in two ways: which sub-steps has the user completed (‘Find Favorites’, ‘Take a Tour’, etc. . . . ) and in which overall step the user currently is engaged (‘Step 1, Find Home’, ‘Step 2, Make an Offer’, etc.)
The pubnub (or other p2p functionality) block typically gets pubnub messages indicating journey status changes, and stores them. The p2p block—e.g. Pubnub—typically stores both chat and status update messages and typically stores every such message. Messages stored by the p2p e.g. pubnub block may be retrieved e.g. via ‘get history’ APIs.
The backend block is typically configured to serve two clients, Mobile and Echo.
Typically, usage of the p2p service ensures that the user's app gets journey updates aka status change indications in near real time, without server overloading with unnecessary status requests that would cause redundant DB access. For example, typically, upon a change in the user journey status, the p2p service may use sockets (rather than API polling) to receive a ‘real time’ indication. By saving an extra backend API call, the update is pushed’ to the client. Thus, even when the app is open and in the foreground, once a trigger occurs on the backend side, data is updated immediately on the client. Typically, API calls for the server are saved in order to retrieve data; thus redundant data access that would result, in most cases, in a ‘no change’ result, is saved. In contrast, if the client were configured to ask the server on curtain flows (e.g. when the journey view appears to the user), this would result in much redundant DB access for a response that contains no change.
According to certain embodiments, users are not required to register merely in order to explore the app which can be done without the user creating an account. Typically, only once an end-user wants to do something that generates data which is stored in the system DB such as, say, all or any subset of favorite a listing, scheduling a visit, chatting with an expert, the end-user is prompted to register, aka “force sign up”.
According to certain embodiments, each end-user identifies as a buyer or a seller, depending on whether s/he is interested in buying or selling a home. in the former/latter case, the user is typically shown a buyer's/seller's journey respectively.
In
“Step1” may for example include all or any subset of the operations shown in
The dashboard, for which an example screen display appears in
User Stories for the dashboard are described in the following table, Table I.
Dashboard_schedule menu item: example Requirements, all or any subset of which may be applicable in a given embodiment, are described in the following table,
Dashboard_verification: status of verifications (financial and identity) may be provided, as well as document level status updates. Requirements, all or any subset of which may be applicable in a given embodiment, are described in the following table, Table
an additional status may be provided for “not_started”.
Verification: according to certain embodiments, end-user verification by the system herein, or “becoming Reali verified”, requires that users are registered, and have uploaded a predetermined set of forms e.g. proof of identification, proof of funds, and pre-approval documentation. Users can, typically, upload these forms in any sequence they wish, and at any point during their search. If a user has selected that he/she has an all cash offer, then the pre-approval letter may be non-required for that user to be Reali Verified)
Once these forms are submitted, a computerized process, or alternatively, human Reali experts, review and approve the verification.
According to certain embodiments, the verification process includes:
User Stories, including acceptance criteria therefor, in the third or second to last column, are described in the following table, table v, whose columns respectively represent Title, User Story, Acceptance Criteria, and Notes.
(here and elsewhere, all references to Zeplin are merely by way of example and may be omitted or modified).
Reali Verified—Financial: Any suitable flow may be employed for financial verification e.g. as described herein.
Any suitable flow may be used to Edit a Document (share, edit, rename, and delete) Access Points are described in the following table, table vi.
User Stories are described in the following table, table vii.
STATUSES are described in the following table, table viii.
DOCUMENT CHANGES: Document changes may be reflected immediately upon a user's action. Typically, changes can be made only when the user's verification is not currently in review (Not in Working status). Typically, the submission button's are only enabled when the user's verification isn't currently in review (Not in Working status).
This option allows an end-user a Quick look at documents and status updates.
Any suitable user flows may be employed.
Requirements, all or any subset of which may be applicable in a given embodiment, are described in the following table, table ix:
Requirements, all or any subset of which may be applicable in a given embodiment, are described in the following table, table x:
User stories for Buyer Journey's Step 1: Find Home are described below in table xi.
User stories for Buyer Journey—Step 2: make offer are described in the following table,
Buyer Journey—Step 3: Close User Stories are shown in the following table,
To bring the end to end transaction for both Buyers and Sellers into the app, a bottom navigation bar may be provided, to allow users to easily explore and access the key parts of the app.
Using a bottom navigation bar may allow users access to the 5 top-level destinations within the app. Their location, visibility, and persistence allow quick access and pivoting between tabs. There may be 5 top-level destinations for Buyers and Sellers. The icons and order may remain the same between Buyers and Sellers, but content may change between the two. The tabs and their functions may be all or any subset of the following, shown in tables xiv and xv:
Many variations are possible depending inter alia on whether the platform is an iOS platform, Android platform or other, and on any other designer-specific considerations. For example, according to certain embodiments, all or any subset of the following main navigation tabs are provided for navigation: journey, dashboard, listings, buyer profile, chats. However, this is not intended to be limiting. According to certain embodiments, all or any subset of the following secondary navigation tabs are provided under the main Dashboard tab: Verification, Documents, Schedule, Team, and Offer. However, this is not intended to be limiting. According to certain embodiments, all or any subset of the following secondary navigation tabs are provided under the main Listings tab: My feed, Wishlist (aka Favorites), and My offer. However, this is not intended to be limiting. Also, any known process may be used to access chat, search and discovery for homes, etc. rather than, necessarily, the implementation described herein. Any flow may be used for the dashboard, verification, and offer functionality rather than, necessarily, the implementation described herein. Any suitable hierarchy of steps and substeps may be provided rather than, necessarily, the implementation described herein. Any suitable journey interaction, offer tracking etc. may be provided rather than, necessarily, the implementation described herein.
According to certain embodiments, when a user is prompted to make an offer, the user is prompted to activate a machine learning processor which generates, and display to a user, respective estimated probabilities of winning a home if certain prices are offered respectively. These probabilities may be estimated by storing and repeatedly e.g. continuously re-evaluating, which price offers, typically relative to estimated home value, succeeded in obtaining buyer acceptance of the offer. Any suitable independent variables may be employed, such as a score given to the market at the time of the offer.
It is appreciated that terminology such as “mandatory”, “required”, “need” and “must” refer to implementation choices made within the context of a particular implementation or application described herewithin for clarity and are not intended to be limiting since in an alternative implementation, the same elements might be defined as not mandatory and not required, or might even be eliminated altogether.
Components described herein as software may, alternatively, be implemented wholly or partly in hardware and/or firmware, if desired, using conventional techniques, and vice-versa. Each module or component or processor may be centralized in a single physical location or physical device or distributed over several physical locations or physical devices.
Included in the scope of the present disclosure, inter alia, are electromagnetic signals in accordance with the description herein. These may cam/computer-readable instructions for performing any or all of the operations of any of the methods shown and described herein, in any suitable order including simultaneous performance of suitable groups of operations as appropriate. Included in the scope of the present disclosure, inter alia, are machine-readable instructions for performing any or all of the operations of any of the methods shown and described herein, in any suitable order; program storage devices readable by machine, tangibly embodying a program of instructions executable by the machine to perform any or all of the operations of any of the methods shown and described herein, in any suitable order i.e. not necessarily as shown, including performing various operations in parallel or concurrently rather than sequentially as shown; a computer program product comprising a computer useable medium having computer readable program code, such as executable code, having embodied therein, and/or including computer readable program code for performing, any or all of the operations of any of the methods shown and described herein, in any suitable order; any technical effects brought about by any or all of the operations of any of the methods shown and described herein, when performed in any suitable order; any suitable apparatus or device or combination of such, programmed to perform, alone or in combination, any or all of the operations of any of the methods shown and described herein, in any suitable order; electronic devices each including at least one processor and/or cooperating input device and/or output device and operative to perform e.g. in software any operations shown and described herein; information storage devices or physical records, such as disks or hard drives, causing at least one computer or other device to be configured so as to carry out any or all of the operations of any of the methods shown and described herein, in any suitable order; at least one program pre-stored e.g. in memory or on an information network such as the Internet, before or after being downloaded, which embodies any or all of the operations of any of the methods shown and described herein, in any suitable order, and the method of uploading or downloading such, and a system including server/s and/or client/s for using such; at least one processor configured to perform any combination of the described operations or to execute any combination of the described modules; and hardware which performs any or all of the operations of any of the methods shown and described herein, in any suitable order, either alone or in conjunction with software. Any computer-readable or machine-readable media described herein is intended to include non-transitory computer- or machine-readable media.
Any computations or other forms of analysis described herein may be performed by a suitable computerized method. Any operation or functionality described herein may be wholly or partially computer-implemented e.g. by one or more processors. The invention shown and described herein may include (a) using a computerized method to identify a solution to any of the problems or for any of the objectives described herein, the solution optionally including at least one of a decision, an action, a product, a service or any other information described herein that impacts, in a positive manner, a problem or objectives described herein; and (b) outputting the solution.
The system may, if desired, be implemented as a web-based system employing software, computers, routers and telecommunications equipment as appropriate.
Any suitable deployment may be employed to provide functionalities e.g. software functionalities shown and described herein. For example, a server may store certain applications, for download to clients, which are executed at the client side, the server side serving only as a storehouse. Any or all functionalities e.g. software functionalities shown and described herein may be deployed in a cloud environment. Clients e.g. mobile communication devices such as smartphones may be operatively associated with but external to the cloud.
The scope of the present invention is not limited to structures and functions specifically described herein and is also intended to include devices which have the capacity to yield a structure, or perform a function, described herein, such that even though users of the device may not use the capacity, they are, if they so desire, able to modify the device to obtain the structure or function.
Any “if-then” logic described herein is intended to include embodiments in which a processor is programmed to repeatedly determine whether condition x, which is sometimes true and sometimes false, is currently true or false and to perform y each time x is determined to be true, thereby to yield a processor which performs y at least once, typically on an “if and only if” basis e.g. triggered only by determinations that x is true, and never by determinations that x is false.
Any determination of a state or condition described herein, and/or other data generated herein, may be harnessed for any suitable technical effect. For example, the determination may be transmitted or fed to any suitable hardware, firmware or software module, which is known or which is described herein to have capabilities to perform a technical operation responsive to the state or condition. The technical operation may, for example, comprise changing the state or condition, or may more generally cause any outcome which is technically advantageous, given the state or condition or data, and/or may prevent at least one outcome which is disadvantageous given the state or condition or data. Alternatively or in addition, an alert may be provided to an appropriate human operator or to an appropriate external system.
Features of the present invention, including operations, which are described in the context of separate embodiments, may also be provided in combination in a single embodiment. For example, a system embodiment is intended to include a corresponding process embodiment and vice versa. Also, each system embodiment is intended to include a server-centered “view” or client centered “view”, or “view” from any other node of the system, of the entire functionality of the system, computer-readable medium, apparatus, including only those functionalities performed at that server or client or node. Features may also be combined with features known in the art and particularly, although not limited to, those described in the Background section or in publications mentioned therein.
Conversely, features of the invention, including operations, which are described for brevity in the context of a single embodiment or in a certain order, may be provided separately or in any suitable sub-combination, including with features known in the art (particularly although not limited to those described in the Background section or in publications mentioned therein) or in a different order. “e.g.” is used herein in the sense of a specific example which is not intended to be limiting. Each method may comprise all or any subset of the operations illustrated or described, suitably ordered e.g. as illustrated or described herein.
Devices, apparatus or systems shown coupled in any of the drawings may in fact be integrated into a single platform in certain embodiments or may be coupled via any appropriate wired or wireless coupling such as but not limited to optical fiber, Ethernet, Wireless LAN, HomePNA, power line communication, cell phone, Smart Phone (e.g. iPhone), Tablet, Laptop, PDA, Blackberry GPRS, Satellite including GPS, or other mobile delivery. It is appreciated that in the description and drawings shown and described herein, functionalities described or illustrated as systems and sub-units thereof can also be provided as methods and operations therewithin, and functionalities described or illustrated as methods and operations therewithin can also be provided as systems and sub-units thereof. The scale used to illustrate various elements in the drawings is merely exemplary and/or appropriate for clarity of presentation and is not intended to be limiting.
Any suitable communication may be employed between separate units herein e.g. wired data communication and/or in short-range radio communication with sensors such as cameras e.g. via WiFi, Bluetooth or Zigbee.
It is appreciated that implementation via a cellular app as described herein is but an example, and, instead, embodiments of the present invention may be implemented, say, as a smartphone SDK, as a hardware component, as an STK application, or as suitable combinations of any of the above.
Any processing functionality illustrated (or described herein) may be executed by any device having a processor, such as but not limited to a mobile telephone, set-top-box, TV, remote desktop computer, game console, tablet, mobile e.g. laptop or other computer terminal, embedded remote unit, which may either be networked itself (may itself be a node in a conventional communication network e.g.) or may be conventionally tethered to a networked device (to a device which is a node in a conventional communication network or is tethered directly or indirectly/ultimately to such a node).
| Number | Date | Country | Kind |
|---|---|---|---|
| 267514 | Jun 2019 | IL | national |
