CA2800102A1 - Apparatuses, methods and systems for a property transaction facilitating hub - Google Patents

Abstract

The apparatuses, methods and systems for a property transaction facilitating HUB ("HUB") facilitates the generation, evaluation, and recording of information and activities related to property transactions and the communications surrounding them as well as the relationships' dependencies, work flows, activities related to activity tracking, and/or the like. HUB systems facilitate a more organized and efficient approach to coordinating activities (e.g., sales activities) around a centralized database of contacts. By linking pending and/or historical activities to a contact, company, sales opportunity, data resource, and/or the like, a user or team of users may more readily discover linkages and interrelationships between parties and linked data along with more readily discovering new business opportunities via side-by-side and bifurcated comparisons. Linking activities to users may also allow for the prioritization of tasks according to urgency, due date, client, counterparty, and/or the like. Such organization of activities around users, contacts, and/or the like facilitates higher order and efficiency, which is likely to yield greater productivity.

Description

1 APPARATUSES, METHODS AND SYSTEMS FOR A PROPERTY

2 TRANSACTION FACILITATING HUB

3 RELATED APPLICATIONS AND PRIORITY CLAIMS

4 [o 0 01 ] This is a Continuation-In-Part of and claims priority under 35 U.S.C. 120 to prior U.S. Non-Provisional Patent Application serial no. 12/977,700 entitled, 6 "Apparatuses, Methods and Systems for a Lead Generating HUB," filed December 23, 7 2010 (attorney docket no. 20455-002CP4); to prior U.S. Non-Provisional Patent 8 Application serial no. 12/960,637 entitled, "Apparatuses, Methods and Systems for a 9 Lead Exchange Facilitating HUB," filed December 6, 2010 (attorney docket no.

002CP3); to prior U.S. Non-Provisional Patent Application serial no.
12/883,110 11 entitled, "Apparatuses, Methods and Systems for an Intelligent Inbox Coordinating 12 HUB," filed September 15, 2010 (attorney docket no. 2o455-002CP2); to prior U.S.
13 Non-Provisional Patent Application serial no. 12/872,011 entitled, "Apparatuses, 14 Methods and Systems for an Activity Tracking and Property Transaction Facilitating Hub User Interface," filed August 31, 2010 (attorney docket no. 20455-002CP1);
and to 16 prior U.S. Non-Provisional Patent Application serial no. 12/784,845 entitled, 17 "Apparatuses, Methods and Systems for an Activity Tracking and Property Transaction 18 Facilitating Hub," filed May 21, 2010 (attorney docket no. 20455-002). The entire 19 contents of the aforementioned applications are herein expressly incorporated by reference.

2 [0002] The present invention is directed generally to an apparatuses, methods, 3 and systems of commerce, and more particularly, to apparatuses, methods and systems 4 for a property transaction facilitating HUB.

BACKGROUND
6100031 Contact management systems have come about to allow users to store 7 information about individuals and organizations known to them, such as contact 8 information, job titles, impressions, personal details, and the like.
Contacts stored in 9 contact management systems may be organized and sorted based on a variety of criteria, 1o such as name, affiliation, or category. Contact management systems may include e-mail 11 or calendar systems to allow for communications with or management of contacts in the 12 contact management systems, such as the generation of correspondence with contacts 13 or the scheduling of tasks or events associated with the contacts.

[0004] The apparatuses, methods and systems for a property transaction 1s facilitating HUB (hereinafter "HUB") facilitates the generation, evaluation, and 17 recording of information and activities related to property transactions and the 18 communications surrounding them as well as the relationships' dependencies, work 19 flows, activities related to activity tracking, and/or the like. HUB
systems facilitate a more organized and efficient approach to coordinating activities (e.g., sales activities) 1 around a centralized database of contacts. By linking pending and/or historical 2 activities to a contact, company, sales opportunity, data resource, and/or the like, a user 3 or team of users may more readily discover linkages and interrelationships between 4 parties and linked data along with more readily discovering new business opportunities via side-by-side and bifurcated comparisons. Linking activities to users may also allow 6 for the prioritization of tasks according to urgency, due date, client, counterparty, 7 and/or the like. Such organization of activities around users, contacts, and/or the like 8 facilitates higher order and efficiency, which is likely to yield greater productivity.

9 [o 0 0 5 ] In one implementation, the HUB dynamically generates an interface based io on the role that a user has adopted for a given activity, allows the user to interact with 11 that interface to quickly and efficiently view information (e.g., present and/or historical) 12 of relevance to an actual or potential property transaction, and records user activities or 13 interactions so as to allow future access to a given interface state or set of relationships 14 defined by interface element values, such as they may pertain to the given property transaction, an associated counterparty or contact, and/or the like. In one 16 implementation, the HUB may provide quick access to contact information, including 17 property information owned, rented, leased, controlled, desired, dispositioned is requested, and/or brokered by the contact, and may include a bifurcated display to 19 allow for side-by-side visualization of required and available property information, attributes, and/or the like. The HUB may also implement a variety of other functions 21 and features in various embodiments, including individual lead generation, new 22 business generation and tracking, prospective lead generation, property data scraping 23 and/or distribution, report generation, dynamic querying and searching of historical 1 activity records, contact information and/or lead sharing, bounty reward lead 2 generation user interface modification and/or customization, and/or the like.

3 [o 0 0 6 ] In one embodiment, an activity recording processor-implemented method 4 is disclosed, comprising: receiving a contact identifier; retrieving contact information associated with the contact identifier; retrieving contact property attributes associated 6 with the contact identifier; receiving user property attributes; providing by the 7 processor a correlated display of contact property attributes and user property 8 attributes; recording at least one activity snapshot comprising at least one contact s property attribute, at least one user property attribute, the contact identifier, and a 1o timestamp; and storing the recorded at least one activity snapshot in an activity 11 database.

12100071 In one embodiment, an activity recording processor-implemented method 13 is disclosed, comprising: receiving a contact identifier; retrieving contact information 14 associated with the contact identifier; retrieving contact prospect attributes associated with the contact identifier; retrieving user requirement attributes; providing by the 16 processor a correlated display of contact prospect attributes and user requirement 17 attributes; recording at least one activity snapshot comprising at least one contact 18 prospect attribute, at least one user requirement attribute, the contact identifier, and a 19 timestamp; and storing the recorded at least one activity snapshot in an activity database.

21 [0008] In one embodiment, a linkage query generating processor-implemented 22 method is disclosed, comprising: receiving a user identifier; receiving a user role 23 specification; selecting a user interface based on the role specification;
generating a 1 linkage query based on the user identifier and the role specification;
querying linked 2 contact information from a contact-role database using the linkage query;
providing 3 linked contact information retrieved in response to the querying to the selected user 4 interface configured to provide the provided linked contact information for user

5 selection; receiving a linkage target contact selection from a selection from the linked

6 contact information; retrieving property attribute information based on the linkage

7 target contact selection; and populating at least one portion of the user interface with

8 the retrieved property attribute information.

9 [0009] In one embodiment, a property mapping processor-implemented method io is disclosed, comprising: receiving a mapping instruction; extracting property 11 information from fields in a user interface; querying property records from a properties 12 database based on the extracted property information; retrieving property records based 13 on the querying; and providing the retrieved property records for display in a map 14 interface according to geocode information associated with the property records.

[ 0 010 ] In one embodiment, a search facilitating processor implemented method 16 is disclosed, comprising: providing a plurality of variable selection elements for display;
17 receiving a first variable selection from a first variable selection element of the plurality 18 of variable selection elements; retrieving a plurality of available first variable values 19 corresponding to the first variable selection; providing the plurality of available first variable values for display in a selectable listing; receiving a first variable value selection 21 from the selectable listing; querying further available variable selections based on the 22 received first variable value selection; configuring remaining variable selection elements 1 based on the further available variable selections; and retrieving at least one data record 2 based on received variable value selections.

3 [0011] In one embodiment, a schedule optimizing processor-implemented .4 method is disclosed, comprising: receiving an appointment schedule, comprising a plurality of appointments, wherein each appointment includes a time and a location;
6 determining distances between locations of pairs of appointments in the appointment 7 schedule; determining time intervals between times of pairs of appointments having 8 distances determined to be within a specified distance range; generating a rescheduling s recommendation message when at least one determined time interval is within a 1o specified time interval range; and providing the rescheduling recommendation message 11 for display to a user. Such a method may also be implemented to provide intelligent 12 recommendations about scheduling new appointments that a user may not have 13 considered, such as may be based on distances from pre-existing appointments in a user 14 schedule, and/or the like.

[0012] In one embodiment, a real estate listing service system is disclosed, 16 comprising: a memory; a processor disposed in communication with the memory and 17 configured to issue a plurality of processing instructions stored in the memory; a listing 18 service module, stored in the memory, and configured to engage the processor to access 19 real estate listing information stored in the memory; and a barcode module, stored in the memory, and configured to engage the processor to receive and generate barcodes 21 associated with the real estate listing information.

22 100131 In one embodiment, an integrated contact relationship management and 23 real estate listing service system is disclosed, comprising: a memory; a processor 1 disposed in communication with the memory and configured to issue a plurality of 2 processing instructions stored in the memory; a listing service module, stored in the 3 memory, and configured to engage the processor to access real estate listing information 4 stored in the memory; and a contact relationship management module, stored in the memory, and configured to engage the processor to access contact information stored in 6 the memory and associated with the real estate listing information, and to track user 7 activities with respect to contacts associated with the contact information.

8100141 In embodiments, the HUB may be configured to effectuate intelligent s inbox coordination, which may facilitate the processing of messages configured as email to messages, XML data, HTTP POST message content, and/or the like for economical ii display and interaction. The HUB's intelligent inbox coordination features may allow 12 for the distillation of large volumes of message data and/or content to highlight and/or 13 direct users to the particular message and/or attachment containing data that is most 14 interesting or relevant to them. Aspects of HUB intelligent inbox coordination features may include the generation and application of email allocation rules and/or sub-rules;
16 analysis, parsing, intelligently filing and/or subfiling, and/or other processing of email 17 content, attachments, and/or other associated data; generation of message and/or 18 message data analytics, statistics, summaries, industry trends, news content, and/or the 19 like; and/or the like.

[ 0 015 ] In one embodiment, an intelligent inbox coordinating processor-21 implemented method is disclosed, comprising: retrieving at least one email message 22 from an email message repository; identifying at least one data file associated with the 23 at least one email message; accessing the at least one data file to extract file data;

i analyzing extracted file data to determine at least one category association of the at least 2 one email message; incrementing a counter for at least one category identifier based on 3 the at least one category association; generating a summary message including analytics 4 based on the at least one counter; and providing the summary message for display.

[o 016 ] In another embodiment, an intelligent inbox coordinating processor-6 implemented method is disclosed, comprising: periodically retrieving a plurality of 7 email messages addressed to a user from at least one designated email message folder, s wherein the plurality of email messages are previously directed to the at least one s designated email message folder based on an evaluation of the plurality of email io messages in relation to at least one email direction rule; identifying at least one flyer file 11 associated with each email message of the plurality of email messages, wherein the at 12 least one flyer file is configured as either an attached portable document format file, a 13 linked remote portable document format file, or a linked webpage; accessing the at least 14 one flyer file to extract property data, wherein accessing includes downloading the flyer file when configured as an attached portable document format file, and accessing an 16 associated link when configured as either a linked remote portable document format file 17 or a linked vvebpage, and wherein extracting property data includes converting the at 18 least one flyer file to text; analyzing extracted property data to determine property 1s category associations of the plurality of email messages, wherein analyzing includes:
parsing the extracted property data into a plurality of data fields, correlating the data 21 fields based on positional proximity in the flyer file, and identifying property data values 22 based on correlation of corresponding data fields with data fields of property data 23 identifiers, and wherein the at least one property category association is at least one of a 24 company, a property type, and an address field; incrementing counters for property 1 category identifiers based on property category associations; and generating a summary 2 message including statistical analytics based on the counters; and providing the 3 summary message for display to the user.

4 100171 In embodiments, the HUB may be configured to facilitate transaction and/or exchange of lead information, such as contact information, real estate site drives, 6 market comparables, marketing ideas, and/or the like. The HUB may engender a 7 tailored and efficient forum for coordinating transactions of lead information based on a 8 centralized database of contacts and other lead information associated with and/or 9 belonging to users. In one embodiment, users may submit lead requests comprising 1o parameters and/or criteria based on which one or more queries may be performed on 11 that database. Other users having leads matching the request may then be notified and 12 may decide whether to share their lead information with the requesting user. In one 13 implementation, users may include a bounty or other user-specified offer price with 14 their lead request, which may be provided to a lead owner upon transfer of the requested lead information. In some implementations, users may submit lead quality 16 rating scores and/or the like subsequent to receiving lead information, which may assist 17 future requestors in selecting the lead providers with whom they wish to engage in 18 transactions.

19 [00181 In one embodiment, a lead service exchange facilitating processor-implemented method is disclosed, comprising: receiving a lead request comprising lead 21 criteria from a requestor; querying a lead database based on the lead criteria to retrieve 22 a plurality of candidate lead matches, wherein each candidate lead match is associated 23 with at least one of a plurality of candidate lead match owners; generating a lead sharing i request message; providing the lead sharing request message to each of the plurality of 2 candidate lead match owners; receiving at least one lead sharing acceptance in response 3 to the lead sharing request message from at least one of the plurality of candidate lead 4 match owners; providing at least one lead candidate identifier corresponding to the at 5 least one of the plurality of candidate lead match owners for selectable display to the 6 requestor; receiving selection of the at least one lead candidate identifier from the 7 requestor; effectuating a compensation to the at least one of the plurality of candidate 8 lead match owners; and providing access to at least one of the plurality of candidate lead 9 matches associated with the at least one of the plurality of candidate lead match owners.

10 [0019] In another embodiment, a lead sharing processor implemented method is

11 disclosed, comprising: receiving a lead share request from a requestor, the lead share

12 request comprising at least one lead share parameter and a bounty offer;
querying user

13 records based on the at least one lead share parameter; retrieving at least one matching

14 lead based on the querying; retrieving a user quality rating corresponding to the user record associated with the retrieved at least one matching lead; determining a bounty 16 premium based on the user quality rating; and offering the at least one matching lead 17 for display to the requestor in exchange for payment of an acceptance amount equal to 18 the bounty offer summed with the bounty premium.

19 [00201 In another embodiment, an access permissions setting processor implemented method is disclosed, comprising: retrieving a list of user contacts 21 associated with a user; providing an access permissions setting interface, including the 22 list of user contacts, for display to the user; receiving at least one access permission 23 setting in association with at least one user contact via the access permissions setting 1 interface, the at least one access permission setting comprising at least one of a contact 2 access setting, a marketing idea access setting and a site drive access setting; and storing 3 the at least one access permission setting in association with the at least one user 4 contact and the user.

[0021] In embodiments, the HUB may be configured to identify leads for users 6 based on user-entered information, user contacts, and/or the properties associated with 7 a user and/or in which a user is interested, and/or identifying leads through properties a associated with a property listing database. Leveraging connectivity between contract 9 relationship management functionality, property listing service features, intelligent 1o inbox coordination capabilities, and/or the like, the HUB may identify connections 11 between user requirements and/or assets and opportunities to fulfill those requirements 12 and/or to transact those assets.

13 [0022] In one embodiment, a lead generating processor implemented method is 14 disclosed, comprising: receiving a plurality of property, tenant client, site drive and/or other field/market activity parameters; discerning an input activity associated with the 16 plurality of such parameters; determining a complementary activity that is 17 complementary to the input activity; generating a query statement based on the 18 plurality of such parameters and the complementary activity; querying lead records 19 based on the query statement to identify at least one matching lead record;
and providing the at least one matching lead record.

21 [00231 In another embodiment, a lead generating processor-implemented 22 method is disclosed, comprising: identifying a transactional counterparty associated 23 with a current activity; querying at least one record associated with the transactional 1 counterparty to retrieve at least one lead prospect; retrieving at least one lead prospect 2 record associated with the at least one lead prospect; comparing data field entries of the 3 at least one lead prospect record with activity data elements associated with the current 4 activity to yield a lead match rating; and generating a lead notification when the lead match rating is greater than a threshold.

7 [0024] The accompanying appendices and/or drawings illustrate various non-8 limiting, example, inventive aspects in accordance with the present disclosure:

9 [00251 FIGURES IA-C show implementations of a tenant-broker user interface in 1o embodiments of HUB operation;

11 [ 0 0 26] FIGURES 2A-B show examples of landlord-broker user interfaces in one 12 embodiment of HUB operation;

13 10027] FIGURES 2C-D show alternative implementations of HUB user interfaces 14 in embodiments of HUB operation;

[0028] FIGURE 3A shows an implementation of data flow between and among 16 HUB components in block-diagram form in one embodiment of HUB operation;

17 [0029] FIGURE 3B shows an implementation of a contact profile or contact data 18 record in one embodiment of HUB operation;

19 [003o] FIGURE 4 shows an implementation of data flow between and among HUB components and affiliated entities in one embodiment of HUB operation;

1100311 FIGURE 5A shows an implementation of logic flow for HUB system-user 2 interaction in one embodiment of HUB operation;

3 [0032] FIGURE 5B shows an implementation of role-based user interface profiles 4 in one embodiment of HUB operation;

[0033] FIGURE 6A shows an implementation of logic flow for query generation 6 and activity recording in one embodiment of HUB operation;

7100341 FIGURE 6B shows an implementation of activity based HUB UI field 8 resets in one embodiment of HUB operation;

9100351 FIGURE 7A shows an implementation of logic flow for lead generation in one embodiment of HUB operation;

11 10036] FIGURE 7B shows an implementation of logic flow for query construction 12 in one embodiment of HUB operation;

13 [00371 FIGURE 8A shows an implementation of logic flow for generating 14 marketing materials and links to those materials in one embodiment of HUB
operation;
15100381 FIGURE 8B shows an implementation of logic flow for user engagement of 16 marketing material links in one embodiment of HUB operation;

17 [00391 FIGURE 9 shows an implementation of user interface for accessing HUB
18 community features in one embodiment of HUB operation;

19 [00401 FIGURE to shows an implementation of logic flow for effectuating lead transactions in one embodiment of HUB operation;

21 10041] FIGURES 11A-D show an implementation of user interface for contact 22 exchange in one embodiment of HUB operation;

110042] FIGURES 12A-C show an implementation of user interface for marketing 2 idea exchanging in one embodiment of HUB operation;

3100431 FIGURES 13A-E show an implementation of user interface for site drive 4 information acquisition in one embodiment of HUB operation;

10044] FIGURES 14A-E show an implementation of user interface for activity 6 diagnostics and reporting in one embodiment of HUB operation;

7100451 FIGURE 15 shows an implementation of logic flow for geocode acquisition 8 in one embodiment of HUB operation;

9 10046] FIGURE 16A shows an implementation of logic flow for mapping HUB
1o data in one embodiment of HUB operation;

11 [0047] FIGURE 16B shows an implementation of logic flow for intelligent 12 mapping in one embodiment of HUB operation;

13 10048] FIGURE 17 shows an implementation of logic flow for map generation in 14 one embodiment of HUB operation;

10049] FIGURE 18 shows an implementation of a HUB map user interface in one 16 embodiment of HUB operation;

17 [0050] FIGURE 1g shows an implementation of a HUB map user interface in 18 another embodiment of HUB operation;

19 [00511 FIGURE 20 shows an implementation of a HUB map user interface in another embodiment of HUB operation;

21 [0052] FIGURE 21 shows an implementation of a HUB map user interface in 22 another embodiment of HUB operation;

110053] FIGURE 22 shows an implementation of a HUB map user interface in 2 another embodiment of HUB operation;

3 [0054] FIGURE 23 shows an implementation of logic flow for map interaction 4 and data extraction in one embodiment of HUB operation;

5 10055] FIGURE 24 shows an implementation of logic flow for dynamic map 6 updating in one embodiment of HUB operation;

7 10056] FIGURE 25 shows an implementation of logic flow for spatiotemporal 8 schedule optimization in one embodiment of HUB operation;

9 10057] FIGURE 26 shows an implementation of logic flow for a contact searching 1o rolodex in one embodiment of HUB operation;

11 [0058] FIGURE 27 shows an implementation of logic flow for contact display 12 configuration in one embodiment of HUB operation;

13 10059] FIGURE 28 shows an implementation of logic flow for a prospect 14 generation rolodex in one embodiment of HUB operation;

15 [0060] FIGURE 29 shows an implementation of data flow between and among

16 HUB components and affiliated entities in one embodiment of HUB operation;

17 [0061] FIGURE 30 shows an implementation of logic flow for intelligent inbox

18 coordination in one embodiment of HUB operation;

19 [0062] FIGURE 31 shows an implementation of logic flow for intelligent inbox coordination in another embodiment of HUB operation;

21 [0063] FIGURES 32A-B show implementations of logic flow and data parsing 22 rules for data scraping in one embodiment of HUB operation;

1 [ 0 0 64 ] FIGURE 33 shows an implementation of logic flow for inbox coordinator 2 configuration in one embodiment of HUB operation;

3 [00651 FIGURE 34 shows an implementation of logic flow for one-button rule 4 generation in one embodiment of HUB operation;

[ o o 6 6 ] FIGURE 35 shows an implementation of logic flow for summary screen 6 interactions in one embodiment of HUB operation;

7 [0067] FIGURES 36A-B show implementations of summary screen user 8 interfaces in one embodiment of HUB operation;

9 [0068] FIGURES 37A-B show implementations of summary screen user interfaces 1o in another embodiment of HUB operation;

11 [0069] FIGURE 38 shows an implementation of logic flow for summary screen 12 generation in one embodiment of HUB operation;

13100701 FIGURES 39A-C show implementations of user interface for time-resolved 14 summary screen elements in one embodiment of HUB operation;

100711 FIGURE 40 shows an implementation of logic flow for tracking user 16 message response analytics in one embodiment of HUB operation;

17100721 FIGURE 41 shows an implementation of logic flow for message display 18 prioritization in one embodiment of HUB operation;

19 10073] FIGURE 42 shows an implementation of logic flow for code capture information retrieval and processing in one embodiment of HUB operation;

21 100741 FIGURE 43 shows an implementation of logic flow for lead exchange in 22 one embodiment of HUB operation;

1 10075] FIGURE 44 shows an implementation of logic flow for lead exchange in 2 another embodiment of HUB operation;

3100761 FIGURE 45 shows an implementation of logic flow for lead exchange in 4 another implementation of HUB operation;

100771 FIGURE 46 shows an implementation of user interface for lead request 6 submission in one embodiment of HUB operation;

7 10078] FIGURES 47A-C show implementations of user interface for lead 8 candidate selection in one embodiment of HUB operation;

9100791 FIGURE 48 shows a schematic illustration of data flow between and 1o among HUB components and affiliated entities for lead generation in one embodiment 11 of HUB operation;

12 [0 080] FIGURE 49 shows a schematic illustration of data flow for lead generation 13 based on various inputs in one embodiment of HUB operation;

14 [0081] FIGURE 50 shows an implementation of logic flow for lead generation in one embodiment of HUB operation;

16 [o 0 8 2 ] FIGURE 51 shows a schematic illustration of alternative lead identification 17 in one embodiment of HUB operation;

18 10083] FIGURE 52 shows an implementation of logic flow for alternative lead 19 identification in one embodiment of HUB operation; and 10084] FIGURE 53 is of a block diagram illustrating embodiments of the HUB
21 controller.

1 [0085] The leading number of each reference number within the drawings 2 indicates the figure in which that reference number is introduced and/or detailed. As 3 such, a detailed discussion of reference number loi would be found and/or introduced 4 in Figure 1. Reference number 201 is introduced in Figure 2, etc.

3 [o 0 8 6 ] This disclosure details aspects of apparatuses, methods and systems for a 4 property transaction facilitating HUB (hereinafter, "HUB"). HUB embodiments may serve to facilitate contact relationship management, lead generation, property/retailer 6 and/or real estate browsing and/or searching, transactions, broker activity tracking, 7 and/or the like features and functionality. In one embodiment, the HUB may allow a 8 user to specify a role or "hat" in the context of a prospective transaction of property (e.g., 9 a buyer, seller, tenant, landlord, buyer/tenant or buyer broker, seller/landlord or ,o landlord or investment sales broker, investor, leasing agent, property manager, business ii developer, dispositioner, real estate professional, Municipality contact, and/or the like).
12 That role specification may then be used to configure a user interface, such as in 13 accordance with a role-based user interface profile, for presentation to the user. The 14 user may then interact with the user interface to specify desired, required, or available property/tenant attributes, based on which queries of property listings/tenants may be 16 performed to find matching results. The HUB may also include an integrated contact 17 relationship management (CRM) system configured to track and manage contact 18 information, such as may be associated with properties in the aforementioned property 1s listing, with transactions related to those properties, and/or the like. By integrating prospective property/tenant transactional listings with a CRM system, the HUB
enables 21 a wide array of new features and expanded functionality, further discussion of which is 22 provided below.

1100871 It is to be understood that, depending on the particular needs and/or 2 characteristics of a HUB user, counterparty, property characteristic, client device, server 3 device, control configuration, data payload, communication and/or network framework, 4 monetization model, and/or the like, various embodiments of the HUB may be 5 implemented that enable a great deal of flexibility and customization. The instant 6 disclosure discusses embodiments and/or applications of the HUB primarily directed to 7 real estate listings and transactions, especially as mediated by real estate brokers.
a However, it is to be understood that the systems described herein may be readily 9 configured and/or customized for a wide range of other applications and/or 1o implementations. For example, aspects of the HUB may be adapted for other types of 11 commerce, transactions of services, chattels, and/or the like, non-commercial 12 exchanges, service requirements fulfillment, side-by-side and bifurcated product and/or 13 lead comparison, matching and discovery, transactions of property and/or real estate in 14 a virtual world, and/or the like. For example, in various implementations, the HUB may 15 be adapted to any application having different parties wherein one party has 16 requirements to fulfill and the other party has capabilities, materials, expertise, assets, 17 and/or the like to fulfill those requirements. In other variations, the HUB
may be used 18 for side-by-side recruitment, skill-set, product and/or pricing comparison and 19 discovery, and/or the like. It is to be understood that the HUB may be further adapted

20 for other implementations or transactional applications.

21 [00881 FIGURES iA-C show implementations of a user interface in embodiments

22 of HUB operation. The illustrated interface in Fig. 1A may, in one implementation,

23 provide access to HUB features and functionality, and may, in one implementation, be

24 employed by a real estate professional acting on behalf of a tenant to engage possible 1 counterparties, landlords, landlord brokers, and/or the like to seek possible and/or find 2 potential properties for the tenant client. Although the instant specification may use the 3 term "broker," this term should be understood to encompass any real estate 4 professional, agent, broker, service provider, and/or the like. The role of the user as tenant broker is specified, in the illustrated implementation, via the radio button 6 elements shown at 101, where the tenant broker (i.e., "TB") button has been selected.
7 The illustrated implementation further includes buttons for landlord broker (i.e., 8 "LLB"), investment sales buyer (i.e., "INV SALES BUYER"), and investment sales seller 9 (i.e., "INV SALES SELLER"). Selection of a particular role may cause reconfiguration of 1o the user interface, reconfiguration of the manner in which states and/or values of user 11 interface elements are used to build database queries, and/or the like, as described in 12 further detail below.

13 [0089] The TB maybe provided with a list of all of his clients 103, wherefrom each 14 client may be selectable to populate a tenant client name 105 and/or tenant site requirements 155, indicating desired property attributes for that tenant client (e.g., 16 square footage, location, layout, features, amenities, view, type of location, price, terms, 17 and/or the like). A broker's client information may, in one implementation, be stored in 18 a contacts table of a HUB database. The availability of ready access to a list of clients 19 associated with the user allows for quick and easy access to clients who may have property requirements or desires matching a counterparty with which the broker is 21 engaged at any given time.

22 [00901 In one implementation, the interface may include a timer box 11o which 23 may provide a scheduling button to allow a user to generate a new scheduled activity 1 and/or a complete button to allow a user to indicate completion of a given activity and 2 or set of activities. In one implementation, scheduling a new activity may allow a user to 3 interact with a calendar and/or to enter a scheduled date, time, subject, completion 4 status, and/or the like in association with a scheduled event, such as a meeting, phone call, teleconference, and/or the like. In one implementation, scheduling a new activity 6 may cause the HUB to take a snapshot of a current set of user interface element states, 7 values, linkages, and/or the like and associate that snapshot with the scheduled activity, 8 such as for later retrieval and/or review. In one implementation, selection of activity 9 completion may cause conclusion of a given session, such as by terminating automatic recording of the session by a HUB activity recorder, as discussed in further detail below.
ii In one implementation, completion of an activity will automatically trigger re-12 initialization and recording of a new activity subsequent to the termination of the first 13 activity recording session. For example, an activity associated with one property may 14 have an assigned timer that will terminate and/or pause and/or reset when the activity for that property has concluded and/or when an activity associated with another 16 property has begun. In one implementation, an overall and/or global timer may 17 monitor the total time of a user session (e.g., such as may be associated with a given 18 user, communication with a given contact, and/or the like) while various and/or 19 multiple activities with their own timers begin, pause and/or end. In various HUB
implementations, pluralities of activity timers may be employed, including timers that 21 depend on other timers, are independent, begin or end upon a user interaction with the 22 UI, and/or the like. In one implementation, a user may select a completion button, or 23 otherwise manifest termination of a given activity, in order to terminate the timer for 24 that activity only, while the global timer continues to run. In another implementation, 1 selection of the completion button may cause the conclusion of a global session, possibly 2 comprising more than one activity recording session, and may terminate an overall 3 timer associated with the overall session. In one implementation, a single activity 4 and/or a single activity recording session may be associated with each interaction with a given counterparty, contra broker, and/or the like, regardless of whether a user changes 6 roles during the session. In one implementation, changing roles may cause additional 7 activity timers to stop and start. In one implementation, the timer box 11o may also 8 include an overall timer display, indicating a global time for the global session. The s timer box 11o may also, in one implementation, indicate other information about the 1o current or other scheduled activity, such as the scheduled date and/or time, subject, 11 activity status, priority, and/or the like. In one implementation, a user may be 12 permitted to edit the scheduled activity information, which may then be appended to a 13 data record corresponding to the scheduled activity and/or an activity recording session, 14 as described in further detail below. In one implementation, this may change the appropriate calendar record and associated scheduled date, time, subject, completion 16 status, and/or the like.

17 [00911 In one implementation, the interface may further include contact 18 information 115, such as may be derived from an integrated CRM system and/or may be 1s associated with another party with whom the user is engaged in an activity, such as a phone call, meeting, teleconference, instant messaging session, and/or the like 21 communications. Contact information may correspond to any of a wide variety of 22 different parties with whom the user may be engaged and/or about whom the user may 23 wish to investigate, such as but not limited to a contra broker, client, direct contact, 24 prospect for new business, transactional counterparty, and/or the like. The contact type 1 may, in one implementation, be stored in association with the contact and may appear 2 in the interface display upon selection of the contact. In one implementation, a user 3 may be permitted to edit the contact type and/or to select a corresponding contact type 4 from a selectable list for association with the contact. Displayed contact information may include any information stored in the CRM system in association with the contact, 6 such as but not limited to contact name, phone number, e-mail address, postal address, 7 recent activity, personal notes on the contact, and/or the like. In one implementation, 8 the interface may include an element, such as a button, integrated address book, and/or s the like 116 to allow the user to select a new contact with whom they are engaged. For 1o example, in one implementation, selection of a button such as that shown at 116 may ii cause the display of an address book, rolodex, user profile selection page, and/or the like 12 from which a user may select a new contact, whose information will then be displayed at 13 115. In one implementation, selection of a new contact may trigger resetting of the 14 overall activity timer 110, a particular activity timer or other subsidiary timer, and/or the like.

16 [ O O 9 2] In one implementation, the interface may further include a listing, 17 mapping, and/or other presentation of clients, existing client locations 125, target client 1s locations 130, and/or the like associated with the contact. For example, in an 19 implementation wherein the contact is a contra broker comprising a landlord broker (e.g., where the user is a tenant broker), the client's existing locations may be, for 21 example, existing rented and/or owned properties of the retailer client.
Rented and/or 22 owned properties may, in one implementation, be listed at 125, while properties and/or 23 property characteristics sought and/or desired for rent and/or purchase may be listed at 24 13o and/or 175. In another implementation, the same information and/or subsets 1 thereof may be included at 125 and 130, except organized differently. For example, the 2 information at 125 may comprise information pertaining to clients' properties 3 configured as a list, while the information at 130 may comprise information to clients' 4 properties organized according to a hierarchical and/or telescoping arrangement of 5 locations corresponding to a desired property location, such as may be specified by a 6 tenant client of the tenant broker user. For example, a tenant may specify one or more 7 target locations comprising location information, such as a country/region, state, 8 county, city, intra-city/village/suburbs/neighborhood, street, and/or the like. The client 9 locations may then be organized into a hierarchical chart of the target locations, at 1o varying degrees of target location specificity, so as to indicate which if any of the client 11 locations match the target country, target state, target city, and/or the like. In one 12 implementation, a user may click on the location hierarchy at any level to be provided 13 with a list of client properties matching that location. In one implementation, such a 14 provided list of client properties may be provided in the listing area at 125 in response to 15 selection of a location from the location chart at 130.

16 10093] The interface may also include facilities, such as "map it" and/or "list it"
17 buttons 120, which may allow a user to switch between views of the property listings, 18 from a list view to a view in which the properties are shown in their positions on a map.
19 In one implementation, these buttons may engage Google Maps application 20 programming interface tools to display listing elements on an embedded Google Map.
21 Any of a wide variety of other mapping tools and/or systems may be employed in 22 alternate implementations, such as but not limited to Yahoo Maps, Mapquest, Bing 23 Maps, and/or the like. In one implementation, a map may be displayed as an opaque, 24 translucent, or transparent overlay on top of the HUB UI. A user may, for example, then 1 be allowed to move the overlay map, to switch between an opaque overlay view and a 2 regular map view, and/or otherwise interact with the map and/or a mapping window.
3 In one implementation, the HUB may allow for overlaying of multiple maps, different 4 views of a single map, may allow the user to select different mapping applications showing the same subject property from different views in the same window or view, 6 different geographic and/or other property and/or contact information on a single map, 7 and/or the like. In one implementation, such information may be added or removed 8 from the map by checking or unchecking boxes or the like In one implementation, client 9 listings may be sorted and/or arranged based on any of a variety of criteria, such as, but io not limited to proximity to a specified location, recentness of entry and/or availability 11 for a given listing, contact rating, contact history and/or existence of scheduled activity 12 with the contact, and/or the like. In one implementation, mouse-over and/or selection 13 of a client in the client listing may result in display of any contact information stored for 14 that client in the integrated CRM system. In one implementation, selection of a client in the client listing may allow a property associated with that client to be loaded into an 16 existing prospective property match information area 16o and/or may cause creation of 17 a new search "paper" 140, both of which are described further below.

18 10094] A search paper 140 may, in one implementation, comprise a graphical 19 representation of a field of view, search area, sheet of paper, and/or the like aggregating modules and/or data for a target location, property, activity, search session, and/or the 21 like. For example, in one implementation, a paper 140 may be displayed for each target 22 location (the cities of Schaumburg and Calumet City in the implementation illustrated in 23 Figure 1). A new paper may be created, for example, upon user selection of a new paper 24 generation button (e.g., the add new prospective property button at 145), upon selection 1 of a new contra broker and/or contra broker property, and/or the like.
Different papers 2 may then be activated and/or brought to the foreground by clicking on the paper tabs, 3 such as those displayed at the left of each paper with the location name at 140. Paper 4 tab names may be allowed to take values at varying levels of specificity, such as, in one implementation, varying from county to a specific building address. In one 6 implementation, multiple papers may be associated with different prospective property 7 matches and, thus, not available for a user adopting a landlord broker role.
In one s implementation, when a tenant broker clicks on a new tenant client, the number of 9 papers may change accordingly, to reflect the existence of multiple papers generated io based on prior activity. In one implementation, there may exist a unique and/or 11 independent stack of papers for each tenant client. In various implementations, the 12 HUB interface may provide the ability to create a plurality of new papers at and 13 maintain them on-screen at any given time.

14 [o O 95] The interface may further include a bifurcated display 143 showing a side-by-side representation of site requirements and prospective property information, to 16 allow for attribute-by-attribute comparison of desired and available property attributes.
17 A list of property attributes, grid variables, and/or the like 150 may be provided next to 18 and/or as part of the bifurcated display to show identifiers of those attributes next to the 19 attribute values listed at 16o and 155. In one implementation, the list of attributes, grid variables, and/or the like displayed and/or for which corresponding fields exist in the 21 property information and/or site requirement areas, may depend on a variety of factors, 22 such as but not limited to the role selected by the user, fields customized by the user, a 23 current user activity, client characteristics, and/or the like. In one implementation, the 24 site requirement information 155 for a tenant client may be static, corresponding to the 1 property attributes specified as desired by the tenant, while the prospective property 2 match information 16o may admit inputs of property information by a user. In one 3 implementation, the interface may include a button or other interface element such as 4 that shown at 145 for initiating entry of new prospective property match information, attributes, and/or the like. In one implementation, selection of that interface element 6 may cause the HUB to store any prior prospective property match information entered 7 at 16o and clear the property information area for new entry. In one implementation, a 8 user may be prompted, prior to storage and clearance of the prior property information, o as to whether and/or how the prior property information should be stored (e.g., as a 1o proposed property, qualified property, presented property, declined property, and/or 11 the like). In one implementation, all UI elements or a specified subset of UI elements 12 may be removed, selectively added, moved, customized, and/or the like by a HUB user, 13 such as to maximize usability, promote efficiency, and/or optimize usage of features 14 important to the user.

[o 0 9 6 ] In alternative implementations or embodiments of HUB operation, the 16 bifurcated display at 143 and/or any other HUB features may be adapted for 17 transactions of chattels, transactions of services, non-transactional comparisons, and/or 18 the like. For example, in one implementation, a user may populated the requirements 19 side 155 of the bifurcated display 143 with skill requirements for a particular task and populate the prospective match side 16o of the display with existing skills of various 21 employees to find an employee best suited for a particular task. In another example, a 22 requirements side 155 may be populated with hardware requirements for a piece of 23 software and the prospective match side 16o may be populated with hardware devices 24 having various capabilities (wherein the contacts may, for example, be owners, 1 controllers, and/or the like of those hardware devices). The HUB system may generally 2 be adapted for any other application having interacting parties wherein one party has 3 specified requirements and one or more other parties have capabilities, availabilities, 4 skills, assets, services, and/or the like. In some implementations, the HUB
may be employed for side-by-side recruitment, skill-set, product and/or pricing comparison and 6 discovery, and/or the like.

7 10097] The bifurcated display may also include a plurality of buttons, or other a such interface elements configured to allow a user to transact marketing materials, s provide input access for property information, associate a status with prospective 1o property information entered at 160 and/or to move that information into a separate 11 table, such as that shown at 187 and discussed in further detail below, and/or the like.
12 For example, in the illustrated implementation, interface buttons are provided including 13 "move to qualified," "move to declined," "allow LLB to directly enter property data,"
14 "view/email/upload marketing materials," and "request marketing materials."
A move to qualified button may allow a user to store entered prospective property match 16 information, label it as qualified property information, populate a qualified properties 17 area of a table such as that shown at 187 with the prospective property information, 18 and/or the like. A move to declined button may allow a user to store entered 1s prospective property information, label it as declined property information, populate a declined properties area of a table such as that shown at 187 with the prospective 21 property information, and/or the like. An allow LLB to directly enter property data 22 button may allow for direct entry of property information into the property information 23 portion of the bifurcated display 16o by a contra broker or other counterparty of the 24 user, such as via an instant messaging protocol. In one implementation, a contra broker 1 or counterparty may enter property information, and the user may employ an auto-form 2 fill whereby line items in the form are received by the tenant broker, who may then 3 automatically accept the filled information and use it to fill the display at next viewing.
4 A view/email/upload marketing materials button may allow for quick generation and/or 5 transmission of marketing materials associated with property information shown in the 6 bifurcated display. A request marketing materials button may cause generation and/or 7 transmission of a request for marketing materials, such as may be associated with 8 information shown in the bifurcated display.

9 [00981 In one implementation, the interface may include a plurality of rating io indicators 175, such as one for each property attribute and/or grid variable listed in the ii bifurcated display. Such rating indicators may, in one implementation, allow a user to 12 specify and/or quantify how well a value of a grid variable of a prospective property 13 matches the required value of the grid variable in the site requirements.
For example, in 14 one implementation, the rating indicators may comprise three radio buttons resembling 15 a traffic light (e.g., red, yellow, and green buttons), and whereby a user may specify a 16 good, medium, or bad match between prospective property match information and 17 tenant site requirements. Any of a wide variety of other forms of rating indicators may 18 be used in various implementations, such as, but not limited to: numerical and/or 19 textual input fields, sliding bar rating indicators, thumbs up/down indicators, and/or 20 the like. In one implementation, an overall rating indicator 176 may also be included in 21 the interface. In one implementation, the overall rating indicator 176 may be 22 independent of the rating indicators at 175, and may allow a user to specify an overall 23 impression of a given activity, transaction, lead, opportunity, and/or the like. In 24 another implementation, the overall rating indicator 176 may be determined by values 1 entered to the rating indicators at 175, such as reflecting an average, weighted average, 2 and/or the like of the values of those indicators. The interface may further include a 3 deal stage field or other such interface element (e.g., radio button, pull-down menu, 4 and/or the like) allowing a user to specify a stage of the deal-making process in which a given activity, search, prospect, lead, and/or the like is situated. In one implementation, 6 attribute and/or global rating indicator values and/or a deal stage may be stored in 7 association with a given activity, such as part of an activity recording session.

8 [00991 In one implementation, the interface may further include a current activity s timer 178, indicating a time associated with a current activity, activity recording session, io and/or the like. The interface may further, in one implementation, include a facility, 11 such as a text entry window, to allow a user to enter notes, such as general notes, 12 impressions, and/or the like related to the current activity. In one implementation, a 13 note header may be automatically included indicating the linked activity and a time at 14 which each note was begun and/or edited.

[ o o i o o ] In one implementation, the interface may further include a "time 16 machine" facility comprising components to allow a user to scroll through a history of 17 HUB activities, notes, search queries, results, and/or the like and/or to dynamically 18 filter and/or branch that history by specifying filter variables. In one implementation, 19 the time machine facility may include interface elements, such as the rolling cylinders shown in the illustrated implementation at 182, to allow a user to enter desired values, 21 ranges, and/or the like of variables which may be used to filter returned activity 22 information. For example, the rotating cylinders in the illustrated implementation allow 23 a user to specify contact information (e.g., contact identity, location, and/or the like), i retailer and/or client information (e.g., retailer identity, location, and/or the like), site 2 requirement information, property information, and/or the like. In one 3 implementation, the variables that a user can adjust values for via the roller cylinders 4 may depend on the role that a user has assumed for a given activity. In one implementation, one or more cylinders may be locked on a given filter variable value to s set the locked value as the value to be used in a query of historical activities, notes, 7 and/or the like. In one implementation, locking of a filter variable value on one cylinder s may cause the space of available values for the other filter variables to be limited to 9 those corresponding to existing records having the requisite value for the locked filter 1o variable. For example, if a user locks the contact wheel on "John Smith,"
then thereafter 11 only the retailers, site requirements, and property information associated with John 12 Smith may be provided for selection on the remaining cylinders. The interface may 13 further include a timeline element 185 allowing a user to scroll through a range of dates 14 to set a specified desired date and/or the specify a range of dates over which a search of prior activities is to be conducted. For example, in one implementation, setting filter 16 variable values will call a list of activity records having filter variable values matching 17 those set by the user via the cylinders 182 and will populate the timeline 185 with times 18 of those matching records. Then, a user may move from record to record by scrolling 19 along the timeline. In one implementation, a page flow such as that shown in Fig. 1B
may be provided for display to a user to show matching historical records, allowing for 21 sequential review of activity snapshots and/or the like. In one implementation, 22 selection of each record will cause the bifurcated display and/or other aspects of the 23 interface of Fig. lA to reflect the activities, notes, property information, site 24 requirements, and/or the like associated with the selected recorded activity. A user may 1 select a button, such as the "Now" button shown at 186, to return the interface to the 2 current activity and/or to toggle between current activity and selected historical activity.
3 [o 0101 ] The interface may further include a table such as that shown at 4 displaying tabs for property information, activities, notes, and/or the like that have been labeled with various statuses. For example, in one implementation, a user may label 6 properties with statuses such as, but not limited to, prospective properties, qualified 7 properties, presented properties, declined properties, and/or the like. In one 8 implementation, prospective properties may comprise HUB system-determined possible o match recommendations, such as may be based on various property factors in ,o comparison with site requirements (e.g., proximity to target location, similarity of 11 square footage requirements, property attributes, and/or the like). In one 12 implementation, prospective property tabs may be populated with property information 13 scraped and/or otherwise extracted from marketing materials (e.g., documents in a 14 variety of electronic formats, such as Word documents, Portable Document Format documents, and/or the like), emails, websites, and/or the like. In one implementation, 16 qualified property information may comprise property information identified by the 17 user as a qualified candidate property awaiting approval from a tenant, retailer, client, 18 and/or the like. In one implementation, presented property information may comprise io property information that has been discussed with the tenant, retailer, client, and/or the like. In one implementation, declined property information may comprise property 21 information rejected by the user and or rejected by a tenant, retailer, client, and/or the 22 like. In one implementation, the interface may include a button or other such feature 23 188 allowing the user to map properties in the table at 187, such as by representing 24 properties with different statuses using different colors, symbols, and/or other 1 differentiators on the map display at their respective locations. In one implementation, 2 property mapping may be implemented with multiple layers that can be checked or 3 unchecked, such as with each layer corresponding to a given property status.
A user 4 may then, for example, selectively include or exclude layers in the map for various purposes, such as to only view qualified properties, or to view qualified properties 6 together with proposed properties. In one implementation, table values at 187 may be 7 dictated and/or otherwise influenced by user entries at 160.

8 [ 0 0 10 21 Figs. 1B and 1C show alternative implementations of HUB papers (cf. 140 9 in Fig. 1A) in embodiments of HUB operation. In Fig. 1B, papers are implemented as a 1o page flow interface 189 whereby a user may quickly flip through different HUB papers, 11 select a desired paper, and/or the like. In various implementations, a selected HUB
12 paper may be shown enlarged, may occupy a separate display area, may be fellable in its 13 place in the page flow, and/or the like. For example, HUB pages configured as Flash 14 packaged HTML may be displayed in a page flow such as that shown at 189 and still be configured for form filling. In one implementation, the interface such as that shown at 16 189 may also include other interface elements to adjust page viewing, such as a scrollbar 17 190, a size-adjustment handle to increase or decrease the viewing area of the interface 18 189, and a full-screen button 192 to cause the interface 189 to occupy an entire display 19 area. In Fig. 1C, papers are implemented as selectable and/or movable icons on a desktop and/or browser area 193. A page may be displayed as an icon 194 and, in one 21 implementation, multiple icons may be stacked 195, such as to form groups or 22 collections of pages. In one implementation, stacking of pages may cause records 23 associated with the pages to be associated with each other, in representation of the 24 stacking. In one implementation, a stack of papers such as that shown at 191 may be 1 associated with each other and/or with a unique tenant client. A selected page icon may 2 then be enlarged and/or populate a full-scale display area of the interface 196. In one 3 implementation, a single click, mouse-over, and/or the like on a given stack of papers 4 may show a preview of information associated with the stack and/or pop-up a window 5 indicating a tenant client identity, location, property attribute collection, and/or the like 6 associated with the stack for quick and economical user review. It should be noted that 7 the paper configurations shown in Figs. 1B and/or 1C may be employed in conjunction 8 with user interfaces configured for various user roles and/or hats, including a tenant 9 broker role, a landlord broker role, and/or the like. With regard to items 191 and 193, in io one implementation, these views may extend as a shelf 193, and/or be overlaid atop a ii portion of the HUB interface 196.

12 100103] FIGURE 2A shows an example landlord-broker user interface in one 13 embodiment of HUB operation. In the implementation illustrated in Fig. 2A, the LLB
14 role has been selected at the role selection element 201. In one implementation, the 15 interface may include, proximate to the contra broker contact information, a list of the 16 tenant clients 205 associated with and/or known to be associated with the contra 17 broker. Selection, mouseover, and/or the like of a tenant client in the list of tenant 18 clients may cause display of one or more site requirements associated with that tenant 19 client, allowing the user to quickly identify possible opportunities for transacting client 20 properties. The interface may further provide a listing of those tenant client site 21 requirements organized in a location chart similar to that shown at 130 in Fig. 1A. The 22 interface may further include a listing of the user's and/or user's clients' properties 215 23 for quick review and/or selection. When a retail tenant has been selected for discussion 24 or other activity, that retail tenant's name 220 may appear in an activity area of the 1 interface. The LLB interface may also provide a modified version of the bifurcated 2 display 230 whereby the property details 240, such as may be related to a particular 3 property and/or a particular client, are static, while the tenant site requirements 235 4 admit inputs. In one implementation, as inputs are added, the my properties and/or my company properties fields at 255 may be filled in real-time to reflect a broad range of 6 potential property matches narrowing as additional tenant site requirements are added 7 at 235. Depending on selection or un-selection of interface elements such as the boxes 8 at 255, the list of potential property matches may be narrowed and/or expanded in 9 accordance. The interface may also include facilities, such as the button elements 1o shown near 245, to allow a user to request a credit report, email credit release forms, 11 personal financial specialist statement, and/or the like from a contra broker, 12 counterparty, tenant, buyer, and/or the like. In one implementation, the table at 255 13 may include properties with various statuses (e.g., qualified, presented, declined) as well 14 as prospective properties of the user and/or the user's company.

151001041 In one implementation, the interface shown in Fig. 2A may be shown for 16 user activities related to a current landlord client. The user may select a tab such as that 17 shown near 258 to switch between an interface suitable for existing clients and another 18 interface suitable for prospective clients. In one implementation, a HUB
interface for 19 new business, prospective clients, and/or the like may take a form similar to the 20 example shown in Fig. 2B, where the "New Biz" tab has been selected at 260.
Contact 21 information associated with a prospective client may be displayed 262, ass well as a 22 listing of potential new property representations for that client 264. In one 23 implementation, clicking on a potential new property representation from the listing at 24 264 may cause the display at 265 to populate with any known information about the 1 property. Thereafter, a user's entry of property information at the area near 265 may 2 cause the information for that property listing to be updated, including, in one 3 implementation, in the listing displayed at 264. The interface may further include a 4 complete listing of known properties for the prospective client 266, beyond merely those listings for which the user may seek potential representation (i.e., those shown at 264).
6 In one implementation, potential new property representations for a given prospective 7 client may also be accessed by means of papers or tabs such as that shown at 268, s wherein each paper or tab may, for example, correspond to a given potential new 9 property representation for the prospective client. The interface may also, in one 1o implementation, include a table area 270 configured to display information such as 11 properties associated with the user which neighbor a potential new property 12 representation, properties associated with the user's company which neighbor a 13 potential new property representation, completed deals having attributes similar to the 14 potential new property representation, and/or the like which, in one implementation, can be customized by the user. Display of this information to the user may enable the 1s user to quickly relate relevant information to the prospective client to demonstrate a 17 familiarity with the locations, types of properties, and/or the like associated with the 1s prospective client and/or to demonstrate success in prior transactions with such 19 properties so as, in one implementation, to help the sales pitch of winning the new business. The interface may also, in one implementation, include "pending activity"
21 and/or "completed activity" tabs to allow a user to view all recorded pending and/or 22 completed activities related to the new business solicitation.

23 [00105] In one implementation, aspects of interfaces such as those shown in Fig.
24 1A and Figs. 2A-B may be time-dependent and/or time sensitive and/or may be shown 1 or hidden or minimized or maximized at different phases of system operation and/or 2 user interaction. Selective display of user interface elements may, in one 3 implementation, facilitate user interaction with and/or understanding of HUB
features 4 and functionality, such as based upon user role, by providing clean and non-cumbersome presentation of HUB UI tools. For example, in one implementation, the 6 left side of the interface, such as that shown in Fig. 1A and Figs. 2A-B, may be made to 7 appear immediately upon engaging the HUB, but may disappear after io seconds (or 8 other designated time period) absent user interaction, click, mouseover, and/or the like.
9 Similarly, in one implementation, UI elements for role and/or current activity io specification may be provided for display immediately, but me made to disappear, such ii as after 11 seconds. The bifurcated display, an example of which is shown at 143 in Fig.
12 LA, as well as associated UI features such as user notes, and/or the like, may, in one 13 implementation, not be displayed at the initial engagement of the HUB, but may be 14 made to appear some time thereafter, such as after 5 seconds. In one implementation, the bifurcated display may never disappear after first appearing. In one 16 implementation, the time machine UI features may appear at the same time as the 17 bifurcated display and disappear some time thereafter, such as after to seconds. In one 18 implementation, a table such as that shown at 187 in Fig. 1A may be made to appear at 19 the same time as the bifurcated display and disappear some time thereafter, such as after 1o seconds. In one implementation, other UI elements, such as the UI
buttons 21 shown at 170 in Fig. 1A, may be displayed or hidden on an as-needed and/or availability 22 basis (e.g., shown when the user's activities have made the use of that button useful or 23 desirable). Other timings and/or combinations, arrangements, orders, and/or the like 24 of showing and hiding UI elements may be employed in alternative implementations. In 1 one implementation, the time periods for display and/or hiding of UI
elements may be 2 specified by a HUB administrator and/or customized by a HUB user. In one 3 implementation, recent user activities and/or historical user activity patterns may 4 influence and/or determine the timing, order, and/or scope of selective display of UI
elements. In one implementation, a user may be permitted to manually open or hide 6 one or more UI elements and/or to turn off the hiding of UI features altogether. In one 7 implementation, mousing over an area of the UI may cause one or more hidden UI
a elements, UI areas, information areas, and/or the like to be displayed for a period of 9 time (e.g., temporarily, until minimized by the user, and/or the like).

[ o o i 0 6 ] FIGURES 2C-D show alternative implementations of HUB user interfaces 11 in embodiments of HUB operation. Fig. 2C shows an alternative implementation of a 12 HUB user interface 272 configured for a landlord broker role in one embodiment of 13 HUB operation. Fig. 2D shows an implementation of a contact information and/or 14 profile page in one embodiment of HUB operation. The page, in one implementation, may include the contact name 274; company and/or contact information 276;
telephone 16 information 278; known or suspected tenant clients associated with the contact 280;
17 address and/or mailing information 282; broker status, type, and/or the like 18 information 284; notes, comments, and/or the like 286; and/or the like. The interface 19 may further include a plurality of tabs, which are selectable to view corresponding information, records, and/or the like. For example, the interface may include a History 21 tab 288, which displays a selectable listing of prior activity information, such as but not 22 limited to: the name of a contact, tenant client, company, and/or the like, who may also 23 have been engaged in the activity (e.g., as a counterparty); a result or status of the 24 activity; a type or label for the activity; a date and/or time of the activity; a summary, 1 comments, notes, and/or the like associated with the activity; and/or the like. In one 2 implementation, selection of an activity from the list at 288 may allow for review of 3 further information associated with the activity and/or may trigger display of an 4 interface such as that shown in Fig. 2C with an auto-populated bifurcated display 5 and/or other interface elements reflecting a state snapshot from the selected activity.
6 Other tabs may, in one implementation, include: a pending tab 290, allowing the 7 viewing of pending activities; tenant representation searches 292, allowing for viewing 8 of information, histories, and/or the like associated with searches performed in a tenant s representation role; landlord representation searches 294, allowing for viewing of 1o information, histories, and/or the like associated with searches performed in a landlord 11 representation role; a potential match tab 296, allowing the viewing of self-identified, 12 system-identified, or user suggested property matches; and/or the like.

13100:107] FIGURE 3A shows an implementation of data flow between and among 14 HUB components in block-diagram form in one embodiment of HUB operation. A
HUB
15 system 301 may include a number of operational modules and/or data stores configured 16 to carry out HUB features and/or functionality. A HUB controller 305 may serve a 17 central role in some embodiments of HUB operation, serving to orchestrate the 18 reception, generation and distribution of data and/or instructions to, from and between 1s HUB modules and/or allow further analysis of data generated during HUB
operation.
20 The HUB controller 305 may be coupled to one or more operational modules configured 21 to implement various features associated with embodiments of HUB operation.
In one 22 implementation, the HUB controller 305 may be coupled to an end 23 user/ communications interface 310 configured to provide HUB UI features and 24 functionality; receive user interactions, query requests and/or parameters, role 1 specifications, and/or the like; transmit query results and/or other requested 2 information; and/or the like. The HUB controller 305 may further be coupled to a 3 third-party resource interface 315 configured to communicate with one or more third-4 party data resources, submit data requests thereto, receive data therefrom, and/or the like. For example, in one implementation, a third-party resource coupled to the HUB
6 system may comprise an external database housing property specifications, such as real 7 estate listings, contact relations information, and/or the like. The HUB
controller 305 8 may further be coupled to an administrator user interface 320 configured to provide an 9 interface through which an administrator can monitor and/or interact with HUB system 1o settings, manage data, and/or the like. For example, in one implementation, a HUB
11 administrator may interact with the HUB system via the administrator user interface to 12 adjust the values of a role-based query matrix which defines how UI element states are 13 input to a query builder for a given role selection, how those states affect a particular 14 query, and/or the like.

[ o o i o 8 ] The HUB controller 305 may further be coupled to a dynamic UI
16 configurer module 325 which may, in one implementation, configure and provide a user 17 interface for property querying. In one implementation, the dynamic UI
configurer may 18 build a user interface based on a user interface profile, such as may be generated or 19 received in response to a role specification by a user, may be configured as an interface template, XML document, and/or the like, and wherein the interface elements provided 21 for display to the user and/or the manner in which queries are constructed from the 22 values thereof may be instructed by the interface profile. In one implementation, the 23 HUB system may, via the dynamic UI configurer, provide a bifurcated interface for 24 display to a user where one half of the bifurcated display is a fixed representation of a 1 query result (e.g., available property attributes) and the other half of the display is 2 receptive to query inputs (e.g., desired property attributes). In one implementation, the 3 dynamic UI configurer may configure the bifurcated display with attention to which side 4 is fixed and which admits inputs depending on the role specified by the user (e.g., when a user is a buyer, tenant, or buyer/tenant broker, fixing the property requirements and 6 configuring the prospective matching properties to receive inputs; and when a user is a 7 seller, landlord, or seller/landlord broker, fixing the property attributes and configuring 8 the property requirements to receive inputs).

o [ 0 010 9 ] The HUB controller 305 may further be coupled to a query builder module 330, configured to draw values from inputs and/or states of user interface elements and 11 generate one or more query statements, such as may be used to query a database of 12 property listings and/or attributes, contact information, and/or the like.

13 [ o o i i o ] The HUB controller 305 may further be coupled to a role manager module 14 335 configured to receive specification of a user role and retrieve one or more role profiles associated therewith. A role profile may, in one implementation, include and/or 16 instruct the retrieval of one or more user interface profiles for provision to the dynamic 17 UI configurer for generation of a user interface appropriate to the selected role. The role 18 manager may also, in one implementation, determine how queries are built from user 19 interface element states and/or values, such as by providing a map of query states and/or values to query statement positions for use by the query builder module 330. In.
21 one implementation, the role manager may further be configured to specify under what 22 circumstances an activity tracker module should initialize an activity timer and/or start 23 a new tracking session. Such specification may be made in the form of a matrix, table, 1 profile, and/or the like specifying relationships between user roles and interface actions 2 that trigger the beginning of a new activity session.

3 [ o 0111] The HUB controller 305 may further be coupled to an activity tracker 4 module 340 configured to record aspects of user interactions and/or activities involving the HUB system via the user interface. In one implementation, the activity tracker may 6 initiate a timer for each new activity and record interface states and values and/or 7 changes thereof over the course of a given recording session. In one implementation, 8 the activity tracker may divide the session time into a plurality of time slices, such as 9 may be of equal size, and record the values and/or states of the complete set of interface 1o elements, and/or of a selected subset thereof, at the conclusion of each time slice. In 11 another implementation, the activity tracker may record changes in selected interface 12 element states and/or values whenever they occur during a given session.
Recorded 13 session information may, in one implementation, be stored by the activity tracker in an 14 activities table of a HUB system database for later searching, retrieval, review, and/or the like.

16 [00112] The HUB controller 305 may further be coupled to a data scraper module 17 342 configured to extract, interpret, and/or reconfigure data received from any of a 18 variety of sources. For example, in one implementation, the HUB may be configured to 19 receive e-mails containing property data, such as data pertaining to attributes of available properties. Property data may be contained in the body of the e-mail, may be 21 embedded in the email, and/or in one or more attachments, such as PDF
files, XML files 22 or other structured documents, MS Word documents or other word processing 23 documents, MS Excel files or other spreadsheet documents, and/or other formatted 1 files. The data scraper may extract property information from the e-mail and/or 2 attachments and populate records of a database therewith. Extracted information may 3 then be retrieved in response to subsequent user queries, to generate reports and/or e-4 blasts for dissemination to users, and/or the like.

100113] The HUB controller 305 may further be coupled to a property marketing 6 tool module 343 configured to process property information and to generate one or 7 more types of marketing materials based thereon, transfer and/or exchange marketing 8 of such materials between interested parties, and/or the like. For example, in one s implementation, the property marketing tool may receive property information directly io from a user and/or a third party data repository, and/or extract property information 11 from a properties database, retrieve a marketing template such as from a marketing 12 templates database, and populate fields of the marketing template with elements of the 13 retrieved property information. The property marketing tool may, in one 14 implementation, be further configured to generate marketing materials such as webpages, PDF documents, flyers and/or other printed documents, cellular phone text 16 and/or email messages, listing service entries, and/or the like. In one implementation, 17 the property marketing tool may further be configured to generate links to generated 18 marketing materials. For example, the property marketing tool may generate a URL or 1s other link to a generated rebpage. In another implementation, the property marketing tool may generate a barcode, QR code, matrix code, and/or the like one dimensional or 21 two dimensional barcode, the scanning of which may cause the automatic linking of a 22 scanning device (e.g., a cellular phone) to a webpage displaying property information, 23 the retrieval of a file containing property information, and/or the like.
In one 24 implementation, the scanning device may be configured to upload and/or download 1 scanned property information. In one implementation, the property marketing tool 2 may employ any of a wide variety of barcode generating tools, such as Zint, Barbecue, 3 Kaywa, and/or the like. In one implementation, the property marketing tool may 4 further allow for e-blasts and/or other distributions of marketing materials, including 5 the selective provision of generated marketing materials to a list of participant e-mails, 6 SMS text addresses, and/or the like. In one implementation, participants may specify 7 what types of materials they are interested in receiving, and the property marketing tool 8 may analyze property information, generated marketing materials, associated metadata, 9 and/or the like to determine if a given marketing material should be provided to a given 1o user or set of users. In one implementation, the property marketing tool may further 11 allow for the automatic population of property information, contact information, 12 scheduled activities, and/or the like based on detected interactions of users with 13 generated links, barcodes, and/or the like.

141001141 In one implementation, HUB components, such as the property marketing 15 tool, data scraper, and/or the like may permit users to enter property and/or contact 16 information associated with scanned barcodes into corresponding HUB
databases. For 17 example, in one implementation, the HUB may allow a user to sync (e.g., one-way or 18 two-way syncing) property and/or contact information downloaded to a mobile device 19 (e.g., cellular phone), obtained by scanning a barcode, with that user's stored property 20 and/or contact information in a HUB account. Syncing may be achieved, for example, 21 by entering an instruction on the mobile device to remotely sync the device with the 22 HUB account via one or more communication networks. Alternatively, a user may be 23 allowed and/or prompted to sync mobile device property and/or contact information 1 with his or her HUB account when the user attaches the mobile device to a HUB
2 terminal computing device.

31001151 In one implementation, scanning barcodes may have different results 4 depending on the character of the barcode and/or associated property and/or contact, depending on the role of the user scanning the barcode, and/or the like. For example, in 6 one implementation, a tenant broker scanning a code at a remote location (e.g., from a 7 billboard, sign placed at the property location, flyer, magazine, website, and/or the like) a may initiate the automatic sending of a message (e.g., via email, text message, instant 9 message, and/or the like) to a property and/or landlord broker to engage in further discussion, request additional property information (e.g., price, extras, square footage ii available, and/or the like), and/or the like. In another example, a landlord broker may 12 scan a property code to automatically sync with a CRM account, capture geographical 13 coordinates of an associated property (e.g., latitude and longitude), such as may be 14 based on data stored in association with the scanned code and/or which may be automatically pulled from a GPS element of the scanning device, leverage coordinates to 16 incorporate the property onto a map within HUB facilities and/or otherwise integrated 17 with the HUB contact relation management elements, and/or the like. In one 18 implementation, the scanning of barcodes associated with properties may effectuate 19 accurate labeling of mapped properties in a HUB equipped mapping system. A
user may scan a barcode associated with a property and obtain geographic coordinates 21 associated with the property, such as from the code itself, a lookup based on the code, 22 integrated GPS components of the scanning device, and/or the like. The property 23 information and geographic coordinates may then be used to specifically and accurately 24 label a building, lot, and/or the like location on a graphically displayed map with 1 property name, type, and/or other property information. Various property information 2 may also be used to allow for filtering of the mapped properties in a variety of ways.

3 [0011611 In one implementation, scanning of a barcode associated with a property 4 may trigger a comparison of property attributes associated with that property with other property attributes associated with the scanning user. For example, in one 6 implementation, a tenant broker scanning a barcode may have property attributes of the 7 property associated with the barcode automatically compared with the tenant broker's 8 site requirements information to determine whether or not a match exists. In another 9 example, a landlord broker scanning a barcode of another landlord broker's property io may have property attributes of that property automatically compared with one or more ii of the scanning landlord broker's existing properties, such as to determine competitive 12 threat or advantage, relative pricing, and/or the like. Scanning a barcode associated 13 with one of the landlord broker's own properties may, in one implementation, provide a 14 comparison of attributes of the property associated with the scanned barcode with other properties managed by the landlord broker. In another implementation, scanning of a 16 barcode by a landlord broker may initiate a query on a database of individual and/or 17 company clients based on property attributes associated with the scanned barcode to 18 quickly identify potential matches for vacant spaces, generate call lists (e.g., exportable 1s to Excel or another spreadsheet program), and/or the like.

1001171 The HUB controller 305 may further be coupled to a HUB database (DB) 21 345 configured to store a variety of data associated with HUB operation in various 22 embodiments. For example, in one implementation, the HUB database may include 23 tables for storing information associated with contacts and/or contact relationship 1 management; properties, property attributes, real estate listings, and/or the like; user 2 activities, activity records, user interface configurations, and/or the like; role profiles, 3 role based user interface configurations, query building instructions, and/or the like;
4 marketing templates, and/or the like. Further detail surrounding such tables is provided below.

6 [o 0118 ] FIGURE 3B shows an implementation of a contact profile or contact data 7 record in one embodiment of HUB operation. A plurality of cards are shown 350, where 8 each card may be associated with a unique contact and/or user identifier (ID). The s example illustrated in Fig. 3B may, in one implementation, be part of a HUB
user 1o interface, such as an address book, rolodex, and/or the like, whereby a user may flip 11 through, select, view, edit, and/or the like information associated with his or her 12 contacts. In an alternative implementation, the information shown in Fig.
3B may be 13 reflective of some of the contents and/or structure of a contact profile and may not be 14 implemented as an actual user interface. The contact information shown in the illustrated implementation may include a picture of the contact 355, one or more 16 barcodes 356 (e.g., such as may be associated with the user, with user properties, 17 activities, and/or the like), as well as contact information 358 such as name, title, 18 contact type, employer, address, phone number, e-mail address, fax number, and/or the 19 like. When implemented as a user interface, the illustrated implementation may also include interface elements such as the buttons shown at 36o to allow for quick actions 21 associated with the contact, such as sending an e-mail message, sending an instant 22 message, syncing the contact information with a mobile device, and/or the like. The 23 profile may further include a collection of associated properties 363, such as properties 24 owned by the contact, properties or property attributes desired by or required by the 1 contact, properties owned by a client of the contact, properties or property attributes 2 desired by or required by a client of the contact, and/or the like. A
variety of property 3 information may be included, such as but not limited to: a property ID, property type, 4 property attributes, pictures, location information, barcodes associated with the property, and/or the like. In one embodiment, the contact profile/contact data record, 6 i.e., contact information, may be implemented as a series of interlinked HUB
database 7 tables, whereby each table is interlinked by way of unique key fields. In one 8 implementation, a user interface button may be provided to allow the user to quickly 9 populate an interface such as that shown in Figs. 1A and 2A-B with selected property io information (e.g., to populate the bifurcated display). The profile may further include a 11 collection of associated activities 365. In one implementation, the activities shown at 12 365 are activities engaged in by the contact, such as with any other user.
In another 13 implementation, the activities shown at 365 are specifically the activities engaged in 14 between the contact and the viewing user whose contact it is. Activity information may include, but is not limited to: an activity ID; a property ID, property attributes, and/or 16 the like associated with the activity; a date and/or time period associated with the 17 activity; one or more roles associated with the activity and/or with the users engaged in 18 the activity, such as a role of each party engaged in a transactional exchange, 19 negotiation, and/or the like; contact IDs of contacts engaged in or otherwise associated with the activity; and/or the like. The profile may further include client information 21 370, reflecting the clients associated with and/or belonging to the contact and/or user.
22 Client information may include, but is not limited to: a client ID; a client name; client 23 contact information, associated properties; a date and/or time period indicative of the 24 amount of time that the client relationship has existed; one or more roles assumed by 1 the client; one or more roles assumed by the user in relation to the client (e.g., tenant 2 broker, landlord broker, and/or the like); and/or the like. It should be noted that the 3 particular example shown in Fig. 3B directed to contact information relevant to a real 4 estate professional is for illustrative purposes only, and other configurations, profile 5 contents, linkages, and/or the like are contemplated as being within the scope of HUB
6 operation in particular embodiments or implementations. For example, in an 7 implementation directed to recruitment, the information at 363 may be representative 8 of skills and/or skill profiles instead of properties.

9 [00119] FIGURE 4 shows an implementation of data flow between and among 1o HUB components and affiliated entities in one embodiment of HUB operation.
The 11 HUB 401 may include one or more HUB servers 405, configured to implement HUB
12 features and/or functionality, and one or more HUB databases 410, configured for 13 storage of HUB data. The HUB 401 may serve to mediate interactions and/or 14 transactions of sellers and/or landlords (LLs) 425 with buyers and/or tenants 435, who 15 may communicate with each other and with the HUB via one or more communication 16 networks 415, which may, in various implementations, include the Internet, intranets, 17 extranets, mobile networks and/or associated mobile databases, and/or the like 18 networks. In addition to or instead of sellers/LLs and/or buyers/tenants, brokers of 19 those parties 420, 430 may interact with each other and/or with HUB
facilities. In some 20 implementations, the HUB may also facilitate communications between a user broker 21 and one or more contra brokers 437 which may, in one implementation, comprise real 22 estate brokers having clients who do not have their own access to HUB data, features, 23 and/or functionality. The HUB may also be communicatively coupled, such as via a 24 communication network 415, with one or more third-party resources 440, such as 1 property information repositories, contact relations management resources, and/or the 2 like.

3[0012o] FIGURE 5A shows an implementation of logic flow for HUB system-user 4 interaction in one embodiment of HUB operation. A user role specification may be received 501, such as via a user interface similar to that shown at Fig. iA
and/or Fig. 2A-6 B. In one implementation, a user role specification may be selected from roles such as a 7 landlord-broker, a tenant-broker, an investment sales buyer, an investment sales seller, a a tenant, a landlord, a buyer, a seller, and/or the like. Subsequent to receipt of a role 9 specification, the HUB may query a UI configuration profile based on the role 1o specification 505 and retrieve a UI configuration profile suited to the role specified by 11 the user. In one implementation, UI configuration profiles may be associated with role 12 specifications in accordance with the table shown, in one implementation, at Fig. 5B. In 13 the illustrated implementation, various HUB UI elements, functionalities, objects, 14 and/or the like 56o may be displayed in correspondence with user specification of particular roles 565 (e.g., landlord broker communicating with tenant broker, landlord 16 broker communicating directly with retailer, landlord broker communicating with 17 existing landlord broker client, and/or the like, such as shown in the examples in Fig.
18 5B). In one implementation, some UI elements may appear universally the same 19 throughout each scenario and/or use mode. The UI profiles shown in Fig. 5B
are for.
illustrative purposes only, and other profiles, including designations of UI
elements in 21 association with user roles, may be used in alternative implementations of the HUB and 22 HUB operation. The HUB may then configure a UI based on the retrieved UI
23 configuration profile 510, such as may include a plurality of user interface elements, 24 fields, inputs, access privileges, query building rules, and/or the like.

1 [00121] Once a UI has been configured and provided for user display, the HUB
2 may monitor and record user activities to generate retrievable and/or searchable 3 records thereof. A determination may be made as to whether a user session, activity 4 recording session, and/or the like has been initiated 515. In one implementation, session initiation may be indicated by user selection of a session initiation UI element.
6 In another implementation, session initiation may be indicated by HUB
detection of the 7 initiation of communication with a contact. If no session is initiated, the HUB may wait 8 for a period of time 520 (which, in one implementation, may depend on user 9 circumstances, role, and/or the like) before checking again for an initiated session 515.
1o When a new session is initiated, a new session timer may be initialized 525, and user 11 activities may be tracked and recorded 530. An implementation of user activity tracking 12 and recording is provided in Fig. 6A. A determination may be made as to whether a 13 given session has been or is to be terminated 535. For example, in one implementation, 14 cessation of a communication with a contact may signal session termination to the HUB.
In another implementation, selection of a session termination UI element by the user 16 may cause the session to terminate. If session termination is not detected or 17 determined, then the HUB may wait 54o and continue to track/record user activities 18 530. Otherwise, a determination may be made as to whether the user has selected a new 19 role 545 and, if so, the system may receive the new role specification and return to 501.
Otherwise, a determination may be made as to whether a new session has been initiated 21 550. If so, a new session timer may be initialized and the system may return to 525.
22 Otherwise, the flow may conclude 555. In one implementation, the selection of a new 23 role, the initiation of a new session, and/or any of a set of designated user interactions 1 with the interface may qualify to terminate a prior session and/or to initiate a new 2 session, timer initialization, and/or the like.

3 [ o 012 2 ] FIGURE 6A shows an implementation of logic flow for query generation 4 and activity recording in one embodiment of HUB operation. In tracking and/or recording user activities and interactions with the HUB UI, the HUB may monitor time 6 601, such as via a system clock. A determination may be.made as to whether any query 7 triggers have been received, for example as a result of user interactions with the UI 605.
8 For example, in one implementation, a role-based query matrix may define which UI
9 element states are inputs to a query builder for a given role selection, how those states 1o affect a particular query, and/or the like. User manipulation of any of these UI elements 11 may then cause a new query to be generated. If no new query parameters are received, 12 the HUB may proceed to check for an activity switch 61o and/or end of interval 655, 13 which is discussed more fully below. If, on the other hand, the HUB
discerns that one or 14 more new query parameters have been received, the HUB may check the query matrix corresponding to the particular role selected by the user 615 to determine, based on the 16 received query trigger(s), which one or more matrix element(s) to use for query 17 construction. Those matrix elements may then be used to determine query parameters 18 620 to be employed in building a new query 625. In one implementation, the query may 19 comprise a SQL statement, with components selected based on the user's UI
interactions, as may be instructed, in one implementation, by the query matrix.

21 [001231 The new query may be submitted, such as to a database management 22 system, to retrieve any matching results 630. For example, in one implementation, the 23 user interface may include interface elements allowing a user to specify attributes of a 1 desired property, and the query may be submitted to a database of property information 2 to seek properties having attributes matching the user specifications. A
determination 3 may be made as to whether any results are retrievable in response to the query 635. If 4 there are no matching results, a blank results area may be provided and/or an error message indicating that no matching results were found 640. On the other hand, if 6 matches are found at 635, they may be provided for display to the user 645, such as in a 7 results listing. In one implementation, results may be sorted prior to display 650, 8 wherein such sorting may be based on any of a variety of different criteria, such as, but 9 not limited to: automatic or user-selected criteria; alphabetical ordering;
relevance;
1o temporal ordering, such as based on a time at which a product listing was added to the 11 database, updated, and/or the like; a reliability, quality, or other rating or ranking of a 12 lister, seller, broker, and/or the like associated with a given product listing; a 13 determined likelihood of interest or opportunity rating associated with the product 14 listing; and/or the like. In one implementation, matching results may be provided for display in a geographic display. For example, in an implementation directed to real 16 estate listings, retrieved matching results may be displayed on a map based on 17 addresses associated with those listings. A HUB system may, for example, employ 18 Google Maps application programming interface tools to provide matching real estate 19 listings for display on an embedded Google Map.

20[00:124] A determination may be made at 61o as to whether an activity switch has 21 occurred. An activity switch may, for example, be detected as a particular interaction or 22 sequence of interactions with a user interface, such as the selection of a particular UI
23 element, submission of a query, selection and/or changing of a user role, and/or the 24 like. In one implementation, UI interactions registering as a qualifying activity switch 1 may depend on a user role and may be specified in a table, matrix, and/or the like 2 relating user roles to qualifying UI interactions. If no activity switch is detected, a 3 determination may be made 655 as to whether the end of an interval has been reached.
4 For example, in one implementation, a snapshot of the current states and/or values 5 associated with UI elements may be taken periodically after each pre-set interval of time 6 has transpired. In an alternative implementation, a snapshot may be taken any time a 7 UI element of a designated set of UI elements has a value changed or state change, any 8 time a user activity type is switched, and/or the like. If the end of interval has been 9 reached at 655 or if an activity switch is detected at 610, screen information and/or 1o associated metadata may be captured 665. The HUB may further reset a current activity 11 timer 612 if an activity switch has been detected. In various implementations, screen 12 information and/or associated data may include, but is not limited to, states and/or 13 values associated with all or selected UI elements, screenshots, recent and/or current 14 queries, retrieved results, prospective property match information, tenant site 15 requirements, proposed properties, qualified properties, presented properties, declined 16 properties, rating indicators, contact information, client information, notes, query 17 results, timestamp, user identifier, and/or the like. One or more of these data may be 18 captured, queried, and/or otherwise retrieved from HUB UI data records, user inputs, 19 third party data sources, and/or the like sources. If the end of interval has not been 20 reached at 655, the HUB may wait for a period of time 66o and continue to monitor 21 time 601.

22 [o 0125] Captured screen information and/or associated metadata may then be 23 stored in association with a timestamp 670. In one implementation, UI
states are stored 24 as activity records in an activity table, wherein each activity record contains and/or is 1 linked to records containing fields specifying quantities, such as the states and/or values 2 associated with UI elements, time and/or date stamps, user identification, counterparty 3 identification, activity type, role, current and/or recent queries, current and/or recent 4 retrieved results, and/or the like. In one implementation, an activity record may take a form similar to the following example XML record:

6 <TimeSlice>
7 <Time>
8 <Date> April 20, 2010 </Date>
9 <Start_time> 12:00:00 </Start_time>
<End_time> 12:00:40 </End_time>
11 </Time>
12 <HUB_Details>
13 <Site_Requirements>
14 <Square_Footage> 1500-2000 </Square_Footage>
<Location>
16 <City> Calumet City </City>
17 <State> IL </State>
18 </Location>
19 <Type> urban commercial </Type>
</Site_Requirements>
21 <Property_Details>
22 <Square_Footage> 1750 </Square_Footage>
23 <Location>
24 <City> Hammond </City>
<State> IL </State>
26 </Location>
27 <Type> suburban commercial </Type>
28 </Property_Details>
29 <Status_Indicators>
<Line_Status_Indicators>
31 <Square_Footage> green </Square_Footage>
32 <Location>
33 <City> yellow </City>
34 <State> green </State>
</Location>
36 <Type> yellow </Type>
37 </Line_Status_Indicators>
38 <Header_Status_Indicators> green 39 </Header_Status _Indicators>
</Status_Indicators>
41 <Contact_Info>
42 <Name> John Smith </Name>

1 <Email> JohnSmith@johnsmith.e-mail.com </Email>
2 <Phone> (555)555-5555 </Phone>
3 </Contact_Info>
4 <Client_Info>
<Name> Jane Brown </Name>
6 <Email> JaneBrown@janebrown.e-mail.com </Email>
7 <Phone> (555)555-4444 </Phone>
8 </Client_Info>
9 </HUB_Details>
</TimeSlice>

12 [00126] Stored activity records may be retrieved at a later time, used to generate 13 reports, and/or the like. For example, in one implementation, a user may load a given 14 activity record to cause an interface, such as that shown in Figs. 1 and 2A-B, to return to the state at which the activity snapshot corresponding to that record was taken. A user.
16 may then be permitted to play and/or step-through subsequent or prior activity 17 snapshots connected in time to the loaded record. In one implementation, activity 18 records may be shared among different HUB users to allow them to see activity 19 snapshots of the user generating the record. For example, in one implementation, employee activity records may be automatically accessible to a manager user, who may 21 sort, filter, search, and/or otherwise inspect employee activity records to find 22 information, review employee performance, and/or the like. In another 23 implementation, a user may generate one or more reports based on stored activity 24 records. For example, a user may generate a report of all activities, deal stages, properties, and/or the like in a given time period; all contacts with which activities have 26 been undertaken in a given time period; all activities for a given deal stage, contact, 27 client, property, and/or the like; and/or any other combination, sorting, filtering, 28 and/or the like of stored activity data. In one implementation, report generation may be 29 automated, such as on a scheduled basis, such that reports may be periodically 1 generated and sent to a user's manager/supervisor, to a transactional counterparty, to a 2 client, to a records-retention department, and/or the like.

3 [00127] FIGURE 6B shows an implementation of activity based HUB UI field 4 resets in one embodiment of HUB operation. The column at 675 shows possible HUB
UI elements and/or other fields, variables, and/or the like which may be reset by a 6 particular user action or activity. A number of activities, in turn, are shown at 680. The 7 table entries, then, indicate which fields 675 may be reset by which activities 68o in one 8 implementation, including some special cases where fields are auto-populated, resets s are role-based, and/or the like.

10[00128] FIGURE 7A shows an implementation of logic flow for lead generation in 11 one embodiment of HUB operation. The HUB may employ a logic flow similar to that 12 shown in Fig. 7A in response to a submitted query to identify and/or provide candidate 13 transactional counterparties who may have information, contacts, and/or the like 14 relevant to a particular set of desired property attributes. The HUB may receive property attribute specifications 701 and build a query based thereon 705. The query 16 may be submitted to a database of consummated transactions to retrieve transactions of 17 properties having attributes sufficiently matching those of the query. In one 18 implementation, a HUB properties table, activities table, and/or the like may include 19 transactional information and may be queried at 710 to retrieve transactions with matching properties. A determination may be made as to whether any such matching 21 transactions are found in response to the query 715. If not, an error handling procedure 22 may be undertaken 720, such as providing a blank set of results for display, providing an 23 error message, requesting relaxation of query parameters and/or property attributes, i and/or the like. In one implementation, query parameters and/or property attributes 2 may be automatically relaxed and the query resubmitted 725 to find approximate 3 matches to the submitted query.

4 [0012.9] If one or more matching transactions are retrieved, they may be counted for each associated entity 730. Entities associated with a given transaction may, for 6 example, comprise a buyer, seller, tenant, landlord, investor, broker, and/or the like.
7 Entities with matching transactions may then be sorted based on the counted number of 8 matching transactions associated with each entity 735, such as in descending order. The 9 sorted list of entities may then be provided for display 740. This may, for example, 1o allow a user to view entities that have completed many transactions of properties similar 11 to that in which a user is interested, thereby potentially providing leads to transactional 12 counterparties for a future property transaction. A determination may be made as to 13 whether a user wishes to refine and/or input different property specifications and, if so, 14 the HUB may return to 701. Otherwise, the flow may conclude 750.

[0 0 13 0 ] FIGURE 7B shows an implementation of logic flow for query construction 16 in one embodiment of HUB operation. A logic flow similar to that shown in the 17 implementation of Fig. 7B may be employed by the HUB in a variety of contexts, such as 18 when a user adopts a landlord broker or other such property provision role, to generate 19 queries of existing property, contact, and/or activity records in real time based on input information. Property attribute values input by a user may be received 752, such as via 21 the bifurcated display at 230 in Fig. 2A. In one implementation, tenant site 22 requirements entered at 235 may be employed for query construction in accordance 23 with the flow shown in Fig. 7B. Received property attribute values may then be used to 1 construct a query (e.g., a SQL query statement) 754. In one implementation, which 2 entered values may be used to construct a query, how the values are organized within 3 the query, whether and how other interface field element values are used in construction 4 of the query, and/or the like may be determined and/or instructed based on certain 5 criteria 756, such as the role that a user has adopted, interface element settings and/or 6 values, and/or the like. The constructed query statement may then be used to query 7 contact records, property records, activity records, and/or the like to find properties 8 matching and/or corresponding to the input property attribute values 758.
Retrieved 9 matching property information may then be used to populate elements of the user 1o interface, such as the table at 255 in Fig. 2A, and/or the like. A
determination may then 11 be made as to whether a selection has been received of a table element populated by 12 retrieved matching property attributes 762. Selection may, in one implementation, 13 comprise a click, mouse-over, and/or the like of a table element by a user.
If selected, 14 the HUB may automatically populate an appropriate side of a bifurcated display, such as 15 that shown at 230 in Fig. 2A, wit the retrieved matching property attributes. If no table 16 element selection is detected at 762, then the HUB may wait for a period of time and 17 recheck for selection and/or may receive entry of grid inputs manually to the bifurcated 18 display 766. In one implementation, tenant site requirements entered at 235 may be 19 employed for query construction and the retrieved matching properties may be 20 incorporated into a map for display to the user. For example, the HUB may query 21 property location information and generate a map display with the properties located 22 thereon based on the queried locations. In one implementation, the map may be 23 populated, in real-time, and be brought to the foreground or background of the user interface and/or be displayed as translucent, semi-transparent, and/or the like to allow 2 for quick review of property locations while continuing with other HUB
activities.

3 100131] FIGURE 8A shows an implementation of logic flow for generating 4 marketing materials and links to those materials in one embodiment of HUB
operation.
A user may engage a HUB property marketing tool 801, such as by selecting a link 6 and/or other associated UI element. A determination may be made as to whether 7 selection of a marketing template is allowed 805. For example, in one implementation, 8 only some users may be authorized to select from a multiplicity of marketing templates.
9 In another implementation, only one template may be available for a given activity, ,o material type, and/or the like. If selection is not allowed, then the HUB
may retrieve the ii sole available marketing template 810, such as from a marketing templates database. If 12 selection is available, then the HUB may provide a selectable list of templates, receive a 13 user selection of a desired template, and retrieve the template 815, such as from a 14 marketing templates database. In one implementation, a marketing template may be configured as an XML file or other structured file specifying a plurality of fields 16 corresponding to various property information (e.g., picture, contact, property type, 17 address, owner info, square footage, price, and/or the like) that may be filled out with 18 specific property information 820. In one implementation, property information may 19 be directly entered by a user, such as via a web interface. In another implementation, a user may select a property information identifier, and the HUB may auto-populate the 21 template with corresponding property information corresponding to the selected 22 identifier. In still another implementation, the HUB may automatically populate a 23 template with property information automatically retrieved from an internal database, 24 retrieved from a third party property data repository, extracted and/or scraped from a 1 website, email, PDF file, and/or the like. A determination may be made as to whether 2 approval is needed for the populated marketing template 825. For example, in one 3 implementation, a manager or other administrator may specify that all marketing 4 materials generated by employees require prior approval. In another implementation, the HUB may be configured to automatically perform a compliance check on all 6 populated templates to ensure that all required fields have been filled, entered 7 information is properly formatted, and/or the like. If approval is needed, the HUB may 8 perform a compliance check, submit the populated template for compliance check, 9 submit the populated template for manager approval, and/or the like 830. A
1o determination may be made as to whether approval has been granted 831 (e.g., if an 11 approval message has been generated and/or received). If not, then an error handling 12 procedure may be undertaken 832, such as requesting modification, additional 13 information and/or clarification for the information populating the template, providing 14 an error message to an originating user, and/or the like. Otherwise, marketing materials may be generated based on the populated template 835. Any of a wide variety 16 of marketing materials may be generated by the HUB in different embodiments of HUB
17 operation. For example, the HUB may generate a webpage, PDF or other formatted 18 document, email message, electronic report, printer flyer, listing service submission, 19 and/or the like. The HUB may further generate and/or provide one or more links to generated marketing materials. For example, the HUB may be configured to generate a 21 barcode, QR code, matrix code, and/or the like one dimensional or two dimensional 22 code 840, the scanning of which may link to a webpage and/or instruct the retrieval of a 23 page, document, and/or the like containing property information associated with the 24 code. It should be understood that the term "barcode" as used herein includes any one 1 dimensional or two dimensional barcode, matrix code, QR code, and/or the like 2 optically machine-readable representation of data. The HUB may also generate and/or 3 retrieve and/or provide a link, URL, and/or the like to a webpage, document, and/or the 4 like containing and/or comprising the generated marketing materials 845. In still another implementation, the HUB may generate an email message and/or e-blast 6 message comprising a message sent to a plurality of users, such as may be based on 7 user-specified preferences and/or provision criteria in comparison with marketing 8 material characteristics, metadata, and/or the like 850.

91001321 FIGURE 8B shows an implementation of logic flow for user engagement of io marketing material links in one embodiment of HUB operation. A wide variety of ii different results may be connected to user engagement of marketing material links, and 12 in particular with scanning of HUB generated barcodes, in different embodiments of 13 HUB operation. Fig. 8B shows several possible implementations for illustrative 14 purposes, but it is to be understood that other possibilities are contemplated as being within the scope of HUB embodiments. A user may scan a barcode 855, such as by 16 using a cellular telephone camera or other scanning device. In one implementation, the 17 user may then be provided with a selectable list of options as to which action he or she 18 would like to take 860. In one implementation, the user may be provided with property 19 information media, such as a PDF file or other document, email message, image files, video, and/or the like 865. In another implementation, the user may be provided with a 21 link to a webpage and/or may automatically be connected to the webpage containing 22 property information 870. In one implementation, the webpage may be a listing service 23 listing. In another implementation, the user may be redirected to a listing service 24 application. In one implementation, the user's HUB account may be auto-populated 1 with contact information, property information, and/or the like associated with the 2 scanned barcode, and/or the user may automatically "friend" the associated contact in a 3 social network context. In yet another implementation, property information may be 4 downloaded to a mobile device upon scanning of a barcode, and the mobile device information may then be synced with a user's HUB account at a later time, such as by 6 interfacing the mobile device with a HUB account resource. In one implementation, the 7 HUB may send a message containing user information to the contact associated with the 8 barcode, schedule a call or other activity, and/or the like 88o.

s 100133] FIGURE 9 shows an implementation of user interface for accessing HUB
1o community features in one embodiment of HUB operation. A HUB page may include a 11 window gol for accessing HUB community features and/or otherwise engaging certain 12 HUB features centered around interactions with other HUB users. For example, in one 13 implementation, the community features may include an internal and/or external (e.g., 14 such as may depend on user preference settings) contact exchange feature 903, allowing users to trade, buy, sell, and/or otherwise transact contact information, leads, and/or 16 the like. In one implementation, community features may further include a marketing 17 ideas feature 905, allowing users to confer, exchange marketing ideas, leads, and/or the 18 like. In one implementation, community features may further include site drives 910, 19 allowing users to review relevant locations proximate to a given property which may act as site drives.

21 100134] FIGURE 1o shows an implementation of logic flow for effectuating lead 22 transactions in one embodiment of HUB operation. A lead request and/or lead request 23 parameters may be received 1001. For example, in one implementation, a lead request 1 may comprise a company name, such as may correspond to a company which a HUB
2 user may want to introduce a given property for a possible transaction, lead, and/or the 3 like. In various implementations, other lead request parameters may be provided, such 4 as but not limited to: a contact name, a contact address, property parameters, company 5 type, company attributes, and/or the like. In one implementation, the user may also 6 submit a bid as part of the lead request parameters, wherein the bid is indicative of a 7 total amount, base amount, estimate, and/or the like of money, tokens, and/or the like 8 that the user is willing to pay in exchange for the receiving the lead information. The 9 HUB may then access leads matching the received request parameters 1005. For io example, the HUB may perform a query of contact information, property information, 11 activity information, and/or the like for all other users, a subset of users, only users who 12 are contacts of the requesting user, and/or the like to determine which if any of the 13 users may have one or more contacts matching the lead request parameters.
In one 14 implementation, prior to accessing matching leads, the HUB may perform a check of 15 user authorization for lead request services. For example, requester authorization 16 information may be checked 1olo and a determination made as to whether the user is 17 authorized 1015 (e.g., whether the user has subscribed to lead request services, whether 18 any holds exist on such services for a user account, and/or the like). If authorized, leads 19 may be accessed 1005. Otherwise, the HUB may, in some instances, offer a user the 20 opportunity to upgrade his or her account to acquire the lead request services 1020. A
21 determination may be made as to whether that offer has been accepted 1025 and, if so, 22 leads may be accessed 1005. If not accepted, an error handling procedure may be 23 undertaken 1030, such as may include the display of a message to the user that lead 24 request services are not available.

11001351 Once leads matching the input request parameters have been accessed, 2 they may be provided for display to the requester 1035. In one implementation, 3 matching leads are displayed as a selectable list showing information of the contact 4 and/or user holding the lead, but not information about the lead itself. A
user may then select a contact and/or user from the listing 1045 in order to retrieve lead information.
s In one implementation, prior to providing a list of matching leads for display, the HUB
7 may sort matching leads based on some criteria 1040. For example, in one 8 implementation, leads may be sorted based on the quality rating of the contact 9 providing the lead (discussed in further detail below). In another implementation, a ,o user may specify criteria for sorting, selection of a subset, and/or the like manipulation ii of the list of leads. Thus, for example, a user may sort results alphabetically based on 12 contact name, may select only those leads corresponding to a desired geographic area, 13 and/or the like. In still another implementation, potential lead providers may pay a fee 14 for prioritized and/or advantaged placement in a list of matching leads. In various implementations, such a prioritized placement fee may be fixed, may depend on the 16 quality ratings of lead providers in the listing, may depend on the lead provider's own 17 quality rating, and/or the like. Lead selection may be received 1045, such as by a user 18 selecting an element of the matching leads list with a mouse click, and a determination 19 of the lead provision fee may be made, such as maybe based on a provider quality rating associated with the selected lead provider 1050. In one implementation, the lead 21 provision fee may be equal to the bid amount input by the user at 1001. In another 22 implementation, the lead provision fee may be based on the bid amount input by the 23 user at 1001 and on one or more other factors. For example, an amount may be added 24 to and/or subtracted from the bid to yield the lead provision fee based on the quality 1 rating of the lead provider (e.g., adding a premium for very high quality ratings, adding 2 nothing or subtracting something for very low rated lead providers, and/or the like). In 3 one implementation, an amount may only be added to the bid made by the user to 4 determine the lead provision fee, whereby the bid is indicative of an amount the user is willing to pay regardless of the quality of the lead or lead provider. In one 6 implementation, the lead provision fee may further be based on an amount specified by 7 the lead provider, such as a minimum amount required before the lead will be shared.

8 100136] In one implementation, the user may be provided with a request to pay the 9 lead provision fee 1055, and a determination may be made as to whether or not the io payment of that fee has been agreed to 1060. In an alternative implementation, the fee 11 would be displayed to and/or otherwise known by the user prior to selection of a lead 12 provider, and selection would automatically trigger the debiting of a payment account 13 associated with the user, the generation of a bill, or other payment mechanism.
14 Payment is received from the user 1065, such as by entry of credit card information, automatic debiting of a user account, receipt of a signed promise to pay, and/or the like, 16 and the HUB proceeds to provide the hidden lead information to the requester 1070 and 17 to provide payment and/or an indication of payment to the lead provider 1075, such as 18 via crediting of a lead provider account,. sending of a message to the lead provider, i and/or the like. Subsequent to receipt of the lead, the lead requester may be provided the opportunity to rate the quality of the lead received 1080, such as may be based on 21 the reliability of the lead information, the friendliness and/or helpfulness of the lead 22 and/or lead provider, and/or the like. In one implementation, a user who has received 23 the lead may submit one rating for that lead at any time in the future. In another 24 implementation, the user may submit one rating, but only for a specific time period 1 following receipt of the lead. In still another implementation, the user may submit a 2 rating and subsequently change that rating. The HUB may then update the quality 3 rating of the lead provider based on the lead quality score received from the user 1085, 4 and the updated lead provider score may then be provided for display to future lead requesters in determining whether or not to pursue a lead with that provider.

6 100137] FIGURES 11A-D show an implementation of user interface for contact 7 exchange in one embodiment of HUB operation. In Fig. 11A, a window is presented to 8 the user 1101 to allow him or her to submit lead request parameters (in the illustrated 9 implementation, a company name has been entered). A user seeking to acquire a 1o particular lead, contact, and/or the like may experience a particularly acute and/or 11 urgent need in light of commercial and competitive pressures. The HUB may facilitate 12 alleviation of that need via an economical interface such as that shown in Fig. 11A, 13 asking the user only to specify basic information to assist the HUB in identifying 14 possible sources of the requested information. A list of possible leads and/or lead providers may then be provided, such as that shown in Fig. 11B. The list in the 1s illustrated implementation includes the name of the contact (who is the lead provider) 17 1105, the contact's title 1110, the contact's territory 1115, the name of the contact (who is 18 a seller in this case) 1120, a quality rating associated with the contact, and a lead 19 provision fee 1130 (configured here as a number of tokens required to acquire the lead information). The list in the illustrated implementation also may include selectable 21 interface elements 1135 by which the user may manifest his or her selection of an 22 element of the list.

11001381 The list may also be sorted based on any of the list information categories.
2 For example, Fig. 11C illustrates one implementation where a user has selected the 3 contact territory category, and is provided with a dialog box 1140 by which the user may 4 select a contact territory filter in order to narrow down the returned results. The resulting filtered list 1145 is displayed, in one implementation, in Fig. 11D.

6 100139] FIGURES 12A-C show an implementation of user interface for marketing 7 idea exchanging in one embodiment of HUB operation. A user may seek assistance with s leads, marketing ideas, and/or the like by selection of an associated user interface 9 element such as the marketing ideas button at 905 in Fig. 9. A user may then be 1o presented with a dialog box 1201 admitting entry of a message requesting assistance 11 from other users. In various implementations, the message may be provided for display 12 to all HUB users, HUB users who have acknowledged willingness to receive marketing 13 idea requests, HUB users who are contacts of the requesting user, and/or the like. In 14 response to a submitted message, the requesting user may be presented with a listing of ideas, advice, leads, and/or the like, similar to that shown at 1205 in the example in Fig.
16 12B. In one implementation, mousing over an element of the list at 1205 may cause the 17 generation of a pop-up window 1210 providing further information about the advice, 18 lead, ideas, and/or the like associated with that element. The interface may further 19 include interface components 1215 configured to allow a user to manifest selection of an element of the listing. Selection of an element may result in the display of a screen 21 similar to that shown in the example of Fig. 12C, wherein the message 1220 of a 22 responding user is displayed in full. The interface may also include a component 1225 23 allowing the user to manifest a desire to reply to the message.

1 [0 014 0 ] FIGURES 13A-E show an implementation of user interface for site drive 2 information acquisition in one embodiment of HUB operation. The HUB may allow for 3 leveraging of the power of an industry community to share information in such a 4 manner as to assist one user or group of users in taking advantage of and/or improving 5 the experience of another in various areas of community knowledge, such as marketing, 6 lead generation, contacts, and/or the like. The HUB may, in one implementation, 7 leverage such data generated by community interaction to increase the effectiveness of 8 HUB profiles, real-time population of properties, and/or the like and/or use of historical 9 accuracy of a HUB ranking and/or rating system to provide potential and/or valuable io marketing ideas. A user may request site drive locations and/or information in ii association with a given property, such as one of their own properties, a client property, 12 a desired property, and/or the like, such as by selecting an associated user interface 13 element like that shown at 91o in Fig. 9. The address of the property for which the site 14 drive information has been requested may be displayed 1301, and a map provided 1305 15 indicating the location of the reference property 1306 and of the associated and/or 16 nearby site drives 1307, such as may be present within a specified distance of the 17 reference property. A user may select, mouse-over, and/or otherwise choose a site drive 18 and be shown a pop-up window 1310 of information associated with the selected site 19 drive, such as the name of an associated broker, a rating associated with the broker, a 20 center of the site drive, a radius, and/or the like. The pop-up window may also include a 21 button or other UI element allowing the user to acquire complete information about the 22 site drive. Selection of that element may cause the display of a screen similar to that 23 shown in the example of Fig. 13C, wherein additional site drive information is provided 24 1315, and including selectable listings of retailers 1320 and/or shopping centers 1325 i associated with the site drive. Selection of a shopping center allows for the user to view 2 names of retailers 1330 associated with the selected shopping center, such as by the 3 listing of retailers shown at 1335. The HUB may also, in one implementation, allow a 4 user to view missing retailers 1340 associated with a shopping center, such as by identifying retailers by name, retail category, and/or the like who are not located in the 6 shopping center but are, for example, a qualified distance away from it to be included in 7 a list 1345 for display to the user. Although the description of the site drive facilities s referencing Figs. 13A-E is primarily directed to real property transactions, it should be 9 understood that these facilities are adaptable to a wide variety of other applications 1o within different embodiments or implementations of the HUB. For example, in an 11 implementation directed to recruitment, the HUB may provide information analogous 12 to site drives, such as may include a graphical representation analogous to a map, 13 showing candidates for a position and their various skill-set positions relative to one 14 another.

100141] FIGURES 14A-E show an implementation of user interface for activity 16 diagnostics and reporting in one embodiment of HUB operation. As noted above, the 17 HUB may include a variety of facilities to allow for the evaluation, analysis, and 18 reporting of user activities and/or relationships. In the illustrated implementation, a 19 variety of charts, graphs, and/or other modes of display are provided as part of a dashboard interface to allow quick evaluation of user activities. For example, the 21 illustrated implementation includes a pie chart showing a breakdown of overall user 22 activities 1401. The illustrated implementation also includes a three dimensional bar 23 graph displaying information related to client meetings 1405, and a two dimensional bar 24 graph displaying information related to sales 1410. In one implementation, a user may 1 customize the displayed information and/or modes of display in the dashboard interface 2 to suit his or her specific needs and/or requirements. For example, a user may select 3 data categories to include in a graph as well as the type of graph, position on the screen, 4 display size, display colors, labels, scales, and/or the like. In one implementation, the dashboard components and/or the facilities to allow for user customization may be 6 implemented by means of multimedia platform tools such as those of Adobe Flash. In 7 one implementation, a user may click on, mouse over, and/or otherwise select a 8 component of a displayed graph, chart, and/or the like to receive additional 9 information. For example, in Fig. 14B, mousing over the pie chart wedge at 1415 yields io display of the associated label at 1420. The user may then click the wedge at 1415 to be ii provided with more granular data about that category of landlord representation. For 12 example, in one implementation, the user may be provided with a display similar to that 13 shown in the example of Fig. 14C, where the pie chart 1425 now represents information 14 associated with the selected wedge 1415. Additional information associated with the properties and/or clients displayed at 1425 may be provided in an associated table 1430, 16 such as a listing of potential tenants who may be interested in the properties for which 17 the user is the landlord broker. The user may, in one implementation, be allowed to 18 again select a wedge of the pie chart (as shown at 1435 in Fig. 14D) to receive still more 19 detailed information about the client, relationship, one or more properties, and/or the like associated with the selected wedge. An example of such information is shown in 21 Fig. 14E, wherein a summary of the representation for a particular landlord client 1440 22 is shown, including property attributes 1445, contact information 1450, and/or the like.
23 The interface may also include tabbed areas 1455 allowing the user to view pending 24 and/or future scheduled activities with this client; historical records of activities i associated with this client; potential matching contacts, tenants, clients, and/or other 2 parties who may be interested in this client's property (e.g., such as may be discerned 3 based on historical activities, inquiries from tenant brokers, queries built based on the 4 property attributes at 1445, and/or the like); information pertaining to contacts associated with the client (e.g., other brokers spoken to about the client's properties);
6 and/or the like.

7100142] FIGURE 15 shows an implementation of logic flow for geocode acquisition 8 in one embodiment of HUB operation. Geocodes may be obtained in relation to stored 9 information received from mobile phones or other mobile devices, associated with 1o barcodes, scraped and/or otherwise extracted from online sources (e.g., websites, URLs, 11 and/or the like) and/or scanned documents, stored within HUB databases, and/or the 12 like, such as properties, contacts, appointments, and/or the like. In one 13 implementation, the HUB may obtain geocodes in a batch process for multiple locations 14 at a time, while in an alternative implementation, a geocode may be obtained for newly added location data at the time it is added to a HUB database. In the implementation 16 illustrated in Fig. 15, new location data is received 1501 (e.g., from a HUB interface, such 17 as entries to a HUB bifurcated display; from a barcode, matrix code, and/or the like 18 scanned by a mobile device, and/or information queried from a database based on 19 scanning one or more such codes; retrieved by scraping and/or otherwise extracting location information from a website, electronic document, scanned brochure, and/or the 21 like; and/or the like). In various implementations, location data may take any of a 22 variety of forms, such as but not limited to: postal address information, latitude and 23 longitude coordinates, GPS coordinates, and/or any other location identifying 24 information. A determination is made as to whether a record exists in one or more HUB

1 databases representing the received location 1505. Such a determination may be made, 2 for example, by comparing location identifying information to corresponding record 3 information. If a record does not exist, a new location record may be created 1510 for 4 the data being received. If a matching record does exist, a determination may be made as to whether a geocode already exists in the record. If so, then whatever new data has 6 been received, if any, may be used to append, edit, update, and/or otherwise modify the 7 existing data record 1520. If no geocode exists in the record, or if a new record was 8 created to accommodate the new data, then a determination may be made as to whether 9 address data exists in the newly received data 1525. Address data may comprise a street to address, cross-street, telephone number, building name, location description, and/or 11 any information sufficient to discern a specific location associated with the data. If no 12 address data exists, then an error handling procedure may be undertaken, such as 13 requesting entry of the address data, storing the record with a flag to identify it as 14 lacking address data and/or to re-request address data at a future time, deleting the record, and/or the like 1530. In one implementation, information scraped or otherwise 16 extracted from one or more listing services, scanned documents, and/or the like may be 17 queried to attempt to find address data corresponding to the received location data. If 1s address data does exist at1525, that address data may be provided for geocode 1s generation 1535. In one implementation, address data may be provided to a one or more tools in a Google Maps JavaScript API toolkit, Bing Maps API toolkit, Yahoo Maps 21 Developers API toolkit, and/or the like in order to retrieve corresponding geocodes. A
22 determination may be made as to whether geocodes are available 1540. If not, an error 23 handling procedure may be undertaken 1545, such as to leave a data record's geocode 24 field blank, schedule a future attempt to convert the address information to geocode 1 information, request additional address information input, and/or the like.
If the 2 geocode information is available, it may be retrieved 155o and stored in association with 3 the location record 1555 for later access, retrieval and/or use.

4 100143] FIGURE 16A shows an implementation of logic flow for mapping HUB
5 data in one embodiment of HUB operation. A mapping instruction may be received 6 1601, such as a result of a user action, selection of a HUB interface element (e.g., 7 elements 12o and/or 188 of Fig. 1A), a map generation subroutine of an automatic HUB
8 system process, and/or the like. In one implementation, a mapping instruction may 9 include specification of a set and/or subset of mappable data to be included in a map.
io For example, a user may highlight and/or otherwise select client target locations in ii nested folders, such as from a portion of the HUB interface like those shown at 125 and 12 130 in Fig. 1 or 210 in Fig. 2A, and instruct the HUB to map those selected locations. A
13 determination may then be made as to whether map data parameters are discernible in 14 association with the received mapping instruction. For example, such a determination 15 made in response to selection of a "Map It" button like that shown at 188 of Fig. 1A may 16 be based on an inspection of whether or not the table at 187 is populated with location 17 information or sufficient location identifying information to allow for the further 18 acquisition of map data parameters. Examples of map data parameters may include, 19 but are not limited to: addresses, building names, cross streets, zip codes, city names, 20 property owner identifiers, identifiers of contacts having associated properties, property 21 broker identifiers, and/or the like. If map data parameters are not discernible, the HUB
22 may request and receive input of map data parameters sufficient to produce a map 161o.
23 In an alternative implementation, an error handling procedure may be undertaken, such 24 as providing an error message to the user, producing a blank or default map, and/or the 1 like 1615. If sufficient information is received to allow for discernment of map data 2 parameters, the HUB may use received map data parameters to query location data 3 records 1620 in order to retrieve geocode information associated with the map data 4 parameters 1625. A determination may then be made as to whether the map data corresponding to the geocodes and/or map data parameters is subject to 6 subcategorization. Such a determination may be made, for example, based on 7 subcategory identifiers or other categorizable information contained in and/or 8 connected to location data records queried at 1620. Examples of map data 9 subcategorization may include identifying properties as qualified properties; proposed 1o properties; presented properties; declined properties; tenant client target properties;
11 tenant client existing properties; landlord client properties; market comparables; site 12 drives; contact-associated properties; and/or the like. In one implementation, the 13 determination of whether map data is subject to subcategorization may further be based 14 on a user designation (e.g., of user hat and/or role) or interface element selection, such as the selection of a checkbox indicating a desire to group mapped properties by 16 subcategories or related attributes. If map data is subject to subcategorization, 17 appropriate subcategories may be assigned to the map data and a map key may be 18 configured based on that subcategorization, such map data within a particular 19 subcategory will appear as having a unique icon or other identifier on a generated map 1635. The map may then be generated with the map data, in accordance with any 21 applied subcategorization 1640. If a map has already been generated and the new map 22 data is to be appended thereto, the new map data may be added to the existing map at 23 1640. A determination may then be made as to whether additional map data is to be 24 mapped 1645, such as based on a user inquiry. If so, a new map data group may be 1 created, corresponding to the map data to be added to the existing map, and the map 2 key may be configured accordingly 1650, and the HUB may return to 1605.
Otherwise, 3 map generation may be done 1655.

4 100144] FIGURE 16B shows an implementation of logic flow for intelligent mapping in one embodiment of HUB operation. A flow similar to that shown in the 6 example of Fig. 16B may be implemented in order to auto-populate a generated map 7 with property and/or other location geospatial information that is determined to be of 8 possible contextual relevance for a user and/or a user's client. For example, the HUB
9 may receive a client identifier 1657, such as the name and/or other identity information io associated with a client with which a broker or other user is currently engaged in 11 communication. A mapping instruction may also be received 1659, such as a result of a 12 user action, selection of a HUB interface element, a map generation subroutine of an 13 automatic HUB system process, and/or the like. The HUB may then retrieve client 14 target parameter(s), such as client target property requirements and/or characteristics, target tenant requirements and/or characteristics, and/or the like 1662.
Target 16 parameters may, in some implementations, be derived from entries into a bifurcated 17 display portion of a HUB interface (e.g., from entries into area 155 of Fig. 1), from a user 18 and/or client profile and/or data record, and/or the like. In one implementation, the 1s HUB may further discern one or more current client goal(s) 166o, such as a goal to rent, buy, sell, view as an open house, and/or the like. Such goals may be discerned, for 21 example, from a user entry, from contextual cues detected from user interactions with a 22 HUB interface during a communication session with the client, and/or the like. In one 23 implementation, discerned client goals may affect retrieval of target parameters (e.g., 24 only a client's target property characteristics corresponding to rental targets may be i retrieved if the client's current goal is determined to be associated with renting). Based 2 on the retrieved target parameters, and in one implementation on the current client 3 goals, the HUB may query property listings 1664. In some implementations, property 4 listings queried at 1664 may include a user's properties, a user's company's properties, properties gleaned from a third party source and/or stored in a third party database, 6 properties scraped and/or otherwise extracted from analyzed websites, scanned and/or 7 digital documents, flyers, and/or the like. A determination may be made as to whether 8 any listings exist matching the parameters of the query and, if not, then an error 9 handling procedure may be undertaken, such as to provide a default, empty, and/or 1o unpopulated map for display 1668. Otherwise, if one or more matches are found, a 11 determination may be made as to whether the matching map data is subject to sub-12 categorization 1670 (e.g., if there exist one or more common characteristics across the 13 matching data based on which the data may be grouped into subcategories).
If so, then 14 subcategories may be assigned to the map data and a map key may be configured based on those assignments and/or sub-categorizations 1672. Geocode data may be extracted 16 from data records, barcodes, digital files, and/or the like associated with the map data 17 1674 and one or more maps may be generated, displaying and/or adding the map data, 18 based on the retrieved geocode information 1676.

19 100145] FIGURE 17 shows an implementation of logic flow for map generation in one embodiment of HUB operation. In one implementation, the logic flow shown in 21 Fig. 17 may be implemented at 1640 in Fig. 16A. A determination may be made as to 22 whether there exist multiple layers and/or subcategories of map data for presentation 23 1701. Such a determination may be made, for example, based on inspection of layer 24 descriptors, subcategory identifiers, and/or the like associated with location records to 1 be mapped. If multiple layers and/or subcategories of map data exist, the HUB may set 2 an initial and/or default set of layers for display, such as may be based on a user role, 3 user preference setting, and/or the like 1705. A determination may then be made as to 4 whether layer selection changes are desired or received from the user 1710.
For example, in one implementation, a user may change layer display settings by clicking on 6 one or more interface elements to register a selection and/or deselection of one or more 7 layers. If layer selections are detected, the HUB may set selected layers to show in a 8 generated map 1712, such as by designating selected layers as displayable in a location 9 data record. Once layers are set, or if there are no multiple layers, the HUB may to determine if one or more map engine selections are desired 1715. For example, a HUB
ii user may be provided with the option of selecting one or more map engines for 12 presentation of map data, such as but not limited to: Google Maps, Yahoo Maps, 13 Mapquest, Bing Maps, and/or the like. In one implementation, such a determination 14 may be made based on the availability of map engine selection options to a HUB user, the accessibility of map engine tools, the nature of mapped data, selected map settings, 16 and/or the like. In one implementation, the HUB may automatically determine, apply 17 and/or recommend a preferred map engine, such as may be based on characteristics of a 18 user, map data, interface context, and/or the like. For example, if the HUB
detects that 19 a user is engaged in a discussion with a commercial real estate tenant client interested in leasing retail store space, the HUB may default to a street-view presentation (e.g., 21 Google Maps street-view, Microsoft Street Slide view, and/or the like). The HUB may 22 include and access data records storing associations between client goals and/or other 23 interface contextual cues and map engines or other selected display features in order to 24 provide such contextually relevant recommendations and/or default presentations of 1 map data. If map engine selection is available and/or detected, map engine selections 2 may be received 1720 and, if not, then a default map engine may be selected 1725. Map 3 engines may be used in conjunction with one another such that a user can choose to flip 4 back, forth and/or between maps generated by different engines, and/or display maps 5 side-by-side such as to have both views available. In one implementation, a user may 6 readily copy, e-mail, save and/or export maps internally within a HUB system and/or 7 with external parties for on-the-fly discussion and analysis. Selected layer data may 8 then be provided to tools associated with one or more selected map engines for map 9 generation 1730, and generated map information, such as a graphical map display, may 1o be retrieved and provided for display 1735. A determination may then be made as to 11 whether any layer selection changes are desired or have been received 1740 and, if so, 12 the Hub may return to 1712. Otherwise, a determination may be made as to whether any 13 map engine changes are desired or have been received 1745 and, if so, the HUB may 14 return to 1720. Otherwise, the map generation subroutine shown in Fig. 17 may 15 conclude and/or exit.

161001461 FIGURE 18 shows an implementation of a HUB map user interface in one 17 embodiment of HUB operation. A map, such as that shown in the example of Fig. 18, 18 may allow a user to map a variety of different geospatial and/or spatiotemporal 19 information. In one implementation, a map such as that shown in Fig. 18 may be used 20 to map property information populating another HUB interface, such as a bifurcated 21 display area similar to that shown in the example at 143 of Fig. 1. In such an 22 implementation, entry of new information in another part of the HUB
interface, such as 23 a bifurcated display portion, may cause an automatic and/or dynamic updating of 24 displayed information in a HUB map interface such as that shown in Fig. 18.
A map 1 area 1801 shows a mapped region, which may be adjusted in position, zoom or scale, 2 view, and/or the like, such as by using the map tools shown at 1803. In addition to 3 general geographic information associated with the mapped area, such as street names, 4 landmarks, and/or the like, the map also includes mapped location data, indicated by icons such as those at 1805. The interface further includes a control panel 181o with a 6 variety of interface elements allowing for modification and/or customization of the 7 displayed map area and/or map data. It should be understood that the interface 8 elements shown in Fig. 18 are for illustrative purposes only, and any variety, 9 combination, subset, and/or the like of the displayed interface elements, as well as other 1o elements with related and/or complementary functionality, may be employed within 11 different implementations of the HUB and HUB user interfaces. A key 1815 shows 12 identifying information for displayed map data, such as may correspond to map layers, 13 subcategories, and/or the like. As in the displayed implementation, the key may include 14 checkboxes or other interface facilities allowing a user to select or deselect displayed map data, layers, subcategories and/or the like. The panel may further include a map 16 opacity slider element 1820, allowing a user to adjust the transparency and/or opacity of 17 the displayed map area 1801 from a low level (e.g., completely transparent) to a high 18 level (e.g., completely opaque). The panel may further include a view radius dial 1825, 19 allowing a user to adjust the a radius, scale, zoom, and/or the like associated with the displayed map area 1801. In one implementation, a point at the center of the displayed 21 map area 1801 (e.g., the point from which the radius, controlled by the element at 1825, 22 may be drawn) may be a nearest intersection, or other point of interest, in proximity to 23 and/or otherwise associated with one or more mapped properties. The panel may 24 further include an "Import data" button 1830, selection of which may generate a dialog 1 box by which a user may specify one or more filenames corresponding to files, such as 2 text files, PDF documents, word processing documents, spreadsheet documents, XML
3 files or other structured documents, and/or the like which may contain map data. In 4 one implementation, an "Import data" button such as that shown at 1830 may allow a user to provide location information from and/or associated with a scanned barcode, 6 matrix code, and/or the like. For.example, in one implementation, selection of an 7 import data button may cause a number to be displayed to a user, to which the user may 8 submit an MMS message containing an image of a code captured by a mobile device 9 camera, which may then be decoded at a remote server in order to extract and/or io retrieve associated location information. In another implementation, an import data 11 button may allow a user to automatically transfer a captured code image (and, in some 12 implementations, images within that image, e.g., retailer logos, street logos, 13 demographic data logos, and/or the like) to a computing terminal, which may then be 14 decoded thereon and/or passed over a communication network to a remote server for conversion to location information. In one implementation, a scanned barcode, matrix 16 code, and/or the like may itself contain geospatial information and/or may allow a user 17 to connect to a source of associated geospatial information. In another implementation, 18 a barcode may have property identifying information (e.g., the name of a building, 19 associated contact information, and/or the like), and a mobile device application may automatically capture geospatial information from a device sensor (e.g., a GPS
unit) at 21 the time the code is captured, and associate the position information with the captured 22 code. Imported data, once successfully loaded, may automatically appear as icons in the 23 map area. In one implementation, imported map data may be designated as a unique 24 layer, subcategory, and/or the like. The panel may further include a "Show nearest 1 intersection" button 1835, selection of which may show information related to a nearest 2 intersection (e.g., names of crossing streets) for one or more displayed locations, such as 3 for one or more of the icons 1805 signifying map data locations. In one implementation, 4 selection of the button at 1835 may generate a special pointer that, when used to click on a mapped icon, may generate and display the nearest intersection information for that 6 icon. The panel may further include a variety of sliders 1840 for filtering displayed map 7 data based on a variety of criteria. For example, the displayed implementation includes 8 a "gut feel" slider, whereby a user may set a value, upper value, lower value, range, 9 and/or the like for the gut feel indicator associated with one or more properties to filter 1o displayed properties to only those having gut feel values satisfying the specified values 11 and/or criteria. Another example of a filtering slider shown at 1840 is a time slider, 12 which may allow a user to specify one or more times and/or a range of times by which to 13 filter displayed properties. Times set by the slider may, for example, correspond to the 14 time a property has been listed for sale or rent, the last time a status change occurred for the property, the first and/or last time a HUB user communicated with a contact about a 16 property, and/or the like. In one implementation, a time slider may be manipulated to 17 cause displayed properties to evolve in time, such as to reveal status changes associated 18 with the properties (e.g., for sale, shown to prospective buyers, in contract, sale closed, 19 and/or the like). In one implementation, maps at different stages of a time evolution may be un-done and/or re-done, saved, exported, and/or the like. In one 21 implementation, a time slider may update mapped data and/or map data statuses 22 and/or other associated information based on the historical records of HUB
activity at 23 various times associated with the mapped properties. Another example of a possible 24 filtering slider shown at 1840 is a price slider, which may allow a user to set a price 1 value, minimum, maximum, range, and/or the like by which to filter displayed 2 properties according to their sale prices, asking prices, bid prices, rent levels, geographic 3 price averages, historical price values, and/or the like. A wide variety of other filter 4 sliders may be employed in other implementations of the HUB and HUB user interfaces (e.g., displayed filter sliders may be selected based on a user role, user preference 6 settings, and/or the like). The panel may further include a field for specifying a mapped 7 region 1850, into which a user may enter information based on which a map area 1801 a may be modified, such as an address or collection of addresses, city name, building a name, zip code, state name, area code, intersection, retailer/restaurant name, contact 1o name, and/or the like. The panel may further include a plurality of buttons allowing a ii user to vary a view and/or type of view in a map area 1801. For example, buttons may 12 exist to allow a user to vary a map view to a map setting (e.g., schematic display of 13. labeled streets, landmarks, parks, buildings, waterways, and/or the like);
a traffic setting 14 (e.g., showing traffic flows, densities, and/or the like, such as may be accessed from a traffic alert data source); a satellite setting, showing satellite photography images, 16 "bird's eye" images, and/or the like associated with the map area; a street setting, 17 showing street-level photography images, user-generated street photos, and/or the like;
18 an interiors setting, showing overlaid images, thumbnails, and/or the like of property 19 interiors, user and/or broker submitted interior photos, and/or the like; a layout setting, showing property layout views, blueprints, and/or the like; and/or the like.
In one 21 implementation, one or more of the map views may be employed to generate a plurality 22 of maps that can be minimized and/or maximized for side-by-side comparison.
In one 23 implementation, one or more of the map view elements shown at 1855 may be 1 connected to and/or may implement tools from a map engine toolkit such as those 2 discussed above.

3 100147] FIGURE 19 shows an implementation of a HUB map user interface in 4 another embodiment of HUB operation. In this implementation, a map control panel 5 1901 further includes user role selection elements 1905, whereby a user may set a 6 desired role for association with and/or modification of the currently displayed map. In 7 one implementation, data records associated with map data, displayed properties, panel 8 tools, and/or the like may include connections with and/or to user role values. Selection 9 of a user role may then have a variety of effects, such as but not limited to, changing io panel tools, displayed properties, layer and/or subcategory designations and/or 11 availability, and/or the like. For example, in the implementation illustrated in Fig. 19, a 12 tenant broker role is selected at 1905, and consequently the key at 1910 shows tenant-13 broker associated and/or specific layers and/or subcategories, including tenant client 14 target properties, tenant client existing properties, and/or the like. In one 15 implementation, a HUB map interface may further be configured with a button 1912, or 16 other interface element, allowing a user to save a state of control panel settings. For 17 example, in one implementation, the HUB may maintain one or more data records 18 having fields corresponding to each of the options in the map control panel, and saving a 19 state may cause current values of those interface options to register as saved data values 20 in the corresponding fields of those one or more data records. A user may then recover 21 a given interface configuration by opening a saved state 1913. In one implementation, 22 the HUB may automatically save a record of a finite number of previous control panel 23 setting configurations, and allow a user to undo, step-back, and/or the like to recover a 1 recent, prior control panel settings configuration via a corresponding interface element 2 1915.

3 100148] FIGURE 20 shows an implementation of a HUB map user interface in 4 another embodiment of HUB operation. As in Fig. 19, a control panel is shown with user role selection elements 2005, however here with a landlord broker role 6 selected. Accordingly, the key at 2010 includes landlord broker associated and/or 7 specific layers and/or subcategories, such as market comparables, and/or the like. The 8 implementation of the displayed properties key shown in Fig. 20 further includes "My 9 Properties" and "My Company Properties" options, which may allow a user in an LB role io to view properties on a map such as those listed at element 215 of Fig. 2.
These options 11 in the displayed implementation further include fields 2015 admitting keywords, based 12 upon which the displayed properties may be filtered. For example, entry of the keyword 13 "Naperville" may cause only "My Properties" located in, and/or otherwise associated 14 with, Naperville to be displayed on the map. In one implementation, a global keyword filter may be applied at once to more than one of the property types shown in the map 16 key. In one implementation, properties shown in a map key may be displayed in a 17 manner similar to nested folders such as those shown at 215 in Fig. 2. It should be 18 noted that the implementations shown in Figs. 19 and 20 are for illustrative purposes 19 only, and that a wide variety of other roles (e.g., new business, investment sales, property management, disposition, and/or the like) and associated user interfaces may 21 be implemented and/or available within a particular implementation.

22 [001-491 FIGURE 21 shows an implementation of a HUB map user interface in 23 another embodiment of HUB operation. In one implementation, an interface pointer 1 element, such as a mouse pointer 2101, may be used to select, click on, mouse-over, 2 and/or the like one or more mapped properties to produce a pop-up window, dialog box, 3 and/or the like such as that shown at 2105. In one implementation, such a window 2105 4 may appear translucent or opaque, and/or may fade-in or fade-out depending on user interaction with the window and/or the map element(s) to which the window is 6 connected. In one implementation, a user may be able to enter a timescale for fade-in 7 and/or fade-out of the window 2105. The window 2105 may include a variety of 8 information associated with the selected property, such as one or more property images 9 2110, other property information 2115 (e.g., property attributes from a HUB
bifurcated 1o display), and/or the like. The window 2105 may further include contact information 11 2120, such as for one or more contacts, tenants, landlord, brokers, and/or the like 12 associated with the displayed property. The window 2105 may further include a 13 selectable link to view other options 2125, such as to auto-populate other portions of the 14 HUB interface (e.g., the bifurcated display) with information associated with the selected property, send the property information in an e-mail, generate a report 16 associated with the property, view a nearest point of interest, view a site drive, view 17 market comparables, add a push-pin to the map at the location of the property, edit 18 property information, and/or the like.

19 [00150] FIGURE 22 shows an implementation of a HUB map user interface in another embodiment of HUB operation. Here, selection of a map data icon yields a 21 window 2201 with a variety of options for manipulating, interacting with, viewing, 22 and/or the like map data and/or associated property information. Such options may, 23 for example, include viewing of property information associated with the selected icon;
24 viewing of associated property pictures, exteriors, interiors, layouts, and/or the like;

1 auto-population of a portion of the HUB interface (e.g., the bifurcated display) based on 2 property information and/or property records associated with the selected map icon;
3 sending property information in an e-mail message, instant message, fax, and/or the 4 like; generation of one or more reports (e.g., PDF documents, word processing documents, spreadsheets, and/or the like) containing property information associated 6 with the selected map icon; initiation of a communication connection (e.g., phone call, 7 e-mail message, instant messaging session, and/or the like) with a contact (e.g., client, 8 tenant, landlord, broker, agent, bank, mortgage professional, and/or the like) associated 9 with the selected map icon; querying and/or displaying one or more nearby points of 1o interest, site drives, cross-streets and/or intersections, market comparables, shopping 11 centers, schools, libraries, police stations, and/or the like; adding a push-pin or other 12 map marker at the location of the selected map icon; editing property information 13 associated with the selected map icon; and/or the like.

14 [o 0151 ] FIGURE 23 shows an implementation of logic flow for map interaction and data extraction in one embodiment of HUB operation. An indication of a map 16 interaction may be received 2301, such as a click, mouse-over, and/or the like on a 17 location, icon, and/or the like within a displayed map. In response to the interaction, 18 the HUB may query available action options 2305. Available actions may depend on a 19 variety of factors, such as but not limited to the type of location selected, the type of interaction therewith, a selected user role, user authorizations, contact availability, 21 property information availability, and/or the like. The HUB may provide a selectable 22 list of available options for display to the user 2310, and receive a selected option 23 therefrom 2315. Selectable options may include, but are not limited to, those discussed 24 above with relation to Figs. 21 and 22, such as viewing and/or editing property 1 information and/or associated property records 2320; auto-populating portions of the 2 HUB user interface, such as the bifurcated display 2325; extracting and sending and/or 3 reporting selections of a map and/or associated property information 2330;
4 corresponding with a contact associated with map data 2335; add a note, push-pin, and/or other marker or information for association with a point on a displayed map, a 6 map icon, property, and/or the like 2340; get closes points of interest to a selected point 7 2345; and/or the like.

8 [00152] FIGURE 24 shows an implementation of logic flow for dynamic map 9 updating in one embodiment of HUB operation. A displayed map may be updated in io real time based on user interactions, such as the variation of panel tool settings, map ii data inputs, and/or the like. A map may be provided with a display of map data based 12 on current map data parameters and/or map settings 2401. A determination may then 13 be made as to whether there are any map display parameter updates 2405. In one 14 implementation, map display parameter updates may comprise the manipulation, adjustment, and/or the like of any of the panel tools shown in Figs. 18-20. If an update 16 exists, the instruction for that update may be received 2410 and the map display 17 configuration may be updated based on the received instruction 2415. A
determination 18 may also be made as to whether HUB display inputs have been updated 2420.
In one 19 implementation, HUB display inputs may comprise entries to existing and/or desired property characteristics and/or requirements, such as those which may be entered into 21 the bifurcated display of a HUB interface (see, e.g., element 143 of Fig.
1). In another 22 implementation, HUB display inputs may include any information stored in a property 23 record. If updates exist, they may be received 2425 and the HUB may query map data 24 records based on the received parameter update 2430. Based on that query, a i determination may be made as to whether one or more data records exist matching the 2 submitted update and/or query 2435. If not, then the HUB may return to 2401 and 3 provide a map for display based on the prior set of mapped records. In one 4 implementation, an error message may further be provided and/or other error handling 5 procedures undertaken. If one or more matching records exists, address data may be 6 extracted therefrom 2440 and used to generate a map with new map data 2401.
The 7 HUB may also determine whether additional updates have been, can be, or will be 8 provided 2422 and, if not, map updating may be complete 2423. In one 9 implementation, a map update may be correlated to the date and/or time that a specific 1o file name and/or data record identifier was last updated, such that a user can scroll 11 through previously stored files and/or data records and updates maps based thereupon 12 as ordered, e.g., by date relevance.

131001531 In keeping track of user scheduled activities, calendars, and/or the like, 14 the HUB and/or HUB data records may track both temporal and spatial information 15 associated therewith, such as the times and locations of scheduled appointments. The 16 HUB may further contain information about the identities of appointment 17 counterparties and/or meeting participants. Based on these collections of information, 18 the HUB may allow for optimization of user schedules, such as to minimize travel times 1s and/or distances, provide intelligent suggestions for potential new appointments based 20 on proximity to existing appointments, group scheduled activities in time that have 21 close spatial locations and/or separate activities in time that have disparities in spatial 22 location, and/or the like. FIGURE 25 shows an implementation of logic flow for 23 spatiotemporal schedule optimization in one embodiment of HUB operation.
Schedule 24 information may be retrieved for a specified period and/or range of time 2501, such as from one or more data records associated with a user ID. In one implementation, 2 schedule information may comprise a series of times and locations of scheduled 3 activities and/or appointments (and their correlated priorities, e.g., high, medium, low).
4 A determination may be made as to whether any of the activities, activity counterparts, and/or the like have a distance from each other that is within a set distance range, such 6 as less than a threshold distance 2505. If so, then a determination may be made as to 7 whether the difference between scheduled times for those activities is in a set time 8 range, such as less than a threshold time difference but greater than the duration of the 9 activities themselves 2510. If so, then, in an implementation where activities have io designated priority values, a determination may be made as to whether any set activity 11 priority values are greater than a threshold priority value 2515. If not (e.g., both 12 activities have sufficiently low associated priority values), then the HUB
may suggest 13 rescheduling of those qualifying activities to the same day 2520. In one 14 implementation, upon confirmation of rescheduling, an e-mail message, text message, instant message, alert, and/or the like notice may be provided to parties associated with 16 the activity for notification and/or confirmation. In an alternative implementation, the 17 HUB may automatically update a schedule and/or generate a new schedule with the is activities rescheduled to the same day. If either of the activities have a priority higher 19 than a threshold value at 2515, then a determination may be made as to whether both activities have a priority value exceeding the threshold 2525. If so (e.g., both activities 21 have sufficiently high associated priority values), then no rescheduling is made at that 22 time, and the HUB moves to 2535. If one of the activities has lower priority than the 23 threshold, though, the HUB may suggest rescheduling of that lower priority activity to 24 be on the same day as the higher priority activity 2530. The HUB may further 1 determine one or more travel distances, such as a total day travel distance, for activities 2 in the schedule that are scheduled on the same day 2535. In one implementation, travel 3 distances may be determined based on tools in a map engine API toolkit. A
4 determination may be made as to whether any of the determined distances exceed a maximum distance threshold 2540. If so, then the HUB may suggest rescheduling of 6 activities on a day having a sufficiently large travel distance and/or may suggest 7 alternative days to reschedule activities based on spatial proximity of activities 2545, 8 after which spatiotemporal schedule optimization may conclude 2550.

9 100154] FIGURE 26 shows an implementation of logic flow for a contact searching 1o rolodex in one embodiment of HUB operation. The contact searching rolodex may allow ii for efficient and user-friendly organization, search and display of a user's list of contacts.
12 A first contact query parameter may be received 2601, such as a contact identifier 13 and/or characteristics, property identifier and/or characteristics, and/or the like. A
14 determination may then be made as to whether there are to be additional query parameters 2605 and, if so, those parameters are received 2615. Contacts and/or 16 contact records may then be queried based on received query parameters 2610. A
17 determination may be made as to whether any matching contacts exist for the submitted 18 query 2620 and, if not, then an error handling procedure may be undertaken, such as 19 providing an error message, requesting the entry of new and/or modified search parameters, and/or the like 2625. If one or more matches are found at 2620, then 21 matching contact information may be retrieved 2630. The HUB may further retrieve 22 and/or determine grouped subcategory configuration information based on the query 23 and/or the retrieved results 2635. In one implementation, grouped subcategory 24 information may include any of a variety of subcategory identifiers into which contacts 1 may be grouped, such as but not limited to: company, retail category, state or other 2 geographic designation, job title, role, HUB status and/or label, contact type, scheduled 3 activity status, communication frequency and/or recentness, and/or the like.
In one 4 implementation, subcategories may have further subcategories nested therein.
In one implementation, the list of grouped subcategories and/or nested subcategories selected 6 and/or retrieved at 2635 may depend on the received query parameters, retrieved 7 results, a user role, user history (e.g., my properties, my LL properties, my tenant a clients, and/or the like), and/or the like. The HUB may then determine subcategory 9 allocations of retrieved contacts 2640, such as may comprise a number of retrieved 1o contacts associated with and/or allocatable to each of the retrieved subcategory labels.
11 For example, all contacts who are located in the state of California may be identified 12 with the CA subcategory, and a number may be determined of all such identified 13 contacts. Contact display characteristics may then be configured 2645, such as 14 described in one implementation in Fig. 27. The HUB may then provide configured contacts and grouped subcategories for display 2650. In one implementation, 16 configured contacts may be provided at one side of an interface display while a listing of 17 subcategory labels may be provided on another side of the interface display (e.g., with 18 numbers of matching contacts, determined at 2640, displayed next to each subcategory 19 label). A determination may be made as to whether there are any query parameter changes, additions, subtractions, and/or the like 2655 and, if so, then the HUB may 21 return to 2615. Otherwise, a determination may be made as to whether any sub-22 category selections have been received 2660. In one implementation, a subcategory 23 selection may be registered when a user clicks on, mouses over, and/or otherwise 24 interacts with a subcategory label in the HUB user interface. If a subcategory selection 1 is registered, the HUB may query remaining contacts (e.g., those contacts retrieved in 2 response to the prior set of query parameters and/or subcategory selections) based on 3 the new subcategory selection 2665 and return to 2630 to retrieve contacts matching the 4 new query. Otherwise, the contact selection and display may conclude 2670.

100155] FIGURE 27 shows an implementation of logic flow for contact display 6 configuration in one embodiment of HUB operation. A HUB contact display 7 configuration flow, such as that shown in one implementation in Fig. 27, may allow for 8 optimization of display parameters to maximize useful information displayed to the user 9 in response to a contact query. Contacts may be sorted based on one or more selected io criteria 2701, such as alphabetically, by frequency and/or recentness of correspondence, 11 by priority value, by number and/or value of associated properties, by distance, and/or 12 the like. The number of contacts to be displayed may be determined 2705, such as by 13 counting the number of contact records retrieved in response to a submitted query, and 14 a determination made as to whether there is only a single contact 2710. If so, contact information associated with the single contact may be configured for full size display, 16 such as to occupy the entire screen and/or an entire designated area for contact 17 information, include all available contact information that can be displayed in the 18 screen, and/or the like. In one implementation, where a single contact exists, contact 1s information associated with the single contact may be provided for full-size and/or full-screen display without any need for a mouse click or other further interaction from a 21 user to open or engage such a display. If there is not a single contact at 2710, then a 22 determination may be made as to whether the number of contacts falls into an 23 intermediate range of values 2730. If so, then the contact information associated with 24 those contacts may be configured for intermediate-size display 2735, for example to 1 show approximately 3-5 contacts on the page at a time. If the number of contacts is 2 greater than the intermediate range at 2730, then contact information may be 3 configured for minimum size display 2745, such as showing only a single line for each 4 contact. For any multi-contact display (e.g., 2735 and/or 2745), a determination may be 5 made as to whether a single contact selection has been received 2750, such as a user 6 clicking on, mousing over, and/or otherwise interacting with a single contact from the 7 list of contacts. If so, then the HUB may return to 2715 to configure the displayed 8 contact for full-size display. A determination may be made as to whether a change in 9 contact query parameters is received or if the user specifies a desire to return to a multi-lo contact view after having selected a single contact therefrom 2720. If such a change ii and/or desire is registered, the HUB may return to 2701. Otherwise, contact display 12 configuration may conclude 2725.

13 [o 015 6 ] FIGURE 28 shows an implementation of logic flow for a prospect 14 generation rolodex in one embodiment of HUB operation. A HUB prospect generation 15 flow, such as that shown in the example implementation of Fig. 28, provides a powerful 16 facility for searching information, performing nested search procedures, and quickly 17 identifying desired and/or useful information from a collection of data. A
prospect 18 generation rolodex interface may, in one implementation, comprise a collection of 19 rollable cylinder elements (i.e., "cylinders," "rollers," and/or the like, where these terms 20 are used interchangeably herein), or other such interface elements, by which a user may 21 specify variable names and/or values. In one implementation, variable names made 22 available on one or more given rollers may be based on categories of information 23 associated with contacts, properties, and/or the like and/or on fields in data records 24 associated therewith. In one implementation, available search variables may further 1 depend on a user role, an initial user query, and/or the like. The HUB may provide 2 rolodex cylinders in an initial and/or default state, such as with no search variable 3 selections 2801. The user may then specify, and the HUB may receive, a first search 4 variable selection on one of the cylinders 2805. Based on the selected first search variable, the HUB may then retrieve possible values for the retrieved search variable and 6 populate a column corresponding to the roller on which the variable has been set with 7 the retrieved values 2810. In one implementation, the HUB may query existing data 8 records and/or historical user activities to find all values of the selected variable existing 9 in those records, and may only populate the column with those existing variable values.
1o A determination may be made as to whether a variable value has been selected, such as ii by clicking or mousing over by a user 2815. If so, then a determination is made as to 12 whether the selected value has been locked 2820. A user may lock a variable value by 13 selecting a lock option, double-clicking the value, and/or otherwise registering a desire 14 to lock the value by an appropriate user interface element. If no lock has occurred, the HUB may return to 2815. Otherwise, once a variable value is locked, the locked value of 16 the variable may be displayed in proximity with the roller and/or cylinder on which the 17 associated variable is shown 2825. The HUB may then retrieve additional variables 18 based on the locked variable 2830. For example, if a first variable is locked on a first 19 value, the HUB may restrict itself to data records having that first variable with the first value, and may limit available variables on the remaining rollers to those that are 21 relevant to and/or have non-trivial values within the remaining data records. The HUB
22 may further restrict values for the remaining variables to those values that exist in data 23 records who have a first variable with the locked first value 2835. The additional 24 variables and associated variable values may then be provided for selectable display on 1 the remaining rollers 2840. A determination may be made as to whether any locked 2 variables have been unlocked 2845 and, if so, available variables and/or values 3 corresponding to that unlocked variable may be expanded 2850. If there is no 4 unlocking at 2845, a determination may be made as to whether a variable value has been selected on any column of values corresponding to a variable-set roller 2855. If 6 not, the HUB may return to 2805 to receive further search variable selections on one or 7 more rollers. If a variable has been selected at 2855, a determination is made as to 8 whether that variable value has been locked 2860. If not, the HUB may return to 2855 9 until a value is locked. Once a value has been locked at 2860, the HUB may return to 2825 to further refine available variables and/or variable values on any remaining 11 rollers. Upon locking of all variables, retrieved results may be provided for display 12 therebelow.

13 [o0157] In one embodiment, the HUB may be configured to effectuate intelligent 14 inbox coordination, which may facilitate the processing of messages configured as email messages, XML data, HTTP POST message content, and/or the like for economical 16 display and interaction. The HUB's intelligent inbox coordination features may allow 17 for the distillation of large volumes of message data and/or content to highlight and/or 18 direct users to the particular message and/or attachment containing data that is most 19 interesting or relevant to them. Aspects of HUB intelligent inbox coordination features may include the generation and application of email allocation rules and/or sub-rules;
21 analysis, parsing, intelligently filing and sub-filing, and/or other processing of email 22 content, attachments, and/or other associated data; generation of message and/or 23 message data analytics, statistics, summaries, industry trends, news content, and/or the 24 like; and/or the like.

1 [ o o 15 8 ] FIGURE 29 shows an implementation of data flow between and among 2 HUB components and affiliated entities in one embodiment of HUB operation.
The 3 HUB 2901 may serve a central role to receive and process messages and to generate 4 and/or output message summaries. For example, email messages 2905 may be received via a communication network 2910. In one implementation, email messages 2905 may 6 be received at the HUB by being addressed to a HUB email address. In an alternative 7 implementation, email messages may be passed through an intermediary facility for 8 extracting attachments, accessing embedded links, scraping and/or parsing email 9 content, and/or the like 2915. In another implementation, a user may manually pass io and/or create rules to allow emails to pass. In one implementation, an attachment/link 11 scraper 2915 may be configured as part of the HUB 2901 while, in another 12 implementation, the attachment/link scraper 2915 may be configured as an external 13 and/or third-party facility, data warehouse, and/or the like from which scraped and/or 14 parsed email data is passed to the HUB 2901. In some implementations, other electronic messages may also be received and/or processed by the HUB 2901 and/or an 16 attachment/link scraper 2915 component, such as but not limited to XML
messages 17 2920, HTTP POST messages 2925, and/or the like. In accordance with apparatuses, 18 methods and systems described herein, the HUB 2901 may process received messages in 19 order to generate message analytics, statistics, summaries, and/or the like, such as may be configured for inclusion in one or more summary messages, message dashboard 21 displays, and/or the like 2930, which may then be configured for, provided to, stored in 22 and/or accessible by one or more client terminal devices 2935; mobile devices 2940;
23 email and/or web servers 2945; system, web, email and/or the like databases 2950;
24 and/or the like. In other implementations, the HUB may communicate with one or 1 more devices, such as mobile devices, configured for code capture (e.g., scanning and/or 2 imaging barcodes, 2D matrix codes, steganographic images, and/or the like), whereby 3 such codes may contain data content which can be transmitted to and/or synced directly 4 into the HUB and/or HUB databases.

[00159] FIGURE 30 shows an implementation of logic flow for intelligent inbox 6 coordination in one embodiment of HUB operation. Although Fig. 3o discusses an 7 embodiment of the HUB directed to the processing of email messages, it is to be 8 understood that the HUB may be configured to process other types of data s transmissions, messages, code captures (e.g., barcodes), and/or the like in addition to io and/or instead of email messages, such as but not limited to XML data, HTTP
POST
11 data, and/or the like. An email message, such as may be addressed to an individual user 12 and/or to a group of users, may be delivered to a user address, such as via an exchange 13 server 3001 or other email message processing, storage and/or access system. s (e.g., 14 Outlook rules). A copy of the delivered message may then be generated 3005.
In one implementation, copy generation may be based on an analysis of email content, sender 16 address, attachment and/or link content, and/or the like, such as based on an evaluation 17 of the email message vis a vis one or more email rules (e.g., Outlook rules). In one 18 implementation, all email messages in a user's inbox may be evaluated to determine if a 19 copy is to be generated. In another implementation, email messages may be initially directed to one or more designated email folders and/or subfolders, such as manually by 21 a user and/or automatically based on an evaluation of those messages in accordance 22 with one or more email rules 3003. In various implementations, such rules may be 23 designated by a user, automatically generated, and/or the like, as discussed in 24 accordance with various embodiments and implementations herein. Copies may then 1 be generated at 3005 for emails residing in and/or otherwise associated with the 2 designated folders. In one implementation, code for inserting rules into an email 3 management program (e.g., Microsoft Outlook) within embodiments of HUB
operation 4 may take a form similar to the following example:

namespace EMailStatsAddIn 6 {
7 using System;

8 using Microsoft.Office.Core;
9 using Extensibility;

using System.Runtime.InteropServices;
11 using Outlook = Microsoft.Office.Interop.Outlook;
12 using System.Windows.Forms;

14 [GuidAttribute("F73EF012-69B8-4349-83F9-SBFCD50C538D"), Progld("EMailStatsAddln.Connect")I
16 public class Connect : Object, Extensi_bility.IDTExtensibility2 17 {

18 IniFile iniObj = new IniFile(@"C:\\Program Files\\Citigo\\Flyer 19 Filter\\F1yerFilter property.ini");
21 private Outlook.Application applicationObject;
22 private object addlnInstance;

24 Our UI will consist of a single CommandBarButton private CommandBarButton btnGetEMailStats;

27 <summary>

28 /// Implements the constructor for the Add-in object.
29 /// </summary>
public Connect o 31 {
32 }

34 <summary>
Implements the OnConnection method of the IDTExtensibility2 36 interface.

1 /// Receives notification that the Add-in is being loaded.
2 /// </surmcary>

3 /// <param term='application'>

4 /// Root object of the host application.
</param>

6 <param term='connectMode'>
7 Describes how the Add-in is being loaded.
8 </param>

9 /// <param term='addInInst'>
/// Object representing this Add-in.
11 </param>

12 public void OnConnection(object application, 13 Extensibility.ext ConnectMode connectMode, 14 object addlnlnst, ref System.Array custom) {

16 f/ Cast to a strongly typed Application class.
17 applicationObject - (Out'_ook.Application)application;
18 addinInstance = addInInst;

// If we are not loaded upon startup, forward to 21 OnStartupCompleteO

22 and pass the incoming System.Array.

23 if (connectMode != ext ConnectMode.ext cm Startup) 24 {
OnStartupComplete(ref custom);
26 }
27 }

29 /// <summary>

/// Implements the OnDisconnection method of the IDTExtensibility2 31 interface.

32 /// Receives notification that the Add-in is being unloaded.
33 /// </summary>
34 /// <param term='disconnectMode'>
Describes how the Add-in is being unloaded.
36 /// </param>
37 /// <param term='custom'>
38 Array of parameters that are host application specific.
39 /// </param>

1 public void OnDisconnection(Extensibility.ext DisconnectMode 2 disconnectMode, ref System.Array custom) 3 {
4 If this Add-in is unloading from the host, but the application is not shutting down, forward to our 6 // OnBeginShutdown().
7 if (disconnectMode !_ 8 ext DisconnectMode.ext dm HostShutdown) 9 {
OnBeginShutdown(ref custom);
11 }
12 applicationObject = null;
13 }

Implements the OnAddlnsUpdate method of the IDTExtensibility2 16 interface.
17 /// Receives notification that the collection of Add-ins has 18 changed.
19 public void OnAddlnsUpdate(ref System.Array custom) {
21 }

23 /// Implements the OnStartupComplete method of the 24 IDTExtensibility2 interface.
Receives notification that the host application has completed 26 loading.
27 public void OnStartupComplete(ref System.Array custom) 28 {

29 #region Create GUI.
First, get access to Outlook's CommandBars on 31 the active explorer.
32 CommandBars commandBars =
33 applicationObject.ActiveExplorer().CommandBars;
34 try {

36 If our button is already 37 on the Standard CommandBar, use it.
38 btnGetEMailStats = (CommandBarButton) 39 commandBars["Standard"].Controls["Create Flyer Filter for this Email"];

1 }
2 catch 3 {
4 If our button is not there, // we may make a new instance.

6 // Note that the Add o method was 7 // defined to take optional parameters, 8 which are not supported in C#.
9 Thus we must specify Missing.Value.
btnGetEMailStats = (CommandBarButton) 11 commandBars["Standard"].Controls.Add(l, 12 System.Reflection.Missing.Value, 13 System. Reflection.Missing.Value, 14 System. Reflection.Missing.Value, System.Reflection.Missing.Value);
16 btnGetEMailStats.Caption = "Create Flyer Filter for this 17 Email";
18 btnGetEMailStats.Style = MsoButtonStyle.msoButtonCaption;
19 }
Setting the Tag property is not required, but can be used 21 to quickly retrive your button.
22 btnGetEMailStats.Tag = "Create Flyer Filter for this Email";

24 Setting OnAction is also optional, however if you specify the ProgID of the Add-in, the host will automatically 26 load the Add-in if the user clicks on the CommandBarButton when 27 the Add-in is not loaded. After this point, the Click 28 event handler is called.
29 btnGetEMailStats.OnAction = "!GEMailStaLsAddIn.Connect>";
btnGetEMailStats.Visible = true;
31 btnGetEMailStats.Click += new 32 CommandBarButtonEvents ClickEventHandler( 33 btnGetEMailStats Click);

#endregion 36 }

1 /// Implements the OnBeginShutdown method of the IDTExtensibility2 2 interface.

3 /// Receives notification that the host application is being 4 unloaded.

public void OnBeginShutdown(ref System.Array custom) 6 {
7 // Delete our button.
8 CommandBars commandBars =

9 applicationObject.ActiveExplorer O .CommandBars;
try 11 {

12 // Find our button and kill it.

commandBars["Standard"].Controls["Statistics"].Delete(Syst:em.Reflection.Missin g .Value);

17 catch (System.Exception ex) 18 { MessageBox.Show(ex.Message); }
19 }
21 void CreateActionRule() 22 {

23 Outlook.Rules ruless =
24 applicationObject.Session.DefaultStore.GetRules();

26 for (int k = 1; k < ruless.Count; k++) 27 {

28 if (ruless[k].Name.Equals("ActionAndDecissionRule")) 29 return;
}

32 Outlook.MAPIFolder inbox =
33 applicationObject.Session.GetDefaulttolder( 34 Outlook.OlDefaultFolders.olFolderInbox);
inbox.Folders.Add("Aksiyon&Kararlar", 36 Outlook.OlDefaultFolders.olFolderlnbox);
37 Outlook.MAPIFolder targetfolder =
38 inbox.Folders["Aksiyon&Kararlar"];

39 Outlook.Rules rules =
applicationObject.Session.DefaultStore.GetRules O;

41 Outlook.Rule rule = rules.Create("ActionAndDecissionRule", 1 Outlook.OlRuleType.olRuleReceive);

2 Outlook.TextRuleCondition sub = rule.Conditions.Body;
3 sub.Enabled = true;

4 sub.Text = new string[] { "ToplantisiKararlari-iyitoplantiKontrol"
};

6 Outlook.MoveOrCopyRuleAction movecopy = rule.Actions.MoveToFolder;
7 movecopy.Enabled = true;

8 movecopy.Folder = targetfolder;
9 rule.Execute(true, inbox, false, Outlook. OlRuleExecuteOption.olRuleExecuteUnreadMessages);
11 rules.Save(false);
12 }

14 private void btnGetEMailStats Click(CommandBarButton Ctrl, ref bool CancelDefault) 16 {

17 DateTime today = DateTime.Today;
18 string filter #region Check Folder 21 // Get items in user's inbox.
22 Outlook.NameSpace outlookNS =
23 applicationObject.GetNamespace("MAPI");
24 Outlook.MAPIFolder inboxFolder =
outlookNS.GetDefaultfolder(Outlook.OlDefaultFolders.olFolderlnbox);

27 Outlook.Folder targetFolder = null;

29 string folderPath = inboxFolder.FolderPath + @"\Property Flyers";

31 targetFolder = GetFolder(folderPath);

33 if (targetFolder == null) 34 {
//If Property Flyers folder doesn't exist, create it 36 targetFolder = inboxFolder.Folders.Add("Property Flyers", 37 Type.Missing) as Outlook.Folder;
38 }
39 #endregion 2 #region Create Filter 4 filter = "[Subject]=property";
6 #endregion 8 #region Filter, then Move mails To Property Flyers Folder,also Send 9 them to configured mail address Outlook.Items filterItems = inboxFolder.Items.Restrict(filter);

12 foreach (object item in filterItems) 13 {
14 Outlook.Mailltem mi = item as Outlook.Mailltem;
16 if (mi != null) 17 {
18 mi.Move(targetFolder);
19 //Send mail to mail configured SendNewMail(iniObj.IniReadValue("Email", "RecipientName"), 21 iniObj.IniReadValue("Email", "RecipientEmail"), mi.Subject, mi.Body);
22 }
23 }
24 #endregion 26 #region Sent items stats.
27 #endregion 29 MessageBox.Show("ok");
}
31 private Outlook.Folder GetFolder(string folderPath) 32 {
33 Outlook.Folder folder;
34 string backslash = @"\";
try 36 {
37 if (folderPath.StartsWith(@"\\")) 38 {

1 folderPath = folderPath.Remove(O, 2);
2 }

3 String[] folders = folderPath.Sp'_it(backslash.ToCharArray O );
4 folder = applicationObject.Session.Folders[folders[O]] as Outlook.Folder;

6 if (folder != null) 7 {

8 for (int i = 1; i <= folders.GetupperBound(0); i++) 9 {

Outlook.Folders subFolders = folder.Folders;
11 folder = subFolders[folders[i]]

12 as Outlook.Folder;
13 if (folder == null) 14 {
return null;
16 }
17 }
18 }
19 return folder;
}
21 catch { return null; }
22 }
23 }
24 }
[00160] The generated email message copy may then be copied to a HUB database 26 and/or forwarded to a HUB email address 3010, from where it may be immediately 27 accessed for further processing and/or stored for a period of time for later access, 28 analysis, cross referencing, database updating, and/or the like. For example, in one 29 implementation, the HUB and/or HUB subsystems may periodically retrieve email messages copied at 3010 and extract feature data therefrom, such as attached files, 31 linked files, linked web pages, email message content, and/or the like 3015. Data may 32 then be scraped from email message data features and/or parsed into data fields 3020, 33 such as in accordance with the flow shown in Fig. 32 in one implementation.
The HUB

i may then generate one or more summary messages, dashboard interfaces, rolodex-style 2 email category summaries, and/or the like 3025, as discussed in further detail 3 herebelow, and said summary messages may then be provided for user access 3030, 4 such as by configuring them as email messages, configuring them as webpages embedded in an email message, configuring them as linked and/or attached files in an 6 email message, providing them to a user email client, providing them to a mobile device 7 application or other client computer terminal application, and/or the like.
In one 8 implementation, generated summary message data may be stored as a summary 9 message record at a message database and accessed by one or more remote client 1o terminals, mobile devices, and/or the like as needed.

11 [00161] An original copy of the message may be provided for retrieval access by a 12 user, such as via a mail application such as Microsoft Outlook, a Webmail client, and/or 13 the like 3035. A decision may then be made as to whether messages having attachments 14 are to be filtered 3040 (e.g., such a decision may be made by querying a user setting, querying user terminal device capabilities, and/or the like). If so, then emails having 16 attachments may be blocked from the client device, may be directed to a particular 17 folder, and/or the like 33045. Otherwise, the emails may be passed through to the client 18 device 3050. A determination may also be made as to whether the email messages are 19 to be blocked from one or more user mobile devices 3055. For example, a user may set a preference to block email messages and/or sync one or more mobile devices to company 21 servers (e.g., Blackberry, Microsoft servers, and/or the like) having attachments from a 22 mobile device in order to avoid transmission rate and/or data storage problems 23 associated with the data requirements of those attachments. If the messages are not set 24 for blocking, then the email messages may be passed through to and/or be accessible by 1 the mobile device 3060. Otherwise, the emails may be blocked from the mobile device 2 3065, and/or the content on the mobile device and desktop may be synced. In one 3 implementation, a mobile device application may pull summary message data such as 4 that generated at 3025 for storage and/or display on the mobile device in lieu of the blocked emails 3070. In one implementation, the summary message data provided to 6 and/or displayed at the mobile device may be configured as an email message.
In one 7 implementation, attachment information from the blocked emails may be extracted and 8 provided directly to the mobile device in lieu of the email and/or the full attached file 9 3067, whereon it may be directly viewed, such as via a mobile application interface, 1o mobile device web browser, mobile device email client, and/or the like.

11 [o o 16 2 ] In one implementation, property information extracted from email 12 messages, attached and/or linked files and/or webpages, and/or the like, and/or the 13 analytics generated based thereon may be used by the HUB to populate data records 14 associated with one or more real estate listing services. For example, in one implementation, listing service data may be updated periodically, each time a new 16 message is received by a participating HUB user, and/or the like frequency, and the 17 resulting real estate information may be made available to users other than those to 18 which the property information was originally directed. In one implementation, 19 acquired property information provided in such a listing service may be searchable. In another implementation, authorization settings may be associated with various property 21 information, such that only limited groups of users may be authorized to access 22 particular sets of property information.

1 [ o 016 3 ] FIGURE 31 shows an implementation of logic flow for intelligent inbox 2 coordination in another embodiment of HUB operation. An email message may be 3 delivered to a user address, such as via an Exchange server 3101, and a user may have 4 access to retrieve the message, such as via Microsoft Outlook, an Webmail client, and/or the like 3105. A determination may be made as to whether or not to filter messages 6 (e.g., those having attached files, having embedded files and/or links, and/or the like) 7 3110, such as may be based on user defined filters and/or rules (such as may apply to 8 folders, nested folders within folders, and/or the like), preference settings, client device 9 capabilities, and/or the like and, if no filtering is to occur, then those emails may be 1o passed to the user inbox 3115. If, on the other hand, emails having attachments are 11 determined to be filtered at 3110, then emails having attached files, and/or matching 12 other rule-specified criteria, may be passed to a designated folder 3120.
Emails in the 13 designated folder may then be copied and/or forwarded to a HUB address 3125, such as 14 on an immediate, delayed, periodic, and/or the like basis. Emails sent to the HUB
address may then be retrieved, such as on a scheduled and/or periodic basis, and 16 associated email data extracted 3130. For example, extracted data may comprise one or 17 more attached files (e.g., attached to an email or within an email, embedded files and/or 18 links, and/or the like), linked files, linked webpages, email message content, and/or the 19 like. Extracted data may then be scraped and/or parsed into one or more data fields 3135, such as in accordance with the implementation illustrated in Fig. 32.
The HUB
21 may then generate one or more summary messages, dashboard interfaces, rolodex-style 22 email category summaries, and/or the like 3140, as discussed in further detail 23 herebelow, and said summary messages may then be provided for user access 3145, such 24 as by configuring them as email messages, providing them to a user email client, 1 providing them to a mobile device application or other client computer terminal 2 application, and/or the like. In one implementation, generated summary message data 3 may be stored at a message database and accessed by one or more remote client 4 terminals, mobile devices, and/or the like as needed.

[ o o i 6 4 ] FIGURE 32A shows an implementation of logic flow for data scraping in 6 one embodiment of HUB operation. In various implementations, the HUB may employ 7 a variety of data scraping and/or extraction tools and techniques depending on the s particular goals and/or constraints of a particular application, such as but not limited to 9 text conversion, optical character recognition, screen scraping, report mining, and/or io the like. In one implementation, an email message may be retrieved 3201, such as from 11 an email database and/or server, via a communication network, from a designated email 12 folder, and/or the like. A determination may be made as to whether desired email data 13 is configured as a link within the email message 3205. Such a determination may be 14 made based on an inspection of the email message data for link data, based on an inspection of an email tag identifying the email as containing link data, and/or the like.
16 If the data is not configured as a link at 3205, the HUB may presume, in one 17 implementation, that the data is configured as a file attachment, a PDF
file attachment, 18 and/or the like. In an alternative implementation, the HUB may determine if data is .19 configured as an attachment 3207, such as by inspecting whether any file is attached to the email message, whether the attached file is in one of a collection of acceptable 21 and/or expected formats (e.g., PDF), and/or the like. If not, then the HUB
may extract 22 text from the body of the email message itself 3208. Otherwise, an attached PDF file 23 may be extracted and a PDF to text conversion may be performed thereon321o, such as 24 by using online conversion tools for Adobe PDF documents (e.g., emailing the PDF

1 document to pdf2txt@adobe.com causes a reply email to be delivered with a text file 2 attachment containing the text information from the original PDF document), using any 3 of a variety of pdf to text conversion tools such as pdftotext (which is an open source 4 command-line utility for PDF to plain text conversion), and/or the like.
Alternatively, if the determination at 3205 finds that the email data is configured as a link, a second 6 determination may be made as to whether the linked data is configured as a file (e.g., 7 PDF) or a webpage 3215. If configured as a PDF link, then the PDF may be retrieved 8 3220, and a PDF to text conversion may be performed 3210. If, on the other hand, the s link is configured as a webpage, a determination may be made regarding the format of io the webpage, such as whether it is configured as an HTML page or plaintext 3222. If 11 configured as HTML, an HTML to text conversion may be performed 3225, such as 12 using any of a variety of HTML to text conversion tools (e.g., EtText, HTMLCon, Aquatic 13 Moon Software's Markup Remover, and/or the like). Otherwise, text data may be 14 extracted directly from a page configured as text 3226. In some implementations, extraction may include opening multiple links embedded within weblinks in order, 16 ultimately, to reach the one or more links containing particular data targeted for 17 extraction. Text data may then be parsed to extract and/or identify specific categories of 18 information, correlate information with particular data fields, and/or the like 3230. For 19 example, the HUB may search for keywords in the converted text (e.g., "address,"
"square feet," "area," "city," "state," "company," "property type," "price,"
"bedrooms,"
21 "baths," "agent," "phone," and/or the like) and for text data in proximity to those 22 keywords and/or matching particular grammatical and/or syntactic requirements (e.g., 23 a string of numeric characters that is ten characters in length, with appropriate dashes 24 and/or parenthesis, may be recognized as a phone number when in proximity to the 1 word "phone"). Parsed text data may then be pushed to a database, such as configured 2 as a message data record, may be provided for display in a user interface, may be 3 provided to a mobile device application, and/or the like 3225. Message data may then 4 be retrieved for use in generation of summary messages and/or dashboard interface elements, as discussed herein.

6 [00165] FIGURE 32B shows an implementation of data parsing rules in one 7 embodiment of HUB operation. The rules are illustrated in this implementation as a 8 table, where each rule is correlated with a particular flyer 3240, which may be 9 associated variously with a particular email folder, sender, email characteristic, barcode, 1o and/or the like. Rules are then defined for each flyer with respect to various categories 11 of data, such as but not limited to: company 3245, property type 3250, transaction type 12 3255, address 3260, City 3265, county 3270, state 3275, square footage 3280, and/or 13 the like.

14 [ o o16 6 ] In one implementation, scraping rules may take a form similar to the following XML examples:

16 <rule>
17 <fieldname>Company<fieldname>
18 <searchWhere>From Address</searchWhere>
19 <how>strpos</how> //Searches for the FIRST occurance of <string>
<definition>
21 <string>@</string>
22 <position>string after</position>
23 <limit>
24 <how>same word</how>
</limit>
26 </definition>
27 </rule>
28 <rule>

1 <fieldname>Company<fieldname>

2 <searchWhere>PDF</searchWhere>

3 <how>stripos</how> //Searches for the LAST occurance of <string>
4 <definition>
<string>@</string>
6 <position>string after</position>
7 <limit>

8 <how>same word</how>
9 </limit>
</definition>
11 </rule>
12 <rule>
13 <fieldname>Company<fieldname>
14 <searchWhere>PDF</searchWhere>
<how>stripos</how> //Case insensative search for the FIRST occrance 16 of <string>
17 <definition>
18 <string>Real Estate, Inc</string>
19 <string>Real Estate Inc</string>
<string>Real Estate GROUP</string>
21 <position>words before</position>
22 <limit>
23 <how>new line</how>
24 </limit>
</definition>
26 </rule>

28 <rule>
29 <fieldname>Property Type</fieldname>
<searchWhere>PDF</searchWhere>
31 <how>compare</how> //Compares text to a table 32 <definition>
33 <table>property type</table>
34 </definition>
</rule>

37 <rule>
38 <fieldname>Transaction Type</fieldname>

1 <searchWhere>PDF</searchWhere>
2 <how>stripos + compare</how>
3 <definition>
4 <string>Available for $compare</string> //$compare is filled in from transaction type table for use with stripos 6 <position>used variable</position> //"$compare" in the above 7 match 8 <table>transaction type</table>
9 </definition>
</rule>

12 <rule>
13 <fieldname>State</fieldname>
14 <searchWhere>PDF</searchWhere>
<how>stripos + compare</how>
16 <definition>
17 <string>, $compare</string>//$compare is filled in from the 18 states table for use with stripos 19 <position>used variable</position> //"$compare" in the above match 21 <table>states</table>
22 </defintion>
23 </rule>

<rule>
26 <fieldname>City</fieldname>
27 <searchWhere>PDF</searchWhere>
28 <how>strpos</how>
29 <defintion>
<string>, $state</string> //$state would be populated from the 31 State rule above 32 <position>words before</position>

33 <limit> //limit how far to search "words before"
34 <how>compare 11 words=2</how> //This means we will keep going backwards until we either reach 2 words, or match a value in the street 36 table.
37 <table>streets</table>
38 <include>no=$compare</include> //do not include the 39 found compare </limit>
41 </definition>

1 </rule>

3 <rule>
4 <fieldname>Address</fieldname>
<searchWhere>PDF</searchWhere>
6 <how>strpos</how>
7 <definition>
8 <string>$city</string> //$city would be populated from the City 9 rule above <position>words before</position>
11 <limit>
12 <how>numeric II new line</how> //keep going backwards 13 until we find numeric (street number) 14 <include>yes=$numeric</include> //include the numeric if found 16 </limit>
17 </definition>
18 </rule>

<rule>
21 <fieldname>Address</fieldname>
22 <searchWhere>PDF</searchWhere>
23 <how>strpos</how>
24 <definition>
<string>$city</string> //$city would be populated from the City 26 rule above 27 <position>words before</position>
28 <limit>
29 <how>numeric 11 new line</how> //keep going backwards until we find numeric (street number) 31 <include>yes=$numeric</include> //include the numeric if 32 found 33 </limit>
34 </definition>
</rule>

37 <rule>

38 <fieldname>SQ FT</fieldname>
39 <searchWhere>PDF</searchWhere>
<how>stripos</how>

1 <defintion>
2 <string>Available:</string>
3 <string>Space:</string>
4 <position>words after</string>
<limit>

6 <how>numericspace 11 words=l</how>
7 <include>yes=$numericspace && no=words</include>
8 </limit>
9 <verifyDataType>numericspace</verifyDataType>
</definition>
11 </rule>

13 <rule>
14 <fieidname>SQ FT</fieldname>
<searchWhere>PDF</searchWhere>
16 <how>stripos + compare</how>
17 <defintion>
18 <string>$compare</string>
19 <position>words before</string>
<limit>
21 <how>numericspace 11 words=l</how>

22 <include>yes=$numericspace && no=words</include>
23 </limit>
24 <table>square feet words</table>
<verifyDataType>numericspace</verifyDataType>
26 </definition>

27 </rule>
28 [001671 FIGURE 33 shows an implementation of logic flow for inbox coordinator 29 configuration in one embodiment of HUB operation. A flow similar to that shown in the 3o example of Fig. 33 may be employed by HUB implementations to allow a user to 31 configure a HUB intelligent inbox coordination application, such as at a client terminal 32 device. A user may download an installer application 3301 and run it to open an 33 installation wizard application 3305, which may guide the user to create rules to name 34 folders and/or subfolders, or which may guide the user to directly and/or manually 1 name folders and/or subfolders, to which emails, email data, email attachments (e.g., 2 flyers), and/or the like may be directed, and may allow the user to view one or more 3 email addresses to which emails, email data, email attachments (e.g., flyers), and/or the 4 like may be directed. New folders and/or subfolders may then be created based on user inputs to the installation wizard 3310, and the HUB may generate one or more rules to 6 move emails, email data, email attachments (e.g., flyers) and/or the like to the specified 7 folders and/or subfolders 3315. In one implementation, a user may be allowed to 8 explicitly specify a rule, such as via an email client application (e.g., Microsoft Outlook).
9 In another implementation, a user may be requested to specify email characteristics io and/or tags, based on which a rule may be automatically generated. In one 11 implementation, the HUB may subsequently provide selectable icons, buttons, and/or 12 the like user interface elements for selectable display in association with subsequent 13 email messages and automatically generate rules to apply to future emails based on the 14 content and/or characteristics of those messages when the icons are selected by a user 3320, whereby future emails are routed to appropriate folders for and/or in accordance 16 with rule application 3325. For example, if the selectable icon is selected by a user for 17 an email message having a PDF message attachment, the HUB may automatically 18 generate a rule for transferring all email messages having PDF messages to a designated 19 folder. In another implementation, the HUB may evaluate and employ message content in the automatically generated rule (e.g., the HUB may discern an email message sender 21 and generate a rule whereby all email messages from that sender are transferred to a 22 specified folder). In another implementation, the HUB may evaluate and employ 23 message content in the automatically generated rule (e.g., the HUB may discern that an 24 email pertains to a specific property, specific tenant, or is within a defined proximity 1 [e.g., mileage radius] of a property, and may generate one or more rules and/or sub-2 rules whereby all email messages from that sender are transferred to a specified folder 3 and/or sub-folders). In one implementation, automatically generated rules may be 4 displayed as prospective rules to a user, who may be allowed to accept, reject, modify, and/or the like. In one implementation, multiple selectable icons, flags, and/or the like 6 may be provided with email messages, allowing a user to specify different rules to be 7 applied to those messages and/or folders to which those messages should be routed 8 and/or copied.

9 [001681 FIGURE 34 shows an implementation of logic flow for one-button rule 1o generation in one embodiment of HUB operation. In one implementation, Fig.
34 may 11 represent an elaboration and/or extension of box 3320 in Fig. 33.
Selectable icons, 12 and/or the like interface elements, may be provided for display with email messages, 13 such as by an email client application 3401. In one implementation, multiple icons may 14 be displayed, such as may correspond to different email rules, different email folders and/or subfolders, and/or the like. A determination may be made as to whether the 16 icon has been selected 3405. When it has, the selected icon may be correlated with a 17 folder 3410, such as by correlating it with the sole folder to which all selected emails are 18 directed, correlating it with a folder to which the particular selected icons of multiple 19 icons corresponds (e.g., in an icon data record), providing a selectable list of possible folders for display to the user, and/or the like. The HUB may then extract and parse 21 email data 3415, such as email message content data, sender data, addressee data, data 22 as to whether a link or attachment is present, email attachment data, linked data, 23 and/or the like. A determination may be made as to whether sufficient data has been or 24 can be extracted 3420. For example, a comparison may be made of extracted data with 1 rule generation criteria, such as an amount of extracted data, available types of data, 2 and/or the like. If the amount of data is insufficient at 3420, then an error handling 3 procedure may be undertaken 3425, such as providing an error message to the user, 4 denying rule generation, requesting manual entry of rule parameters, and/or the like.
Otherwise, if sufficient data exists, then one or more prospective and/or candidate rules 6 may be generated based on the extracted and parsed email data and provided for display 7 to the user. In one implementation, rules of varying specificity may be generated and 8 provided on a sorted basis (e.g., order of increasing number of rule parameters) for 9 display to a user. The user may then be requested to accept, reject, modify, and/or the io like displayed candidate rules. A determination may be made as to whether the rule is ii accepted by the user 3435, such as based on the receipt of an acceptance action by the 12 user (e.g., clicking an "I accept" button, and/or the like). If acceptable, then the rule 13 may be added to other email rules for future application to qualifying emails 3440. If 14 not acceptable, in one implementation, the HUB may presume the rule has been rejected and may return to 3401. In another implementation, the user may be provided 16 with an opportunity to manually modify the candidate rule.

17 [ o 016 9 ] FIGURE 35 shows an implementation of logic flow for summary screen 18 interactions in one embodiment of HUB operation. In one implementation, the flow in 19 Fig. 35 references aspects of the user interfaces shown in Figs. 36A-B and Figs. 37A-B.
Once a summary screen has been generated, displaying summary data associated with 21 received email and/or other messages, a user may be permitted to interact with the 22 summary screen to retrieve original message data, evaluate received messages and/or 23 message data, generate response messages, and/or the like. An email summary may be 24 provided to the user 3501, and a user interaction with an element of the summary 1 message may be received 3505. That interaction may take a variety of forms in various 2 implementations. For example, the user may click on and/or mouseover a slice of a 3 displayed pie chart, a point and/or segment of a line graph, a category listing, a PDF
4 link, and/or the like 3505. The HUB may then open a category listing screen based on the user interaction 3510 and provide that screen for display 3515. In one 6 implementation, the category listing screen may take a form similar to the examples 7 shown in Fig. 36B and/or Fig. 37B. The HUB may then receive user input of one or a more message response triggers 3520, such as may be associated with one or a sub-9 group of messages, may represent a "gut feel" or other evaluation of the messages in the 1o category listing screen, and/or the like. A determination may be made as to whether the 11 message response trigger is an inbox trigger 3525, which may indicate that the 12 associated message is to be directed to the user's regular inbox folder instead of to any 13 other particular folder to which it may have been previously designated or directed. If 14 the trigger is determined at 3525 to be an inbox trigger, then the email message may be sent back to the user's inbox 3530. If not an inbox trigger, then, in one implementation, 16 the HUB may presume the trigger to be an auto-text generation trigger, and may 17 generate auto-text in association with the emails based on the received trigger 3535. For 18 example, in one implementation, the message response trigger may comprise a "gut 19 feel" indicator, which may take any of several values (e.g., green, yellow, red, and/or the like) which may correspond respectively to several automatic text outputs (e.g., "We are 21 interested in the property. Please contact us," "This could be a possibility, but will have 22 to be reviewed further," "We're sorry, but we're not in the market for that type of 23 property now. Thanks," and/or the like). In one implementation, the user may enter 24 text manually in addition to and/or instead of automatically generated text. The HUB

1 may then receive a send command from the user 3540, and may send response 2 messages including the auto-generated text to the message senders 3545. In one 3 implementation, a user may send response on an individual message basis while, in 4 another implementation, multiple response messages may be sent on a batch basis. A
determination may be made as to whether additional message interactions are desired 6 3550 and, if so, the flow may return to 3501. Otherwise, the flow may conclude 3555.
71001701 In one implementation, a user-specified message response trigger may 8 cause a corresponding message to be copied, forwarded, transferred, and/or the like to s one or more contacts, such as those in a user's list of contact, where those contacts may 1o be selected based on categories and/or subcategories correlated with message data 11 elements. In another implementation, a greater target set may be specified allowing the 12 message to be provided to a broader list of recipients beyond a user's contact list (e.g., 13 all HUB users, all users associated with a given office, all users for a given region, all 14 users in a given department, and/or the like). In one example, if a user who is a tenant broker receives a message including a flyer for an available property that is correlated 16 with the city of Schaumberg, the property type of storefront, and the price of 17 $6ooo/mo., and the user specifies a gut feel indicator value of green for that message, 18 the message may automatically be sent to all tenant clients associated with the tenant 19 broker user having contact records indicating interest in properties matching those categories and/or subcategories. In another example, if a user who is a landlord broker 21 receives a message indicating desired property attributes that is correlated with the city 22 of Schaumberg, the property type of storefront, and the price of $6ooo/mo., and the 23 user specifies a gut feel indicator value of green for that message, the message may 24 automatically be sent to all landlord clients associated with the landlord broker user 1 having contact records indicating available properties matching those categories and/or 2 subcategories. Thus, the HUB may be configured to utilize its store of message data, 3 property flyer information, and/or the like to notify, alert, and send messages, message 4 data, property flyers, and/or the like to all parties to create an efficient marketplace and/or bidding system for the exchange and/or transaction of those properties.

6 1001711 In another implementation, a message response trigger specified by a 7 message recipient may cause a corresponding message to be re-sent, copied, forwarded, 8 transferred, and/or the like to other recipients by an original sender, where the 9 additional recipients may be selected based on categories and/or sub-categories 1o correlated with message data elements. For example, if one or more message recipients 11 who are tenant brokers enter positive message response trigger values, such as green 12 gut-feel indicator values, for a given message and/or that message's associated property 13 data, that message may be sent on behalf of the message-originating landlord broker 14 and/or landlord client to other recipients, such as further tenant brokers, tenant clients, and/or the like matching message correlated categories and/or sub-categories.
In 16 another example, if one or more message recipients who are landlord brokers enter 17 positive message response trigger values, such as green gut-feel indicator values, for a 18 given message and/or that message's associated property data, that message may be 19 sent on behalf of the message-originating tenant broker and/or tenant client to other recipients, such as further landlord brokers, landlord clients, and/or the like matching 21 message correlated categories and/or sub-categories. In one implementation, further 22 message recipients may be limited to a message originator's contact list while, in 23 another implementation, further message recipients may be drawn broadly from all 24 HUB users, and/or subsets of HUB users sharing particular characteristics (e.g., 1 company, region, department, and/or the like). Provision of property messages with 2 positive message response trigger value inputs to further recipients may, in one 3 implementation, facilitate an efficient market for property and/or allow message 4 originators to obtain the best deals in association with property transactions.

100172] FIGURES 36A-B show implementations of summary screen user 6 interfaces in one embodiment of HUB operation. Data associated with user messages 7 may be provided in a selectable list 3601 in proximity with a summary display 3605, 8 configured in the displayed implementation as a rolodex similar to the examples 9 discussed above for display of contact information. Here, the rolodex includes four io categories of data (company, property type, state, county) which may be associated with 11 received email messages and/or information contained in attachments and/or 12 embedded links thereof. For each category, subcategories of information are displayed 13 with numbers reflecting the number of messages received in a period of time that are 14 correlated with that subcategory. The selectable list of messages 3601 may comprise a variety of information associated with and/or extracted from the message data, such as 16 sender information 3610; a date that the message was sent and/or received 3615; a 17 subject line, first message line, and/or other message content data 3620;
and a size of 18 the message and/or any files embedded therein and/or attached thereto 3625.
The 19 illustrated implementation may further include a selectable icon 3630 allowing a user to access one or more attached files, PDFs, and/or the like associated with, attached to, 21 embedded within, and/or linked by each message. The illustrated implementation may 22 further include an indicator 3635 configured to show whether a given message and/or 23 associated linked, attached, embedded, and/or the like data is a duplicate of data 24 previously received, and/or to display any prior message response trigger values, gut 1 indicator values, and/or the like that a user may have specified in association with a 2 particular message. The indicator may, for example, display red when a message is 3 received having sufficiently similar characteristics to a prior message, and display green 4 otherwise. In another implementation, the indicator may display a check mark when a message is received having sufficiently similar characteristics to a prior message, and 6 may display a value of a message response trigger, gut feel indicator (e.g., green, yellow, 7 red, and/or the like), and/or the like that a user may have previously set for a prior 8 message that is matched to the current message. In one implementation, the interface 9 may further include a button or other such interface facility configured to automatically io generate one or more email allocation rules based on characteristics of selected emails, ii such as in accordance with the flow shown in Fig. 34.

121001731 Selection of a category and/or subcategory of messages from a summary 13 message, such as the rolodex display at 3605 in Fig. 36A, may, in one implementation, 14 yield an interface similar to the example shown in Fig. 36B. Here, again, a summary message area may be shown, which may in one implementation be configured as a 16 rolodex display 3605. The interface may further include a selectable listing of messages 17 3640, where each message is associated with the subcategory selection discussed above.
18 In the displayed implementation, the selected category and subcategory reflect a 19 particular company name 3645. The listing may display other aspects and/or facets of message data, data contained in message attachments, embedded and/or linked files, 21 and/or the like. For example, in an implementation where message data is associated 22 with real estate properties, the further information may include, but it not limited to:
23 property city 3650, property county 3655, property state 3660, property area (e.g., 24 square footage) 3665, property type 3670, and/or the like. In various implementations, 1 displayed message data, such as that shown at 3645, 3650, 3655, 3660, 3665, and 3670, 2 and/or other message display features may be modifiable and/or customizable by a user 3 to suit particular display needs, preferences, and/or the like. The listing may further 4 include a selectable element 3675 by which a user may open an attached file, such as a PDF, for viewing. In one implementation, the interface may further include a message 6 response trigger facility, such as a gut feel indicator 3680, by which a user may register a 7 reaction, impression, assessment, evaluation, and/or the like in association with each 8 message and/or a group of messages. For example, in the illustrated implementation, a 9 gut feel indicator may be set by the user, with values of either green, yellow or red. In one implementation, a selected message response trigger, gut feel indicator value, 11 and/or the like may be stored in association with a corresponding message, message 12 attachment, message link, message data, and/or the like. In one implementation, 13 selection of a particular message response trigger, gut feel indicator, and/or the like may 14 trigger the generation of an automatic text response, such as that shown at 3685, which may then be sent to the message originator, such as by pressing a send button 369o. In 16 one implementation, a user may supplement, modify, and/or replace auto-generated 17 text prior to sending. In one implementation, a plurality of messages, such as may be 18 selected as a group, may be sent together with a single user action (e.g., desired 19 messages are selected, auto-text is generated for them, and the user may then select a "send all" button).

21 [o O i 74 ] FIGURES 37A-B show implementations of summary screen user interfaces 22 in another embodiment of HUB operation. In addition to message summary rolodex 23 and selectable message listing areas, the implementation shown in Fig. 37A
also 24 includes a dashboard interface element comprising a pie-chart 3701, which may reflect 1 the relative proportions of messages allocated to different subcategories within an 2 overall category. The overall category may then be selected to view different dashboard 3 elements, add more dashboard elements, and/or the like, such as by the category 4 selection pull-down menu at _3705. In various implementations, a wide variety of other dashboard elements may be employed and/or configured within embodiments of HUB
6 operation, such as but not limited to: bar graphs, histograms, line charts, timelines, 7 cartograms, area charts, bubble charts, scatterplots, and/or the like. In one 8 implementation, components of displayed dashboard elements may be selectable to 9 show messages associated with those components. For example, in the illustrated to implementation, a user may click on a wedge of the displayed pie chart 3701 in order to 11 see a listing of messages corresponding to the category and/or subcategory associated 12 wit the selected wedge. Fig. 37 A also includes a key 3708 for a duplication indicator 13 similar to the example shown at 3635 in Fig. 36A, where the indicator may display a 14 check mark when a message is received having sufficiently similar characteristics to a prior message, and may display a value of a message response trigger, gut feel indicator 16 (e.g., green, yellow, red, and/or the like), and/or the like that a user may have previously 17 set for a prior message that is matched to the current message. Fig. 37B
shows an 18 implementation of such a selectable listing of messages 3710. The illustrated io implementation further includes a selectable icon for previewing an email in the list 3715, selection of which may trigger generation and/or display of a summary, 21 abridgment, and/or the like of a corresponding email message. The illustrated 22 implementation further includes selectable elements 3720 whereby a user may specify a 23 mode of communication by which a response, such as an auto-generated response 1 string, may be relayed to a message originator, such as may include email, instant 2 message, phone call, audio message, postal mail, web comment, and/or the like.

3 100175] FIGURE 38 shows an implementation of logic flow for summary screen 4 generation in one embodiment of HUB operation. A flow similar to that shown in the example of Fig. 38 may be employed by embodiments of the HUB to generate summary 6 messages, rolodexes, dashboards, and/or the like and/or the analytics, statistics, 7 industry trends, and/or the like underlying those displays. Message element data may 8 be discerned 3801, such as in accordance with the scraping and/or parsing analyses 9 discussed above. Those elements may then be correlated with data categories, subcategories, and/or the like 3805, such as based on rules and/or sub-rules similar to 11 the examples shown in the table in Fig. 32B and/or the associated XML rules discussed 12 above in one implementation. Thus, for example, a city name in an attached real estate 13 property flyer may be recognized based on HUB rules and correlated with the "city"
14 category and the sub-category corresponding to that particular city. In one implementation, the HUB may further add in value-add elements, categories, sub-16 categories and/or the like that are associated with message data elements 3803, such as 17 by querying a database of value-add elements based on message data elements 18 discerned at 3801. For example, the HUB may query a county name based on city 19 and/or state information extracted from a message and/or message data that does not itself include the county information. A wide variety of other value-add information 21 may be queried based on data retrieved from an analyzed message, such as but not 22 limited to: city, county, latitude, longitude, global positioning system coordinates, 23 demographic information, mapping system map links (e.g., Google Maps, Bing Maps, 24 and/or the like). In one implementation, a first query may be conducted based on extracted message data elements, and then a second, third, and/or further query may be 2 made based on value-add elements, categories, subcategories, and/or the like retrieved 3 in response to a prior query. A determination may be made as to whether a category, 4 sub-category, and/or the like exists for a particular message data element, value-add element, and/or the like. In one implementation, if no category, sub-category, and/or 6 the like exists to accommodate the element, then an error handling procedure may be 7 undertaken, such as to ignore the element. In another implementation, if no category, 8 sub-category, and/or the like exists to accommodate the element, and new category, 9 sub-category, and/or the like may be generated based on the discerned element 3815.
io Once categories are correlated with message data elements, counters for those 11 categories may be incremented 3820, such as to track the number of messages having 12 data elements correlated to those categories. For example, if ten messages arrive in a set 13 period of time and five of those messages include data elements identifiable as 14 correlated with the city of Chicago, IL, then a counter corresponding to the Chicago subcategory of the city category would be at five. Counter statistics may then be 16 updated 3825. A wide variety of different counter statistics, analytics, and/or the like 17 may be tracked in various implementations, such as but not limited to: mean value in a 18 given period, average value in a given period, median value in a given period, variance 19 and/or standard deviation in a given period, percentage and/or relative value, frequency and/or rate, and/or the like. The HUB may then generate a summary message, such as 21 a rolodex display, dashboard elements, time-resolved message volume plots, and/or the 22 like based on the counter statistics 3830. In one implementation, the HUB
may access 23 other HUB data, such as user contact data, property data, and/or the like for analysis in 24 conjunction with message data and/or correlated categories, and/or for inclusion in the 1 summary message 3830. Counter values, statistics, message data elements, correlated 2 category records, and/or the like may be stored for later access and/or retrieval 3830.

3 [o o i 76 ] FIGURES 39A-C show implementations of user interface for time-resolved 4 summary screen elements in one embodiment of HUB operation. An interface similar to that shown in the examples of Figs. 39A-C may be employed by HUB
embodiments to 6 show time-resolved message volume information, analytics, and/or the like.
For 7 example, the illustrated implementation shows a plot 3901 of message volume by city 8 3905 as a function of time 3910, reflecting, for example, the number of messages 9 received by a user that the HUB has correlated with particular cities over time. In the 1o illustrated implementation, plots 3915 are displayed for three cities:
Calumet City, 11 Schaumberg and Glenwood. The plotted information may further include one or more 12 icons 3920 indicative of other HUB data, such as the location in time of a message from 13 a user's contact associated with the plotted city, or other category and/or subcategory.
14 For example, in the illustrated implementation, icons are shown 3920 indicating messages from contacts Joe, Pete, and two others. The interface may further include 16 interface elements, such as pull-down menus, allowing a user to adjust plotted 17 categories 3925 (e.g., the data plotted on the ordinate axis 3905), other plot options 18 3930, revert to a rolodex view 3935, revert to a dashboard view 3940, and/or the like.
19 In one implementation, the figure may further include contact listings 3945, selectable message listings, and/or the like to facilitate communications based on displayed data.
21 Fig. 39B shows further aspects of a plot category pull-down menu 3950, where a user 22 may select other data categories for plotting against time (e.g., state, county, company, 23 agent, price, message type, property type, property characteristics, and/or the like), and 24 of plot options 3955, where a user may select options to change plot characteristics (e.g., 1 change scale, change offset, change axes, add plots, remove plots, change plot style, 2 extract analytics, extract numerical data, and/or the like). Fig. 39C shows further 3 aspects of the interface of Fig. 39A, in one implementation, where a user may click 4 and/or mouse-over a plot icon such as that shown at 3920 to be shown a menu with further options for interacting with that icon and/or underlying data. For example, in 6 the illustrated implementation, a pop-up menu 3960 may be displayed to allow a user to 7 perform one or more actions related to a contact associated with the displayed icon, 8 such as but not limited to: view contact information and/or a contact profile; view a 9 message from the contact; send a new message to the contact; view recent HUB
activity 1o related to the contact; populate a HUB display, such as a bifurcated display area, with 11 property information associated with the icon and/or with the contact; show the 12 associated property information on a map; show other properties associated with the 13 contact; and/or the like.

14 100177] FIGURE 40 shows an implementation of logic flow for tracking user message response analytics in one embodiment of HUB operation. In one 16 implementation, the HUB may employ a flow similar to the example shown in Fig. 40 17 for generating, displaying, storing, publishing, and/or the like message analytics and/or 18 analytics associated with message data, user response triggers to message data, and/or 19 the like. The HUB may receive user message response triggers from one or more users 4001 and aggregate received triggers in correlation with message data elements and/or 21 associated categories 4005. Thus, for example, in one implementation, the HUB may 22 track the number of green gut feel indicators, yellow gut feel indicators, and red gut feel 23 indicators that have been received for messages having real estate property flyers for the 24 city of Schaumberg. Any other type of message trigger indicator value may be tracked 1 for any other type of message data element, category, sub-category, and/or the like. A
2 determination may be made as to whether analytics associated with aggregated user 3 message response triggers are to be updated 4010. For example, in one 4 implementation, such a determination may be made based on inspection of a clock, to determine whether an update time has been reached. If analytics are not to be updated 6 at 4010, then the HUB may wait for a period of time 4015 and/or continue to receive 7 and/or aggregate user message response triggers. If analytics are to be updated, the 8 HUB may analyze aggregated user message response triggers to generate trigger s statistics, analytics, and/or the like 4020. For example, in one implementation, based io on the aggregate gut-feel indicators for various real estate property categories, the HUB
11 may discern a relative desirability of different aspects of real estate.
Generated statistics 12 and/or analytics may be stored 4025 and a determination may be made as to whether or 13 not those statistics and/or analytics are to be published 4030. Such a determination 14 may be made based on the nature of the statistics and/or analytics, inspection of a publication schedule, and/or the like. If no publication is to occur at 4030, the HUB
16 may return to 4001 and continue receiving and/or aggregating user message response 17 triggers. Otherwise, the HUB may generate a publication of statistics and/or analytics, 18 such as by providing them for display for free and/or on a fee and/or subscription basis, 19 such as via a website, newsletter, email list, data feed, and/or the like.
A determination may be made as to whether or not to continue receiving and analyzing user message 21 response triggers 4040 and, if so, the flow may return to 4001. Otherwise, the flow may 22 conclude 4045.

23 1001781 FIGURE 41 shows an implementation of logic flow for message display 24 prioritization in one embodiment of HUB operation. In one implementation, the HUB

1 may employ a flow similar to the example shown in Fig. 41 for implementing prioritized 2 placement of messages and/or associated message content in HUB-generated message 3 summary displays, message listings, rolodexes, dashboards, and/or the like.
A new 4 message may be received 4101, analyzed and/or processed for correlation of message data elements with one or more categories and/or sub-categories 4105, and message 6 categorization statistics and/or analytics may be updated 4115, such as in accordance 7 with the embodiments and implementations discussed previously. A
determination 8 may then be made as to whether the user from which the message was received (e.g., the 9 message originator) has paid 4120. For example, a user may pay a premium amount in order to be granted priority placement of his or her messages in summary messages, 11 message listings, and/or the like provided by the HUB to message recipients. In one 12 implementation, a user may specify and/or such payment may be tied to a period of 13 time during which the user's messages will receive priority placement, a number of 14 messages for which priority placement is effectuated, and/or the like. The determination at 4120 may be made, for example, by inspection of a user profile record, 16 priority account record, and/or the like. If no payment has been received from the user, 17 then the message may be configured for ordinary and/or usual placement in a summary 18 message, message listing, and/or the like 4125 (e.g., such as may be sorted according to 1s some objective basis and/or criteria). If, however, the HUB recognizes payment from the user, a determination may be made as to whether a priority placement period has 21 expired 4130, such as by checking a payment date against a current date in relation to a 22 defined priority period. In another implementation, instead of and/or in addition to 23 checking for expiration of a priority placement period, the HUB may check a number of 24 previous priority-placed messages in relation to a limit to determine if all available 1 priority placements have already occurred, or if the present message should also receive 2 priority placement. If the period has expired, a message may be provided to the user, in 3 one implementation, explaining that the priority period has expired 4135, and the 4 message may be configured for ordinary placement 4125. If the priority period has not expired at 4130, then a determination may be made as to whether a conflict exists with 6 another user's priority placement 4140. If not, then the message may be configured for 7 priority placement in summary messages, message listings, dashboards, rolodex 8 displays, and/or the like of message recipients 4145. For example, in one s implementation, the message may be placed at or near the top of a message listing. In io other implementations, the message and/or message data elements, correlated ii categories and/or sub-categories, and/or the like may be provided for prominent 12 display, highlighted, flashing, bolded, underlined, placed in a central position in the 13 display screen, and/or the like. If a conflict exists at 4140, then a conflict resolution 14 procedure may be undertaken, such as implementing a priority hierarchy based on amount paid, order in time the amount was paid, user history, user characteristics, 16 target characteristics and/or relationship with the user, and/or the like.
In one 17 implementation, when a conflict exists, the HUB may implement a bidding system 4150, 18 such as by soliciting bids from the conflicting users and providing highest priority 19 placement to the user or users providing the highest bid amounts. For example, a determination may be made as to whether a particular user has won the bidding session, 21 such as by providing the highest bid and, if so, that user's messages may receive the 22 highest priority placement 4145. Otherwise, they may be configured for ordinary 23 placement 4125, lower priority placement, and/or the like.

1 100179] FIGURE 42 shows an implementation of logic flow for code capture 2 information retrieval and processing in one embodiment of HUB operation. In one 3 implementation, the HUB may employ a flow similar to that shown in the example of 4 Fig. 42 for aggregating, processing, analyzing, and/or the like information associated with barcodes and/or other codes captured, imaged, scanned, and/or the like by user 6 mobile devices. A code may be captured by a user 4201, such as, for example, a barcode, 7 2D matrix code, steganographic image, and/or the like provided in association with a 8 real estate property, other property, and/or the like. A query may then be performed to 9 retrieve information based on the captured code 4205, and a determination may be 1o made as to whether any information was retrievable by that query 4210. If not, an error 11 handling procedure may be undertaken 4215, such as to ignore the code capture, 12 provide a message to the user, and/or the like. If matching information is found at 13 4210, then the retrieved information and/or access thereto may be provided to the HUB
14 4220, which may scrape and/or parse data therefrom into one or more data fields 4225 in order to correlate the received information with one or more categories and/or sub-16 categories. A summary message may then be generated based on the correlated 17 categories and/or subcategories, and may include a further characteristic field 18 indicating the origin of the data as being associated with code captures, as opposed to 19 messages 4230. The summary message may then be provided for user display, such as via an email client, mobile application, web page, and/or the like 4235. In one 21 implementation, real estate property information aggregated as a result of code captures 22 may form the basis of a real-estate listing service.

23 [00180] In embodiments, the HUB may be configured to facilitate transaction 24 and/or exchange of lead information, such as contact information, real estate site drives, i market comparables, marketing ideas, calendar time, and/or the like. The HUB
may 2 engender a tailored and efficient forum for coordinating transactions of lead 3 information based on a centralized database of contacts and other lead and/or market 4 information associated with and/or belonging to users. In one embodiment, users may submit lead requests comprising parameters and/or criteria based on which one or 6 more queries may be performed on that database. Other users having leads matching 7 the request may then be notified and may decide whether to share their lead 8 information with the requesting user. In one implementation, users may include a 9 bounty or other user-specified offer price with their lead request, which bounty may be 1o provided to a lead owner and/or provider upon transfer of the requested lead 11 information. In one implementation, a lead provider may also set a bounty, minimum 12 payment amount, and/or the like to act as a required price, target price, threshold price, 13 and/or the like for the sharing of lead information. In some implementations, lead 14 requestors may submit lead quality rating scores and/or the like subsequent to receiving lead information, which may assist future requestors in selecting the lead providers with 16 whom they wish to engage in transactions. For example. lead requestors may be able to 17 view such lead quality scores and/or ratings for candidate lead providers and/or leads to 18 determine which are the most desirable to pursue and/or to pay a bounty for.

19 [00181] In one implementation, the HUB may facilitate transactions based on contact information, such as from one broker to another, from a broker to a retailer or 21 other interested party, and/or the like. In another implementation, the HUB
may 22 facilitate direct contact between HUB users, such as facilitating transactions based on 23 calendar time, such as from one retailer to another, from one retailer to a broker, and/or 24 the like. For example, in such an implementation, a retailer may receive a message 1 requesting access to the retailer's time (e.g., for a call, to schedule a meeting, 2 videoconference, and/or the like) in exchange for a bounty price. In the context of 3 commercial real estate implementations, commercial real estate professionals seeking to 4 maximize the return on their time and efforts (which, after all, are often directed towards earning commissions) may employ the HUB to engage retailers to receive quick 6 feedback on properties being marketed. The HUB may facilitate an incentive structure 7 for retailers to share their time with brokers, such as to provide this kind of feedback on 8 marketed properties, in exchange for the payment of an agreed-upon bounty.
Similarly, 9 the broker, who also has limited time and is interested in receiving the greatest return io on time invested, receives some assurance that the exchange will be of some value.
11 Therefore, the retailer or professional representing the retailer may be able to stipulate 12 the value of his time, and the professional representing the property may decide 13 whether or not it is worth it to him to pay for a scheduled amount of that time.

14 [ 0 018 21 FIGURE 43 shows an implementation of logic flow for lead exchange in one embodiment of HUB operation. A HUB user may act as a requestor, and submit a 16 request for lead information to the HUB 4301. In various implementations, lead 17 information may comprise contact information (e.g., name, electronic address, postal 18 and/or business address, business and/or personal telephone numbers, instant 19 messaging address, user identifier within an online service, contact authorization, and/or the like), site drive information, marketing ideas, notes, and/or any other 21 community-sourced and/or user generated and/or controlled information. In one 22 implementation, the request may further include bounty, payment offer, contingent 23 payment offer, and/or the like, reflecting an amount of compensation that the requestor 24 is willing to pay in exchange for the requested lead information. In one implementation, 1 the bounty may be a fixed sum of money. In another implementation, the bounty may 2 be a percentage of an expected future transaction amount (e.g., the sale or lease of real 3 estate) for a transaction associated with the lead request. In one implementation, a lead 4 request may include a requestor payment account identifier (e.g., a credit card number, bank account number, online payment facilitation service number, and/or the like) and s any associated authorization information to allow the HUB to automatically deduct an 7 amount upon successful consummation and/or fulfillment of the lead request.
In one 8 implementation, the HUB may transfer a bounty amount into a escrow account prior to 9 consummation and/or fulfillment of the lead request, and then transfer that amount to from the escrow account into a lead provider account upon consummation and/or ii fulfillment, as described below. In one implementation, a service fee or other 12 percentage of the bounty may be levied by the HUB for completed transactions. In one 13 implementation, such a service fee may be deducted from the bounty prior to payment 14 to the lead provider while, in another implementation, such a fee may be deducted from a lead requestor account in addition to the bounty amount.

16 [00183] In one implementation, the request may further include any of a variety of 17 lead identifying criteria, based on which the HUB may perform one or more queries to 18 retrieve information pertinent to the lead request. For example, a user may specify a 19 property identifier, location, contact name, contact role and/or title, and/or the like.
The HUB may then perform a query on HUB users and/or associated user lead 21 information based on the lead criteria provided in the request 4305. In one 22 implementation, the query may further be based on a bounty or other payment amount 23 specified in the lead request, whereby only lead providers having minimum 24 compensation requirements less than the lead requestor's specified bounty are returned 1 in response to the query. In one implementation, such a minimum compensation 2 amount may be set by the lead provider and/or may be based in whole or in part on a 3 quality rating associated with the lead provider. In one implementation, only lead 4 providers who have opted in to a lead sharing service may be included in the query at 4305. In another implementation, all users may be included in the query at 4305, and a 6 subsequent extraction of users who have opted in may then be performed. A
7 determination may be made as to whether, in response to the query 4310, one or more 8 HUB lead providers can be found having associated leads matching the query.
If not, 9 then an error handling procedure may be undertaken 4315, such as providing an error 1o message to the lead requestor, requesting reentry of lead criteria parameters, and/or the 11 like. If one or more matches are found, the HUB may provide each matching user with a 12 message requesting acceptance of the user contact request and/or authorization to 13 release further information about the available lead to the requestor 4320.
A
14 determination may then be made as to whether at least one acceptance has been received in response to the notice message at 4320 and, if not, then an error handling 16 procedure may be undertaken 4315, such as notifying the requestor of the lack of 17 acceptances, notifying the requestor of the number of rejections, requesting reentry of 18 lead criteria, and/or the like. If at least one acceptance is received at 4325, the HUB
19 may provide a selectable list of matching lead provider and/or lead information (e.g., broker names, titles, prices and/or premiums, redacted lead information, and/or the 21 like) for selectable display to the requesting user 4330. In one implementation, the 22 HUB may sort matches prior to displaying them to the requestor 4335.
Sorting may be 23 based on any one or combination of a variety of different sort criteria in various 24 implementations. For example, the HUB may order match results based on alphabetical i order; a lead provider quality rating; order in which acceptances were submitted and/or 2 received; match quality relative to lead criteria; a difference between a proposed and an 3 expected or required payment amount for provision of the requested lead;
participation 4 and/or status in a priority-placement program (e.g., a user may pay a premium in order to receive priority placement in such lists); and/or the like.

6 [00184] The HUB may receive a selection of one or more entries in the selectable 7 list from the requesting user 4340. Lead information (e.g., such as contact information) 8 associated with those entries may then be provided to the requesting user, and a 9 payment may be effectuated to the one or more users (e.g., brokers) who own, control, 1o provide, and/or are otherwise associated with the provided lead information 4345. In ii some implementations, access may be provided to the requested lead information via an 12 email message, an instant message, web page access (e.g., permanent access, access for a 13 set period of time, and/or the like), and/or the like. In one implementation, where the 14 bounty and/or proposed payment included in the lead request is contingent on the outcome of a future transaction, the HUB may further monitor the outcome of that 16 transaction and only effectuate payment upon receipt of an indication of successful 17 consummation thereof. For example, where the bounty is specified as a percentage of 18 an expected transaction amount, the HUB may withhold payment until receipt of an 19 authorized indication (e.g., entry by a HUB administrator) of a transaction amount for the associated transaction, at which time the appropriate payment amount may be 21 determined and effectuated. In one implementation, a service fee may be deducted 22 from and/or added to the payment amount, and a net payment effectuated between the 23 lead requestor and lead provider. In another implementation, a fee payment may be 24 made based on the type of associated transaction (e.g., full payment being due at the 1 time of a closing on a property sale; partial payment being due upon execution of a lease 2 with remainder of payment being due upon tenant doors opening for business;
and/or 3 the like).

4 100185] The HUB may then receive a lead quality score from the requesting user 4350, such as may reflect a perceived quality associated with the received lead 6 information. Any of a variety of lead ratings may be employed in different 7 implementations of the HUB, such as but not limited to numerical scores, radio-button 8 ratings, "like" buttons, thumbs-up and/or thumbs-down ratings, and/or the like. A lead s quality score associated with the owner, originator, controller, and/or the like of the lead may then be updated based on the received lead quality score 4355.

11 [ O o 18 61 FIGURE 44 shows an implementation of logic flow for lead exchange in 12 another embodiment of HUB operation. A lead request, such as one similar to that 13 shown at 4301 in Fig. 43, may be received from and/or broadcast by a requesting user 14 4401, and a query may be performed to find one or more lead sources, associated users, and/or the like matching specified criteria provided and/or associated with the received 16 request 4401. In one implementation, the queried database source may, by default, 17 include and/or be filtered to access only those users, lead providers, and/or the like who 18 have opted in to participate in the lead sharing program. A determination may be made 19 as to whether any matches exist 4410 and, if not, then an error handling procedure may be undertaken 4415, such as notifying the requestor of the lack of acceptances, notifying 21 the requestor of the number of rejections, requesting reentry of lead criteria, and/or the 22 like. If a match exists at 4410, the HUB may provide a selectable list of matches, such as 23 user (e.g., broker) names, titles, prices and/or premiums, redacted lead information, i and/or the like for selectable display to the requesting user 4425. In one 2 implementation, a determination may be made as to whether there are multiple matches 3 in response to the query 4420 and, if not, then the single match may be provided at 4 4425. If multiple matches are determined to exist at 4420, those may be sorted based on any one or combination of a variety of different sort criteria in various 6 implementations, such as based on alphabetical order; a user quality rating;
match 7 quality relative to lead criteria; a difference between a proposed and an expected or s required payment amount for provision of the requested lead; participation and/or 9 status in a priority-placement program (e.g., a user may pay a premium in order to io receive priority placement in such lists); and/or the like. The HUB may receive selection 11 of one or more entries in the selectable list from the requesting user 4435 and may 12 generate a lead sharing request message to be sent to one or more users (e.g., brokers) 13 selected at 4435 to request authorization to share the requested information 4440. A
14 determination may be made as to whether any acceptances are received 4445 and, if not, then an error handling procedure may be undertaken 4450, such as providing an error 16 message to the requesting user, requesting re-selection, and/or the like.
If at least one 17 acceptance is received, lead information (e.g., contact information) may be provided to 18 the requesting user, and payment may be effectuated for the user owning, controlling, 19 and/or otherwise associated with the provided lead information 4455. The HUB may then receive a lead quality score from the requesting user 4460, such as may reflect a 21 perceived quality associated with the received lead information. Any of a variety of lead 22 ratings may be employed in different implementations of the HUB, such as but not 23 limited to numerical scores, radio-button ratings, "like" buttons, thumbs-up and/or 24 thumbs-down ratings, and/or the like. A lead quality score associated with the owner, 1 originator, controller, and/or the like of the lead may then be updated based on the 2 received lead quality score 4465.

3 [00187] FIGURE 45 shows an implementation of logic flow for lead exchange in 4 another implementation of HUB operation. A requestor may submit lead (e.g., contact) search terms, such as a contact name, location, business affiliation, title, price range, 6 transactional status, and/or the like 4501, and the HUB may perform a query of user 7 records based thereon 4505. A determination may be made as to whether a user with 8 matching lead information exists 4510 and, if not, then an error handling procedure 9 may be undertaken 4515, such as providing an error message to the user, requesting to reentry of search terms, and/or the like. If a match exists at 4510, then the HUB may ii generate and/or provide abridged and/or redacted lead information for display to the 12 requesting user. For example, if the user has requested to be provided with contact 13 information matching specified criteria (e.g., for a broker in Peoria, IL
with landlord 14 clients in suburban commercial real estate), the HUB may provide only a subset of the contact information, such as one or more of a title, letters of a name, an affiliated 16 company, general and/or granular location information, property attributes, and/or the 17 like. The HUB may then receive a selection of one or more entries in the list of redacted 18 list information 4525 from the requesting user. A determination may be made as to 19 whether the requesting user is authorized for permission-based access to the selected information 4530, such as, for example, if the owner and/or controller of that 21 information has specified an identifier associated with the requesting user as part of an 22 authorized list of users for the requested lead information. If permission based access is 23 authorized, then the lead information may be provided to the requesting user and, in 24 one implementation, a payment effectuated to the lead providing user (e.g., broker) 1 4555. A wide variety of different payment mechanisms, methods, offerings, and/or the 2 like may be employed in different embodiments of HUB operation, such as, but not 3 limited to, credit card payments, cash exchanges, promissory notes and/or contracts, 4 payment facilitation services (e.g., PayPal), virtual currency facilities, contingency fee arrangements, lead trading or other bartering, and/or the like.

6 [ o o 18 8 ] If there is no permission-based access authorized at 4530, a determination 7 may be made as to whether the one or more users associated with the selected lead 8 information have opted in for providing instant access to lead information in response 9 to lead requests, or if instead they have opted to receive a further opportunity to approve io provision of the requested lead information 4335. If the users have opted in to provide 11 instant access, then the HUB may determine whether the requesting user and/or the 12 lead request itself meet minimum requirements for lead information provision 4538.
13 For example, in one implementation, such a determination may be made based on a 14 comparison of a bounty proposal from the lead requestor to a minimum required amount specified by the lead owner and/or controller for sharing the requested lead 16 information, whereby the minimum requirement is met if the bounty exceeds the 17 minimum required amount. In another example, a minimum requirement may be 1s based on a comparison of a requesting user identifier and/or other requesting user 1s characteristics to a list of preferred and/or prohibited identifiers and/or characteristics.
If the minimum requirements have not been met, an error handling procedure may be 21 undertaken 4550, such as providing an error message to the requesting user, prompting 22 the user for re-selection of desired leads, and/or the like. If the minimum requirements 23 have been met at 4538, then the requested lead information may be provided to the 1 requesting user, and payment effectuated for the owner and/or controller of the lead 2 information 4555.

3 [o 018 91 If the lead originators have not opted in at 4535, the HUB may provide 4 them with a lead sharing request notice and/or message 4540, and a determination may be made as to whether they have accepted the request 4545. If not, then an error 6 handling procedure may be undertaken 4550, such as providing an error message to the 7 requesting user, prompting the user for re-selection of desired leads, and/or the like.
8 Otherwise, if the lead request is accepted at 4545, then the requested lead information 9 may be provided to the requesting user, and payment effectuated for the owner and/or 1o controller of the lead information 4555. The HUB may then receive a lead quality score 11 from the requesting user 4560, such as may reflect a perceived quality associated with 12 the received lead information. Any of a variety of lead ratings may be employed in 13 different implementations of the HUB, such as but not limited to numerical scores, 14 radio-button ratings, "like" buttons, thumbs-up and/or thumbs-down ratings, and/or the like. A lead quality score associated with the owner, originator, controller, and/or 16 the like of the lead may then be updated based on the received lead quality score 4565.

17 [ O o 19 O ] In one implementation, the HUB may track and/or maintain records of 18 lead requests, lead provisions, lead transactions, bounty payments, and/or the like.
19 Tracked records may include, for example, a record of a lead requestor identifier, lead provider identifier, date, time, lead request type, lead request parameters, lead quality 21 score, bounty amount, and/or the like. The HUB may analyze lead request and/or 22 transaction records to discern one or more trends associated therewith. For example, 23 the HUB may determine which brokers, retailers, tenants, landlords, and/or the like 1 HUB users have been accessed the most and/or been the target of the most lead 2 requests by HUB lead sharing services. In another example, the HUB may determine 3 which locations, property types, property characteristics, price ranges, and/or the like 4 are the most popular among lead requestors, lead requests, provided leads, and/or the like. The HUB may perform any of a wide variety of statistical analyses on accumulated 6 information, such as, but not limited to, calculating averages, means, medians, 7 variances, standard deviations, location and/or time resolved trends, correlations, a and/or the like. In one implementation, accumulated and/or generated trend s information may be made available to HUB administrators, users, and/or the like. The HUB may publish lead request and/or lead provision analytics, provide fee-based 11 access, and/or the like.

12 [o 0191 ] FIGURE 46 shows an implementation of user interface for lead request 13 submission in one embodiment of HUB operation. By engaging elements of the lead 14 request form 4601, a lead requesting user may specify a variety of lead request information, criteria, offers, and/or the like to tailor a particular lead request. The 16 interface may, for example, allow a user to specify a request type 4605, for example as a 17 contact information request, a marketing idea request, a site drive request, a calendar 18 time request, a personal introduction request, a broad request covering all available 19 categories, and/or the like. In one implementation, the interface may further include one or more fields 4610 by which a user may enter and/or submit request parameters, 21 lead criteria, search terms, search strings, and/or the like information for use by the 22 HUB in querying lead information stored in one or more HUB databases. In one 23 implementation, request parameter fields may be subdivided into one or more sub-24 fields accepting entry of specific categories of request parameters, such as, but not 1 limited to, lead name, lead title, lead type, location, property type, property 2 characteristics, property name, transaction type, availability, bounty amount, and/or the 3 like. In one implementation, the interface may further include facilities to allow a user 4 to specify a bounty offer for association with the lead request 4615, such as in the form of a number in conjunction with a currency unit. In one implementation, the interface 6 may further include one or more fields or other interface elements allowing a user to 7 further target and/or refine the lead request. For example, a user may be able to specify a desired characteristics of a lead originator, controller, owner, and/or the like. When the s lead request is complete, the user may engage an interface element such as the button 1o shown at 4625 to submit the request to the HUB. In one implementation, an interface 11 similar to the example shown in Fig. 46 may be implemented as a web interface.

12 [001921 FIGURES 47A-C show implementations of user interface for lead 13 candidate selection in one embodiment of HUB operation. Interfaces similar to the 14 examples shown in Figs. 47A-B may be employed by HUB embodiments to allow lead requesting users to select desired lead resources. In one implementation, a lead request 16 results page 4701 may include a button or similar interface element to allow a lead 17 requestor to return to a lead request page, such as that shown in Fig. 46, to modify 18 request parameters 4705. A results interface may include a variety of information 19 related to lead results returned in response to a lead request, such as information pertaining to a lead provider associated with the requested lead information 4710, a 21 quality rating for that lead provider 4715, and/or the like. In one implementation, a 22 quality premium 4720 may be assessed, such that a lead requesting user may be 23 requested to agree to pay an additional amount equal to the quality premium in order to 24 receive the lead information from the associated user. The interface may further include i one or more facilities to allow a user to select one or more of the entries in the results 2 page 4725, based on which the user may register a desire to retrieve the selected 3 information 4730.

41001931 In one implementation, an interface similar to the example shown in Fig.
47B may allow a lead requestor to view information about lead originating, owning, 6 controlling, and/or the like users within the results page. For example, in one 7 implementation, interaction with a user identifier (e.g., clicking, mousing over, and/or 8 the like), may engender a pop-up window 4735 that includes information for the contact 9 user, such as a photo 4740, contact information 4745, and/or the like.

101001941 In one implementation, an interface similar to the example shown in Fig.
11 47C may further provide a subset of lead information for display to a lead requestor 12 prior to lead selection, lead provision, bounty payment, and/or the like.
For example, in 13 the illustrated implementation, for a contact information request, the lead requestor 14 may be provided with a contact title 4750, contact location 4755, and/or the like to assist the requestor in selecting a lead provider with whom to exchange lead information 16 and/or payment. In various implementations, any of a variety of selected and/or 17 redacted lead information may be provided for display, such as redacted contact 18 information, title, location, company name, contact type, calendar availability, site drive 19 information, redacted and/or abbreviated marketing ideas, and/or the like.
Fig. 47C
also illustrates an implementation whereby matching lead providers having minimum 21 payment thresholds in excess of the bounty amount associated with a lead request may 22 still be provided for display to the lead requestor. For example, in the illustrated 23 implementation, a result entry is displayed 4760 where the lead provider identity is 1 redacted, and a message is provided indicating that the lead requestor provided bounty 2 is too low to allow for engagement in a lead sharing transaction with the corresponding 3 lead provider. Display of this information, or other limited information related to the 4 lead provider, may inspire a lead requestor to modify request parameters in order to be able to access lead information provided by that lead provider.

61001951 In embodiments, the HUB may be configured to identify leads for users 7 based on user-entered information, user contacts, and/or the properties associated with 8 a user and/or in which a user is interested. Leveraging connectivity between contact 9 relationship management functionality, property listing service features, intelligent 1o inbox coordination capabilities, and/or the like, the HUB may identify connections 11 between user requirements and/or assets and opportunities to fulfill those requirements 12 and/or to transact those assets or to alert the lead seeker of information correlating to 13 their expressly stated needs or to notify them of potential needs derived from their 14 historical or current activity in the contact relationship management service, property listing service, intelligent inbox coordination service, and/or the like.

16 [00196] FIGURE 48 shows a schematic illustration of data flow between and 17 among HUB components and affiliated entities for lead generation in one embodiment 18 of HUB operation. A HUB system 4801 may include components, such as those 19 discussed above, facilitating contact relationship management ("CRM") 4805, property listing 4810, intelligent inbox coordinating 4815, and/or the like features and/or 21 services, all of which may be communicatively coupled with each other and/or with one 22 or more HUB databases 4820. The HUB may further be communicatively coupled via a 23 communication network 4825 to one or more users 4830, who may enter a variety of 1 inputs, such as search terms, entries into a HUB bifurcated display, contact and/or 2 property data and/or parameters, code (e.g., barcode) captures and/or associated data, 3 scraped email and/or webpage data, and/or the like. In turn, the user may receive HUB
4 generated leads related to received inputs, and/or which may identify possible opportunities for transactions, communications with other users, marketing, and/or the 6 like. For example, users may receive contact information, property information, site 7 drive information, marketing idea information, and/or the like 4840 which may be 8 associated with and/or retrieved in response to receipt of various user inputs 4835. The 9 HUB 4801 may further be coupled to one or more external resource servers 4845 and/or io external resource databases485o to receive lead generation inputs and/or to access lead 11 information. In one implementation, external resources may comprise real estate listing 12 services, contact relationship management systems, electronic message and/or mail 13 services, code capture data sources, and/or the like.

14 100197] FIGURE 49 shows a schematic illustration of data flow for lead generation based on various inputs in one embodiment of HUB operation. In one implementation, 16 the non-exhaustive catalog of data sources shown in Fig. 49 may serve both/either as 17 triggers for the generation and identification of new leads and/or as sources of data for 18 the development of a body of data from which future leads may be generated and/or 19 identified. For example, the HUB 4901 may receive one or more code captures 4905, such as described previously, based on which any of a variety of data (e.g., property 21 requirements and/or specifications, site drive information, contact information, and/or 22 the like) may be retrieved and/or stored. In one implementation, retrieved information 23 may be employed, such as in accordance with the method described with reference to 24 Fig. 50, to form a query to seek related, alternative, complementary, and/or the like 1 information from existing data resources. In another implementation, data retrieved in 2 response to a code capture (e.g., property parameters, a location where the code was 3 captured, an associated contact, an identifier of the user capturing the code, and/or the 4 like) may be stored in a HUB data record, and may be accessed at a future time by a query formed based on other inputs (e.g., property parameters) in order to identify 6 some connection to those other inputs and/or possible leads. Other inputs which may 7 be exploited to build lead data and/or which may be used to build queries to identify 8 new leads include, but are not limited to: search strings and/or entries into one or more 9 search fields (e.g., property parameters entered to seek matching properties) 4910;
1o entries into a HUB bifurcated display 4915; email messages and/or email message 11 summaries, such as may be generated by a HUB intelligent inbox coordinator 4920;
12 HUB and/or external database record entries and/or existing data records 4925; and/or 13 the like. Among the leads 4930 which may be generated in response to the receipt of 14 one or more such inputs are contact information, site drive information, property listings, marketing ideas, and/or the like.

16 [001981 For further illustration, in one example, a tenant broker may enter desired 17 site requirements of a tenant client in a HUB bifurcated display, such as during a 18 telephone conversation with a counterbroker representing one or more landlord clients.
19 All or a subset of the entered site requirement information may be used to construct a query statement with which existing HUB property records are queried. Such existing 21 records may include records of property information generated directly as a result of 22 user property information inputs, property information scraped and/or analyzed from 23 websites, property information scraped and/or analyzed from emails (e.g., emails 24 received by the tenant broker, emails received by the tenant brokers contacts, and/or 1 the like), property information scraped and/or analyzed from documents (e.g., Word, 2 HTML, PDF files and/or the like), property information of other users, property 3 information received in response to captured codes, and/or the like. Any retrieved 4 property information may be analyzed, rated, ranked, and/or the like to determine if the match is of sufficient closeness, quality, and/or the like (as discussed further below) to 6 warrant identification as a potential lead for the user. If identified as a lead, the HUB
7 may provide notice of the property information to the tenant broker, and/or may access 8 further information linked with the property information, such as associated contact 9 information, site drive information, marketing idea information, and/or the like, which io may then be provided to the tenant broker.

11 [ o o 19 9 ] In one implementation, the HUB may further identify a current role, 12 activity, and/or the like associated with the input information, discern a complementary 13 role, activity, and/or the like, and construct a query based on the current activity/role 14 and/or the complementary activity/role. For example, a current role may comprise a tenant broker role, and a complementary role may comprise a landlord broker role, 16 whereby property information entered under a tenant broker role may be used to query 17 property information connected with and/or entered under a landlord broker role. In 18 another implementation, the HUB may seek leads based on patterns of property 19 information. For example, if the HUB detects that a user has entered a particular collection of property characteristics more than a threshold number of times, it may 21 perform a query based on that collection of information, and/or a subset thereof, to 22 identify leads of possible continuing interest to the user. Input patterns may be detected 23 from any combination of inputs such as those shown in Fig. 49. For example, a pattern 24 of inputs may be discerned by cross-correlating inputs into a bifurcated display, code 1 capture data retrievals, and user emails analyzed by a HUB intelligent inbox 2 coordinator.

3[0020o] FIGURE 50 shows an implementation of logic flow for lead generation in 4 one embodiment of HUB operation. One or more property inputs may be received 5001, such as, but not limited to, entries to a HUB bifurcated display, search strings 6 and/or search terms, contact information, scraped and/or summarized email and/or 7 website data, property listing information, code captures and/or data retrieved in 8 response thereto, and/or the like. In one implementation, property inputs may exploit 9 AJAX tools to facilitate communication of property inputs in a local client interface to a io remote server for analysis, lead identification and/or generation, and/or the like. In one 11 implementation, the HUB may collect and analyze inputs over a period of time, and 12 proceed with lead generation for inputs, and/or subsets thereof, which have a pattern of 13 occurrence and/or which have occurred and/or have been received more than a 14 minimum threshold number of times. In one implementation, the HUB may discern a role, activity, and/or the like associated with a current or past pattern of inputs 5005.
16 For example, in one implementation, an input activity may comprise a buy-side activity, 17 sell-side activity, investment activity, tenant role, tenant broker role, landlord role, 18 landlord broker role, and/or the like. An activity and/or role may, in one 19 implementation, be specified by a user using one or more role specification interface elements, such as those shown at 101 in Fig. 1A.

21 [00201] In one implementation, a determination may be made as to whether 22 sufficient property inputs and/or activity identifying inputs have been provided to 23 warrant identification and/or generation of leads 50o8. For example, in one 1 implementation, the HUB may seek inputs corresponding to at least a user role, 2 property location, and property square footage at 5008 before proceeding with further 3 lead identification. In one implementation, different property inputs may have different 4 weights in consideration of whether sufficient inputs have been received.
For example, in one implementation, while a location and a square footage may be sufficient, a 6 property type and a property price may be insufficient unless they also include a 7 property visibility input. In one implementation, an initial query of possible lead 8 matches may be performed at 5008 to discern a volume of matching results and, if that s volume exceeds a threshold, the results may be discarded and the HUB may note that 1o there are insufficient inputs. In an alternative implementation, the HUB
may provide a 11 sample of the results to the user with a notice that a high volume of results has been 12 retrieved, and providing an option to the user as to whether he or she would like to 13 proceed or wait until further property inputs are received.

14 [ 0 0 2 0 2 ] The HUB may then discern one or more roles, activities, and/or the like that are complementary to and/or otherwise related to the input roles, activities, and/or 1s the like 5010. In one implementation, the HUB may engage one or more rules to 17 correlate input activities with complementary activities. For example, a rule may specify 18 that, if the user has specified a tenant broker role, then the complementary role is 19 landlord broker. In another example, a rule may specify that, where an input activity is a code capture of a property for sale, the complementary activity is property sales, such 21 that lead information that is provided in response to the input may be property 22 information for other available properties for sale. The HUB may prepare a query 23 statement based on the received inputs 5015. In one implementation, the query 24 statement and/or the selection of database tables and/or records to which the query 1 statement are applied may be further be based on the discerned input activity and/or 2 the discerned complementary activity. In one implementation, the HUB may 3 automatically determine ranges of values centered around received property inputs, 4 and/or may determine additional values related to received inputs, and may use those ranges and/or additional values in preparation of the query statement. For example, if 6 received inputs include property price, property square footage, and a property type, the 7 HUB may build ranges of price and square footage that encompass lo% above and lo%
8 below the received values, may supplement the property type with related types, and 9 may construct the query using the ranges and related types. In one implementation, a io subset of received property information may be used in preparing the query statement, ii such as may be based on a prioritization schedule of different property characteristics.
12 For example, in one implementation, property characteristics, in descending order of 13 prioritization may be type, price, square footage, location, and/or the like. The query 14 statement may then be constructed by first selecting all input property information and/or exact values of those inputs. In one implementation, subsequent query 16 statements may be prepared excluding property inputs with lower prioritization values, 17 and/or including broader ranges around received values, until a desired number of 18 matching results are retrieved in response to the query. In one implementation, 19 property characteristic prioritization may be different for different discerned input activities and/or discerned complementary activities.

21 [00203] A determination may be made as to whether the database tables and/or 22 records searched using the query prepared at 5015 should be confined to a limited group 23 of contacts (e.g., the contacts of the user from whom the property inputs were received) 24 5020. If so, then those contacts and/or associated records for properties, site drives, 1 marketing information, and/or the like may be queried 5025. Otherwise, a broader 2 group of contacts and/or associated records for properties, site drives, marketing ideas, 3 and/or the like may be queried 5030, such as all records in the HUB
database.
41002041 In one implementation, a query may take a form similar to the following SQL example:

6 function FindMatchingContacts {
7 mysql_select_db ("Contacts.rdb"); // select database to search 8 $query = "SELECT contact-info WHERE property-info LIKE `%' s $input_property_info;
$result = mysql _query($query);
11 mysgl_close ("Contacts.rdb");
12 return $result;
13 }

14 [ 0 0 2 0 5 ] A determination may be made as to whether any matches exist in response to the query 5035 and, of not, the HUB may undertake an error handling procedure 16 5040, such as returning to 5015 to prepare another query statement using a more 17 restricted selection of property inputs (e.g., excluding more low priority inputs than in 18 the first query statement). In one implementation, no action may be taken by the HUB
19 if there are no matches retrieved at 5035. If one or more matches are found at 5035, the HUB may evaluate a match quality 5045 for each matching result. For example, in one 21 implementation, a match quality may be based on the number of original property 22 inputs and/or the size of ranges around those inputs used in the preparation of the 23 query statement at 5015. In one implementation, the match quality may consider the 24 prioritization schedule of property characteristics and weight the quality value more heavily for matches (or lack thereof) between higher priority property characteristics.
26 The determined match quality may be compared with a threshold value and a 27 determination made as to whether the match quality exceeds that threshold 5050. If 1 not, an error handling procedure may be undertaken 5040. If the match quality exceeds 2 the threshold, the HUB may identify the one or more matching results as leads 5055, 3 such as by generating a match record with one or more links to the one or more 4 matching contact, property, site drive, marketing idea, and/or the like records. The match record may further include a variety of other information, such as but not limited 6 to property inputs, contact information and/or links to contact information for the user 7 from whom the property inputs are received, match quality, and/or the like.
In one 8 implementation, the HUB may further provide notice of the lead, such as to the user 9 from whom the property inputs were received, to a user associated with matches 1o identified at 5035, and/or the like.

11 [ 0 0 2 0 6 ] FIGURE 51 shows a schematic illustration of alternative lead identification 12 in one embodiment of HUB operation. In one implementation, the HUB may be 13 configured to identify relevant alternative lead opportunities during real-time 14 communications with other HUB users. For example, a HUB user (e.g., broker) may be engaged in a discussion and/or negotiation with a transactional counterparty (e.g., 16 counterbroker) and may engage a HUB bifurcated display 5101 to compare property 17 requirements with available property characteristics. The HUB may access a data 18 record associated with the counterbroker 5115 to identify whatever other clients 19 associated with that broker may be accessible (e.g., whatever information about the counterbroker's clients that the broker user has authorization to access).
Records for 21 those clients 5120 may then be accessed in order to evaluate whether property 22 information associated with those clients is a closer to match to the broker's property 23 characteristics than the ones being discussed in the current activity. If so, the 24 alternative lead opportunity associated with the other client may be identified to the 1 user broker 5125, which may notify the user broker to raise the possibility of a 2 transaction involving that client with the counterbroker engaged in the current activity.

3 [0 0 2 0 7] FIGURE 52 shows an implementation of logic flow for alternative lead 4 identification in one embodiment of HUB operation. The HUB may identify a broker engaged in a current activity 5201, such as a counterbroker with whom a user is s currently engaged in communications and/or whose information has been entered by a 7 current user in a HUB bifurcated display. The HUB may construct a query based on the 8 identified broker 5205 in order to retrieve identifiers of clients associated with the s broker 5210. In one implementation, a user may be restricted in access to information io about a broker's clients, and may only have access to a limited subset of client identities 11 (e.g., clients entered by the user himself in association with the broker, clients 12 specifically designated as accessible to the user, and/or the like). A
determination may 13 be made as to whether any clients can be identified 5215 and, if not, then an error 14 handling procedure may be undertaken 5220, such as notifying the user that no other clients can be identified. In one implementation, the HUB may take no action if no 16 clients can be identified at 5215. If another client can be identified at 5215, the HUB
17 may retrieve client property parameters 5225 from an associated client record, such as 18 property requirements for a tenant client or available property characteristics for a 19 landlord client. The HUB may then compare retrieved broker client property parameters with property parameters associated with the current activity 5230.
For 21 example, if a user has entered site requirements in the current activity and the client is a 22 landlord client, the property characteristics of available properties associated with the 23 landlord client may be compared with those site requirements. In another example, if a 24 user has entered available property characteristics in the current activity and the client 1 is a tenant client, the tenant client's site requirements may be compared with those 2 available property characteristics. A match quality may be determined based on the 3 comparison at 5230. In one implementation, such a match quality rating may be based 4 on a weighted sum of normalized differences between client property parameters and property parameters associated with the current activity. A determination may be made 6 as to whether the match exceeds a minimum threshold value 5235. For example, in one 7 implementation, the threshold value may be taken as a determined match quality 8 between property parameters associated with the current activity and property 9 parameters associated with a client involved in the current activity. In another 1o implementation, the threshold value may be a fixed value regardless of a current 11 activity. If the match is greater than the threshold, the HUB may register the existence 12 of the matching parameters 5240, such as by providing notice of the match to the user.
13 A determination may be made as to whether there is a new activity 5245 for which a 14 further evaluation of alternative leads is to be made. If so, then the HUB
may return to 5201. Otherwise, the flow may conclude 5250.

16 HUB Controller 17 [002o8] FIGURE 53 illustrates inventive aspects of a HUB controller 5301 in a 18 block diagram. In this embodiment, the HUB controller 5301 may serve to aggregate, 19 process, store, search, serve, identify, instruct, generate, match, and/or facilitate interactions with a computer through property transaction facilitating and associated 21 activity and communication recording technologies, and/or other related data.

22[00209] Typically, users, which may be people and/or other systems, may engage 23 information technology systems (e.g., computers) to facilitate information processing.

1 In turn, computers employ processors to process information; such processors 2 may be referred to as central processing units (CPU). One form of processor is referred 3 to as a microprocessor. CPUs use communicative circuits to pass binary encoded signals 4 acting as instructions to enable various operations. These instructions may be operational and/or data instructions containing and/or referencing other instructions 6 and data in various processor accessible and operable areas of memory 5329 (e.g., 7 registers, cache memory, random access memory, etc.). Such communicative 8 instructions may be stored and/or transmitted in batches (e.g., batches of instructions) 9 as programs and/or data components to facilitate desired operations. These stored 1o instruction codes, e.g., programs, may engage the CPU circuit components and other 11 motherboard and/or system components to perform desired operations. One type of 12 program is a computer operating system, which, may be executed by CPU on a 13 computer; the operating system enables and facilitates users to access and operate 14 computer information technology and resources. Some resources that may be.
employed in information technology systems include: input and output mechanisms through 16 which data may pass into and out of a computer; memory storage into which data may 17 be saved; and processors by which information may be processed. These information 18 technology systems may be used to collect data for later retrieval, analysis, and 19 manipulation, which may be facilitated through a database program. These information technology systems provide interfaces that allow users to access and operate various 21 system components.

22[002-10] In one embodiment, the HUB controller 5301 may be connected to and/or 23 communicate with entities such as, but not limited to: one or more users from user 1 input devices 5311; peripheral devices 5312; an optional cryptographic processor device 2 5328; and/or a communications network 5313.

3 [O 0211] Networks are commonly thought to comprise the interconnection and 4 interoperation of clients, servers, and intermediary nodes in a graph topology. It should be noted that the term "server" as used throughout this application refers generally to a 6 computer, other device, program, or combination thereof that processes and responds to 7 the requests of remote users across a communications network. Servers serve their 8 information to requesting "clients." The term "client" as used herein refers generally to a s computer, program, other device, user and/or combination thereof that is capable of io processing and making requests and obtaining and processing any responses from ii servers across a communications network. A computer, other device, program, or 12 combination thereof that facilitates, processes information and requests, and/or 13 furthers the passage of information from a source user to a destination user is 14 commonly referred to as a "node." Networks are generally thought to facilitate the transfer of information from source points to destinations. A node specifically tasked 16 with furthering the passage of information from a source to a destination is commonly 17 called a "router." There are many forms of networks such as Local Area Networks 1s (LANs), Pico networks, Wide Area Networks (WANs), Wireless Networks (WLANs), etc.
19 For example, the Internet is generally accepted as being an interconnection of a multitude of networks whereby remote clients and servers may access and interoperate 21 with one another.

1 [0 0219 ] The HUB controller 5301 may be based on computer systems that may 2 comprise, but are not limited to, components such as: a computer systemization 5302 3 connected to memory 5329.

4 Computer Systemization [00213] A computer systemization 5302 may comprise a clock 5330, central s processing unit ("CPU(s)" and/or "processor(s)" (these terms are used interchangeable 7 throughout the disclosure unless noted to the contrary)) 5303, a memory 5329 (e.g., a 8 read only memory (ROM) 5306, a random access memory (RAM) 5305, etc.), and/or an 9 interface bus 5307, and most frequently, although not necessarily, are all interconnected 1o and/or communicating through a system bus 5304 on one or more (mother)board(s) 11 5302 having conductive and/or otherwise transportive circuit pathways through which 12 instructions (e.g., binary encoded signals) may travel to effect communications, 13 operations, storage, etc. Optionally, the computer systemization may be connected to an 14 internal power source 5386. Optionally, a cryptographic processor 5326 may be connected to the system bus. The system clock typically has a crystal oscillator and 16 generates a base signal through the computer systemization's circuit pathways. The 17 clock is typically coupled to the system bus and various clock multipliers that will 18 increase or decrease the base operating frequency for other components interconnected 19 in the computer systemization. The clock and various components in a computer systemization drive signals embodying information throughout the system. Such 21 transmission and reception of instructions embodying information throughout a 22 computer systemization may be commonly referred to as communications. These 23 communicative instructions may further be transmitted, received, and the cause of 1 return and/or reply communications beyond the instant computer systemization to:
2 communications networks, input devices, other computer systemizations, peripheral 3 devices, and/or the like. Of course, any of the above components may be connected 4 directly to one another, connected to the CPU, and/or organized in numerous variations employed as exemplified by various computer systems.

6 100214] The CPU comprises at least one high-speed data processor adequate to 7 execute program components for executing user and/or system-generated requests.
8 Often, the processors themselves will incorporate various specialized processing units, s such as, but not limited to: integrated system (bus) controllers, memory management 1o control units, floating point units, and even specialized processing sub-units like 11 graphics processing units, digital signal processing units, and/or the like. Additionally, 12 processors may include internal fast access addressable memory, and be capable of 13 mapping and addressing memory 529 beyond the processor itself; internal memory may 14 include, but is not limited to: fast registers, various levels of cache memory (e.g., level 1, 2, 3, etc.), RAM, etc. The processor may access this memory through the use of a 16 memory address space that is accessible via instruction address, which the processor 17 can construct and decode allowing it to access a circuit path to a specific memory 18 address space having a memory state. The CPU may be a microprocessor such as:
19 AMD's Athlon, Duron and/or Opteron; ARM's application, embedded and secure processors; IBM and/or Motorola's DragonBall and PowerPC; IBM's and Sony's Cell 21 processor; Intel's Celeron, Core (2) Duo, Itanium, Pentium, Xeon, and/or XScale;
22 and/or the like processor(s). The CPU interacts with memory through instruction 23 passing through conductive and/or transportive conduits (e.g., (printed) electronic 24 and/or optic circuits) to execute stored instructions (i.e., program code) according to 1 conventional data processing techniques. Such instruction passing facilitates 2 communication within the HUB controller and beyond through various interfaces.
3 Should processing requirements dictate a greater amount speed and/or capacity, 4 distributed processors (e.g., Distributed HUB), mainframe, multi-core, parallel, and/or super-computer architectures may similarly be employed.Alternatively, should 6 deployment requirements dictate greater portability, smaller Personal Digital Assistants 7 (PDAs) may be employed.

8 [00215] Depending on the particular implementation, features of the HUB may be s achieved by implementing a microcontroller such as CAST's R8051XC2 microcontroller;
io Intel's MCS 51 (i.e., 8051 microcontroller); and/or the like. Also, to implement certain 11 features of the HUB, some feature implementations may rely on embedded components, 12 such as: Application-Specific Integrated Circuit ("ASIC"), Digital Signal Processing 13 ("DSP"), Field Programmable Gate Array ("FPGA"), and/or the like embedded 14 technology. For example, any of the HUB component collection (distributed or otherwise) and/or features may be implemented via the microprocessor and/or via 16 embedded components; e.g., via ASIC, coprocessor, DSP, FPGA, and/or the like.
17 Alternately, some implementations of the HUB may be implemented with embedded 18 components that are configured and used to achieve a variety of features or signal 19 processing.

[00216] Depending on the particular implementation, the embedded components 21 may include software solutions, hardware solutions, and/or some combination of both 22 hardware/ software solutions. For example, HUB features discussed herein may be 23 achieved through implementing FPGAs, which are a semiconductor devices containing 1 programmable logic components called "logic blocks", and programmable 2 interconnects, such as the high performance FPGA Virtex series and/or the low cost 3 Spartan series manufactured by Xilinx. Logic blocks and interconnects can be 4 programmed by the customer or designer, after the FPGA is manufactured, to implement any of the HUB features. A hierarchy of programmable interconnects allow 6 logic blocks to be interconnected as needed by the HUB system designer/administrator, 7 somewhat like a one-chip programmable breadboard. An FPGA's logic blocks can be 8 programmed to perform the function of basic logic gates such as AND, and XOR, or 9 more complex combinational functions such as decoders or simple mathematical 1o functions. In most FPGAs, the logic blocks also include memory elements, which may be ii simple flip-flops or more complete blocks of memory. In some circumstances, the HUB
12 may be developed on regular FPGAs and then migrated into a fixed version that more 13 resembles ASIC implementations. Alternate or coordinating implementations may 14 migrate HUB controller features to a final ASIC instead of or in addition to FPGAs.
Depending on the implementation all of the aforementioned embedded components and 16 microprocessors may be considered the "CPU" and/or "processor" for the HUB.

17 Power Source 18 [ O O 2 17] The power source 5386 may be of any standard form for powering small 19 electronic circuit board devices such as the following power cells:
alkaline, lithium hydride, lithium ion, lithium polymer, nickel cadmium, solar cells, and/or the like.
21 Other types of AC or DC power sources may be used as well. In the case of solar cells, in 22 one embodiment, the case provides an aperture through which the solar cell may 23 capture photonic energy. The power cell 5386 is connected to at least one of the i interconnected subsequent components of the HUB thereby providing an electric 2 current to all subsequent components. In one example, the power source 5386 is 3 connected to the system bus component 5304. In an alternative embodiment, an outside 4 power source 5386 is provided through a connection across the I/O 5308 interface. For example, a USB and/or IEEE 1394 connection carries both data and power across the 6 connection and is therefore a suitable source of power.

7 Interface Adapters 8 [00218] Interface bus(ses) 5307 may accept, connect, and/or communicate to a 9 number of interface adapters, conventionally although not necessarily in the form of io adapter cards, such as but not limited to: input output interfaces (I/O) 5308, storage 11 interfaces 5309, network interfaces 5310, and/or the like. Optionally, cryptographic 12 processor interfaces 5327 similarly may be connected to the interface bus.
The interface 13 bus provides for the communications of interface adapters with one another as well as 14 with other components of the computer systemization. Interface adapters are adapted for a compatible interface bus. Interface adapters conventionally connect to the 16 interface bus via a slot architecture. Conventional slot architectures may be employed, 17 such as, but not limited to: Accelerated Graphics Port (AGP), Card Bus, (Extended) 18 Industry Standard Architecture ((E)ISA), Micro Channel Architecture (MCA), NuBus, 19 Peripheral Component Interconnect (Extended) (PCI(X)), PCI Express, Personal Computer Memory Card International Association (PCMCIA), and/or the like.

21 [ O 0 219 ] Storage interfaces 5309 may accept, communicate, and/or connect to a 22 number of storage devices such as, but not limited to: storage devices 5314, removable 23 disc devices, and/or the like. Storage interfaces may employ connection protocols such 1 as, but not limited to: (Ultra) (Serial) Advanced Technology Attachment (Packet 2 Interface) ((Ultra) (Serial) ATA(PI)), (Enhanced) Integrated Drive Electronics ((E)IDE), 3 Institute of Electrical and Electronics Engineers (IEEE) 1394, fiber channel, Small 4 Computer Systems Interface (SCSI), Universal Serial Bus (USB), and/or the like.

[ 0 0 2 2 0 ] Network interfaces 5310 may accept, communicate, and/or connect to a 6 communications network 5313. Through a communications network 5313, the HUB
7 controller is accessible through remote clients 5333b (e.g., computers with web 8 browsers) by users 5333a. Network interfaces may employ connection protocols such as, 9 but not limited to: direct connect, Ethernet (thick, thin, twisted pair to/loo/looo Base 1o T, and/or the like), Token Ring, wireless connection such as IEEE 802.11a-x, and/or the 11 like. Should processing requirements dictate a greater amount speed and/or capacity, 12 distributed network controllers (e.g., Distributed HUB), architectures may similarly be 13 employed to pool, load balance, and/or otherwise increase the communicative 14 bandwidth required by the HUB controller. A communications network may be any one and/or the combination of the following: a direct interconnection; the Internet; a Local 16 Area Network (LAN); a Metropolitan Area Network (MAN); an Operating Missions as 17 Nodes on the Internet (OMNI); a secured custom connection; a Wide Area Network 18 (WAN); a wireless network (e.g., employing protocols such as, but not limited to a 19 Wireless Application Protocol (WAP), I-mode, and/or the like); and/or the like. A
network interface may be regarded as a specialized form of an input output interface.
21 Further, multiple network interfaces 5310 may be used to engage with various 22 communications network types 5313. For example, multiple network interfaces may be 23 employed to allow for the communication over broadcast, multicast, and/or unicast 24 networks.

1 [002211 Input Output interfaces (I/O) 5308 may accept, communicate, and/or 2 connect to user input devices 5311, peripheral devices 5312, cryptographic processor 3 devices 5328, and/or the like. I/O may employ connection protocols such as, but not 4 limited to: audio: analog, digital, monaural, RCA, stereo, and/or the like;
data: Apple Desktop Bus (ADB), IEEE 1394a-b, serial, universal serial bus (USB); infrared;
joystick;
6 keyboard; midi; optical; PC AT; PS/2; parallel; radio; video interface:
Apple Desktop 7 Connector (ADC), BNC, coaxial, component, composite, digital, Digital Visual Interface 8 (DVI), high-definition multimedia interface (HDMI), RCA, RF antennae, S-Video, VGA, 9 and/or the like; wireless: 8o2.11a/b/g/n/x, Bluetooth, code division multiple access (CDMA), global system for mobile communications (GSM), WiMax, etc.; and/or the 11 like. One typical output device may include a video display, which typically comprises a 12 Cathode Ray Tube (CRT) or Liquid Crystal Display (LCD) based monitor with an 13 interface (e.g., DVI circuitry and cable) that accepts signals from a video interface, may 14 be used. The video interface composites information generated by a computer systemization and generates video signals based on the composited information in a 1s video memory frame. Another output device is a television set, which accepts signals 17 from a video interface. Typically, the video interface provides the composited video 18 information through a video connection interface that accepts a video display interface 19 (e.g., an RCA composite video connector accepting an RCA composite video cable; a DVI
connector accepting a DVI display cable, etc.).

21 [ o 0 2 2 21 User input devices 5311 may be card readers, dongles, finger print readers, 22 gloves, graphics tablets, joysticks, keyboards, mouse (mice), remote controls, retina 23 readers, trackballs, trackpads, and/or the like.

1 [002231 Peripheral devices 5312 may be connected and/or communicate to I/O
2 and/or other facilities of the like such as network interfaces, storage interfaces, and/or 3 the like. Peripheral devices may be audio devices, cameras, dongles (e.g., for copy 4 protection, ensuring secure transactions with a digital signature, and/or the like), external processors (for added functionality), goggles, microphones, monitors, network 6 interfaces, printers, scanners, storage devices, video devices, video sources, visors, 7 and/or the like.

8 [ O 0 2 2 41 It should be noted that although user input devices and peripheral devices 9 may be employed, the HUB controller may be embodied as an embedded, dedicated, 1o and/or monitor-less (i.e., headless) device, wherein access would be provided over a 11 network interface connection.

12 [00225] Cryptographic units such as, but not limited to, microcontrollers, 13 processors 5326, interfaces 5327, and/or devices 5328 may be attached, and/or 14 communicate with the HUB controller. A MC68HCi6 microcontroller, manufactured by Motorola Inc., may be used for and/or within cryptographic units. The MC68HC16 16 microcontroller utilizes a 16-bit multiply-and-accumulate instruction in the 16 MHz 17 configuration and requires less than one second to perform a 512-bit RSA
private key 18 operation. Cryptographic units support the authentication of communications from 19 interacting agents, as well as allowing for anonymous transactions.
Cryptographic units may also be configured as part of CPU. Equivalent microcontrollers and/or processors 21 may also be used. Other commercially available specialized cryptographic processors 22 include: the Broadcom's CryptoNetX and other Security Processors; nCipher's nShield, 23 SafeNet's Luna PCI (e.g., 7100) series; Semaphore Communications' 40 MHz 1 Roadrunner 184; Sun's Cryptographic Accelerators (e.g., Accelerator 6ooo PCIe Board, 2 Accelerator 50o Daughtercard); Via Nano Processor (e.g., L21oo, L2200, U2400) line, 3 which is capable of performing 500+ MB/s of cryptographic instructions; VLSI
4 Technology's 33 MHz 6868; and/or the like.

Memory 6 [ 0 0 2 2 6 ] Generally, any mechanization and/or embodiment allowing a processor to 7 affect the storage and/or retrieval of information is regarded as memory 5329. However, 8 memory is a fungible technology and resource, thus, any number of memory 9 embodiments may be employed in lieu of or in concert with one another. It is to be io understood that the HUB controller and/or a computer systemization may employ 11 various forms of memory 5329. For example, a computer systemization may be 12 configured wherein the functionality of on-chip CPU memory (e.g., registers), RAM, 13 ROM, and any other storage devices are provided by a paper punch tape or paper punch 14 card mechanism; of course such an embodiment would result in an extremely slow rate of operation. In a typical configuration, memory 5329 will include ROM 5306, RAM
16 5305, and a storage device 5314. A storage device 5314 may be any conventional 17 computer system storage. Storage devices may include a drum; a (fixed and/or 18 removable) magnetic disk drive; a magneto-optical drive; an optical drive (i.e., Blueray, 19 CD ROM/RAM/Recordable (R)/ReWritable (RW), DVD R/RW, HD DVD R/RW etc.);
an array of devices (e.g., Redundant Array of Independent Disks (RAID)); solid state 21 memory devices (USB memory, solid state drives (SSD), etc.); other processor-readable 22 storage mediums; and/or other devices of the like. Thus, a computer systemization 23 generally requires and makes use of memory.

1 Component Collection 2 1002-27] The memory 5329 may contain a collection of program and/or database 3 components and/or data such as, but not limited to: operating system component(s) 4 5315 (operating system); information server component(s) 5316 (information server);
user interface component(s) 5317 (user interface); Web browser component(s) 6 (Web browser); database(s) 5319; mail server component(s) 5321; mail client 7 component(s) 5322; cryptographic server component(s) 5320 (cryptographic server);
8 the HUB component(s) 5335; and/or the like (i.e., collectively a component collection).
9 These components may be stored and accessed from the storage devices and/or from 1o storage devices accessible through an interface bus. Although non-conventional 11 program components such as those in the component collection, typically, are stored in 12 a local storage device 5314, they may also be loaded and/or stored in memory such as:
13 peripheral devices, RAM, remote storage facilities through a communications network, 14 ROM, various forms of memory, and/or the like.

Operating System 16 [002-281 The operating system component 5315 is an executable program 17 component facilitating the operation of the HUB controller. Typically, the operating 18 system facilitates access of I/O, network interfaces, peripheral devices, storage devices, 19 and/or the like. The operating system may be a highly fault tolerant, scalable, and secure system such as: Apple Macintosh OS X (Server); AT&T Plan 9; Be OS; Unix and 21 Unix-like system distributions (such as AT&T's UNIX; Berkley Software Distribution 22 (BSD) variations such as FreeBSD, NetBSD, OpenBSD, and/or the like; Linux 23 distributions such as Red Hat, Ubuntu, and/or the like); and/or the like operating 1 systems. However, more limited and/or less secure operating systems also may be 2 employed such as Apple Macintosh OS, IBM OS/2, Microsoft DOS, Microsoft Windows 3 2000/2003/3.1/95/98/CE/Millenium/NT/Vista/XP (Server), Palm OS, and/or the like.
4 An operating system may communicate to and/or with other components in a component collection, including itself, and/or the like. Most frequently, the operating s system communicates with other program components, user interfaces, and/or the like.
7 For example, the operating system may contain, communicate, generate, obtain, and/or 8 provide program component, system, user, and/or data communications, requests, 9 and/or responses. The operating system, once executed by the CPU, may enable the 1o interaction with communications networks, data, I/O, peripheral devices, program 11 components, memory, user input devices, and/or the like. The operating system may 12 provide communications protocols that allow the HUB controller to communicate with 13 other entities through a communications network 5313. Various communication 14 protocols may be used by the HUB controller as a subcarrier transport mechanism for interaction, such as, but not limited to: multicast, TCP/IP, UDP, unicast, and/or the 16 like.

17 Information Server 18 [00229] An information server component 5316 is a stored program component 1s that is executed by a CPU. The information server may be a conventional Internet information server such as, but not limited to Apache Software Foundation's Apache, 21 Microsoft's Internet Information Server, and/or the like. The information server may 22 allow for the execution of program components through facilities such as Active Server 23 Page (ASP), ActiveX, (ANSI) (Objective-) C (++), C# and/or NET, Common Gateway 1 Interface (CGI) scripts, dynamic (D) hypertext markup language (HTML), FLASH, Java, 2 JavaScript, Practical Extraction Report Language (PERL), Hypertext Pre-Processor 3 (PHP), pipes, Python, wireless application protocol (WAP), WebObjects, and/or the like.
4 The information server may support secure communications protocols such as, but not limited to, File Transfer Protocol (FTP); HyperText Transfer Protocol (HTTP);
Secure 6 Hypertext Transfer Protocol (HTTPS), Secure Socket Layer (SSL), messaging protocols 7 (e.g., America Online (AOL) Instant Messenger (AIM), Application Exchange (APEX), 8 ICQ, Internet Relay Chat (IRC), Microsoft Network (MSN) Messenger Service, Presence 9 and Instant Messaging Protocol (PRIM), Internet Engineering Task Force's (IETF's) io Session Initiation Protocol (SIP), SIP for Instant Messaging and Presence Leveraging 11 Extensions (SIMPLE), open XML-based Extensible Messaging and Presence Protocol 12 (XMPP) (i.e., Jabber or Open Mobile Alliance's (OMA's) Instant Messaging and 13 Presence Service (IMPS)), Yahoo! Instant Messenger Service, and/or the like. The 14 information server provides results in the form of Web pages to Web browsers, and allows for the manipulated generation of the Web pages through interaction with other 16 program components. After a Domain Name System (DNS) resolution portion of an 17 HTTP request is resolved to a particular information server, the information server 18 resolves requests for information at specified locations on the HUB
controller based on 19 the remainder of the HTTP request. For example, a request such as http://123.124.125.126/myInformation.html might have the IP portion of the request 21 "123.124.125.126" resolved by a DNS server to an information server at that IP address;
22 that information server might in turn further parse the http request for the 23 "/myInformation.html" portion of the request and resolve it to a location in memory 24 containing the information "myInformation.html." Additionally, other information 1 serving protocols may be employed across various ports, e.g., FTP
communications 2 across port 21, and/or the like. An information server may communicate to and/or with 3 other components in a component collection, including itself, and/or facilities of the 4 like. Most frequently, the information server communicates with the HUB
database 5319, operating systems, other program components, user interfaces, Web browsers, 6 and/or the like.

7 [ 0 0 2 3 0 ] Access to the HUB database may be achieved through a number of 8 database bridge mechanisms such as through scripting languages as enumerated below 9 (e.g., CGI) and through inter-application communication channels as enumerated below to (e.g., CORBA, WebObjects, etc.). Any data requests through a Web browser are parsed 11 through the bridge mechanism into appropriate grammars as required by the HUB. In 12 one embodiment, the information server would provide a Web form accessible by a Web 13 browser. Entries made into supplied fields in the Web form are tagged as having been 14 entered into the particular fields, and parsed as such. The entered terms are then passed along with the field tags, which act to instruct the parser to generate queries directed to 16 appropriate tables and/or fields. In one embodiment, the parser may generate queries in 17 standard SQL by instantiating a search string with the proper join/select commands 18 based on the tagged text entries, wherein the resulting command is provided over the 19 bridge mechanism to the HUB as a query. Upon generating query results from the query, the results are passed over the bridge mechanism, and may be parsed for 21 formatting and generation of a new results Web page by the bridge mechanism. Such a 22 new results Web page is then provided to the information server, which may supply it to 23 the requesting Web browser.

1 100231] Also, an information server may contain, communicate, generate, obtain, 2 and/or provide program component, system, user, and/or data communications, 3 requests, and/or responses.

4 User Interface 10023?-] The function of computer interfaces in some respects is similar to 6 automobile operation interfaces. Automobile operation interface elements such as 7 steering wheels, gearshifts, and speedometers facilitate the access, operation, and 8 display of automobile resources, functionality, and status. Computer interaction o interface elements such as check boxes, cursors, menus, scrollers, and windows 1o (collectively and commonly referred to as widgets) similarly facilitate the access, 11 operation, and display of data and computer hardware and operating system resources, 12 functionality, and status. Operation interfaces are commonly called user interfaces.
13 Graphical user interfaces (GUIs) such as the Apple Macintosh Operating System's Aqua, 14 IBM's OS/2, Microsoft's Windows 2000/2003/3.1/95/98/CE/Millenium/NT/XP/Vista/7 (i.e., Aero), Unix's X-Windows 16 (e.g., which may include additional Unix graphic interface libraries and layers such as K
17 Desktop Environment (KDE), mythTV and GNU Network Object Model Environment 18 (GNOME)), web interface libraries (e.g., ActiveX, AJAX, (D)HTML, FLASH, Java, 19 JavaScript, etc. interface libraries such as, but not limited to, Dojo, jQuery(UI), MooTools, Prototype, script.aculo.us, SWFObject, Yahoo! User Interface, any of which 21 may be used and) provide a baseline and means of accessing and displaying information 22 graphically to users.

1 [ 0 0 2 3 3 ] A user interface component 5317 is a stored program component that is 2 executed by a CPU. The user interface may be a conventional graphic user interface as 3 provided by, with, and/or atop operating systems and/or operating environments such 4 as already discussed. The user interface may allow for the display, execution, interaction, manipulation, and/or operation of program components and/or system 6 facilities through textual and/or graphical facilities. The user interface provides a facility 7 through which users may affect, interact, and/or operate a computer system.
A user s interface may communicate to and/or with other components in a component 9 collection, including itself, and/or facilities of the like. Most frequently, the user 1o interface communicates with operating systems, other program components, and/or the 11 like. The user interface may contain, communicate, generate, obtain, and/or provide 12 program component, system, user, and/or data communications, requests, and/or 13 responses.

14 Web Browser [00234] A Web browser component 5318 is a stored program component that is 16 executed by a CPU. The Web browser may be a conventional hypertext viewing 17 application such as Microsoft Internet Explorer or Netscape Navigator.
Secure Web 18 browsing may be supplied with 128bit (or greater) encryption by way of HTTPS, SSL, 19 and/or the like. Web browsers allowing for the execution of program components through facilities such as ActiveX, AJAX, (D)HTML, FLASH, Java, JavaScript, web 21 browser plug-in APIs (e.g., FireFox, Safari Plug-in, and/or the like APIs), and/or the 22 like. Web browsers and like information access tools may be integrated into PDAs, 23 cellular telephones, and/or other mobile devices. A Web browser may communicate to 1 and/or with other components in a component collection, including itself, and/or 2 facilities of the like. Most frequently, the Web browser communicates with information 3 servers, operating systems, integrated program components (e.g., plug-ins), and/or the 4 like; e.g., it may contain, communicate, generate, obtain, and/or provide program component, system, user, and/or data communications, requests, and/or responses. Of 6 course, in place of a Web browser and information server, a combined application may 7 be developed to perform similar functions of both. The combined application would 8 similarly affect the obtaining and the provision of information to users, user agents, 9 and/or the like from the HUB enabled nodes. The combined application may be io nugatory on systems employing standard Web browsers.

11 Mail Server 12 100235] A mail server component 5321 is a stored program component that is 13 executed by a CPU 5303. The mail server may be a conventional Internet mail server 14 such as, but not limited to sendmail, Microsoft Exchange, and/or the like.
The mail server may allow for the execution of program components through facilities such as 16 ASP, ActiveX, (ANSI) (Objective-) C (++), C# and/or NET, CGI scripts, Java, 17 JavaScript, PERL, PHP, pipes, Python, WebObjects, and/or the like. The mail server 18 may support communications protocols such as, but not limited to: Internet message 19 access protocol (IMAP), Messaging Application Programming Interface (MAPI)/Microsoft Exchange, post office protocol (POP3), simple mail transfer protocol 21 (SMTP), and/or the like. The mail server can route, forward, and process incoming and 22 outgoing mail messages that have been sent, relayed and/or otherwise traversing 23 through and/or to the HUB.

1 [00236] Access to the HUB mail maybe achieved through a number of APIs offered 2 by the individual Web server components and/or the operating system.

3 [00237] Also, a mail server may contain, communicate, generate, obtain, and/or 4 provide program component, system, user, and/or data communications, requests, information, and/or responses.

6 Mail Client 7 [00238] A mail client component 5322 is a stored program component that is 8 executed by a CPU 5303. The mail client may be a conventional mail viewing application 9 such as Apple Mail, Microsoft Entourage, Microsoft Outlook, Microsoft Outlook Express, Mozilla, Thunderbird, and/or the like. Mail clients may support a number of 11 transfer protocols, such as: IMAP, Microsoft Exchange, POP3, SMTP, and/or the like. A
12 mail client may communicate to and/or with other components in a component 13 collection, including itself, and/or facilities of the like. Most frequently, the mail client 14 communicates with mail servers, operating systems, other mail clients, and/or the like;
e.g., it may contain, communicate, generate, obtain, and/or provide program 16 component, system, user, and/or data communications, requests, information, and/or 17 responses. Generally, the mail client provides a facility to compose and transmit 18 electronic mail messages.

19 Cryptographic Server [00239] A cryptographic server component 5320 is a stored program component 21 that is executed by a CPU 5303, cryptographic processor 5326, cryptographic processor 22 interface 5327, cryptographic processor device 5328, and/or the like.
Cryptographic 1 processor interfaces will allow for expedition of encryption and/or decryption requests 2 by the cryptographic component; however, the cryptographic component, alternatively, 3 may run on a conventional CPU. The cryptographic component allows for the 4 encryption and/or decryption of provided data. The cryptographic component allows for both symmetric and asymmetric (e.g., Pretty Good Protection (PGP)) encryption and/or 6 decryption. The cryptographic component may employ cryptographic techniques such 7 as, but not limited to: digital certificates (e.g., X.5o9 authentication framework), digital 8 signatures, dual signatures, enveloping, password access protection, public key 9 management, and/or the like. The cryptographic component will facilitate numerous 1o (encryption and/or decryption) security protocols such as, but not limited to: checksum, 11 Data Encryption Standard (DES), Elliptical Curve Encryption (ECC), International Data 12 Encryption Algorithm (IDEA), Message Digest 5 (MD5, which is a one way hash 13 function), passwords, Rivest Cipher (RC5), Rijndael, RSA (which is an Internet 14 encryption and authentication system that uses an algorithm developed in 1977 by Ron Rivest, Adi Shamir, and Leonard Adleman), Secure Hash Algorithm (SHA), Secure 16 Socket Layer (SSL), Secure Hypertext Transfer Protocol (HTTPS), and/or the like.
17 Employing such encryption security protocols, the HUB may encrypt all incoming i8 and/or outgoing communications and may serve as node within a virtual private 19 network (VPN) with a wider communications network. The cryptographic component facilitates the process of "security authorization" whereby access to a resource is 21 inhibited by a security protocol wherein the cryptographic component effects authorized 22 access to the secured resource. In addition, the cryptographic component may provide 23 unique identifiers of content, e.g., employing and MD5 hash to obtain a unique 24 signature for an digital audio file. A cryptographic component may communicate to 1 and/or with other components in a component collection, including itself, and/or 2 facilities of the like. The cryptographic component supports encryption schemes 3 allowing for the secure transmission of information across a communications network 4 to enable the HUB component to engage in secure transactions if so desired.
The cryptographic component facilitates the secure accessing of resources on the HUB and 6 facilitates the access of secured resources on remote systems; i.e., it may act as a client 7 and/or server of secured resources. Most frequently, the cryptographic component 8 communicates with information servers, operating systems, other program components, 9 and/or the like. The cryptographic component may contain, communicate, generate, obtain, and/or provide program component, system, user, and/or data communications, 11 requests, and/or responses.

12 The HUB Database 1310024o] The HUB database component 5319 may be embodied in a database and 14 its stored data. The database is a stored program component, which is executed by the CPU; the stored program component portion configuring the CPU to process the stored 16 data. The database may be a conventional, fault tolerant, relational, scalable, secure 17 database such as Oracle or Sybase. Relational databases are an extension of a flat file.
18 Relational databases consist of a series of related tables. The tables are interconnected 19 via a key field. Use of the key field allows the combination of the tables by indexing against the key field; i.e., the key fields act as dimensional pivot points for combining 21 information from various tables. Relationships generally identify links maintained 22 between tables by matching primary keys. Primary keys represent fields that uniquely 1 identify the rows of a table in a relational database. More precisely, they uniquely 2 identify rows of a table on the "one" side of a one-to-many relationship.

3 100941] Alternatively, the HUB database may be implemented using various 4 standard data-structures, such as an array, hash, (linked) list, struct, structured text file (e.g., XML), table, and/or the like. Such data-structures may be stored in memory 6 and/or in (structured) files. In another alternative, an object-oriented database may be 7 used, such as Frontier, ObjectStore, Poet, Zope, and/or the like. Object databases can a include a number of object collections that are grouped and/or linked together by 9 common attributes; they may be related to other object collections by some common 1o attributes. Object-oriented databases perform similarly to relational databases with the 11 exception that objects are not just pieces of data but may have other types of 12 functionality encapsulated within a given object. If the HUB database is implemented as 13 a data-structure, the use of the HUB database 5319 may be integrated into another 14 component such as the HUB component 5335. Also, the database may be implemented as a mix of data structures, objects, and relational structures. Databases may be 16 consolidated and/or distributed in countless variations through standard data 17 processing techniques. Portions of databases, e.g., tables, may be exported and/or 1s imported and thus decentralized and/or integrated.

19 [ O o 2 4 21 In one embodiment, the database component 5319 includes several tables 5319a-i. A Contacts table 5319a may include fields such as, but not limited to:
21 contact_ID, contact-name, postal-address(es), email address(es), phone-number(s), 22 instant_messenger_ID(s), property_ID(s), user-status, activity-11)(s), 23 related_contact_ID(s), job-title(s), role_ID(s), client_ID(s), client_role(s), 1 client_type(s), priority-status, and/or the like. The Contacts table may support and/or 2 track multiple entity accounts on a HUB. In one implementation, user profiles and/or 3 user information may be stored in the contacts table. In another implementation, user 4 profiles and/or other user information may be stored in association with an independent users table. In one implementation, client roles and/or types may indicate 6 a relationship between the user and/or contact and the client (e.g., tenant client, 7 landlord client, and/or the like), and may act as query linkages that pivot off the user's 8 selected role. A Properties table 5319b may include fields such as, but not limited to:
9 property_ID, property_name, property-type, property_dimensions, address, lo price-parameter(s), transaction-history, contact_ID(s), property-status, 11 property-type, activity-ID(s), transaction-information, rating-indicator(s), and/or the 12 like. An Activities table 5319c may include fields such as, but not limited to: activity_ID, 13 activity_name, contact_ID(s), property_ID(s), contact-attribute(s), 14 property-attribute(s), rating indicator(s), transaction-information, role_ID(s), client_ID(s), time, date, user-ID(s), activity_type, and/or the like. A Role Profiles table 1s 5319d may include fields such as, but not limited to: role_ID, 17 role_UI_matrix_element(s), role_query_matrix_element(s), role_name, role-type, 18 and/or the like. A market data table 5319e includes fields such as, but not limited to:
19 market_data_feed_ID, property-ID, spot-price, bid_price, ask-price, interest-rate, and/or the like; in one embodiment, the market data table is populated through a 21 market data feed (e.g., Bloomberg's PhatPipe, Dun & Bradstreet, Reuter's Tib, Triarch, 22 etc.), for example, through Microsoft's Active Template Library and Dealing Object 23 Technology's real-time toolkit Rtt.Multi. A Marketing Templates table 5319f may 24 include fields such as, but not limited to: template_ID, template-name, contact_ID(s), 1 property_ID(s), authorization-criteria, and/or the like. A Messages table 53198 may 2 include fields such as, but not limited to: message_ID, sender_ID, contact_ID(s), 3 property_ID(s), sender-address(es), message-source, message-format, recipient 4 address(es), subject, message_data, attachment(s), link(s), embedded-data, and/or the like. A Message Rules table 5319h may include fields such as, but not limited to:
6 rule_ID, rule-name, rule_input(s), categories, sub-categories, folder_ID(s), 7 folder-name(s), and/or the like. A Message Summaries table 5319i may include fields 8 such as, but not limited to: message_summary_ID, message_summary_name, 9 contact_ID(s), message_ID(s), statistics, analytics, time, message-source, and/or the like. A Leads table 5319) may include fields such as, but not limited to:
Lead_ID, 11 match-score, property-inputs, input-user, site_drive, marketing-idea, contact_ID(s), 12 message_ID(s), property_ID(s), activity_ID(s), statistics, analytics, time, 13 message-source, and/or the like.

14 [O O 2 4 31 In one embodiment, the HUB database may interact with other database systems. For example, employing a distributed database system, queries and data access 16 by search HUB component may treat the combination of the HUB database, an 17 integrated data security layer database as a single database entity.

18 1002441 In one embodiment, user programs may contain various user interface 19 primitives, which may serve to update the HUB. Also, various accounts may require custom database tables depending upon the environments and the types of clients the 21 HUB may need to serve. It should be noted that any unique fields may be designated as 22 a key field throughout. In an alternative embodiment, these tables have been 23 decentralized into their own databases and their respective database controllers (i.e., 1 individual database controllers for each of the above tables). Employing standard data 2 processing techniques, one may further distribute the databases over several computer 3 systemizations and/or storage devices. Similarly, configurations of the decentralized 4 database controllers may be varied by consolidating and/or distributing the various database components 5319a-j. The HUB may be configured to keep track of various 6 settings, inputs, and parameters via database controllers.

7 [ 0 0 24 5 ] The HUB database may communicate to and/or with other components in 8 a component collection, including itself, and/or facilities of the like.
Most frequently, the 9 HUB database communicates with the HUB component, other program components, 1o and/or the like. The database may contain, retain, and provide information regarding 11 other nodes and data.

12 The HUBs 13 [00246] The HUB component 5335 is a stored program component that is executed 14 by a CPU. In one embodiment, the HUB component incorporates any and/or all combinations of the aspects of the HUB that was discussed in the previous figures. As 16 such, the HUB affects accessing, obtaining and the provision of information, services, 17 transactions, and/or the like across various communications networks.

18 [ o 0 2 4 7 ] The HUB component enables the generation, evaluation, and recording of 19 information and activities related to property transactions and the communications surrounding them as well as the relationships' dependencies, work flows, activites 21 related to activity tracking, property transaction facilitation, intelligent inbox 22 coordination, message analysis, summary message generation, rule generation, lead 1 exchange facilitation, lead identification and/or generation, and/or the like and use of 2 the HUB.

3 [00248] The HUB component enabling access of information between nodes may 4 be developed by employing standard development tools and languages such as, but not limited to: Apache components, Assembly, ActiveX, binary executables, (ANSI) 6 (Objective-) C (++), C# and/or NET, database adapters, CGI scripts, Java, JavaScript, 7 mapping tools, procedural and object oriented development tools, PERL, PHP, Python, 8 shell scripts, SQL commands, web application server extensions, web development 9 environments and libraries (e.g., Microsoft's ActiveX; Adobe AIR, FLEX &
FLASH;
1o AJAX; (D)HTML; Dojo, Java; JavaScript; jQuery(UI); MooTools; Prototype;
11 script.aculo.us; Simple Object Access Protocol (SOAP); SWFObject; Yahoo!
User 12 Interface; and/or the like), WebObjects, and/or the like. In one embodiment, the HUB
13 server employs a cryptographic server to encrypt and decrypt communications. The 14 HUB component may communicate to and/or with other components in a component collection, including itself, and/or facilities of the like. Most frequently, the HUB
16 component communicates with the HUB database, operating systems, other program 17 components, and/or the like. The HUB may contain, communicate, generate, obtain, 18 and/or provide program component, system, user, and/or data communications, 19 requests, and/or responses.

Distributed HUBs 21 [002491 The structure and/or operation of any of the HUB node controller 22 components may be combined, consolidated, and/or distributed in any number of ways 23 to facilitate development and/or deployment. Similarly, the component collection may 1 be combined in any number of ways to facilitate deployment and/or development. To 2 accomplish this, one may integrate the components into a common code base or in a 3 facility that can dynamically load the components on demand in an integrated fashion.

4 [0025o] The component collection may be consolidated and/or distributed in countless variations through standard data processing and/or development techniques.
6 Multiple instances of any one of the program components in the program component 7 collection may be instantiated on a single node, and/or across numerous nodes to 8 improve performance through load-balancing and/or data-processing techniques.
9 Furthermore, single instances may also be distributed across multiple controllers 1o and/or storage devices; e.g., databases. All program component instances and 11 controllers working in concert may do so through standard data processing 12 communication techniques.

13 [00251] The configuration of the HUB controller will depend on the context of 14 system deployment. Factors such as, but not limited to, the budget, capacity, location, and/or use of the underlying hardware resources may affect deployment requirements 16 and configuration. Regardless of if the configuration results in more consolidated 17 and/or integrated program components, results in a more distributed series of program 18 components, and/or results in some combination between a consolidated and 19 distributed configuration, data may be communicated, obtained, and/or provided.
Instances of components consolidated into a common code base from the program 21 component collection may communicate, obtain, and/or provide data. This may be 22 accomplished through intra-application data processing communication techniques 23 such as, but not limited to: data referencing (e.g., pointers), internal messaging, object 1 instance variable communication, shared memory space, variable passing, and/or the 2 like.

3 [00252] If component collection components are discrete, separate, and/or 4 external to one another, then communicating, obtaining, and/or providing data with and/or to other component components may be accomplished through inter-application 6 data processing communication techniques such as, but not limited to:
Application 7 Program Interfaces (API) information passage; (distributed) Component Object Model 8 ((D)COM), (Distributed) Object Linking and Embedding ((D)OLE), and/or the like), 9 Common Object Request Broker Architecture (CORBA), local and remote application 1o program interfaces Jini, Remote Method Invocation (RMI), SOAP, process pipes, shared 11 files, and/or the like. Messages sent between discrete component components for inter-12 application communication or within memory spaces of a singular component for intra-13 application communication may be facilitated through the creation and parsing of a 14 grammar. A grammar may be developed by using standard development tools such as lex, yacc, XML, and/or the like, which allow for grammar generation and parsing 16 functionality, which in turn may form the basis of communication messages within and 17 between components. For example, a grammar may be arranged to recognize the tokens 18 of an HTTP post command, e.g.:

19 w3c -post http://... Valuel 21 [002531 where Valuer is discerned as being a parameter because "http://" is part of 22 the grammar syntax, and what follows is considered part of the post value.
Similarly, 23 with such a grammar, a variable "Valuer" may be inserted into an "http://"
post 24 command and then sent. The grammar syntax itself may be presented as structured data 1 that is interpreted and/or otherwise used to generate the parsing mechanism (e.g., a 2 syntax description text file as processed by lex, yacc, etc.). Also, once the parsing 3 mechanism is generated and/or instantiated, it itself may process and/or parse 4 structured data such as, but not limited to: character (e.g., tab) delineated text, HTML, structured text streams, XML, and/or the like structured data. In another embodiment, 6 inter-application data processing protocols themselves may have integrated and/or 7 readily available parsers (e.g., the SOAP parser) that may be employed to parse (e.g., 8 communications) data. Further, the parsing grammar may be used beyond message 9 parsing, but may also be used to parse: databases, data collections, data stores, 1o structured data, and/or the like. Again, the desired configuration will depend upon the 11 context, environment, and requirements of system deployment. The following resources 12 may be used to provide example embodiments regarding SOAP parser implementation:

13 http://www.xav.com/per]./site/lib/SOAP/Parser.html http://publib.boulder.ibm.com/infocenter/tivihelp/v2rl/index.jsp?topic=/com.ibm .IBMDI.doc/referenceguide295.htm 16 1002-54] and other parser implementations:

http://publib.boulder.ibm.com/infocenter/tivihelp/v2rl/index.jsp?topic=/com.ibm 18 .IBMDI.doc/referenceguide259.htm 19 [o 0 2 5 5 ] all of which are hereby expressly incorporated by reference.
[00256]

21 [002571 In order to address various issues and improve over previous works, the 22 application is directed to HUB. The entirety of this application (including the Cover 23 Page, Title, Headings, Field, Background, Summary, Brief Description of the Drawings, 24 Detailed Description, Claims, Abstract, Figures, Appendices, and otherwise) shows by way of illustration various embodiments in which the claimed inventions may be 1 practiced. The advantages and features of the application are of a representative sample 2 of embodiments only, and are not exhaustive and/or exclusive. They are presented only 3 to assist in understanding and teach the claimed principles. It should be understood that 4 they are not representative of all claimed inventions. As such, certain aspects of the disclosure have not been discussed herein. That alternate embodiments may not have 6 been presented for a specific portion of the invention or that further undescribed 7 alternate embodiments may be available for a portion is not to be considered a 8 disclaimer of those alternate embodiments. It will be appreciated that many of those s undescribed embodiments incorporate the same principles of the invention and others io are equivalent. Thus, it is to be understood that other embodiments may be utilized and 11 functional, logical, organizational, structural and/or topological modifications may be 12 made without departing from the scope and/or spirit of the disclosure. As such, all 13 examples and/or embodiments are deemed to be non-limiting throughout this 14 disclosure. Also, no inference should be drawn regarding those embodiments discussed herein relative to those not discussed herein other than it is as such for purposes of 16 reducing space and repetition. For instance, it is to be understood that the logical 17 and/or topological structure of any combination of any program components (a 18 component collection), other components and/or any present feature sets as described ,s in the figures and/or throughout are not limited to a fixed operating order and/or arrangement, but rather, any disclosed order is exemplary and all equivalents, 21 regardless of order, are contemplated by the disclosure. Furthermore, it is to be 22 understood that such features are not limited to serial, execution, but rather, any 23 number of threads, processes, services, servers, and/or the like that may execute 24 asynchronously, concurrently, in parallel, simultaneously, synchronously, and/or the 1 like are contemplated by the disclosure. As such, some of these features may be 2 mutually contradictory, in that they cannot be simultaneously present in a single 3 embodiment. Similarly, some features are applicable to one aspect of the invention, and 4 inapplicable to others. In addition, the disclosure includes other inventions not presently claimed. Applicant reserves all rights in those presently unclaimed inventions 6 including the right to claim such inventions, file additional applications, continuations, 7 continuations in part, divisions, and/or the like thereof. As such, it should be 8 understood that advantages, embodiments, examples, functional, features, logical, 9 organizational, structural, topological, and/or other aspects of the disclosure are not to 1o be considered limitations on the disclosure as defined by the claims or limitations on 11 equivalents to the claims. It is to be understood that, depending on the particular needs 12 and/or characteristics of a HUB individual and/or enterprise user, database 13 configuration and/or relational model, data type, data transmission and/or network 14 framework, syntax structure, and/or the like, various embodiments of the HUB, may be implemented that enable a great deal of flexibility and customization. For example, 16 aspects of the HUB may be adapted for other types of commerce, transactions of 17 services, chattels, and/or the like, non-commercial exchanges, transactions of property 18 and/or real estate in a virtual world, and/or the like. While various embodiments and 19 discussions of the HUB have been directed to real estate listings and transactions, especially as mediated by real estate brokers, however, it is to be understood that the 21 embodiments described herein may be readily configured and/or customized for a wide 22 variety of other applications and/or implementations.

Claims (152)

What is claimed is:

1. An activity recording processor-implemented method, comprising:
receiving a contact identifier;

retrieving contact information associated with the contact identifier;
retrieving contact property attributes associated with the contact identifier;

receiving user property attributes;

providing by the processor a correlated display of contact property attributes and user property attributes;

recording at least one activity snapshot comprising at least one contact property attribute, at least one user property attribute, the contact identifier, and a timestamp; and storing the recorded at least one activity snapshot in an activity database.

2. The method of claim 1, wherein the user property attributes are desired property attributes and the contact property attributes are available property attributes.

3. The method of claim 1, wherein the user property attributes are available property attributes and the contact property attributes are desired property attributes.

4. The method of claim 1, wherein the correlated display comprises a side-by-side display of the contact property attributes and the user property attributes, wherein each line corresponds to a given property attribute.

5. The method of claim 4, further comprising:

receiving a rating indicator value in association with at least one line, wherein the rating indicator value indicates a perceived similarity between a line-associated contact property attribute and a line-associated user property attribute; and wherein the at least one activity snapshot further comprises the rating indicator value.

6. The method of claim 1, wherein the contact identifier is associated with a transactional counterparty.

7. The method of claim 6, wherein the transactional counterparty is any one of: a property buyer, a property seller, a landlord, a tenant, a landlord broker, investment sales broker, specialty leasing agent, a tenant broker, a leasing agent, a property manager, a business developer, a dispositioner, a real estate professional, and a municipality representative.

8. The method of claim 6, wherein the transactional counterparty is a real estate professional.

9.The method of claim of wherein the real estate professional is a property broker.

10. The method of claim 6, wherein the transactional counterparty is a property owner.

11. The method of claim 6, wherein the transactional counterparty is a property purchaser.

12. The method of claim 1, wherein recording at least one activity snapshot further comprises:

recording a plurality of activity snapshots.

13. The method of claim 1, further comprising:
receiving a client identifier; and wherein the at least one activity snapshot further includes the client identifier.

14. The method of claim 1, further comprising:

receiving query parameters comprising at least one of a requested contact identifier, a requested contact property attribute. and a requested user property attribute;

generating a query statement based on the received query parameters;
querying the activity database based on the query statement; and retrieving the at least one activity snapshot based on the querying.

15. The method of claim 14, further comprising:

receiving a client identifier, wherein the at least one activity snapshot further includes the client identifier; and wherein query parameters further comprise the client identifier.

16. The method of claim 1, further comprising:

receiving user notes; and wherein the at least one activity snapshot further includes the user notes.

17. The method of claim 1, further comprising:

receiving a user role specification comprising either a property acquisition role or a property provision role;

wherein the user property attributes are desired property attributes and the contact property attributes are available property attributes if the received user role specification comprises a property acquisition role; and wherein the user property attributes are available property attributes and the contact property attributes are desired property attributes if the received user role specification comprises a property provision role.

18. The method of claim 1, further comprising:

providing contact property attributes for display to a user;

receiving selection or a subset of contact property attributes associated with a particular property; and wherein providing by the processor a correlated display of contact property attributes and user property attributes further comprises:

populating the correlated display with the subset of contact property attributes associated with the particular property.

19. The method of claim 1, further comprising:

repeatedly recording further activity snapshots until receipt of an activity termination indicator or a new contact identifier.

20. An activity recording processor-implemented method comprising:
receiving a contact identifier;

retrieving contact information associated with the contact identifier;
retrieving contact prospect attributes associated with the contact identifier;

retrieving user requirement attributes;

providing by the processor a correlated display of contact prospect attributes and user requirement attributes;

recording at least one activity snapshot comprising at least one contact prospect attribute, at least one user requirement attribute, the contact identifier, and a timestamp; and storing the recorded at least one activity snapshot in an activity database.

21. An activity recording apparatus, comprising:
a memory;

a processor disposed in communication with the memory and configured to issue a plurality of processing instructions stored in the memory, wherein the processor issues instructions to:

receive a contact identifier;

retrieve contact information associated with the contact identifier;
retrieve contact property attributes associated with the contact identifier;
receive user property attributes;

provide by the processor a correlated display of contact property attributes and user property attributes;

record at least one activity snapshot comprising at least one contact property attribute, at least one user property attribute, the contact identifier, and a timestamp; and store the recorded at least one activity snapshot in an activity database.

22. An activity recording processor-accessible medium, comprising:

a plurality of processing instructions stored in the medium and issuable by the processor to:

receive a contact identifier;

retrieve contact information associated with the contact identifier;
retrieve contact property attributes associated with the contact identifier;
receive user property attributes;

provide by me processor a correlated display of contact property attributes and user property attributes;

record at least one activity snapshot comprising at least one contact property attribute, at least one user property attribute, the contact identifier, and a timestamp; and store the recorded at least one activity snapshot in an activity database.

23. An activity recording processor-implemented system, comprising:
means to receive a contact identifier;

means to retrieve contact information associated with the contact identifier;

means to retrieve contact property attributes associated with the contact identifier;

means to receive user property attributes;

means to provide by the processor a correlated display of contact property attributes and user property attributes;

means to record at least one activity snapshot comprising at least one contact property attribute, at least one user property attribute, the contact identifier, and a timestamp; and means to store the recorded at least one activity snapshot in an activity database.

24. A linkage query generating processor-implemented method, comprising:
receiving a user identifier;

receiving a user role specification;

selecting a user interface based on the role specification;

generating a linkage query based on the user identifier and the role specification;

querying linked contact information from a contact-role database using the linkage query;

providing linked contact information retrieved in response to the querying to the selected user interface configured to provide the provided linked contact information for user selection;

receiving a linkage target contact selection from a selection from the linked contact information;

retrieving property attribute information based on the linkage target contact selection; and populating at least one portion of the user interface with the retrieved property attribute information.

25. The method of claim 24, wherein the user interface is a bifurcated user interface.

26. The method of claim 25, wherein the at least one portion of the user interface is a site requirements side of the bifurcated user interface.

27. The method of claim 24, further comprising:

generating a query based on the retrieved property attribute information;

querying matching property information from a property database based on the generated query; and providing the matching property information for display by the user interface.

28. The method of claim 24, further comprising:
receiving a new role specification;

generating a new linkage query and a new linkage target contact based on the new role; and updating the user interface based on the new linkage target contact.

29. The method of claim 24, wherein the contact information includes role links and property links.

3o. The method of claim 29, wherein the role links include a unique user identifier, a contact's role, and a counter-contact's role.

31. The method of claim 29, wherein the property links include a property type, a unique property identifier, a desired transaction type, and transaction requirements.

32. The method of claim 31, wherein the property type may be a lease or purchase type.

33. The method or claim 31, wherein the property type may include a property type descriptor including commercial lot, commercial building.

34. The method of claim 31, wherein the desired transaction type may be a property lease or property sale.

35. The method of claim 31, wherein the transaction requirements may include site requirements.

36. The method of claim 24, wherein the property information is associated with a unique barcode.

37. The method of claim 24, wherein the property attribute information includes a property location, and wherein populating at least one portion of the user interface with the retrieved property attribute information further comprises:

instructing generation of a property map based on the property location.

38. A property mapping processor-implemented method, comprising:
receiving a mapping instruction comprising at least one user interface contextual cue;

accessing property query parameters based on the mapping instruction;
querying property records from based on the accessed property query parameters;

retrieving property records based on the querying; and providing the retrieved property records for display in a map interface according to geocode information associated with the property records.

39. The method of claim 38, further comprising:

determining layer assignments for each of the retrieved property records;
and configuring display characteristics of the retrieved property records based on the layer assignments.

40. The method of claim 39, wherein layer assignments are determined, at least in part, based on a specified user role.

41. The method of claim 38, wherein accessing property query parameters further comprises:

retrieving a client identifier corresponding to a current communication session;

querying client target property characteristics from a client profile based on the retrieved client identifier; and wherein the property query parameters are the client target property characteristics.

42. The method of claim 38, wherein accessing property records further comprises:

retrieving property query parameters from a bifurcated display.

43. The method of claim 42, wherein the property query parameters are site requirements.

44. The method of claim 42, wherein the property query parameters are available property characteristics.

45. The method of claim 38, further comprising:

providing a plurality of display configuration interface elements for display;

receiving at least one display configuration instruction via at least one of the plurality of display configuration elements; and configuring the map interface based on the at least one display configuration instruction.

46. The method of claim 45, wherein the plurality of display configuration interface elements are selected based on a user role.

47. The method of claim 45, wherein the plurality of display configuration interface elements includes at least a map engine selection element.

48. The method of claim 45, wherein the plurality of display configuration interface elements includes at least a time slider element.

49. The method of claim 48, wherein the at least one display configuration instruction comprises at least one selected time and wherein configuring the map interface based on the at least one display configuration instruction further comprises:
displaying a time snapshot of the retrieved property records at the at least one selected time.

50. The method of claim 45, wherein the plurality of display configuration interface elements includes at least a price slider element.

51. The method of claim 50, wherein the at least one display configuration instruction comprises at least one selected price and wherein configuring the map interface based on the at least one display configuration instruction further comprises:

displaying a subset of the retrieved property records corresponding to the at least one selected price.

52. A search facilitating processor implemented method, comprising:
providing a plurality of variable selection elements for display;

receiving a first variable selection from a first variable selection element of the plurality of variable selection elements;

retrieving a plurality of available first variable values corresponding to the first variable selection;

providing the plurality of available first variable values for display in a selectable listing;

receiving a first variable value selection from the selectable listing;

querying further available variable selections based on the received first variable value selection;

configuring remaining variable selection elements based on the further available variable selections; and retrieving at least one data record based on received variable value selections.

53. The method of claim 52, wherein the plurality of variable selection elements comprise rollable cylinders.

54. The method of claim 52, wherein configuring remaining variable selection elements based on the further available variable selections further comprises:

providing further available variable selections for selectable display on the remaining variable selection elements.

55. A schedule optimizing processor-implemented method, comprising:
receiving an appointment schedule, comprising a plurality of appointments, wherein each appointment includes a time and a location;

determining distances between locations of pairs of appointments in the appointment schedule;

determining time intervals between times of pairs of appointments having distances determined to be within a specified distance range;

generating a rescheduling recommendation message when at least one determined time interval is within a specified time interval range; and providing the rescnedunng recommendation message for display to a user.

56. The method of claim 55, further comprising:

querying priority values for appointments having time intervals determined to be within a specified time interval range; and generating and providing the rescheduling recommendation message only when at least one of the priority values is less than a threshold priority value.

57. The method of claim 55, further comprising:

determining at least one prospective appointment with a contact in a user contact list having a distance to the location of at least one existing appointment of the plurality of appointments less than a pre-set threshold distance; and providing an indicator of the prospective appointment for selectable display.

58. The method of claim 57, further comprising:

receiving a selection of the indicator of the prospective appointment; and sending a confirmation message to an address corresponding to the contact.

59. A real estate listing service system, comprising:
a memory;

a processor disposed in communication with the memory and configured to issue a plurality of processing instructions stored in the memory;

a listing service module, stored in the memory, and configured to engage the processor to access real estate listing information stored in the memory;
and a barcode module, stored in the memory, and configured to engage the processor to receive and generate barcodes associated with the real estate listing information.

60. The system of claim 59, further comprising:

a contact relationship management module, stored in the memory, and configured to engage the processor to access contact information stored in the memory and associated with the real estate listing information, and to track user activities with respect to contacts associated with the contact information.

61. The system of claim 59, wherein the listing service module and the barcode module are accessible from a mobile device.

62. An integrated contact relationship management and real estate listing service system, comprising:

a memory;

a processor disposed in communication with the memory and configured to issue a plurality of processing instructions stored in the memory;

a listing service module, stored in the memory, and configured to engage the processor to access real estate listing information stored in the memory;
and a contact relationship management module, stored in the memory, and configured to engage the processor to access contact information stored in the memory and associated with the real estate listing information, and to track user activities with respect to contacts associated with the contact information.

63. The system of claim 62, wherein the listing service module and the contact relationship management module are accessible from a mobile device.

64. A contact displaying processor implemented method, comprising:
receiving a contact display request;

querying a plurality of stored contact records based on the contact display request;

accessing a subset of contact records based on the querying;

discerning a set of categories associated with the subset of contact records;
determining allocations of contact records in the subset of contact records to each category of the set of categories;

determining display characteristics of the subset of contact records based on a number of contact records in the subset of contact records; and providing a correlated display of the set of categories, the allocations, and the subset of contact records, wherein the subset of contact records are configured in accordance with the display characteristics.

65. The method of claim 64, wherein determining display characteristics of the subset of contact records based on a number of contact records in the subset of contact records further comprises:

configuring a full-size display when the number of contact records is one.

66. The method of claim 64, further comprising:

sorting the subset of contact records.

67. The method of claim 66, wherein sorting the subset of contact records further comprises:

determining a communication frequency associated with each contact record of the subset of contact records; and sorting the subset of contact records in order of descending communication frequency.

68. An intelligent inbox coordinating processor-implemented method, comprising:

retrieving at least one message from a message repository;

identifying at least one data source associated with the at least one message;

accessing the at least one data source to extract target data;

analyzing the target data to determine at least one category association of the at least one message;

incrementing a counter for at least one category identifier based on the at least one category association;

generating a summary message including analytics based on the at least one counter; and providing the summary message for display.

69. The method of claim 68, wherein the at least one message comprises at least one email message.

70. The method of claim 69, wherein the message repository comprises an email folder, and wherein the at least one email message is allocated to the email folder based on at least one email allocation rule.

71. The method of claim 68, wherein the message repository comprises a third-party data warehouse.

72. The method of claim 68, wherein the at least one data source comprises an attached file.

73. The method of claim 68, wherein the at least one data source is accessible via a link embedded in the at least one message.

74. The he method of claim 73, wherein the at least one data source comprises a web page.

75. The method of claim 73, wherein the at least one data source comprises a linked file.

76. The method of claim 68, wherein the at least one message is retrieved in response to a mobile device code capture.

77. The method of claim 68, wherein the at least one category association comprises at least one property category.

78. The method of claim 68, wherein the at least one property category comprises a real estate property category.

79. The method of claim 68, further comprising:

receiving at least one message response trigger in association with the at least one message;

generating a response message based on the at least one message response trigger; and sending the response message to an originator of the at least one message.

8o. The method of claim 79, wherein the at least one message response trigger comprises a gut feel indicator.

81. The method of claim 79, further comprising:

updating at least one category message response trigger aggregation record associated with the at least one category identifier based on the received at least one message response trigger; and publishing the at least one category message response trigger aggregation record.

82. The method of claim 68, further comprising:

receiving at least one message response trigger in association with the at least one message;

querying additional recipients based on the at least one category association when the at least one message response trigger satisfies positive reaction criteria; and providing the at least one message to the additional recipients.

83. An intelligent inbox coordinating processor-implemented method, comprising:

periodically retrieving a plurality of email messages addressed to a user from at least one designated email message folder, wherein the plurality of email messages are previously directed to the at least one designated email message folder based on an evaluation of the plurality of email messages in relation to at least one email direction rule;

identifying at least one flyer file associated with each email message of the plurality of email messages, wherein the at least one flyer file is configured as either an attached portable document format file, a linked remote portable document format file, or a linked webpage;

accessing the at least one flyer file to extract property data, wherein accessing includes downloading the flyer file when configured as an attached portable document format file, and accessing an associated link when configured as either a linked remote portable document format file or a linked webpage, and wherein extracting property data includes converting the at least one flyer file to text;

analyzing extracted property data to determine property category associations of the plurality of email messages, wherein analyzing includes:

parsing the extracted property data into a plurality of data fields, correlating the data fields based on positional proximity in the flyer file, and identifying property data values based on correlation of corresponding data fields with data fields of property data identifiers, and wherein the at least one property category association is at least one of a company, a property type, and an address field;

incrementing counters for property category identifiers based on property category associations; and generating a summary message including statistical analytics based on the counters; and providing the summary message for display to the user.

84. An intelligent inbox coordinating processor-implemented method, comprising:

providing a selectable interface element in association with at least one email message;

receiving a selection of the selectable interface element;

correlating the selectable interface element with at least one email folder;
extracting email data from the at least one email message;

generating an email direction rule based on the email data, wherein the email direction rule is configured to direct future email messages having characteristics matching the email data to the at least one email folder.

85. The method of claim 84, further comprising:
providing the email direction rule for approval; and receiving an approval indicator in response to the providing.

86. A property listing service generating processor-implemented method, comprising:

receiving at least one property data message;

analyzing the at least one property data message to extract property information;

correlating extracted property information with at least one property category designation; and updating a property listing service based on the correlating.

87. The method of claim 86, wherein the at least one property data message comprises an email message.

88. The method of claim 86, wherein the at least one property data message is received in response to at least one mobile device code capture.

89. An intelligent inbox coordinating apparatus, comprising:
a memory;

a processor disposed in communication with the memory and configured to issue a plurality of processing instructions stored in the memory, wherein the processor issues instructions to:

retrieve at least one message from a message repository;

identify at least one data source associated with the at least one message;
access the at least one data source to extract target data;

analyze the target data to determine at least one category association of the at least one message;

increment a counter for at least one category identifier based on the at least one category association;

generate a summary message including analytics based on the at least one counter; and provide the summary message for display.

9o. An intelligent inbox coordinating processor-accessible medium, comprising:

a plurality of processing instructions stored in the medium and issuable by a processor to:

retrieve at least one message from a message repository;

identify at least one data source associated with the at least one message;
access the at least one data source to extract target data;

analyze the target data to determine at least one category association of the at least one message;

increment a counter for at least one category identifier based on the at least one category association;

generate a summary message including analytics based on the at least one counter; and provide the summary message for display.

91. An intelligent inbox coordinating processor-implemented system, comprising:

means to retrieve at least one message from a message repository;

means to identify at least one data source associated with the at least one message;

means to access the at least one data source to extract target data;

means to analyze the target data to determine at least one category association of the at least one message;

means to increment a counter for at least one category identifier based on the at least one category association;

means to generate a summary message including analytics based on the at least one counter; and means to provide the summary message for display.

92. A lead service exchange facilitating processor-implemented method, comprising:

receiving a lead request comprising lead criteria from a requestor;
querying a lead database based on the lead criteria to retrieve a plurality of candidate lead matches, wherein each candidate lead match is associated with at least one of a plurality of candidate lead match owners;

generating a lead sharing request message;

providing the lead sharing request message to each of the plurality of candidate lead match owners;

receiving at least one lead sharing acceptance in response to the lead sharing request message from at least one of the plurality of candidate lead match owners;

providing at least one lead candidate identifier corresponding to the at least one of the plurality of candidate lead match owners for selectable display to the requestor;

receiving selection of the at least one lead candidate identifier from the requestor;

effectuating a compensation to the at least one of the plurality of candidate lead match owners; and providing access to at least one of the plurality of candidate lead matches associated with the at least one of the plurality of candidate lead match owners.

93. The method of claim 92, wherein the at least one of the plurality of candidate lead matches comprises contact information.

94. The method of claim 92, wherein the at least one of the plurality of candidate lead matches comprises site drive information.

95. The method of claim 92, wherein the lead request further comprises a proposed compensation, and wherein the compensation is equal to the proposed compensation.

96. The method of claim 95, wherein querying a lead database further comprises:

comparing the proposed compensation to minimum compensation values for lead matches in the lead database; and retrieving the candidate lead matches having minimum compensation values less than the proposed compensation.

97. The method of claim 96, wherein the minimum compensation value associated with the at least one of a plurality of candidate lead match owners depends on a quality rating associated with the at least one of a plurality of candidate lead match owners.

98. The method of claim 92, wherein providing at least one candidate identifier corresponding to the at least one of the plurality of candidate lead match owners further comprises:

providing at least one quality rating for display in association with the at least one candidate lead identifier.

99. The method of claim 92, wherein the at least one lead sharing acceptance comprises a plurality of lead sharing acceptances and the at least one lead candidate identifier corresponding to the at least one of the plurality of candidate lead matches comprises a plurality of lead candidate identifiers corresponding to each of a plurality of accepting candidate lead matches.

100. The method of claim 99, further comprising:

sorting the plurality of lead candidate identifiers based on sorting criteria to generate a sorted list of lead candidate identifiers; and wherein providing at least one lead candidate identifier further comprises providing the sorted list of lead candidate identifiers.

101. The method of claim 100, wherein the sorting criteria is based on an order of response to the lead sharing request message.

102. The method of claim 100, wherein the sorting criteria is based on differences between a proposed compensation included in the lead request and benchmark compensations associated with each of the plurality of lead candidate identifiers.

103. The method of claim 100, wherein the sorting criteria is based on priority placement statuses associated with each of the plurality of lead candidate identifiers.

104. The method of claim 100, wherein the sorting criteria is based on a match quality associated with each of the plurality of lead candidate identifiers in relation to the lead criteria.

105. The method of claim 100, wherein the sorting criteria is based on a quality rating associated with each of the plurality of accepting candidate lead matches.

1o6. The method of claim 92, further comprising:
receiving a lead quality score from the requestor; and updating a lead quality rating associated with the at least one of the plurality of candidate lead match owners based on the lead quality score.

107. The method of claim 92, further comprising:

providing abridged candidate lead match associated with each of the plurality of candidate lead matches information for selectable display to the requestor;
receiving a selection of at least one of the plurality of candidate lead matches from the requestor; and wherein the lead sharing request message is only provided to the at least one of the plurality of candidate lead matches.

108. The method of claim 92, wherein the lead request further comprises a payment account identifier and wherein effectuating compensation comprises deducting an amount from a requestor account associated with the payment account identifier and crediting the amount to an account associated with the at least one of the plurality of candidate lead match owners.

109. The method of claim 92, wherein effectuating compensation comprises:
receiving indication of a transaction associated with the lead request; and effectuating a payment to the at least one of the plurality of candidate lead match owners comprising a percentage of a transacted amount associated with the transaction.

110. A lead sharing processor implemented method, comprising:

receiving a lead share request from a requestor, the lead share request comprising at least one lead share parameter and a bounty offer;

querying user records based on the at least one lead share parameter;
retrieving at least one matching lead based on the querying;

retrieving a user quality rating corresponding to the user record associated with the retrieved at least one matching lead;

determining a bounty premium based on the user quality rating; and offering the at least one matching lead for display to the requestor in exchange for payment of an acceptance amount equal to the bounty offer summed with the bounty premium.

111. The method of claim 110, further comprising:

receiving an acceptance indicator from the requestor, the acceptance indicator signifying a willingness to pay the acceptance amount; and providing the at least one matching lead for display to the requestor.

112. The method of claim 111, further comprising:

debiting a requestor account for the acceptance amount; and crediting an account corresponding to the user record associated with the retrieved at least one matching lead for the acceptance amount.

113. The method of claim 111, further comprising:

receiving a payment for the acceptance amount from the requestor; and providing the payment to a user corresponding to the user record associated with the retrieved at least one matching lead.

114. The method of claim 111, further comprising:

receiving a payment for the acceptance amount from the requestor;

deducting a service fee from the payment to yield a net payment; and providing the net payment to a user corresponding to the user record associated with the retrieved at least one matching lead.

115. The method of claim no, wherein the lead share request further comprises a target filter, and wherein querying user records based on the at least one lead share parameter is restricted to user records matching the target filter.

116. The method of claim 110, wherein the at least one matching lead comprises a plurality of matching leads.

117. The method of claim 116, further comprising:

sorting the plurality of matching leads based on selected sorting criteria;
and wherein offering the at least one matching lead for display to the requestor further comprises, providing an ordered list of user identifiers corresponding to user records associated with the plurality of matching leads based on the sorting.

118. The method of claim 117, wherein the selected sorting criteria comprises a quality rating of users corresponding to user records associated with the plurality of matching leads.

119. The method or claim 110, wherein the lead share request further comprises a request type selection.

120. The method of claim 119, wherein the request type selection comprises at least one of contact information, marketing idea information and site drive information.

121. The method of claim 119, wherein querying user records based on at least one lead share parameter is restricted to user record fields associated with the request type selection.

122. The method of claim 110, wherein the bounty offer further includes a currency unit selection.

123. The method of claim 110, wherein the bounty premium is zero.

124. An access permissions setting processor implemented method, comprising:

retrieving a list of user contacts associated with a user;

providing an access permissions setting interface, including the list of user contacts, for display to the user;

receiving at least one access permission setting in association with at least one user contact via the access permissions setting interface, the at least one access permission setting comprising at least one of a contact access setting, a marketing idea access setting and a site drive access setting; and storing the at least one access permission setting in association with the at least one user contact and the user.

125. The method of claim 124, wherein the at least one access permission setting comprises at least one of a contact access setting and a marketing idea setting, and further comprising:

providing a second list of user contacts for display to the user;

receiving a user contact selection from the second list of user contacts; and wherein storing the at least one access permission setting is further in association with the user contact selection.

126. The method of claim 124, further comprising:
receiving an access request from a requester;

determining an access permission via the at least one access permission setting and the access request; and if the access permission is true, then:

querying requested information from at least one user record associated with the user based on the access request, retrieving the requested information based on the querying, and providing the requested information for display to the requester;

else:

denying the access request.

127. A lead service exchange facilitating apparatus, comprising:
a memory;

a processor disposed in communication with the memory and configured to issue a plurality of processing instructions stored in the memory, wherein the processor issues instructions to:

receive a lead request comprising lead criteria from a requestor;

query a lead database based on the lead criteria to retrieve a plurality of candidate lead matches, wherein each candidate lead match is associated with at least one of a plurality of candidate lead match owners;

generate a lead sharing request message;

provide the lead sharing request message to each of the plurality of candidate lead match owners;

receive at least one lead sharing acceptance in response to the lead sharing request message from at least one of the plurality of candidate lead match owners;
provide at least one lead candidate identifier corresponding to the at least one of the plurality of candidate lead match owners for selectable display to the requestor;

receive selection of the at least one lead candidate identifier from the requestor;

effectuate a compensation to the at least one of the plurality of candidate lead match owners; and provide access to at least one of the plurality of candidate lead matches associated with the at least one of the plurality of candidate lead match owners.

128. A lead service exchange facilitating medium, comprising:

a plurality of processing instructions stored in the medium and issuable by a processor to:

receive a lead request comprising lead criteria from a requestor;

query a lead database based on the lead criteria to retrieve a plurality of candidate lead matches, wherein each candidate lead match is associated with at least one of a plurality of candidate lead match owners;

generate a lead sharing request message;

provide the lead sharing request message to each of the plurality of candidate lead match owners;

receive at least one lead sharing acceptance in response to the lead sharing request message from at least one of the plurality of candidate lead match owners;
provide at least one lead candidate identifier corresponding to the at least one of the plurality of candidate lead match owners for selectable display to the requestor;

receive selection of the at least one lead candidate identifier from the requestor;

effectuate a compensation to the at least one of the plurality of candidate lead match owners; and provide access to at least one of the plurality of candidate lead matches associated with the at least one of the plurality of candidate lead match owners.

129. A lead sharing apparatus, comprising:
a memory;

a processor disposed in communication with the memory and configured to issue a plurality of processing instructions stored in the memory, wherein the processor issues instructions to:

receive a lead share request from a requestor, the lead share request comprising at least one lead share parameter and a bounty offer;

query user records based on the at least one lead share parameter;
retrieve at least one matching lead based on the querying;

retrieve a user quality rating corresponding to the user record associated with the retrieved at least one matching lead;

determine a bounty premium based on the user quality rating; and offer the at least one matching lead for display to the requestor in exchange for payment of an acceptance amount equal to the bounty offer summed with the bounty premium.

130. A lead sharing processor-accessible medium, comprising:

a plurality of processing instructions stored in the medium and issuable by a processor to:

receive a lead share request from a requestor, the lead share request comprising at least one lead share parameter and a bounty offer;

query user records based on the at least one lead share parameter;
retrieve at least one matching lead based on the querying;

retrieve a user quantity rating corresponding to the user record associated with the retrieved at least one matching lead;

determine a bounty premium based on the user quality rating; and offer the at least one matching lead for display to the requestor in exchange for payment of an acceptance amount equal to the bounty offer summed with the bounty premium.

131. A lead generating processor implemented method, comprising:
receiving a plurality of property parameters;

discerning an input activity associated with the plurality of property parameters;

determining a complementary activity that is complementary to the input activity;

generating a query statement based on the plurality of property parameters and the complementary activity;

querying lead records based on the query statement to identify at least one matching lead record; and providing the at least one matching lead record.

132. The method of claim 131, wherein the at least one matching lead record is identified by leveraging connectivity with at least one of: a contact relationship management feature; a property listing service feature; and an intelligent inbox coordination feature.

133. The method of claim 132, wherein the at least one matching lead record is identified using historical activity extracted from the at least one of: a contact relationship management feature; a property listing service feature; and an intelligent inbox coordination feature.

134. The method of claim 131, further comprising:

evaluating a match quality for the at least one matching lead record;
comparing the match quality to a threshold match value; and wherein the at least one matching lead record is only provided if the match quality exceeds the threshold match value.

135. The method of claim 131, wherein the query statement is further based on the input activity.

136. The method of claim 131, further comprising:
determining a contact subset; and wherein querying lead records is limited to the contact subset.

137. The method of claim 136, wherein the contact subset is a contact set of a user from which the plurality of property parameters is received.

138. The method of claim 131, wherein the plurality of property parameters are received from a user, and wherein providing the at least one matching lead record comprises providing notice of the at least one matching record to the user.

139. The method of claim 131, wherein the plurality of property parameters are received in response to a code capture.

14o. The method of claim 131, wherein the plurality of property parameters are received via a bifurcated display.

141. The method of claim 131, wherein the plurality of property parameters are extracted from at least one email message.

142. The method of claim 131, wherein the at least one matching lead record is a property listing record.

143. The method of claim 1, wherein the at least one matching lead record is a contact record.

144. The method of claim 131, wherein the at least one matching lead record corresponds to a site drive.

145. The method of claim 131, wherein the at least one matching lead record corresponds to a marketing idea.

146. A lead generating processor-implemented method, comprising:
identifying a transactional counterparty associated with a current activity;

querying at least one record associated with the transactional counterparty to retrieve at least one lead prospect;

retrieving at least one lead prospect record associated with the at least one lead prospect;

comparing data field entries of the at least one lead prospect record with activity data elements associated with the current activity to yield a lead match rating;
and generating a lead notification when the lead match rating is greater than a threshold.

147. The method of claim 146, wherein the transactional counterparty is a broker, and wherein the at least one lead prospect record is associated with a client of the broker.

148. The method of claim 146, further comprising:
comparing the lead match rating to a threshold; and wherein a lead notification is only generated if the lead match rating exceeds the threshold.

149. The method of claim 146, wherein the threshold is equal to a current lead match rating associated with the current activity.

150. The method of claim 146, wherein the lead match rating is determined based on a weighted sum.

151. A lead generating apparatus, comprising:
a memory;

a processor disposed in communication with the memory and configured to issue a plurality of processing instructions stored in the memory, wherein the processor issues instructions to:

receive a plurality of property parameters;

discern an input activity associated with the plurality of property parameters;

determine a complementary activity that is complementary to the input activity;

generate a query statement based on the plurality of property parameters and the complementary activity;

query lead records based on the query statement to identify at least one matching lead record; and provide the at least one matching lead record.

152. A lead generating medium, comprising:

a plurality of processing instructions stored in the medium and issuable by a processor to:

receive a plurality of property parameters;

discern an input activity associated with the plurality of property parameters;

determine a complementary activity that is complementary to the input activity;

generate a query statement based on the plurality of property parameters and the complementary activity;

query lead records based on the query statement to identify at least one matching lead record; and provide the at least one matching lead record.