JP2020129186A - Information processing apparatus, information processing method, and program - Google Patents

Abstract

To provide an information processing apparatus which can manage details of payment claimed on the basis of a contract, in association with contents of the contract.SOLUTION: An information processing apparatus 1 comprises: a first acquisition unit which acquires contract information about a contract between a user and a business operator, in which periodic payment from the user to the business operator is claimed; a second acquisition unit which acquires detailed information indicative of details of the payment from the user to the business operator; a storage unit in which the detailed information and the contract information are stored; and an output unit which outputs the contract information corresponding to factors of the payment in the detailed information to a terminal device of the user along with the detailed information.SELECTED DRAWING: Figure 1

Description

The present invention relates to an information processing device, an information processing method, and a program.

Various services are available for introducing online usage details of financial accounts and credit cards. For example, in Patent Document 1, there is an information integration system that distributes card usage information indicating the usage history of a credit card to a member terminal of a credit card member, and information in which the credit card member can add a comment to the card usage information. An integrated system is disclosed. According to Patent Document 1, by associating a comment such as a diary or a household account book with the card usage information, the credit card member can immediately understand what purpose the credit card is used for.

JP, 2005-63216, A

However, the invention according to Patent Document 1 only leaves a comment in association with the usage details of the credit card, and has not yet clearly recorded the payment factor related to the usage details.

In one aspect, it is an object of the present invention to provide an information processing device or the like that can manage the details of expenses generated based on a contract in association with the contract details.

In one aspect, the information processing apparatus acquires contract information regarding a contract between a user and a business operator, and contract information of the contract in which the user regularly pays the business operator. The first acquisition unit, a second acquisition unit that acquires detailed information indicating the details of the expenditure from the user to the business entity, a storage unit that stores the detailed information and contract information, and the detailed information together with the detailed information. An output unit for outputting the contract information corresponding to a factor of spending information to the terminal device of the user.

In one aspect, it is possible to manage the details of the expenses generated based on the contract in association with the contract content.

It is explanatory drawing which shows the structural example of a detailed inquiry system. It is a block diagram which shows the structural example of a server. It is a block diagram which shows the structural example of a terminal. It is explanatory drawing which shows an example of a record layout of member DB, member store DB, specification DB, and contract DB. It is explanatory drawing which shows an example of a detailed screen. It is explanatory drawing which shows an example of the detailed screen at the time of contract information registration. It is explanatory drawing which shows an example of the detailed screen at the time of browsing contract information. It is a flow chart which shows an example of the processing procedure which a statement inquiry system performs. 9 is a flowchart showing an example of a processing procedure executed by the server according to the second embodiment. FIG. 16 is an explanatory diagram showing an example of a detail screen according to the third embodiment. 9 is a flowchart showing an example of a processing procedure executed by the specification inquiry system according to the third embodiment. It is explanatory drawing which illustrates an example of the detailed screen which concerns on Embodiment 4. 16 is a flowchart showing an example of a processing procedure executed by the specification inquiry system according to the fourth embodiment.

Hereinafter, the present invention will be described in detail with reference to the drawings showing an embodiment thereof.
(Embodiment 1)
FIG. 1 is an explanatory diagram showing a configuration example of a detail inquiry system. In the present embodiment, a user who is a member of a credit card can inquire the usage details of the credit card, and in addition to the usage details, a membership corresponding to a payment factor (expense factor) of the usage details. A detailed inquiry system capable of inquiring about contract contents with a store will be described. The statement inquiry system includes an information processing device 1, terminals 2, 2, 2,... And a member store device 3. Each device is communicatively connected to a network N such as the Internet.

The information processing apparatus 1 is an information processing apparatus capable of various information processing and information transmission/reception, and is, for example, a server device, a personal computer, or the like. In the present embodiment, the information processing device 1 is assumed to be a server device, and is read as server 1 for simplicity. The server 1 is a server device of a credit card company that provides a settlement service using a credit card to the user. In the present embodiment, the server 1 provides a user with an inquiry service for the details of credit card usage.

In particular, in the present embodiment, the server 1 uses the details of the usage, such as insurance fee, communication fee, and electricity fee, at which regular payment (expenditure) occurs, and the contract content between the user and the member store, which is the payment factor. When the user inquires about the usage details of the credit card, the contract contents can be browsed as well (see FIG. 7). As a result, it is possible to easily understand what contract the usage statement that is regularly billed is based on, and the user does not have to make a memo for each usage statement that occurs for the same reason. Inquiry service can be provided.

In addition, although a credit card statement inquiry system will be described as an example in the present embodiment, the present embodiment is not limited to this, and the present invention can be applied to a financial account inquiry system in a financial institution such as a bank. You may apply. That is, the server 1 only needs to be able to manage detailed information on payment (expenditure) from a user to a predetermined business operator in association with contract information that is a payment factor, and payment is not limited to a credit card.

The terminal 2 is a terminal device of a user who is a member of a credit card, and is, for example, a smartphone, a personal computer, a tablet terminal, or the like. For example, the application program distributed by the server 1 is installed in the terminal 2 in advance, and the terminal 2 performs the processing described below by executing the application program.

The member store device 3 is an information processing device of a credit card member store (business), and is, for example, a personal computer, a server device, or the like. The member store apparatus 3 accesses the server 1 to check the credit information when receiving a credit card use application from the user, and performs the payment based on the credit card when approved by the server 1 (credit card company). ..

FIG. 2 is a block diagram showing a configuration example of the server 1. The server 1 includes a control unit 11, a main storage unit 12, a communication unit 13, and an auxiliary storage unit 14.
The control unit 11 includes an arithmetic processing unit such as one or more CPUs (Central Processing Units), MPUs (Micro-Processing Units), and GPUs (Graphics Processing Units), and stores the program P1 stored in the auxiliary storage unit 14. By reading and executing, various information processing, control processing, etc. are performed. The main storage unit 12 is a temporary storage area such as an SRAM (Static Random Access Memory), a DRAM (Dynamic Random Access Memory), and a flash memory, and temporarily stores data necessary for the control unit 11 to execute arithmetic processing. Remember. The communication unit 13 is a communication module for performing processing relating to communication, and transmits/receives information to/from the outside.

The auxiliary storage unit 14 is a non-volatile storage area such as a large-capacity memory or a hard disk, and stores the program P1 and other data necessary for the control unit 11 to execute processing. Further, the auxiliary storage unit 14 stores a member DB 141, a member store DB 142, a specification DB 143, and a contract DB 144. The member DB 141 is a database that stores information on each user who is a member of a credit card. The member store DB 142 is a database that stores information about each member store of the credit card. The statement DB 143 is a database that stores the details of credit card usage by each user. The contract DB 144 is a database that stores contract information regarding contracts between users and member stores.

The auxiliary storage unit 14 may be an external storage device connected to the server 1. The server 1 may be a multi-computer including a plurality of computers, or may be a virtual machine virtually constructed by software.

In addition, in the present embodiment, server 1 is not limited to the above configuration, and may include, for example, an input unit that receives an operation input, a display unit that displays an image, and the like. Further, the server 1 includes a reading unit that reads a portable storage medium m1 such as a CD (Compact Disk)-ROM and a DVD (Digital Versatile Disc)-ROM, and reads the program P1 from the portable storage medium m1 and executes the program P1. You can Alternatively, the server 1 may read the program P1 from the semiconductor memory m2.

FIG. 3 is a block diagram showing a configuration example of the terminal 2. The control unit 21, the main storage unit 22, the communication unit 23, the display unit 24, the input unit 25, the imaging unit 26, and the auxiliary storage unit 27 are provided.
The control unit 21 has one or more CPUs, arithmetic processing devices such as MPUs, and reads and executes the program P2 stored in the auxiliary storage unit 27 to perform various information processing and control processes related to the terminal 2. And so on. The main storage unit 22 is a temporary storage area such as a RAM, and temporarily stores data necessary for the control unit 21 to execute arithmetic processing. The communication unit 23 includes an antenna for performing communication, a processing circuit, and the like, and transmits/receives information to/from the outside. The display unit 24 is a display device such as a liquid crystal display or an organic EL (Electro Luminescence) display, and displays an image. The input unit 25 is an operation interface such as a touch panel and mechanical keys, and inputs operation contents to the control unit 21. The image pickup unit 26 is a camera including a C-MOS (Complementary MOS) sensor and the like, and picks up an image. The auxiliary storage unit 27 is a non-volatile storage area such as a ROM (Read Only Memory), and stores the program P2 and other data necessary for the control unit 21 to execute processing.

The terminal 2 may download the program P2 from another computer via the network N and store it in the auxiliary storage unit 14. Further, the terminal 2 may include a reading unit that reads a portable storage medium m3 such as a CD-ROM, and may read the program P2 from the portable storage medium m3 and execute the program P2. Alternatively, the server 1 may read the program P2 from the semiconductor memory m4.

FIG. 4 is an explanatory diagram showing an example of the record layout of the member DB 141, the member store DB 142, the specification DB 143, and the contract DB 144.
The member DB 141 includes a member ID column, a name column, a card number column, and a member information column. The member ID column stores a member ID for identifying each user who is a member of the credit card. The name column, the card number column, and the member information column each store the name of each user, the card number of the credit card, and the member information in association with the member ID. Member information may include, for example, a user's address, contact information, financial account information, and the like.

The member store DB 142 includes a member store ID column, a name column, and a member store information column. The member store ID column stores member store IDs for identifying each member store of the credit card. The name column and the member store information column respectively store the member store name and member store information in association with the member store ID. The member store information may include, for example, the member store address, contact information, and financial account information.

The detail DB 143 includes a detail ID column, a member store ID column, a member ID column, a usage date column, a detailed column, an amount column, and a contract ID column. The item ID column stores item IDs for identifying individual usage items of the credit card. The member store ID column, the member ID column, the usage date column, the detailed column, and the amount column are respectively associated with the item ID, and the ID of the member store using the credit card, the user's member ID, the date of use, and the contents of the item of use are associated with each other. (Details), purchase price, and ID of contract information associated with the usage details are stored.

The contract DB 144 includes a contract ID column, a member ID column, a member store ID column, a contract name column, a detailed column, and a memo column. The contract ID column stores a contract ID for identifying individual contract information between the user and the member store. The member ID column, the member store ID column, the contract name column, the detailed column, and the memo column are associated with the contract ID, respectively, and the member ID of the user who is one of the parties to the contract and the ID of the member store that is the other party of the contract. , Contract name, contract details, and memo entered by the user regarding the contract. Details of the contract include, for example, information about the contract period, the amount of payment (expenditure) that occurs regularly, the contract cancellation method, and other contract details.

FIG. 5 is an explanatory diagram showing an example of the detail screen. FIG. 5 illustrates an example of a detail screen that displays a list of credit card usage details. The outline of the present embodiment will be described below.
As described above, the server 1 provides a credit card settlement service. For example, the server 1 accepts a payment request to the user from the member store apparatus 3 at the time of inquiry about the credit information of the user's credit card, or at a regular timing. The server 1 stores the payment request in the specification DB 143 as the credit card specification information, and performs the payment process on a predetermined charging date.

In the present embodiment, the server 1 provides a service for inquiring the usage details of a credit card that is settled as described above. For example, the server 1 receives a predetermined login process, acquires a member ID and the like from the terminal 2, reads detailed information indicating usage details associated with the acquired member ID from the detailed DB 143, and transmits the detailed information to the terminal 2. The terminal 2 displays the detail screen illustrated in FIG. 5 based on the detail information acquired from the server 1.

For example, the terminal 2 accepts the monthly designation by the operation input to the monthly designation field 51, and displays the usage details of the credit card in the designated monthly on the statement screen. For example, as shown in FIG. 5, the terminal 2 displays the total usage amount of the credit card and also a detailed list 52 which is a list of detailed usage. In the statement list 52, the usage date of the credit card, the usage destination (member store, details, etc.), the usage amount, etc. are displayed for each usage statement.

When displaying the above detailed screen, the terminal 2 can obtain not only the detailed information but also the contract information associated with the detailed information from the server 1 and display it on the detailed screen. The contract information is information about the contract between the user and the member store (business operator), which is a factor of payment of the usage statement, and is regularly paid (expenditure) such as insurance fee, communication fee, and electricity fee. Is the information about the contract that occurs. For example, when transmitting the detailed information to the terminal 2, the server 1 reads out the contract information associated with the detailed information to be transmitted from the contract DB 144, and transmits it together with the detailed information to the terminal 2.

For example, the server 1 reads the contract information of each contract that the user has exchanged with each member store from the contract DB 144 based on the user's member ID acquired from the terminal 2 when logging in. Then, the server 1 associates the read contract information with the detailed information and transmits the contract information to the terminal 2.

For example, the server 1 compares each item of detail information and each item of contract information, and estimates which usage item corresponds to which contract. For example, the server 1 uses the details (details) of the usage details included in the specification information, the member store ID of the member store that is the biller, the contract name included in the contract information, and the member store ID of the member store that is the contract partner. Etc. and the contract corresponding to the payment factor of each usage statement of the credit card is estimated. The server 1 transmits the corresponding contract information to the terminal 2 in a form associated with each usage statement.

Note that, for example, when the payment request is received from the member store apparatus 3, and when the contract ID of the contract which is the reason for the payment (payment factor) is also notified, it is not necessary to perform the above estimation process. It suffices that the server 1 manages the detailed information and the contract information in association with each other and can transmit them to the terminal 2.

When the detailed information in which the contract information is associated is received, for example, the terminal 2 is another item in which the contract information is not associated so that the user can easily identify that the contract information is associated. The corresponding detailed information is displayed in a mode different from the information. For example, the terminal 2 changes the display mode by color coding or the like. Note that, in FIG. 5, for convenience, the detailed information associated with the contract information is illustrated in italics with underline. As will be described later, when the specification input specifying the detailed information associated with the contract information is received, the terminal 2 pops up the contract information corresponding to the specified detailed information (see FIG. 7). As a result, the user can easily understand for what reason the usage statement was charged.

FIG. 6 is an explanatory diagram showing an example of a detailed screen when contract information is registered. Before explaining the popup display of the contract information, the process of setting and registering the contract information corresponding to the detailed information will be described.

The method of registering the contract information is not particularly limited, but in the present embodiment, the terminal 2 accepts the setting registration of the contract information and associates it with the detailed information. Specifically, when the terminal 2 displays the above-described detailed screen and the contract information is unregistered (unacquired) from the server 1, the popup image 61 prompts the user to input the contract information. Is displayed and the contract information is input from the user.

For example, the terminal 2 uses the usage statement to be associated with the contract information in the usage statement to be billed to the user according to the content (details, etc.) of the usage statement included in the statement information received from the server 1 and the member store that is the billing source. It is determined whether or not the details. Further, for example, the terminal 2 should associate the contract information with each other when the same member requests the same amount of money continuously for a plurality of months or when the same member request the same amount of money for the same month over a plurality of years. Judge that it is a usage statement. When it is determined that the contract information is the usage statement to be associated, the terminal 2 further determines whether the contract information is already associated with the usage statement, and whether the contract information corresponding to the specification information is received from the server 1. Determine whether. When it is determined that the contract information is not received, that is, when the contract information is not associated with the detailed information, the terminal 2 displays the pop-up image 61.

The terminal 2 accepts the input (setting registration) of the corresponding contract information for the detailed information for which the input of the contract information is prompted by the pop-up image 61. The contract information may be manually input by the user. For example, the terminal 2 receives the contract information by reading the contract distributed from the member store to the user by OCR (Optical Character Recognition). That is, the terminal 2 captures a contract document by the image capturing unit 26 according to an operation input by the user, and reads necessary contract information from the captured image by character recognition. For example, the terminal 2 has a contract name (a plan name of a contract plan provided by a member store, etc.), a name of a member store that is a contract partner, a contract period (a contract renewal period, etc.), and a billing amount that is regularly generated. Read the information.

The terminal 2 transmits the item ID of the corresponding item information to the server 1 together with the contract information read above. The server 1 stores the contract information received from the terminal 2 in association with the detailed information. For example, the server 1 stores the contract information in the contract DB 144 in association with the member ID of the user and the member store ID of the member store, and associates the contract ID of the newly stored contract information with the item ID received from the terminal 2. It is attached and stored in the detail DB 143. Through the above processing, the server 1 associates the detailed information with the contract information.

In the above description, the terminal 2 performs the character recognition of the contract, but the terminal 2 only transmits the image of the contract to the server 1, and the server 1 performs the character recognition to extract the contract information. It may be done.

Further, although the server 1 acquires the contract information from the terminal 2 in the above, the contract information may be acquired from the member store apparatus 3, for example, as in a second embodiment described later. In this way, the acquisition route of the contract information is not particularly limited.

FIG. 7 is an explanatory diagram showing an example of a detailed screen when browsing contract information. The terminal 2 displays the contract information associated with the detailed information on the detailed screen as described above. FIG. 7 shows an example of a detailed screen when displaying contract information.

When the terminal 2 receives a designation input to any usage statement in the statement list 52 of the statement screen illustrated in FIG. 5, the contract information corresponding to the specified usage statement is displayed. Specifically, the terminal 2 superimposes and displays the pop-up image 71 showing the contract information of the specified usage statement on the specification screen.

For example, in the pop-up image 71, the terminal 2 displays the contract name (plan name of the contract plan), the name of the member store that is the contract partner, other detailed contract contents, the next renewal time corresponding to the contract period, and periodically. Display the amount of charges that will occur. Further, the terminal 2 displays a hyperlink 711 for performing the contract cancellation procedure and a memo field 712 for the user to input text.

The hyperlink 711 is, for example, a link for transitioning to a Web page of a member store, and is a link for a Web page for performing a contract cancellation procedure. When the operation input to the hyperlink 711 is accepted, the terminal 2 transits to the Web page of the member store and enables the cancellation procedure. It is possible to enhance the convenience of the user by enabling the transition to the Web page for the cancellation procedure on the statement screen that displays the usage statement from each member store.

The memo field 712 is an input field in which the user can freely enter text, and is an input field for the user to leave a memo of himself/herself regarding the contract content. The text entered in the memo field 712 is stored in the contract DB 144 as contract information. As a result, the user can, for example, leave a memo of the intention of future contract renewal and the like, and the convenience of the user can be improved.

As described above, the user can browse the contract content associated with the usage details of the credit card, and can easily understand the reason why the payment was made. In particular, since each usage statement in which payment (expenditure) is generated regularly is associated with the contract, it is not necessary to input memos one by one, and user convenience can be improved.

FIG. 8 is a flowchart showing an example of a processing procedure executed by the detail inquiry system. The contents of the processing executed by the detail inquiry system will be described with reference to FIG.
The terminal 2 performs a predetermined login process and transmits information including the user's member ID and the like to the server 1 (step S11). The server 1 reads detailed information indicating the usage details of the user's credit card and contract information corresponding to the payment factor (expenditure factor) of the detailed information from each database based on the member ID and the like, and transmits it to the terminal 2. (Step S12). For example, the server 1 reads out the detailed information associated with the user's member ID from the detailed DB 143. In addition, the server 1 reads each contract information associated with the user's member ID from the contract DB 144.

The server 1 compares the read detailed information and the contract information, estimates the contract information corresponding to the detailed information, associates the detailed information and the contract information, and then transmits them to the terminal 2. For example, the server 1 uses the details (details) of the usage details included in the specification information, the member store ID of the member store that is the biller, the contract name included in the contract information, and the member store ID of the member store that is the contract partner. Etc. and the contract corresponding to the payment factor of each usage statement of the credit card is estimated. The server 1 transmits the information of each contract to the terminal 2 in a form associated with each usage statement.

When the detailed information and the contract information are received from the server 1, the terminal 2 displays a detailed screen showing a list of detailed information (step S13). Specifically, as illustrated in FIG. 5, the terminal 2 displays a list of monthly usage details designated by the user. In this case, for example, the terminal 2 displays the detailed information associated with the contract information in a mode different from other detailed information.

The terminal 2 determines whether or not there is detailed information for which contract information has not been acquired (unregistered) among the detailed information received from the server 1 (step S14). For example, the terminal 2 determines whether or not the item information is the item information to which the contract information should be associated according to the content of the usage statement, the member store that is the billing source, and the like. Further, for example, the terminal 2 determines whether or not there is a bill from the same member store for a plurality of consecutive months, or for a plurality of years and for substantially the same amount of money in the same month. When it is determined that there is detailed information to which the contract information is associated, the terminal 2 further determines whether or not the contract information corresponding to the detailed information is acquired from the server 1.

When it is determined that there is unacquired detailed information for the contract information (S14: YES), the terminal 2 displays a popup image 61 that prompts the user to input the contract information corresponding to the detailed information, by superimposing it on the detailed screen. Yes (step S15). The terminal 2 accepts the input of the contract information and transmits it to the server 1 together with the detailed ID of the corresponding detailed information (step S16). For example, the terminal 2 images the contract according to the operation input by the user, extracts necessary contract information from the captured image, and transmits the contract information to the server 1. When the contract information and the item ID are received from the terminal 2, the server 1 stores the contract information in association with the item ID (step S17).

After executing the process of step S16 or in the case of NO in step S14, the terminal 2 accepts a designation input for designating any one of the detailed information displayed in the list (step S18). The terminal 2 superimposes and displays the pop-up image 71 showing the contract information corresponding to the specified detailed information on the detailed screen (step S19). The pop-up image shows the contract name (plan name), the name of the contracted member store, the contract content, the contract period (renewal time), and the amount of the bill that is regularly generated based on the contract, as well as the contract cancellation procedure. It includes a hyperlink 711 for transitioning to a Web page to be performed, a memo field 712 in which the user can freely enter text, and the like.

The terminal 2 accepts operation inputs to the hyperlink 711, the memo field 712, etc. (step S20). The terminal 2 determines whether or not to execute the contract cancellation procedure based on the presence/absence of an operation input to the hyperlink 711 (step S21). When it is determined that the cancellation procedure is to be performed (S21: YES), the terminal 2 transitions to the Web page for performing the contract cancellation procedure (step S22). After executing the process of step S22, or in the case of NO in step S21, the terminal 2 ends the series of processes.

In the above description, payment from the user to the member store (business operator) has been taken as an example, but the present embodiment is not limited to this, and for example, expenditures for deposits and investment, defined contribution pension, etc. The present embodiment may be applied to contract management for. That is, the expenditure from the user to the business is not limited to mere payment, but may be transfer of some asset (money).

Further, in the above, when performing the cancellation procedure, it is decided to transit to the Web page provided by the member store, but the present embodiment is not limited to this, and the cancellation procedure is performed by the operation on the pop-up image 71. It may be possible.

Further, in the above description, for convenience, one contract information is associated with one usage statement (specification information) of the credit card, but the present embodiment is not limited to this. Alternatively, a plurality of contract information may be associated with one usage statement. For example, when a user makes a plurality of contracts (for example, mobile phone call contracts for the whole family) with the same member store (for example, a telephone company), a plurality of contracts for each of the plurality of contracts for one usage statement. Information may be managed in association with each other, and a plurality of contract information may be displayed as a list by the pop-up image 71 on the detailed screen of FIG. 7.

As described above, according to the first embodiment, it is possible to manage the details of the expenditure generated based on the contract in association with the contract content.

Further, according to the first embodiment, the contract information can be easily browsed by designating any one of the detailed information displayed on the detailed screen, and the convenience of the user can be improved.

Further, according to the first embodiment, it is possible to proceed to the contract cancellation procedure from the credit card statement screen, and it is possible to enhance the convenience for the user.

Further, according to the first embodiment, it is possible to link the usage details scheduled for payment (expenditure) with the contract information, and not only the usage details already billed but also the usage details scheduled to be billed. You can also check the corresponding contract details.

(Embodiment 2)
In the present embodiment, the contract information is acquired in advance before the member store makes a payment request to the user, and the contract information acquired in advance is associated with the item information when the member store makes a payment request. Describe. It should be noted that the same contents as those of the first embodiment are designated by the same reference numerals and the description thereof will be omitted.
In the first embodiment, it has been described that the terminal 2 operated by the user accepts the setting registration of the contract information. On the other hand, the server 1 may acquire the contract information not from the user side but from the member store side.

For example, when the server 1 receives an inquiry about the credit information of the user from the member store apparatus 3, the server 1 also acquires the contract information. Generally, when a user uses a credit card at a member store, a credit card company receives an inquiry from the member store, evaluates the credit of the user, and determines whether or not to approve the use of the credit card. There is. In the present embodiment, the server 1 acquires contract information at the timing of the above credit judgment.

That is, the server 1 accepts an inquiry about the credit information of the user from the member store apparatus 3 when the member store makes a contract with the user to pay based on the credit card. When the inquiry from the member store apparatus 3 is accepted, the server 1 refers to the statement DB 143 to determine whether delay in payment or the like has occurred, and whether to approve the use of the credit card or not. evaluate. The server 1 returns the credit information to the member store device 3.

In this case, when the credit information for approving the use of the credit card is returned, the server 1 acquires the contract information from the member store apparatus 3. The server 1 stores the contract information in the contract DB 144 in association with the IDs of the user who is the party to the contract and the member store. By the above-described processing, the user does not need to set and register the contract information by himself, and the convenience can be improved.

FIG. 9 is a flowchart showing an example of a processing procedure executed by the server 1 according to the second embodiment.
The server 1 receives an inquiry from the member store apparatus 3 regarding the credit information of the user who is a member of the credit card (step S201). The server 1 refers to the statement DB 143 to generate credit information that evaluates whether or not to approve the use of the credit card, and transmits it to the member store apparatus 3 (step S202).

When the credit information to approve the payment using the credit card is transmitted, the server 1 acquires the contract information regarding the contract made between the user and the member store from the member store apparatus 3 (step S203). The server 1 stores the acquired contract information in the contract DB 144 in association with the member ID of the user and the member store ID of the member store (step S204), and ends the series of processes.

As described above, according to the second embodiment, the user does not need to set and register the contract information by himself, and the convenience can be improved.

(Embodiment 3)
In the present embodiment, a mode will be described in which the user is recommended to transfer to a contract different from the existing contract with the member store.
FIG. 10 is an explanatory diagram showing an example of the detail screen according to the third embodiment. In the present embodiment, the server 1 has a contract (second contract) different from the existing contract (first contract) when the terminal 2 displays the pop-up image 71 showing contract information. Information) is displayed, and the user is recommended to switch to the contract.

For example, the server 1 refers to the contract information of the existing contract stored in the contract DB 144, and determines whether or not the current date corresponds to the renewal time of the existing contract. The renewal time is, for example, a period from the date before the renewal date of the contract by a predetermined period until the renewal date. When it is determined that the update period is applicable, the server 1 presents contract information of another contract, that is, information of another contract plan provided by the member store in order to recommend the user to review the existing contract. For example, when it corresponds to the renewal time of the insurance contract, the server 1 presents the contract information of another insurance product.

For example, as shown in FIG. 10, the terminal 2 displays the contract information regarding the existing contract and the contract information regarding the different contract in the same pop-up image 71. In addition, for example, the terminal 2 also displays a comparison result obtained by comparing payment amounts generated by each contract so that the user can easily compare the contracts. Further, for example, the terminal 2 displays a hyperlink 713 for transitioning to a Web page for performing the application procedure for another contract so that the user can easily perform the transfer procedure for another contract.

Although only one separate contract is shown in FIG. 10, a plurality of separate contracts may be presented. Further, the item to be compared between the existing contract and another contract is not limited to the payment amount, and may be, for example, the contract period or other items. As described above, the server 1 only needs to be able to present the existing contract and the separate contract in a mode that allows the user to compare them, and the specific mode is not particularly limited.

FIG. 11 is a flowchart showing an example of a processing procedure executed by the specification inquiry system according to the third embodiment.
After the terminal 2 performs a predetermined login process and transmits the user's member ID and the like to the server 1 (step S11), the server 1 executes the following process. The server 1 reads the detailed information associated with the member ID and the contract information corresponding to the detailed information from each database (step S301).

The server 1 refers to the read contract information and determines whether or not the current date corresponds to the renewal time that is a predetermined period before the contract renewal date (step S302). When it is determined that the update time is applicable (S302: YES), the server 1 accesses the member store apparatus 3 and acquires contract information regarding another contract different from the existing contract that the user has already exchanged with the member store. Yes (step S303). After executing the process of step S303 or in the case of NO in step S302, the server 1 transmits the contract information related to another contract to the terminal 2 together with the detailed information and the existing contract information corresponding to the detailed information (step S304). ). The terminal 2 shifts the processing to step S13.

When the specification input of the detailed information is received (step S18), the terminal 2 compares the existing contract information corresponding to the specified detailed information with the contract information regarding another contract different from the contract indicated by the contract information. The pop-up image 71 to be displayed is displayed (step S305). Specifically, as described above, the terminal 2 displays the existing contract information and the contract information of another contract, and also displays the comparison result obtained by comparing the billed amount and the like. The terminal 2 shifts the processing to step S20.

As described above, according to the third embodiment, by recommending the user to transfer to another contract, it is possible to support the review of the existing contract.

(Embodiment 4)
In the present embodiment, a mode will be described in which not only the detailed statement information of the payment already charged by the member store is displayed, but also the payment schedule estimated to be charged by the member store is displayed based on the contract information. ..
As described in the first embodiment, the server 1 stores the contract information regarding the contract that the user has with each member store in the contract DB 144. In the first embodiment, the server 1 contributes to the convenience of the user by presenting the contract information corresponding to the usage details of the credit card charged by the member store.

On the other hand, since the contract information is stored in the contract DB 144, the server 1 can estimate the payment schedule (spending schedule) of the credit card generated by the user. That is, the server 1 can estimate the payment schedule to be generated based on the contract from the monthly billing amount, billing date, etc. defined in the contract information, and present it to the user.

FIG. 12 is an explanatory diagram illustrating an example of the detail screen according to the fourth embodiment. For example, when a month prior to the current month is designated in the monthly designation field 51, the terminal 2 generates detailed information that payment is estimated to be generated in the monthly, and the detailed list 52 is displayed. indicate.

For example, when the previous month is designated in the monthly designation field 51, the terminal 2 sends detailed information to the server 1 indicating the payment schedule to be generated based on the contract the user has with each member store. Request to output. When the request is received from the terminal 2, the server 1 estimates the usage statement expected from the billing amount, the billing date, etc. included in the contract information of each contract associated with the user's member ID, and generates the statement information. And sends it to the terminal 2. The terminal 2 displays a list of the detailed information received from the server 1 on the detailed screen. Needless to say, the contract information may be viewable on the detailed screen regarding the usage details to be paid.

FIG. 13 is a flowchart showing an example of a processing procedure executed by the specification inquiry system according to the fourth embodiment.
After the server 1 transmits the detailed information and the contract information to the terminal 2 (step S12), the terminal 2 executes the following processing. According to the operation input from the user, the terminal 2 determines whether or not to display the detailed information indicating the usage details to be paid based on the contract with the member store (step S401). When it is determined that the detailed payment information is not displayed (S401: NO), the terminal 2 shifts the processing to step S13.

When it is determined that the usage details to be paid are displayed (S401: YES), the terminal 2 requests the server 1 to generate and output detailed information indicating the usage details to be paid (step S402). When the request is received from the terminal 2, the server 1 refers to the contract information associated with the user's member ID and displays detailed information indicating the usage details of the credit card estimated to be paid by the contract. It is generated and transmitted to the terminal 2 (step S403). The terminal 2 displays the detailed information received from the server 1 in a list on the detailed screen (step S404), and moves the process to step S18.

As described above, according to the fourth embodiment, it is possible to grasp the details of the credit card to be paid based on the contract, which contributes to the convenience of the user.

The embodiments disclosed this time are to be considered as illustrative in all points and not restrictive. The scope of the present invention is shown not by the above meaning but by the scope of the claims, and is intended to include meanings equivalent to the scope of the claims and all modifications within the scope.

1 server (information processing device)
11 control unit 12 main storage unit 13 communication unit 14 auxiliary storage unit P1 program 141 member DB
142 member store DB
143 Detail DB
144 contract DB
2 terminal 21 control unit 22 main storage unit 23 communication unit 24 display unit 25 input unit 26 imaging unit 27 auxiliary storage unit P2 program 3 member store device

Claims (9)

A first acquisition unit which is contract information related to a contract between a user and a business, and which acquires contract information of the contract in which the user regularly pays the business.
A second acquisition unit that acquires detailed information indicating a detailed description of spending from the user to the business operator;
A storage unit for storing the detailed information and the contract information,
An output unit configured to output the contract information corresponding to the spending factor of the detailed information to the terminal device of the user together with the detailed information. The output unit outputs a list screen of the detailed information,
From the list screen, a reception unit that receives a specification input that specifies any of the detailed information,
The information processing apparatus according to claim 1, wherein the output unit outputs the contract information corresponding to the spending factor of the specified detailed information. The information processing apparatus according to claim 2, wherein the output unit outputs the contract information including a contract cancellation method or link information for canceling the contract. A second receiving unit that receives an inquiry about the credit information of the user from the business operator;
The said 1st acquisition part acquires the said contract information from the said enterprise, when the inquiry of the said credit information is received. The information processing apparatus of any one of Claims 1-3 characterized by the above-mentioned. A third acquisition unit that acquires contract information of a second contract different from the first contract that the user has with the business operator,
The output unit outputs the contract information related to the first contract, the contract information about the second contract, and a comparison result obtained by comparing the first and second contracts. The information processing apparatus according to claim 1. A generating unit that refers to the contract information and generates the detailed information indicating the details of the planned spending by the user,
The information processing apparatus according to any one of claims 1 to 5, wherein the output unit outputs the detailed information related to the details of the planned spending. Contract information relating to a contract between a user and a business operator, wherein contract information of the contract in which regular payment is generated from the user to the business operator is acquired,
Obtaining detailed information indicating the details of expenditure from the user to the business operator,
The detailed information and contract information are stored in the storage unit,
An information processing method, comprising: causing a computer to execute a process of outputting the contract information corresponding to an expense factor of the detailed information to a terminal device of the user together with the detailed information. Contract information relating to a contract between a user and a business operator, wherein contract information of the contract in which regular payment is generated from the user to the business operator is acquired,
Obtaining detailed information indicating the details of expenditure from the user to the business operator,
The detailed information and contract information are stored in the storage unit,
A program for causing a computer to execute a process of outputting the contract information corresponding to an expense factor of the detailed information to the terminal device of the user together with the detailed information. Contract information relating to a contract between a user and a business operator, showing contract information of the contract in which the user regularly pays the business operator, and details of the spending that has occurred based on the contract. Get detailed information and
Display the list screen of the detailed information on the display unit,
From the list screen, accept specification input to specify any of the detailed information,
A program for causing a computer to execute a process of displaying the contract information corresponding to the specified detailed information on the display unit.

Images