User-controlled sourcing data control

Abstract

A method for user-controlled sourcing data control on a terminal comprises at least the following steps: acquiring user data on the terminal, the user data representing a user and / or a use of the terminal; generating a requirement dataset on the basis of the user data according to a requirement rule able to be predetermined by the user, the requirement dataset representing a sourcing wanted by the user in relation to at least one product; and generating a sourcing dataset on the basis of the requirement dataset, the sourcing dataset representing at least one available sourcing of the at least one product.

Description

[0001] User-controlled procurement data control

[0002] The present invention relates to methods, computer programs and devices for user-controlled procurement data control using terminal devices, in particular mobile terminal devices such as smartphones, tablets and the like.

[0003] Digitalization in almost all areas of life now offers device users a wide range of options for procuring required products, such as items or services, flexibly and quickly. However, the volume of required data flows is increasingly leading to problems with data efficiency and security. In connection with the generation and provision of procurement data, the demands on the performance of technical data processing tools have increased significantly. For example, extensive procurement data that is automatically provided on a mobile device requires high data transmission capacities and, as a rule, powerful graphics processors to adequately display the procurement data. This can have an undesirable impact on the processing speed of the device, despite increasingly powerful devices.Furthermore, efficient use and analysis of procurement data is made more difficult, especially when data is received in packets with higher latency. Real-time processing of procurement data is then practically impossible.

[0004] Another problem area concerns the protection of sensitive user data, the misuse of which, whether private or commercial, must be counteracted as far as possible.

[0005] Given the problems described above, it is conceivable to restrict the receipt of procurement data on a device. Alternatively, an attempt could be made to protect the user data captured on the device from third-party access through manual settings. However, these measures hamper the potential to make product procurement more efficient and easier by providing users with meaningful procurement data.

[0006] It is an object of the invention to provide a method for procurement data control which optimizes the generation of procurement data in the sense of accurate and rapid information about available procurement options and at the same time offers better protection of the underlying user data.

[0007] The object is achieved by a method having the features of claim 1. Such a method serves for user-controlled procurement data control on a terminal device and comprises at least the following steps: capturing user data on the terminal device, wherein the user data represents a user and / or a use of the terminal device; generating a request data record on the basis of the user data as a function of a request rule predeterminable by the user, wherein the request data record represents a procurement of at least one product desired by the user; and generating a procurement data record on the basis of the request data record, wherein the procurement data record represents at least one available procurement of the at least one product.

[0008] One aspect of the solution is that the procurement data is not generated directly from the usually very extensive user data, but rather from a separately generated requirement data set. The requirement data set is generated based on a requirement rule that can be predetermined by the user. The user thus has complete control over the extent and form of their user data used to generate the procurement data. The user data itself can, of course, also be partially contained in the requirement data set. In this case, however, the user data in question must "pass" the requirement rule. User data is therefore only used to generate the procurement data under the conditions specifically defined in the requirement rule.

[0009] The inventive solution creates user-controlled procurement data control in two respects. Firstly, the user controls the data basis for the procurement data not merely through individual, more or less reliable data protection filters for the user data, but through a holistically designed requirement or data rule that is subject to user control. Secondly, the user's requirements for a desired procurement of a product are summarized in a separate requirement data set, which can be processed independently of other data, especially raw user data, and thus represents a means of enforcing procurement data control.

[0010] The requirement rule preferably does not merely serve as a filtering tool for user data, but rather enables targeted data transformation with regard to one or more required products. In particular, the requirement data set generated based on the requirement rule is tailored to efficient and targeted procurement and is therefore preferably not merely understood as a subset of a large user data pool. In this respect, one aspect of the control solution according to the invention is that the procurement data set is not based directly on the user data, but rather on the requirement data set generated for this purpose. In this way, the scope, form, and quality of the procurement data can be controlled directly by the user, which was not previously possible.

[0011] From the user's perspective, extensive control over the available user data is guaranteed. The user no longer has to take a passive role, as was previously the case, allowing extensive user data to flow from the device by consenting to cookies and receiving procurement data that is largely irrelevant and hinders efficient procurement and the efficient use of the device. Instead, the user is enabled to actively request only the desired procurement data and receive it promptly. The potential of the available data can still be fully exploited while maintaining data control.

[0012] The product to be procured can generally be a required object to which specific technical properties and parameters are assigned. Alternatively, the product can also be a service, which can also be characterized by technical data, such as in the case of a repair service. Both the service and the object in question are described by procurement data that are relevant to the user and specify at least one aspect for the possible procurement of the service or product. A product can also be other types of products, e.g. a food product. The procurement data can also be of a technical nature, e.g. in the form of a weight specification or as geographical and / or temporal availability information for a specific food product. Embodiments of the invention are disclosed in the claims, the description and the figures.

[0013] According to one embodiment, the method is fully or partially computer-implemented. A distributed execution of the method steps is preferred, such that user data is collected at least partially on the terminal device, in particular using the terminal device's data processing means, such as the processor, the platform (e.g., operating system), and / or the user interface, which is preferably graphical. User data stored internally on the terminal device can also be collected, which data is generated, for example, by using software applications installed on the terminal device.

[0014] To generate the request data record, user data is preferably transferred to a central server associated with the device and considered particularly trustworthy and secure. The user thus retains control over these procedural steps. Alternatively, it is conceivable that the request data record is generated on the device itself to enforce data control even more strictly.

[0015] The procurement dataset is preferably generated on another central server, which, however, does not necessarily have to have the same level of trust as the server responsible for generating the request dataset. Typically, the user will want the request dataset to at least not contain particularly sensitive user data. Accordingly, the data security requirements for processing the request dataset can be reduced. However, for maximum data security, it is possible to maintain consistently high requirements, for example, by using special data formats and cryptographic procedures.

[0016] The terminal is preferably a mobile device, e.g., a smartphone, tablet, laptop, or other compact data terminal. The terminal is preferably equipped with a display device that has a graphical user interface for controlling the terminal, for example, in the form of a touch-sensitive display surface.

[0017] According to a further embodiment, the request rule can be modified by the user. For example, the user can select a desired request rule from various predetermined request rules, making the type of modification particularly simple for the user. Alternatively, the user can set one or more subrules, e.g., by specifying a data type and / or restricting the user data that can be used for the request data set. Conversely, certain parts of the user data can be excluded from generating the request data set. The request rule can thus comprise selective filtering of the user data.

[0018] The request rule preferably includes a sub-rule for transforming the user data. The transformation can, in particular, be designed such that the request data extends beyond the user data itself. In other words, the request data set includes not only subsets of the user data, but also data derived from the user data, which can thus represent the result of an automated analysis of the user data. The request data set can thus be significantly more powerful than the user data itself. The user nevertheless retains control over which information is released. For this purpose, the request rule can also start with the generated request data set by analyzing it as well and, if necessary, removing unwanted sub-data from the request data set.

[0019] With regard to the aforementioned aspect of data transformation, the requirement rule can incorporate a machine learning model. This allows even complex dependencies within the user data to be exploited. The requirement data sets can still be generated quickly with a small and meaningful data volume. The model is preferably self-learning, meaning it is continuously improved through the use of user feedback data.

[0020] Various variants are conceivable for the model type used in the requirement rule. Good results are usually achieved with a neural network, particularly a convolutional neural network (CNN).

[0021] In a preferred embodiment, the user data is captured on the terminal device using a progressive web app (PWA). This enables data capture on the terminal device even without an existing data communication connection (offline), while still enabling user-friendly control from the browser. In this case, the installation of an app can advantageously be dispensed with. The user data captured using PWA is preferably transmitted from the terminal device to a central server on which the request data record is generated. Alternatively or additionally, the user data can be captured by the operating system of the terminal device, whereby the operating system can have one or more capture programs for this purpose. According to a further embodiment, the request rule provides that the request data record is generated depending on an active input from the user on the terminal device.In this way, the user can directly control when and, if applicable, under what circumstances a request data record is generated. For example, the user's input can contain a specification regarding when the request data record should be generated and which conditions must be met for the desired procurement and the product in question. Active input thus promotes the goal of user-controlled control. In particular, this control can also consist of ensuring that no unsolicited or irrelevant procurement data is received on the device, as specified by the user.

[0022] The user's input preferably includes authentication data, such as a password or a biometric identification feature (e.g., a fingerprint or a facial photograph of the user). This can further increase the security of the process.

[0023] According to a further embodiment, the procurement data record is generated depending on validity data that represents a time-limited validity of the request data record. Additionally or alternatively, the provision of the procurement data record to the terminal device can be made dependent on the validity data. This reduces the data transmission requirement. Furthermore, the accumulation of unnecessary or irrelevant procurement data on the terminal device is avoided.

[0024] As explained, the inclusion of validity data in procurement data control also serves to improve data security. For this purpose, a further embodiment can provide for the generation of a respective request data record in a non-storable data format. Immediate processing of the data can be enforced in this way. The provision of irrelevant or delayed procurement data records is thus at least less likely. At the same time, misuse of the data is made more difficult. Furthermore, the request data record and any validity data are preferably not modifiable. This feature is also suitable for improved procurement data control.

[0025] To further increase data security, it is preferable to provide the request data record in encrypted form on a central server. This can, in particular, be the server that generates the procurement data record. If user data is also transmitted to a central server, it can be encrypted using known cryptographic methods for increased security to protect it from unauthorized access.

[0026] According to a further embodiment, the procurement data set is provided to the terminal device based on authorization data. The source of the procurement data set is thus verified or authenticated. This can counteract the processing of false or insecure procurement data at the terminal device. In one embodiment, the authorization data can be formed by an authentication code, which is initially part of the request data set and is incorporated into the procurement data set as proof of authorization.

[0027] According to a further embodiment, the request data set is generated depending on at least one data profile that can be selectively activated and / or modified by the user. For example, the user can select a data profile from a number of predetermined data profiles to activate it and use it as the basis for generating the request data set.

[0028] The data profile serves to improve the control of the process and is preferably taken into account when executing the request rule.

[0029] The procurement data records can also be generated depending on a data profile, whereby a respective procurement data record can be directly adapted to the underlying requirement data record via the data profile.

[0030] The data profile preferably defines a priority for a predetermined master data type of the requirement and / or procurement data set. The master data type thus serves to structure the data and represents an aspect of the desired procurement (in the case of the requirement data set) or the available procurement (in the case of the procurement data set) that is highlighted for the user. The master data type is preferably formed by one of the following data types: position data; time data; image, video, and / or audio data; or specification data.

[0031] According to a further embodiment, the user data and / or the request data record comprise at least one of the following data types: position data, in particular relating to an area of ​​a desired delivery; time data; image, video, and / or audio data; procurement data previously provided on the terminal device; and / or specification data. In terms of content, the user data represents at least one aspect of the desired procurement, e.g., a local area in which the required product is to be procured (position data); a time window within which the product is to be procured (time data); a photo, a film, or an acoustic description of the desired product or similar products to be procured (image, video, and / or audio data). The user data or the request data record can thus contain specific requirements for the desired procurement.The procurement data generated as a result can be tailored to this in such a way that products that are available but violate one of the requirements mentioned are not represented in the procurement data set.

[0032] The user data may have been entered on the end device currently or in the past, in particular when using one or more apps installed on the end device. The user data can also be recorded on the end device automatically, but preferably in a user-controlled manner, i.e. the user can exclude certain types of user data from recording and subsequent processing from the outset. On the other hand, user data that the user has not directly entered can be derived as additional user data. For example, information about potentially required products can be determined based on the user data, in particular using powerful machine learning models. Furthermore, procurement data previously provided on the end device and / or information about actually procured products can be incorporated directly as user data or in derived form into the newly generated requirement data set.

[0033] According to a further embodiment, the procurement data record comprises at least one of the following data types: Position data, in particular relating to a range of possible delivery of an available product; Time data; Image, video, and / or audio data (e.g., a static or dynamic image of the product); Specification data (e.g., a size of the product or a product quantity); and / or Delivery data (e.g., a price of the product). In terms of content, the aforementioned data types represent at least one aspect of the available procurement of a product, in particular adapted to the specifications of the requirement data record. The product in question can correspond exactly to the product desired according to the requirement data or be a similar product. In general, a procurement data record can also specify available procurement options for multiple products.

[0034] The procurement data record should generally be adapted to the requirement data record. The adaptation can relate to both the data content and the data format. For example, the adaptation between the data records can be achieved by using data profiles with matching data types, as described above. Furthermore, it is preferred that a unique assignment exists between a requirement data record and a procurement data record generated on this basis, which can be taken into account when providing the procurement data record to the terminal device.

[0035] For efficient procurement data control, the procurement data set can be generated based on a predetermined procurement data rule. The procurement data rule is adapted to optimize the match between the desired procurement and an available procurement based on the requirement data set and a product data set. The product data set represents at least one available product that can be procured by the user and can therefore be communicated to the user via the procurement data. The match between the requirement data and the product data can be maximized, for example, by hierarchically checking one or more optimization conditions.

[0036] According to a further embodiment, the procurement data set is generated based on a plurality of predetermined procurement data sets stored in a database. The procurement data sets can be generated particularly efficiently and quickly in this way because they are available at least in a draft or already in a final form. In the simplest case, a procurement data set therefore only needs to be selected or only slightly modified. The generation of the data set is then possible particularly efficiently.

[0037] According to a further aspect, the invention relates to a method for generating a request data record for user-controlled procurement data control using a terminal device. The method comprises, firstly, the acquisition of user data on the terminal device, wherein the user data represents a user and / or a use of the terminal device. Secondly, a request data record is generated based on the user data in accordance with a request rule predeterminable by the user.

[0038] The request data record represents, as described above, a procurement of at least one product desired by the user. The request data record preferably forms the basis for generating a procurement data record that represents at least one available procurement of the product. The request data record can be provided on a central server for this purpose. The steps of the method are preferably carried out using different data processing units, in particular such that the user data is recorded on the terminal device and the request data record is generated on a central server that receives the user data from the terminal device. The request data record can then be transmitted to another central server for the purpose of generating the procurement data record.

[0039] With regard to the aspect of generating the procurement data as such, the invention relates, according to a further aspect, to a method for generating a procurement data record for user-controlled procurement data control using a terminal device. The method comprises at least the following steps: receiving a request data record generated on the basis of user data in accordance with a request rule predeterminable by the user. The request data record represents—as before—a procurement of the at least one product desired by the user. Likewise, the user data represents a user and / or a use of the terminal device. The method further provides for generating a procurement data record based on the request data record.

[0040] The procurement data record represents at least one available procurement of at least one product, which, as described, can be an object, a service, or a food product. Preferably, all steps of the method are performed on a central server. The server can receive the request data record from a second server and provide the procurement data record directly or indirectly (e.g., via the second server) to the terminal device.

[0041] Preferably, the procurement data record is generated based on a product data record that represents at least one available product for the desired procurement. The product data record can generally be received from another central server that generates product data records or queries a database.

[0042] According to a further aspect, the invention relates to a method for generating a product data record for user-controlled procurement data control using a terminal device. The method comprises at least the following steps: receiving a request data record generated on the basis of user data in accordance with a request rule predeterminable by the user. As before, the request data record represents a procurement of at least one product desired by the user. The user data represents, as in connection with the aspects already described, a user and / or a use of the terminal device.

[0043] The method further provides for generating a product data record based on the requirement data record. The product data record generally contains information about available products and is therefore used to generate a procurement data record. Preferably, the method is executed on a central server that is separate from a second server on which the procurement data record is generated.

[0044] It should be understood that the described methods can each be embodied as computer-implemented methods, i.e., all or at least some of the method steps are carried out by a computer in the broadest sense. The respective computer or computer-like unit can be formed by a central server or a part thereof. The user's terminal device also represents a computer that executes the method steps assigned to it in a computer-implemented manner.

[0045] It is also to be understood that each of the described methods may be embodied by a computer program, wherein the instructions of the computer program, when executed on a computer, cause the computer to carry out the steps of a method according to at least one of the embodiments disclosed above.

[0046] A further aspect of the invention generally relates to a device connected to at least one electronic data processing means and a non-volatile memory. A computer program is stored in the memory, the instructions of which, when executed by the at least one data processing means, cause the latter to carry out the steps of a method according to at least one of the embodiments disclosed above. The device can, in particular, be formed by a terminal or a central server. Furthermore, it should be understood that, with distributed execution of the method steps on different devices, a corresponding system can be formed that serves to implement user-controlled procurement data control.

[0047] The described methods are preferably designed to be real-time capable. For example, the time span between the generation of the request data record and the subsequent provision of the associated procurement data record can be less than 500 milliseconds. This assumes a typical data transmission speed of a mobile network. However, other values ​​may also apply.

[0048] The features disclosed in connection with the first-described method, in particular in connection with the individual embodiments, can also be implemented in a corresponding manner in each of the other described methods. In other words, the features of the embodiments can be implemented in a corresponding manner in the remaining methods.

[0049] For ease of understanding, the above assumption was made that a single requirement data set is used to generate a procurement data set. However, it is of course possible to carry out the process in a corresponding manner with multiple requirement data sets and / or procurement data sets.

[0050] The described aspects of the invention are described below purely by way of example with reference to the drawings, in which:

[0051] Fig. 1 shows a first diagram illustrating aspects of a method for user-controlled procurement data control;

[0052] Fig. 2 shows a second diagram illustrating aspects of the method for user-controlled procurement data control of Fig. 1; and

[0053] Fig. 3 is a third diagram illustrating aspects of the method for user-controlled procurement data control of Fig. 1 .

[0054] Functionally identical elements are marked with the same reference symbols.

[0055] A method for user-controlled procurement data control is first described with reference to Fig. 1. At the beginning of the method, user data 16 and usage data 18 are recorded within a usage instance 10. The usage instance 10 comprises at least one mobile electronic device that is regularly operated and controlled by a user for various purposes, in particular to procure required products or at least to initiate the procurement. The device can be a smartphone, for example.

[0056] The user data 16 includes, in particular, data that characterizes the user as such, e.g., in the form of the user's personal characteristics (e.g., age, gender, purchasing power, marital status, and / or attitudes and interests regarding required products). However, the user data 16 may also contain direct specifications regarding generally required products and / or their procurement, e.g., in the form of specification data for required products or location data that describe a desired delivery area for a product.

[0057] Usage data 18 primarily includes data related to the direct use of the device, whereby usage data 18 can be divided into two groups. Firstly, usage data 18 results from the user's operation, such as the apps used or websites accessed, the data content exchanged in this process, and the usage time. Other data representing usage behavior can also be used.

[0058] Another part of the data recorded on the device relates to any procurement data records 19 that were provided on the device. These provide information about the range of required products and other associated detailed information. In addition to specification data describing the product itself, the previous procurement data records 19 may also contain advertising data, for example, in the form of brand names and / or offer prices.

[0059] The usage data 18 may also contain information about products that were actually procured by the user in response to provided procurement data 19. The usage data 18 thus provides information about the relevance of procurement data sets 19 that were provided to the terminal device in the past.

[0060] The user data 16, the usage data 18, and the previous procurement data 19 are processed with a requirement rule 20 to generate a requirement data set 22. The requirement rule 20 comprises a machine-trained model, in particular a neural network, which is stored and executed on a central server S of the usage instance 10 (see Fig. 3).

[0061] The execution of the request rule 20 is dependent on input data 15 entered by the user on the terminal device. The request data record 22 is therefore only generated after the user has given their approval. This approval can optionally be granted in the form of a permanent approval, e.g., in the form of a flag that can be set optionally by the user. The input data 15 preferably includes the user's authentication data.

[0062] In terms of high data control, the request rule 20 is characterized by the fact that it can be predetermined by the user and modified as needed. For example, in connection with an initial or subsequent training of the request rule 20, the user can decide which data should be used for this purpose. Accordingly, the user can directly set which parts of the user data 16, usage data 18, and procurement data 19 available on the terminal device should be used to generate the request data record 22. Alternatively or additionally, the request rule 20 can have a downstream filtering stage such that unwanted data components in a generated request data record 22 are detected and automatically removed before transmission to another server. The filtering stage can be set directly by the user, e.g.by specifying data groups that should not be part of the request data (e.g. no personal data such as age or interests, which may, however, be part of the user data 16).

[0063] The requirement data set 22 preferably contains only information about one or more products that the user actually wishes to procure. In other words, the information contained in the requirement data set 22 relates exclusively to products that fall within a range of needs requested by the user. However, additional data that, for example, is only loosely related to the product or its procurement and could thus dilute the requirement data set 22 is not included. The data processing resources required for transmitting the requirement data set 22 and evaluating it can therefore be correspondingly smaller. Alternatively, a larger number of requirement data sets 22 can be generated and processed. These can, in particular, originate from different usage instances.

[0064] For further processing, the request data record 22 is transmitted from the usage instance 10 to a procurement data instance 12. The request data record 22 was preferably encrypted beforehand to prevent data misuse. The procurement data instance 12 comprises a central server (not shown) that computer-aidedly evaluates the request data record 22 and generates a request and provision data record 24. Compared to the request data record 22, the data record 24 is expanded by provision data relating to aspects of the technical provision of a procurement data record 28 to be generated at the usage instance 10. For example, the provision data may contain a data type for the procurement data record 28 that is not directly specified in the request data record 22.

[0065] The requirement and provision data record 24 is provided to a product data instance 14, which generates a product data record 26 based on this data record 24. The product data record 26 represents both data of a product to be procured according to the requirement data record 22, as well as data relating to the possible procurement, such as position data that indicates a desired delivery location for the product. Any marginal requirements for the procurement data record 28 resulting from the provision data can also be taken into account by the product data instance 14 when generating the product data record 26.

[0066] The product data record 26 is transmitted from the product data instance 14 to the procurement data instance 12, which generates the procurement data record 28 on this basis. The procurement data record 28 is then provided to the usage instance 10 and, in particular, transmitted to the terminal device.

[0067] The procurement data record 28 is at least partially evaluated and displayed on the terminal device to inform the user about one or more available procurement options. The user can then decide whether or not to initiate the procurement of a product.

[0068] The separately generated requirement data set 22 ensures to a high degree that the procurement data set 28 meets the user's requirements for their desired procurement. The procurement data set 28 is thus highly relevant to the user and therefore facilitates the efficient procurement of products. Furthermore, procurement data sets 28 are provided in response to an active requirement, thus avoiding the generation and transmission of superfluous procurement data.

[0069] Further aspects which shape the method for user-controlled procurement data control of Fig. 1 are described below with reference to Fig. 2.

[0070] The generation of the request data set 22 is based on a predetermined data profile. The user can select from one of the data profiles A, B, C, or D. The respective selection is taken into account as part of the input data 15 when executing the request rule. Available options are a position data profile A, a time data profile B, an image data profile C, and a specification data profile D.

[0071] Position data profile A defines position data as the master data type for the requirement data set 28. This can be done, in particular, in such a way that the available procurements of one or more products must be deliverable within a territory specified by the position data, for example, by personal pickup or by delivery to a location specified by the user. Accordingly, at least one position-related constraint is defined, which is incorporated into the correspondingly structured requirement data set 22.

[0072] Alternatively, time data profile B can be selected, according to which predetermined time data has the highest priority over other data types. For example, time data profile B can require that a date of initial availability be specified for each available product offered via a procurement data record. It can also be specified that procurement options older than a predetermined date are excluded from the procurement data record 28 in advance. In this way, the user can emphasize the timeliness of the available procurement options. This can be particularly useful if the user is already well informed about the procurement options currently available and therefore does not need them.

[0073] Another selection option is image data profile C. This allows the user to give priority to image data for the procurement data record 28 to be generated. For example, the user can take a photo of a required product and / or an identification element attached to the product (such as a product number or a logo). The photo can be incorporated into the requirement data record 22 as part of the usage data 18 via the requirement rule 20. The product can then be detected by the procurement data instance 12 and / or the product data instance 14 using the image data. This ensures that the procurement data record 28 contains an available procurement for the detected product. The image data can also be formed by image sequences, i.e. video data. The image data profile C can then also be referred to as a video data profile. Furthermore, it is conceivable, as an alternative or in addition to image or video data, to use video data profiles.Video data acoustic signal data for the.

[0074] Data profile to describe the product acoustically.

[0075] Specification data profile D also provides the option of including a user-specified specification data type as a mandatory boundary condition in requirements data set 22. The specification data type can be defined, for example, in the form of a product category (such as a raw material) or a specific product (raw material XY). Accordingly, it is ensured that the subsequently provided procurement data set 28 contains coordinated procurement options that are offered to the user.

[0076] It should be understood that the selected data profile affects not only the requirement data record 22, but also the associated procurement data record 28. For example, it can be provided that the data type prioritized by the data profile is brought to the foreground when the procurement data record 28 is displayed on the terminal device by activating a corresponding display profile. For example, in the case of position data profile A, the positions of the various available procurements can be summarized in a map. The user thus receives a good overview of where the desired product can be procured. In the case of time data profile B, the procurement options can be sorted according to their timeliness.

[0077] In contrast to Fig. 1, the requirement data record 22 according to Fig. 2 is first transmitted to a provision instance 30, through which the requirement data record 22 and the procurement data record 28 are exchanged or mediated between the usage instance 10 and the procurement data instance 12. The provision instance 30 can be viewed as a further instance for implementing the procurement data control alongside the procurement data instance 12.

[0078] The provision instance 30 is preferably formed by a separate, central server, which can be assigned to the procurement data instance 12. However, it is also possible to integrate the functions into the procurement data instance 12, for example, by implementing the functions of the provision instance 30 and the procurement data instance 12 through a single server. Alternatively, it is conceivable to dispense with the provision instance 30, as indicated in Fig. 1.

[0079] The provisioning instance 30 generates a first request and mediation data record 34 and a first provisioning data record 58 using a provisioning rule 32.

[0080] The first request and mediation data record 34 is expanded compared to the request data record 22 to include information relevant for the generation and provision of the procurement data record 28. For example, in the case of multiple provision instances 30 and procurement data instances 12, it can be determined to which procurement data instance 12 the data record 34 must be transmitted and to which provision instance 30 the procurement data to be generated must be transmitted. Such mediation data generally serves the coordinated generation and provision of procurement data records. For example, it can be avoided that multiple redundant procurement data records 28 are generated and provided in response to a request data record 22. Furthermore, the provision instance 30 can check whether the procurement data record 28 is valid and may be provided to the usage instance 10.The first provision data record 58 represents data-related aspects related to the provision and form of the procurement data record 28. For example, the data type specified according to the selected data profile A, B, C, or D can be included in the first provision data record 58 and transmitted directly to the procurement data instance 12. Other data can also be derived from the requirement data record 22 and transmitted to the procurement data instance 12 as "procurement data parameters" independently of the first requirement and mediation data record 34. This enables, among other things, accelerated generation and provision of the procurement data record 28.

[0081] Within the procurement data instance 12, the first request and mediation data record 34 is processed using a mediation rule 36. Predefined mediation data is used to check whether further processing is possible and whether a suitable procurement data record 28 can be generated. If applicable, a second request and mediation data record 38 is generated, which is subsequently processed using a procurement data rule 40.

[0082] Procurement data rule 40 is adapted to maximize the match between the desired procurement of a product and the available procurement of the product. Rule 40 can use a machine-learned model, e.g., a neural network, for this purpose.

[0083] Procurement Data Rule 40 cooperates with a

[0084] Authorization data rule 48, which is within the procurement data instance

[0085] 12 represents a third pillar for enforcing user-driven procurement data control and is implemented together with Procurement Data Rule 40 through a machine-learned model.

[0086] The authorization data rule 40 is adapted to ensure the provision of the generated procurement data according to the request data record 22. For example, inappropriate or invalid procurement data records can be excluded from forwarding to the provisioning instance 30. Furthermore, the authorization of the provisioning instance 30 to receive a procurement data record can be checked.

[0087] Using the procurement data rule 40 and the authorization data rule 48, a first procurement and brokerage data record 54 is generated. The data processing circles involved are described in more detail below.

[0088] The procurement data rule 40 comprises a query to a procurement database 42 in which a plurality of predetermined procurement data records are stored. If it is determined that a suitable procurement data record is available, it is read from the procurement database 42 and used as the basis for generating the first procurement and brokerage data record 54. If no suitable procurement data record is available, a second requirement data record 44 is generated and transmitted to the product data instance 14.

[0089] The second requirement data record 44 contains, in particular, the data from the first requirement data record 22, e.g., in the form of specification data and position data for a product to be procured. Based on the second requirement data record 44, the product data instance 14 generates a specification data record 46 that describes a procurable product and is transmitted to the procurement data instance 12. The specification data record 46 can be considered part of a product data record 26 (see Fig. 1).

[0090] The specification data record 46 is used by the procurement data rule 40 to generate a procurement data record that forms part of the first procurement and brokerage data record 54. The procurement data rule 40 also takes into account an availability data record 52 and a second provision data record 50, as described further below.

[0091] The second provision data record 50 is transmitted to the product data instance 50 depending on the authorization rule 48 to determine whether the required provision data is available for generating the procurement data record. In response to receiving the provision data record 50, the product data instance 14 transmits an availability data record 52 to the procurement data instance 12. The availability data record 52 provides information about one or more available procurement options that are a prerequisite for generating a suitable procurement data record. Furthermore, the availability data record 52 indicates whether the specifications of the provision data record 50 can be met and whether the procurement data record can be generated and provided accordingly.

[0092] The first procurement and brokerage data record 54 is further processed using brokerage rule 36 and, after checking the brokerage requirements, is converted into a second procurement and brokerage data record 60, which is transmitted to brokerage instance 30. Using provision rule 32, it is then checked whether the requirements for providing procurement data record 28 are met. If applicable, the brokerage information is removed from data record 60, and the resulting procurement data record 28 is transmitted to usage instance 10. Procurement data record 28 is hereby provided to the terminal device.

[0093] The prerequisites for provision can, for example, consist in meeting a provision time required by the request data record 22 and / or demonstrating that the procurement data record 28 is assigned to the request data record 22. The data required for this purpose can be contained, at least in part, as brokering information in the procurement and brokering data record 60, e.g., in the form of validity and / or authentication data. However, this information is not transmitted to the usage instance 10. The amount of data provided there is therefore limited to the data requested exclusively. The transmission bandwidth requirement is correspondingly minimized. The procurement data record 28 is preferably encrypted before being transmitted to the usage instance 10 to ensure the protection of the procurement data record 28.

[0094] It should be understood that the usage instance 10, the provisioning instance 30, the procurement data instance 12, and the product data instance 14 form a networked system for implementing user-controlled procurement data control. The instances 10, 12, 14, and 30 are interconnected via electronic communication links. The connection between the usage instance 10 and the provisioning instance 30 is preferably wireless. This is particularly useful for mobile devices. The connections between the instances 30, 12, and 14 are preferably wired to maximize transmission speed and data security.

[0095] With reference to Fig. 3, further aspects of user-controlled procurement data control are described below.

[0096] Data 15, 16, 18, and 19 are recorded on the terminal device E and transmitted as terminal data 17 to the central server S. The server S, like the terminal device E, is assigned to the user instance 10. However, they can be spatially separated and connected to each other via a wireless communication connection of a mobile network.

[0097] Server S is considered particularly trustworthy and secure with regard to data security. Data 17 can optionally be encrypted before transmission to best prevent data misuse.

[0098] In one embodiment, the generated request data record 22 can first be transmitted to the terminal E and from there forwarded to the external instances 30 and 12. The user retains direct control over the forwarding of the request data record 22. Alternatively, the request data record can be sent directly from the server S to the external instances 30 and 12. This case is indicated in Fig. 3 by the reference symbol 22'. In this case, the forwarding can also be controlled by the user by transmitting a corresponding release from the terminal E to the server S via the input data 15. LIST OF REFERENCE SYMBOLS

[0099] 10 Usage instance

[0100] 12 Procurement data instance

[0101] 14 Product data instance

[0102] 15 Input data

[0103] 16 User data

[0104] 17 Device data

[0105] 18 Usage data

[0106] 19 Previous procurement data

[0107] 20 requirement rule

[0108] 22 First requirement record

[0109] 22' First request record

[0110] 24 Request and provision record

[0111] 26 Product data record

[0112] 28 Procurement data record

[0113] 30 Deployment instance

[0114] 32 Deployment rule

[0115] 34 First request and placement data record

[0116] 36 Mediation rule

[0117] 38 Second request and mediation data record

[0118] 40 Procurement data rule

[0119] 42 Procurement database

[0120] 44 Second request record

[0121] 46 Specification data record

[0122] 48 Authorization rule

[0123] 50 Second provisioning record

[0124] 52 Availability record

[0125] 54 First procurement and brokerage data set

[0126] 58 First provisioning record

[0127] 60 Second procurement and brokerage data set A Position data profile

[0128] B Time data profile

[0129] C Image data profile

[0130] D Specification data profile E End device

[0131] S Central Server

Claims

PATENT CLAIMS 1 . A method for user-controlled procurement data control on a terminal device, comprising: - capturing user data (16, 18, 19) on the terminal (E), wherein the user data represents a user and / or a use of the terminal (E); - generating a request data record (22) on the basis of the user data (16, 18, 19) in dependence on a request rule (20) predeterminable by the user, wherein the request data record (22) represents a procurement of at least one product desired by the user; and - generating a procurement data record (28) on the basis of the requirement data record (22), wherein the procurement data record (28) represents at least one available procurement of the at least one product.

2. The method according to claim 1, wherein the request rule (20) is modifiable by the user and preferably comprises a selective filtering of the user data (16, 18, 19), and wherein the request rule (20) comprises a machine learning model.

3. The method according to claim 1 or 2, wherein the user data (16, 18, 19) is captured on the terminal (E) using a progressive web app and / or an operating system of the terminal (E) and is transmitted from the terminal (E) to a central server (S), and wherein the request data record (22) is generated on the central server (S).

4. Method according to at least one of the preceding claims, wherein the request rule (20) provides that the generation of the request data record (22) takes place as a function of an active input (15) of the user at the terminal (E), and wherein the input preferably comprises authentication data of the user.

5. The method according to at least one of the preceding claims, wherein the generation of the procurement data record (22) and / or provision thereof to the terminal (E) occurs depending on validity data representing a time-limited validity of the request data record (22); and / or wherein the request data record (22) is generated in a non-storable data format and is preferably non-modifiable.

6. Method according to at least one of the preceding claims, wherein the request data record (22) is provided in encrypted form to at least one central server (12, 14, 30).

7. Method according to at least one of the preceding claims, wherein the acquisition data record (28) is provided to the terminal (E) in dependence on authorization data.

8. Method according to at least one of the preceding claims, wherein the request data record (22) and / or the procurement data record (28) is generated as a function of at least one data profile (A, B, C, D) which can be selectively activated and / or modified by the user, in particular wherein the data profile is selected from a number of predetermined data profiles (A, B, C, D).

9. The method according to claim 8, wherein the data profile (A, B, C, D) defines a priority for a predetermined lead data type of the request data record (22) and / or the procurement data record (28), wherein the lead data type represents an aspect of the desired and / or available procurement prioritized for the user and is formed by one of the following data types: - Position data; - Time data; - Image, video and / or audio data; - Specification data.

10. Method according to at least one of the preceding claims, wherein the user data (16, 18, 19) and / or the request data record (22) comprise at least one of the following data types and represent at least one aspect of the desired procurement: - Position data, in particular concerning an area of ​​a desired delivery; - Time data; - Image, video and / or audio data; - procurement data previously provided on the terminal device; - Specification data.

11. Method according to at least one of the preceding claims, wherein the procurement data record (28) comprises at least one of the following data types and represents at least one aspect of the available procurement: - Position data, in particular concerning an area of ​​an available delivery; - Time data; - Image, video and / or audio data; - Specification data; - Delivery details.

12. The method according to any one of the preceding claims, wherein the procurement data record (28) is generated in dependence on a predetermined procurement data rule (36, 40, 48) adapted to optimize a match between the desired procurement and an available procurement on the basis of the requirement data record (22) and a product data record (26, 46, 52), and wherein the product data record (26, 46, 52) represents at least one available product.

13. The method according to any one of the preceding claims, wherein the procurement data record (28, 54, 60) is generated on the basis of a plurality of predetermined procurement data records stored in a database (42).

14. A method for generating a request data record (22) for user-controlled procurement data control on a terminal device (18), comprising: - capturing user data (16, 18, 19) on the terminal (E), wherein the user data (16, 18, 19) represent a user and / or a use of the terminal (E); and - generating a request data record (22) on the basis of the user data (16, 18, 19) depending on a request rule (20) that can be predefined by the user, wherein the request data record (22) represents a procurement of at least one product desired by the user; in particular wherein the request data record (22) Forms the basis for generating a procurement data record (28) that represents at least one available procurement of the at least one product; in particular, wherein the step of capturing the user data (16, 18, 19) is carried out on the terminal (E) and the step of generating the request data record (22) is carried out on a central server (S).

15. The method according to claim 14, wherein the request rule (20) is modifiable by the user and preferably comprises a selective filtering of the user data (16, 18, 19), and wherein the request rule (20) comprises a machine learning model.

16. The method according to claim 14 or 15, wherein the user data (16, 18, 19) are captured on the terminal (E) using a progressive web app and / or an operating system of the terminal (E) and are transmitted from the terminal (E) to the central server (S), and wherein the request data record (22) is generated on the central server (S).

17. Method according to at least one of claims 14 to 16, wherein the request rule (20) provides that the generation of the request data record (22) takes place as a function of an active input (15) of the user at the terminal (E), and wherein the input preferably comprises authentication data of the user.

18. Method according to at least one of claims 14 to 17, wherein the request data record (22) is generated in dependence on at least one data profile (A, B, C, D) which is can be selectively activated and / or modified by the user, in particular wherein the data profile is selected from a number of predetermined data profiles (A, B, C, D).

19. Method for generating a procurement data record (28) for user-controlled procurement data control with a terminal device (E), comprising at least the following steps: - Receiving a request data record (22) generated on the basis of user data (16, 18, 19) in dependence on a request rule (20) predeterminable by the user, wherein the request data record (22) represents a procurement of at least one product desired by the user, and wherein the user data (16, 18, 19) represent a user and / or a use of the terminal device (E); and - Generating a procurement data record (28) based on the request data record (22), wherein the procurement data record (28) represents at least one available procurement of the at least one product; in particular, wherein the method is executed on at least one central server (12, 30).

20. The method according to claim 19, wherein the procurement data record (28) is generated as a function of at least one data profile (A, B, C, D) contained in the request data record (22).

21. Method for generating a product data record (14) for user-controlled procurement data control with a terminal device (E), comprising at least the following steps: - receiving a request data record (22, 24, 44) which is generated on the basis of user data (16, 18, 19) in dependence on a is generated by a user-determinable request rule (20), wherein the request data record (22, 24, 22) represents a procurement of at least one product desired by the user, and wherein the user data (16, 18, 19) represents a user and / or a use of the terminal device; and - generating a product data record (26, 46, 52) on the basis of the request data record (22, 24, 22), wherein the product data record (26, 46, 52) represents at least one available product, in particular wherein the product data record (26, 46, 52) forms a basis for generating a procurement data record (28, 54, 60) on the basis of the request data record (22, 24, 22), and wherein the procurement data record (28, 54, 60) represents at least one available procurement of the at least one available product; in particular wherein the method is carried out on a central server (14).

22. A computer program for user-controlled procurement data control, comprising instructions which, when executed by a computer, cause the computer to carry out the steps of a method according to any one of the preceding claims.

23. Device for user-controlled procurement data control, wherein the device (10, 12, 14, 30) is connected to at least one data processing means and a non-volatile memory in which at least one computer program is stored, wherein the computer program comprises instructions which, when executed by the at least one data processing means causing it to carry out the steps of a method according to one of claims 1 to 21.

Images