Callee-initiated communication method, communication system, and electronic payment system

Abstract

To effectively utilize communication resources and additional devices by controlling a communication device as intended by an owner of the communication device, and to achieve an efficient routing guide service system and a secure and convenient electronic settlement and moving body charge collection system by eliminating nuisance communication, reducing useless communication traffics, and utilizing supervision, anonymous communication and other additional devices of the communication device.SOLUTION: A ruler player of a communication device issues an instruction to an electronic secretary interposed between the communication device and a network beforehand. There are provided a plurality of handling methods from rejection to control permission for the electronic secretary to respond to each communication request from a caller after identifying the caller or communication content in accordance with instruction content of the ruler player, in order to process communication requests arriving from the inside and the outside.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] The present invention relates to communication using electronic devices on a communication network, and in particular to the stage of establishing a communication connection and ensuring the security of the communication. It also relates to the integration of communication and remote control functions, which determine all operations according to the will of the called party or the party controlling the called communication equipment. [Background technology]

[0002] Telecommunications have become widespread. Various information technology services using the Internet have rapidly spread to the general public, high-speed, high-capacity, always-on connections have spread to ordinary households, and caller ID notification has become common. Today, the caller is in control of communications. However, serious damage has been caused by spam communications against the recipient's will, frauds that falsely identify the sender, emails that have a negative impact on young people, frequent "attacks" by sending large amounts of email, viruses that can infect people just by looking at the screen of an incoming email, and "one-ring" calls that fail to complete, causing disruptions to telecommunications carrier networks and causing widespread paralysis of telephone lines for long periods of time. Negative issues have also emerged, such as the paralysis and degradation of communication infrastructure and the drowning of normal communications. The weaknesses of the existing public communication system have led to the above illegal and legal acts. Conventional spam communication prevention technologies are divided into various alert levels. However, none can simultaneously address a wide range of situations. For example, "designated rejection" blocks emails from specified recipients, but it has the problem of being unable to specify all recipients. "designated reception" only allows emails from specified recipients, but it can lead to a "closed-doors" mentality (see, for example, Patent Document 1, Non-Patent Documents 1 and 2). The method described in Patent Document 6 improves the convenience of registering and canceling rejected numbers. Reception is blocked based on reception conditions specified by the recipient, and the email sender decides whether to forward the email. However, determining the conditions is difficult, and it is difficult to specify all the conditions (see, for example, Patent Documents 2 and 3). Another method involves recording unopened emails and charging the sender a fee (see, for example, Patent Document 4). Other methods extract the sender's identification information from received emails (see, for example, Patent Document 5).

[0003] However, these technologies (a) lack the ability to respond after at least one nuisance call (see, for example, Patent Document 6), and legal regulations such as opt-out methods force individuals to respond to all callers, making them virtually ineffective, especially in the case of email. The reasons for this are: 1. The number of callers is enormous. Even a single call is nuisance, and it is impractical to reject each call individually. Even if a rejection registration is enabled, the storage capacity for the number of calls that can be registered is limited, and it cannot be expanded infinitely. The aforementioned legal regulations also cannot solve problems, such as how to restrict the content of calls in foreign languages, there are countries that do not have legal systems for restricting calls, and prosecuting violators is not practical when the caller is an individual rather than an organization. 2. They cannot deal with one-ring nuisance calls. 3. They cannot address the problem of criminal acts such as "it's me" scams, which involve falsifying the caller's identity, or the use of home-attendance confirmation calls by burglars. (b) It is not possible to set perfect reception conditions. "Designated reception" technology leaves a strong possibility that important communications will not be received. Strict legal regulations and the opt-in system, which only allows sending to registered users, hinder freedom of expression and freedom of business. Regarding the concept of spam, there is no common standard for determining what content constitutes spam, and it cannot be determined without considering the subjective factors of the individual recipient. Filtering technologies using publicly known spam sender databases and other methods are completely unable to reflect the recipient's subjective opinion, and there are clearly limitations to what they can do in the current situation where sender addresses are constantly changing.

[0004] (c) Generally, conventional communication systems are premised on the concept that communicating parties know each other's identities. For example, a person's phone number serves as a person's identity. Therefore, casually disclosing one's phone number to unknown parties poses some potential danger. Meanwhile, when anonymous communication is required from start to finish in online activities such as person-to-person or person-to-company transactions, relationships, and job hunting, once you invite someone, your email address or phone number is disclosed to the other party, making it difficult to easily sever ties with them when you want to withdraw. Patent Document 10 describes a two-step method for anonymous communication, which involves establishing a communication channel through a dedicated anonymous communication center that removes the identity information of both parties from the communication content. (d) With technological advances, small portable communication devices are becoming more multifunctional. The potential needs for utilizing additional functions such as cameras and location information devices attached to communication equipment, and for safe communication and supervision for children, elderly people with dementia, and even when unattended, remain unmet. For example, regarding the use of location information, some devices are equipped with control means for setting a driving route, but this requires a large amount of calculation and is not suitable for small devices such as mobile phones (see, for example, Patent Documents 7 and 8). There are also devices related to mobile phones equipped with means for receiving radio waves from GPS satellites, but there is no means for preventing unwanted communications (see, for example, Patent Document 9). Patent documents 19-20 and 27-29 disclose technologies for using mobile devices for payments. However, these technologies do not allow secure use of payment PINs. Patent documents 30-31 disclose technologies for cashless transactions. However, these technologies impair the liquidity of funds. [Patent Document 1] JP 5-14488 A (Claim 1, Figures 1-4) [Patent Document 2] JP 2002-344524 A (claims 1-15, figures 1-19) [Patent Document 3] JP 2000-10880 A (claims 1-5, figures 1-18) [Patent Document 4] Japanese Patent No. 3283873 (Claim 1-2, Figure 1-3) [Patent Document 5] Japanese Patent No. 3003640 (Claim 1-2, Figure 1-2) [Patent Document 6] JP 2002-290566 A (full text, Figures 1-3) [Patent Document 7] Patent No. 3460033 specification [Patent Document 8] JP Patent Publication No. 6-60821 (Claim 1-2, Figure 1) [Patent Document 9] Japanese Patent No. 3039536 (full text, Figures 1-7) [Patent Document 10] U.S. Patent No. 5,884,270 (full text, Figures 1-9) [Patent Document 11] U.S. Patent No. 6,070,149 [Patent Document 12] U.S. Patent No. 6,370,235 [Patent Document 13] U.S. Patent No. 6,691,156 [Patent Document 14] JP 2001-148094 A (full text, Figures 1-7) [Patent Document 15] Japanese Patent Application Publication No. 10-307993 [Patent Document 16] Japanese Patent Application Publication No. 9-22497 [Patent Document 17] Patent No. 3488192 [Patent Document 18] Patent No. 3028796 [Patent Document 19] Japanese Patent Application Publication No. 8-339407 [Patent Document 20] Japanese Patent Application Laid-Open No. 2001-338250 [Patent Document 21] Japanese Patent Application Laid-Open No. 2003-141043 [Patent Document 22] Japanese Patent Application Laid-Open No. 2002-374307 [Patent Document 23] Japanese Patent Application Laid-Open No. 2003-36230 [Patent Document 24] Japanese Patent Application Laid-Open No. 2001-217861 [Patent Document 25] Japanese Patent Application Laid-Open No. 2003-333097 [Patent Document 26] Japanese Patent Application Laid-Open No. 2003-216548 [Patent Document 27] Special Publication No. 2004-519022 [Patent Document 28] Patent No. 3497144 [Patent Document 29] Patent No. 3339843 [Patent Document 30] Japanese Patent Application Laid-Open No. 2000-242717 [Patent Document 31] Japanese Patent Application Laid-Open No. 2001-306982 [Patent Document 32] Japanese Patent Application Laid-Open No. 2000-48283 [Patent Document 33] Japanese Patent Application Laid-Open No. 2002-42273 [Patent Document 34] Japanese Patent Application Publication No. 11-234393 [Patent Document 35] Japanese Patent Application Laid-Open No. 2003-18636 [Non-Patent Document 1] Study Group on How to Deal with Spam Emails, "Interim Report," [online], January 24, 2002, Ministry of Internal Affairs and Communications, p. 10, [Retrieved January 9, 2004], Internet<URL:http: / / www.soumu.go.jp / s-news / 2002 / 020124_4.html> [Non-patent document 2] Study Group on How to Deal with Spam Emails, "Report," [online], October 7, 2002, Ministry of Internal Affairs and Communications, pp. 3-5 [Retrieved January 9, 2004], Internet<URL:http: / / www.soumu.go.jp / s-news / 2002 / 021007_1.html> [Non-patent document 3] J. Myers, "RFC1939, POP3 (Post Office Protocol - Version 3)," [online], May 1996, IAB (Internet Architecture Board) Standard Recommendation Document RFC (Request for Comments), p. 11 [Retrieved January 12, 2004], Internet <URL:(ftp: / / ftp.rfc-editor.org / in-notes / rfc1939.txt) [Non-patent document 4] J. Klensin, "RFC2821 (Simple Mail Transfer Protocol)," [online], April 2001, IAB (Internet Architecture Board) Standard Recommendation Document RFC (Request for Comments), p. 32, [Retrieved January 14, 2004], Internet <URL:(ftp: / / ftp.rfc-editor.org / in-notes / rfc2821.txt) [Non-patent document 5] P. Resnick, "RFC2822 (Internet Message Format)," [online], April 2001, IAB (Internet Architecture Board) Standard Recommendation Document RFC (Request for Comments), p. 26 [Retrieved January 20, 2004], Internet <URL:(ftp: / / ftp.rfc-editor.org / in-notes / rfc2822.txt) DISCLOSURE OF THE INVENTION [Problem to be solved by the invention]

[0005] These concerns all relate to the wishes of the administrator of an electronic device (hereinafter referred to as a communication device) equipped with communication and communication-related functions, i.e., the desire to prevent the device from being operated by others, including spam, and the desire to control the device at one's own discretion. The problems with the prior art have been unable to satisfy these wishes. The object of the present invention is to solve these problems and satisfy the wishes of the parties. Specifically, the object of the present invention is to safely and efficiently utilize communication resources in accordance with the wishes of the parties. The object of the present invention is to eliminate spam without impairing existing communication functions in a normal and open manner, reduce unnecessary communication volume, and utilize communication device accessories such as custody, emergency communication, anonymous communication, and efficient mobile location information services. The object of the present invention is also to provide route guidance services, grasp traffic conditions without the need for dedicated equipment, and realize a safe and convenient electronic payment and mobile toll collection system. [Means for solving the problem]

[0006] In order to solve the above problems, as shown in Figure 1, the present invention allows an administrator of a communication device to issue instructions in advance to an electronic secretary interposed between the communication device and the network, and the electronic secretary, in accordance with the instructions of the administrator, is provided with a number of methods for handling communication requests arriving from inside or outside (communication device or network), and when the communication request is received, it selects one of the multiple methods for handling the communication request; in this specification, the handling method is referred to as "treatment," and means a method for taking a specific action for a specific communication request determined by the administrator. In the conventional concept of communication, the caller is usually the initiator, and it is taken for granted that when you call someone, the other person will answer. Response methods are also simple, so there is no need to use special terms to describe them. In this invention, response methods are diverse, and there is no appropriate technical term to succinctly express them. Therefore, the word "treatment" is used to describe the relationship between the two parties. The reject treatment expresses a complete rejection of the caller, the allow treatment expresses a traditional communication need, and the control treatment expresses a latent need: giving the caller control of the communication device. The term "control permission" as used herein refers to the administrator's intention to allow the communication equipment to be in a controlled state, to execute the caller's commands, or to activate designated functions or programs. For example, a caller can remotely activate a camera attached to the communication device to monitor the callee, and an authentication program can be activated when a communication request for electronic payment confirmation is received. The idea behind this invention is that all communication begins with prior permission from all callers. When an unknown caller calls without permission, the system first asks for the caller's name, determines their identity, and then decides whether to communicate. This is called request acceptance. This process can be likened to the example of a receptionist or secretary. Specific rules are instructed to the secretary in advance, and when the designated visitor arrives, the secretary will handle them in the instructed manner. When an unknown visitor arrives, the secretary will ask for their name and purpose, and decide whether to let the visitor through based on the rules instructed by the boss. For example, if the boss is interested in the visitor's purpose, the visitor will be allowed through. If the visitor turns out to be an old acquaintance of the boss, the visitor will be allowed through. A smart secretary will remember the visitor and be able to quickly decide whether to treat them kindly or turn them away for the second visit.

[0007] If the boss himself comes, he will follow his orders because he has the control. This is like remotely controlling a communication device. In this invention, the parties issue instructions in advance to an electronic secretary that fulfills the role of the secretary, and the electronic secretary processes communication requests according to the instructions of the parties. The electronic secretary is taught a first rule consisting of a pair of a caller ID and a treatment to be given, and the communication request is first handled based on the first rule. The electronic secretary is also taught a second rule consisting of a question, a correct answer, and a treatment. If the first rule does not tell how to handle the request, the electronic secretary asks the caller a question, and if a correct answer is obtained, the request is handled based on the second rule, and the caller's ID and treatment are stored as the first rule. The electronic secretary is also instructed on how to handle callers for whom the correct answer was not obtained. The second rule can include personal information about the parties involved. For example, if a rule specifies that the name of the party involved must be known, callers who do not know the name of the recipient can be rejected. Family members and relatives can also be identified by a secret phrase or password. In the case of telephone communications, voice recognition and voiceprint recognition can also be used. The types of treatment include reception rejection and communication permission for communication requests arriving from the outside, and outgoing communication requests include outgoing rejection and outgoing permission for communication requests originating from the inside. A virtual account (described later) is introduced for settlement. [Effects of the Invention]

[0008] (a) Prevention of spam emails and calls. The greatest feature of this invention is that it prevents spam communications before they even occur, preventing them from even being allowed to occur even once. 1. If the caller ID and recipient ID pair do not match, communication is not permitted. Even if the caller ID can be forged, it cannot be made to match the recipient ID pair. In cases where the caller ID cannot be forged, such as with caller ID notification, unknown callers are given a limited number of opportunities to apply, and any subsequent attempts are unconditionally rejected, thereby preventing automated spam attempts by programs. 2. The application procedure automatically begins for those attempting to make a one-ring call, and the sender begins to be charged for the call, thereby imposing sanctions. 3. Unregistered callers are automatically verified using a set procedure, which also helps prevent "it's me, it's me" scams in which careless individuals such as the elderly are deceived. (b) At the same time, if the other party answers the callee's question correctly, for example, if the callee's name can be answered, the normal and open communication function will remain almost the same as before, with almost no loss of functionality. The caller's freedom will not be restricted. When selling or advertising something, it will be beneficial for both parties only if the other party is interested. The present invention provides a means for the callee to declare their interest in advance, and will not reject communications that are beneficial to both parties. (c) When this invention is operated on a receiving server, it can block spam communication requests at the point of transmission. This reduces the amount of communication caused by large amounts of unnecessary email on public networks, allows for more efficient use of facilities, and saves on spam communication compensation fees paid by telecommunications companies. Even if it is not operated on a receiving server, it reduces the social burden of changing communication contracts and implementing legal regulations, and saves time manually identifying and deleting spam emails. Eliminating spam communications ultimately expands the use of communication methods. (d) Simple anonymous communication and one-way communication, which allows only one party to send a message, will become possible. This will allow people to socialize, find jobs, and so on more safely and comfortably over public communication networks. (e) The other party can be automatically identified based on the subjective awareness of each party, and even if the other party obtains unauthorized communication permission due to an automatic processing problem, that permission can be revoked. (f) Communication devices and communication accessories can be used safely and efficiently according to the wishes of the person in charge of the receiving communication device. This allows for the integration of functions for guarding, crime prevention, emergency communication, and vehicle navigation. This creates new uses and new needs. In addition, the problems, means, and effects of each embodiment will be described.

[0009] The terms used in this specification are: "communication request" means the content of communication that arrives at the electronic secretary before the sender's original communication purpose is achieved, for example, a connection request, or an email, data, or consent request received by the electronic secretary before the recipient receives it; "rule" means knowledge used to control processing, expressed as a pair of search conditions for the processing object and definition information for the action when the search conditions are met; and "first rule" means a condition part having an application condition related to the sender ID (sender's identifier) ​​and an execution part instructing the implementation of an action corresponding to the treatment. The "first rule set" is a set of first rules, and in this specification, creating a first rule and adding it to the first rule set means providing a treatment to the caller. The "second rule" is a rule having a condition part with an application condition related to the expected application content and an action corresponding to the treatment. The third rule has a condition part having an application condition relating to a caller ID and a reception time, and an execution part instructing the execution of an action corresponding to the treatment, and states that "if the actual caller ID detected from the communication request matches the caller ID in the condition part and a predetermined time has not elapsed since the reception time, then the communication request is treated based on the treatment." The "fourth rule" is a rule having a condition part with a question to be presented to the caller, an application condition related to the correct answer to the question, and an execution part of an action related to the score, and expresses the matter that "if the answer to the question from the caller is correct, count the score and add up the total score." The "fifth rule" is a rule having a condition part with application conditions related to the callee ID and the time of calling, and an execution part that instructs the implementation of an action corresponding to the treatment, and expresses the matter that "if the destination ID (the callee's ID) matches the callee ID in the condition part, and"If a predetermined time has not elapsed since the time of the call, the call request is processed based on the treatment." "Caller" means a party or device requesting the start of communication. "Treatment information" means the callee ID and information on the first rule set, provided that if there is only one callee ID, the first rule set is used. "ID" means an identifier provided by a communication service provider to a party using the communication service, and multiple identifiers can be provided to one party. "Communication authorization" means transmitting a communication request to a callee, and when the electronic secretary determines that communication is authorized, it transmits the communication request to the callee, creating the same state as when a communication request is received by a conventional communication means, allowing the callee to make a final decision on whether to communicate. "Receiving client" means a device that can retrieve a callee's email stored on a server, such as a mobile phone that receives emails, or a Post Office Protocol - Version 3 (POP3) specified in the standard recommendation document RFC (Request for Comments) issued by the IAB (Internet Architecture Board). 3) corresponds to a host that is attempting to use a service that complies with this definition; "sending client" means a device that sends email, such as a client terminal that sends email or an ISP server that sends email; "server" means a party that provides a service, such as a telephone exchange; "receiving server" means a device that receives and stores email and delivers the stored email to the recipient when the recipient accesses it, such as a mobile phone company's email center or a host that provides POP3 service; "communication" means transmitting information and control signals; "email" means email; "pre-application" means that a party discloses information including its ID (identifier) ​​to have the sender apply for permission to communicate, and the sender applies for permission to communicate to the party before making a communication request; "identity registration" means that a party using a communication service is identified by ID, and the provider of the communication service provides the ID to the party;"Permission to listen" means that a caller is allowed to acquire an audio signal acquired by a microphone of the callee's communication device; "Permission to monitor" means that a caller is allowed to acquire an image signal acquired by an imaging device installed on the callee's side through the callee's communication device; "Permission to acquire location" means that a caller is allowed to acquire location information acquired by a location acquisition means installed on the callee's side through the callee's communication device; "Permission to alert" means that a caller is allowed to output information through the callee's communication device to alert the callee; "Permission to forward information" means that a caller is allowed to forward information to the callee's communication device; "Initial expected treatment" means a preset treatment to be applied when treatment cannot be determined by the applicable rule set; "Subject" means that a purposeful information field (Informational fields), "sender email address" refers to the email address to which email is sent to the sender, including the return email address designated by the sender, "treatment request" refers to a request for permission to communicate, and the traditional act of sending a message can also be considered a form of treatment request, "treatment relationship" refers to the relationship established by the treatment each party gives to the other, "treatment set" refers to a collection of multiple treatments, "request content" refers to the content of a request for permission to communicate, "expected request content" refers to the request content expected by the receiving party, for example, when asking the other party for the name of the receiving party, the exact name is the expected request content, i.e., the correct answer to the question is the expected request content, or it can be specified as a topic of interest, keyword, or expected request content, "program execution permission" refers to permission for the sender to execute a program on the receiving party's communication device, and the communication device is equipped with a means for executing programs such as a CPU.

[0010] Explanation of email-related terms and concepts. The flow of email transmission generally goes from the sender's terminal (sending client) to the sending mail server (receiving server), from the sending mail server (sending client) to the receiving server, and from the receiving server to the recipient's terminal (receiving client). The sending mail server has two roles: receiving server and sending client. Hereinafter, an embodiment of the present invention will be described with reference to the drawings. Figure 1 shows an example of the schematic configuration of one embodiment of the present invention. A party terminal 101 communicates over a network 104 via an electronic secretary 102, and the electronic secretary may be incorporated into the party terminal or the server that provides the communication service, or in the case of telephone communication, into the telephone set or exchange. When it is installed on the server side, it is connected to the party's terminal through a communication channel. The instruction file 103 may be installed in the electronic secretary or may be independent of the electronic secretary. An administrator may directly input data into the instruction file (not shown). The instruction file is stored in a data storage device. As long as the storage device can achieve the objectives of the present invention, it can be an electronic memory circuit such as a magnetic storage device, RAM, ROM, or optical storage medium. A desirable implementation of the instruction file is a database that organizes and integrates interrelated data, including multimedia information, for easy retrieval. Hereinafter, the same reference numerals will be used for common or similar components in the various drawings. Figure 2B is a record layout diagram showing the contents of the data database (hereinafter referred to as R1DB) that records the first rule set related to items and treatments. There can be multiple items. For example, the condition section of the "communication confirmation" treatment (described later) contains two items: the calling number and the command.

[0011] Tables contain all the data in a database. A table is a collection of columns. Data is organized in a row-column format. Each row represents a record, and each column represents a field in that record. The layout of a record consists of information organized by "field name" (on the left side of the table shown in the image) and "field characteristics" (on the right side of the table shown in the image). Rows correspond to each field. A primary key is a column whose value uniquely identifies each row in a table. A foreign key is a column that establishes a link between data in two tables. R1DB has fields for caller ID and treatment ID. Figure 2A is a record layout diagram showing the contents of a data database (hereinafter referred to as TDB) that records one embodiment of a treatment set. The specific implementation of each treatment varies depending on the communication device, and the total number of treatment types that can be implemented varies depending on the communication device. The treatment set can be expanded or simplified to suit the needs of each individual party. The treatment ID is used to identify the processing method (function) to be called within the program, and the text is used to display the content of the function to the user. Figure 2C is a record layout diagram showing the contents of a data database (hereinafter referred to as GDB) that records one embodiment of the presentation information. If the presentation information includes a question to be presented to the sender, it may be in the format shown in Figure 2F. FIG. 2D is a record layout diagram showing the contents of a data database (hereinafter referred to as R2DB) that records an embodiment of a second rule set regarding expected application content and treatment. FIG. 2E is a record layout diagram showing the contents of a data database (hereinafter referred to as R3DB) that records an embodiment of a third rule set relating to senders, reception times, and treatments.

[0012] 2F is a record layout diagram showing the contents of a data database (hereinafter referred to as R4DB) that records questions to be presented to callers, correct answers to the questions, and an embodiment of a fourth rule set regarding scores. The questions and presentation information stored in the GDB include information selected from the group consisting of text, audio, and images. FIG. 2G is a record layout diagram showing the contents of a data database (hereinafter referred to as R5DB) that records an embodiment of a fifth rule set relating to the call recipient ID, the time of call origination, and treatment. FIG. 2H is a record layout diagram showing the contents of a data database (hereinafter referred to as TRDB) that records one embodiment of the treatment relationship master. FIG. 4 is a flowchart of one embodiment of the present invention. A method for communication via an electronic secretary system (hereinafter referred to as "electronic secretary") that supports communication in a telecommunications network, in which an administrator issues instructions to an electronic secretary in advance, the electronic secretary is installed between a communication device and the telecommunications network, and the electronic secretary processes communication requests from the inside (communications device) or the outside (telecommunications network) in accordance with the administrator's instructions, the method comprising: (a) a step of inputting data to construct an instruction file that instructs the electronic secretary to perform tasks; and the instruction file has a condition part having application conditions related to items, and an execution part that instructs the execution of actions corresponding to treatments. and (b) a step of communicating using the electronic secretary capable of the following operations: (a) a first set of rules (referred to as the "first rule set" in this specification) written in the form of rules that: (the first rule expresses the fact that "when actually receiving the communication request from a sender, if the item (hereinafter referred to as the "fact item") detected from the communication request matches the item in the condition part, then process the communication request based on the treatment"; (b) a step of communicating using the electronic secretary capable of the following operations: (1) detecting the item from the communication request from the sender; (2) accessing the instruction file; (3) searching through all rules in the first rule set to find a rule whose application condition is met and executing the execution part of the rule (hereinafter simply referred to as applying a predetermined set of rules); and (4) transmitting the communication request to the recipient (hereinafter referred to as "communication permission") for each of the communication requests (hereinafter referred to as "treatment set"). When the communication request is received, one of the treatment methods is selected to process the communication request. When a communication request from an internal or external caller arrives, the system detects the item, i.e., the actual item, from the communication request (401), reads the instruction file (402), and applies the first rule set according to the following first rule set application procedure. Specifically, the system searches all rules in the first rule set related to items and treatments to find a rule whose application condition is met. It then searches the R1DB (see Figure 2B) for a rule whose condition matches the item and actual item (403) and determines whether it is found (404). If the record is found, i.e., if a rule whose application condition is met is found, the treatment given to the caller can be extracted from the treatment ID field. The system then executes the rule execution part (406). If the rule is not found, it processes the communication request according to a predetermined processing method, i.e., the initial expected treatment (405).

[0013] A rule set is a description of process control using structured data. In other words, there are multiple different data in the same rule set. Different data in the same rule set are used to control similar processes. In this specification, when the same rule set is described using different data, it is referred to as a rule set for something. First, we will explain the case where an external communication request is processed and a treatment is given to each caller. In the first rule set, the item is the caller ID (caller identifier), and the treatment for rejecting the communication request is called "reject reception," and the treatment for accepting the communication request is called "accept request." Accepting the request means that the caller is permitted to express a desire to communicate with the recipient, and this action can convey the communication matters, including information for identifying the caller, to the electronic secretary. Furthermore, the caller's original purpose of communication cannot be achieved before the information presented is presented to the caller, the caller's response is received, and it is determined that the communication request can be permitted based on the response. The term "communication matter" refers to the content of communication that establishes a communication connection between the caller and the electronic secretary and that is received by the electronic secretary and requires communication with the recipient before the caller's original purpose of communication is achieved. For example, in the case of telephone communication, the caller's name, phone number, and purpose are recorded and transmitted to the recipient, and the electronic secretary sends a voice message and receives the caller's reply, but does not allow conversation with the recipient until the reply is determined to be correct. Repeated question and answer sessions are possible. Immediate and subsequent determination of the callee are possible. Responses can be received by dialed number or voice recognition. For purposes of this invention, the term "submission receipt" refers to any interaction that facilitates an ongoing cycle of presenting invitation messages and receiving responses.

[0014] In the case of e-mail communication, an e-mail address, a subject, etc. are received, but are not passed to a recipient before the contents are judged to be correct, and an electronic secretary replies with presented information, and the contents of the sender's reply according to the presented information are not passed to the recipient before the contents are judged to be correct. The recipient can freely decide what information to present. For example, they can ask the caller for personal information such as the recipient's name. Conventional telephone technology has a function that allows you to play dumb when you are not at home. In this invention, however, you can confirm the caller only when you do not know who the caller is, and if you can confirm the call, you can communicate, but if you know who the caller is, you can either answer the call or refuse to answer. Figure 5 is a flowchart of another embodiment of the present invention. The instruction file includes presentation information to be presented to the sender, and the electronic secretary can operate to present the presentation information to the sender. The instruction file includes a second set of rules (referred to as the "second rule set" in this specification) described in rules having a condition part with application conditions related to expected request content and an execution part instructing the implementation of an action corresponding to the treatment (the second rule expresses the fact that "if the expected request content is detected from the communication request, process the communication request based on the treatment"). The request acceptance includes the following operations: (a) detecting the expected request content from the communication request, and (b) applying the second rule set. The ID is detected (501), the instruction file is read (502), the first rule set is applied (503), and the result is judged (504). When accepting an application, all rules in the second rule set relating to the expected application content and treatment are searched for to find a rule whose application conditions are met (505), and it is judged whether or not it is found (506). If not found, a predetermined treatment method is used, i.e., treatment is performed based on the initial expected treatment.

[0015] For example, the proposed information may be presented to the sender and then the reception may be rejected. Alternatively, the reception may be rejected without any notification. This is preferably determined by the parties involved. The initial expected treatment is preferably selected from the treatment set excluding the application acceptance treatment (507). When no rule satisfying the application conditions of the first rule set is found, the user can choose whether or not to execute the application acceptance treatment. If a rule whose application condition is satisfied is found, the communication request is treated according to the treatment given, i.e., the treatment described in the execution part of the rule (508). The treatment includes communication permission and reception refusal, and various treatments, i.e., various methods of treatment, can be specified according to the will of the administrator of the communication equipment depending on the capabilities of the communication equipment of the receiving party, such as partially allowing communication or recording the caller's message. For example, if the communication equipment only has basic communication functions, the electronic secretary's communication permission treatment simply allows the communication content to pass without interruption, while the communication refusal simply blocks the communication content altogether. A communication device incorporating an embodiment of the present invention has basic communication functions and control functions. The electronic secretary's control permission setting commands the communication device to enter a controlled state, and then passes communication content containing the sender's instructions. Furthermore, various controlled states, such as information transfer permission, alert permission, location acquisition permission, listening permission, and surveillance permission, can be realized. Using the second rule set, phishing (sender identity forgery) scams can be prevented by issuing a password to the sender. The second rule set can be used to determine whether or not communication is permitted based on the content of the communication. Freedom of communication is not restricted. Mail order sales and advertising, which are beneficial for both parties, are possible.

[0016] Communication requests from the inside can be processed in the same way as the mechanism for processing communication requests from the outside. For example, a first rule set for outgoing calls can be used, in which the item is the callee ID (identifier of the callee). A treatment called "reject outgoing calls" for rejecting communication requests, a treatment called "allow outgoing calls" for allowing communication requests, and a treatment called "authentication outgoing calls" can be used. The authentication treatment starts an authentication program, and allows outgoing calls if authentication by password matching or the like is successful. For example, in the case of a company, this invention can be used to manage outgoing calls such as international calls. In this specification, giving a treatment to a communication request means taking a specific action on a communication request with specific communication content. Fig. 6 is a flowchart of another embodiment of the present invention described in the description of Fig. 5. The communication is an email communication, the sender ID is the sender's email address (reply address), the presented information includes an explanation of the conditions for receiving email, the communication permission treatment is to allow email to be received, and the presenting is to reply to the sender, and when the communication request arrives, the electronic secretary first applies the first rule set, and if no rule whose application conditions are met is found, the request is accepted, and in the step of accepting the request, when the second rule set is applied, if no rule whose application conditions are met is found, i.e., if no treatment can be decided, the presented information is presented to the sender and then the communication request is rejected. The sender's email address is detected (601), the instruction file is read (602), the first rule set is applied (603), the result is judged (604), the second rule set is applied (605), and the result is judged (606). The presented information includes a description of the conditions for receiving email, and the communication permission treatment is to allow the email to be received. That is, the electronic secretary passes the email and the recipient receives the email. The reception refusal treatment is to not receive the email (608). Presenting the presented information to the sender is to return the presented information to the sender (607). Figure 7 is a diagram showing the configuration of another embodiment of the present invention described in the description of Figure 6. The electronic secretary and instruction files R1DB, GDB, and R2DB are installed in a receiving client user terminal 701. Reference numeral 702 indicates a receiving server of an ISP (Internet Service Provider).

[0017] Figure 8 is a flowchart of another embodiment of the present invention described in the description of Figure 6. The electronic secretary is installed on the receiving client side, and refusing the communication request means sending a delete command to the receiving server to delete the email from the receiving server, and the method for requesting permission to communicate that is presented to the sender is to write the request details in the subject of the email. The presented information includes at least content that prompts the sender to write the request details in the subject of the email, for example, by presenting a question and prompting the sender to write the answer in the subject. Then, the system logs in to the receiving server (801) and detects the sender's ID, i.e., the sender's email address, from the header of the email (802). For example, the system sends the command "TOP 1 0" described in POP3 (Non-Patent Document 3), a common email receiving protocol, and receives and analyzes the header of the first email from the POP3 server, thereby detecting the sender's email address. Then, the instruction file is read (803), and the first rule set is applied in the first rule set application procedure (804, 805, 809). If no rule whose application condition is met is found in the first rule set, the second rule set is applied in the following example procedure (806, 807). First, correct answer content is extracted one by one from all records in the R4DB (see Figure 2F), and based on the extracted content, the corresponding content is searched for in the subject line included in the header of the email and scored. Then, all records in the R2DB are searched for records that match the score value. If such records are found, that is, if a rule whose application condition is met is found, the treatment ID can be extracted from the treatment ID field. Then, the execution part of the rule is executed (809). The first expected treatment is processed (808).

[0018] There is also an invention that extracts the sender's identification information from an incoming email (Patent Document 5). This invention differs in that it extracts the sender ID from the header of the incoming email. This invention can achieve its purpose without opening the body of the email. Therefore, compared to the above invention that opens the body of the email, it can significantly reduce the amount of communication traffic that is charged for communication with the server, especially for mobile phones. Fig. 9 is a diagram showing the configuration of another embodiment of the present invention described in the description of Fig. 6. An electronic secretary and instruction files R1DB, GDB, and R2DB are installed on the receiving server 901 side. Reference numeral 902 indicates a receiving client. Reference numeral 903 indicates a mail sending client. FIG. 10 is a flowchart of another embodiment of the present invention described in the description of FIG. 6. A method for requesting permission to communicate with a sender involves including the request details in the subject line of an email. The presented information includes at least a prompt to include the request details in the subject line of the email. The electronic secretary is installed on the receiving server side. Rejecting the communication request involves notifying the sending client of the email that an error has occurred and then halting the communication. The system receives the email up to the envelope (1001), detects the sender's email address, reads the instruction file (1002), and applies the first rule set in the first rule set application procedure (1003, 1004, 1009). If no rule satisfying the application condition is found in the first rule set, the system receives the header including the email subject to receive the email (1005), and then applies the second rule set in the second rule set application procedure (1006, 1007, 1009). The system processes the initial request (1008).

[0019] FIG. 11 is a partial flowchart of the early decision process of another embodiment of the present invention described in the description of FIG. 10. The early decision means deciding and executing the rejection of email before the email body is completely received. The present invention can decide to reject the email body by examining the email subject. However, while prior art SMTP-compliant email senders have a step for checking authorization after sending the email envelope and before sending the content, they do not have a step for checking authorization before sending the email body when they begin sending the email content (see Non-Patent Document 4). Therefore, there is a possibility that some email senders are implemented to ignore the error code returned when a sending client is forcibly aborted by closing the communication channel during content transmission and retransmit the email. This invention can achieve early decision making, preventing unnecessary communication traffic, even when receiving from such prior art senders. The early decision process begins when no rule whose application condition is met is found in the step of applying the first rule set (1004 in FIG. 10). The third rule set is then applied in the next step of applying the third rule set. Specifically, the R3DB is searched (1101) based on the conditions that the sender ID (in this example, the sender's email address) matches and that a predetermined time has not elapsed between the time of receipt and the time of search. The results are then evaluated (1102). If the record is found, that is, if a rule whose application condition is met is found, the treatment can be extracted from the treatment ID field. The execution part of the rule is then executed (1110). If no rule whose application condition is met is found, the header containing the email subject is received (1103), and the second rule set is applied in the second rule set application step (1104, 1105, 1112), and the first expected treatment is processed (1106). However, if the treatment and initial expected treatment of the second rule set execution part include a rejection of reception (judgment: 1107), a third rule is created based on the actual sender ID, reception time, and rejection of reception treatment, and added to the third rule set (1108). The communication request is processed based on the treatment. If the rejection of reception is in the waiting state, a temporary error status is returned to the sending client and the communication is forcibly aborted (1109). Otherwise, the communication request is processed based on the given treatment (1112). The purpose of executing the third rule is to cause a conventional SMTP-compliant sender to abort before receiving the conventional formal abort step: header. Since it only needs to be executed once, once the execution part of the third rule is executed, the corresponding rule is deleted (1111).

[0020] Issuing a TCP protocol socket close command is one example of the forced abort. When an SMTP-compliant sender retries transmission after a certain period of time, the third rule set is used as a rejection history. If the history detects a retry from a sender that was forced to abort, the system rejects the content transmission using standard SMTP methods. If no retry occurs, the old rejection history is deleted. In this way, an early decision can be made to prevent the generation of unnecessary traffic. A third rule set for this purpose is called the abort third rule set. The embodiments shown in Figures 30 and 31 are proposed as an extension function of conventional SMTP. When a sender that implements this function and the invention shown in Figure 10 are used simultaneously, the recipient's electronic secretary does not need to handle the above-mentioned retry, and there is no need to rely on a forced abort means using a command in the TCP layer, which is located at a different layer from SMTP, and this can further reduce the traffic volume on the public network and the processing load on the connected mail server for spam emails. If the third rule is set to a predetermined time longer than the retry interval (see Non-Patent Document 4), the retry transmission can be reliably detected (YES in 1102), causing the sender to give up and preventing unwanted repeated retries. In step 1109, instead of a temporary error state, a failure response may be returned to the sending client. Instead of the header, after receiving part or all of the content, if the correct answer to the question or the expected keyword is not detected or is detected, it may be determined to be spam. Figure 12 is a flowchart of another embodiment of the present invention described in the description of Figure 6. The information presented to the sender prompts the sender to request permission for communication. The information includes at least a prompt to enter the request details in the email. The electronic secretary is installed on the receiving server side. Rejecting the communication request involves notifying the email sending client of an error and then halting the communication. When the communication request arrives, the electronic secretary first receives the email envelope containing the actual sender ID and applies the first rule set. If no rule satisfying the application conditions is found, the electronic secretary receives the email content and accepts the request. The electronic secretary receives the envelope (1201), detects the sender's email address, reads the instruction file (1202), and applies the first rule set according to the first rule set application procedure (1203, 1204, 1209). If no rule whose application condition is satisfied is found in the first rule set, the content is received (1205), and the second rule set is applied in the second rule set application procedure (1206, 1207, 1209). The first expected result is processed (1208).

[0021] FIG. 13 is a flowchart of another embodiment of the present invention described in the description of FIG. 6. When applying the second rule set, if a second rule whose application condition is satisfied is found, the caller is given the treatment of the execution part of the found second rule. The process involves detecting the ID (1301), reading the instruction file (1302), applying the first rule set (1303), determining the result (1304), applying the second rule set (1305), determining the result (1306), and processing the initial expected treatment (1307). The difference from FIG. 5 is that when a second rule whose application condition is satisfied is found, the storage conditions are further checked (1310). If the conditions are satisfied, the electronic secretary gives the caller the treatment of the execution part of the found second rule. That is, a first rule is created based on the caller's ID and the treatment, added to the first rule set (1309), and the communication request is processed based on the treatment (1308). Typically, one of the storage conditions is that the treatment of the execution part of the second rule found is not application acceptance. The storage conditions can be specified or changed by the parties. This process is called automatic screening. If you use this method, for example, if the recipient answers the specified questions correctly, all parties who have contacted the recipient at least once will be automatically stored in the first rule, and the same questions will not be asked a second time. Application acceptance treatment is not usually given to specific parties. If you downgrade the communication permission treatment to a party that you have given that treatment and give application acceptance treatment, it will be useful as a record of communication with that party. Step 1307 handles the matter based on the initial treatment. In this example, the initial treatment is to present the presented information to the caller and then refuse to receive the call. If the caller is unknown, the presented information must be presented to have the caller request permission to communicate. If the presented information was not presented in the exchange of request acceptance, it can be presented in this step. It is also possible for the parties not to present it at their discretion. FIG. 14 is a flowchart of a portion of another embodiment of the present invention described in the description of FIG. 5. This portion of the process is included in the initial expected treatment processing block (FIG. 5, 507). That is, if the treatment is not determined by the first and second rules, the third rule set is applied in the third rule set application procedure (1401, 1402, 1405). Once applied, the corresponding rule is deleted from the third rule set (1406), and a first rule is created based on the caller ID and the predetermined treatment and added to the first rule set (1407). If no rule whose application condition is met is found, a third rule is created based on the caller ID, the time of receipt, and the predetermined treatment and added to the third rule set (1403). The electronic secretary executes the original initial expected treatment (1404).

[0022] This invention automatically replies to unknown senders to verify their identity. However, currently, the majority of spam emails have forged reply addresses. Sending an automatic reply can result in the creation of new spam. This invention automatically replies to unknown senders if a second email is received from the reply address and does not contain information that can verify the sender's identity. If the recipient specifies, for example, to ignore and reject the specified treatment, the address is ignored and rejected, and then the recipient is rejected without an automatic reply. Similar to the third rule, a time element may be incorporated into the condition part of the first rule. For example, the first rule with the rejection treatment may be deleted after one month or more has passed. This allows rejected senders to return to the initial expected treatment, preventing the first rule set from becoming too large. Forged, unreturnable addresses are immediately rejected. In the case of telephone calls, this invention can prevent attacks by repeated applications. The invention provides the other party with a limited number of opportunities to apply, and handles repeated applications by machines, etc. This can be achieved by including the number of applications as an execution condition or by providing a limited number of application treatments. Please note that the purpose of using the third rule set is different from the purpose of using it to forcibly stop the call. Figure 15 shows the configuration of another embodiment of the present invention described in the description of Figure 5. An electronic secretary and instruction files R1DB, GDB, and R2DB are incorporated into the party terminal side 1501. It is equipped with a means for communication through real-time interaction. A party terminal 1502 having control can communicate with the called party terminal 1501 without the intervention of the called party, and can send control commands 1510 to the terminal 1501. A party terminal 1503 that has been granted communication permission can perform normal two-way communication 1520 with the terminal 1501. Communication and control can coexist. Figure 16 is a flowchart of another embodiment of the present invention described in the description of Figure 5. The communication is a telephone communication, the presented information includes a description of the conditions for receiving the communication, and when a communication request is received, the electronic secretary first applies the first rule set, and if no rule whose applicable conditions are met is found, the request is accepted. The step of accepting the request includes presenting the presented information to the sender, receiving the sender's response, and applying the second rule set. If no rule whose applicable conditions are met is found, i.e., no treatment can be determined, the communication request is handled based on the initial expected treatment. The system detects the ID (1601), reads the instruction file (1602), applies the first rule set and judges the result (1603, 1604), and if no rule is found that satisfies the conditions, it presents the presentation information to the sender, receives the sender's response (1605), applies the second rule set and judges the result (1606, 1607), and depending on the result, handles the communication request based on the initial expected treatment or the treatment given (1608, 1609).

[0023] 17 is a flowchart of another embodiment of the present invention described in the description of FIG. 5. The presented information includes a question to be presented to the sender, and the expected application content is an answer to the question that earns a predetermined total score. The instruction file includes the question to be presented to the sender, a fourth rule set (hereinafter referred to as the "fourth rule set") described in rules having a condition part with an application condition for a correct answer to the question, and an execution part for an action related to the score (the fourth rule expresses the fact that "if the answer to the question from the sender is correct, count the score and add up the total score"), and the electronic secretary is further capable of the following operations: (a) present the question to the sender, (b) receive the sender's answer to the question, and (c) apply the fourth rule set. This process illustrates the procedure for repeatedly presenting a guidance message, receiving a response, and determining the accuracy of the response. It corresponds to the processing block "Present the presentation information to the caller and receive the caller's response" in Figure 16 (1605 in Figure 16). The process determines whether the rule data record has been processed properly (1701), extracts it (1702), presents a question to the caller, and receives the caller's response (1704). A single question may have multiple correct answers. For example, when checking an identification number, multiple identification numbers exist. In this embodiment, the mechanism for confirming multiple correct answers (1705) does not ask the same question, but instead checks whether the answer received from the previous question is the correct answer for the next question. This is determined by adding a question presentation unnecessary indicator to the R4DB or by leaving the question field blank (1703). There are cases where it is not necessary to present all questions. For example, there are cases where the caller's identity can be determined from the initial question. This embodiment has a mechanism for early termination of the question and answer session if the total score (1706) exceeds a predetermined score (1707). The system that performs this process has a means for receiving the caller's response depending on the type of presented information. For example, if the answer is obtained by dialing a telephone number, the system has a means for recognizing the number that was pressed.

[0024] In the case of telephone calls, callers are identified by the calling telephone number. This invention can identify callers by an identification number or password issued by the party. Using the identification number, communication is possible from any calling terminal. Figure 18 shows the configuration of another embodiment of the present invention. The electronic secretary and instruction file are installed on the communication service providing server 1801 side. Each party has its own instruction file, and multiple parties can use it. A party with usage rights inputs data to build their own instruction file from any terminal 1803 or telephone (1820). A communication request or control command from the caller terminal 1802 is sent via the electronic secretary server (1810). Figure 19 shows the configuration of another embodiment of the present invention. The electronic secretaries have a means for accessing the instruction file (1930) via a network, and one manager uses multiple electronic secretaries (1901, 1904). The multiple electronic secretaries access one instruction file 103. Reference numeral 1940 indicates an email sent via server 1904. The fifth rule set (Figure 2G, R5DB) created by the electronic secretary is also saved in the instruction file 103 (not shown in Figure 19). FIG. 20 is a flowchart of the outgoing call processing part of another embodiment of the present invention described in the description of FIG. The method is characterized in that the instruction file further includes a fifth set of rules (hereinafter referred to as the "fifth rule set") written in rules having a condition part with application conditions related to the recipient ID and the time of calling, and an action part that instructs the implementation of an action corresponding to the treatment, and the electronic secretary is further capable of the following operations: (a) applying the fifth rule set, (b) sending a communication request to the recipient and receiving the treatment, and (c) creating the fifth rule and adding it to the fifth rule set.

[0025] All rules in the fifth rule set relating to the destination recipient's ID, the time of call, and the treatment are searched for to find a rule whose application condition is met, and the result is judged (2001, 2002). If a rule whose application condition is met is found, the call request is processed based on the given treatment (2004). If no such rule is found, a communication request is sent to the recipient, and the treatment is received (2003). If the recipient is the electronic secretary of the present invention, the treatment received is determined based on a predetermined return code, and communication is carried out (2005, 2006). If the recipient is using conventional technology, for example, a conventional mail receiving server, it is desirable to regard the reception of the message as a rejection if a permanent error code is received. If the received treatment is "immediately unavailable," a fifth rule is created based on the callee ID, the time of call, and the treatment, and added to the fifth rule set (2007). The primary objective of this invention is to block spam communications at their source. Preferably, this system is operated on a server, as shown in Figures 18 and 19, so that callers cannot be prevented from entering "immediately unavailable," including the "rejection of reception," into the R5DB (2007). If the treatment given to the recipient is "rejection of reception," repeated calls are blocked within a specified time period. It is desirable for the server administrator to set this specified time period. For example, a treatment such as "please try again in one hour" can be implemented on the sending server side. If the R5DB is not cleared, the number of R5DB records for indiscriminate spam callers will increase. The server administrator can manage the number of R5DB records by reducing the sending efficiency of the caller or issuing a warning. A communication request originating from the inside can be treated by the first rule set for outgoing calls set by the administrator of the communication device. Note that the first and fifth rule sets for outgoing calls have different purposes.

[0026] Figure 21 shows a system for anonymous communication between electronic secretary users. The first and second parties are users of the electronic secretary of the present invention. As shown in Figure 1, the electronic secretary operates between the terminal and the communication network and is incorporated into the party's terminal or the server that provides communication services (not shown in Figure 21). The first and second data are personal information of the first and second parties, respectively. This information is shown in Figure 3A, which describes the PDDB, and includes party IDs such as phone numbers, names, pen names, addresses, educational backgrounds, work history, etc. The server system 2103 stores the personal information PDDB and VDB of parties wishing to communicate anonymously and provides services such as searching for communication partners to initiate anonymous communication. This method involves anonymous communication between two or more parties. The contrasting background art is primarily described in Patent Document 10. The challenge is to achieve simple and convenient anonymous communication. The primary method is to create a communication channel between the parties through controlled permission handling. FIG. 3A is a record layout diagram showing the contents of a party data database (hereinafter referred to as PDDB) relating to party data in one embodiment. FIG. 3B is a record layout diagram showing the contents of a verification data database (hereinafter referred to as VDB) according to one embodiment of the present invention, which relates to data recording verification requests. FIG. 3C is a record layout diagram showing the contents of a verifier data database (hereinafter referred to as VRDB) according to one embodiment of the present invention, which relates to data that records verifier information. Fig. 22 is a partial flowchart of the processing of the first party. Fig. 23 is a partial flowchart of the processing of the second party. Fig. 24 is a flowchart of the processing of searching the server, sending data, and exchanging benefits. This invention can be used by two or more parties simultaneously. In the following description, it is assumed that the first party enters the treatment to be given to the data disclosure party in the PDDB, grants proxy permission treatment to the server (2202), and the second party sends a search request to the server (2302). See Example 4 for another example of party data other than the PDDB.

[0027] The parties 2101 and 2102 input first and second data and at least one party rule for disclosing the data to the server 2103 and grant communication permission to the server (2110, 2111, 2201, 2301). The server receives the party data and party rule and stores them in the PDDB (2401). The party rule includes profiles of candidates who will and will not disclose information, whether confirmation is required before disclosing information, and information on what information will be disclosed to which candidates, and stores these in the disclosure authorization profile in the PDDB. The second party sends a search request including search criteria (2112, 2302), which the server receives and searches the PDDB (2402). The search results, such as the number of records that meet the criteria, are sent to the second party (2303, 2403). It is determined whether the first data satisfies the search criteria (2404), and if there is first data that satisfies the search criteria, it is determined whether the first party rules are satisfied (2405), and if so, the first data is sent to the second party (2113, 2303, 2406). If the first party grants proxy permission treatment to the server and enters the treatment to be given to the second party to whom the first data will be disclosed in the PDDB, the server acts on behalf of the first party's operation and grants the second party the treatment to be given to the disclosure target included in the first data (2113, 2407). It is determined whether the second party rules are satisfied (2408), and if so, the second data of the second party is sent to the first party (2114, 2203, 2409). Party rules can include a requirement that an individual be verified before information is released. Party rules can specify a condition that information about the party has been verified. It is possible to ask the server to verify information about the parties. The verification information is stored in the verification database VDB, and the verifier information is stored in the verifier data database VRDB.

[0028] If the party's instruction file is stored on a server in the network, the server is logged in based on the access permission information (ID, password) and data is entered into the instruction file. Proxy permission is implemented by entering the information into the instruction file based on the access permission information entered by the requester. If the instruction file is stored locally, proxy permission is implemented by granting information transfer permission to the server and entering it into the local instruction file. The implementation of a process in which a server processes a search request and determines whether first data satisfies search criteria and first (second) party rules disclosing the first (second) data is known from U.S. Patent No. 6,277,999. There are many search techniques that can be used, including keywords, fuzzy logic, and natural language search tools. According to this invention, since the called party holds the key to the success or failure of communication, it is possible to sever the connection between the party ID, such as a telephone number, and the identity. Personal telephone calls and emails are only connected to parties within a range that can be easily trusted. This provides an effect similar to that of a dedicated network on a public network. Since this invention allows the party to later refuse communication with a public network communication ID known to the other party, it is possible to realize anonymous communication that maintains anonymity and allows easy use of all communication functions using a regular number, as long as the party does not disclose their identity. For example, this invention does not require the intervention of a dedicated central controller that removes the identity from the communication content. There is also no need to create a special communication channel. Compared to anonymous communication technology (see Patent Document 10) that requires a dedicated central controller and two steps for data exchange between parties, the present invention can easily realize anonymous communication and easy data exchange. The communication service provider provides an ID to the party using the communication service, and the party's identification information is stored on a server using a method in which a party selected from the group consisting of the communication service provider and a third party registers the party's identification information. The communication service provider that manages the server and third parties such as security service providers that work with them are legally obligated to protect information. In the event of damage caused by illegal activity, the other party's identity can be investigated through legal means, allowing for safe communication.

[0029] You can cut off the communication relationship by resetting the other party's treatment to rejection. If necessary, you can use an additional ID to sign up for a new phone number dedicated to anonymous communication, separate from your regular phone number. For example, Nippon Telegraph and Telephone East Corporation offers an additional number service in addition to your original subscriber line number, and the additional number can also be used as your caller ID. In the case of email, a new address can be used as an additional ID. If you no longer need anonymous communication and find setting the treatment to rejection to be a burden, simply cancel the additional ID contract. The concept of treatment in ordinary terms is a give-and-take relationship. The term treatment used in this invention is also a give-and-take relationship, but "treatment exchange" does not necessarily mean simultaneous exchange. In this invention, only one party can give permission to communicate, and the other party can communicate. FIG. 25 is a flowchart of another embodiment of the present invention described in the description of FIG. 4, to which control permission treatment is added. FIG. 26 is a diagram showing the configuration of one embodiment of the present invention described in the description of FIG. 25. The administrator of terminal A 2601 grants information transfer permission and program execution permission treatment to terminal C 2603. When information is transferred from terminal C to terminal A, the data is written to the storage device 13 of terminal A (2610), and attention permission treatment is granted, it is possible to output information to the display unit 18 through terminal A and output sound from the speaker 17 to alert nearby parties. Terminal B 2602 and terminal A perform normal two-way communication (2620). When information requesting confirmation of the bank's electronic payment is received from terminal C, an authentication program is activated, the owner of terminal A inputs a fingerprint through the fingerprint sensor, and the authentication program compares the input fingerprint information with the registered fingerprint information, and only if they match, sends a pre-registered PIN to terminal C to confirm the payment.

[0030] Figure 27 is a conceptual diagram showing the configuration of another embodiment of the present invention. The administrator of mobile device 2701 grants location acquisition permission to the caller of terminal A 2702. Terminal A issues a location information acquisition command 2711, and the mobile device acquires location information using its installed location acquisition means in accordance with the command and transfers the acquired location information to terminal A (2712). The location information includes information selected from the group consisting of a received GPS (Global Positioning System) location signal, location information converted from the received GPS location signal, current location information of a PHS (Personal Handy Phone) terminal, and mobile terminal location information provided based on mobile phone base station location information (hereinafter referred to as "specific location"). The specific location includes information selected from the group consisting of a GPS location signal received from a GPS satellite 2704, location information converted from the received GPS location signal, current location information provided based on PHS terminal base station 2705 location information, and mobile terminal location information provided based on mobile phone base station 2706 location information. When the called party's communication device, a mobile communication device (hereinafter referred to as "mobile device"), issues a communication request to terminal A having a pre-registered ID, it detects the speed or the location information and transfers it to terminal A (2714), transfers movement plan information to terminal A, and further grants terminal A the treatment of (a) information transfer permission and (b) attention alert permission. Terminal A transfers the information to the mobile device, causes the information display means of the mobile device to output the information, and alerts nearby parties through the attention alert means of the mobile device (2715). For example, groups wishing to share their locations, such as nearby moving vehicles or hikers, can share and display their locations. Terminal A, which has granted permission to acquire speed, can acquire the speed of the mobile device in the same way as the location information acquisition command. Terminal A can then acquire movement information from the mobile device only when necessary. The electrical configuration of the mobile device, calculation of movement speed and direction, and estimation of traffic conditions are known from Patent Document 14. The alerting includes generating a sound, light, or vibration signal in the mobile device. The movement plan information includes arrival destination information, and the information transferred to the mobile device includes a map information, recommended route, current route, traffic congestion information ahead, detour information, and weather information. The location information includes a specific location. Terminal B 2703 and the mobile device perform normal bidirectional communication (2713). A system for supervising wandering elderly people has appeared several years ago. This invention is not just an element that can acquire (control) the location information of the caller. Please note that this invention also includes an element that can make calls.

[0031] FIG. 28 is a flowchart of another embodiment of the present invention relating to dynamic route guidance (see FIG. 27). This example aims to efficiently provide a vehicle navigation function to a mobile terminal with a location information acquisition function, such as a GPS-equipped mobile phone. When a communication request is sent to a server terminal of a fixed-line device with a pre-registered ID, the mobile device transmits its current location and destination information to the server, which receives it (2801). The server searches for a recommended route and transmits it to the mobile device (2802). It then searches for congestion information on the recommended route at predetermined intervals (2803) and determines whether congestion will occur (2804). If congestion does occur, the server, which has been granted location acquisition permission, acquires the mobile device's current location and checks the route to be traveled (2805). If congestion occurs before the route to be traveled, it searches for a detour (2806, 2807). If a detour exists, the server, which has been granted information transfer permission and warning permission, transfers the detour information to the mobile device and then notifies the driver by voice (2808). Route search requires a large amount of calculation and calculation speed. Searching for dynamic road traffic information from a mobile device is inefficient. This invention delegates operations that cannot be performed by inexpensive portable mobile terminals to a server, and communicates with the mobile device only when a traffic jam occurs that the driver may be caught in, and notifies the mobile device of detour information. By giving the server control permission, the receiving driver does not need to perform any operations themselves. Route search and detour search are known from Patent Documents 7 and 8. Figure 29 is a conceptual diagram of another aspect of the present invention relating to location information, etc. When a mobile device 2701 detects a change in location, it transfers (2911) the changed location information to terminal A 2702 having a pre-registered ID. Terminal A grants the mobile device permission to transfer information and permission to issue a warning. The control permission includes permission to listen in. It is assumed that the administrator of the mobile device grants permission to listen in and permission to monitor the caller of terminal A. Terminal A issues a communication request, a listening command, and a monitoring command (2921). In response to these commands, the mobile device sends to terminal A audio signals acquired by an installed transmitter and image signals acquired by an imaging device (2922). This example can be used for a mobile device used to supervise a child. For example, a parent can track their child's location and monitor their activities, such as playing in the park or commuting to school. Location information that changes after school or while the child is on the move is automatically transferred to the parent's terminal A. The mobile device is preferably a PHS, and information is transferred via email, a form of packet communication. Terminal A is preferably a computer with a constant Internet connection via an ADSL line or similar, which displays the location of the child carrying the mobile device on a map in real time. It can also be used for car theft prevention. If there is any unscheduled movement of the vehicle, an alert is sent to the owner, allowing tracking. For taxi or transportation services requiring high location accuracy, a GPS location acquisition method is preferable.

[0032] An image display unit that adds mobile device position information to map data and displays the map data on an image is known from Patent Document 9. The first rule set of the present invention is a receiver (administrator) driven system that allows location acquisition permission to be granted to any caller determined by the administrator. Therefore, unlike the invention shown in Patent Document 9, the caller can directly acquire the location of the mobile device without relying on a third party relay such as a service center fixed to the receiver. FIG. 30 shows the configuration of a mail sending client for pairing with the mail receiving embodiment (FIG. 10) of the present invention, an embodiment of the system described in claim 131. An email 3003 stored in the storage device 13 of the sending client 3001 is sent to the receiving server 3002. For an embodiment of the configuration of the email 3003, see the prior art SMTP (Non-Patent Documents 4 and 5). FIG. 31 is a flowchart of an embodiment of the sending client of the method described in claim 113 used by the system described in claim 131. Session initialization and sending client initialization (3101). An envelope is sent (3102) by issuing SMTP-compliant commands: MAIL command and RCPT command, and the sender and recipient email addresses are transmitted to the receiving server, and a check is made to see if the envelope has been accepted (3103). The processing up to this point is the same as that of SMTP. To determine authorization to send the body based on information contained in the header, the information field contained in the header is sent (3104). The information field contains information that allows the recipient to determine the specified receiving conditions, and a check is made to see if authorization is granted (3105). In the present invention, this step is called the "INFO command." The receiving server can compare the received envelope and information field with the reception conditions specified by the recipient and determine whether to authorize the transmission of the next body. If authorized, it issues a conventional DATA command to transmit the content (3106). If authorized and accepted, the transmission is processed normally and the sent mail is deleted from the storage device 13 (3107, 3109). If not authorized, it performs error processing (3108).

[0033] Prior art SMTP sends the content as a single block after authorizing the envelope and then performs authorization checks. When using only commands at the mail transfer protocol hierarchy, content cannot be rejected until the entire content has been received. Therefore, even if a content rejection is determined based on its content, unnecessary communication occurs. Meanwhile, the widely used content specification (Non-Patent Document 5) includes information fields—Subject, Comments, and Keywords—that contain human-readable information and allow recipients to enter information that allows them to determine the specified reception conditions. Existing email communication software also provides a means for entering information in these fields. If the sender does not initially know the recipient's reception conditions, the receiving server automatically notifies the sender of the recipient's reception conditions. Furthermore, the email address of a sender who satisfied the reception conditions only once is recorded. For subsequent transmissions, if the sender's address in the envelope is determined to have satisfied the previous reception conditions, the information fields are not checked and the content is passed through. As a result, the receiving server can determine whether to authorize the transmission of the body based on the received envelope and information received before receiving the body. As a standard for approval of sending the body, it is desirable to separate the information field from the header and send it before the content, but to make the most of existing communication software, the information field may be extracted from the header and sent first, and if approval is granted, the content may be sent without changing it from the previous one, i.e., with the DATA command that sends the previous content (3106). Alternatively, the header may be sent first, and if approval is granted, the body may be sent. As described above, the present invention utilizes the already widely accepted subject field to build an efficient email communication system that can prevent spam emails. BEST MODE FOR CARRYING OUT THE INVENTION

[0034] When operated on the server side, this invention simultaneously prevents spam and reduces the overall network traffic. When the control and authorization function is used at the same time, a multi-function terminal is realized. A payment system consisting of packet communication connections, virtual account-based rewards, and authentication using the mobile phone's built-in fingerprint recognition function enables robust and convenient cashless transactions. Example 1

[0035] Multi-function telephone (3201) FIG. 32 is a block diagram showing the configuration. Reference numeral 17 denotes a microphone and a speaker. FIGS. 33A to 33D show the TDB, R1DB, R2DB, and R4DB. The presentation information is a question to be presented to the caller. The question is a pre-recorded audio file. In this example, a blank question field indicates that the question does not need to be presented, the predetermined total score for early termination of the question and answer session is 3 (see FIG. 17, 1707), and the storage condition for automatic review is that if the total score is 5, the caller is automatically given treatment in the second rule execution unit (see FIG. 13, 1310). Figure 34 is a schematic flowchart of the process, and the basic part is the same as Figure 13. In this embodiment, the party terminal is a telephone, or the party terminal function is built into a PC, or it can be realized as an external adapter dedicated to telephones. When the caller calls for the first time from a phone number that the caller does not recognize, a question message is played to the caller, and the caller answers by pressing the dial button. The response is judged and the treatment is decided. FIG. 35 shows an example of an operation in which treatment is automatically given to allow normal calls to the telephone number of a related party through automatic examination. A wide variety of functions can be set, from basic spam prevention functions. The instruction file settings in this example can achieve the following functions: Designated reception (treatment ID = 4) and designated rejection (treatment ID = 1) for each caller's phone number. For unknown callers, an application acceptance is required, so the call is automatically answered immediately without ringing, and the caller is charged the communication fee. This allows for financial sanctions to be imposed on callers who make incomplete calls (one-ring calls) from the machine, and since the caller does not respond correctly, the total score is 0, treatment ID = 0, the call is rejected, and the number does not remain in the call history. However, if you give permission, the call will ring normally, and you won't be charged until the recipient answers. If you get the caller's name wrong during the first question, the call will be immediately rejected. If you press 4 for another matter, the second question will be sent, prompting you to press the appropriate dialing button: 1 for real estate sales, 2 for English conversation, 3 for household goods, or 4 for sporting goods. Depending on your score, each selection will automatically ring, record without ringing, disconnect, or automatically memorize the caller ID, or not. When the PIN code 5678 is pressed, the call will automatically connect without ringing. This allows you to monitor and eavesdrop on babysitters or children at home. For example, parents can choose whether to call or eavesdrop on their child's cell phone.

[0036] The first question in this example is simple, but it can be made more complex to suit your actual usage. For example, if you ask for a first name and a last name in two questions, presented in order (answering the first one correctly before presenting the second), and present five options for each, the probability of getting the correct answer by answering randomly drops to 1 in 25. The number you enter in the answer field can have a variety of functions depending on how you use it. For example, you can use it as an extension number, and if the answering question is set to "Please press the extension number," you can answer calls from people who know that number regardless of the calling number. When treatment is given to the calling number of the other party's home telephone, if the same person calls from a public telephone, the guidance message asks the person to enter their home number as identification, and the entered number is collated with the treatment information to determine the treatment. The specific method for reviewing the benefits application will vary depending on the specific configuration of the device of the party involved. Various methods can be used as long as they achieve the objective of the review stage of the present invention. For example, voice recognition or image recognition may be used. Existing automated telephone transaction technology used by banks etc. provides voice guidance to the caller, who then operates the dial buttons and confirms the customer's identity using a PIN number. This invention differs in that the response method is different for each call number and the caller does not need to register a PIN number in advance. In this example, the electronic secretary accepts the intentions of the parties using rules and scores, but it is also possible to accept requests using natural language. For example, "Receive calls from people who know my name" or "Receive solicitation calls related to used car sales." Using well-known rule-based technology (see, for example, Patent Document 11), the electronic secretary can listen to these requests, have the user input any missing information, and compile the necessary rules. The electronic secretary of the present invention can be installed on the telephone exchange and related service providing server side using publicly known technology (see, for example, Patent Document 6). Symbol 21 is the electric lock control unit, and symbol 22 is the electric lock of the controlled device. When number 8765 is pressed, score = 10, treatment ID = 6, and an unlock signal are output, unlocking the front door. The communication line for unlocking can be a telephone line or a short-range communication means such as infrared. The present invention differs from the invention shown in Patent Document 21 in that it includes an element called a second rule set, in which the decision on whether to allow or disallow communication does not depend on the caller ID. As a result, it is possible to authenticate the caller from the content of the communication, and real-time control is possible. Example 2

[0037] Answering machine (3601) Fig. 36 is a diagram showing the configuration of a telephone set according to this embodiment. Figs. 37A to 37C show the TDB, R1DB, and data database (GDB) for recording response guidance (presentation information). This example illustrates the concept of the present invention: all communications are subject to a multi-treatment permission system, and a means is provided for granting permission to unauthorized parties. This example records calls from unknown parties and does not answer them directly. This protects the elderly and other vulnerable people from fraud. It is suitable for users with a relatively limited communication range, except for business use and unspecified parties. It is also possible to reject all calls from unauthorized outsiders, and as usage time accumulates, the treatment settings are automatically completed, achieving the goal without excessive burden on the parties involved. The example given is a first-time caller pretending not to be home, and if the caller's identity can be confirmed by their voice, the call can be made immediately. It is desirable to devise a system that is convenient for operation, such as allowing the number of the last caller to be easily registered with a single button. If there is an important customer, the caller's number can be registered in advance. Caller identification can be done by group. For example, area codes can be used to allow calls to be made to hometown numbers. This example is simple, easy to use, and inexpensive to manufacture. It can be implemented in an external adapter for the telephone, or on the server side that provides the exchange and related services.

[0038] In the past, it was taken for granted that if a person paid to make a communication request, the recipient would receive it. However, with the development of communication networks, it has become increasingly costly to issue communication requests, and as more and more people have access to communication networks, there is no reason to accept communication requests from anyone. At the very least, it should be possible to reject calls from people who are completely unrelated to the person. Conversely, with the exception of public services, the person making the call usually knows the person they want to talk to in advance and has a reason for calling. Therefore, the permission-based communication of the present invention can prevent nuisance communications without sacrificing much of the conventional communication functionality. This invention differs from the invention shown in Patent Document 12 in that it allows a one-time call to be made to a call recipient such as a mail order salesperson without going against the recipient's wishes by using the answering call feature. It also differs from the invention shown in Patent Document 34 in that it has a call rejection feature. Example 3

[0039] Email receiving client system In this embodiment, the electronic secretary is incorporated into the party's terminal. It will be commercialized as a PC (personal computer) application (URL: http: / / www.netinfotech.co.jp, http: / / www.Emailship.com) and will be available for public sale soon. Figure 38 is a block diagram showing the configuration of the third embodiment. In this figure, reference numeral 10 denotes the server equipment of the ISP. Reference numeral 381 denotes a mail service party terminal. This embodiment is a client of the ISP's mail service server, reference numeral 11 denotes a processor, which is composed of a CPU and the like, and controls each part, transfers data, performs various calculations, temporarily stores data, etc. Reference numeral 12 denotes an input / output control means, which controls data input from a server connected via a communication line and controls data output to the server. Reference numeral 15 denotes a communication transfer device, which is connected to the ISP. Reference numeral 16 denotes a keyboard and display unit, and reference numeral 13 denotes a storage device. First, such a program is used in the processor 11, and is composed of, for example, a program for setting treatment, initial expected treatment, request confirmation question, correct answer (keyword), treatment to be given to the correct answer, and the main electronic secretary program. Next, data such as instruction files are stored in the storage device 13. A magnetic storage medium is used as the storage device. Figures 39A-D show the TDB, R1DB, R2DB, and GDB. A question and presented information are automatically returned to the sender. Figure 40 is a schematic flowchart of the receiving process. The basic part is the same as Figure 8.

[0040] Processor 11 displays a question input screen as shown in Figure 41 on the display unit of terminal 381, and prompts the terminal operator to input the criteria for determining this treatment, i.e., the requested confirmation question, the correct answer, and the treatment to be given to the correct answer (4101). When an email from an unauthorized sender arrives at the server, an automatic reply is sent to the sender with presented information and questions guiding them to apply for permission, and while guiding them through the application, the sender is asked to enter the answer to the confirmation question in the subject line of the reply email. Most spam emails are sent automatically by machines. For example, if a correct answer is given to a confirmation question such as "How many is one plus one?", it is clear that the sender is a human being and not a machine, and unlike when the recipient is an automatic email sending machine, the recipient can decide for themselves whether they wish to receive future emails. Of course, there are many machines that can do addition, but it would not be profitable to create a machine that can automatically understand the questions posed to each person. This invention achieves its purpose without opening the email itself. It significantly reduces the amount of communication traffic, especially for the charged portion of the connection to the server, such as a mobile phone. If a correct answer, such as the recipient's name or keywords in a category of interest, is detected from the subject or body of the email, a specific treatment is given. In other words, it implicitly performs a permission request procedure, providing convenience to the sender. When searching from the body of the email, it is preferable to use a server-side version of this invention. Processor 11 displays a screen such as that shown in Figure 42 on the display unit of terminal 381, prompting the terminal operator to select initial expected treatment 4202 from list 4201. Figure 39A shows the treatment set adopted in this example, and one of the specific realizations of the treatment of the application acceptance type is "return a request confirmation question to the sender and refuse to receive." If necessary, it is possible to add treatments such as "return a request confirmation question to the sender and receive only the subject."

[0041] A specific example of a type of treatment that allows partial communication is "receive a limited size, save it in a temporary folder, and notify the recipient." There is also the "receive" treatment, which is necessary for manual review. The "receive and give receive treatment" treatment gives the receive treatment to the sender after receiving the email. If the email is received from an unknown email address, a request confirmation question is sent back to the sender as an initial treatment, and the email is rejected. In the initial setting of this product, first, after receiving confirmation from the parties, the recipients listed in the address book of the existing email software are given a receiving permission treatment (treatment ID = 4) (Fig. 42, 4203), and then the recipients can be individually allowed to receive or blocked addresses and domain names can be entered at any time, and the treatment can be set and changed for each sender. It is also possible to extract the recipient address from the email sent by the parties and automatically give the recipient a receiving permission treatment. 39A to 39D are examples of the set treatment information, and the following functions can be realized simultaneously: designated reception (treatment ID = 4) and designated rejection (treatment ID = 1) for each address or domain, Reject unwanted emails sent automatically by a machine (Treatment ID = 2), restrict reception of emails sent by unrelated people (answered by 1 + 1 = 2) and wait for manual treatment review (Treatment ID = 3), and give the sender the treatment of receiving emails only after receiving emails sent by someone who knows the recipient's name (Treatment ID = 5). In this embodiment, the presented information is processed in multiple languages ​​based on the character code information contained in the mail header information and the regional information contained in the suffix of the domain name of the sender address. This invention differs from Patent Document 21 in that it includes an element called a second rule set, which does not depend on the sender ID for determining whether or not to allow communication. Therefore, it is possible to prevent phishing scams in which the sender address is forged by issuing a password (Fig. 39C, 5678) to the sender. It is equipped with a means to express interest in the sender through the presented information (Fig. 39D), and it is possible to search for the other party's responses or keywords from the subject or body of the message, enabling communication that is beneficial to both parties. Example 4

[0042] Internet videophone and surveillance system In this embodiment, an electronic secretary is operated on the server side and a videophone terminal for a party is completed on the client side for communication via the electronic secretary. 1: Fig. 43 is a block diagram showing the overall configuration. Fig. 44 is a block diagram showing the internal configuration of the first embodiment. In this diagram, reference numeral 430 denotes a server, which is connected to the Internet via a route control device and a telephone line. Reference numerals 431 to 434, ... denote various terminals, which are connected to the Internet in the same manner as the server 430. Here, the terminals 431, 432, ... each have an output unit such as a CRT, LCD, speaker, etc., an input unit such as a keyboard, mouse, camera, microphone, etc., and a function for executing a videophone program. 1-1: Server Configuration Next, the detailed configuration of the server 430 will be described. Fig. 44 is a block diagram showing the configuration of the server 430 and the terminal. In this diagram, reference numeral 11 denotes a processor, which is composed of a CPU and the like, and controls each part, transfers data, performs various calculations, temporarily stores data, etc. Reference numeral 12 denotes an input / output control means, which controls data input from a terminal connected via the Internet, and controls data output to the terminal. Reference numeral 15 denotes a communication transfer device, which is connected to the Internet. Reference numerals 13 and 14 denote storage devices, in which the following files are stored: First, a main program is stored in the storage device 14. This main program is used by the processor 11 and is composed of, for example, a program for displaying a treatment application screen on the display unit of the terminal, a treatment screening program for displaying detailed information about the party who sent the treatment application, a program for displaying the public name of the party who sent the treatment application in the party's address book, a program for displaying the status of other parties, a program for activating a videophone program, and a program for displaying an icon for calling the other party.

[0043] Next, a party master database table and a treatment relationship master database table are stored in the storage device 13. The party master stores party information records. One party information record is composed of information specific to the party, such as the party ID, password, email address, IP address, self-introduction, etc. (See the PDDB for another example of party data). In this embodiment, the party ID is automatically assigned by the processor 11 when a new registration for service participation is made, but identity registration can be performed at this stage. The password, email address, and self-introduction are stored as information registered and sent by the party from the terminal 431, 432, ... The IP address stores the address of the terminal that sent the signal when the videophone communication program of the terminal 431, 432, ... is started. The treatment relationship master stores treatment information records. One treatment information record is made up of treatment information and treatment application indication information. When the present invention is operated on the client side, it records the treatment given to the other party using the R1DB. When operated on the server side, the highly efficient treatment relationship master TRDB (see Figure 2H) of this embodiment is desirable. Treatment information consists of the recipient's own ID, the caller ID to whom the recipient gave treatment, and the treatment given. Treatment information and treatment application display information are information entered from the user interface of a program that displays a treatment application screen on the terminal display, and are information sent from terminals 431, 432, ... 2: Operation will be explained. Here, terminals 431, 432, ... are each connected to server 430 to communicate, and all function as terminals for the videophone parties, but for convenience of explanation, the following explanation will be given assuming that terminal 431 is connected to server 430. When terminal 431 is connected to server 430, processor 11 detects this connection via input / output control means 12 and controls terminal 431 in accordance with the main program. Figure 45 is a flowchart showing the operation of this main program.

[0044] 2-1: To explain the process of creating a party information record, let us assume that the terminal operator is a new party. New registration will be explained. In step Sa1 shown in Figure 45, processor 11 displays a main menu screen as shown in Figure 46 on the display unit of terminal 431, and prompts the terminal operator to select the desired process from "Login" and "New Registration" in order to use the service. On this main menu screen, a mouse cursor MC is displayed, and various operations can be performed by clicking on a predetermined location. For example, if the mouse cursor MC is positioned over the display area of ​​either link button 4601 or 4602 and the mouse cursor MC is clicked, the process indicated in that display area is performed. Here, the terminal operator positions the mouse cursor MC over the display area of ​​link button 4602 and then performs a click operation (hereinafter, this operation will be simply referred to as a click) to select the "New Registration" process. Detecting this, processor 11 proceeds to step Sa2 shown in Figure 45, where the terminal operator is prompted to enter their name, email address, and password. If it is determined that the entered email address is not in use in the party master, a user ID is automatically assigned by processor 11 based on the entered information, and the user ID is used as the party's public ID. Next, processing of step Sa3 is performed. In step Sa3, processor 11 controls terminal 431 to display the contact book screen shown in FIG. In the following steps Sa4 to Sa7, you can always return to the contacts screen or the main menu screen by performing a specific operation. Now, in the case of a newly registered party, this contacts screen will not display any contacts in the contacts, but for the sake of convenience, we will use a screen that already has several contacts.

[0045] First, we will explain how to add a new contact. In order to communicate with a contact, you first apply for special treatment. Adding a new contact is a specific procedure for applying for special treatment. On the screen for adding a new contact, you can apply for special treatment and specify the treatment you want to give to the contact at the same time. The terminal operator is prompted to add a member. The terminal operator clicks link button 4701. Processor 11 then performs the processing of the next step Sa4. In step Sa4, processor 11 controls terminal 431 to display the member addition screen shown in Fig. 48, and prompts the terminal operator to input public ID information. This example shows an example of a pre-application. The public ID is either published by the person concerned on an Internet bulletin board or in a chat room on a communication network, or directly provided by the other party. This member addition screen displays input boxes 4801 and 4802 for the ID and self-introduction. Check buttons 4803 through 4807 are displayed, corresponding to the information disclosure treatment to be given to the other party: "Publish email address to this member," "Publish private email address," "Publish homepage address," "Publish profile address," and "Publish my status to this member." A selection box 4808 is displayed, corresponding to the incoming call permission treatment to be given to the other party. The terminal operator is prompted to enter and select the other party's public ID, 200, in the "Identification ID" box, and the self-introduction "This is..." in the "Self-introduction" box. Then, the terminal operator clicks the execute link button 4810. The treatment set in this embodiment has three types of incoming call permission for videophone incoming call response methods: "automatic rejection of reception," "prompt every time," and "automatic reception." "Automatic reception" is a control permission treatment. The caller instructs the receiver's communication device (videophone terminal) that they have control, and can communicate with the caller without the receiver's intervention. Of course, the terminal must always be in a state where it can receive calls.

[0046] The information disclosure range to the other party is configured by multiple selectable options: "Disclose email address to this member," "Disclose private email address," "Disclose homepage address," "Disclose profile address," and "Disclose my status to this member" (4809). Regarding treatment application, there are two options: "Accept treatment application" and "Reject treatment application." The default initial treatment is "Inquire every time," and if all information is not disclosed, it is "Accept treatment application." This embodiment does not include a function to change the initial expected treatment. Now, with this operation, the procedure will perform the next execution process of the treatment application (see Figure 49). Here, the terminal operator is Party A, the person with whom the user wishes to communicate is Party B, and Party B's public ID is 200. In order to process the treatment request based on the treatment given by party b to party a, processor 11 first checks whether party a is already on party b's sender list by searching the already created party master (4901). If party a is on party b's sender list, it checks the treatment given by party b to a in relation to the treatment request (4902). If the treatment given is "treatment request rejected," it controls the display unit of terminal 431 to display "Member addition rejected" (Sa8), and then returns the procedure to step Sa3 to display the contact book screen again. If party a is not on party b's sender list and the treatment given is not "treatment request rejected," it gives the default initial treatment to party a, creates a new treatment information record consisting of b's and a's IDs, initial expected treatment, and treatment request indication information, stores this in the treatment relationship master, and returns to the contact book screen. In step Sa3, processor 11 controls terminal 431 to display the contact book screen shown in Fig. 47. The terminal operator is prompted to confirm the personal settings. The terminal operator clicks link button 4702. Then, processor 11 performs the processing of the next step Sa7.

[0047] In step Sa7, processor 11 controls terminal 431 to display the personal setting screen of the party shown in Figure 50, displays public ID 5001 to the terminal operator, controls the display area of ​​the public ID to be write-protected, and controls so that personal information 5002 can be changed. 2-2: Login,In 2-1, the operator of terminal 431 is party a, who has completed a treatment application to party b. Here, it is assumed that the existing party b is operating terminal 432. For convenience of explanation, the screens displayed on terminal 431 in the explanation of 2-1, and Figs. 46 and 47 will be used in the following explanation as screens displayed on party B's terminal 432. The following explanation will be given assuming that terminal 432 is connected to server 430. When terminal 432 is connected to server 430, processor 11 detects this connection via input / output control means 12 and controls terminal 432 in accordance with the main program. Fig. 51 is a flowchart showing the login processing operation of the main program. In step Sa1 shown in Fig. 45, processor 11 displays a main menu screen as shown in Fig. 46 on the display unit of terminal 432, and prompts the terminal operator to select the desired process from "Login" and "New Registration" in order to use the service. Here, the terminal operator enters an email address and a password in "Email Address" input box 4603 and "Password" input box 4604, and clicks link button 4601 to select the "Login" process. Detecting this, processor 11 checks by searching for the party master that has already been created based on the entered email address and password (Fig. 51, 5101).

[0048] If processor 11 determines that the email address and password are incorrect, it proceeds to step Sa7, and controls the display unit of terminal 432 to display "Email address or password is incorrect," and then returns the procedure to step Sa1, causing the main menu screen to be displayed again. On the other hand, if processor 11 determines that the entered email address and password are correct, it performs the processing of the next step Sa3. In step Sa3, processor 11 controls terminal 432 to display the contact book screen shown in Figure 47, extracts the person who has newly applied for treatment from the treatment relationship master, notifies party b, and displays party a who has applied for treatment in party b's contact book in green with party a's public name souss (4705).In accordance with the information disclosure treatment given to party b by the other parties, the status is disclosed using colors and icons (4706).An email creation icon is displayed for persons who have disclosed their email addresses (4703), a link icon is displayed for persons who have disclosed their profile addresses (4704), and detailed information about the person corresponding to the pencil icon is displayed. When the link button (4707) is clicked, the processor 11 performs processing of the next step Sa5. In step Sa5, the processor 11 controls the terminal 432 to display the friend list item editing screen shown in FIG. 52, performs treatment review and treatment changes on this screen, displays detailed information 5203 of party a who sent a treatment request to party b, and controls editing of treatment 5201 to be given to party a, thereby prompting party b to review party a's treatment request, decide on treatment to be given to party a, and select each treatment content. In addition to reviewing treatment requests, the processor 11 also changes treatment given to existing partners on this friend list item editing screen.

[0049] Party B then selects each treatment content and clicks link button 5204. Processor 11 then updates the treatment information record based on the selected treatment content and stores it in the treatment relationship master. If party B wishes to sever the relationship with the other party, he or she clicks link button 5202 to delete the other party. Processor 11 then performs processing of step Sa6. In step Sa6, processor 11 controls terminal 432 to display the treatment application qualification designation screen shown in FIG. 53, and by selecting "reject treatment application" for treatment application qualification 5301, future contact with the other party can be severed. Party B then clicks link button update 5302. Processor 11 then updates the treatment information record based on the selected treatment content and stores it in the treatment relationship master. This example illustrates the implementation of the anonymous communication function part of the present invention. As long as the parties do not reveal their identities, anonymity is maintained, and anonymous communication can be easily realized using all communication functions using a normal number (ID). The server here is not a dedicated central controller that removes identities from communication content, and there is no need to create a special communication channel. To prevent crime, it is sufficient to properly register the identity when obtaining the ID. 2-3: Videophone Communication. Assume that party a and party b have established a friendly relationship through the processes described in 2-1 and 2-2, and that party a's terminal 431 and party b's terminal 432 are connected to the server 430. FIG. 54 is a flowchart showing the operation of the videophone communication program. In step Sa3, processor 11 controls the display of the contact list screen shown in FIG. 47, and party b clicks the link button "Start Program" (4708). Then, processor 11 starts the videophone communication program on party b's terminal and passes "-" as the start parameter. When the videophone communication program starts, it sends the IP address of its own terminal to the server (5401), and then determines whether the start parameter is an IP address (5402). If it determines that the parameter is not an IP address, it displays a connection waiting screen and waits for a connection (Sb3: connection waiting screen, FIG. 55). A connection request is checked during standby (5405). The processor 11 updates the information record of the party b based on the IP address information sent by the terminal videophone communication program of the party b, and stores the updated information in the party master.

[0050] Then, the status display icon for party b (4709 in Figure 47) is displayed as a camera icon on the contact screen of party a. Party a clicks on party b's camera icon 4709. Then, processor 11 extracts party b's IP address from the party master, starts the videophone communication program of party a's terminal 431, passes the IP address as a parameter (5403), notifies the caller ID, and requests a connection to the destination IP address, i.e., makes a call to party b and receives a response from the callee b's videophone communication program (5404). When the videophone communication program of the recipient b receives a connection request, it queries the processor 11 using the caller ID as a query parameter, and upon receiving the query, the processor 11 extracts treatment information from the treatment relationship master of the server 430 based on the caller ID (5406), and returns the treatment given to the caller party a to the videophone communication program as the query result. If the treatment given to the caller party a is "automatic reception" (5407, YES), the electronic secretary instructs the callee side communication device TV phone terminal that the caller has control, and in response, the callee party b's video phone communication program permits the communication request without ringing, without displaying an input request screen and going through the input request, sends a response of connection approval, makes an automatic connection, and allows the other party to obtain the image signal captured by the camera, i.e., sends the image signal, and at the same time, when the image signal sent by the other party is received, it is displayed on the screen and a video phone communication in progress screen (Sb2: video phone communication in progress screen, Figure 56) is displayed. Meanwhile, the videophone communication program of the caller party a receives the approval response, and after steps 5404 and 5409, displays the received image signal on the videophone communication screen and communicates or monitors (Sb2). If the treatment given to the caller party a is "inquire every time" (Figure 54, 5408, YES), the videophone communication program of the called party b rings the bell and displays an input request screen (Sb4: approval inquiry screen: displays "You have received a call from party a. Do you want to accept?") to inquire of the called party b whether to connect.

[0051] At the same time, the caller's videophone communication program displays a screen waiting for the other party's approval (Sb1: Approval waiting screen: displays "Waiting for the other party's approval..."). If the called party b approves the connection (Fig. 54, 5410, YES), the videophone communication program displays a videophone communication in progress screen and makes the caller party a's videophone communication program respond that the connection has been approved, and then the videophone communication program running on the caller party a's terminal recognizes this response (5409, YES), displays a videophone communication in progress screen, and begins communication. If the called party b does not approve the connection (Fig. 54, 5410, NO), the videophone communication program displays a connection waiting screen (status display: 5501) and makes the videophone communication program of the calling party a respond that the connection has been rejected, and then the videophone communication program running on the calling party a's terminal judges this response (5409, NO), displays the connection result as "Access denied" (Fig. 55, 5502, Fig. 54, 5411) on the display unit of the terminal of the calling party a, then displays a connection waiting screen and waits for the connection (Sb3: connection waiting screen, Fig. 55). If the treatment given to the calling party a is "automatic reception rejection" (Fig. 54, 5408, NO), the same processing as when the called party b does not approve the connection is performed. 3: Flow overview Next, Figure 57 shows the flow of establishing a relationship of service with the recipient party via a public ID. To receive the communication service of the present invention, party A first uses terminal 5701 to log in to server 5702 via the Internet, and then uses public ID: 200 that party B has made public to submit a service request to party B expressing their desire to communicate (1). Party A, requesting treatment, enters the public ID of recipient party B: 200 (Figure 48, 4801), and at the same time grants party A the "Inquire Every Time" treatment (4808) to party B. The server saves the "Inquire Every Time" treatment that party A grants to the designated party B in the treatment relationship master (5703), and if party A does not exist in party B's caller list, it grants party A party B's initial treatment of "Automatic Rejection of Reception" (5704). In this state, party B can make calls and communicate with party A. Reverse communication is not possible. The recipient takes the initiative. The server notifies party A that it has accepted the request (3), (4). When party b logs in to the server using terminal 5705, the party who has newly applied for treatment is extracted from the treatment relationship master and notified to party b (5) to (8). In Figure 47, party a who has applied for treatment is displayed in party b's contact book in green with party a's public name souss (4705), and the status is made public with colors and icons according to the information disclosure treatment given to party b by other parties (4706).

[0052] Figure 52 shows detailed information about party a who sent a treatment request to party b. Party b reviews the treatment request and decides the treatment to give to party a (Figure 52, 5201). The treatment given to party a, "Inquire every time," is replaced with the treatment stored in the server, "Automatic rejection of reception" (10). This allows parties a and b to send connection requests to each other's videophone partners. This embodiment allows control permission to be granted to any one or more callers, allowing the caller to directly control the receiving device, launch the receiving device's TV communication program, and send and receive data with the receiving device. Instead of controlling the video phone camera in this embodiment, it can also be implemented to control the GPS receiver of a mobile phone. The ability of any caller granted control permission to directly obtain and display the receiver's location information differs from the prior art shown in Patent Document 9, in which location information can only be obtained from a fixed location information center during the product design stage. Since a third-party location information center is not required, significant benefits are achieved, resulting in significant reductions in hardware equipment and user operating costs. Mobile phone models equipped with a means for displaying their own location information can obtain the original display data from the other party's mobile phone and display it on their own device's display means. Example 5

[0053] Mail Server System Figure 58 is a block diagram showing the configuration of this embodiment, and illustrates the operation of an electronic secretary 5801 of the present invention on the mail server side of ISP 5812. The electronic secretary is independent of the existing mail server, and after receiving permitted emails, forwards them to the conventional mail server 5802. Emails sent from clients of ISP 5812 are processed directly via the electronic secretary. When handling the business contact address of a public institution that provides services to unspecified senders or a product sales company, the electronic secretary 5801 writes keywords related to its own business scope or services in the guidance information, and when a request to send an email for which communication permission has not been granted in advance arrives, if the specific keyword is not detected from the header of the email in accordance with the second rule, the electronic secretary 5801 presents (replies to) the guidance information to the sender and refuses to receive the email. For example, the email address for inquiries regarding applicant registration at the Japan Patent Office is PA1670@jpo.go.jp (abbreviated as "F" in Figure 58), and the guidance information for this address (Figure 60) states, "This address is the contact point for the applicant registration officer in the Patent Office Application Support Division. If you would like to use this address, please write <Inquiries regarding applicant registration> in the subject line of the email and resend it." Consider the case where the second rule set (Figure 61) is set up in the electronic secretary to temporarily receive emails containing "inquiries regarding applicant registration," but not to give any special treatment to the sender (ID=5, Figures 59 and 61).

[0054] The email address of the applicant terminal 5804 is fe1@netinfotech.co.jp ("A" in Figure 58). The applicant obtains an inquiry email address from the Japan Patent Office's website, and preferably information is also posted on the website. The applicant then writes the string "Inquiries regarding applicant registration, registration method" in the subject line and sends an email (Figure 58, (a1) To:F, applicant registration related...) to PA1670@jpo.go.jp (F). The electronic secretary is permitted to receive the email in accordance with the second rule, and it is forwarded to the mail server 5802. The email is placed in F's mailbox. The reply (a2) from the Application Support Division is sent via the electronic secretary. If an applicant sends an email for the first time without knowing the keyword, the electronic secretary will immediately send an automatic reply and provide the applicant with the guidance information. Even outside of the Patent Office's business hours, applicants can receive the guidance information in a short time. The automatic reply route for the guidance information is applicant → sending server 5803 → receiving server 5801 → sending server 5803 → applicant. We tested sending and receiving from sender → sending server → receiving server → recipient using an actual ADSL line and in an environment with URLs: mail.netinfotech.co.jp and mail.yahoo.co.jp servers. The time taken was less than 5 seconds. Therefore, applicants can resend the email by following the instructions with almost no time delay. When a terminal 5805 that uses a robot to send spam emails sends an email (Figure 58, (b1) To: F, oooxxx...) to the Application Support Division for product sales, the electronic secretary sends an automatic reply (b2) informing the user of the information, and then refuses to receive the email. Normally, it is impossible for the robot to understand the information and resend it according to the instructions. If an email attack occurs due to a person intentionally following the guidance information, it is possible to manually set up a communication rejection. When a mail bomb attacker 5806 who frequently sends a large number of emails using a robot sends an email to the Application Support Division (Figure 58, (c1) To: F, oooxxx...), the electronic secretary will automatically reply (c2) to provide information and then reject the email. When the electronic secretary using the method described in claim 9 (see Figure 14) automatically replies, a third rule is created based on the sender's email address, the time of receipt, and a specified rejection treatment (ID=0), and added to the third rule set for attack prevention (Figure 63). In this embodiment, the constants used are shown in Figure 64. The specified time in the condition part of the third rule for attack prevention is set to 60 minutes, and the specified treatment is to reject the email if there is no reply. Then, if the attacker sends a second email (c3) within 60 minutes, it will be rejected with no reply (Figure 14, 1407), and any subsequent attacks will be rejected immediately upon checking the email envelope.

[0055] A preferred variation of the present invention is to add the number of emails arriving to the condition part of the third rule. For example, if the attacker's fifth email arrives within 60 minutes, the communication request is processed based on the treatment. Since the electronic secretary determines the sender based on the envelope or header of the email (claim 5), there is no need to receive the email itself, which can significantly reduce the amount of traffic on the public network. In the prior art shown in Patent Document 13, when the sender is unknown, the system temporarily receives the email, automatically replies to the sender with a confirmation email created by the server, and once the email is confirmed, passes the received email to the recipient. As described above, the present invention differs from the prior art in that it does not generate a large amount of unnecessary communication on the public network, eliminates the risk of email attacks overwhelming communication bandwidth or overloading server memory, eliminates the risk of the automatic reply email itself becoming a large number of new spam emails due to the mechanism of a third rule set for attack prevention, and reflects the subjective intentions of each recipient. Furthermore, when operated on the client side, such as on a mobile phone, the present invention has the advantage that recipients who have been inconvenienced by spam emails are not further charged unreasonable fees. As described above, it is possible to completely reject erroneous emails, machine-sent spam emails, and attack emails while ensuring normal business operations. A preferred variation of the present invention stores the IP addresses of anomalous callers and rejects TCP connections by IP addresses. When a sender uses a conventional mail sending server (SMTP client), the electronic secretary determines the sender's identity from the email header and forcibly terminates the communication by closing the underlying delivery connection without receiving the email body (Claim 6, Figure 11). Since the sending server whose communication has been forcibly terminated will retry, the forcibly terminated state is recorded using a dedicated third rule set, and when the sending server retries, the electronic secretary identifies the other party from the recorded sender ID and terminates the communication normally. Figure 65 shows the dedicated third rule set (R3DB2). Please note that different data is recorded from the third rule set for attack prevention (R3DB1) shown in Figure 63.

[0056] If the mail sending server uses a sending system utilizing claims 99 and 100 instead of the conventional technology, authorization to send the body is determined based on the information contained in the header. Therefore, the information field contained in the header is sent (Fig. 31, 3104). The electronic secretary on the receiving server receives the information field containing the subject, and then applies the second rule set (Fig. 10, 1006, 1007, 1009) to determine whether or not to authorize the sending of the body. If authorization is granted, that is, if communication is permitted, the sending side is notified, and the communication continues (Fig. 31, 3106). Using the inventions of claims 99 and 100 and the electronic secretary simultaneously further reduces unnecessary communication volume, eliminating the need to forcibly terminate communication. Communication control processing becomes clearer. When sending email from an electronic secretary, it is possible to prevent spam communications from the source (see Claim 26, Figure 20). D: Mail bomber (5807) sends email (Figure 58, (d1) To: A, oooxxx...) to A: Applicant, and A is using electronic secretary 5803 operated on the server side. Electronic secretary 5803 receives (d1) and, since sender D does not have permission to receive, sends automatic reply (d2) to the sender informing them of the applicant's information and rejects the receipt. Electronic secretary 5801, who sent (d1), receives the rejection treatment from 5803, creates a fifth rule, adds it to the fifth rule set R5DB (Figure 66), and saves it in sender D's instruction file. If D again sends (d3) within the time (one day) set in the fifth rule condition part, electronic secretary 5801 applies the fifth rule and rejects the transmission (Figure 20, 2004). Such spam is rejected by the original sending client before it reaches the public network 5813. For example, if the sender uses Microsoft Outlook, when they press the send button, Outlook immediately reports the message as undeliverable.

[0057] While the system is running, the third and fifth rules are deleted if a specified time has passed since the time they were created. Companies and organizations that provide services to specific callers often have business communications that are limited to a certain range. Conventional public telecommunications networks offer cheap and fast communication. However, due to their open nature, they are not suitable for such business. This invention achieves the effect of closed communication for specialized users over a public telecommunications network. For example, the Japan Patent Office currently only handles inquiries about the status of patent examinations via mail. The present invention proposes the following process via email: The email address for the inquiry is assumed to be E (Figure 58, 5808). The information for E states, "This is the contact point for inquiries about the status of patent examination. If you are using this for the first time, please enter "Application number: Reference number" in the subject line of the email and resend. Example: "Patent application 2003-70953:0302-001"." When the email arrives, the second rule grants communication permission to receive email to the sender who correctly entered the application number and reference number, and the granted permission is saved in the first rule set. The "Application Number:Serial Number" serves as the password for first obtaining permission to communicate. Alternatively, a password determined by the Patent Office or the applicant can be used. The password will be included in the application delivery documents. The predetermined recording condition of claims 101 and 102 includes the treatment ID. If the treatment ID determined by the second rule is 6, the treatment is saved. That is, the password is not checked for the sender's second and subsequent emails. When a business system has many communication parties and is dynamically changing, it is difficult to manually maintain the instruction file. This problem is solved by the instruction file input component described in claims 131 and 132.

[0058] Figure 67 illustrates the layout of the user interface for the instruction file input component. Figure 68 shows the data passed to the instruction file input component according to the user interface. The electronic secretary 5801 runs on a Microsoft Windows®-based computer. (Someone) enters constants, guidance information, and other information that does not change much into an instruction file on a web server via the Internet. Input components are Microsoft Windows (registered trademark) The terminal 5810, which runs on the base computer, extracts the application number and docket number from the patent office's existing pending case data 5811 and passes them to the component. Alternatively, when the application number is to be stored in the business data, the business system calls the component to input the data into the instruction file. Preferably, the input component stores the authorized caller ID and related information of the second rule set, and deletes the related information from the instruction file after the application case is no longer pending at the patent office. As described above, even when there are many parties involved and the number of parties changes dynamically, a communication environment like a secure private communication network for only the parties involved can be created on a public Internet communication network without manual dynamic maintenance. Although electronic secretary 5801 sends email directly to the Internet 5813, emails other than automatic replies may be forwarded via a conventional mail server 5802, for example, as in 5808-5801-5802-5813 (not shown in Figure 58). In this case, because the email forwarding within the ISP (5801-5802) is fast, the electronic secretary can be spared the responsibility of managing the queue of outgoing emails, and functions such as queue management of conventional mail servers can be fully utilized. A conventional mail server, such as Sendmail running on a Unix-based computer, can be used. The present invention may be utilized as a component of a mail server. Example 6

[0059] An embodiment is an electronic payment system. FIG. 69 is a block diagram illustrating a method and system for electronic payments. [Field] This relates to a system that enables cashless commercial transactions. In particular, this relates to an electronic payment server, an electronic payment system, an electronic payment method, and a program that enable instant payments using communication terminals such as mobile phones. [Background] There are payment systems for credit cards and debit cards (shopping with a cash card). There are also many services for Internet business (e-business) and mobile communication devices such as cell phones and PHS. However, card data can easily be stolen. When shopping with a debit card, entering a personal identification number is insecure, and the PIN can easily be stolen from finger movements. If the terminal is tampered with or the line is intercepted, information used to withdraw money from an account can easily be stolen. This has resulted in damage caused by counterfeit cash cards and stolen personal identification numbers. Patent documents 30 and 31 disclose technology for opening dedicated accounts that prevent large losses. However, deposits and withdrawals between the ordinary account and the dedicated account are required, which reduces the liquidity of ordinary account funds. [Challenge] A payment method and system that is convenient, safe and prevents large losses, and provides liquidity of funds.

[0060] [Means] In an electronic payment system and method for processing commercial payments between an account (e.g., debit card, credit card) holder (hereinafter also referred to as "buyer") and a seller (Figure 69, 6902) at any type of financial institution or payment center (hereinafter also referred to as "bank") to facilitate electronic payments, the buyer (Figure 69, 6901) sends reservation information (Figure 69, A) reserving electronic payment to the bank (Figure 69, 6903) to pay for a planned purchase by electronic payment, and uses an identification ID (Figure 69, B) to purchase a product (Figure 69, G). Table 1 shows The bank's computer A simple example of reservation information, data, and operation information is shown. [Table 1]

[0061] The terms used in this specification are defined as follows: "Communication ID" refers to the communication destination when confirming a payment request with a buyer. For example, this includes a mobile phone number, computer communication address, etc. "Identification ID" means a user identifier associated with a Buyer's bank account, such as a phone number, vehicle identification number, etc. "Virtual Account" means a fictitious account used to make payments to a specific intended payee, such as a railroad, highway, ATM, shopping, or internet store account, or other fictitious account used to make payments to a specific seller, institution, or group of sellers. "Maximum Balance Amount" means a value that specifies the balance of a virtual account. By reserving it, the balance of the virtual account is set to the maximum balance amount. "Confirmation-free limit" means the maximum payment amount for which confirmation may be omitted. The "accumulation limit without confirmation" means the standard amount for which confirmation is always required. Omission of confirmation is a cumulative method, and if the cumulative amount of payments for which confirmation is omitted exceeds the standard amount (hereinafter referred to as "accumulation excess"), confirmation is performed, the cumulative amount is set to zero, and accumulation is resumed. "Balance Notification Amount" means the amount by which your balance is low and you think it would be better to reserve it. "Automatic Recovery Days" means the minimum number of days required for the balance to be automatically restored to the balance limit. "Payment reservation confirmation required" refers to a flag that specifies whether or not the user should reserve a payment request that will occur at the exit when the ID medium holder passes through the entrance to the paid area.

[0062] "Verification Information" means information used to verify a payment request. It is equivalent to a PIN number for a virtual account. The information shown in Table 1 using the above terms, the balance notification destination, and the PIN number are reservation information. "Balance" means the balance in a Virtual Account. "Communication confirmation" means one of the control permission treatments available. See Figure 70 for the treatment ID. "Operation information" refers to information to be input into the authentication program that is started by the communication confirmation procedure. In Table 1, the settlement reservation confirmation necessity flags that are not used for virtual accounts are indicated by "-". The seller generates a payment request (Figure 69, C) requesting payment of the used amount and sends the payment request to the bank for approval. The bank identifies the virtual account from the seller identifier, etc. included in the payment request, and if the balance and bank account balance (hereinafter referred to as the "total balance") are sufficient, the bank presents a confirmation request (Figure 69, D) to the buyer to confirm the payment request. The buyer presents confirmation information (Figure 69, E) to the bank to confirm the payment request. Only after confirmation by the buyer does the bank send approval (Figure 69, F) to the seller and make the payment. The virtual account is identified by a method designated by the buyer, such as an industry code, seller name, product type, etc. The bank provides available information, such as a seller identifier, to the buyer, allowing them to select association with the virtual account. For the data structure and the like related to the payment processing of the present invention, reference is made to known techniques, for example, Patent Documents 27 to 29. Unlike conventional dedicated accounts, reserved deposits (limits that cannot be freely withdrawn from the entire account balance), and prepaid cards, virtual accounts allow the total balance to be freely withdrawn from a bank account. Figure 73 shows a schematic diagram of the balances of bank accounts opened by the account holder and reserved virtual accounts. The balance of a virtual account can exceed the total balance. The settlement amount is equal to or less than both the balance and the total balance. Virtual accounts have the effect of maintaining the liquidity of funds while maintaining the security of payments. There is no inconvenience in depositing too much into multiple dedicated accounts and not being able to easily use the funds for other purposes.

[0063] The confirmation request includes the cause and amount of the charge and asks the buyer to confirm the payment request. Banks are required to process transactions promptly. Sellers may operate their own clearing houses that act as banks. Any information communication means can be used. Any means that can achieve the purpose of this embodiment, such as telephone, email, or the Internet, is acceptable. Communication means that are always connected to a network may also be used. For example, communication may be via the mobile Internet Web or chat-like two-way communication (chat-like interaction). The buyer may call and obtain a confirmation request from the bank. The electronic secretary analyzes incoming communications and performs communication confirmation procedures on the communications to confirm the payment request. For example, an authentication program is launched when a call to the bank's electronic payment telephone number or access to a web page that provides electronic payment services identified by a URL is detected. The reservation information may include verification criteria. The bank may approve the payment request without sending or receiving a verification request and verification information if the verification criteria included in the reservation information are satisfied by the data included in the payment request. Examples of such verification criteria include, but are not limited to, a seller identifier, a payment limit, a settlement date, a settlement time, or any combination thereof, or any other criteria that the buyer may find convenient. The bank may confirm the payment request to the buyer through the seller's communications module, e.g., a cashier's terminal, or may choose to send a confirmation request to both buyer and seller's devices, or may request confirmation via email and / or web. The identification ID recording medium may use any means that matches the seller's device. For example, a barcode may be displayed on a mobile phone display. A magnetic card, ID tag, IC card, infrared, or other short-range communication means may also be used. The identification ID may also be manually entered into the seller's device. Furthermore, it is also possible to select to display the usage history, balance, total balance, etc. on the store's device or print it on the receipt.

[0064] The medium on which the ID is recorded can be duplicated and given to family members for use. For example, a child buys a drink at a convenience store and presents the card with the barcode containing the ID to the clerk to pay, while the parent can confirm the payment request on their mobile phone at home. If the medium is accidentally duplicated or lost, unauthorized use can be easily detected, and the medium can simply be disposed of. It can be used to verify all withdrawals from the user's bank account. For example, when withdrawing cash from an ATM, the ATM can be considered the seller (Fig. 69, 6902). The user enters their account number or unique ID into the ATM using a medium such as a magnetic card, enters the amount, and the bank withdraws the money only after confirming the withdrawal through the user (buyer) communication module. Communication verification can also be performed at the ATM in addition to traditional cash card authentication. Furthermore, the bank can generate a transaction code for each transaction, transfer it to the mobile phone, and use a short-range communication means to input and verify the transaction code into the ATM, and operate an authentication program using a fingerprint, thereby ensuring that only the person in question can make the transaction. The balance is the limit for electronic payments from the virtual account, and the payment amount is deducted from the balance. If the balance is insufficient, the payment request is denied. Amounts within the balance range can be used with verification information other than the PIN. The balance is the maximum loss amount if the identification ID, verification information, and buyer communication device are stolen simultaneously. Any attempt to pay more than the confirmation limit is immediately notified to the owner and confirmed. The confirmation limit is a cash-like amount that can be used with only the identification ID. If you want to reject a payment request, you can invalidate the confirmation information. The relevant The virtual account may be frozen. Payment amounts that do not require confirmation are accumulated, and when a payment request is made that would exceed the confirmation-free accumulation limit, confirmation is always performed, and the accumulation is then reset to zero before continuing. This allows for the confirmation of large payments. The confirmation-free accumulation limit is the maximum loss amount if both the identification ID and confirmation information are stolen at the same time.

[0065] When the balance falls below the balance notification amount, a notification to that effect is sent to the designated balance notification destination. Furthermore, when certain conditions are met, the balance is automatically restored to the upper limit (automatic restoration). For example, automatic restoration occurs when the condition is met that the number of days since the last reservation or automatic restoration has passed. The verification information is different in nature from authentication information such as a PIN number. It can be used according to the importance of the payment and the usage environment. When using the virtual account for payments in a public environment, it is better to use verification information different from a PIN number. For virtual accounts in environments where safe entry is possible, such as ATM corners, the verification information can be the same as the PIN number. The term "communication confirmation" includes alerting the holder to an incoming communication request with a ringtone, vibration, etc., receiving information and presenting it visually or audibly, and automatically starting an authentication program. The authentication program includes a process of comparing the input operation information with registered operation information, and only if it matches, transmitting the pre-registered information to the outside (bank). The operation information includes a simple button operation, an authorization code, a voice, a password, a human physical characteristic (biometric information) such as a fingerprint, etc. The confirmation information is used as the registration information. If necessary, multiple communication confirmation treatments such as those shown in FIG. 70 can be provided. Reservations can be made via the internet, telephone or at a bank counter using your ID or account number and PIN. Device etc. Device It would also be good to make it so that only those who have the same password can make a reservation.

[0066] Preferably, the personal identification number (authentication information) to Use a one-time password (OTP) And Since a different password is used for each communication, damage from wiretapping can be prevented. For example, the authentication program can be equipped with a function to realize OTP. Temporary reservations can be made even with public telephones, and a daily usage limit can be set to prevent damage from line tapping. Furthermore, OTP can be used as confirmation information. Preferably, after authentication Prescribed virtual account For example, access the instruction file and give the bank a communication confirmation. Or, add the instruction file to Prescribed virtual account If a valid / invalid flag is set, the communication confirmation treatment will reject the communication if the flag is set to invalid. The personal authentication utilizes the personal authentication means attached to the communication device, and the buyer registers personal identification information in the device in advance. When the personal identification means is activated, the device prompts the operator to enter the personal identification information, compares the entered information with the registered personal identification information, and if the comparison results in a match (authentication successful), allows the next operation. The personal identification information includes biometric information such as a fingerprint, or a password, etc. Preferably, Prescribed virtual account After enabling it, if a certain time, for example, 4 hours, The virtual account will be invalidated (the payment cannot be approved). [effect] For maximum security, before going out shopping, set your balance to the amount you plan to use, set the verification-free limit to zero, and reserve your mobile phone number as the destination, then confirm with your fingerprint. The communication destination is reserved at the store side as a device that remembers the identification ID and confirmation information, and payment can be made by manually inputting the identification ID and confirmation information at the store only by memory.

[0067] When making everyday payments, you don't need to use your PIN during input operations or communication. When making reservations, you can safely use your PIN. You can also choose not to use your PIN at all in everyday life. The outflow speed of money from an account for each purpose can be freely controlled, there is no possibility of high-value damage caused by card counterfeiting exceeding the outflow speed, and if the outflow speed is within the planned range, automatic recovery eliminates the need for reservations, improving household budget planning. Detailed explanation Details of the conventional technologies used (communication software, command transmission, program execution, IC card, OTP, etc.) will be omitted. Figures 70 and 71 show the TDB and R1DB of an embodiment of a mobile phone with electronic payment functionality according to the present invention. The block diagram showing the configuration is basically the same as that shown in Figure 26. The R1DB is an embodiment of the one shown in Figure 2B. For ease of explanation, the calling number is used. As in Example 4, communication means such as a constant internet connection or packet communication can also be used, and the caller can also be identified by an ID such as an email address. Figure 74 is a flow diagram of transaction processing in the virtual account schematic diagram shown in Figure 73. Figure 75 is a flow diagram of approval processing shown in Figure 74. Next, we will explain the reservation for the virtual account "Shopping." The communication ID "090-1234-5678, store," the identification ID "045-1234-5678," the confirmation information "456," and other reservation information shown in Table 1 are sent. The confirmation information and buyer fingerprint shown in Table 1 are stored in an instruction file. The communication ID means that the confirmation request is sent to both the mobile phone and the store terminal. A barcode recording the home phone number is attached to the back of the mobile phone as an identification ID.

[0068] The seller reads the ID using a barcode reader on the cash register terminal, and sends the ID, seller's account number, store name, amount due (A), etc. to the bank to request payment (Figure 74, 7401). If the buyer has forgotten their mobile phone, they can manually enter their home phone number into the cash register terminal. The bank searches for the account number from the identification ID, and if, for example, the initial payment amount A is 500 yen and the total balance (B) is 200,000 yen, B is sufficient and the process continues (7402, YES), and if a specific virtual account cannot be identified, the shopping account is selected (7403). A's balance does not exceed 100,000 yen (7404, YES), and approval processing (7405) is performed. However, since the amount does not exceed the confirmation-free limit of 1,000 yen (Figure 75, 7501), the bank omits confirmation and immediately approves the settlement request. The payment amount of 500 yen for which confirmation was omitted is accumulated in the cumulative amount (C) (Figure 75, 7502). C becomes 500 yen, A is debited from the account, and transferred to the seller's account. At the same time, A is debited from the virtual account, and the new total balance becomes 200,000-500=199,500 yen, and the remaining balance becomes 100,000-500=99,500 yen (7407). If the payment amount for the second purchase, A, is 600 yen, when it is accumulated in C, C becomes 1,100 yen, exceeding the accumulation limit without confirmation (7503, YES). Therefore, the bank searches for the mobile phone number from the identification ID and calls the mobile phone to confirm the payment request. At the same time, a confirmation request is also displayed on the cash register terminal (7504). The buyer confirms the payment request by entering the confirmation information "456" into the cash register or by entering their fingerprint through the fingerprint sensor into the authentication program launched on their mobile phone. If the payment request cannot be confirmed, for example, because the confirmation information is incorrect (7505, NO), the transaction is rejected (7406). If confirmed, the transaction is approved. If the accumulation is exceeded, the accumulated amount C is set to 0 yen (7506). The new total balance becomes 200,000 - 1,100 = 198,900 yen, and the remaining balance becomes 100,000 - 1,100 = 98,900 yen.

[0069] FIG. 72 is a block diagram of yet another embodiment of the present invention relating to a ticket. [Field] Toll collection systems for cashless railways, buses, expressways, urban areas, parking lots, event venues, and other toll areas (hereinafter referred to as "roads") [Means] Electronic payment as shown in Figure 69 is used. The seller (road, Figure 72, 6902) reads the user identification ID at the entrance (Figure 72, 7204) (Figure 72, 1) and sends payment reservation (Figure 72, 2) information to the bank, including the identification ID and reason, to reserve the payment. The bank sends a confirmation request (Figure 72, 3) to the user to confirm the reservation. The user confirms the confirmation request and sends confirmation information (Figure 72, 4) to the bank. The bank sends reserved (Figure 72, 5) information to the seller only after it is confirmed by the user. The seller reads the identification ID at the exit (Figure 72, 7205) (Figure 72, 6), settles the usage fee, and sends a payment request (Figure 72, 7) to the bank. The bank sends a confirmation request (Figure 72, 8) to the user to confirm the payment request. The user confirms the confirmation request and sends confirmation information (Figure 72, 8) to the bank. The bank sends an authorization (Fig. 72, 10) to the seller and makes the payment only after it has been confirmed by the user. If the payment reservation confirmation requirement flag is set to "required," admission control is possible depending on whether the reservation is approved or rejected. Detailed explanation In a specific example, this is the payment of a train fare. An identification ID is recorded on a contactless IC card. For reservations made to the virtual account "Railway Company," the following reservation information is sent: communication ID "090-1234-5678," identification ID "IC card number," confirmation information "456," whether payment reservation confirmation is required "Not required," and other reservation information shown in Table 1.

[0070] The boarding station ticket gate (7204) reads the ID and transfers it to the server (installed in Figure 72, 6902, not shown). The server creates an entry record that records the ID, boarding station, and time, and sends payment reservation information (different from the virtual account reservation information) including the ID and boarding station name to the bank. If the payment reservation confirmation necessity flag is "not required," the bank omits confirmation (Figure 72, 3, 4), sends the reserved information to the ticket gate, and entry is permitted. The ticket gate at the exit station settles the fare of the passenger identified by the read identification ID, sends a payment request to the bank, and allows the passenger to exit once approval is received. If the fare is within the range that does not exceed the confirmation limit, the bank will omit the confirmation (Figure 72, 8, 9), which has the effect of speeding up the exit decision process. If the payment reservation confirmation necessity flag is "Yes", and the identification ID read by the entrance ticket gate is valid, the entrance ticket gate will allow entry and then send a payment reservation to the bank, and if the destination station receives reservation information, it may allow exit and then send a payment request to the bank. This has the effect of speeding up the entry / exit decision process. Furthermore, to speed up processing and reduce costs for processing payment requests, the payment amount without confirmation can be accumulated on the IC card or server. Accumulation and entry / exit judgment can be approved offline without communicating with the bank. For offline approval, the seller obtains the necessary reservation information set by the buyer from the bank.

[0071] Figure 76 is a flow chart for offline approval. The seller terminal reads the identification ID and, if it determines that the product price does not exceed the confirmation-free limit (Figure 76, 7601), it adds the product price to the cumulative amount saved by the seller (7602). If the cumulative amount exceeds the limit, it creates a payment request using the total cumulative amount as the product price and requests approval from the bank using the procedure shown in Figure 74 (hereinafter referred to as "online approval") (7605). If the transaction is approved (7606, YES), it resets the cumulative amount to zero (7607). If the cumulative amount does not exceed the limit, the sales transaction is approved without communicating with the bank. In this system, this process is called "offline approval." An ID (IC card, etc.) is issued for the guaranteed amount, and if payment is refused, the payment is made in cash at the exit. If a cancellation of the ID is requested, the amount used may be deducted from the guaranteed amount and refunded. The cumulative limit that does not require verification and the guaranteed amount may be limited to about the same amount. This has the effect of guaranteeing the collection of payment. For example, if an ID is used that was issued or activated for 1,000 yen, rides up to 990 yen are permitted, and when the next ride is in a 120 yen section, the amount will be set at the exit. Including the increase If the payment is refused, the withdrawal settlement amount is 120 yen, and if the ID is cancelled, the refund amount is 10 yen. For one ID, multiple sellers can independently store the accumulated amount and approve it offline. For example, the same mobile phone number can be used as an ID and be valid for trains operated by different railway companies. Furthermore, passengers can grant location permission to vendors to speed up entry and exit. Entry gates can determine the validity of nearby passenger IDs in advance. Exit gates can provisionally settle fares (assuming passengers will disembark at the station nearest their location). Mobile phone locations can be obtained from the telephone company's system, eliminating the need for direct connection to the mobile phone.

[0072] When processing tickets for entry to an event venue, the customer orders the ticket from a ticket shop or similar before entering, and the entrance management server, which corresponds to a bank, stores the ticket information. The ticket information includes data such as an identification ID, venue name, event name, date and time, number of people, and seat location. The server then sends a call to the mobile phone number corresponding to the identification ID read by the entrance ticket gate, authenticates the person, and then allows entry. Sellers may operate their own clearing center. Instead of public communication methods, they may use mobile infrared, DSRC (Dedicated Short Range Communication), Bluetooth (registered trademark) It is also possible to communicate with the ticket gate using a non-contact short-range communication means such as the above and directly start the personal authentication program on the mobile phone. Yet another particular example is road toll collection. [Background] Japan's electronic toll collection system (ETC system) consists of an ETC on-board unit, an ETC card that stores personal information, contract information or electronic currency, an entrance / exit gate, and a DSRC (Direct Speed ​​Control) device. However, vehicles are required to pass through the gate at a speed that allows them to stop at any time. It is also expensive. Meanwhile, Singapore has a system for ERP that uses cameras to photograph the license plates of vehicles traveling at speeds of 180 km / h or less and charges them accordingly. While the existing camera-based charging technology allows for free-flow toll gates that allow high-speed passage, it is difficult to separate the vehicle owner from the toll payer. [Challenge] To realize a cashless, free-flow fare system at low cost. [Means] Use the electronic payment shown in Figure 69. The vehicle's registration number is used as the user identification ID. For reservations to the virtual account "Expressway," the following reservation information is sent: communication ID "090-1234-5678," identification ID "license plate number," confirmation information "456," whether payment reservation confirmation is required "Yes," and other reservation information shown in Table 1.

[0073] The seller photographs the license plate at the entrance (7204) with a digital camera, reads the identification ID with an image recognition means, and sends a payment reservation including the identification ID, entrance name, etc. to the bank. If the reservation information is received, the seller is allowed to exit, settles the payment based on the entry record, and sends a payment request to the bank. The entry and exit records will also contain the vehicle type and photographs according to the fee category as evidence of use. If the payment reservation or payment request is rejected, or if electronic payment is not reserved, the vehicle user (owner) will be identified by the identification ID and billed by sending an invoice, etc. Administrative fees may also be added to the bill. If there is an entrance gate, the identification ID is a virtual account settlement, or if reservation information is received, entry is permitted. If there is an exit gate, the identification ID is a virtual account settlement, or reservation information is received, or approval is received, then exit is permitted. Preferably, the vehicle is guided by electronic signals and voice messages on mobile phones according to the judgment results. Non-stop lanes for electronic payment may be installed alongside conventional toll gates. Furthermore, cameras may be installed at the first-arrival positions in the entrance and exit lanes, or location information from mobile phones may be acquired to determine the payment method of vehicles approaching the entrance and exit, provisionally settle the fare, or quickly determine the entrance and exit gates. Preferably, a road usage schedule (period) is specified, and the reservation of the virtual account is cancelled once the schedule has passed. In the case of a system in which a fee is charged each time a boundary line of a toll area such as in a city center (hereinafter referred to as "passing fee") is crossed, the same processing as that at the exit can be carried out at the boundary line.

[0074] A charging system based on distance traveled (hereinafter referred to as distance charging) can be realized. The user gives the system location acquisition treatment, and when entering a toll area, the system will keep track of the mobile phone's location almost continuously. For example, mobile phone location information (location cell, GPS information, etc.) can be obtained from a server and tracked. The distance traveled by the mobile phone is calculated as the distance traveled by a car, and the charge amount can be calculated. If the mobile phone battery runs out or the location cannot be determined, a fixed charge can be applied. The camera for reading vehicle information may be replaced with other vehicle information acquisition means necessary for billing, such as a license plate equipped with a communication function. [Function] ETC systems must instantly recognize high-speed vehicles as they pass through gates or boundary lines, and instantly process two-way communication and electronic currency transfers. This requires high speed, high accuracy, and high reliability. Security features, such as maintaining the confidentiality of credit card information and preventing data tampering, require instantaneous, high-volume processing. This is the reason for the high cost of ETC systems. This invention only requires photographing the vehicle and reading the license plate, and the signal processing technology required for this is mature. Furthermore, since it does not transmit confidential information, it does not require instantaneous, high-volume processing when passing through gates, and it does not require an on-board unit or ETC card, thereby reducing costs for both roads and vehicles. It also eliminates issues such as highway card counterfeiting. It also facilitates the separation of vehicle owners and toll payers. It facilitates non-stop traffic at toll booths, etc. Because it does not use cards, there are no concerns about card counterfeiting or the hassle of running out of electronic currency or increasing the balance.

[0075] FIG. 69 is a block diagram illustrating yet another method and system for payment. In an electronic payment system and method for processing commercial payments between a bank, a buyer, and a seller, a buyer uses an identification ID (Fig. 69, 1) to purchase goods (Fig. 69, 6) from a seller. The seller generates a payment request (Fig. 69, 2) requesting payment of the amount used and sends the payment request to a bank (Fig. 69, 6903) to approve the payment request. The bank presents a confirmation request (Fig. 69, 3) to the buyer to confirm the payment request. The buyer confirms the payment request by sending authentication information such as a PIN number (Fig. 69, 4) to the bank through a buyer communication module. The bank sends approval (Fig. 69, 5) to the seller only after it has been confirmed by the buyer. A communication confirmation procedure is performed for a communication request to confirm a payment request. The registration information sent by the authentication program activated by the communication confirmation procedure includes the authentication information. This has the effect of avoiding the need to enter the authentication information in public places. Preferably, the electronic payment is invalidated after the payment request is confirmed. This ensures that identity authentication is always performed before each payment, eliminating the risk of loss even if the mobile phone is lost. Example 7

[0076] Mobile phone key [Field] Using a mobile phone as a key for your home door, safe, car, etc. [Means] When unlocking, the electric lock control system confirms unlocking with the user through the communication module. The lock is unlocked only after confirmation by the user. The confirmation is performed by sending authentication information such as a PIN number to the electric lock control system. Figure 32 illustrates the configuration of an electric lock control system. In Example 1, the case where unlocking is performed by a mobile phone call was explained. In this example, the electric lock of the controlled device makes the call. When the user performs an unlocking operation using an unlocking operation means such as an unlocking operation button, the system makes a call to the user. Figures 70 and 71 show examples in which a communication confirmation treatment is given to an unlocking confirmation communication request. The system unlocks only after receiving the specified authentication information. The unlocking operation may be further verified against a password entered using the numeric keypad. To unlock the door, simply press the call button that doubles as a door phone, or you can have a call between the door phone and your mobile phone. Remote unlocking is possible. [Effect] A lock with strong security can be realized by using personal authentication results such as biometric authentication without keys or keyholes. Example 8

[0077] [Field] This embodiment relates to the collection of traffic information and route guidance for mobile objects. This specification shows the use of a mobile phone as the mobile communication terminal device. However, the mobile communication terminal device is not limited to a mobile phone, and electronic information devices with communication functions (such as notebook PCs, PDAs, electronic organizers, car navigation systems, etc.) can also be used. [Background] Technologies for collecting traffic information from vehicles are known from Patent Documents 14 and 15. A technology for predicting road usage conditions is known from Patent Document 17. The technology shown in Patent Document 16 is intended to prevent traffic congestion from occurring. [Problem] To provide cooperative and efficient collection of traffic information using mobile communication devices, prevent and avoid congestion, and provide dynamic route guidance for moving vehicles. [Means] A database of information such as traffic information, maps, and facility data, as well as an optimal route calculation function that includes all vehicle elements, is consolidated in a traffic center. Via communication lines, the traffic center collects travel plans from users (pedestrians and cars), including departure times and departure and arrival points, and provides users with recommended travel plans and recommended planned routes. A user's mobile communication device acquires current location information, a traffic center communicates with the mobile body to grasp the moving situation, and when a traffic jam ahead on the moving route occurs or is predicted, a number of cars sufficient to eliminate the traffic jam are selected and transferred to an avoidance route, and only necessary information is retrieved and transferred to the mobile device when necessary, such as when a map ahead is newer than a map possessed by the mobile body or when the mobile body does not possess a map ahead. Each time it communicates with a mobile device, it collects information on the location, speed, direction of travel, etc., and updates the traffic situation database. The traffic center provides communication methods with the mobile device, including constant connection, interval connection, and connection only when an event is detected. The mobile device measures the position, speed, traveling direction, etc., and provides the traffic center with necessary control treatment, such as acquisition of measurement data, transfer of map and voice information, and warning, etc., so that the user can exchange the necessary information with the traffic center without taking his / her hands off the steering wheel while driving.

[0078] When a mobile device issues a communication request to a traffic center, the mobile device detects information including the location of the mobile device, transfers requests for route search, traffic congestion information search, etc. to the traffic center, receives a route and a command from the traffic center, operates according to the command, guides the user to the received route, and when the user departs from the route midway, requests the traffic center to search for a route again. The system detects events such as intersections and changes in vehicle speed at locations where congestion occurs, such as during fog, poor visibility, or on uphill roads, and the traffic center continuously tracks the vehicle's location, notifies the driver of the location of surrounding vehicles, recommends speed adjustments, maintains a safe distance between vehicles, and assists in preventing congestion and safe driving. A danger prevention service is provided through communication between approaching vehicles mediated by the traffic center. Nearby vehicles are treated as a group while moving, and the traffic center keeps track of the location of each member of the group. Through the traffic center's mediation, each member exchanges connection numbers, allowing direct connection between vehicles, vehicle-to-vehicle information communication, and the locations of other vehicles in the group are displayed on the mobile device screen. If danger such as approaching vehicles in front or behind, sudden braking, airbag deployment, or an accident is detected, an emergency call is made to warn the relevant vehicles. The locations of all vehicles in the approaching group are tracked in real time, the distance between vehicles is maintained, and data is provided to the autonomous driving system installed in each vehicle. When the traffic center is short of information, it uses a mobile phone with a position detection device mounted on a moving body such as a car as a mobile monitor to collect information, analyzes the received information, creates an information collection command and sends it back to the monitor. One way to activate a monitor is to automatically send information to the traffic center when a set condition is met, such as a travel speed of 20 km / h or more. One response or command from the traffic center upon receiving the information is to return the transmission interval t. t is positively correlated with the monitor density p. In other words, t is increased as p increases. As density increases, the possibility of duplicate information transmission increases, so increasing the transmission interval can reduce unnecessary information transmission. For example, t is calculated using the formula t = a*p+b, where a and b are constants. As a specific example, if p is within a 10 km radius, there are 10 monitors within a 10-minute difference in transmission time, and a = 5 and b = 10, then t is 60 minutes. In other words, it instructs the monitor to send information again after 60 minutes.

[0079] The specific definition (calculation) method of p and the values ​​of a and b may differ depending on the importance of the measurement location. For example, if it is necessary to increase the measurement density in urban areas compared to suburban areas, the values ​​of a and b or the count radius of p can be made smaller than in suburban areas. The center selects and uses a predetermined value depending on the current location of the monitor. Additionally, the command may include the following information transmission conditions: Do not transmit during a specified time period. Do not transmit within a specified movement speed range. Do not transmit within a specified geographic range. Transmit only when the speed or movement direction changes. The operation of mobile monitoring involves rewarding information providers or releasing mobile phones with built-in automatic monitoring functions. A preferred reward method is to convert the amount of information provided into reward points and store them in a memory device. Users can exchange the points they have accumulated for services such as route guidance. Traffic signals can be controlled based on real-time traffic flow and emergency vehicles. For example, when a vehicle's predicted location approaches an intersection, the traffic center will send a signal, grasp the vehicle's location in real time, and avoid unnecessary red lights. If emergency vehicles transmit their own location information in real time, optimal control of traffic signals ahead is possible. The traffic center can check the locations of other vehicles on the route ahead of the emergency vehicle and instruct them to move out of the way. The traffic center can monitor speeding and vehicle behavior near intersections, and if it detects a risk of collision, it will immediately warn the drivers and pedestrians involved. The traffic center can also provide route guidance services to pedestrians with mobile devices. It can provide guidance on routes to avoid the last train or train cancellations based on travel plans, commuter routes, current location, time, etc.

[0080] [Action, effect] This has the effect of enabling the collection of information needed to realize traffic guidance while also providing it.The following feedback can be expected: Increased congestion → Increased demand for services → Increased amount of information that the traffic center can collect → Guidance based on the collected information → Decrease in traffic congestion. By dynamically recommending routes, the traffic center can realize an optimal traffic system by changing previously unordered traffic flow into an orderly one. It can provide accurate, real-time information tailored to each driver and pedestrian. It can predict congestion before it occurs and provide optimal avoidance routes based on each vehicle's route information, allowing the transportation capacity of the traffic network to be fully utilized without concentrating it on specific roads. Compared to installing sensors fixedly on roads, there is no limit to measurement points, and traffic condition information can be collected evenly across the road, probabilistically uniformly, or according to importance. This system can provide dynamic route guidance for vehicles and guidance on avoiding congestion without requiring users to operate mobile phones while traveling or driving, which is prohibited by traffic laws. It can also provide guidance to pedestrians on detours in the event of an accident that causes train service to be suspended. This will make it easier to support safe driving, optimize traffic management, improve the efficiency of road management, support pedestrians, and assist emergency vehicle operations, as well as alleviate and prevent congestion before it occurs. [Industrial Applicability]

[0081] As described above, the present invention is suitable for a communication method using electronic devices on a communication network. [Brief explanation of the drawings]

[0082] [Figure 1] 1 is a diagram showing an example of a basic schematic configuration of the present invention; [Figure 2A] This is a record layout diagram showing the contents of a TDB. [Figure 2B] This is a record layout diagram showing the contents of the R1DB. [Figure 2C] This is a record layout diagram showing the contents of the GDB. [Figure 2D] This is a layout diagram of records showing the contents of an R2DB. [Figure 2E] This is a record layout diagram showing the contents of the R3DB. [Figure 2F] This is a record layout diagram showing the contents of the R4DB. [Figure 2G] This is a record layout diagram showing the contents of the R5DB. [Figure 2H] FIG. 1 is a layout diagram of records showing the contents of a TRDB. [Figure 3A] FIG. 10 is a layout diagram of records showing the contents of a PDDB. [Figure 3B] FIG. 1 is a layout diagram of records showing the contents of a VDB. [Figure 3C] FIG. 10 is a layout diagram of records showing the contents of a VRDB. [Figure 4] 1 is a flowchart of an embodiment of the present invention. [Figure 5] 10 is a flowchart of another embodiment. [Figure 6] 10 is a flowchart of another embodiment. [Figure 7] FIG. 10 is a diagram illustrating a configuration of another embodiment. [Figure 8] 10 is a flowchart of another embodiment. [Figure 9] FIG. 10 is a diagram illustrating a configuration example of another embodiment. [Figure 10] 10 is a flowchart of another embodiment. [Figure 11] 10 is a partial flowchart of an early decision process according to another embodiment. [Figure 12] 10 is a flowchart of another embodiment. [Figure 13] 10 is a flowchart of another embodiment. [Figure 14] 10 is a flowchart of another embodiment. [Figure 15] FIG. 10 is a diagram illustrating a configuration example of another embodiment. [Figure 16] 10 is a flowchart of another embodiment. [Figure 17] 10 is a flowchart of another embodiment. [Figure 18] FIG. 10 is a diagram illustrating a configuration of another embodiment. [Figure 19] FIG. 10 is a diagram illustrating a configuration of another embodiment. [Figure 20] 10 is a partial flowchart of a call processing; [Figure 21] FIG. 1 is a diagram illustrating a system configuration for anonymous communication. [Figure 22] 10 is a partial flowchart of the first party's processing. [Figure 23] 10 is a partial flowchart of the second party's processing. [Figure 24] 10 is a flowchart of a treatment exchange processing portion. [Figure 25] 10 is a flowchart of another embodiment. [Figure 26] FIG. 1 is a diagram illustrating a configuration of an embodiment. [Figure 27] FIG. 1 is a conceptual diagram showing the configuration of a location information system. [Figure 28] 10 is a flowchart of a vehicle driving guidance function. [Figure 29] FIG. 10 is a conceptual diagram of another embodiment of the present invention relating to position information, etc. [Figure 30] FIG. 2 is a diagram illustrating a configuration of a mail sending client. [Figure 31] 10 is a flowchart of an email transmission process. [Figure 32] FIG. 2 is a block diagram showing the configuration of a multifunction telephone; [Figure 33A-D] FIG. 10 shows the contents of the instruction file of the telephone. [Figure 34] 4 is a flowchart of the telephone. [Figure 35]FIG. 10 is a diagram showing an example in which the telephone number of a related person is automatically given a treatment that allows normal calls through automatic screening. [Figure 36] FIG. 1 is a diagram showing the telephone configuration of an answering machine embodiment. [Figure 37A-C] FIG. 10 shows the contents of the instruction file of the telephone. [Figure 38] FIG. 2 is a block diagram showing the configuration of an embodiment of a mail receiving client; [Figure 39A-D] FIG. 10 is a diagram showing the contents of an instruction file in the embodiment. [Figure 40] 10 is a schematic flowchart of a reception process. [Figure 41] FIG. 10 is a diagram showing a question input screen. [Figure 42] FIG. 10 is a diagram showing a first encounter selection screen. [Figure 43] 1 is a block diagram showing the configuration of an Internet videophone and monitoring system. [Figure 44] FIG. 2 is a block diagram showing the internal configuration of the embodiment. [Figure 45] 10 is a flowchart showing the operation of a main program. [Figure 46] FIG. 10 is a diagram showing a main menu screen. [Figure 47] FIG. 10 is a diagram showing a contact book screen. [Figure 48] FIG. 10 is a diagram showing a member addition screen. [Figure 49] FIG. 10 is a diagram showing a treatment application process. [Figure 50] FIG. 10 is a diagram showing a personal setting screen. [Figure 51] 10 is a flowchart showing a login processing operation. [Figure 52] FIG. 10 is a diagram showing a friend list editing screen. [Figure 53] FIG. 10 is a diagram showing a treatment application qualification designation screen. [Figure 54] 10 is a flowchart showing the operation of a videophone communication program. [Figure 55] FIG. 10 is a diagram showing a connection waiting screen. [Figure 56]FIG. 10 is a diagram showing a videophone communication in progress screen. [Figure 57] FIG. 1 is a diagram showing an outline of the process for establishing a working relationship. [Figure 58] FIG. 1 is a block diagram showing the configuration of an embodiment of a mail server system. [Figure 59] FIG. 10 is a diagram showing the compensation information database. [Figure 60] FIG. 1 is a block diagram showing the Guidance Information Data Database (GDB). [Figure 61] FIG. 10 is a diagram showing a second rule set. [Figure 62] FIG. 10 is a diagram showing a first rule set. [Figure 63] FIG. 10 is a diagram showing a third rule set for attack prevention. [Figure 64] FIG. 10 is a diagram showing usage constants. [Figure 65] FIG. 10 is a diagram showing a third rule set for cancellation. [Figure 66] FIG. 10 is a diagram showing a fifth rule set. [Figure 67] A diagram showing the user interface of the input component. [Figure 68] FIG. 10 is a diagram showing data to be passed to an input component. [Figure 69] 1 is a block diagram illustrating a method and system for electronic payment. [Figure 70] FIG. 1 illustrates a TDB for an electronic payment embodiment. [Figure 71] FIG. 10 illustrates an R1DB in an electronic payment embodiment. [Figure 72] FIG. 10 is a block diagram of another embodiment of a ticket. [Figure 73] FIG. 2 is a diagram illustrating an account and a virtual account. [Figure 74] 1 is a flow diagram of a transaction process in a virtual account schematic diagram. [Figure 75] 10 is a flow chart of an approval process. [Figure 76] 1 is a flow chart of offline approval. [Explanation of symbols]

[0083] 11, 111, 211...processor 12, 112, 212...input / output control means 13, 14, 114, 214...Storage device 15, 115, 215...Communication forwarding device 16...Keyboard and display unit. 17...Microphone, speaker 18...Camera, keyboard and display. 19...Vibrator 20...Fingerprint sensor

Claims

1. 1. A computer-implemented method comprising: a setting step of setting instruction information when the user is authenticated based on the authentication information; a processing step of processing a plurality of service requests from the user based on the instruction information; wherein the service is a process provided to the user, the service request is a request from the user to receive the service; the authentication information is information obtained from an electronic device; the electronic device is a device that provides the authentication information to the user; method.

2. The authentication information includes a one-time password. The method of claim 1.

3. the authentication information includes information that is different from information previously used; 3. The method according to any one of claims 1 to 2.

4. the electronic device is selected from the group consisting of a computer, a portable electronic device, and a mobile phone; 4. The method according to any one of claims 1 to 3.

5. The service includes a communication that conveys communication information; 5. The method according to any one of claims 1 to 4.

6. The communication includes at least one of a telephone call, an email, an internet communication, a wireless communication, and a data communication. The method of claim 5.

7. the communication comprises a paper document; 7. The method according to any one of claims 5 to 6.

8. the instruction information includes a secret code; 8. The method according to any one of claims 1 to 7.

9. the instruction information includes a monetary amount; 9. The method according to any one of claims 1 to 8.

10. the instruction information includes at least one of status information and time information; The status information is information indicating whether the service can be provided.

10. The method according to any one of claims 1 to 9.

11. the instructional information includes information associated with an account; the account is selected from the group consisting of a debit card account, a credit card account, and a bank account; 11. The method according to any one of claims 1 to 10.

12. the instruction information includes information associated with electronic money; the electronic money is electronic data, the electronic data is data on the balance of the monetary value available for payment, using the instructional information includes updating the balance amount.

12. The method according to any one of claims 1 to 11.

13. the instruction information includes at least one of identification information for identifying a user of the service, personal information, and communication destination information; The communication destination information is information that can identify the communication destination.

13. The method according to any one of claims 1 to 12.

14. The instruction information includes at least one of an IC card number, an email address, a telephone number, a computer communication address, a license plate number, account information, a correspondence address, a name, and an address; 14. The method according to any one of claims 1 to 13.

15. the communication information includes transaction information regarding the transaction; 15. The method according to any one of claims 5 to 14.

16. The transaction includes a withdrawal transaction to withdraw cash.

16. The method of claim 15.

17. The transaction includes at least one of a debit card transaction, a credit card transaction, a money transfer transaction, a payment transaction, and an account-to-account transfer transaction.

16. The method of claim 15.

18. The transaction is between a payer and a payee, The transaction information for the transaction is entered by the payee, the transaction information includes at least one of an amount and information identifying the payee; 16. The method of claim 15.

19. The transaction is a transaction that increases the amount in electronic data indicating the balance of monetary value available for settlement.

16. The method of claim 15.

20. The transaction is an account-related transaction, updating the account balance of the account.

20. The method of any one of claims 15 to 19.

21. the request is a permission request for permission to pass; 21. The method of any one of claims 1 to 20.

22. providing the service.

22. The method of any one of claims 1 to 21.

23. and processing the request based on the authentication information.

23. The method of any one of claims 1 to 22.

24. A method executed in a system comprising a client and a server, a client providing a request for a service; a step of the client receiving response information to the request from the server; a client providing authentication information according to any one of claims 1 to 23 if requested by said response information; a step of providing, to a client, if requested by said answer information, indication information according to any one of claims 1 to 23; Including, The server is a device comprising means for executing the steps of the method according to any one of claims 1 to 23. method.

25. Apparatus comprising means for carrying out the method of any one of claims 1 to 24.

26. A program for causing a computer to execute the method according to any one of claims 1 to 24.

27. A computer-readable storage medium storing the program according to claim 26.

Images