Apparatus and system for providing information required for meeting with desired person while travelling5459859Abstract Disclosed is an apparatus and a system for providing information required for meeting with a desired person while travelling. A subscriber registers his or her attribute data, attribute data of a desired person and his or her travel schedule data through an input/output terminal. Input data is transferred via a communication network to a host computer. Host computer generates information regarding the other party who the subscriber can meet with for each subscriber by processing data transferred from many subscribers. Generated data is stored in an output list file, so that the subscriber is able to know a possibility to meet with a desired person while travelling by making access to the output list file through the input/output terminal. Claims What is claimed is: Description BACKGROUND OF THE INVENTION
TABLE 1
______________________________________
Movement data (from point X to point Y)
______________________________________
(1-1)
Starting of location
October 8, 1990 9:55 a.m.
(1-2)
End of movement October 8, 1990 10:55 a.m.
(2-1)
Starting point: Area
Kyushu
(2-2)
Prefecture Kumamoto
(3-1)
Transportation means
Airplane
(3-2)
Flight No. ANA 522
(3-4)
Departure station (Name of
Kumamoto Airport
town)
(3-5)
Arrival station (Name of town)
Itami Airport
______________________________________
An example of location data is shown in Table 2 below.
TABLE 2
______________________________________
Location data (in a certain area)
______________________________________
(1-1) Starting of location
October 8, 1990 6:30 p.m.
(1-2) End of location October 9, 1990 9:30 a.m.
(2-1) Area Kinki
(2-2) Prefecture Osaka
(2-3) County/city Osaka
(2-4) City/town Osaka-City
(2-5) Town/district Sakai
(3-1) Starting place Hotel Prince
(3-2) Communication means
Tel.No. 06-232-5678
______________________________________
FIG. 6 is a diagram showing data representing several examples of movement data input as schedule data. FIG. 7 is a diagram showing data representing several examples of location data input as schedule data. It is pointed out that other various data are allowed to be used as movement data and location data besides the examples shown in FIGS. 6 and 7. As described above, after attribute data is input by reference to data input area 14 shown in FIG. 3 and schedule data is also input by reference to data input area 16 shown in FIG. 5, a retrieval processing including data input by many other subscribers is executed by host computer 3 shown in FIG. 1. While this retrieval processing will be described subsequently in detail, the following description will first be made on an example of an output list which is finally output by display unit 12 and/or printer 13. In the following example, assume that a certain user, Mr. A has a registration schedule shown in Table 3 below.
TABLE 3
______________________________________
Mr. A's registered schedule
______________________________________
Oct. 10 8:30 Kumamoto Airport: ANA522
1990 10:30
to Flower Exposition
16:30
18:00 Hotel Prince Osaka (Arrival)
Oct. 11 9:30 Hotel Prince Osaka (Departure)
10:00 Hankyu Railway Express for
Kawaramachi, Kyoto
11:00
to Heian Shrine, Kyoto
12:00
16:00 Japan Railway Sanyo for Osaka
18:00 Hotel Prince Osaka (Arrival)
Oct. 12 9:00 Hotel Prince Osaka (Departure)
9:30 Hankyu Railway Express for
Kobe
10:30 Mt. Rokko by cable car
12:00
to Top of Mt. Rokko
14:00
16:00 Hotel Koyo in Arima Onsen
(Arrival)
Oct. 13 9:00 Hotel Koyo in Arima Onsen
(Departure)
9:30 Kobe Railway Express for
Sannomiya
10:20
to Ijinkan in Sannomiya, Kobe
10:50
11:00
to Daiohji Zoo
13:00
14:00 From Miyoshi to Osaka Airport
by Airport limousine
18:55 Osaka Airport: ANA529
______________________________________
In addition, assume that another user, Mr. B has a registration schedule shown in Table 4 below.
TABLE 4
______________________________________
Mr. B's registered schedule
______________________________________
Oct. 11 10:00 Kumamoto Airport: ANA524
1990 11:30 For Kyoto by Airport Limousine
12:30 Sightseeing in Kiyomizu
to Temple, Kyoto
14:00
18:30 Hotel Miyako, Kyoto (Arrival)
Oct. 12 9:00 Hotel Miyako, Kyoto
(Departure)
10:00 Express from Hankyu
Kawaramachi to Osaka
12:00
to Flower Exposition
17:00
18:00 Hotel Prince Osaka (Arrival)
Oct. 13 9:00 Hotel Prince Osaka (Departure)
10:00
to Flower Exposition
14:00
16:30 Osaka Airport: ANA527
______________________________________
FIG. 8 is a diagram of an output list showing an example of an output list of the user, Mr. A. FIG. 9 is a diagram of an output list showing an example of an output list of another user, Mr. B. As can be seen from the registered schedules of Mr. A and Mr. B. shown in the above tables 3 and 4, it is possible that Mr. A and Mr. B who do not know each other (or know each other but do not know their mutual schedules in some case) may meet on their schedules. In this example, assume that Mr. A's attribute data match Mr. B's. Therefore, Mr. B's schedule data and attribute data are displayed as the other party's information in Mr. A's output list 91 shown in FIG. 8. With reference to FIG. 8, Mr. A's output list 91 includes a column 92 for displaying schedule data of Mr. A, a column 93 for displaying schedule data of the other party (i.e., including Mr. B), and a column 94 for displaying detailed attribute data of the other party. With reference to FIG. 9, Mr. B's output list 95 includes a column for displaying Mr. B's schedule data, a column 97 for displaying the other party's (i.e., including Mr. A) schedule data, and a column 98 for displaying the other party's detailed attribute data. As shown in FIGS. 8 and 9, since there are other people (Mr. E, Mr. X, Mr. W etc.) other than Mr. B and Mr. A who Mr. A and Mr. B may possibly meet with, respectively, as their respective other parties, schedule data and attribute data concerning those other people are also displayed. Mr. A and Mr. B who have received the output lists shown in FIGS. 8 and 9, respectively, can be informed that there are their respective expecting parties on travels. Accordingly, Mr. A and Mr. B can communicate with their desired parties before starting to travel or during travelling. If they agree to meet each other, they can see each other while travelling. The foregoing description has been made on one example of the manner of use of the information providing system shown in FIG. 1. A detailed description will now be made on a data processing in the information providing system shown in FIG. 1. FIG. 10 is an overall flow chart showing a schematic processing flow in the information providing system shown in FIG. 1. With reference to FIG. 10, first, in a step 101, attribute data are input (or updated in some case) by a large number of users or subscribers. A subscriber inputs/updates self-attribute data and expected attribute data through input/output terminal 1 shown in FIG. 1. The input attribute data is transferred through communication network 2 to host computer 3. In a step 102, data input processor 31 processes the transferred attribute data and registers or stores the processed attribute data in attribute file 41. In some case, the data in attribute file 41 is updated. In a step 103, schedule data is input through input/output terminal 1 by the subscriber. In some case, the subscriber updates the schedule data. The input schedule data is transferred through communication network 2 to host computer 3. In a step 104, data input processor 31 processes the transferred schedule data and registers the processed schedule data in schedule file 42. In some case, the schedule data in schedule file 42 is updated. In a step 105, data coupling processor 32 couples two data stored via a common registrant number by referring to attribute file 41 and schedule file 42. That is, for each subscriber, attribute data and schedule data are coupled to each other (which will be described in detail later), and coupled attribute/schedule data is generated. In a step 106, the generated attribute/schedule data is registered in attribute/schedule file 43. In some case, the attribute/schedule data in file 43 is updated. In a step 107, expected number detecting processor 33 generates three expected number files 44, 45 and 46 by carrying out a processing which will be described later in detail. In some case, expected number files 44, 45 and 46 are updated. In a step 108, feasible meeting detecting processor 34 detects a feasible meeting by carrying out a processing which will be described later in detail. In a step 109, data concerning a feasible meeting is stored in intermediate file 47. In some case, the data stored in intermediate file 47 is updated. In a step 110, data output processor 35 generates output data having a format suitable for an output by display unit 12 or printer 13, and stores the generated output data into an output list file 48. In some case, the data in output list file 48 is updated. In a step 111, data output processor 35 responds to a request from input/output terminal 1 to refer to the data stored in output list file 48, and applies requested data through interface unit 30 and communication network 2 to input/output terminal 1. A data format of the data stored in each of files 41 to 47 shown in FIG. 1 will now be described. The data stored in attribute file 41 has a data format shown in Table 5 below.
TABLE 5
______________________________________
Registrant No.
Attribute Data
______________________________________
RN EA.sub.1 EA.sub.2
EA.sub.3
EA.sub.4
. . .
______________________________________
With reference to Table 5, the data stored in attribute file 41 includes attribute data EA1, EA2, . . . provided for each registrant, i.e., each registrant number RN. Respective attribute data EA1, EA2, . . . correspond to attribute codes representing the attribute data described with reference to FIG. 3. That is, each of attribute codes EA1, EA2, . . . represents attributes of an expected person for the a registrant. In the example shown in FIG. 3, a code representing the prefecture "Hiroshima Prefecture" from which a registrant (having his or her registrant number RN) comes is input as attribute code EA1, a code representing the city "Hiroshima City" from which the registrant comes is input as attribute code EA2, and a code representing the town "Funairi" from which the registrant comes is input as attribute code EA3. Other data shown in FIG. 3 (data numbers 02 to 04) are also input as attribute codes of the same registrant number RN in accordance with a predetermined coding. Accordingly, attribute data input via data input area 14 shown in FIG. 3 is converted into an attribute code in data input processor 31 of FIG. 1, and thereafter, the converted attribute code is stored in the data format shown in Table 5 in attribute file 41. Similarly, when an alteration or updating of attribute data is requested, data input processor 31 alters or updates the attribute code stored in attribute file 41 in accordance with the request. Schedule data stored in schedule file 42 shown in FIG. 1 has a data format shown in Table 6 below.
TABLE 6
______________________________________
Schedule Data
Registrant No.
Time Place
______________________________________
RN TMA TMB PL.sub.1
PL.sub.2
PL.sub.3
PL.sub.4
. . .
______________________________________
With reference to Table 6, schedule data also includes time codes TMA and TMB and place codes PL1, PL2, . . . provided for each registrant, i.e., each registrant number RN. Time code TMA includes a code for determining the time/date/month/year for a registrant to start in a certain place. Time code TMB includes a code for determining the time/date/month/year for the registrant to end. Place codes PL1, PL2, . . . include a code for determining places sequentially from a larger area to a smaller area. That is, single schedule data stored in schedule file 42 represents that registrant RN stays at a place determined by place codes PL1, PL2, . . . during a period determined by starting time code TMA and ending time code TMB. Therefore, schedule data input via data input area 16 shown in FIG. 5 is converted into a time code and a place code in data input processor 31 of FIG. 1 and is then stored in schedule file 42 for each registrant number. The data stored in attribute/schedule file 43 has a data format shown in Table 7 below.
TABLE 7
__________________________________________________________________________
Schedule Data Registrant
Attribute Data Time Place No.
__________________________________________________________________________
EA.sub.1
EA.sub.2
EA.sub.3
EA.sub.4
. . .
TMA TMB PL.sub.1
PL.sub.2
PL.sub.3
PL.sub.4
. . .
RN
__________________________________________________________________________
As can be seen from Table 7, the contents of attribute/schedule file 43 is obtained by coupling the attribute data and the schedule data stored in attribute file 41 and schedule file 42 in accordance with a predetermined processing. This coupling processing is made by data coupling processor 32 shown in FIG. 1. The data coupling processing is carried out on the basis of a flow chart shown in FIG. 11. FIG. 11 is a flow chart showing a processing in data coupling processor 32 shown in FIG. 1. With reference to FIG. 11, in a step 121, attribute data EA1, EA2, . . . are read for each one registrant number RNA by reference to attribute file 41. In a step 122, schedule data, i.e., time codes TMA and TMB and place codes PL1, PL2, . . . are read for each registrant number RNB by reference to schedule file 42. In a step 123, attribute/schedule data which is obtained by all combinations of attribute data EA and schedule data TM and PL are produced for each registrant (RNA). The produced attribute/schedule data are stored in attribute/schedule file 43. Accordingly, in this step 123, attribute data EL and schedule data TM and PL are coupled to each other for each registrant, so that the coupled data are stored in attribute/schedule file 43. In a step 124, it is determined whether the processings in steps 121 to 123 are carried out for all the registrants. If attribute data of a registrant which is not processed is left in attribute file 41, the processing returns to step 121. When the processings in steps 121 to 123 are completed for all the registrants, the above-described data coupling processing is completed. This results in generation of coupled data having the data format shown in Table 7 in attribute/schedule file 43 shown in FIG. 1. A description will now be made on a processing carried out in expected number detecting processor 33 shown in FIG. 1. Prior to this description, a description will first be made on a data format of data generated in an expected number detecting processing, i.e., a data format of data stored in expected number files 44, 45 and 46 shown in FIG. 1. Table 8 below shows a data format of data stored in a first expected number file 44.
TABLE 8
______________________________________
Attributes Expected Number
______________________________________
EA.sub.1
EA.sub.2 EA.sub.3
EA.sub.4
. . .
ENA
______________________________________
With reference to Table 8, single data stored in first expected number file 44 includes attribute codes and the number of registrants who expect common attributes. Attribute data includes attribute codes EA1, EA2, . . . as already described. Attribute codes EA1, EA2, . . . are used as a first retrieval key KA for use in detecting a first expected number, as will be described later. Data stored in a second expected number file 45 has a data format shown in Table 9 below.
TABLE 9
______________________________________
Expected
Attributes Time Number
______________________________________
EA.sub.1
EA.sub.2
EA.sub.3
EA.sub.4
. . .
TMA TMB ENB
______________________________________
With reference to Table 9, single data stored in second expected number file 45 includes attribute codes EA1, EA2, . . . , time codes TMA and TMB, and expected number data ENB. That is, expected number data ENB corresponds to the number of registrants who have common attribute codes and common time codes. Data stored in a third expected number file 46 has a data format shown in Table 10 below.
TABLE 10
__________________________________________________________________________
Attributes Place Expected Number
__________________________________________________________________________
EA.sub.1
EA.sub.2
EA.sub.3
EA.sub.4
. . .
PL.sub.1
PL.sub.2
PL.sub.3
PL.sub.4
. . .
EN.sub.1
EN.sub.2
EN.sub.3
EN.sub.4
. . .
__________________________________________________________________________
With reference to Table 10, single data stored in a third expected number file 46 includes attribute codes EA1, EA2, . . . , place codes PL1, PL2, . . . , and expected number data EN1, EN2, . . . For example, expected number data EN1 corresponds to the number of registrants who have common attribute codes EA1, EA2, . . . and common place code PL1. Expected number code EN2 corresponds to the number of registrants who have common attribute codes EA1, EA2, . . . and common place codes PL1 and PL2. In addition, expected number code EN3 corresponds to the number of registrants who have common attribute codes EA1, EA2, . . . and common place codes PL1, PL2 and PL3. Another expected number data EN4 also corresponds to the number of registrants according to a similar rule. FIG. 12 is a flow chart showing a generation processing of expected number file 44 in expected number detecting processor 33 shown in FIG. 1. With reference to FIG. 12, first, in a step 131, a first retrieval key KA is extracted by reference to attribute/schedule file 43. First retrieval key KA is comprised of attribute codes EA1, EA2, . . . as mentioned above. In a step 132, the number of registrants who have the same retrieval key code is counted for each retrieval key KA by reference to attribute/schedule file 43. That is, the number of registrants who have registered the same attribute data is obtained as expected number data ENA. In a step 133, expected number data ENA is stored in expected number file 44 for each retrieval key KA. That is, data having the data format shown in Table 8 is stored in expected number file 44. FIG. 13 is a flow chart showing a generation processing of expected number file 45 in expected number detecting processor 33 shown in FIG. 1. With reference to FIG. 13, in a step 134, a second retrieval key KB is extracted by reference to attribute/schedule file 43. Second retrieval key KB is comprised of attribute codes EA1, EA2, . . . and time codes TMA and TMB shown in Table 9. In a step 135, the number of registrants who have the same retrieval key code is counted for each retrieval key KB by reference to attribute/schedule file 43. Accordingly, the number of registrants who have the same attribute data and the same time code is obtained as expected number data ENB. In a step 136, expected number data ENB is written for each retrieval key KB in expected number file 45. Thus, data having the data format shown in Table 9 is stored in second expected number file 45. FIG. 14 is a flow chart showing a generation processing of a third expected number file 46 in expected number detecting processor 33 shown in FIG. 1. With reference to FIG. 14, a third retrieval key KC is extracted by reference to attribute/schedule file 43 in a step 137. Third retrieval key KC is comprised of attribute codes EA1, EA2, . . . and place codes PL1, PL2, shown in Table 10. In a step 138, the number of registrants who have the same retrieval key code is counted for each retrieval key KC by reference to attribute/schedule file 43. As described above, expected number data EN2, for example, corresponds to the number of registrants who have common attribute codes EA1, EA2, . . . and common place codes PL1, PL2. Similarly, expected number data EN4 corresponds to the number of registrants who have common attribute codes EA1, EA2, . . . and common place codes PL1 to PL4. In a step 139, expected number data EN1, EN2, . . . are written for each retrieval key KC in expected number file 46. Accordingly, data having the data format shown in Table 10 is stored in third expected number file 46. A processing carried out in feasible meeting detecting processor 34 shown in FIG. 1 will now be described. With reference to FIG. 15, expected number data ENA is read by reference to expected number file 44 in a step 181. It is determined in a step 182 that read data ENA is not lower than "2". When data ENA is "1", the processing returns to step 181. When a relation ENA.gtoreq."2" is satisfied, the processing proceeds to a step 183. In step 183, a first retrieval key KA having expected number ENA not lower than "2" is extracted from expected number file 44, and expected number file 45 is retrieved with retrieval key KA. Thus, expected number data ENB having retrieval key KA is read from expected number file 45. In a step 184, it is determined whether expected number data ENB is not lower than "2". If data ENB is "1", the processing returns to step 183. If a relation ENB.gtoreq."2" is satisfied, the processing proceeds to a step 185. In step 185, a second retrieval key KB is extracted from expected number file 45, and expected number file 46 is retrieved with retrieval key KB. Accordingly, expected number data ENj (j=1, 2, . . . ) is read. A determination is made in a step 186 as to whether all data ENj are not lower than "2". When at least one data ENj is "1", the processing returns to step 185. When all data ENj satisfy a relation ENj.gtoreq.2, the processing proceeds to a step 187 shown in FIG. 19. In step 187, retrieval data for retrieving attribute/schedule file 43 is generated with combinations of attribute code EA, time code TM and place code PL. In a step 188, registrant numbers RNA, RNB, . . . are extracted by retrieving of attribute/schedule file 43 with retrieval data. In a step 189, intermediate file data are generated for all combinations of extracted registrant numbers, and generated data are stored in intermediate file 47. In a step 190, a determination is made as to whether all data in expected number file 44 are processed or not. When any data is left, the processing returns to step 181 shown in FIG. 15. When all data in expected number file 44 are processed, the processing in feasible meeting detecting processor 34 shown in FIG. 1 is completed. A data format of data generated as the result of the feasible meeting detection processing shown in FIGS. 15 and 16 is represented in Table 11 below. That is, the data format shown in Table 1 corresponds to the data format of the data stored in intermediate file 47 shown in FIG. 1.
TABLE 11
__________________________________________________________________________
The Other Schedule Data of the Other
Registrant
Party's
Attribute Data of
Party
No. No. the Other Party
Time Place
__________________________________________________________________________
RNA RNB EA.sub.1
EA.sub.2
EA.sub.3
EA.sub.4
. . .
TMA TMB PL.sub.1
PL.sub.2
PL.sub.3
PL.sub.4
. . .
__________________________________________________________________________
With reference to Table 11, single data stored in intermediate file 47 includes the other party's registrant number data provided for each registrant number RNA, the other party's attribute data and the other party's schedule data. The other party's number data RNB corresponds to a registration number of a person who registrant RNA may possibly meet with while travelling. The other party's attribute data and schedule data as well as the other party's number data RNB are stored in intermediate file 47. That is, other party attribute data includes other party attribute codes EA1, EA2, . . . The other party schedule data includes the other party's time codes TMA and TMB and place codes PL1 and PL2, . . . Consequently, intermediate file 47 stores therein, for each registrant, information regarding the person who the registrant might see while travelling. Output list file 48 is produced in the following procedure by reference to intermediate file 47. FIG. 17 is a flow chart for use in generating data stored in output list file 48 shown in FIG. 1. With reference to FIG. 17, in a step 161, sorting of data stored in intermediate file 47 is made by using registrant numbers. As a result, data as to the same registrant are concentrated in intermediate file 47, and accesses of data with respect to one registrant can easily be made. In a step 162, schedule data is read by reference to schedule file 42 for each registrant existing in intermediate file 47. That is, data necessary to constitute the output lists shown in FIGS. 8 and 9 are read for each registrant. In a step 163, read schedule data are written in an output format in the output list file for each registrant. In the example shown in FIG. 8, for example, Mr. A's schedule data is written in a data format which is suitable for constituting the output list of FIG. 8, in output list file 48. In a step 164, information as to the feasible other party is read for each registrant by reference to intermediate file 47. In the example shown in FIG. 8, schedule information and attribute information concerning Mr. B and Mr. E are read from intermediate file 47. In a step 165, the read other party information is written in the data format suitable for constituting the output list into output list file 48. As the result of data writing in steps 163 and 165, data having a data format suitable for outputting the output list shown in FIG. 8, for example, is formed in output list file 48. A determination is made in a step 166 as to whether there are any other registrants left as the other party. If some other party is left, the processing returns to step 164. If no other party is left, the processing proceeds to a step 167. In step 167, it is determined whether there remain in intermediate file 47 any other registrants who are not subjected to the processings in steps 162 to 166. If some registrant is left, the processing returns to step 162. If there is no registrant left, the output list file data generation processing shown in FIG. 16 is completed. The foregoing description has been made on the detailed processings in steps 101 to 110 shown in the overall flow chart of FIG. 10. The processings in steps 101 to 110 shown in FIG. 10 are carried out at predetermined time intervals, for example, once in a day or twice in a day in some case. The user can obtain latest information by referring to output list file 48. In addition to intermediate file 47, intermediate file data one generation before, i.e., one generation older is also stored in old intermediate file 49. By comparing data in latest intermediate file 47 and that in old intermediate file 49, feasible meeting detection processor 34 is able to detect that a realizable meeting newly occurs or does not occur. Information as to such a new realizable meeting is also reported to subscribers through input/output terminals 1. Accordingly, a subscriber who has completed his or her attribute data registration and schedule data registration can obtain the latest output list by making access again to this information providing system via input/output terminals 1 after a predetermined time interval has passed. That is, when a certain subscriber requests an output of an output list via input/output terminals 1, data output processor 35 refers to output list file 48 thereby to transfer the output list data requested by the subscriber toward the input/output terminals. The subscriber can obtain information as to the other party during his or her travel by referring to an output list displayed on display unit 12. The output list is allowed to be output even via printer 13 if necessary. In such a manner, if the subscriber makes access to the information providing system shown in FIG. 1, then the subscriber can obtain the output lists shown in, for example, FIGS. 8 and 9. By referring to the output lists, the subscriber recognizes that it is possible to meet with a person who the subscriber expects to meet on his or her travel schedule. The subscriber can communicate with a desired person prior to or during travel, so that an expected meeting can be realized. Although the present invention has been described and illustrated in detail, it is clearly understood that the same is by way of illustration and example only and is not to be taken by way of limitation, the spirit and scope of the present invention being limited only by the terms of the appended claims.
|
Same subclass Same class Consider this |
||||||||||
