Method and apparatus for intermediation of meetings and calls

• US 8,175,904 B2
• Filed: 10/14/1999
• Issued: 05/08/2012
• Est. Priority Date: 10/14/1998
• Status: Active Grant

• Current Assignee: Bradley S. Templeton
• Original Assignee: Bradley S. Templeton
• Inventors: Templeton, Bradley S.
• Primary Examiner(s): Boswell, Beth V
• Assistant Examiner(s): JACKSON, ERNEST ADEYEMI
• Application Number:
  US09/416,278
• Publication Number:
  US 20030191676A1
• Time in Patent Office: 4,590 Days
• Field of Search: 705/7, 705/8, 705/9, 705/7.11, 705/7.12, 709/204, 709/205, 709/206, 709/207
• US Class Current: 705/7.12
• CPC Class Codes: G06Q 10/0631 Resource planning, allocation, distributing or scheduling for enterprises or organisations
• CPC Class Codes: G06Q 10/06311 Scheduling, planning or task assignment for a person or group
• CPC Class Codes: G06Q 10/1095 Meeting or appointment
• CPC Class Codes: H04M 2201/18 Comparators
• CPC Class Codes: H04M 2203/2011 Service processing based on information specified by a party before or during a call, e.g. information, tone or routing selection
• CPC Class Codes: H04M 2203/2072 Schedules, e.g. personal calendars
• CPC Class Codes: H04M 3/42059 Making use of the calling party identifier
• CPC Class Codes: H04M 3/42068 where the identifier is used to access a profile
• CPC Class Codes: H04M 3/42102 Making use of the called party identifier
• CPC Class Codes: H04M 3/4211 where the identifier is used to access a profile
• CPC Class Codes: H04M 3/42229 Personal communication services, i.e. services related to one subscriber independent of his terminal and/or location diverting calls from one subscriber to another subscriber, i.e. two different subscriptions H04M3/54; selecting arrangements in intelligent networks H04Q3/005
• CPC Class Codes: H04M 3/42323 PBX's with CTI arrangements
• CPC Class Codes: H04M 3/42365 Presence services providing information on the willingness to communicate or the ability to communicate in terms of media capability or network connectivity
• CPC Class Codes: H04M 3/42374 where the information is provided to a monitoring entity such as a potential calling party or a call processing server
• CPC Class Codes: H04M 3/432 Arrangements for calling a subscriber at a specific time, e.g. morning call service
• CPC Class Codes: H04M 3/436 Arrangements for screening incoming calls , i.e. evaluating the characteristics of a call before deciding whether to answer it based on the calling party profile H04M3/42059; based on location H04M3/42348; based on presence H04M3/42365; diversion H04M3/54
• CPC Class Codes: H04M 3/48 Arrangements for recalling a calling subscriber when the wanted subscriber ceases to be busy
• CPC Class Codes: H04M 3/4878 Advertisement messages
• CPC Class Codes: H04M 3/523 with call distribution or queueing
• CPC Class Codes: H04M 3/56 Arrangements for connecting several subscribers to a common circuit, i.e. affording conference facilities video conference systems H04N7/15
• CPC Class Codes: H04M 7/006 : Networks other than PSTN/ISDN providing telephone service, e.g. Voice over Internet Protocol (VoIP) , including next generation networks with a packet-switched transport layer H04L65/00 takes precedence; aspects not specific to the type of network H04M3/00; special services in those networks H04M3/42

Abstract

A computer-implemented method and system for assisting in the intermediation of realtime meetings, including telephone calls and face to face meetings. A user informs his system that he wishes to, for example, make a telephone call. The system sends a request for a realtime meeting to the specified target. Both the target and the requester queue the request. When both the requester and the target are mutually available, the realtime meeting can take place. Some embodiments cause this to happen automatically, some prompt the user to take action, such as dialing the telephone.

Claims

1. A computer-implemented method for the intermediation of real time meetings, comprising:

receiving an indication by a requester system that a requester (R-A) wants to request a realtime meeting M-A with a target T-A;

sending to a decider system (D) a request to conduct a real time meeting M-A;

queuing the request for the meeting M-A by the decider system;

receiving by the decider system (D) an availability status of T-A;

receiving by the decider system (D) an availability status of R-A, where a possible availability status includes not available;

receiving an indication by the requester system that a requester (R-B) wants to request a realtime meeting M-B with target T-B, the meeting M-B to be disjoint in time with the meeting M-A; and

such that one of the parties to M-A (R-A or T-A), known as the ‘

common party’

is also the same as one of the parties to M-B (R-B or T-B) and thus there are three distinct parties, the decider D being associated with the common party;

sending to the decider system (D) a request to conduct a real time meeting M-B;

queuing the request for the meeting M-B by the decider system, such that requests for at least two distinct meetings, disjoint in time are placed in the queue, so that multiple pending real time meetings for the common party are in the queue at the same time;

receiving by the decider system (D) an availability status of targer T-B;

receiving by the decider system (D) an availability status of the requester R-B, where a possible availability status includes not available;

initiating, by the decider, one of the two meetings M-A and M-B by connenting the common party and the other party to that meeting when the common party and that other party are mutually available; and

dequeuing the request for a meeting.

2. The method of claim 1, wherein a system of the target T-A is polled to determine the availability of target T-A.

3. The method of claim 1, wherein the system of the target T-A pushes the availability status of target T-A to the decider system.

4. The method of claim 1, wherein a system of a party is polled to determine the party'"'"'s availability.

5. The method of claim 1, wherein the system of a party pushes the party'"'"'s availability status to the decider system.

6. The method of claim 1, wherein mutual availability is determined by checking the availability of one of the target/requester pairs T-A/R-A and T-B/R-B.

7. The method of claim 1, wherein a request is sent to a plurality of targets and mutual availability is determined when the requester and one of the plurality of targets is available.

8. The method of claim 1, further comprising displaying the availability status of one of the requesters R-A and R-B on the target system, along with an indication that one of the requesters R-A and R-B has requested a meeting.

9. The method of claim 8, wherein the availability status is one of in, out, and unknown.

10. The method of claim 1, further comprising displaying an availability status of the target T-A on the requester system, along with an indication that the requestor has requested a meeting with the target.

11. The method of claim 10, wherein the availability status is one of in, out, and unknown.

12. The method of claim 1, wherein the decider system a part of the system of the common party for whom it is responsible, and wherein the decider already knows the status of the common party for which it is responsible.

13. The method of claim 1, wherein the decider system chooses to activate one of two real time meetings, where the parties for both meetings are available, based on at least one of:

ranking information including manual ranking through a user interface presented to the common party;

priority information provided by either party;

the order in time in which the requests were made; and

relationship information about the parties based on party input or past history.

14. The method of claim 1, wherein the decider system chooses to activate one of two real time meetings, where the parties for both meetings are available, based on ranking information including manual ranking through a user interface presented to the common party.

15. The method of claim 1, wherein the decider system chooses to activate one of two real time meetings, where the parties for both meetings are available, based on priority information provided by either party.

16. The method of claim 1, wherein the decider system chooses to activate one of two real time meetings, where the parties for both meetings are available, based on the order in time in which the requests were made.

17. The method of claim 1, wherein the decider system chooses to activate one of two real time meetings, where the parties for both meetings are available, based on relationship information about the parties based on party input or past history.

18. The method of claim 1, wherein a non-common requester R-A or R-B is party to another, distinct meeting request.

19. The method of claim 1, wherein a non-common target is party to another distinct meeting request.

20. The method of claim 1, wherein each of the three systems has requested and has pending requests for two or more real-time meetings in the queue.

21. The method of claim 1, wherein if all parties become available at once, only one of the meetings M-A and M-B will occur immediately and the other meeting will remain queued.

22. The method of claim 1, wherein the common party is the target T-A and T-B.

23. The method of claim 1, wherein the common party is the requestor R-A and R-B and the common party participates in both of the meetings M-A and M-B.

24. the method of claim 1, wherein the target is a specific individual selected by the requestor.

25. The method of claim 1, wherein the target is a specific individual.

26. The method of claim 1, wherein the common party is the requestor R-A and R-B.

27. The method of claim 1, wherein the target is any one of a group of targets.

32. The method of claim 18, wherein the non-common requester R-A or R-B that is party to another distinct meeting request is a target in that meeting request.

33. The method of claim 1, wherein the requestor R-A changes states from not available to available, while waiting for the realtime meeting M-A.

34. The method of claim 1, wherein the requestor R-A participates in another distinct realtime meeting while waiting for the realtime meeting M-A.

35. The method of claim 1, wherein the requester R-A becomes available when the requestor R-A terminates a call.

36. The method of claim 1, wherein the requester R-A and target T-A are both available when they are both off of the phone.

28. A method comprising:

transmitting or receiving at a computing system a first request for a first real-time meeting between a requestor and a first target, the requestor and the first target being individuals;

storing the first request in a queue on the computing system, the queue including more than one request for a real-time meeting;

determining that the first target is unavailable using the computing system, the determination being based on a first signal received by the computing system from an electronic tool of the first target;

waiting until the first target changes from being unavailable to being available;

when the first target is available, determining if the requester is available based on a second signal received by the computing system;

if the requestor is available, then automatically initiating the first real-time meeting using computing instructions stored on a computer readable medium of the computing system; and

if the requester is unavailable, then waiting until a time the requestor becomes available.

29. The method of claim 28, further comprising:

in response to the requester becoming available, determining if the first target is still available;

if the first target is still available, then initiating the first real-time meeting; and

if the first target is unavailable, then waiting until the first target becomes available.

30. The method of claim 28, further comprising:

transmitting or receiving a second request for a second real-time meeting between the first requester and a second target, the second request being transmitted or received between a time the first request is transmitted or received and a time the first real-time meeting is initiated;

storing the second request in the queue; and

initiating the second real-time meeting prior to the first real-time meeting if the second target becomes available before the first target.

31. The method of claim 28, further comprising;

transmitting or receiving a second request for a second real-time meeting between a second requestor and the first target, the second request being transmitted or received between a time the first request is transmitted or received and a time the first real-time meeting is initiated;

storing the second request in the queue; and

initiating the second real-time meeting prior to the first real-time meeting if the second requester becomes available before the first requester.

38. The method of claim 28, further comprising:

in response to the requester becoming available, determining if the first target is still available using computing instructions stored on a computer readable medium of the computing system; and

if the first target is unavailable, then waiting until the first target becomes available.

37. A method comprising:

transmitting or receiving at a computing system a first request for a first real-time meeting between a requestor and a first target, the requestor and the first target being individuals;

determining that the first target is unavailable, using the computing system, the determination being based on a first electronic signal received from the first target;

storing the first request in a queue on the computing system, the queue including more than one request for a real-time meeting;

waiting until the first target changes from being unavailable to being available;

when the first target is available, automatically determining if the requester is available based on a second electronic signal received by the computing system; and

if the requester is unavailable, then waiting until a time the requestor becomes available.