Bill aggregation and payment management system

Abstract

A system for bill aggregation and payment management that facilitates secure communication between users and service providers. The system comprises a bill aggregation server in communication with multiple service provider servers over a wide area network. It registers user and service provider profiles, allowing service providers to search for user profiles using public identifiers. Upon verification, the system transmits bill data to the user's electronic device, where it is displayed and can be paid through a user interface. The system uses encryption techniques for secure transmission of private data, supports manual and automatic payment processing, and provides notifications for new bills and upcoming due dates. It also includes features for automatic archiving of paid bills, shared logins for multiple users, and analysis of bill data to suggest alternative service providers.

Description

Bill Aggregation and Payment Management SystemField of the Invention

[0001] The present invention relates to systems and methods for managing, aggregating, and processing bill payments. More specifically, the invention relates to a bill aggregation and payment system that facilitates secure communication between users and service providers, enabling the electronic delivery, storage, and payment of bills through a unified platform.Background of the Invention

[0002] Managing and paying bills can often be a fragmented and inefficient process for both consumers and service providers. Traditional methods of receiving bills via physical mail or email can lead to issues such as misplacement, delays, or a lack of organisation. Consumers may struggle to keep track of multiple bills from different service providers, each with its own payment system, which can result in missed payments or late fees. Service providers, on the other hand, face challenges in ensuring timely delivery of bills and receiving payments promptly.

[0003] Technological solutions such as electronic billing and online payment portals have been introduced, but these often require users to engage with multiple platforms, creating further inefficiencies. Additionally, the growing need for secure management of personal and financial data has brought challenges in protecting sensitive information during transactions between consumers and service providers.

[0004] There is a need for a more integrated and secure approach to managing, receiving, and paying bills, one that can streamline the process for users while ensuring data privacy and security. Improvements in communication technology and data encryption methods offer potential solutions for addressing these issues by creating a more seamless, centralised system for bill management.

[0005] It is to be understood that, if any prior art information is referred to herein, such reference does not constitute an admission that the information forms part of the common general knowledge in the art, in Australia or any other country.Summary of the Disclosure

[0006] The described bill aggregation and payment system facilitates the secure management, storage, and payment of bills for users and service providers. The system comprises a bill aggregation server that communicates with service provider servers over a wide area network. The system allows users to register user profiles, which include public and private data, and service providers can search for these user profiles using public identifiers. Upon verifying the connection between a registered user profile and a service provider profile, the system transmits bill data to the user’s electronic device, where the bills are displayed and can be paid through a user interface.

[0007] The system may further enable secure transmission of private data by employing encryption techniques, such as one-way hashing, to verify sensitive information without transmitting raw data. Additionally, the system supports the registration and management of payment credentials, allowing users to manually or automatically make payments before the bill’s due date. The system can send notifications, such as push notifications, to inform users of new bills or approaching due dates. Users may also search for and automatically link with service providers through the system.

[0008] According to one aspect, there is provided a bill aggregation and payment system comprising a server configured with controllers for registering user and service provider profiles, enabling secure linking based on public and private identifiers, receiving bill data from service providers, and presenting the data on a user interface of an electronic device. This arrangement provides a technical framework for centralising bill delivery and payment in a secure and verifiable manner.

[0009] In one embodiment, the registration controller may be adapted to store payment credentials in association with user profiles, while the user interface controller may initiate payment instructions using these credentials. By embedding the credentials within the system itself, payments can be processed without requiringrepeated entry by the user, thereby improving reliability and reducing the potential for input error.

[0010] Preferably, the system may further include a service provider search controller enabling the user interface to query registered service provider profiles. By allowing the linking of a user profile and a service provider profile through a controlled process , bills can be automatically directed to the correct user without manual input of account details.

[0011] In some configurations, the user profile identifier may comprise a communication endpoint such as an email address or a mobile number. This permits existing communication channels to be re-used for profile discovery, reducing integration complexity between service providers and the bill aggregation server.

[0012] It is also envisaged that the linking controller may be capable of verifying signatures generated with a private key of a service provider and validated using a corresponding public key. This provides an integrity check ensuring that only authenticated providers are able to transmit bill data to the system.

[0013] The bill receiving controller may be arranged to determine a due date from bill data and, in cooperation with a notification function, transmit an electronic communication prior to expiry. Where implemented as a push notification to the electronic device, this reduces the risk of late payment by alerting the user within the relevant time frame.

[0014] In certain embodiments, the server may execute a comparison function configured to analyse bill data from different service providers and identify alternatives. This technical capability supports user decision-making by enabling comparative analysis of billing information across providers.

[0015] According to another aspect, the system may apply a one-way hash algorithm to private identifiers, with service providers applying the same algorithm to their stored identifiers for verification. By comparing only hashed data, the system preserves confidentiality while still allowing reliable matching of user and provider records.

[0016] Payments may be either manually initiated or automatically triggered in advance of a due date based on predefined settings. This dual mode provides flexibility while ensuring that, in automatic mode, payments are consistently made on time.

[0017] In yet another embodiment, the server may generate notifications upon receipt of new bills and display them through the user interface of the electronic device. This ensures that the user is promptly made aware of new financial obligations.

[0018] Preferably, the system may support shared logins whereby multiple user profiles are linked to a single provider profile. This arrangement allows collaborative management of bills while maintaining consistent records across different devices.

[0019] In a further embodiment, once a payment has been processed, the system may automatically archive the bill into a retrievable store. This reduces data clutter while ensuring that a permanent record of transactions is maintained for audit or reference.

[0020] The system may also be configured to automatically update payment credentials across all linked provider profiles when a user’s payment method changes. This prevents the need for manual updates with individual providers, thereby streamlining ongoing use.

[0021] Additionally, the server may track and visualise spending trends over time through a dedicated analysis controller. This permits historical billing patterns to be reviewed and supports technical functions such as forecasting and anomaly detection.

[0022] According to another aspect, the server may incorporate a tokenisation service in conjunction with a hardware security module and key management service, ensuring that payment credentials are stored only in tokenised form. This prevents exposure of primary account numbers, improving security compliance.

[0023] In one preferable embodiment, private identifiers may be verified through hashed matching rather than raw transmission. This solution enhances privacy while allowing consistent record linking between user and provider.

[0024] In some embodiments, bill data is processed through a message queue supporting idempotency keys and sequence numbers. Such configuration ensuresexactly-once processing and consistent state despite asynchronous delivery from multiple providers.

[0025] The system may also record state transitions, such as bill receipt and payment events, in an immutable ledger implemented with hash chaining. This provides a tamper-evident log supporting secure audit trails and regulatory compliance.

[0026] Preferably, bill summaries may be retrieved from an in-memory cache updated from an event log. This reduces response latency on user devices while maintaining synchronisation with persistent storage.

[0027] In one configuration, a scheduler subsystem may generate due-date events and transmit notifications through a remote gateway. This ensures timely delivery of reminders and reduces missed deadlines.

[0028] It is further envisaged that cryptographic validation of provider signatures may be performed, thereby mitigating impersonation risks and ensuring that bill data originates from trusted sources.

[0029] According to another aspect, the native application on the user device may employ conflict-free replicated data types to queue and reconcile actions under intermittent connectivity. This provides consistent state management without data loss when network connections are unreliable.

[0030] Finally, in a further embodiment, per-record encryption of payment data may be applied using envelope keys resident only in a hardware security module, with key rotation handled by a key management service. This provides a segregation of duties and supports compliance with financial data protection standards.

[0031] Other aspects of the invention are also disclosed.Brief Description of the Drawings

[0032] Notwithstanding any other forms which may fall within the scope of the present invention, preferred embodiments of the disclosure will now be described, by way of example only, with reference to the accompanying drawings in which:

[0033] Figure 1 is a block-level system diagram illustrating the bill aggregation and payment system, including the bill aggregation server, service provider servers, and user electronic devices.

[0034] Figure 2 is a flow diagram illustrating an exemplary method of use for the bill aggregation and payment system, showing the steps involved in registering user profiles, searching for service providers, receiving bill data, and making payments.Description of Embodiments

[0035] The system 100 described herein is a bill aggregation and payment system 100 designed to streamline the management and payment of bills for users and service providers. As shown in Figure 1 , the system 100 comprises a bill aggregation server 101 that is in operable communication with a plurality of service provider servers 102 over a wide area network 103, such as the Internet. The bill aggregation server 101 executes a series of computer program code instruction controllers 104 that collectively provide the functionalities described below. The server 101 is equipped with a processor 115 that processes digital data 114 and communicates with a memory device 112 via a system bus 113. In use, the processor 115 retrieves and executes program instructions and associated data from the memory device 112, interpreting and executing the computer control functions required for the system's 100 operation.

[0036] The bill aggregation server 101 is configured for communication with user electronic devices 110, which may include mobile communication devices such as smartphones. These devices interact with the server via a software application that displays the user interface 108 on the device's digital display 109. The user interface 108 allows users to view and manage their bill data in a convenient and interactive manner.

[0037] The system 100 operates by enabling the registration of both user profiles 105 and service provider profiles 106. The registration controller 104A within the server is responsible for creating and maintaining these profiles. Each user profile 105 contains public and private data, where public data includes identifiers such as a user ID, and private data includes sensitive information like account numbers. A key feature of the system is the ability to protect private data while still allowing service providers to search for users via public identifiers.

[0038] For example, a service provider wishing to send a bill to a customer can search for the customer using public identifiers such as an email address, mobile number, or street address. This is achieved through the user profile search controller 104B, which exposes an API 107 to the service provider servers 102. The API 107 allows the service provider to search for a registered user profile 105 based on the user ID. Once a match is found, the linking controller 104C establishes a connection between the user profile 105 and the service provider profile 106. This process ensures that private user data remains secure, only being shared with the service provider once the connection is verified.

[0039] Verification of private data may be further enhanced by the use of encryption techniques. For instance, the private customer account number can be hashed using a one-way hash algorithm before being transmitted to the service provider. The service provider server 102, upon receiving the hash, applies the same hashing algorithm to its stored account number to determine if the two hashes match. This ensures that the user’s private information is never transmitted in an unencrypted form, providing a high level of security while allowing for the verification of the user profile.

[0040] Once the user profile 105 is linked to the service provider profile 106, the bill receiving controller 104D manages the reception of bill data from the service provider server 102. This bill data is stored and made available for display on the user’s electronic device 110 via the user interface controller 104E. The user can view their bills on the digital display 109 and make payments directly through the interface 108. Payment credentials, such as bank or credit card details, can be stored securely in relation to the user profile 105, and the user interface controller 104E allows the user to initiate payments either manually or automatically before the bill's due date. Payment processing is handled by the payment server 111 , which receives instructions from the bill aggregation server 101 to complete the transaction.

[0041] The system 100 may also supports a user’s addition of service providers. Using the service provider search controller 104F, a user can search for a service provider, such as their gas or electricity provider, and link their profile automatically. Oncelinked, future bills from that provider are sent directly to the user’s account within the system 100, eliminating the need for paper bills and manual input.

[0042] In another embodiment, the system 100 supports a variety of user profile IDs, including communication endpoint identifiers. These identifiers may take the form of email addresses or mobile phone numbers.

[0043] Additionally, the system 100 may use cryptographic techniques to enhance security. For example, the linking controller 104C can be configured to verify cryptographic signatures signed by the service provider server 102 using a private key. The verification is performed using the corresponding public key, ensuring the integrity of the communication between the bill aggregation server 101 and the service provider servers 102.

[0044] The system 100 may include advanced notification features to ensure users are always aware of upcoming bill payments. The bill receiving controller 104D analyses the bill data to determine when payments are due and, before the due date, the server 100 transmits an electronic communication, such as a push notification, to the user's electronic device 110.

[0045] The comparison controller 104G introduces additional functionality by allowing users to compare service providers. For instance, if a user receives a gas bill, the system 100 can analyse bill data from other gas providers and present the user with alternatives that may offer cheaper rates.

[0046] An exemplary method 200 of use for the system 100 is illustrated in Figure 2. Initially, the user registers a profile 105 through the registration controller 104A, where both public and private data are securely stored. This registration step enables the system to uniquely identify and manage the user’s billing information. Once the user profile is registered (Step 201), the user may then search for service providers using the service provider search controller 104F, which interfaces with the user interface 108 displayed on the electronic device 110 (Step 202). The system allows users to easily identify service providers by using public identifiers such as names or service categories.

[0047] Upon selecting a provider, the linking controller 104C is activated to establish a connection between the user profile 105 and the service provider profile 106 (Step 203). This connection links the user's billing information with the corresponding service provider, enabling future electronic transmission of bills.

[0048] For verification of private data, such as customer account numbers, the system uses a one-way hashing algorithm to enhance security. In this process, the private data is hashed before being transmitted to the service provider server 102. This ensures that the actual sensitive information is not exposed over the network. Once the hashed data is sent to the service provider server 102 (Step 204), the service provider applies the same one-way hashing algorithm to its stored private data, such as the customer’s account number, and compares the two hashes (Step 205). If the hashes match, the identity of the user profile is confirmed, and the verification is successful without the need for transmitting raw private data across the network.

[0049] After verification is complete, the service provider server 102 sends the bill data to the bill aggregation server 101 (Step 206). The bill data is then stored and displayed to the user through the user interface 108 on the electronic device 110 (Step 207). This display allows the user to easily review and manage the incoming bill.

[0050] The user has the option to manually pay the bill or schedule an automatic payment through the payment interface 108. During this process, the system 100 securely uses the stored payment credentials, such as credit card or bank account details, to facilitate the transaction (Step 208). If the bill remains unpaid and the due date is approaching, the system 100 sends a reminder via push notification to the user’s electronic device 110 (Step 209). This reminder helps ensure that the user is aware of impending deadlines and avoids potential late fees or service disruptions.

[0051] The system 100 may be configured for streamlined management of payment credentials, enabling users to add, change, or update stored payment details with ease. In this embodiment, the registration controller 104A and linking controller 104C are configured to manage this functionality in conjunction with the user interface controller 104E. A user may register payment credentials, such as bank account orcard details, within the system 100, similar to the process of configuring a digital wallet application. Once stored, these payment credentials are securely associated with the user profile 105 and may be utilised for initiating electronic payments via the payment server 111.

[0052] If the user’s payment method changes, for instance when a credit card expires or is replaced, the user can update the payment credentials directly through the user interface 108 displayed on the electronic device 110. The system 100 is configured to propagate the updated payment credentials across all linked service provider profiles 106 without requiring the user to individually contact each provider. This ensures that subsequent payments are processed using the new payment credentials automatically, with the user’s continued use of the updated credentials constituting consent to payment by that method.

[0053] By consolidating payment credential management within the system 100, the need for manual communication with service providers is eliminated, thereby significantly improving convenience for the user while maintaining a high level of security. The integration of the registration controller 104A, linking controller 104C, and user interface controller 104E ensures that any updates to payment credentials are synchronised across the system 100, providing a seamless and consistent billing experience for both users and service providers.

[0054] The system 100 may be further configured to simplify the management of bill notifications and payments through various automated processes. The system 100 may integrate a notification system within the bill receiving controller 104D, which alerts users upon the arrival of new bills. The notification system may employ sound or visual cues through the digital display 109 of the electronic device 110 to inform the user of pending bills. This functionality ensures users are promptly notified of new financial obligations, reducing the likelihood of missed payments. The notifications may be customisable, allowing users to adjust how and when they are notified, such as by receiving reminders at preset intervals before the bill due date.

[0055] Another technical aspect of the system 100 may relates to its support for partner logins and shared bill management. The system 100 may enable multipleusers, such as spouses or business partners, to access the same bill data through linked user profiles 105. This shared access ensures that all parties involved are aware of the status of each bill, and payments made by one user are reflected in the system for all linked users. The partner login feature, facilitated by the linking controller 104C, allows shared access to account information without the need to duplicate bill records or profiles, offering a seamless collaborative approach to bill management.

[0056] In one embodiment, the system 100 provides an archiving feature that automatically moves paid bills into a secure digital archive once the payment is processed. This archive, accessible via the user interface 108, offers a structured and searchable repository of historical bill data. Users can easily retrieve past bills for review or auditing purposes, with each archived bill indexed by service provider profile 106, bill type, payment status, and other relevant metadata. The archiving process eliminates the need for users to manually store or organize paper bills, providing a comprehensive digital solution for record-keeping.

[0057] Additionally, the system 100 may offers functionality for automatically updating payment credentials. For instance, if a user’s credit card expires or is replaced, the user can update their payment details once within the system 100, and the new credentials will be propagated to all linked service provider profiles 106. This feature, managed by the registration controller 104A and the linking controller 104C, eliminates the need for users to individually update each service provider, significantly streamlining the bill payment process.

[0058] The system 100 may also include a feature for tracking and visualising bill spending trends over time. Through the user interface 108, the system 100 provides graphical representations of monthly, quarterly, or yearly spending, allowing users to track their expenditures by service category, such as utilities, insurance, or telecommunications. This data is processed by the comparison controller 104G, which not only visualises the data but also helps users identify potential savings by comparing their current bills with other available service provider profiles 106. Thisspending analysis provides users with actionable insights, enabling them to make informed decisions regarding their financial obligations.

[0059] Technical advantages of the system 100 include its ability to securely manage sensitive user data while offering seamless communication between users and service providers. By using secure encryption techniques, the system 100 protects private information such as customer account numbers while still allowing for effective verification processes.

[0060] Technical advantages of the system 100 include its ability to securely manage sensitive user data while offering seamless communication between users and service providers. By using secure encryption techniques, the system 100 protects private information such as customer account numbers while still allowing for effective verification processes.

[0061] In preferable embodiments, the system 100 may further incorporate a number of additional technical features that solve technical problems that may be encountered in electronic bill delivery and payment management. For example, in one preferable embodiment, the system 100 employs a tokenisation service 121 together with a hardware security module 116 and key management service 117 to address the problem of exposing payment credentials across the wide area network 103. In this arrangement, primary account numbers are never transmitted or stored in cleartext, and only secure network tokens are processed by the controllers 104.

[0062] In another preferable embodiment, the system 100 addresses the problem of verifying links between a user profile 105 and a service provider profile 106 without disclosing raw identifiers. This is achieved by applying one-way hashing algorithms, such as SHA-256, or HMAC-based verification, so that matching can occur without revealing sensitive information.

[0063] To solve the problem of reliable ingestion of bill data from asynchronous service provider servers 102, the bill receiving controller 104D may process all incoming documents through a message queue 118, such as Apache Kafka or RabbitMQ, configured with idempotency keys and sequence numbers to guarantee exactly-once processing and consistent state.

[0064] In order to address the problem of repudiation or tampering with historical billing and payment records, the system 100 may also incorporate an immutable ledger 122. Each state transition is recorded as a hash-chained entry, thereby ensuring that any alteration of prior records is detectable and audit-ready.

[0065] To solve the problem of high latency when rendering bills on the electronic device 110, the user interface controller 104E may draw on an in-memory cache 124, such as Redis, which stores read-optimised bill summaries and payment status while applying strict cache invalidation rules derived from the event log 120.

[0066] In another optional embodiment, the system 100 tackles the technical challenge of delivering scalable reminders for upcoming bill due dates. The bill receiving controller 104D cooperates with a scheduler subsystem 131 to generate events that are delivered through push notification gateways, such as Firebase Cloud Messaging or Apple Push Notification Service, to the electronic device 110.

[0067] The system 100 may also be configured to permit shared logins in order to address the problem of multiple users requiring concurrent access to the same bills. This feature, implemented by the linking controller 104C, ensures that linked user profiles 105 can view and manage bill data associated with a service provider profile 106 without duplication or inconsistency.

[0068] To prevent malicious impersonation of service provider servers 102, the linking controller 104C may validate cryptographic signatures signed with a provider’s private key, such as using ECDSA or Ed25519, and verified with the corresponding public key. This ensures that only genuine service providers can transmit bill data.

[0069] In another optional embodiment, the native application on the electronic device 110 may include a synchronisation module configured with conflict-free replicated data types (CRDTs). This solves the problem of intermittent network connectivity by queuing user actions locally and reconciling them with the bill aggregation server 101 when the device reconnects.

[0070] Finally, to satisfy regulatory and audit requirements, the system 100 may apply per-record encryption of payment data with envelope keys stored exclusively in thehardware security module 116 and rotated by the key management service 117. This ensures security and auditability while enforcing segregation of duties.Exemplary system architecture

[0071] In an exemplary implementation, the bill aggregation server 101 is deployed as a distributed service cluster behind a load balancer 125, such as an AWS Elastic Load Balancer or an NGINX-based HAProxy cluster, and a reverse proxy 126 such as NGINX with integrated web application firewall 127 functionality provided by ModSecurity or AWS WAF. The instruction controllers 104A-104G execute as containerised microservices orchestrated by Kubernetes (application cluster 130) running on a cloud compute environment such as Amazon Elastic Kubernetes Service (EKS), Google Kubernetes Engine (GKE), or Microsoft Azure Kubernetes Service (AKS).

[0072] The processor 115 and memory device 112 may be exemplified by Intel Xeon or AMD EPYC processors with ECG DDR5 RAM. The transactional database 119 may be PostgreSQL or MySQL with ACID compliance, replicated using native streaming replication or cloud-native services such as Amazon RDS Multi-AZ or Google Cloud SQL. Time-series metrics are stored in Prometheus with Grafana dashboards (monitoring stack 135), and append-only audit logs are written into Apache Kafka (event log 120) or Amazon Kinesis.

[0073] Communications over the wide area network 103 are secured with TLS 1.3 enforced by OpenSSL or BoringSSL libraries, with elliptic-curve cryptography (e.g. ECDSA P-256 or Ed25519). The API 107 exposed by the user profile search controller 104B and linking controller 104C employs mutual TLS using certificates managed by HashiCorp Vault or AWS Certificate Manager. Payload signing may be implemented with JSON Web Signatures (JWS) via the JOSE standard libraries.

[0074] Payment credentials associated with the user profile 105 are tokenised by a tokenisation service 121 , such as Stripe’s Payment Intents API, Braintree Vault, or Adyen’s tokenisation platform. Cleartext credentials are stored only transiently within a hardware security module (HSM) 116, such as Thales nShield or AWS CloudHSM, or a key management service 117 such as AWS KMS or Google Cloud KMS, withAES-256-GCM encryption. User authentication secrets are hashed with Argon2id using libsodium or the PHC reference implementation.

[0075] The bill receiving controller 104D integrates with a durable message queue 118, such as Apache Kafka, RabbitMQ, or AWS SQS, enforcing idempotency through unique message keys. Normalised bill data is written into an immutable ledger 122 implemented using Hyperledger Fabric, Amazon QLDB, or a blockchain-based append-only datastore. The notification subsystem uses Firebase Cloud Messaging (FCM) or Apple Push Notification Service (APNS) to deliver reminders to user devices 110.

[0076] To optimise responsiveness, an in-memory cache 124 such as Redis or Memcached provides low-latency access to bill summaries and payment status. Analytical queries and spending visualisations by the comparison controller 104G are executed over a data warehouse 132 such as Snowflake, Amazon Redshift, or Google BigQuery. The service provider search controller 104F indexes provider data in an Elasticsearch or OpenSearch cluster (search index 133).

[0077] High availability is ensured by active-active deployment across cloud regions, using consensus mechanisms such as etcd or Consul for leader election within the application cluster 130. Snapshots of the database 119 and ledger 122 are encrypted and replicated to object storage 134, such as Amazon S3 with cross-region replication or Google Cloud Storage.

[0078] The electronic device 110 executes a native iOS or Android application. On iOS, the secure enclave 136 manages biometric authentication via Face ID / Touch ID and stores local device-bound keys, while on Android the equivalent Trusted Execution Environment (TEE) or Google Titan M chip may be used. The application synchronises with the bill aggregation server 101 through RESTful APIs or gRPC endpoints and leverages CRDT-based synchronisation libraries such as Automerge to handle offline state reconciliation.

[0079] Interoperability with service provider servers 102 is managed through canonical bill payloads defined with JSON Schema and enforced by a schema registry 138 such as Confluent Schema Registry. Large artefacts (e.g. PDF statements) arestored and served via pre-signed URLs from object storage 134 (e.g. Amazon S3 or Azure Blob Storage). Webhooks from service providers are authenticated using HMAC signatures and replay-protection nonces validated by the linking controller 104C before enqueueing messages into the message queue 118.

[0080] In the payment workflow, the user interface controller 104E constructs payment instructions referencing tokenised credentials and transmits authorisation requests to the payment server 111 , which may be an integration with PCI-DSS-compliant processors such as Stripe, Adyen, or PayPal. The results are recorded atomically in the transactional database 119 and ledger 122.Exemplary Use Case

[0081] By way of example only, consider a user operating the electronic device 110, in the form of a smartphone running the native application, to manage their electricity bill. Upon initial setup, the user registers a user profile 105 through the registration controller 104A. Public identifiers, such as the user’s email address, are stored together with private data including an electricity account number. Sensitive data is hashed locally on the electronic device 110 before transmission, ensuring that only hashed values are communicated to the bill aggregation server 101.

[0082] The service provider server 102 of the electricity company initiates a search through the API 107 exposed by the user profile search controller 104B. Using the supplied public identifier, the linking controller 104C identifies the correct user profile 105 and transmits the hashed account number for verification. The service provider server 102 applies the same hashing algorithm to its own record of the customer’s account number and confirms a match, thereby verifying the link between the user profile 105 and the service provider profile 106 without exposing raw identifiers.

[0083] Once verified, the service provider server 102 transmits bill data to the bill receiving controller 104D. This transmission passes through the message queue 118, where idempotency keys ensure that duplicated bills are ignored. The bill receiving controller 104D writes the validated bill data into the transactional database 119 and commits a corresponding event to the immutable ledger 122, ensuring the record is permanent and audit-ready.

[0084] The user interface controller 104E updates the user interface 108 on the digital display 109 of the electronic device 110 to show the new bill. To maintain responsiveness, a bill summary is simultaneously cached in the in-memory cache 124. A scheduler subsystem 131 calculates the due date and, using Firebase Cloud Messaging, issues a push notification three days before payment is required.

[0085] The user elects to pay immediately by selecting the bill on the user interface 108. The application retrieves tokenised card credentials from the tokenisation service 121 , where detokenisation is performed inside the hardware security module 116 using AES-256-GCM. The payment instruction is constructed by the user interface controller 104E and transmitted to the payment server 111 via a mutually authenticated TLS session. The payment server 111 processes the transaction through a PCI-DSS-compliant gateway (e.g. Stripe or Adyen) and returns an authorisation code.

[0086] Upon receipt of the authorisation, the bill aggregation server 101 records the successful payment in the transactional database 119 and appends a payment confirmation record to the immutable ledger 122. The user interface 108 immediately reflects the paid status, and the bill is automatically archived by the bill receiving controller 104D into the user’s digital archive for later retrieval.

[0087] If the user later replaces their credit card, they update the payment credentials once through the application. The registration controller 104A and linking controller 104C propagate the new credentials to all linked service provider profiles 106, ensuring that subsequent automatic payments proceed with the updated details without requiring any direct communication with the electricity company.

[0088] In this exemplary use case, the system 100 employs interaction of its components, including secure hashing, the message queue 118, the ledger 122, the tokenisation service 121 , the hardware security module 116, and the notification subsystems. These components cooperate to implement a technically defined method of bill aggregation and payment that ensures secure handling of sensitive data, reliable processing of bill data, and verifiable recording of payment transactions.

[0089] The foregoing description, for purposes of explanation, used specific nomenclature to provide a thorough understanding of the invention. However, it will be apparent to one skilled in the art that specific details are not required in order to practise the invention. Thus, the foregoing descriptions of specific embodiments of the invention are presented for purposes of illustration and description. They are not intended to be exhaustive or to limit the invention to the precise forms disclosed as obviously many modifications and variations are possible in view of the above teachings. The embodiments were chosen and described in order to best explain the principles of the invention and its practical applications, thereby enabling others skilled in the art to best utilize the invention and various embodiments with various modifications as are suited to the particular use contemplated. It is intended that the following claims and their equivalents define the scope of the invention.

Claims

Claims1. A bill aggregation and payment system comprising: a bill aggregation server in operable communication with a plurality of service provider servers over a wide area network, wherein the bill aggregation server executes computer program code instruction controllers comprising: a registration controller configured to register user profiles, each having public and private data, and register service provider profiles; a user profile search controller configured to expose an API to the service provider servers, the API being configured to allow the service provider servers to search for a registered user profile according to a user profile ID; a linking controller configured to record a connection between a registered user profile and a service provider profile and to transmit private data associated with the registered user profile to a service provider server for verification; a bill receiving controller configured to receive and store bill data associated with the connection from the service provider server; and a user interface controller configured to display the bill data on a user interface displayed by a digital display of an electronic device associated with the registered user profile authenticated with the bill aggregation server.

2. The system of claim 1 , wherein the registration controller is further configured to register payment credentials in relation to the user profiles, and wherein the user interface controller is further configured to receive a payment instruction and to initiate an electronic payment with a payment server using the payment credentials associated with the registered user profile.

3. The system of claim 1 , wherein the bill aggregation server further executes a service provider search controller configured to interface the user interface and allow searching for a registered service provider profile,and wherein the linking controller is configured to record a connection between the registered user profile and the service provider profile.

4. The system of claim 1 , wherein the user profile ID is a communication endpoint identifier.

5. The system of claim 4, wherein the communication endpoint identifier is at least one of an email address or a mobile phone number.

6. The system of claim 1 , wherein the linking controller is configured to verify cryptographic signatures signed by the service provider server with a private key using a public key associated with the service provider.

7. The system of claim 1 , wherein the bill receiving controller is configured to analyse the bill data to determine a due date, and wherein the server is further configured to transmit an electronic communication prior to the due date.

8. The system of claim 7, wherein the electronic communication is a push notification transmitted to the electronic device.

9. The system of claim 1 , wherein the bill aggregation server further executes a comparison controller configured to analyse the bill data, and wherein the comparison controller is further configured to select another service provider profile by analysing their respective bill data.

10. The system of claim 1 , wherein the private data associated with the registered user profile is encrypted using a one-way hash algorithm, and wherein the service provider server is configured to hash its copy of the private data using the one-way hash algorithm to verify a match.

11. The system of claim 2, wherein payments can be manually initiated by the user or automatically implemented before a bill due date based on predefined user settings.

12. The system of claim 1 , wherein the bill aggregation server further executes a notification controller configured to generate notifications when a new bill is received and display the notification via the user interface on the electronic device.

13. The system of claim 1 , wherein the system supports shared logins, allowing multiple user profiles linked to a single service provider profile to access and manage shared bill data.

14. The system of claim 1 , wherein the bill data is automatically archived in the system after payment is processed, and the archived bill data is retrievable through the user interface.

15. The system of claim 2, wherein the system is further configured to automatically update payment credentials across all registered service provider profiles when the payment credentials associated with a user profile are modified.

16. The system of claim 1 , wherein the bill aggregation server further executes a spending analysis controller configured to track and visualise bill spending trends over time via the user interface on the electronic device.

18. The system of claim 1 , wherein the server comprises a tokenisation service in communication with a hardware security module and a key management service, configured to store payment credentials only in tokenised form, thereby preventing transmission or storage of primary account numbers in cleartext.

19. The system of claim 1 , wherein the linking controller and the service provider servers are configured to verify private identifiers by applying a one-way hashing algorithm, such that matching occurs without transmitting the identifiers in raw form, thereby preserving confidentiality of private data.

20. The system of claim 1 , wherein the bill receiving controller processes incoming bill data through a message queue supporting idempotency keys and sequence numbers, thereby ensuring exactly-once processing and consistent system state notwithstanding asynchronous delivery from multiple service provider servers.

21. The system of claim 1 , wherein the server records state transitions relating to bill data and payment transactions in an immutable ledger comprising hash-chained entries, thereby ensuring tamper-evident storage and verifiable auditability of historical records.

22. The system of claim 1 , wherein the user interface controller retrieves bill summaries from an in-memory cache updated from an event log, thereby reducing display latency on the electronic device while maintaining consistency with stored bill data.

23. The system of claim 1 , wherein the server cooperates with a scheduler subsystem to generate due-date events and transmit push notifications through a remote notification gateway to the electronic device, thereby ensuring timely reminders of upcoming payment deadlines.

24. The system of claim 1 , wherein the linking controller validates cryptographic signatures generated with a private key of a service provider server using a corresponding public key, thereby authenticating the source of bill data and preventing malicious impersonation.

25. The system of claim 1 , wherein the application on the electronic device implements a synchronisation module using conflict-free replicated data types to queue updates locally and reconcile them with the server when network connectivity is restored, thereby preserving data consistency under intermittent connectivity.

26. The system of claim 1 , wherein the server applies per-record encryption of payment data with envelope keys stored exclusively in the hardware security module and rotated by the key management service, thereby ensuring compliance with audit requirements and enforcing segregation of duties.

27. A method of operating a bill aggregation and payment system, the method comprising: registering user profiles, each having public and private data, and registering service provider profiles; allowing a service provider server to search for a registered user profile via an API using a user profile ID; recording a connection between the registered user profile and a service provider profile; transmitting private data associated with the registered user profile to the service provider server for verification; receiving bill data from the service provider server; displaying the bill data on a user interface of an electronic device associated with the registered user profile; and initiating electronic payments using payment credentials associated with the user profile.

Images