SA517381730B1 - نظام، طريقة ومنتج برنامج كومبيوتر لتلقي الرسائل الالكترونية - Google Patents

نظام، طريقة ومنتج برنامج كومبيوتر لتلقي الرسائل الالكترونية Download PDF

Info

Publication number
SA517381730B1
SA517381730B1 SA517381730A SA517381730A SA517381730B1 SA 517381730 B1 SA517381730 B1 SA 517381730B1 SA 517381730 A SA517381730 A SA 517381730A SA 517381730 A SA517381730 A SA 517381730A SA 517381730 B1 SA517381730 B1 SA 517381730B1
Authority
SA
Saudi Arabia
Prior art keywords
transaction
message
switch
key
switches
Prior art date
Application number
SA517381730A
Other languages
English (en)
Inventor
ستيفين جورج جارليك
نيل انتونى ماستيرس
Original Assignee
اى بى سى او 2012 ليمتد
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Family has litigation
First worldwide family litigation filed litigation Critical https://patents.darts-ip.com/?family=54337808&utm_source=google_patent&utm_medium=platform_link&utm_campaign=public_patent_search&patent=SA517381730(B1) "Global patent litigation dataset” by Darts-ip is licensed under a Creative Commons Attribution 4.0 International License.
Application filed by اى بى سى او 2012 ليمتد filed Critical اى بى سى او 2012 ليمتد
Publication of SA517381730B1 publication Critical patent/SA517381730B1/ar

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • H04L67/1001Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1004Server selection for load balancing
    • H04L67/1023Server selection for load balancing based on a hash applied to IP addresses or costs
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/02Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • G06Q20/027Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP] involving a payment switch or gateway
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46Multiprogramming arrangements
    • G06F9/50Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/08Payment architectures
    • G06Q20/10Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/30Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/382Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3827Use of message hashing
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/385Payment protocols; Details thereof using an alias or single-use codes
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/12Avoiding congestion; Recovering from congestion
    • H04L47/125Avoiding congestion; Recovering from congestion by balancing the load, e.g. traffic engineering
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • H04L67/1001Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1036Load balancing of requests to servers for services different from user content provisioning, e.g. load balancing across domain name servers
    • GPHYSICS
    • G07CHECKING-DEVICES
    • G07FCOIN-FREED OR LIKE APPARATUS
    • G07F19/00Complete banking systems; Coded card-freed arrangements adapted for dispensing or receiving monies or the like and posting such transactions to existing accounts, e.g. automatic teller machines
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00Packet switching elements
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • H04L67/1001Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1034Reaction to server failures by a load balancer

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • Theoretical Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Finance (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Software Systems (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • General Engineering & Computer Science (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

يقدم الاختراع الحالي نظام (100) لتلقي الرسائل الالكترونية electronic messages من مؤسسة مالية، النظام (100) يتضمن مجموعة من مفاتيح مهيأة للاتصال ببعضها البعض ولمعالجة الرسائل الالكترونية المستلمة، حيث يتضمن كل مفتاح دارة معالجة processing circuitry مهيأة لاستلام رسالة إلكترونية تتضمن محدد فريد unique identifier و، بشكل يعتمد على المحدد الفريد، إما معالجة الرسالة الإلكترونية أو إعادة توجيه الرسالة الإلكترونية لواحد آخر من المفاتيح للمعالجة. شكل1

Description

نظام؛ طربقة ومنتج برنامج كومبيوتر لتلقي الرسائل الالكترونية ‎A SYSTEM, METHOD AND COMPUTER PROGRAM PRODUCT FOR‏ ‎RECEIVING ELECTRONIC MESSAGES‏ الوصف الكامل خلفية الاختراع يتعلق الاختراع الحالي بنظام»؛ طريقة ومنتج برنامج كومبيوتر ‎computer program product‏ لتلقي الرسائل الالكترونية ‎.electronic messages‏ يتعلق الاختراع الحالي بسطح بيني» طريقة ومنتج ‎malin‏ كومبيوتر للتحكم في نقل الرسائل الالكترونية. وصف "الخلفية التقنية' المقدم هنا خاص بغرض تقديم السياق العام للكشف. سوف يكون عمل المخترعين الحاليين؛ بالمقدار الموضح في جزءِ الخلفية التقنية؛ بالإضافة إلى جوائب الوصف التي لا التي يمكن ألا تكون مؤهلة كفن سابق وقت الإيداع؛ غير معبر عنه صراحة أو ضمنا كفن سابق في مقابل الاختراع الحالي. 0 تسمح الأنظمة البنكية الالكترونية ‎electronic banking systems‏ الحديثة ‎Jay‏ التمويلات إلكترونيا بين الحسابات البنكية ‎bank accounts‏ للبنوك المختلفة باستخدام رسالة طلب المعاملات الالكترونية ‎electronic transaction request messages‏ (رسائل معاملة ‎(transaction messages‏ . هذه الطريقة الخاصة بنقل التمويلات ‎funds‏ يتمتع بكل من الأمان (الاستفادة من العديد من بروتوكولات التأمين ‎security protocols‏ المعروفة التي تسمح بالنقل الأمن للبيانات عبر شبكة) والملائم (حيث تسمح ‎delat 5‏ الحساب البنكي ‎allay bank account‏ تقل التمويلات في أي وقت» 24 ساعة ‎(lug‏ 365 يوم بالسنة). مع ذلك؛ على الرغم من أن رسالة طلب المعاملات الالكترونية يمكن تنفذيها في أي وقت؛ يتم نقل التمويلات فقط بين البنوك على أساس دوري. وهذا معروف بنموذج "دورة التسوية ‎settlement‏ ‏عادر" أثناء كل دورة تسوية؛ يتم تلقي وتسجيل ‎Silay‏ المعاملة الصادرة بواسطة البنوك. بعد ذلك؛ 0 عند نهاية دورة التسوية؛ عادة ما يتم نقل التمويلات بين البنوك (هذا معروف ب "التسوية')؛ على أساس رسائل المعاملة المسجلة ‎recorded transaction messages‏ تبلغ المدة الزمنية بين دورات التسوية ‎settlement cycles‏ بشكل مثالي 8 أو 24 ساعة؛ على الرغم من امكانية استخدام أي مدة زمنية مناسبة.
بسبب التسوبة النهائية بين البنوك على رسائل المعاملة المسجلة المصنوعة أثناء دورة التسوية؛ من المهم أن يتم تخزين وإدارة رسائل المعاملة المسجلة بفاعلية؛ حتى؛ ‎Ole‏ في حالة فشل التقنية أو الكارثة الطبيعية. وهذا يضمن ‎(of‏ عند ‎Dlg‏ كل دورة تسوية؛ يتم اعتبار كل معاملة مكتملة ‎completed transaction‏ أثناء التسوية ويتم اعتبارها ‎Bye‏ واحدة فقط. وهذا يمنع أي عملية دفع زائد أو عملية دفع مخفض من المال الفعلي بين البنوك. بالتالي يهدف الاختراع الحالي إلى تخفيف على الأقل مشكلة توفير نظام مرن ‎flexible system‏ لتخزين تخزين والتحكم في رسائل المعاملات الالكترونية ‎electronic transaction messages‏ بشكل فعال. الوصف العام للاختراع يقدم الاختراع الحالي نظام لتلقي الرسائل الالكترونية من مؤسسة مالية؛ النظام يتضمن مجموعة 0 من مفاتيح ‎shen‏ للاتصال ببعضها البعض ولمعالجة الرسائل الالكترونية المستلمة؛ حيث يتضمن ‎JS‏ مفتاح دارة ‎processing circuitry dallas‏ مهيأة لاستلام رسالة إلكترونية ‎electronic message‏ تتضمن محدد فريد ‎unique identifier‏ وء؛ بشكل يعتمد على المحدد الفريد؛ ‎Lf‏ معالجة الرسالة الإلكترونية أو إعادة توجيه الرسالة الإلكترونية لواحد آخر من المفاتيح للمعالجة. بشكل ‎ce‏ تسمح هذه التجهيزة توزيع الرسائل الالكترونية بين المفاتيح التي سيتم التحكم فيهاء 5 بالتالي تسمح بحمل معالجة ‎processing load‏ يتم توزيعه بالتساوي و؛ في حالة فشل المفتاح؛ ‎Lay‏ ‏يسمح للرسائل المعاد تعيينها بشكل سريع إلى مفتاح مناسب. ثمة معاملات إلكترونية ‎electronic‏ ‎transactions‏ لتجهيزة للمعالجة ذات مرونة وفعالية أكبر والتي يتم تم تحقيقها بناء عليه. في أحد النماذج؛ يحدد المحدد الفريد بشكل فريد معاملة والتي ترتبط به الرسالة الإلكترونية. في أحد النماذج» تتم تهيئة دارة المعالجة لتنفيذ وظيفة عنونة على الرسالة الإلكترونية؛ وظيفة 0 العنونة ‎hashing function‏ باستخدام المحدد الفريد للرسالة الإلكترونية لتحديد المفتاح الخاص بمعالجة الرسالة الإلكترونية. في أحد النماذج؛ تتضمن مجموعة المفاتيح مجموعة أولى من مفاتيح موضوعة عند موضع أول ومتصلة بقاعدة بيانات ‎database‏ أولى ومجموعة ثانية من مفاتبح موضوعة عند موضع ثاني ومتصلة بقاعدة بيانات ثانية. 5 في أحد النماذج» في ‎Alla‏ أن مفتاح واحد من المجموعة الأولى من مفاتيح يتم إليها إعادة توجيه الرسالة الإلكترونية غير عاملة لمعالجة الرسالة الإلكترونية؛ المفتاح المستلم مهياً للقيام بأي من:
إعادة توجيه الرسالة الإلكترونية إلى مفتاح ثاني للمجموعة الأولى من مفاتيح للمعالجة للرسالة
الإلكترونية؛ أو معالجة الرسالة الإلكترونية.
في أحد النماذج» في حالة أنه لا يوجد مفتاح للمجموعة الأولى من مفاتيح يتم إليها إعادة ‎dng‏
الرسالة الإلكترونية عامل للمعالجة الرسالة الإلكترونية؛ المفتاح المستلم مهياً للقيام بأي من: ‎sale]‏ ‏5 توجيه الرسالة الإلكترونية إلى مفتاح من المجموعة الثانية من مفاتيح للمعالجة للرسالة الإلكترونية؛
أو معالجة الرسالة الإلكترونية.
يقدم الاختراع الحالي مفتاح لتلقي الرسائل الالكترونية من مؤسسة مالية يتضمن دارة معالجة مهيأة
لاستلام رسالة إلكترونية تتضمن محدد فريد و؛ بشكل يعتمد على المحدد الفريد؛ إما معالجة الرسالة
الإلكترونية أو إعادة توجيه الرسالة الإلكترونية إلى مفتاح آخر للمعالجة.
0 يقدم الاختراع الحالي طريقة لتلقي الرسائل الالكترونية من مؤسسة مالية في نظام يتضمن مجموعة من مفاتيح 1 ‎shige‏ للاتصال ببعضها البعض ولمعالجة الرسائل الالكترونية المستلمة؛ حيث تتضمن الطريقة الخطوات: استلام؛ عند مفتاح؛ رسالة إلكترونية تتضمن محدد فريد؛ و؛ بشكل يعتمد على المحدد الفريدء أي من معالجة الرسالة الإلكترونية أو إعادة توجيه الرسالة الإلكترونية لواحد آخر من المفاتيح للمعالجة.
في أحد النماذج؛ يحدد المحدد الفريد بشكل فريد معاملة والتي ترتبط به الرسالة الإلكترونية. في أحد النماذج» تتضمن الطريقة تنفيذ وظيفة عنونة على الرسالة الإلكترونية؛ وظيفة العنونة باستخدام المحدد الفريد للرسالة الإلكترونية لتحديد المفتاح الخاص بمعالجة الرسالة الإلكترونية. في أحد النماذج؛ تتضمن مجموعة المفاتيح مجموعة أولى من مفاتيح موضوعة عند موضع أول ومتصلة بقاعدة بيانات أولى ومجموعة ثانية من مفاتيح موضوعة عند موضع ثاني ومتصلة بقاعدة
‎able 20‏ ثانية. في أحد النماذج» في حالة أن مفتاح واحد من المجموعة الأولى من مفاتيح يتم إليها إعادة توجيه الرسالة الإلكترونية غير عاملة للمعالجة الرسالة الإلكترونية؛ تتضمن الطريقة أي من: إعادة توجيه الرسالة الإلكترونية المستلمة إلى مفتاح ثاني للمجموعة الأولى من مفاتيح للمعالجة للرسالة الإلكترونية؛ أو معالجة الرسالة الإلكترونية.
‏5 في أحد النماذج؛ في حالة أنه لا يوجد مفتاح للمجموعة الأولى من مفاتيح يتم إليها إعادة توجيه الرسالة الإلكترونية عامل لمعالجة الرسالة ‎(dg SY)‏ تتضمن الطريقة أي من: إعادة توجيه
الرسالة الإلكترونية المستلمة إلى مفتاح من المجموعة الثانية من مفاتيح للمعالجة للرسالة الإلكترونية؛ أو معالجة الرسالة الإلكترونية. يقدم الاختراع الحالي منتج برنامج كومبيوتر يتضمن تعليمات قابلة للقراءة بواسطة كومبيوتر والتي عند التحميل على مفتاح يقوم بتهيئة المفتاح لتنفيذ الطريقة المذكورة أعلاه وفقا للاختراع الحالي.
تم توفير الفقرات السابقة على سبيل التقديم العام؛ ولا يقصد بها تقييد منظور عناصر الحماية التالية. النماذج الموضحة؛ بالإضافة إلى ‎Lhe‏ أخرى؛ سوف يتم فهمها بشكل أفضل بواسطة الإشارة إلى الوصف التفصيلي التالي المرتبط بالأشكال المصاحبة. شرح مختصر للرسومات ثمة فهم كامل للكشف والعديد من المزايا الموجودة التي تم الحصول عليها بشكل أفضل بالرجوع
0 إلى الوصف التفصيلي التالي عند ارتباطها بالأشكال المصاحبة؛ حيث: الشكل 1 يبين العديد من مكونات نظام وفقا لأحد النماذج؛ الأشكال 2-ب تبين مخطط تدفق يبين العديد من خطوات المعالجة المستخدمة مع رسالة معاملة ‎transaction message‏ بواسطة ‎gia‏ تكوين تبادل ‎switch forming part‏ من النظام ؛» ‎Gy‏ لأحد النماذج؛ 5 الشكل 3ا يشرح مشكلة مرتبطة بتنفيذ غطاء ائتماني ‎debit cap‏ باستخدام النظام؛ ‎Jal‏ 3ب يشرح حل للمشكلة الموضحة بواسطة الشكل 3ا؛ وفقا لأحد النماذج؛ الشكل 4 يبين مخطط تدفق يبين العديد من خطوات المعالجة المستخدمة مع رسالة معاملة بواسطة النظام؛ وفقا لأحد النماذج؛ و الشكل 5 يبين كومبيوتر وفقا لأحد النماذج. 0 الوصف التفصيلي: بالإشارة الآن إلى الأشكال» حيث الأرقام المرجعية المتشابهة تصف أجزاء متطابقة أو متناظرة من العديد من المناظر. الشكل1 يبين لمحة عن نظام 100 وفقا لأحد النماذج. النظام تتضمن مجموعة من البنوك (في هذه الحالة؛ اثنين من ‎coll‏ البنك 1 والبنك 2) ومجموعة من مواقع المفتاح ‎switch sites‏ (في 5 هذه الحالة؛ ‎(uf‏ من مواقع المفتاح» موقع مفتاح ‎Switch Site‏ 1 وموقع مفتاح 2). كل بنك متصل ‎JS‏ من مواقع المفتاح عبر قناة اتصال ‎data communication channel «bly‏ (غير
مبيئة). بالمثل مواقع المفتاح متصلة ببعضها البعض عبر قناة اتصال بيانات (غير مبيئة). يمكن ‎Law‏ قناة اتصال البيانات عبر شبكة اتصال ‎data communication network «lly‏ مثل الانترنت. بالنسبة للمرونة المحسنة؛ يتم فصل مواقع المفتاح بحيث؛ في حالة مشكلة مثل الفشل التقني أو كارثة طبيعية عند موقع مفتاح واحد؛ يمكن استمرار المعالجة عند موقع المفتاح الآخر. مثلاء يمكن وضع مواقع المفتاح عند مواضع جغرافية مختلفة. تتضمن كل من البنوك تطبيق بنكي ‎banking application‏ 102 102« تطبيق بوابي ‎gateway application‏ 104 4ب (المشار إليه ببساطة أيضا ب ‎("Led‏ ووحدة صف رسالة ‎message queue unit‏ 106 6ب. يتضمن كل من مواقع المفتاح ‎Bang‏ صف رسالة ‎J108‏ ‏2108« مجموعة من مفاتيح (في هذه الحالة؛ اثنين من مفاتيح عند كل موقع؛ مفاتيح أس دبليو ‎SWy 1 587 | 0‏ 2 عند موقع مفتاح 1 ومفاتيح ‎SW‏ 3 و5177 4 عند موقع مفتاح 2)؛ قاعدة بيانات 0 )؛ 10ب ووحدة صف رسالة 1112 112ب. علاوة على ذلك؛ واحد من مواقع المفتاح (في هذه الحالة؛ موقع مفتاح 1) تتضمن وحدة مكتب خلفي ‎back office unit‏ 114. يتم وصف وظيفة كل من هذه المكونات بالتفصيل أدناه. تمت ملاحظة أن المكونات المناظرة للبنوك المناظرة أو مواقع المفتاح (المشار إليها بواسطة نفس العدد ولكن حرف مختلف - مثلاء قواعد بيانات ‎databases 5‏ 110 و110[ب في مواقع المفتاح 1 و2؛ على التوالي» وصفوف الرسائل ‎message‏ ‎queues‏ 1106 و106ب في البنوك 1 25 المتتالية) متطابقة وظيفيا. الشكل 1 يبين تدفق رسالة مثالية ‎Mis example message flow‏ بواسطة النظام 100 للسماح بتتفيذ معاملة بين الحسابات البنكية. في المثال المقدم في الشكل 1 يتم تنفيذ المعاملة الخاصة بالتمويلات من الحساب البنكي عند البنك 1 إلى حساب بنكي مختلف عند البنك 2. مع ذلك سوف يتم فهم أن النظام 100 يمكن استخدامه لتنفيذ المعاملة الخاصة بالتمويلات بين الحسابات البنكية المختلفة عند نفس البنك. علاوة على ذلك؛ بالطبع؛ يمكن أن يقوم البنك 2 بتوليد طلبات معاملة والتي تقوم بنقل التمويلات من حساب موضوع عند البنك 2 إلى حساب في البنك 1. يبدأ تدفق الرسالة لتنفيذ المعاملة بين البنك 1 والبنك 2 عندما يقوم حامل الحساب البنكي عند ‎la‏ 1 بإرسال تعليمات إلى البتك 1 لنقل التمويلات إلى الحساب البنكي المملوك عند البنك 2. 5 هذا يؤدي إلى توليد رسالة طلب المعاملة ‎transaction request message‏ (111). تتضمن رسالة طلب المعاملة معرف للبنك والحساب البنكي المعين الذي يتم منه نقل التمويلات ‎OL)‏ كود
تصنيف البنك ‎bank sort code‏ للبنك 1 ورقم الحساب)؛ معرف للبنك والحساب البنكي المعين الذي يتم إليه نقل التمويلات ‎lie)‏ كود تصنيف البنك للبنك 2 ورقم الحساب) والمبلغ وعملة المال الذي سيتم نقله. سوف تحتوي رسالة طلب المعاملة أيضا على معرف فربد والذي يحدد المعاملة بشكل فريد التي تتعلق بها رسالة طلب المعاملة ‎Oli)‏ رقم فريد؛ ترتيب فريد من الحروف؛ توليفة فريدة من الحروف والأرقام؛ أو ترتيب آخر). يتم توفير هذه المعلومات بواسطة التطبيق البنكي 1102. ‎(Sa‏ توفير التطبيق البنكي 1102 بواسطة البنك وبتم الوصول إليه بواسطة عميل باستخدام موقع إلكتروني ‎secure website (ye‏ أو تطبيق جوال ‎mobile application‏ مثل تطبيق مقدم على طرف جوال ‎Jue mobile terminal‏ أو كومبيوتر قرصي ‎tablet computer‏ تتم الإشارة إلى هذا
المعرف الفريد ب 'معرف المعاملة ‎"transaction identifier‏
0 يتم تمرير رسالة طلب المعاملة إلى وحدة صف الرسالة ‎(F106‏ حيث يتم تخزين رسالة طلب المعاملة بشكل مؤقت لحين إتاحة البوابة 1104 لمعالجة رسالة طلب المعاملة. تقوم وحدة صف الرسالة 106 بتخزين رسالة طلب المعاملة بالإضافة إلى أي رسائل أخرى يتم إرسالها إلى البوابة 4 في ترتيب صفي (بحيث يتم إرسال الرسالة المستلمة عند وقت مبكر إلى البوابة 1104 قبل رسالة مستلمة عند وقت سابق). تقوم البوابة 1104 بعد ذلك بجمع الرسالة عند ‎all‏ الأمامي
5 للصف عند الإتاحة. عند إتاحة البوابة 1104 لاستلام رسالة طلب المعاملة؛ تقوم وحدة صف الرسالة 1106 بتمرير رسالة طلب المعاملة إلى البوابة 104ا. تضمن البوابة 104ا أن تكون رسالة طلب المعاملة في صورة معيارية محددة سلفا للاستخدام مع النظام 100 ‎Sli)‏ الصورة المعيارية أيزو 150 2) وتقوم بإرسال الإشارة الرقمية لرسالة طلب المعاملة. تقوم البوابة 1104 أيضا بإضافة
0 معلومات توجيه إلى رسالة طلب المعاملة ‎Ole)‏ إلى مقدمة رسالة طلب المعاملة) لتحديد موقع المفتاح الذي يجب إليه إرسال رسالة طلب المعاملة. تم وصف عملية تشغيل البوابة 1104 بالمزيد من التفاصيل بعد ذلك. كما سيتضح فيما بعدء البوابة 1104 اختيارية إلى النظام ولكن يتم توفيرها في نماذج. في غياب البوابة 104 يجب أن تحتاج رسالة طلب المعاملة إلى أن يتم صياغتها بشكل صحيح ‎aig‏ تسجيلها باستخدام التطبيق البنكي 1102 بالإضافة إلى التوجيه الصحيح.
5 بمجرد فحص صيغة رسالة طلب المعاملة؛ تم إرسال إشارة رسالة طلب المعاملة رقميا وتتم إضافة معلومات توجيه إلى رسالة طلب المعاملة؛ يتم تمرير رسالة طلب المعاملة عودة إلى وحدة صف
الرسالة 1106 للتخزين المؤقت قبل الإرسال إلى وحدة صف الرسالة 108 108ب من واحد من مواقع المفتاح. مرة أخرى»؛ تقوم وحدة صف الرسالة 1106 بتخزين رسالة طلب المعاملة بالإضافة إلى أي رسائل أخرى يتم إرسالها إلى مواقع المفتاح في ترتيب صفي. يتم إرسال رسائل عند الجزء الأمامي للصف في وحدة صف الرسالة ‎T106‏ إلى أي من وحدة صف الرسالة 1108 لموقع المفتاح 1 أو وحدة صف الرسالة 108ب لموقع المفتاح 2 وفقا لمعلومات التوجيه في كل رسالة. سوف يتم توجيه بوابة كل بنك بشكل مثالي كل في رسالة تتابعية بشكل تبادلي بين الاثنين من مواقع المفتاح. بالتالي؛ مثلا؛ إذا كان سيتم إرسال الرسالة عند ‎gall‏ الأمامي من الصف في وحدة صف رسالة 6 إلى وحدة صف رسالة 1108( بعد ذلك سوف يتم إرسال الرسالة في الصف إلى وحدة صف الرسالة 108ب؛ بعد ذلك سوف يتم إرسال الرسالة إلى وحدة صف رسالة 108 وما إلى ذلك. في 0 هذه الحالة؛ سوف تتم رؤية أن رسالة طلب المعاملة يتم إرسالها إلى وحدة صف رسالة 108 لموقع مفتاح 1. يتم تخزين رسالة طلب المعاملة بشكل مؤقت في وحدة صف الرسالة 108 لحين ‎dali]‏ واحد من المفاتيح ‎SW‏ 1 و5177 2 لمعالجة رسالة طلب المعاملة. مرة أخرى» تقوم وحدة صف الرسالة 108 بتخزين رسالة طلب المعاملة بالإضافة إلى أي رسائل أخرى يتم إرسالها إلى المفاتيح ‎SW‏ 1 أو ‎SW 5‏ 2 في ترتيب صفيء بحيث يتم إرسال الرسالة عند الجزء الأمامي إلى أي واحد من المفاتيح ‎SW 1 SW‏ 2 المتاحة أولا. تمت ملاحظة أن صفوف رسائل الجانب البنكي ‎bank-side‏ ‎message queues‏ 106 6ب وصفوف رسائل جانب النظام ‎system-side message queues‏ 7108( 108ب يمكن تنفيذها باستخدام نظام مثل نظام قائمة انتظار الرسائل للمؤسسة الدولية للحاسبات الآلية ‎International Business Machines Corporation - Message‏ ‎.IBM © MQ queue 20‏ في هذه الحالة؛ يتم إرسال رسالة طلب المعاملة إلى المفتاح ‎SW‏ 1. يقوم المفتاح ‎SW‏ 1 بعد ذلك باستخدام وظيفة عنونة إلى رسالة طلب المعاملة. وظيفة العنونة عبارة عن وظيفة معرف المعاملة لرسالة طلب المعاملة ولعدد من المفاتيح المتاحة لكل المواقع (بالتالي» أربيعة مفاتيح في هذا النموذج)» ومخرج وظيفة العنونة عبارة عن عدد يحدد المفتاح الذي يتم استخدامه لمعالجة رسالة 5 طلب المعاملة ‎lie)‏ العدد 1 2 3 أو 4 للمفاتيح ‎SW 2 SW 1 SW‏ 3 أو ‎SW‏ 4 على التوالي). يمكن أن يكون المفتاح المحدد بواسطة وظيفة العنونة هو نفس المفتاح الذي يتم إليه
إرسال رسالة طلب المعاملة أصلا بواسطة وحدة صف الرسالة 1108 ‎«gf‏ بشكل بديل؛ قد يكون عبارة عن مفتاح مختلف. إذا كان المفتاح المحدد بواسطة وظيفة العنونة ‎Ble‏ عن مفتاح مختلف؛ بعد ذلك يقوم مفتاح مستلم الأصلي ‎original receiving switch‏ (المفتاح ‎SW‏ 1 في هذه الحالة) بتمرير رسالة طلب المعاملة إلى المفتاح المحدد بواسطة وظيفة العنونة. في النموذج وفقا للشكل ‎cl 5‏ مع ذلك؛ المفتاح المحدد بواسطة وظيفة العنونة هو نفس المفتاح الذي يتم عنده استلام رسالة طلب المعاملة ‎Dial‏ (ذلك هوء المفتاح ‎SW‏ 1)؛ وبالتالي لا يتم نقل الرسالة إلى مفتاح مختلف. تم
وصف لوغاريتم العنونة ‎hashing algorithm‏ بالمزيد من التفاصيل بعد ذلك. بعد تلقي رسالة طلب المعاملة بواسطة المفتاح 517 1؛ يتم تسجيل حالة المعاملة التي تتعلق بها رسالة طلب المعاملة في قاعدة بيانات 110 في هذه الحالة؛ سوف تقوم قاعدة البيانات 110أ
0 بتسجيل أن المعاملة لا تزال معلقة وأن هناك رسالة واحدة (رسالة طلب المعاملة) من أصل ثلاثة رسائل مطلوية للمعاملة المطلوب إكمالها قد تم تلقيها أو بثها بواسطة المفتاح ‎SW‏ 1 (هذه الرسائل الثلاثة عبارة عن رسائل رسالة طلب المعاملة؛ رسالة معلومات المعاملة ‎transaction information‏ ‎«(M2) message‏ و رسالة تأكيد معاملة أولى ‎(M3) first transaction confirmation message‏ - انظر أدناه).
قاعدة البيانات 1110 عبارة عن قاعدة بيانات مجمعة ‎clustered database‏ تم توليدها على أساس البيانات المخزنة في كل من وحدات التخزين ‎storage units‏ 1109 و109ب. يمكن تنفيذ قاعدة البيانات 1110 مثل قاعدة بيانات منسياء مثلا. تقوم المفاتيح ‎SW 1 SW‏ 2 بجعل حالة المعاملة لكل معاملة معالجة بواسطة هذه المفاتيح يتم تسجيلها وتحديثها في قاعدة البيانات 1110 (تم تحديد ذلك بواسطة السهم تي يو ‎TU‏ في الشكل 1). يتم الحفاظ على وحدات التخزين 109 2109 في
تزامن مع بعضها البعض بحيث يتم تسجيل وتحديث حالة كل معاملة في كل من وحدة التخزين ‎storage unit‏ 1109 ووحدة التخزين 109ب. بالتالي تحتوي وحدات التخزين 9)؛ 109ب على نسخ متطابقة من نفس بيانات؛ ويمكن الحصول على كل حالة معاملة في قاعدة البيانات 110 بالتالي من أي وحدة تخزين 109 أو وحدة تخزين 109ب. بشكل مفيد؛ هذا يعين حالات المعاملة في قاعدة البيانات 1110 لا تزال يمكن الوصول إليها ‎Laie‏ تصبح واحد من وحدات التخزين
5 109 109ب تصبح غير عاملة (بسبب ‎lad‏ أو صيانة مخطط لها أو ما شابه).
تتضمن قاعدة البيانات 110ب ضبط مطابق لذلك الخاص بقاعدة البيانات 110؛ في أن قاعدة البيانات 110ب عبارة عن قاعدة بيانات مجمعة تم توليدها على أساس البيانات المخزنة في كل من وحدات التخزين 109ج؛ 109د. تؤدي المفاتيح ‎SW‏ 3؛ ‎SW‏ 4 إلى تسجيل وتحديث ‎Als‏ ‏المعاملة لكل معاملة معالجة بواسطة هذه المفاتيح في قاعدة البيانات 110ب. يتم الحفاظ على وحدات التخزين 109ج؛ 109د في تزامن مع بعضها البعض بحيث يتم تسجيل وتحديث كل ‎Als‏ ‏معاملة في كل وحدة تخزين 109ج ووحدة تخزين 109د. بالتالي تحتوي وحدات التخزين 109ج؛ 2109 على نسخ متطابق من نفس البيانات؛ ويمكن الحصول على كل ‎Alla‏ معاملة في قاعدة البيانات 110ب بالتالي من أي من وحدة تخزين 109ج أو وحدة تخزين 109د. بمجرد تسجيل حالة المعاملة في قاعدة البيانات 1110 بعد استلام رسالة طلب المعاملة بواسطة 0 المفتاح ‎SW‏ 1 يقوم المفتاح ‎SW‏ 1 بتوليد رسالة معلومات المعاملة. رسالة معلومات المعاملة خاصة بإخطار البنك سواء لاستلام تمويلات المعاملة ‎transaction funds‏ (وهوء البنك 2( الخاصة بالمعاملة. يتم أيضا عمل إخطار باستلام البنك للحساب البنكي المعين وهو استلام التمويلات والمبلغ وعملة المال الذي سيتم استلامه. بالتالي؛ ‎Jie‏ رسالة طلب المعاملة؛ تتضمن رسالة معلومات المعاملة معرف للبنك والحساب البنكي المعين الذي يتم ‎ad]‏ نقل التمويلات ‎lie)‏ كود 5 تصنيف البنك للبنك 2 ورقم الحساب) والمبلغ وعملة المال الذي سيتم نقله. تتضمن رسالة معلومات المعاملة ‎Load‏ نفس معرف المعاملة ‎Jie transaction identifier‏ رسالة معلومات المعاملة (لأن رسالة طلب المعاملة و رسالة معلومات المعاملة مرتبطتين بنفس المعاملة). يمكن أن تتضمن رسالة معلومات المعاملة أيضا معرف للبنك والحساب البنكي المعين الذي يتم منه إرسال التمويلات (مثلاء كود تصنيف البنك للبنك 1 ورقم الحساب)؛ للسماح لحامل الحساب 0 باستلام الحساب البنكي لمعروفة هوية المرسل. بمجرد ‎laa)‏ رسالة معلومات المعاملة؛ يتم إرسالها إلى البنك 2 عبر وحدة صف الرسائل 108 و106ب والبوابة 104ب. تتطابق وحدة صف الرسالة 106ب والبوابة 104ب للبنك 2 وظيفيا مع وحدة صف الرسالة 1106 ‎dss‏ 1104 للبنك 1. ‎(Jal‏ يتم تخزين رسالة معلومات المعاملة بشكل مؤقت وتصطف في وحدة صف الرسالة 1108. بعد ذلك يتم إرسالها عبر قناة اتصال 5 اليانات إلى وحدة صف الرسالة 106ب (على أساس معرف البنك 2 في رسالة معلومات المعاملة)» حيث يتم تخزبنه بشكل مؤقت أيضا وبتم صفه لحين إتاحة البوابة 104ب لاستلامه.
بمجرد الاستلام بواسطة البوابة 104ب؛ يتم التحقق من رسالة معلومات المعاملة (باستخدام توقيع إلكتروني ‎digital signature‏ مولد بواسطة المفتاح). بعد ذلك يتم التمرير عودة إلى وحدة صف الرسالة 106ب؛ حيث يتم التخزين بشكل مؤقت ويتم الصف قبل التمرير إلى التطبيق البنكي 2ب للبنك 2. بالتالي؛ يتم إخطار البنك 2 بالمعاملة والحساب البنكي المعين الذي يستلم تمويلات المعاملة. يمكن بالتالي إضافة إلى الحساب البنكي المعين تمويلات المعاملة؛ حتى إذا تم للم التسوية بين البنك 1 والبنك 2. بعد إرسال رسالة معلومات المعاملة إلى البنك 2؛ يتم تحديث حالة المعاملة في قاعدة البيانات 0 بحيث يتم تسجيل أن المعاملة لا تزال مؤقتة وأن هناك اثنين من الرسائل (رسائل رسالة طلب المعاملة ورسالة معلومات المعاملة) من أصل ثلاثة رسائل مطلوية لاكتمال المعاملة يجب أن 0 يتم تلقيها أو إرسالها بواسطة المفتاح ‎SW‏ 1. بمجرد معالجة رسالة معلومات المعاملة بشكل ناجح بواسطة التطبيق البنكي 102ب للبنك 2؛ يقوم التطبيق البنكي 102ب بإصدار رسالة تأكيد معاملة أولى. رسالة تأكيد معاملة أولى عبارة عن ‎ash‏ على أن رسالة معلومات المعاملة قد تم تلقيها ومعالجتها بشكل ‎mal‏ بواسطة البنك 2؛ وتتضمن نفس معرف المعاملة مثل رسائل رسالة طلب المعاملة ورسالة معلومات المعاملة (لأن ‎Silay 5‏ رسالة طلب المعاملة؛ رسالة معلومات المعاملة ورسالة تأكيد معاملة أولى ترتبط بنفس المعاملة). يتم تخزين رسالة تأكيد معاملة أولى وصفها في وحدة صف الرسالة 106ب؛ ويعد ذلك يتم تمريرها إلى البوابة 104ب بحيث يتم ضمان أنها موجودة في الصورة المعيارية ولإضافة توقيع رقمي ومعلومات توجيه. بعد ذلك يتم تمرير رسالة تأكيد معاملة أولى عودة إلى وحدة صف الرسالة 6ب لتيم التخزين بشكل مؤقت وبتم الصف قبل نقل إلى واحد من مواقع المفتاح. كما هو الحال 0 مع وحدة صف الرسالة 106( يتم إرسال الرسائل عند ‎ial)‏ الأمامي من الصف في وحدة صف الرسالة 106ب بشكل مثالي بشكل تبادلي إلى وحدة صف الرسالة 1108 لموقع المفتاح 1 ووحدة صف الرسالة 108ب لموقع المفتاح 2؛ وفقا لمعلومات التوجيه المضافة إلى كل رسالة بواسطة البوابة 104ب. في هذه الحالة؛ يمكن رؤية أن رسالة تأكيد معاملة أولى يتم إرسالها إلى وحدة صف رسالة 108ب عند موقع المفتاح 2. 5 يتم تخزين رسالة تأكيد معاملة أولى بشكل مؤقت ‎ang‏ صفها في وحدة صف الرسالة 108ب لحين إتاحة واحد من المفاتيح ‎SW 3 SW‏ 4 لاستلام رسالة تأكيد معاملة أولى. في هذه الحالة؛ يمكن
رؤية أن المفتاح ‎SW‏ 4 هو المفتاح الأول المتاح عندما تكون رسالة تأكيد معاملة أولى عند ‎gall‏
الأمامي من الصف؛ وبالتالي يتم إرسال رسالة تأكيد معاملة أولى إلى المفتاح ‎SW‏ 4.
عند المفتاح ‎SW‏ 4؛ يتم استخدام لوغاربتم العنونة مع رسالة تأكيد معاملة أولى. لأن رسالة تأكيد
معاملة أولى لها نفس معرف المعاملة مثل رسالة طلب المعاملة (ورسالة معلومات المعاملة)؛ سوف يكون مخرج لوغاربتم العنونة هو نفس مخرج لوغاريتم العنونة لرسالة طلب المعاملة. ذلك
أن» مخرج لوغاريتم العنونة سوف يشير إلى أن المفتاح ‎SW‏ 1 يجب أن يكون هو المفتاح الذي يتم
إليه إرسال رسالة تأكيد معاملة أولى. بالتالي؛ كما هو مبين في الشكل ‎ol‏ يقوم المفتاح 5174
بإرسال رسالة تأكيد معاملة أولى إلى المفتاح ‎SW‏ 1. يتم هذا الارسال عبر قناة اتصال البيانات
تقوم بتوصيل موقع مفتاح 1 و2.
0 بمجرد استلام رسالة تأكيد معاملة أولى بواسطة المفتاح 517 1؛ يتم تحديث ‎Ala‏ المعاملة في قاعدة البيانات 1110 بحيث يتم تسجيل أن المعاملة مكتملة لأن كل الرسائل (رسائل رسالة طلب المعاملة؛ رسالة معلومات المعاملة ورسالة تأكيد معاملة أولى) المطلوية للمعاملة التي سيتم اكتمالها قد تم الآن تلقيها أو إرسالها بواسطة المفتاح ‎SW‏ 1. في هذه الحالة؛ يتم تحريك حالة المعاملة من جدول رحلات داخلي في قاعدة البيانات 1110 والذي يسجل ‎dials‏ المعاملة الخاصة
5 بالمعاملات القائمة؛ إلى جدول كامل في قاعدة البيانات 1110؛ والذي يسجل تفاصيل المعاملة الخاصة بالمعاملات المكتملة ‎.completed transactions‏ الرسائل الثلاثة رسالة طلب المعاملة؛ رسالة معلومات المعاملة ورسالة تأكيد معاملة أولى كافية لتحديد أن المعاملة ‎ALIS‏ بمجرد استلام رسالة تأكيد معاملة أولى؛ يتم التأكيد على أن معلومات عملية دفع موجودة في رسالة معلومات المعاملة قد تم استلامها ومعالجتها بنجاح بواسطة
0 البنك 2. بالتالي تتم إضافة نفس المبلغ من المال المخصوم من الحساب المرسل للبنك 1 بعد إرسال رسالة طلب المعاملة إلى حساب الاستلام للبنك 2. تمت ملاحظة أن هذا يسمح لعملاء البنك 1 والبنك 2 باختبار عملية نقل آنية للتمويلات» حتى من خلال عندم إجراء التسوية بين البنك 1 والبنك 2. بعد تحديث حالة المعاملة لتسجيل أن المعاملة مكتملة في قاعدة البيانات ‎F110‏ يتم تكوين سجل
5 ملخص المعاملة ‎(TS) transaction summary record‏ على أساس حالة المعاملة. يحتوي سجل ملخص المعاملة على معلومات ‎LAS‏ للسماح بإجراء التسوية للتمويلات بين الحسابات المالية
‎financial accounts‏ المحددة بواسطة رسائل معاملة ويتم تخزينها في وحدة صف الرسالة 1112. ‎dass‏ يتضمن سجل ملخص المعاملة الاسم؛ العنوان» كود التصنيف ورقم حساب المرسل (المصدر) للتمويلات؛ الاسم العنوان» كود التصنيف ورقم حساب المتلقي (المستفيد) للتمويلات؛ مبلغ المال الذي سيتم نقله (شاملا في أي عملة سيتم النقل) ومعرف المعاملة الفريد. يمكن أن يتضمن سجل ملخص المعاملة أيضا معلومات إضافية مثل الوقت والزمن الذي تم فيه إنشاء السجل؛ الأختام الزمنية ‎time stamps‏ المتعلقة بوقت إرسال أو استقبال رسائل المعاملة (رسالة طلب المعاملة؛ رسالة معلومات المعاملة ورسالة تأكيد معاملة أولى)؛ بيانات ووقت التسوية (أو مؤشر آخر لدورة التسوية المعينة حيث يجب معالجة المعاملة) ومؤشر لما إذا كانت أو لم تكن المعاملة ناجحة. بالطبع؛ هذه القائمة لا تشمل كل شيء؛ ‎(gly‏ معلومات يمكن أن تكون مفيدة في 0 تنفيذ التسوية وحساب كل المعاملات يمكن تضمينها في سجل ملخص المعاملة. على الرغم من عدم التوضيح في الشكل 1؛ تتضمن وحدة صف الرسالة 1112 أيضا صورة قاعدة بيانات مجمعة حيث يتم تخزين اثنين من نسخ من كل سجلات ملخص المعاملة على وحدات التخزين المنفصلة. يقوم الحفاظ على اثنين من النسخ متزامنة بتحسين مرونة النظام 100( حيث إنه إذا كانت نسخة من سجل ملخص المعاملات غير متاحة (بسبب الفشل التقني أو ما شابه)؛ لا 5 يزال يمكن استخدام النسخة الثانية. تقوم وحدة صف الرسالة 1112 بشكل مؤقت بتخزين وصف سجل ملخص المعاملة لحين جهوزية وحدة المكتب الخلفي 114 (انظر أدناه) لاستلام سجل ملخص المعاملة للتسوية المعالجة. يمكن تنفيذ عملية تكوين سجل ملخص المعاملة وتشغيل وحدة صف الرسائل 1112 و112[ب باستخدام تطبيق برمجي ‎Jie software application‏ قائمة انتظار رسائل الأرتب ‎Rabbit‏ ‎Rabbit MQ Message queue 20‏ ®« مثلا. في الحقيقة؛ ‎(Sa‏ توصيل قاعدة البيانات المجمعة 0 ووحدة صف رسالة 1112 (وء بالمثل؛ قاعدة البيانات المجمعة 110ب ووحدة صف ‎Als)‏ ‏2مب) وظيفيا بواسطة التطبيق البرمجي بحيث؛ حتى إذا كانت قاعدة البيانات المجمعة ووحدة صف رسالة عند كل موقع؛ في الحقيقة؛ عبارة عن كيانات منفصلة ‎(LIS‏ يتم تنفيذ عملية قراءة وكتابة الوظيفية فيما بينها (شاملة تكوين سجل ملخص المعاملة) بسهولة وبشكل اعتمادي. 5 بعد التخزين الناجح لسجل ملخص المعاملة في وحدة صف الرسالة ‎of112‏ يقوم المفتاح ‎SW‏ 1 بإصدار رسالة تأكيد معاملة ثانية ‎(M4) second transaction confirmation message‏ رسالة
تأكيد معاملة ثانية عبارة عن رسالة ‎ash‏ للتأكيد إلى البنك 1 على أن المعاملة قد تم تنفيذها بنجاح عند البنك 2 وتتضمن نفس معرف المعاملة ‎Jie‏ رسائل رسالة طلب المعاملة؛ رسالة معلومات المعاملة ورسالة تأكيد معاملة أولى (لأن الرسائل رسالة طلب المعاملة؛ رسالة معلومات المعاملة؛ رسالة تأكيد معاملة أولى ورسالة تأكيد معاملة ثانية كلها مرتبطة بنفس المعاملة). يتم إرسال رسالة تأكيد معاملة ثانية إلى البنك 1 عبر ‎ang‏ صف الرسائل 1108 11065 والبوابة 104أ. ذلك أنء رسالة تأكيد معاملة ثانية يتم تخزينها بشكل مؤقت ويتم صفها في وحدة صف الرسالة 1108 بعد ذلك يتم إرسالها عبر قناة اتصال البيانات إلى وحدة صف رسالة 106 حيث يتم تخزينها مرة أخرى وبتم صفها لحين إتاحة البوابة 1104 لاستلامها. ‎aa‏ الاستلام بواسطة البوابة 104 يتم التحقق من رسالة تأكيد معاملة ثانية (باستخدام توقيع رقمي مولد بواسطة المفتاح). بعد ذلك يتم 0 تمريرها عودة إلى وحدة صف الرسالة ‎(J106‏ حيث يتم التخزين بشكل مؤقت وبتم الصف قبل التمرير إلى التطبيق البنكي 1102 للبنك 1. ‎Jal‏ يتم التأكيد إلى البنك 1 على أن نقل التمويلات قد تم تنفيذه بنجاح. في حالة حيث ‎dels‏ الحساب عند البنك المصدر للتعليمات (البنك 1؛ في المثال وفقا للشكل 1) يقوم أولا بإرسال رسالة طلب المعاملة إلى المفتاح المستلم عبر الانترنت باستخدام تطبيق طالب 5 ومفتاح المعالجة ‎WS) processing switch‏ هو محدد بواسطة وظيفة العنونة) ليس هو نفس هذا المفتاح المستلم الأصلي (لاحظ أن الحال لم تكن كذلك في المثال وفقا للشكل 1؛ حيث مفتاح المعالجة 5171 أيضا هو المفتاح الذي يتم عنده تلقي رسالة طلب المعاملة أصلا)؛ بعد ذلك سوف يتم توجيه رسالة تأكيد معاملة ثانية إلى المفتاح المستلم الأصلي من مفتاح المعالجة ‎deny‏ ذلك يتم الإرسال إلى البنك المصدر للتعليمات (عبر وحدة صف الرسائل ذات الصلة 108 2108« 0 1106 106ب) من المفتاح المستلم الأصلي. وهذا ضروري لضمان أن رسالة تأكيد معاملة ثانية قد تمت إعادتها إلى نفس التطبيق الطالب الذي يتم إليه إرسال رسالة طلب المعاملة للمعاملة. تتم تهيئة وحدة المكتب الخلفي 114 لمعالجة سجل ملخص المعاملات المخزنة ‎gig‏ الصف في وحدة صف الرسائل 1112 112ب للسماح للتسوية بأن تتم بين البنك 1 والبنك 2. وهذا ممكن لأن كل من سجل ملخص المعاملات يحتوي على كل المعلومات الضرورية لتتبع مقدار المال 5 الذي يتم نقله من البنك 1 إلى البنك 2 (أو العكس بالعكس) لكل معاملة؛ وبالتالي؛ عند نهاية دورة التسوية؛ يمكن حساب المبلغ الكلي للمال الذي سيتم نقله بين البنوك باستخدام سجل ملخص
المعاملات. وهذا يضمن أن خصم وإضافة الحسابات البنكية لكل معاملة؛ كما هو موضح أعلاه؛ متوافق مع التصفية الصافية المؤجلة للمال الفعلي المنقول بين البنوك. سجل يتم تخزين وصف ملخص المعاملات في صف الرسالة 1112 قبل النقل إلى وحدة المكتب الخلفي 114 للمعالجة. تتضمن المعالجة عند وحدة المكتب الخلفي 114 تخزين سجل ملخص المعاملات والحفاظ على إجماليات المسئولية ثنائية الجانب (بنك إلى بنك) ومتعددة الجانب (بنك إلى بنوك أخرى) لكل بنك ‎(ua)‏ المال المملوك) للاستخدام في التسوية. بعد ذلك تتم التسوية عند نهاية دورة التسوية ‎Ole)‏ ‏كل 8 12 أو 24 ساعة؛ كما هو موضح أعلاه)؛ على أساس هذه البيانات المملوكة بواسطة وحدة المكتب الخلفي 114. لاحظ ‎of‏ في هذا النموذج؛ يتم وضع وحدة المكتب الخلفي 114 عند موقع مفتاح 1. بالتالي؛ 0 يجب إرسال سجلات ملخص المعاملة المخزنة في وحدة صف رسالة 112ب عند موقع مفتاح 2 عبر قناة اتصال البيانات بين مواقع المفتاح ليتم تلقيها بواسطة وحدة المكتب الخلفي 114. في نموذج ‎ci‏ يمكن وضع وحدة المكتب الخلفي 114 عند موقع مفتاح 2؛ في هذه الحالة؛ سوف يتم إرسال سجلات ملخص المعاملة المخزنة في وحدة صف رسالة 1112 عند موقع مفتاح 1 عبر قناة اتصال البيانات بين مواقع المفتاح ليتم استلامها بواسطة وحدة المكتب الخلفي 114. في 5 نموذج آخرء هناك مجموعة من وحدات مكتب خلفية ‎back office units‏ 114؛ واحد موضوع عند كل من موقع مفتاح 1 وموقع مفتاح 2. في هذه الحالة؛ سوف يتم استخدام واحد فقط من وحدات المكتب الخلفية للتسوية. مع ذلك؛ تجرية مجموعة من وحدات مكتب خلفية 114 تعني أن إذا كان واحد من وحدات المكتب الخلفية 114 قد اصبح غير عامل (بسبب ‎Ua‏ أو صيانة مخطط لها أو ما شابه)؛ بعد ذلك يمكن إعادة توجيه سجلات ملخص المعاملة المخزنة في ‎sang‏ صف الرسائل 0 1112 112ب إلى وحدة المكتب الخلفي 114 المتبقية العاملة للتسوية. بالتالي يتضمن النظام 0 مرونة محسنة؛ حيث يمكن تنفيذ التسوية باستخدام سجل ملخص المعاملات على الرغم من فشل واحد من وحدات المكتب الخلفية 114. وصف طلبات المعاملة كما هو مذكور ‎Shad‏ في النموذج وفقا للشكل 1؛ يتم توزيع رساتئل المعاملة (تحديدا؛ رسالة طلب 5 المعاملة ورسالة تأكيد معاملة أولى؛ التي يتم استلامها من البنوك) بين المفاتيح ‎SW‏ 1 517 2؛ ‎SW 3 SW‏ 4 عبر وظيفة عنونة (المشار ‎all‏ أيضا ب "لوغاريتم ‎(ge‏ وهذا يساعد على
ضمان أن الرسائل يتم توزيعها بالتساوي بين المفاتيح؛ بالتالي يتم توفير حمل موازنة حمل للنظام 0. وهي تساعد أيضا على ضمان أن الرسائل المتعلقة بنفس المعاملة تمت معالجتها بواسطة نفس المفتاح ‎oof‏ على الأقل؛ بواسطة مفاتيح لها وصول إلى نفس قاعدة البيانات 110 110[ب. سوف يتم الآن شرح وظيفة العنونة بالمزيد من التفاصيل
كما هو موضح سلفاء تقوم وظيفة العنونة بتخطيط كل رسالة إلى المفتاح. بشكل أكثر تحديداء تقوم وظيفة العنونة باستخدام معرف المعاملة الفريد لرسالة وعدد المفاتيح كمدخلات؛ ومخرجات عدد يشير إلى أي من المفاتيح ‎SW 3 SW 2 517 1 SW‏ 4 سيتم استخدامه لمعالجة الرسالة. حيث؛ وظيفة العنونة لها الصورة: رقم المفتاح - الوظيفة (معرف المعاملة؛ العدد الكلي للمفاتيح)
0 يمكن استخدام أمثلة معينة على وظائف العنونة ‎hashing functions‏ (حيث؛ الوظائف التي تخرج فقط واحد من عدد ثابت من قيم مخرج محددة سلفاء حتى على الرغم من أنه قد يكون هناك عدد كبير؛ أو بشكل ‎caine‏ عدد لا نهائي من المدخلات) معروفة بعينها في المجال ولن تتم مناقشتها بالتفصيل هنا. في نماذج؛ يقوم المفتاح الذي يتلقى أولا رسالة من واحد من البنوك (أو؛ بشكل أكثر تحديداء من
5 واحد من وحدة صف الرسائل 108 108ب) بتنفيذ وظيفة العنونة على الرسالة. وهذا يحدد المفتاح الذي سيتم استخدامه لمعالجة الرسالة. بعد ذلك يتم إرسال الرسالة ‎gf)‏ بمعنى آخر؛ ‎sale)‏ ‏توجيهها) إلى المفتاح المحدد. يتم تنفيذ هذه الوظيفة في دارة معالجة موضوع في المفتاح باستخدام تعليمات قابلة للقراءة بواسطة كومبيوتر المخزنة في وحدة تخزين في المفتاح. وقد تم تقديم أمثلة على إعادة توجيه رسالة بعد تطبيق وظيفة العنونة سلفا نسبة إلى الشكل 1 (حيث تتم إعادة توجيه
0 رسالة تأكيد معاملة أولى؛ والتي يتم تمريرها أوليا إلى المفتاح ‎SW‏ 4؛ إلى المفتاح ‎SW‏ 1 بعد تطبيق لوغاربتم العنونة). يتم استخدام ميزة وظيفة العنونة للرسائل المستلمة من البنوك (حيث؛ الرسائل رسالة طلب المعاملة ورسالة تأكيد معاملة أولى في المثال وفقا للشكل 1)؛ حيث هناك رسائل يمكن إرسالها أوليا إلى أي من المفاتيح ‎SW 2 SW 1 SW‏ 3 و5177 4. تتضمن كل الرسائل المرتبطة بنفس المعاملة نفس معرف المعاملة. وهذا يسمح لهذه الرسائل بأن
5 تتم إعادة توجيهها إلى ومعالجتها بواسطة نفس المفتاح أو؛ على الأقل؛ بواسطة مفاتيح والتي لها وصول إلى نفس قاعدة البيانات ‎(F110‏ 110ب؛ إن أمكن. وهذا ‎cite‏ حيث يسمح لقاعدة البيانات
110 110ب ذات الصلة بأن يتم الحفاظ عليها تحت تحديث مع التقدم في المعاملة المعينة
بشكل أسهل وأكثر فعالية.
بينما من المفيد تحديد موضع المفتاح المحدد الفردي لمعالجة كل الرسائل المرتبطة بمعاملة معينة؛
في حالة أن المفتاح المحدد قد أصبح غير عامل؛ بسبب التلف أو الصيانة المخطط لها أو ما شابه؛ في نماذج الكشف؛ تم توفير قائمة أولوية خاصة بالمفاتيح البديلة التي يجب عليها أن
تتعامل مع الرسائل المرتبطة بتلك المعاملة.
تم شرح مثال على ترتيب أولوية المفاتيح أدناه في الجدول 1
الجدول 1
0 في الجدول 1 تم توضيح ترتيب أولوية للمفاتيح. المفتاح الأول عبارة عن مفتاح مختار بواسطة لوغاربتم العنونة لتحديد عملية توزيع غير متجانسة للرسائل عبر كل المفاتيح. المفتاح الثاني هو المفتاح التالي في ترتيب الأولوية بحيث يجب ألا تتم إتاحة المفتاح الأول؛ تتم إرسال الرسالة لمعاملة معينة إلى المفتاح الثاني. في هذه الحالة؛ يتم وضع المفتاح الثاني عند نفس موقع المفتاح الأول. بمعنى آخرء في حالة أن المفتاح الأول موضوع عند موقع مفتاح 1؛ سوف يتم وضع
5 المفتاح الثاني أيضا عند موقع مفتاح 1. المفتاح الثالث هو المفتاح التالي في ترتيب الأولوية؛ بحيث يجب ألا تتم إتاحة المفتاح الثاني؛ يتم إرسال الرسالة إلى المفتاح الثالث. في هذه الحالة؛ يجب وضع المفتاح الثالث عند موقع مفتاح مختلف مع ذلك الخاص بالمفاتيح الأولى والثانية؛ حيث لا توجد هناك مفاتيح أخرى متاحة عند موقع مفتاح المفاتيح الأولى والثانية. ‎(hal‏ المفتاح الرابع هو المفتاح التالي في ترتيب الأولوية؛ بحيث يجب ألا تتم ‎dal‏ المفتاح الثالث؛ تتم إرسال
0 رسالة إلى المفتاح الرابع. في هذه الحالة؛ يجب وضع المفتاح الرابع (الذي هو المفتاح الوحيد المتبقي) عند نفس موقع المفتاح الثالث.
هناك اثنين من المزايا الملحوظة لتوفير المفاتيح في ترتيب أولوية ‎Jie‏ ذلك المبين في الجدول 1. الميزة الأولى هي أنه يجب أن يفشل واحد من المفاتيح الأولى بعد ذلك تتم معالجة الرسالة بواسطة المفتاح النشط ‎active switch‏ بسرعة. وهذا يضمن أن تتم إعادة تقديم طلب المعاملة بسرعة. ثانياء لأن المفتاح الثاني في ترتيب الأولوية موجود عند نفس موقع المفتاح الأول يضمن هذا أنه إذا أصبح المفتاح الأول غير ‎cele‏ يتم إرسال الرسائل إلى المفتاح الذي له وصول مباشر إلى نفس قاعدة البيانات 110 110ب ‎Jie‏ تلك الخاصة بالمفتاح الأول. وهذا يسمح بمعالجة الرسائل للاستمرار كما لو أن المفتاح الأول عاملاء حيث المفتاح الثاني قادر على الوصول مباشرة وتحديث سجلات حالة المعاملة الخاصة بكل المعاملات المعلقة المعالجة سلفا بواسطة المفتاح الأول. بشكل مفيد؛ يؤدي هذا إلى مقاطعة منخفضة للمعالجة المعاملة في حالة أصبح واحد من المفاتيح
0 عند موقع مفتاح محدد غير عامل. في حالة أن كل المفاتيح عند موقع مفتاح معين غير عاملة؛ يسمح وجود المفاتيح الثالث والرابع في قائمة الأولوية بمعالجة معاملات جديدة (عبارة عن؛ معاملات خاصة بإصدار رسالة طلب المعاملة بعد ما أصبحت كل المفاتيح عند الموقع المعين غير عاملة) للاستمرار. بشكل مفيد؛ يسمح هذا للمعاملات الحديثة بتنفيذها حتى في حالة إذا كانت كل المفاتيح عند موقع مفتاح غير
‎WS) dle 5‏ يمكن أن يحدث بعد كارثة طبيعية عند واحد من مواقع ‎lal‏ مثلا). مع ذلك؛ بالنسبة للمعاملات التي اكتملت جزئيا عند موقع المفتاح غير العامل؛ لا يمكن أن تستمر المعاملة لأن الوصول إلى بيانات ‎dla‏ المعاملة ‎transaction state data‏ (والتي تم تخزينها على قاعدة البيانات 110أ 110ب عند الموقع غير العامل) غير متاح. وسوف تتم مناقشة هذا الموقف بالتفصيل بعد ذلك.
‏20 سوف يتم فهم أن قوائم الأولوية المعينة لكل مفتاح المبينة في الجدول 1 هي مجرد أمثلة؛ وأن قوائم الأولوية البديلة يمكن استخدامها. علاوة على ذلك؛ على الرغم من أن ما سبق يصف تقديم اثنين من مفاتيح عند اثنين من المواقع» يمكن تصور استخدام هذه المبادئ مع أي عدد من المفاتيح عند أي عدد من المواقع. تحسين مرونة النظام
‏5 كما هو موضح فعلاء في النظام 100؛ يتم تخزين بيانات ‎Ala‏ المعاملة للمعاملة في قاعدة البيانات 110 110ب لموقع المفتاح المستخدم لمعالجة المعاملة. بعد ذلك يتم استخدام بيانات
‎dlls‏ المعاملة لتوليد سجل ملخص المعاملة؛ والذي يتم تخزينه وصفه في وحدة صف رسالة ‎A112‏ ‏2 ب المناسبة لحين إتاحة المكتب الخلفي 114 لاستلام سجل ملخص المعاملة عند نهاية دورة التسوية. بعد التخزين الناجح لسجل ملخص المعاملة في وحدة صف الرسالة 1112 112ب المناسب؛ يمكن حذف بيانات ‎Als‏ المعاملة من قاعدة البيانات 110 110ب. علاوة على ‎ld‏ ‏5 عندما يؤكد المكتب الخلفي 114 على وحدة صف الرسالة 112 112ب المناسبة بأنها قد استلمت سجل ملخص المعاملة ‎or lady‏ يمكن حذف سجل ملخص المعاملة من وحدة صف الرسالة 2 2اب. مع ذلك؛ إذا كانت هناك مشكلة عند موقع المفتاح الذي يتم عنده تخزين سجل ملخص المعاملة والذي يمنع وحدة المكتب الخلفي 114 من القدرة على الوصول إلى وحدة صف الرسالة 1112؛ 0 112ب لموقع المفتاح هذا (بالرغم من ترتيب قاعدة البيانات المجمعة لوحدة صف الرسائل 112أ؛ 2ب)؛ بعد ذلك يكون هناك خطر أن سجل ملخص المعاملة لن يتم اعتباره عند نهاية دورة التسوية. وهذا يؤدي إلى حساب التسوية بين البنوك بشكل خاطئ (وبالتالي النقل الخاطئ للمال الفعلي بين البنوك). لتخفيف هذه مشكلة؛ عند تمرير ملخص كل معاملة إلى وحدة صف الرسالة 112 112ب لموقع مفتاح المعالجة ‎processing switch site‏ يتم إرسال نسخة منها إلى واحد من مفاتيح موقع المفتاح ‎AY)‏ للتخزين عند وحدة تخزين الدعم ‎back-up storage unit‏ (غير مبينة). بحيث؛ ‎Ole‏ سوف يتم نسخ سجل ملخص كل معاملة صادر عند موقع مفتاح 1 والمخزن بشكل مؤقت والمصفوف في وحدة صف رسالة 1112 أيضا وتتم إعادة توجيهه إلى المفتاح ‎SW‏ 3 أو ‎SW‏ 4 عند موقع مفتاح 2 والمخزنة في وحدة تخزين الدعم عند موقع المفتاح 2. بشكل مفيد؛ وهذا يعني أنه؛ ولأي سبب؛ 0 إذا كانت سجلات ملخص المعاملة المخزنة في وحدة صف الرسالة 1112 112ب عند موقع معين غير قابلة لا يمكن الوصول إليها إلى وحدة المكتب الخلفي 114 عند نهاية دورة التسوية ‎Ole)‏ بسبب فشل مع وحدة صف الرسالة 1112 112ب)؛ بعد ذلك يمكن أن تظل النسخ المدعومة من سجل ملخص المعاملات يمكن الحصول عليها وإتاحتها إلى وحدة المكتب الخلفي 4 لتنفيذ حسابات التسوية. بالإضافة إلى استخدام ترتيب قاعدة بيانات مجمعة لوحدة صف 5 الرسائل 1112 112ب؛ وهذا يساعد على ضمان أن التسوية بين البنوك يمكن تنفيذها بشكل صحيح.
كما هو موضح أعلاه؛ في نماذج؛ يتم توزيع المفاتيح بين مجموعة من المواقع؛ مع كل موقع يتضمن مجموعة من المفاتيح. في النموذج المقدم في الشكل 1؛ مثلاء هنا أريعة مفاتيح ‎SW‏ 1؛ ‎SW 2 SW‏ 3 و5177 4< مع مفاتيح ‎SW 1 SW‏ 2 والتي تشكل مجموعة عند الموقع 1؛ والمفاتيح ‎SW‏ 3 و517 4 التي تشكل مجموعة عند الموقع 2.
تعمل كل من المفاتيح 517 1 ‎SW 3 SW 2 SW‏ 4 بشكل مستقل عن بعضها البعض. بالتالي؛ في ‎Alla‏ فشل واحد من المفاتيح في مجموعة (بسبب ‎Tad‏ و أو عطل؛ مثلا)؛ أو إذا كان يجب إيقاف مفتاح واحد في مجموعة للصيانة؛ بعد ذلك يمكن استمرار معالجة المعاملة عند المفتاح الآخر في هذه المجموعة (والتي؛ بشكل مفيد؛ يكون لها وصول إلى نفس قاعدة البيانات 0 ب).
يمتد هذا المبدأ ‎Lad‏ أكثر إلى فشل مفتاح ‎candy‏ في حالة أنه حتى إذا فشلت المزيد من المفاتيح؛ طالما أن هناك مفتاح واحد على الأقل في النظام الذي يعمل؛ بعد ذلك يمكن أن يستمر فشل ‎dallas‏ المعاملة (على الأقل للمعاملات الصادرة حديثا). ‎lie‏ إذا فشل المفتاح عند كل من موقع 1 وموقع 2 ‎Sli)‏ مفاتيح ‎SW‏ 1 و5177 3)؛ إذا فشلت كل المفاتيح عند ‎alge‏ معين (مثلا؛ مفاتيح ‎SW‏ 1 و5177 2 عند موقع 1)؛ أو حتى إذا فشلت كل المفاتيح باستثناء واحد ‎lie)‏ فشل المفاتيح
‎SW 1 SW 5‏ 2 و57 3؛ تاركة ‎SW‏ 4 فقط يعمل)؛ بعد ذلك سوف تتم إعادة توجيه رسالة معاملة إلى المفتاح المتاحة (باستخدام وظيفة العنونة) وسوف تستمر معالجة المعاملة. علاوة على ذلك؛ هذا المبداً غير مقيد بفشل المفاتيح. إذا كان هناك مكونات أخرى للنظام 100 تعاني من فشل (مثل واحد من وحدات التخزين 109أ-د)؛ بعد ذلك سوف يتم الكشف عن هذا بواسطة المفتاح ذو الصلة؛ وسوف يؤدي المفتاح بعد ذلك إلى رسائل تتم إعادة توجيهها إلى مفتاح
‏0 بديل كما هو محدد وفقا لوظيفة العنونة. تستمر معالجة المعاملة بالتالي باستخدام واحد من المفاتيح الأخرى. ‎Tal‏ غير مقيد بالتعامل مع أخطاء في المكونات. ‎Ole‏ إذا تم إغلاق موقع مفتاح للصيانة ‎ie)‏ ‏البرمجيات أو تحديثات البرمجيات ‎hardware updates‏ أو ما شابه)؛ بعد ذلك يمكن ألا تكوون مفاتيح الموقع غير متاحة لاستلام رسائل المعاملة. مع ذلك؛ يمكن أن تظل رسائل المعاملة قابلة
‏25 للاستلام والمعالجة بواسطة المفاتيح عند الموقع ‎AY)‏ بالتالي تسمح باستمرار معالجة المعاملة.
وهذا ينطبق إذا كان الموقع ‎LIS‏ مغلقا بسبب»؛ ‎Sle‏ كارثة طبيعية (مثل ‎gua‏ طوفان أو ما شابه). كما هو مذكور ‎Sad‏ يتم توزيع رسائل المعاملة بين المفاتيح ‎SW2 SWI‏ 5773 5174 وفقا لقوائم أولوية المفتاح المحددة بواسطة وظيفة العنونة. عندما يقوم المفتاح أولا بتلقي رسالة المعاملة؛ يقوم بتطبيق وظيفة العنونة على الرسالة ويعد ذلك تتم إعادة توجيه الرسالة (عند الحاجة) إلى المفتاح الأول والتي تم فهمها بواسطة النظام على أنها متاحة للمعالجة في قائمة الأولوية (يتم وصف مراقبة إتاحية المفتاح عبر الترتيب الاختباري بالمزيد من التفاصيل أدناه). لإعادة توجيه الرسالة؛ يحاول المفتاح المستلم الأصلي القيام بتأسيس اتصال ‎Jie)‏ وصلة بروتوكول تحكم بث ‎((TCP) Transmission Control Protocol‏ مع المفتاح الأول في قائمة الأولوية؛ وسوف تقوم بعد ذلك بإعادة توجيه الرسالة بمجرد تأسيس هذا الاتصال بشكل ناجح. )13 لم يتم تأسيس وصلة بشكل ‎mals‏ (كما يمكن أن يتم؛ ‎lie‏ إذا كان هناك خطاً في مفتاح الأولوية الأولى)؛ بعد ذلك يتم تحديد أن المفتاح الأول في قائمة الأولوية غير متاحة وبتم ‎sha)‏ محاولة لإعادة توجيه الرسالة إلى المفتاح التالي في قائمة الأولوية والتي سيتم فهمها بواسطة النظام لإتاحته للمعالجة (مرة أخرى؛ بواسطة محاولة تأسيس وصلة المفتاح التالي في قائمة الأولوية). بهذه الطريقة؛ يتم تكرار العملية لحين العثور على المفتاح المتاح. بالنسبة لرسالة طلب المعاملة (والذي يمثل معاملة مقدمة حديثا)؛ طالما أن مفتاح واحد في قائمة الأولوية متاح لاستلام رسالة المعاملة؛ بعد ذلك يمكن اكتمال ‎dallas‏ المعاملة بواسطة هذا المفتاح لتوليد سجل ملخص المعاملة. وهذا بسبب تسجيل بيانات حالة المعاملة للمعاملة المعينة أولا على أساس المعلومات في رسالة طلب المعاملة؛ وبالتالي لا تحتاج حالة معاملة البيانات السابقة (والتي 0 تتم تخزينها في قاعدة البيانات 110أ؛ 110ب لواحد من مواقع المفتاح) إلى الوصول إلى الاستمرار في معالجة المعاملة. على ‎Lal‏ الأخرى؛ بالنسبة لرسالة تأكيد معاملة أولى؛ يمكن اكتمال معالجة المعاملة إذا كان المفتاح الذي تمت إليه إعادة توجيه رسالة تأكيد معاملة أولى عند نفس موقع المفتاح مثل المفتاح الذي تمت إليه إعادة توجيه رسالة طلب المعاملة (والتي عندها تم إصدار رسالة معلومات المعاملة). وهذا لأن بيانات حالة المعاملة المخزنة عند موقع المفتاح هذا 5 يجب الوصول إليها للاستمرار في معالجة المعاملة. بالتالي؛ في حالة أن كل من المفاتيح عند موقع المفتاح التي تصبح عندها معالجة رسالة طلب المعاملة للمعاملة غير عاملة قبل استلام
رسالة تأكيد معاملة أولى؛ لا يمكن استمرار المعاملة لأن بيانات حالة المعاملة؛ التي تم تخزينها عند موقع المفتاح غير العامل؛ لا يمكن الوصول إليها. وقد تم وصف هذا السيناريو بالمزيد من التفاصيل بعد ذلك. لتقليل نطاق الشبكة الضائع؛ تتم تهيئة كل المفتاح ‎SW 3 SW 2 SW] SW‏ 4 لاختبار كل المفاتيح الأخرى للتأكيد على ما إذا كانت متاحة أو غير متاحة. هذا الاختبار يتضمن إرسال رسالة اختبارية إلى كل من المفاتيح الأخرى؛ والاستماع للاستجابة. إذا لم يتم تلقي استجابة من المفتاح المعين لا يتم تلقيه في مدة زمنية محددة سلفاء بعد ذلك يتم تحديد أن المفتاح المعين غير متاح. بعد ذلك يتم إرسال الرسائل المرتبطة بالمعاملات إلى هذا المفتاح وبعد ذلك إلى المفتاح التالي في قائمة الأولوية. بواسطة تنفيذ هذا الاختبار بشكل دوري؛ لا يتم إتلاف نطاق الشبكة بواسطة المفتاح 0 الذي يحاول تكوين وصلة مع المفتاح غير المتاح. يتم تحديد المدة الزمنية بين الاختبارات بحيث يتم تعويض النطاق الخارجي بشكل أكبر بواسطة التقليل في النطاق المستخدم بواسطة محاولة تكوين وصلات مع المفاتيح غير المتاحة. يمكن أن تكون المدة الزمنية المتاحة 100 مل ثانية؛ على الرغم من تصور المدد الخرى. يستمر الاختبار إلى المفاتيح المحددة بكنها غير متاحة بحيث؛ بمجرد إتاحة المفتاح محل الاستفهام مرة ‎(GAT‏ يصبح هذا معروفا للمفاتيح الأخرى ويمكن بعد 5 ذلك بث الرسائل إلى المفتاح الذي تمت إتاحته. بهذه الطريقة؛ يحدد المفتاح مفتاح آخر غير متاح بعد نتيجة الاختبار السلبية (ذلك أنه؛ عند عدم تلقي استجابة) أو عند فشل محاولة وصلة مع ذلك المفتاح. في أي ‎dlls‏ سوف يتم نقل رسالة ينبغي إرسالها إلى المفتاح غير المتاح إلى المفتاح التالي المتاح وفقا لقائمة الأولوية. وهذه الطريقة تشير أيضا إلى مشاكل أخرى في النظام؛ ‎Ole‏ فشل رابط ‎Jail‏ البيانات ‎data communication‏ ‎link 0‏ بين مواقع المفتاح ‎Oli)‏ إذا كان كل من ‎SW 1 SW‏ 2 غير قادر على الاتصال ب أو الاستجابة المتوافقة للاختبار السلبي الخاص بكل من ‎SW‏ 3 و5177 4؛ بعد ذلك يمكن أن تكون الحالة هي أن رابط اتصال البيانات بين موقع مفتاح 1 وموقع مفتاح 2 قد فشل). في حالة المشكلة؛ يتم توفير الصيانة إلى المفتاح الفاشل أو موقع المفتاح بشكل أسرع مما يمكن أن يتم دون الاختبار. مثلا؛ إذا لم يتم توفير ‎lad)‏ يمكن بالتالي تحديد المفتاح الفاشل أو موقع المفتاح في 5 حالة أن الرسالة المرتبطة بالمعاملة قد فشلت في بثها بشكل صحيح. يمكن أن يتم هذا بشكل أكثر تكرارية من إشارة الاختبار.
سوف يعرف البنك المرسل (البنك 1 في المثال وفقا للشكل 1) أن المعاملة قد اكتملت بشكل ناجح بمجرد تلقي رسالة تأكيد معاملة ثانية. إذا لم يتم تلقي رسالة تأكيد معاملة ثانية بواسطة البنك المرسل في مدة زمنية محددة سلفا (المعروفة بالمهلة)؛ بعد ذلك لا يعرف البنك المرسل ما إذا كانت أو لم تكن المعاملة ناجحة. يمكن أن تكون هذه المهلة خاصة بعدد من الأسباب. ‎lie‏ ‏5 يمكن أن يكون موقع المفتاح الذي تتم عنده معالجة رسالة طلب المعاملة غير عاملة قبل اكتمال المعاملة ‎lia)‏ قبل استلام رسالة تأكيد معاملة أولى)؛ بما يعني أن سجل ملخص المعاملة لم يتم ‎ans‏ أبدا وأن رسالة تأكيد معاملة ثانية غير مولدة أبدا. وسوف تكون عبارة عن معاملة فاشلة. على الناحية الأخرى؛ يمكن أن تكون الحالة هي أن المعاملة قد اكتملت بشكل ناجح وأن رسالة تأكيد معاملة ثانية قد تم إصدارهاء ولكن بعد ذلك يتم فقد رسالة تأكيد معاملة ثانية بعد ذلك في 0 النظام 100 يتم تأجيلها بمقدار انتهاء المهلة. في ‎Ala‏ عدم تلقي رسالة تأكيد معاملة ثانية في المهلة؛ يمكن أن يقوم البنك المرسل بإعادة بث ‎Ally‏ طلب المعاملة. تشرح الأشكال 12-ب كيف أن المفاتيح الفردية تتعامل مع رسائل معاملة؛ شاملة كيف يمكن للمفاتيح الفردية أن تتعامل مع رسائل المعاملة المعاد إرسالها من البنك المرسل. الشكل 2 يبين مثال على مخطط تدفق مع عملية يتم تنفيذها بواسطة المفتاح الذي يتلقى أوليا رسالة معاملة من واحد من وحدة صف الرسائل 108( 108ب؛ وفقا لأحد النماذج. ‎fas‏ العملية عند الخطوة 200. عند الخطوة 202 يتم تلقي رسالة معاملة (مثلاء رسالة طلب المعاملة أو رسالة تأكيد معاملة أولى؛ كما هو مبين في الشكل 1) بواسطة المفتاح من وحدة صف الرسالة ذات الصلة 108 108ب. عند الخطوة 204 يتم استخدام وظيفة العنونة مع الرسالة؛ بالتالي يتم تحديد قائمة أولوية للمفاتيح التي تتم إليها إعادة توجيه الرسالة. عند الخطوة 206؛ يتم 0 تحديد ما إذا كان أو لم يكن المفتاح الأول في قائمة الأولوية متاح لاستلام الرسالة. تم تحديد على أساس إما اختبار المفتاح الأول أو محاولة تأسيس اتصال مع المفتاح الأول؛ كما هو محدد سلفا. إذا تم تحديد أن المفتاح الأول متاح؛ بعد ذلك تنتقل العملية إلى الخطوة 208 حيث تتم إعادة توجيه الرسالة إلى المفتاح الأول. تنتهي العملية بعد ذلك عند الخطوة 210. على الناحية الأخرى؛ إذا تم تحديد أن المفتاح الأول غير متاح؛ بعد ذلك تنتقل العملية إلى الخطوة 212. 5 عند الخطوة 212؛ تم تحديد إذا كان أو لم يكن المفتاح التالي في قائمة الأولوية متاحا لاستلام الرسالة. مرة أخرى؛ يتم تحديد ذلك على أساس إما اختبار أو محاولة تأسيس اتصال مع المفتاح
التالي. إذا تم تحديد أن المفتاح التالي متاح؛ بعد ذلك تنتقل العملية إلى الخطوة 214؛ حيث تتم إعادة توجيه الرسالة إلى المفتاح التالي. تنتهي العملية بعد ذلك عند الخطوة 210. على الناحية الأخرى؛ إذا تم تحديد أن المفتاح التالي غير متاح؛ بعد ذلك يتم تكرار الخطوة 212 للمفتاح التالي في قائمة الأولوية (بالتالي؛ ‎Sle‏ إذا تم تحديد أن المفتاح الثاني في قائمة الأولوية غير متاح؛ بعد ذلك سوف يتم تحديد ما إذا كان أو لم يكن المفتاح الثالث في قائمة الأولوية متاحا). سوف يتم تكرار الخطوة 212 لحين العثور على المفتاح المتاح؛» عند هذه النقطة سوف تستمر العملية إلى الخطوة 214 وسوف تتم إعادة توجيه الرسالة إلى المفتاح المتاح. لاحظ أن المفتاح المتاح سوف يتم العثور عليه أخيرا إذا تم تنفيذ العملية وفقا للشكل 2( حيث المفتاح قادر على تنفيذ العملية وفقا للشكل 2ا؛ بالطبع؛ المتاحة لاستلام رسالة. 0 ايبين الشكل 2ب مخطط تدفق مثال على عملية تم ‎LAE‏ بواسطة المفتاح الذي يتم إليه إعادة توجيه رسالة وفقا لقائمة الأولوية. تبدأ العملية عند الخطوة 216. عند الخطوة 218 يتم استلام الرسالة بواسطة المفتاح. عند الخطوة 220 يتم تحديد أنه إذا كانت أو لم تكن الرسالة هي الرسالة الأولى المتعلقة بالمعاملة (ذلك ‎eof‏ ‏رسالة طلب المعاملة). إذا كانت الرسالة هي رسالة طلب المعاملة؛ بعد ذلك تنتقل العملية إلى 5 الخطوة 222 حيث يتم تحديد ما إذا كانت أو لم تكن رسالة طلب المعاملة المستلمة عبارة عن تكرار لرسالة طلب المعاملة. ثمة تكرار لرسالة طلب المعاملة عبارة عن إعادة بث لرسالة طلب المعاملة لمعاملة معينة من البنك المرسل؛ والذي يمكن أن يتم عند قيام البنك المرسل بإرسال رسالة طلب المعاملة سلفا ولكن لا يتم استلام رسالة تأكيد معاملة ثانية عودة في المهلة. يمكن تنفيذ عملية تحديد الخطوة 222 بواسطة فحص معرف معاملة رسالة طلب المعاملة. إذا 0 كانت رسالة طلب المعاملة عبارة عن ‎NSS‏ بعد ذلك يمكن أن تتم معالجة رسالة طلب المعاملة الأصلية عند موقع المفتاح؛ وبالتالي سوف يتم تسجيل معرف المعاملة (والتي كانت هي نفسها لكل من رسالة طلب المعاملة الأصلية والتكرارية لمعاملة معينة) عند موقع المفتاح ‎lie)‏ في قاعدة البيانات 110 110ب كجزءٍ من بيانات حالة المعاملة). ثمة توافق لمعرف المعاملة لرسالة طلب المعاملة الجديدة مع معرف المعاملة المسجل عند موقع المفتاح سوف يشير بالتالي إلى أن رسالة 5 طلب المعاملة عبارة عن تكرار. بشكل بديل؛ أو علاوة على ‎ld‏ يمكن أن تتضمن رسالة طلب المعاملة تكرارية معلومات ‎lie)‏ في مقدمة الرسالة) التي تشير إلى أن عبارة عن رسالة تكرارية
(يمكن إضافة هذه المعلومات التكرارية المضافة إلى رسالة طلب المعاملة بواسطة التطبيق المصرفي 102 102ب للبنك المرسل؛ مثلا). في حالة تحديد رسالة طلب المعاملة على أنها عبارة عن تكرار؛ تنتقل العملية إلى الخطوة 224. على الناحية الأخرى» إذا لم يتم ارتباط رسائل سابقة متعلقة بالمعاملة التي ترتبط بها رسالة طلب المعاملة ‎lly‏ تمت معالجتها عند موقع المفتاح؛ بعد ذلك يمكن تحديد أن رسالة طلب المعاملة لم تتم إعادة بثها و؛ أيضاء إذا كانت الرسالة المرسلة أولا مرتبطة بمعاملة معينة. في هذه الحالة؛ تنتقل العملية إلى الخطوة 230 حيث تتم معالجة رسالة طلب المعاملة بشكل طبيعي. تمت ملاحظة أن استخدام المعلومات التكرارية المتضمنة في رسالة طلب المعاملة تكرارية هو ميزة محددة. ‎Ole‏ قم باعتبار سيناريو حيث لا يتم استخدام معلومات تكرارية وحيث يصبح موقع 0 المفتاح عاطل كليا عن استلام رسالة تأكيد معاملة أولى وتكوين سجل ملخص المعاملة (التي تشير إلى اكتمال ‎mals‏ للمعاملة)؛ ولكن قبل إرسال رسالة تأكيد معاملة ثانية. سوف يقوم نقص رسالة تأكيد معاملة ثانية بالتسبب في جعل البنك المرسل يقوم بإعادة إرسال رسالة طلب المعاملة؛ والتي تتم بعد ذلك إعادة توجيهها إلى موقع المفتاح البديل. لن يتضمن موقع المفتاح البديل معرف المعاملة ‎Cua)‏ يتم تخزين سجل ملخص المعاملة في قاعدة البيانات 110أ؛ 110ب لموقع المفتاح 5 الأصلي) وبالتالي سوف يكون قادرا على تحديد أن رسالة طلب المعاملة عبارة عن تكرار بواسطة الاعتماد بشكل بسيط على توافق معرف المعاملة. بالتالي سوف تتم معالجة المعاملة مرتبطة برسالة طلب المعاملة كمعاملة جديدة عند موقع المفتاح ‎cond)‏ على الرغم من اكتمال المعاملة فعليا عند موقع المفتاح الأصلي (بواسطة تكوين سجل ملخص المعاملة). وسوف يؤدي هذا إلى معالجة المعاملة بشكل غير صحيح مرتين (بما يعني نقل ضعفي مبلغ المال الذي يرغب المرسل 0 بعد التسوية). مع ذلك؛ إذا تم استخدام المعلومات التكرارية؛ بعد ذلك يسمح هذا بإعادة إرسال رسالة طلب المعاملة التي سيتم تحديدها على أنها تكرارية بواسطة أي مفتاح عند أي موقع مفتاح (بدلا فقط من عند موقع المفتاح الذي يتم عنده معالجة رسالة طلب المعاملة الأصلية وتم تخزين معرف المعاملة). بالتالي يقوم استخدام المعلومات التكرارية بتقليل خطر رسالة طلب المعاملة التي تتم معالجتها بشكل غير صحيح كرسالة طلب المعاملة جديدة أكثر من مرة؛ بالتالي تقليل ‎sha‏ ‏5 معالجة نفس المعاملة بشكل غير صحيح أكثر من مرة. .
عند الخطوة 224 يتم تحديد ما إذا كان أو لم تكن رسالة تأكيد معاملة ثانية الخاصة بالمعاملة التي ترتبط بها رسالة طلب المعاملة المتكررة متاحة عند موقع المفتاح ‎Sle)‏ إذا تم تخزين رسالة تأكيد معاملة ثانية في قاعدة البيانات 1110 110ب عند موقع المفتاح). إذا كانت رسالة تأكيد معاملة ثانية متاحة؛ بعد ذلك يتضمن هذا أن يتم تكوين سجل ملخص المعاملة للمعاملة وأن المعاملة كانت مكتملة عند موقع المفتاح. في هذه الحالة؛ تنتقل العملية إلى الخطوة 226 حيث تتم إعادة إرسال رسالة تأكيد معاملة ثانية إلى البنك المرسل. وسوف يؤكد البنك على أن المعاملة قد اكتملت بنجاح؛ حتى إذا لم يتم تلقي رسالة تأكيد معاملة ثانية أصلا بواسطة البنك المرسل (أو لم يتم تلقيها على الأقل قبل نهاية المهلة). تنتهي العملية بعد ذلك عند الخطوة 232. على الناحية الأخرى؛ إذا كانت رسالة تأكيد معاملة ثانية غير متاحة؛ بعد ذلك يتضمن هذا أن 0 تكون هناك ‎dlls‏ عدم تأكد فيما يتعلق بما إذا كانت أو لم تكن المعاملة مكتملة بشكل ناجح. يمكن أن يتم هذا إذا ‎Ole (IS‏ تصبح كل المفاتيح عند موقع المفتاح التي تتم عندها معالجة المعاملة أصلا (والتي يتم عندها إصدار رسالة تأكيد معاملة ثانية إذا تم اكتمال المعاملة بشكل ناجح) غير متاحة (بسبب خطأً تقني أو ما شابه)؛ في هذه الحالة؛ ‎dlls‏ المعاملة غير معروفة؛ ولم يكن ممكن الحصول على رسالة تأكيد معاملة ثانية. بالتالي تنتهي العملية عند الخطوة 232. سوف تتضمن 5 المعاملة بالتالي ما تم فحصه يدويا عند نهاية دورة التسوية (انظر أدناه). إذا لم يتم تحديد رسالة على أنها رسالة طلب المعاملة عند الخطوة 220؛ بعد ذلك يجب أن تكون هي رسالة تأكيد معاملة أولى التي تم تلقيها من البنك المستلم لتمويلات المعاملة. في هذه الحالة؛ يمكن أن تكتمل المعاملة إذا كان المفتاح الذي ينفذ العملية وفقا للشكل 2ب له وصول إلى بيانات حالة المعاملة للمعاملة (حيث؛ يجب أن يكون المفتاح عند نفس الموقع الذي تمت عنده معالجة 0 رسالة ‎alla‏ المعاملة والذي له وصول إلى قاعدة البيانات ‎F110‏ 110ب ‎Cua‏ يتم تخزين بيانات حالة المعاملة). إذا كان المفتاح له وصول إلى بيانات حالة المعاملة؛ بعد ذلك تنتقل العملية إلى الخطوة 230 ‎Cus‏ تتم معالجة رسالة تأكيد معاملة أولى بشكل طبيعي. وهذا يسمح باكتمال المعاملة (بما يؤدي إلى إصدار رسالة تأكيد معاملة ثانية). تنتهي العملية بعد ذلك عند الخطوة 2. على الناحية ‎(gal)‏ إذا كان المفتاح لا يتضمن وصول إلى بيانات حالة المعاملة ‎LS)‏ ‏25 سيتم إذا كانت كل المفاتيح عند الموقع الذي يتم عنده تخزين قاعدة بيانات حالة المعاملة غير
عملية مع إصدار رسالة تأكيد معاملة ثانية)؛ بعد ذلك ليس من الممكن إكمال المعاملة. بالتالي تنتهي العملية عند الخطوة 232 (ولا يتم إصدار رسالة تأكيد معاملة ثانية). بالتالي» يمكن رؤية أنه إذا كان البنك المرسل لا يتلقى رسالة تأكيد معاملة ثانية التي تؤكد على أن المعاملة قد تم تنفيذها بشكل ناجح؛ بعد ذلك يمكن إعادة إرسال رسالة طلب المعاملة الأصلية التي تصدر تعليمات بالمعاملة بواسطة البنك المرسل. إذا كانت رسالة تأكيد معاملة ثانية متاحة (التي تشير إلى معاملة معالجة بشكل ناجح عند موقع مفتاح لا يزال يعمل) ولكن يتم فقدها أو تأجيلها ببساطة؛ بعد ذلك سوف يتم إعادة إرسال رسالة تأكيد معاملة ثانية إلى البنك المرسل في استجابة لرسالة طلب المعاملة المتكررة. مع ذلك؛ إذا كانت رسالة تأكيد معاملة ثانية غير متاحة؛ بعد ذلك يشير هذا إلى أن المعاملة كانت غير معالجة بشكل ناجح (بما يعني أن رسالة تأكيد معاملة ثانية 0 للم يتم توليدها أبدا) أو أن كل المفاتيح عند موقع المفتاح الذي تمت عنده معالجة المعاملة بشكل عاطل بعد توليد رسالة تأكيد معاملة ثانية (بما يعني أن رسالة تأكيد معاملة ثانية غير متاح ليتم رفضه).؛ في هذه الحالة؛ لا يتم تنفيذ المزيد من المعالجة على رسالة طلب المعاملة المعاد إرسالها. وهذا يساعد على ضمان أنه لا تتم معالجة المعاملة مرتين بواسطة النظام 100 (بالتالي بما يساعد على تجنب موقف حيث يتم خصم المال مرتين من الحساب البنكي المرسل). في هذه ‎dal 5‏ سوف تظل رسالة تأكيد معاملة ثانية غير مستلمة بواسطة البنك المرسل (على الرغم من عملية إعادة إرسال رسالة طلب المعاملة)؛ ويمكن أن يقوم التطبيق المصرفي 102( 102ب للبنك بعمل تقرير للمستخدم بأن المعاملة يمكن ألا تكون ناجحة. عند نهاية دورة التسوية؛ يمكن بعد ذلك تحليل السجلات الداخلية للبنك المرسل؛ السجلات الداخلية للبنك المستلم وسجل ملخص المعاملات الصادر بواسطة النظام 100 بعد ذلك لتحديد ناتج المعاملة وضمان أن كل معاملة التمويلات يتم حسابها. في النموذج المذكور أعلاه؛ يتم تحديد مهلة البنك المرسل لاستلام رسالة تأكيد معاملة ثانية بواسطة الخبير في المجال بكونها المدة الزمنية حيث يجب توقع وصول رسالة تأكيد معاملة ثانية للوصول؛ أخذا بالاعتبار أن وقت المعالجة المتوقعة لكل مكون في النظام 100 أي تأخير في الشبكة؛ إلخ. سوف يتم فهم أن على الرغم منء بالإشارة إلى الأشكال 2( الخطوات شاملة "إعادة توجيه" رسالة 5 معاملة إلى المفتاح المناسب كما هو محدد بواسطة قائمة الأولوية؛ إذا كان المفتاح يتلقى الرسالة عند الخطوة 202 فعليا هي المفتاح التي يجب أن تقوم بمعالجة الرسالة (وفقا لقائمة الأولوية)؛ بعد
— 2 8 —
ذلك سوف تتم ‎Sole)‏ توجيه رسالة المعاملة فعليا إلى مفتاح مختلف. أيضاء سوف تتم المعالجة
بواسطة نفس المفتاح المستلم. تساعد الخواص المذكورة أعلاه هنا على ضمان أن معالجة المعاملة يمكن أن تستمر بشكل اعتمادي وفعال حتى إذا أصبحت مكونات النظام 100 عاطلة.. للمزيد من ‎(pani)‏ عند نهاية دورة التسوية؛ قبل وحدة المكتب الخلفي 114 التي تقوم بتنفيذ معالجة التسوية باستخدام سجل ملخص المعاملات؛ يتم فحص مبلغ المعاملة ‎ASH‏ (حيث؛ المبلغ ‎ASI‏ من المال الذي سيتم نقله) إلى/من كل بنك كما هو محدد بواسطة سجل ملخص المعاملات فى مقابل سجلات مناظرة من مبالغ المعاملة المحمولة بواسطة المفاتيح (سوف يحافظ المفتاح والتي تقوم بمعالجة الرسالة رسالة طلب المعاملة لكل معاملة على سجل مبلغ المعاملة والبنك المرسل والمستلم؛ مثلا). إذا تم تنفيذ
0 معالجة الرسائل وتكوين سجل ملخص المعاملة بشكل صحيح؛ بعد ذلك يجب أن تتوافق مبالغ المعاملة الكلية إلى/من كل بنك المسجلة بواسطة سجل ملخص المعاملات وسجلات المفتاح. في هذه الحالة؛ من المعروف أن معالجة التسوية يمكن تنفيذها بشكل اعتمادي. على الناحية الأخرى؛ إذا كان هناك تعارض بين مبالغ المعاملة الكلية؛ بعد ذلك من المعروف أن هناك مشكلة مع توليد سجل ملخص المعاملات. يمكن بالتالى فحص ذلك وتصحيحه قبل معالجة التسوية.
5 بالتالي؛ في ضوءٍ الخواص المذكورة أعلاه؛ سوف يتم فهم أن النظام 100 يساعد على ضمان أن المعاملات الالكترونية ‎electronic transactions‏ الصادر تعليمات بها بواسطة البنوك غير محذوفة أو فاسدة أو مزدوجة قبل المعالجة عند نهاية دورة التسوية. وهذا يساعد على ضمان أن كل معاملة تم اعتبارها ويتم اعتبارها فقط مرة عند نهاية دورة التسوية. وهذا يتم حتى إذا كان مكون النظام 0 يعاني من ‎Wad‏ أو إذا كانت هناك أي صيانة مخطط لها على أي مكون للنظام 100 والذي
0 يتطلب أن المكون سيتم غلقه بشكل مؤقت. في الوقت ذاته؛ ‎Lalla‏ أن هناك مفتاح واحد على الأقل من النظام 100 والذي يعمل؛ بعد ذلك يقوم حملة الحساب ‎(Sl‏ بالاستمرار في إصدار تعليمات بالمعاملات الجديدة والخدمة الطبيعية. إدارة المسئولية في النظام الموضح أعلاه؛ يتم تنفيذ التسوية الكلية بين البنوك بشكل دوري. بمعنى ‎OAT‏ يتم نقل
5 المال الفعلي بين البنوك دوريا. هذا يعني أن سجل ملخص المعاملات عبارة عن وعود بالدفع في وقت التسوية. يتم تنفيذ التسوية في هذا النموذج بشكل منفصل عن هذا النظام 100؛ عبر نظام
مفعل بواسطة إيداع مشترك للبنك القابض ‎(fie‏ بنك إنجلترا. أنظمة التسوية ‎settlement systems‏ هذه معروفة للخبير في المجال. بالتالي؛ يتم توفير غطاء ائتماني بشكل يعتمد على الإيداعات المحمولة للتسوية. يجب ألا يسمح البنك بتخطي الغطاء الائتماني له. في تنفيذ الغطاء الائتماني في النظام المرن الخاص بالنماذج التي تنتشر عبر العديد من المواقع؛ تتواجد المشكلة. وقد تم شرح هذا في الشكل 3أ. في المثال المبين في الشكل 3ا؛ لنفترض أن البنك أ له غطاء ائتماني بمقدار -10000 جنيه ‎(ila‏ 602. حيث يتم شق النظام 100 عبر موقع مفتاح 1 603 (المشار إليه أيضا ببساطة ب 'موقع 1) وموقع مفتاح 2 604 (المشار إليه ‎Lad‏ ببساطة ب 'موقع 2( لضمان المرونة؛ يتم شق الغطاء الائتماني 602 بالتساوي بين موقع 1 وموقع 2. في كل حالة؛ تقوم المفاتيح عند كل 0 موقع بتسجيل الغطاء الائتماني الخاص بهذا الموقع. ‎(JUL‏ في هذه الحالة؛ ‎aly‏ الغطاء ‎Slat]‏ عند موقع 1 مرتبطة بالبنك هر -5000 جنيه انجليزي والغطاء الائتماني المخزن عند موقع 2 مرتبط بالبنك ‎A‏ يبلغ ‎Lad‏ -5000 جنيه انجليزي. بالطبع؛ هناك انقسامات أخرى مناسبة؛ مثل -2500 جنيه انجليزي لنظام موزع عبر أريعة مواقع وما شابه. إذا افترضنا أن معاملة ائتمانية ‎«debit transaction‏ معاملة 1؛ تتم معالجتها على موقع 1. 5 المعاملة 1 عبارة عن معاملة ائتمانية لذ -2500 جنيه انجليزي. وهذا يعني أن موضع خطر التسوية ‎(SRP) Settlement Risk Position‏ والذي هو مصطلح في المجال وتعني إجمالي المعاملات التي تمت حتى الآن عند كل موقع؛ لموقع المفتاح 1 ‎Ble‏ عن -2500 جنيه انجليزي. بالتالي؛ الجزء المتبقي للغطاء ‎Sle)‏ المتاح للمعاملات المستقبلية (المشار إليها ببساطة أيضا ب "الإيداعات المتاحة") على موقع 1 يبلغ -2500 جنيه انجليزي. حيث لا تتم 0 المعاملات في موقع 2 يبلغ موضع خطر التسوية لموقع 2 0 والإيداعات المتاحة للبنك م في موقع 2 لا يزال -5000 ‎ava‏ انجليزي. بالتالي؛ تبلغ الإيداعات الكلية المتاحة -7500 جنيه انجليزي وموضع خطر التسوية الكلي -2500جنيه انجليزي» 605. بافترارض الآن أن المعاملة الائتمانية الثانية؛ تتم معالجة المعاملة 2 على الموقع 2 والمعاملة 2 بمقدار -300 ‎ava‏ انجليزي. بالتالي؛ تبلغ الإيداعات المتاحة للموقع 2 -4700 جنيه انجليزي 5 وموضع خطر التسوية على موقع 2 -300 جنيه انجليزي. تظل موضع خطر التسوية على موقع 1 عند -2500 جنيه انجليزي والإيداعات المتاحة على موقع 1 تظل عند -2500 جنيه انجليزي.
موضع خطر التسوية الكلي للبنك م (أي إجمالي موضع خطر التسوية عند موقع 1 وموضع خطر التسوية عند موقع 2) -2800 جنيه انجليزي والإيداعات المتاحة (أي إجمالي الإيداعات المتاحة للموقع 1 و2) للبنك ‎A‏ -7200 جنيه انجليزي. لاحظ أن حسابات الائتمان المتاح غير مبينة في الشكل 3أ.
بافتراض الآن أن هناك محاولة لمعاملة ائتمانية ثالثة؛ المعاملة 3؛ لمعالجتها على الموقع 1. المعاملة 3 عبارة عن دين بمقدار -2600 جنيه انجليزي. وهذا يعني أن موضع خطر التسوية للموقع 1 (في حالة وجوب معالجة المعاملة) -5100 جنيه انجليزي وسوف تتخطى بالتالي الغطاء ‎Slay!‏ بمقدار -5000 جنيه انجليزي معينة إلى البنك أ على موقع 1. بالتالي»؛ سوف يتم رفض المعاملة 3.
0 مع ذلك؛ أخذا بالاعتبار أن موضع خطر التسوية الكلي للبنك أ لحين الوصول إلى المعاملة 3 فقط -2800 جنيه انجليزي وبحيث تكون الإيداعات الكلية المتاحة للبنك أ -7200 جنيه انجليزي؛ يجب معالجة المعاملة 3. وهذا يعني توفير مرونة إضافية لحالات فشل التقنية لإيقاف المعاملات التي سيتم السماح بها. تهدف النماذج إلى مناقشة هذه المشاكل كما هو موضح الآن. الشكل 3ب يبين مثال على نماذج الكشف. في المثال؛ يظل الغطاء الائتماني 651 عند -10000
5 جنيه انجليزي. بشكل مشابه للمثال المبين في الشكل 3ا؛ في المثال الخاص بالشكل 3ب؛ يتم شق الغطاء الائتماني 651 بالتساوي بين اثنين من المواقع. بمعنى آخرء يتضمن الموقع 1 ‎slat‏ ‎Slat)‏ بمقدار -5000 جنيه انجليزي وموقع 2 له غطاء ائتماني بمقدار -5000 جنيه انجليزي. في مثال مشابه لذلك الخاص بالشكل ‎¢f3‏ تصل المعاملة 1 عند الموقع 1 وهو عبارة عن ائتمان بمقدار -2500 جنيه انجليزي. بالتالي؛» موضع خطر التسوية عند موقع 1 للبنك أ يبلغ 2500
0 جنيه انجليزي وموضع خطر التسوية للبنك أ عند موقع 2 يبلغ 0 بما يعني أن موضع خطر التسوية الكلي للبنك أ عبر كلا الموقعين يبلغ 2500 جنيه انجليزي. تقل الإيداعات المتاحة الأخرى للموقع 1 إلى -2500 جنيه انجليزي وتظل الإيداعات المتاحة للموقع 2 عند -5000 جنيه انجليزي. بالتالي تبلغ الإيداعات الكلية المتاحة بالتالي -7500 جنيه انجليزي. لاحظ أن حسابات ‎lay)‏ المتاح غير مبينة في الشكل 3آب.
5 بعد ذلك تصل المعاملة 2 عند الموقع 2 وهي عبارة عن دين بمقدار -300 جنيه انجليزي. بالتالي» يظل موضع خطر التسوية للبنك أ عند موقع 1 عند -2500 جنيه انجليزي»؛ يبلغ موضع
خطر التسوية للبنك أ عند موقع 2 -300 جنيه انجليزي وببلغ موضع خطر التسوية الكلي - 0 جنيه انجليزي. علاوة على ذلك؛ تقل الإيداعات المتاحة للموقع 2 إلى -4700 جنيه انجليزي وتظل الإيداعات المتاحة للموقع 1 عند -2500 جنيه انجليزي. بالتالي تبلغ الإيداعات الكلية المتاحة للبنك ‎A‏ بالتالي -7200 جنيه انجليزي.
كما هو موضح بالإشارة إلى الشكل 3؛ إذا وصلت المعاملة 3 (دين بمقدار 2600 جنيه انجليزي) عند موقع مفتاح 1؛ سوف يتم رفض المعاملة كموضع خطر التسوية للموقع 1 يتخطى الغطاء ‎Sle)‏ بمقدار 5000 جنيه انجليزي معينة إلى الموقع 1. لتجنب هذه المشكلة؛ يتم تنفيذ دورة تعديل ‎adjustment cycle‏ دورية في النظام. تحديداء يتم تنفيذ دورة التعديل 656 ‎Led‏ بواسطة المفاتيح عند المواقع 1 و2. تتضمن دورة التعديل حساب قيمة تعديل بواسطة حساب الأحجام
0 الكلية لموضع خطر التسوية عند كل موقع. ذلك أن؛ الحجم الكلي لموضع خطر التسوية 1 بمقدار -2500 جنيه انجليزي والحجم الكلي لموضع خطر التسوية 2 بمقدار -300 جنيه انجليزي والتي يتم حسابها لإعطاء -2800 جنيه انجليزي. وهذا الناتج بعد ذلك بمتوسط عبر رقم المواقع. في هذه الحالة؛ يبلغ المتوسط عبر اثنين من المواقع -2/2800 = -1400 جنيه انجليزي. بالطبع؛ هناك قيم متوسطة أخرى؛ يمكن مثلا استخدام قيمة متوسطة أو ما شابه. غرض تحديد متوسط
5 موضع خطر التسوية عبر كل المواقع في النظام (في هذه الحالة؛ المواقع 1 و2)؛ والتي تقوم بفاعلية بموازنة مسئوليات البنك بين كل مواقع المفتاح. وهذا يعني أن موقع مفتاح واحد يتلقى معاملات بقيمة كبيرة جدا مقارنة بمواقع المفتاح الأخرى؛ بعد ذلك لن يتم تخطي الغطاء ‎SEY)‏ ‏للنظام 100 (ما لم يتم تخطي الغطاء الائتماني للبنك عبر كل المفاتيح). لحساب قيمة التعديل المستخدم مع موقع مفتاح معين؛ يتم استخدام موقع التعديل؛ يتم استخدام
0 المعادلة التالية: ‎adjustment _ site = averaged_ SRP— SRP‏ حيث موقع التعديل ‎Sle‏ عن ‎dad‏ تعديل مستخدمة مع موقع مفتاح معين؛ متوسط موضع خطر التسوية هو متوسط موضع خطر التسوية عبر مواقع المفتاح في النظام وموضع خطر التسوية هي موضع خطر التسوية عند موقع مفتاح معين.
5 باستخدام هذه المعادلة؛» سوف تتم ‎Lj)‏ أن التعديل عند موقع 1 = -2/2800-(-2500) +=1100 والتعديل عند ‎alge‏ 2 = -2/2800-(-300) = -1100
بالتالي؛ يتم تعديل موضع خطر التسوية لموقع معين بواسطة ‎dad‏ التعديل. لا تؤثر ‎dad‏ التعديل هذه على موضع خطر التسوية الكلي للبنك (بالتالي لا تسمح للبنك بتخطي الغطاء الائتماني الكلي). بدلا من ذلك؛ يتم استخدام ‎dad‏ موضع خطر التسوية المعدلة لنشر مسئولية البنك عبر كل مواقع المفتاح.
بشكل أكثر رسمية؛ موضع خطر التسوية المعدل = قيمة موضع خطر التسوية + موقع التعديل بالتالي؛ في حالة الشكل 3ب؛ بعد تنفيذ دورة التعديل» موضع خطر التسوية المعدل للموقع 1 = - 11000 = -1¢400 جنيه انجليزي وموضع خطر التسوية المعدل للموقع 2 = -300+- 0 --400 [جنيه انجليزي. بمعنى ‎«AT‏ فعالية موضع خطر التسوية عند كل موقع هي
0 إذا كان إجمالي موضع خطر التسوية المعدل والمعاملة الجديدة لا تتخطى الغطاء الائتماني على الموقع» بعد ذلك يتم اعتماد المعاملة الجديدة. مع ذلك؛ إذا كان إجمالي موضع خطر التسوية المعدل والمعاملة الجديدة لا تتخطى الغطاء الائتماني على الموقع؛ بعد ذلك يتم رفض المعاملة الجديدة. الآنء بالإشارة إلى الشكل 3ب؛ باستخدام موضع خطر التسوية معدل الموقع 1 (-1400 جنيه
5 انجليزي)؛ ومبلغ المعاملة 3 المعاملة الجديدة. (-2600 جنيه انجليزي)؛ المبلغ الكلي -4000 جنيه انجليزي. وهذا لا يتخطى غطاء ائتماني بقيمة -5000 جنيه انجليزي للموقع 1؛ ويتم السماح بذلك بالتالي بواسطة النظام 100. بالتالي؛ بهذه الطريقة؛ يتم استخدام قيم التعديل لكل موقع لتقليل فرصة مبلغ المعاملة المتاح (حيث؛ مبلغ المعاملة المسموح به بواسطة الغطاء الائتماني الكلي) المرفوضة على أساس الإيداعات المتاحة عند موقع مفتاح فردي.
0 في نماذج؛ تتم دورة التعديل (لحساب ‎dad‏ تعديل جديدة) دوريا. يمكن أن تكون المدة مؤقتة؛ مثلا كل 20 أو 30 ثانية؛ أو يمكن أن تكون بعد موقع يقوم بالتعامل مع عدد من المعاملات أو حتى عندما تتخطى موضع خطر التسوية عند موقع مبلغ محدد سلفا. في ‎Als‏ فشل موقع؛ يمكن زيادة الغطاء الائتماني عند كل موقع متبقي بحيث تكون القيمة الكلية للغطاء الائتماني متاحة. بحيث؛ مثلاء إذا كان الموقع 2 سيفشل؛ بعد ذلك يمكن تعيين الغطاء
‎slay) 5‏ الكلي -10000 جنيه انجليزي غطاء ائتماني إلى موقع 1 بحيث يمكن أن تستمر معالجة المعاملات للمبلغ الكلي إلى قيمة الغطاء الاثتماني الكامل.
تمت ملاحظة أن قيمة موضع خطر التسوية الفعلية لكل موقع (بالتالي؛ في المثال ‎all‏ - 0 لموقع 1 و-300 للموقع 2؛ بعد تنفيذ كل المعاملات في الشكل 3ب) مهمة لأن ‎dad‏ ‏موضع خطر التسوية عند موقع تساوي مبلغ المال الناتج عن (إذا كانت موضع خطر التسوية إيجابية) أو الناتج بواسطة (إذا كان موضع خطر التسوية سلبيا) البنك بعد المعاملات عند هذا الموقع. يجب أن تظل ‎dad‏ موضع خطر التسوية الفعلية عند كل موقع بالتالي غير متغيرة بحيث يمكن استخدامها لضمان أن التسوية قد تم تنفيذها بشكل صحيح. بالتالي لا يزال يتم تخزين قيمة موضع خطر التسوية الفعلية لكل موقع عند أي وقت معين عند موقعه ‎labial‏ على الرغم من أن ‎dad‏ موضع خطر التسوية المعدلة التي يتم استخدامها في ضمان أن الغطاء ‎Sa)‏ الكلي لم يتم تخطيه. تمت ملاحظة أن للحفاظ على موضع خطر التسوية عند كل موقع دقيقا قدر الامكان» سوف يتم تحديثه للبنك المرسل بعد رسالة طلب المعاملة الخاصة بالمعالجة الناجحة وبتم التحديث لاستلام البنك بعد معالجة رسالة تأكيد معاملة أولى بشكل ناجح. تطبيق بوابي كما هو مذكور ‎lad‏ تساعد البوابة 104 104ب لكل بنك على التحكم في نقل الرسائل بين هذا البنك والمفاتيح ‎SW 2 SW »1 SW‏ 3 و5177 4. تقوم كل بوابة 104أ 104ب بتنفيذ عدد من 5 الوظائف نيابة عن كل من البنك والمفاتيح لتقليل جهد المعالجة عند البنوك والمفاتيح. يمكن ملاحظة أن استخدام التطبيق البوابي في النظام الكلي اختياري. مع ذلك؛ إذا كانت البوابة غير مستخدمة بشكل اختياري؛ يجب أن يكون التطبيق المصرفي 102أ؛ 102ب قابل على تنفيذ التحقيق البنيوي (انظر أدناه - تحديدا؛ الخطوة 906 وفقا للشكل 4)؛ توقيع وإرسال والتحقق من الرسالة (مرة ‎«(gyal‏ انظر أدناه - تحديدا الخطوات 910 912 و914 وفقا للشكل 4)؛ توجيه 0 رسائل وإضافة معلومات تكرار رسالة طلب المعاملة (متى أمكن - انظر أعلاه) مع الوظيفية المشابهة. تتعلق إحدى وظائف البوابة عندما يود البنك (بناء على تعليمات حامل الحساب عند هذا البنك) للمعاملة لتتم معالجتها بواسطة النظام 100. سوف يقوم كل بنك بشكل عام باستخدام نظام امتلاك مختلف لإدارة حساباته وللسماح لحاملي الحساب بإصدار تعليمات للمعاملات وما شابه. مع ذلك؛ 5 الأسباب الفعالية؛ يجب أو تتوافق رسائل المعاملة المعالجة بواسطة المفاتيح مع بنية معيارية معينة (أو صيغة؛ ‎Jie‏ معبار أيزو 20022 كما هو مذكور فعلا). ‎(Jal‏ أي رسالة معاملة تم
إصدارها بواسطة حامل حساب عندما يجب على البنك أن يقوم بأخذ صورة لنوع معيار رسالة معاملة ليتم قبولها بواسطة المفاتيح. علاوة على ذلك؛ لأسباب الأمان؛ قد يكون من الضروري أن تتم إرسال رسالة معاملة بين البنك والمفاتيح رقميا ويتم التحقق منها (باستخدام توقيع رقمي) لضمان أن مصدر الرسالة شرعي.
يتم تنفيذ عملية فحص بنية رسائل المعاملة بواسطة البوابة. علاوة على ذلك؛ يتم تنفيذ توقيع الرسائل ليتم نقلها من البنك إلى المفاتيح (يتم التحقق من هذه الرسائل بالتالي بواسطة المفتاح المستلم) والتحقق من الرسائل المرسلة من المفاتيح إلى البنك (هذه الرسائل موقعة سلفا بواسطة المفتاح المرسل) باستخدام البوابة. حيث؛ البوابة الخاصة بالبنك تقدم سطح انتقال بيني بين نظام الملكية لذلك الخاص بالبنك والمفاتيح لضمان أن رسائل المعاملة موقعة رقميا ويتم التحقق منها
0 وتتوافق مع البنية المعيارية المطلوية. يمكن استخدام أي معيار مناسب لبنية رسالة المعاملة والتوقيع الرقمي والتحقق. هذه المعايير معروفة للخبير في المجال. ثمة طريقة مثالية على التوقيع الرقمي وبقوم التحقق باستخدام بيانات عنوان الرسالة (المعنونة باستخدام (خوارزمية التجزئة الآمنة ‎(SHAT (Secure Hash Algorithm 1( )1‏ والتي يتم تشفيرها بعد ذلك (باستخدام تشفير (ريفست - شامير - أدلمان) ‎ull (RSA (Rivest-Shamir-Adleman)‏ في نماذج؛ يتم
صف ‎dibs)‏ المعاملة المطلوب معالجتها بواسطة البوابات 1104 104ب؛ على التوالي؛ في صفوف الرسائل 106 106ب. إذا لم يتم توفير البوابة 1104 21045« سوف يحتاج التطبيق ‎Sul‏ 10251102 إلى توفير هذه الوظيفية. تقوم البوابة أيضا بتوجيه الرسائل إلى مواقع المفتاح بواسطة إضافة معلومات توجيه إلى مقدمة كل رسالة والتي تتم قراءتها بعد ذلك بواسطة صفوف الرسائل 1106 106« 1108 108ب لتوجيه
0 الرسالة إلى موقع المفتاح المناسب. ‎Ole‏ في المثال وفقا للشكل 1؛ يمكن تعليم صف الرسالة 8 المعلمة أم كيو ‎MQ‏ 1 ويمكن تعليم صف الرسالة 108 ب ‎MQ‏ 2. تتم إضافة العلامة ‎MQ‏ ‏1 أو ‎MQ‏ 2 بالتالي إلى مقدمة كل رسالة سيتم إرسالها إلى موقع مفتاح بواسطة البوابة بحيث يمكن أن يقوم صف الرسالة 106 106ب بتوجيه الرسالة إلى موقع المفتاح المناسب. يمكن ‎Load‏ تصور أن ‎idl‏ يمكن أن يتضمن وحدة صف رسائل ‎F106‏ 106ب عديد جوانب البنك
5 (ثلاء يمكن أن يتضمن البنك 1 العديد من صفوف رسائل الجانب البنكي 11106 21106 ...؛ 6 - غير مبين) وأن معلومات التوجيه المضافة بواسطة البوابة يمكن أن تتضمن معلومات
تقوم بتحديد أي وحدة صف رسائل الرسالة ذات جانب بنكي يتم توجيهها إليه. بشكل مفيد؛ يساعد هذا مع حمل بيانات ‎data load‏ تتوازن في النظام 100. كنموذج ‎Jia‏ ¢ يتم شرح إرسال عملية البوابة 1104 للبنك 1 وللمفتاح؛ عند إرسال رسالة من البنك 1 إلى المفتاح؛ بالإشارة إلى العملية المبينة في الشكل 4. ‎fas‏ العملية عند الخطوة 900. عند الخطوة 902 تتلقى البوابة 1104 رسالة معاملة من التطبيق المصرفي 102 للبنك 1 التي سيتم نقلها إلى واحد من المفاتيح للمعالجة. عند الخطوة 904 تقوم البوابة 1104 بتحليل بنية رسالة المعاملة. تحديدا» تضمن البوابة 104 أن الرسالة لها البنية المعيارية الضرورية للمعالجة بواسطة المفاتيح. وهذا يتضمن ضمان أن كل المعلومات الضرورية متضمنة في الرسالة. ‎Ole‏ إذا كانت الرسالة تشير بعملية دفع التمويلات من حساب للبنك 1 إلى حساب للبنك 2؛ بتم ضمان أن عملية 0 الدفع والمبلغ والعملة؛» وكود تصنيف البنك وتفاصيل الحساب الخاصة بالبنك 1 وكود تصنيف البنك وتفاصيل الحساب 2 موجودة كلها في الرسالة وبالصورة الصحيحة (حيث هذه المعلومات مطلوية لاكتمال المعاملة). وهي تتضمن فحص ما إذا كانت الرسالة تتضمن أو لا تتضمن معرف فريد للمعاملة وسواء كانت تتضمن الرسالة معلومات توجيه مناسبة. عند الخطوة 906 إذا تم تحديد أن بنية الرسالة تتوافق مع المعيارء بعد ذلك تنتقل العملية على 5 الخطوة 910. على الناحية الأخرى»؛ إذا تم تحديد أن بنية الرسالة لا تتوافق مع المعيار (مثلاء إذا كانت هناك معلومات أساسية مفقودة من الرسالة)؛ بعد ذلك تنتقل العملية إلى الخطوة 908. عند الخطوة 908 يتم إرسال الرسالة عودة إلى البنك 1 مع رسالة خطأً. تقوم رسالة ‎Waal)‏ بإخطار البنك 1 بأن رسالة المعاملة لا تتوافق مع معيار الرسالة ‎message standard‏ وأنه يمكن رفضها مع الخطاً المذكور ‎Die)‏ مع أي معلومات مفقودة معلومات مضافة). تنتهي العملية بعد ذلك عند 0 الخطوة 922. عند الخطوة 910< يتم توقيع رسالة المعاملة بالتوقيع الرقمي للبنك 1. يسمح التوقيع الرقمي للمفتاح المستلم بضمان صحة الرسالة (أي أن الرسالة ‎Law‏ عند البنك 1). عند الخطوة 912؛ يتم إرسال طلب المعاملة بعد ذلك عبر قناة اتصال البيانات بين البنك 1 وموقع المفتاح المناسب (كما هو محدد بواسطة معلومات التوجيه). تمت ملاحظة أن البوابة يتم تنفيذها بواسطة برمجيات تشغيل الدارة ‎circuitry running software‏ المخزنة على وسط تخزين ‎storage medium‏ (غير مبينة) عند موقع البنك 1. بشكل ‎cube‏ يسمح هذا الترتيب بفحص وتقل رسالة المعاملة للتعامل بشكل مكتمل
بواسطة دارة البوابة ‎gateway circuitry‏ بالتالي يتم تقليل حمل المعالجة عند كل من نظام الملكية للبنك 1 وموقع المفتاح. وهذا بسبب أن الرسائل التي لا تحتوي على المعلومات الصحيحة لا يتم توجيهها إلى موقع المفتاح. علاوة على ذلك يمكن تصور أن البوابة ‎(Sa‏ توفيرها في نظام (كما يمكن أن تقتضي الحال)؛ سوف يقوم التطبيق البنكي بتوفير رسائل موقعة ‎digitally signed dad)‏ ‎messages 5‏ تحتوي على كل المعلومات ذات الصلة والتي تم توفيرها في الصورة المناسبة. بمجرد استلام الرسالة بواسطة المفتاح عند موقع ‎oz ball‏ يمكن التحقق باستخدام التوقيع الرقمي. يتم هذا عند الخطوة 914. كما هو مذكور فعلا؛ تساعد خطوات التوقيع الرقمي والتحقق (الخطوات 910 9145 على التوالي) على ضمان أن أي رسالة معاملة مستلمة بواسطة المفتاح أصلا من واحد من البنوك المسجلة لاستخدام النظام 100. يمكن أن يتم التحقق من التوقيع عند المفتاح الذي 0 يتلقى الرسالة أولا أو؛ بشكل بديل؛ المفتاح (إن وجد) الذي تتم إليه ‎sale]‏ توجيه الرسالة. عند الخطوة 916؛ إذا كان التحقق من التوقيع الرقمي ناجح؛ بعد ذلك تنتقل العملية إلى الخطوة 0 عند هذه النقطة تتم معالجة رسالة المعاملة بواسطة المفتاح المناسب ‎LS)‏ هو موضح فعلا). تنتهي العملية بعد ذلك عند الخطوة 922. على الناحية الأخرى؛ إذا كان التحقق من التوقيع الرقمي غير ناجح؛ بعد ذلك يتضمن هذا أن رسالة المعاملة يمكن أن تتضمن خطأً أو ما شابه مرتبطة بها. تنتقل العملية بالتالي إلى الخطوة 918؛ حيث تتم ‎sale)‏ رسالة المعاملة إلى البنك المرسل. في هذه الحالة؛ يتم توليد معلومات التي تشير إلى أن هناك خطأً في عملية التحقق بواسطة المفتاح الذي قام بتنفيذ عملية التحقق وعادت مع (أو كجزءِ من) رسالة المعاملة. بشكل ‎cade‏ يقوم هذا بإخطار أن البنك المرسل أن هناك مشكلة مع رسالة المعاملة؛ ويمكن أن يقوم البنك المرسل بالتالي بفحص هذا. تنتهي العملية بعد ذلك عند الخطوة 922. بشكل مفيد؛ يساعد التحقق 0 -من التوقيع الرقمي لكل رسائل المعاملة القادمة على منع رسائل النصب أو التعارض (مثلا من طرف غير مصرح له الذي يحاول إصدار تعليمات للمعاملة) من المعالجة. بالتالي؛ يساعد استخدام البوابة لضمان أن كل رسائل المعاملة المستلمة بواسطة مفاتيح المعالجة من نوع بنية معيارية صحيحة. تتضمن المفاتيح بالتالي فقط التي تتم تهيئتها للتعامل مع هذه البنية المعيارية الفردية (غير مجموعة من بنيات الرسالة المختلفة الصادرة عن البنوك المختلفة)؛ بالتالي 5 يتم تحسين فعالية النظام 100. علاوة على ذلك؛ لأن الرسائل يتم إرسالها فقط عبر الشبكة من البنوك إلى النظام 100 إذا كانت تتوافق مع بنية الرسالة الصحيحة؛ لا يتم تضييع نطاق الشبكة
على إرسال رسائل لا تتضمن بنية الرسالة الصحيحة (والتي يجب رفضها بالتالي) إلى المفاتيح. كميزة ‎(Al‏ يساعد التوقيع الرقمي والتحقق على التنفيذ بواسطة البوابة والمفاتيح على تحسين عملية تأمين النظام. كما هو مذكور سلفاء في نماذج؛ يتم تنفيذ كل بوابة 104 104ب بواسطة برمجيات تشغيل الدارة المخزنة على وسط تخزين (غير مبينة) موجودة عند موضع البنك ذو الصلة. سوف يتم فصل هذه البرمجيات وظيفيا مع أي برمجيات تقوم بتنفيذ الوظائف الداخلية عند كل بنك (مثلا؛ النظام عند كل بنك لإدارة الحسابات والتطبيق المصرفي للسماح لحاملي الحساب لإصدار تعليمات للمعاملات وما شابه) وأي برمجيات تقوم بتنفيذ الوظائف الداخلية عند مواقع المفتاح (مثلاء أي برمجيات تم تنفيذها بواسطة المفاتيح ‎SW 3 SW 2 SW 1 SW‏ 4 صفوف الرسائل 1108 2108« إلخ.). بشكل مفيد؛ يسمح هذا بتحقيق فوائد وظائف البوابة (الفعالية والأمان الزائد. كما هو موضح أعلاه) دون زيادة حمل المعالجة ‎processing load‏ اللبي عند البنوك أو عند مواقع المفتاح. تتعلق الوظيفة الثانية للبوابة 104 104ب بمراقبة أي من البنوك وأي من مواقع المفتاح متاح لإرسال واستلام الرسائل ولموازنة حمل البيانات الخاص بالنظام 100. إذا لم يتم توصيل رسالة إلى موقع مفتاح عبر وحدة صف الرسائل ذات الصلة 106أ 2106« 5 1108 108ب في مدة زمنية محددة سلفاء بعد ذلك تقوم ‎sang‏ صف الرسالة ذات الصلة بإضافة معلومات إلى مقدمة ‎All‏ التي تشير إلى أن وقت الجمع قد انتهى ويعيد الرسالة إلى البوابة. يمكن أن يتم هذاء ‎Olde‏ لأن وحدة صف الرسالة 108أ؛ 108ب لموقع المفتاح تفشل في التقاط الرسالة من ‎Bang‏ صف الرسالة ذات الصلة 1106( 106ب في المدة الزمنية المحددة سلفاء أو لأن المفتاح عند موقع المفتاح يفشل في التقاط الرسالة من ‎Bang‏ صف الرسالة ذات الصلة ‎J108‏ ‏0 108ب في المدة الزمنية المحددة سلفا. هناك تشكيلة من الأسباب وراء ذلك؛ شاملة فشل ‎Sang‏ ‏صف الرسالة 1108 108ب عند موقع المفتاح؛ فشل المفاتيح أو فشل الشبكة. في هذه الحالة؛ تقوم البوابة بإعادة إرسال الرسالة إلى الموقع البديل. لذلك؛ ‎lie‏ إذا لم يكن أي من ‎SW 1 SW‏ 2 عند موقع مفتاح 1 يقوم بالتقاط رسالة في المدة الزمنية المحددة سلفاء بعد ذلك؛ عند استلام الرسالة العائدة» سوف تقوم بوابة ‎lid)‏ المصدر للتعليمات بإعادة توجيه الرسالة إلى موقع مفتاح 2. تكمن المشكلة مع ذلك؛ مع ذلك؛ هي أنه إذا كان؛ ‎lie‏ كل المفاتيح عند موقع مفتاح معين لمدة ممتدة من الزمن؛ بعد ذلك هذه الطريقة الخاصة بإعادة توجيه الرسائل حساسة للمعالج وتقوم
بتضييع نطاق الشبكة. وهذا لأنه يتم إرسال الرسائل بشكل مستمر إلى موقع غير ‎hail‏ فقط
لرسائل الخطأً التي سيتم إرسالها بالتالي. ‎(Jilly‏ يمكن أن تصبح الأنظمة الداخلية عند واحد أو أكثر من البنوك بشكل مؤقت غير متاحة لاستلام الرسائل. ‎Olde‏ في المثال وفقا للشكل 1؛ يمكن أن يصبح البنك 2 غير متاح لاستلام رسالة معلومات المعاملة تقوم بإخطار البنك 2 بتوقع عملية دفع التمويلات من البنك 1 في حالة إصدار رسالة معاملة رسالة طلب المعاملة بواسطة حامل حساب عند البنك 1 للدفع لحامل حساب للبنك 2. في هذه الحالة؛ لا يتم استلام رسالة تأكيد معاملة أولى من البنك 2 بعد إرسال رسالة معلومات المعاملة إلى التطبيق المصرفي 102ب؛ ولا يمكن بالتالي إكمال المعاملة. مرة أخرى؛ مع ذلك؛ إذا كان البنك 2 غير متاح لمدة ممتدة من الزمن؛ بعد ذلك هذه الطريقة الخاصة بإكمال
0 إرسال رسائل رسالة معلومات المعاملة إلى البنك 2 عبارة عن مشكلة لأنه حساس للمعالج 070 وبقوم بتضييع نطاق الشبكة. وهذا لأن الرسائل يتم إرسالها بشكل مستمر إلى البنك غير النشط. لتخفيف هذه المشاكل؛ تتم تهيئة البوابة 104 104ب لكل بنك للحفاظ على تتبع أي من البنوك ومواقع المفتاح متاحة لاستلام الرسائل. ويتم تحديد هذا بذاكرة الإتاحية المؤقتة.
5 فيما يتعلق بمراقبة مواقع المفتاح؛ تقوم بوابة بذلك بواسطة إرسال رسالة اختبارية ‎test message‏ إلى موقع مفتاح عبر الشبكة عبر وحدة صف الرسالة 1108 108ب لموقع المفتاح هذا والاستماع للإشارة المرتدة ‎echo‏ لتلك الرسالة العائدة من موقع المفتاح. سوف تقوم بوابة بشكل مثالي بذلك إذا لم تتلق رسالة من موقع مفتاح معين لمدة معينة من الزمن. الإشارة المرتدة (بشكل أكثر تحديدا المعروفة بالإشارة المرتدة عن بعد) عبارة عن نسخة من الرسالة الاختبارية المرسلة إلى موقع
0 المفتاح الذي تم إرساله من موقع المفتاح عودة إلى البوابة. يتم إصدار الإشارة المرتدة بواسطة واحد من المفاتيح عند مواقع المفتاح وفقا للتعليمات المتضمنة في الرسالة الاختبارية. إذا كان في استجابة لإرسال الرسالة الاختبارية لموقع مفتاح معين» تتلقى البوابة إشارة مرتدة لتلك الرسالة في مدة زمنية محددة سلفا (مثلاء مدة من الزمن تساوي مهلة استلام رسالة تأكيد معاملة ثانية)؛ بعد ذلك تعرف البوابة أن موقع المفتاح لا يزال متاح لاستلام رسائل عبر وحدة صف الرسالة ‎F108‏
5 108ب. على الناحية ‎(AY)‏ إذا لم يتم استلام إشارة مرتدة؛ بعد ذلك تحدد البوابة أن موقع
المفتاح غير متاح لاستلام الرسائل (ريما بسبب خطأ) عبر وحدة صف الرسالة 108أ 108[ب؛
وبالتالي تمنع نقل المزيد الرسائل من إلى موقع المفتاح عبر هذا المسار. في حالة قيام البوابة بإرسال رسالة اختبارية إلى موقع مفتاح بالطريقة الموضحة أعلاه و؛ بعد مدة محددة سلفا من الزمن» لا تتلقى إشارة مرتدة عائدة؛ تقوم البوابة بتحديد أن الاتصال بموقع المفتاح عبر وحدة صف الرسالة 108 108ب غير متاح. ذلك لأن؛ إذا كان هذا المسار متاح؛ بعد ذلك سوف تصل الرسالة الاختبارية أخيرا عند المفتاح عند موقع المفتاح؛ وأن المفتاح سوف يقوم بتوليد نسخة للرسالة الاختبارية التي ستتم إعادتها إلى البوابة كإشارة مرتدة. في حالة عدم تلقي إشارة مرتدة» لا تقوم البوابة بعد ذلك بتوجيه رسائل إلى موقع المفتاح عبر وحدة صف الرسالة 108ا؛ 8 ب الخاصة بها. بمعنى آخر؛ يتم تحديد موقع المفتاح ليكون غير متاح. بالتالي تتحكم البوابة
0 في التوزيع التالي للرسائل بمجرد تحديد واحد من مواقع المفتاح على أنه غير متاح. سوف تقوم البوابة أيضا بتحديد أن موقع المفتاح غير متاح إذا كانت رسالة طلب المعاملة عادت إلى البوابة من موقع مفتاح لأنه لم يتم التقاطه بواسطة المفتاح عند موقع المفتاح في مدة زمنية محددة سلفا (انظر الوصف أعلاه). مرة أخرى» في هذه الحالة؛ لن تقوم البوابة بتوجيه الرسائل إلى موقع المفتاح هذا عبر وحدة صف الرسالة 1108( 108ب عند هذا الموقع.
5 للتوضيح؛ تمت ملاحظة أنه إذا كان موقع المفتاح محدد ‎ash‏ غير متاح بواسطة البوابة؛ بعد ذلك لا يعني هذا بالضرورة أن المفاتيح عند موقع المفتاح غير متاحة. أيضاء تتضمن أن الرسائل لا يمكن إرسالها إلى المفاتيح عند موقع المفتاح عبر وحدة صف الرسالة 108 108ب عند موقع المفتاح هذا. مثلاء يمكن أن تكون ببساطة هي الحالة حيث هناك فشل في الشبكة والذي يمنع رسائل النقل إلى المفاتيح عند موقع مفتاح معين عبر وحدة صف الرسالة 108( 108ب؛ ولكن لا
تزال هذه المفاتيح عند موقع المفتاح عاملة كليا. في هذه الحالة؛ يمكن أن تظل هذه الرسائل موجهة إلى المفاتيح عبر موقع المفتاح الآخر وموقع رابط اتصال البيانات البيني ‎inter-site data‏ ‎Dis) communication link‏ وفقا لوظيفة العنونة). عند تحديد ‎alge‏ مفتاح على أنه غير متاح (إما بسبب الحاجة إلى إشارات مرتدة ‎echoes‏ التي يتم استلامها عند البوابة أو بسبب رسالة طلب المعاملة تتم إعادتها إلى البوابة)؛ يتم إرسال الرسائل
5 الاختبارية ‎test messages‏ دوري إلى موقع المفتاح عبر وحدة صف رسالة 1108 108ب الخاصة بها لتحديد ما إذا كانت أو لم تكن متاحة. إذا كان موقع المفتاح لا يزال غير متاح؛ لن يتم بالتالي
تلقي إشارات مرتدة؛ وسوف تستمر الرسائل بالتالي إلى موقع المفتاح. على ‎ald)‏ الأخرى؛ إذا تمت استعادة إتاحية موقع المفتاح ‎Mie)‏ بعد إكمال الإصلاح أو الصيانة)؛ بعد ذلك؛ عند إرسال الرسالة الاختبارية التالية إلى ‎alge‏ المفتاح» سوف يتم تلقي إشارة مرتدة عائدة. في هذه الحالة؛ تقوم البوابة بتحديد أن موقع المفتاح متاح مرة أخرى؛ ويسمح للرسائل بأن يتم إرسالها إلى موقع المفتاح هذا عبر وحدة صف الرسالة 1108 108ب. سوف تقوم البوابة ‎Lad‏ بتحديد أن موقع المفتاح المحدد بأنه غير متاح مرة أخرى في حالة استلام رسالة المعاملة ‎lie)‏ رسالة معلومات المعاملة) من موقع المفتاح هذا (حيث هذه الرسالة لا يمكن استلامها إذا كان موقع المفتاح لا يزال غير متاح).فيما يتعلق بمراقبة البنوك الأخرى؛ تعتمد بوابة البنك على المعلومات الصادرة بواسطة المفاتيح و/أو من معلومات يمكن استنتاجها منن إيصال رسالة تأكيد معاملة ثانية للمعاملات إلى 0 بنوك معينة. بشكل أكثر تحديدا» يمكن أن تقوم كل من المفاتيح بإرسال رسالة اختبارية دوريا إلى كل البنوك باستخدام النظام 100 والانتظار لاستلام إشارة مرتدة من كل من هذه البنوك. إذا لم يتم استلام إشارة مرتدة من بنك معين في مدة زمنية محددة سلفا عند مفتاح معين؛ بعد ذلك سوف يتم تحديد أن البنك غير متاح لاستلام رسائل من هذا المفتاح المعين (ريما بسبب وصلة 5 شبكية خاطئة ‎faulty network connection‏ بين هذا المفتاح والبنك). في هذه الحالة؛ سوف تتم إعادة توجيه رسائل رسالة معلومات المعاملة إلى البنك من هذا المفتاح عبر مسار بديل ‎Nie)‏ ‏عبر المفتاح الآخر عند موقع المفتاح أو حتى عبر واحد من المفاتيح عند موقع المفتاح البديل عبر وصلة موقع البيانات البينية ‎cad. (inter-site data connection‏ ملاحظة أن ؛ في هذه الحالة؛ المفتاح نفسه لا يزال يعمل ويمكن بالتالي تلقي رسائل وفقا لوظيفة العنونة ومعالجة هذه الرسائل. 0 المشكلة فقط هي الإرسال الفعلي للرسائل رسالة معلومات المعاملة إلى البنك محل الاستفهام؛ والتي يتم التغلب عليها بواسطة ‎sale)‏ توجيه الموضحة هنا. لاحظ أن هذا لا ينطبق على رسالة تأكيد معاملة ثانية؛ بالتالي؛ كما هو موضح فعلاء يجب إرسال رسالة تأكيد معاملة ثانية ‎sage‏ إلى البنك المرسل الذي يقوم بإصدار طلب المعاملة عبر نفس المفتاح الذي يتم عنده استلام رسالة طلب المعاملة أصلا (ليس المفتاح المحدد بواسطة وظيفة العنونة). في حالة أن الاتصال بين هذا 5 المفتاح الأصلي والبنك المرسل معطل؛ لا يمكن إرسال رسالة تأكيد معاملة ثانية إلى البنك المرسل عبر هذا المفتاح. يجب بالتالي أن ينتظر النظام لإعادة إرسال رسالة طلب المعاملة من البنك
— 1 4 — المرسل حيث؛ في حالة أن الاتصال بين المفتاح الأصلي وبظل البنك المرسل معطلا سوف يتم توجيهه إلى مفتاح مستلم بديل والذي يتضمن اتصال مع البنك المرسل عبر صفوف الرسائل المناسبة 106 2106« 108( 108[ب. سوف تتم إعادة توجيه رسالة طلب المعاملة بعد ذلك إلى مفتاح المعالجة (وفقا لوظيفة العنونة)؛ بما يؤدي إلى إعادة إرسال رسالة تأكيد معاملة ثانية وإرسال رسالة تأكيد معاملة ثانية هذه ‎sage‏ إلى البنك المرسل عبر المفتاح المستلم البديل. في حالة فشل كل المفاتيح لاستلام إشارة مرتدة من بنك محدد؛ سوف يتم تحديد أن البنك ككل غير متاح (حيث؛ أنها غير متاحة لاستلام رسائل من أي مفتاح)؛ وتتم إحالة المعلومات عودة إلى بوابة البنوك الأخرى. علاوة على ذلك؛ فى حالة؛ ‎Sle‏ الصيانة المخطط لها للأنظمة الداخلية للبنك؛ يكون كل بنك 0 1 يستخدم النظام 00 1 قادرا على فصل النظام 00 1 . في هذه الحالة؛ سوف يقوم البنك بالفصل عمدا (أو؛ بمعنى ‎SAT‏ الخروج) من المفاتيح» وسوف تتم إحالة واحد أو أكثر من معلومات المفاتيح إلى بوابة كل البنوك الأخرى التي تشير إلى أن البنك الذي خرج غير متاح. علاوة على ذلك؛ في حالة أن البنك غير متاح (بسبب الحاجة إلى استجابات إشارة مرتدة للرسائل الاختبارية من كل المفاتيح أو بسبب الخروج)؛ يمكن أن يقوم المفتاح الذي يتلقى رسالة طلب 5 المعاملة التي تصدر تعليمات بالمعاملة الخاصة بالتمويلات إلى البنك غير المتاح بتوليد رسالة تأكيد معاملة ثانية ويرس رسالة تأكيد معاملة ثانية ‎sage‏ إلى البنك المرسل. وهذه رسالة تأكيد معاملة ثانية مختلفة عن رسالة تأكيد معاملة ثانية المعتادة ‎Lo‏ يشير إلى معاملة ناجحة لأنها تحتوي على معلومات لإخطار البنك المرسل بأن البنك المستلم غير متاح وأن المعاملة لم تتم معالجتها بالتالي بنجاح (في هذه الحالة؛ يمكن إعادة تعويض الحساب المختصم منه عند البنك 0 المرسل). تحديداء سوف تحتوي رسالة تأكيد معاملة ثانية على بيانات تشير إلى سبب رفض المعاملة ‎Ole)‏ الكود السبب الذي يشير إلى ‎Jad‏ الشبكة عند البنك المستلم؛ كما هو مشار ‎all‏ ‏بواسطة الحاجة إلى إشارات مرتدة التي يتم ‎gail‏ أو كود السبب الذي يشير إلى أن البنك المستلم قد خرج). يمكن أن تقوم البوابة عند البنك المرسل بالتالي باستخدام رسالة تأكيد معاملة ثانية لتحديد أن البنك المستلم غير متاح حاليا. تمت ملاحظة أن المفاتيح سوف تكون على علم بالبنك غير 5 المتاح بسبب الحاجة إلى إشارات مرتدة يتم تلقيها أو بسبب ‎lid)‏ المنفصل من المفاتيح؛ كما هو مذكور سلفا. على الرغم من أن عملية التحديد بواسطة المفاتيح أن البنك غير متاح خلال استخدام
إشارات مرتدة أو خلال إجراء خروج البنك سوف تتم إحالتها إلى كل من البنوك الأخرى؛ يشير استخدام رسالة تأكيد معاملة ثانية إلى طلب معاملة فاشلة مع بنك معين يقدم طريقة أخرى للبنوك الأخرى لتكون على علم بعدم إتاحيته (وهو ما قد يكون ‎Ole cube‏ إذا كان هناك تأجيل في معيار إحالة هذه المعلومات بواسطة المفاتيح).
سوف تقوم البوابة لكل بنك بتسجيل إتاحية البنوك لبعضها البعض ‎Sia)‏ البنك ‎tA‏ متاح؛ البنك 8: متاح البنك ©: غير متاح) وفقا للمعلومات المؤجل بواسطة المفاتيح (تقوم هذه المعلومات على استخدام إشارات مرتدة و/أو إجراء خروج البنك) و/أو استلام رسائل رسالة تأكيد معاملة ثانية التي تشير إلى أن البنك المعين غير متاح. يشكل هذا السجل جزءٍ من ذاكرة الإتاحية المحمول عند كل بنك (تتضمن ذاكرة الإتاحية شاملة معلومات تتعلق بمواقع المفتاح المتاحة). بسبب هذا
0 السجلء يتم تقليل النطاق الضائع بواسطة محاولات لإرسال رسائل إلى البنوك غير المتاحة. مثلاء عندما يطلب عميل البنك م معاملة جديدة خاصة بالتمويلات المطلوية للبنك المحدد ‎al‏ غير متاح (البنك ©؛ ‎lie‏ في هذه الحالة)؛ سوف تقوم البوابة بعد ذلك برفض هذا بحيث لا يتم إرسال رسالة طلب المعاملة أبداء وسوف يتم إخطار الحساب البنكي ‎dela‏ بواسطة التطبيق المصرفي للبنك ‎A‏ بأن البنك المستلم (البنك ©) غير متاح حاليا. يتم تقليل مقدار نطاق ضائع بواسطة
5 إرسال رسائل معاملة خلال النظام 100 إلى البنك غير المتاح بالتالي. عند تحديد أن البنك قد تم تحديده على أنه غير متاح عبر استخدام إشارات مرتدة ‎LS)‏ هو موضح أعلاه)؛ يمكن إرسال الرسائل الاختبارية دوريا إلى البنك غير المتاح لتحديد ما إذا كان أو لم يكن البنك سيصبح متاحا مرة أخرى. إذا بقي البنك غير متاح؛ بعد ذلك لن يتم استلام أي إشارة مرتدة؛ وسوف تستمر الرسائل بالتالي غير مرسلة إلى البنك. على الناحية الأخرى؛ إذا لم تتم استعادة
0 إتاحية البنك ‎Ola)‏ بعد ‎sale)‏ تكوين وصلة شبكة فاشلة)؛ بعد ‎cll)‏ عند إرسال الرسالة الاختبارية ‎Jul‏ إلى البنك» سوف يتم تلقي إشارة مرتدة عائدة. في هذه الحالة؛ تقوم البوابة بتحديد أن ‎lid)‏ ‏متاح مرة أخرى» ويسمح للرسائل بأن يتم إرسالها مرة أخرى إلى هذا البنك. إذا تم تحديد أن البنك غير متاح بسبب خروجه من المفاتيح؛ بعد ذلك سوف يظل البنك غير متاح لحين ‎sale]‏ الاتصال ب ‎og)‏ بمعنى ‎AT‏ يدخل إلى) المفاتيح مرة أخرى. بمجرد عودة البنك إلى
5 المفاتيح؛ سوف يقوم واحد أو أكثر من المفاتيح بإتاحة المعلومات إلى البوابة الخاصة بكل البنوك الأخرى التي تشير إلى أن هذا البنك متاح مزة أخرى.
— 3 4 — بشكل عام؛ يمكن إرسال الرسائل الاختبارية دوريا إلى كل من البنوك بواسطة المفاتيح مع مدة زمنية مناسبة قصيرة بما يكفي لمحاولة تقليل عدد رسائل المعاملة المرسلة إلى البنك غير المتاح؛ بالتالي يتم حفظ النطاق. في الوقت ذاته؛ يجب ألا تكون المدة الزمنية صغيرة بحيث يتم إرسال الرسائل الاختبارية بشكل متكرر بحيث تستخدم المزيد من نطاق الشبكة وبالتالي تقلل فعالية الشبكة (التي تتعارض مع أثر توفير النطاق بفاعلية الخاص باستخدام الرسائل الاختبارية والإشارات المرتدة بالمقام الأول). ‎(JES‏ يمكن أن تكون المدة الزمنية بين الرسائل الاختبارية المرسلة إلى البنك المحدد بين 5 و30 ثانية تقريبا. بالطبع» يمكن أن يختلف هذا حسب ما هو مفهوم بواسطة الخبير فى المجال. في أحد النماذج؛ تقوم البوابة بإرسال مجموعة من الرسائل الاختبارية قبل تحديد أن موقع المفتاح 0 غير متاح. بالمثل» يقوم كل المفتاح بإرسال مجموعة من الرسائل الاختبارية قبل تحديد أن البنك غير متاح. ‎Ole‏ لترتيب حيث تبلغ المدة الزمنية بين إرسال الرسائل الاختبارية 30 ثانية؛ يمكن أن تقوم البوابة أو المفتاح بإرسال رسالة اختبارية أولى وتستمع إلى إشارة مرتدة. بعد 30 ثانية؛ إذا لم يتم استلام الإشارة المرتدة» حينها تقوم البوابة أو المفتاح بإرسال رسالة اختبارية ثانية وتستمع إلى الإشارة المرتدة. بعد 30 ثانية؛ إذا لم يتم تلقي إشارة مرتدة؛ بعد ذلك يتم تحديد موقع المفتاح (في 5 حالة البوابة إرسال الرسائل الاختبارية) أو البنك (في حالة المفاتيح إرسال الرسائل الاختبارية) الذي يتم إليه ‎Jas‏ الرسائل الاختبارية على أنه غير متاح؛ ويتم تعليق إرسال رسائل المعاملة إلى موقع المفتاح هذا أو البنك. بواسطة إرسال مجموعة من الرسائل الاختبارية قبل تحديد أن موقع المفتاح أو البنك غير ‎lie‏ يساعد على ضمان عدم تعليق إرسال رسائل المعاملة إلى موقع مفتاح الوظيفية أو البنك في حالة أن الإشارة المرتدة العائدة من موقع المفتاح هذا أو البنك خاضع؛ ‎lie‏ ‏0 إلى تأخير شبكة أو ما شابه. بشكل مفيد؛ بسبب الحفاظ على تخزين الإتاحية بواسطة البوابة لكل بنك؛ لا يتم إرسال رسائل معاملة إلى البنوك أو مواقع المفتاح والتي يتم تحديدها على أنها غير متاحة؛ وبالتالي يتم إجراء عدد مخفض من المحاولات لبث رسائل إلى مواقع المفتاح أو البنوك الذي لا يمكنه قبول الرسائل. بالإضافة إلى تقليل خطر إفساد أو فقد ‎clad)‏ هذا يعني أيضا أن المعالجة وسعة الشبكة لا يتم 5 توصيلها مع الرسائل. بالتالي يتم تحسين فعالية المعالجة والشبكة.
بالإضافة إلى ذلك؛ تمت ملاحظة أن هناك حد محدد سلفا مفروض بواسطة البنوك على المبلغ من الزمن الذي يجب أن تستغرقه المعاملة. ذلك ‎of‏ يجب ألا يكون الوقت بين إرسال رسالة طلب المعاملة الأولية واستلام ‎Ally‏ تأكيد معاملة ثانية بواسطة البنك أكثر من القيمة المحددة سلفا. يمكن ضبط أي قيمة حدية مناسبة؛ مع ذلك؛ بشكل مثالي؛ سوف يتم ضبطها عند حوالي 5 إلى ثانية. بالتالي سوف يكون من المهم ضمان أن رسائل المعاملة يتم إرسالها خلال النظام بفعالية قدر الإمكان للمساعدة في ضمان أن المعاملة مكتملة في هذا الحد الزمني. بشكل مفيد؛ بسبب استخدام تخزين الإتاحية عند كل بنك؛ لا تتم إضاعة الوقت بواسطة محاولة لإرسال رسائل معاملة إلى المفاتيح عبر مواقع المفتاح غير المتاحة (والتي سوف تؤدي إلى إعادة الرسالة وتضطر إلى إعادة التوجيه؛ بالتالي إضاعة الوقت). ‎cial‏ لأن كل مفتاح يحافظ على سجل خاص بكل 0 المسارات المتاحة لكل بنك (وفقا للرسائل الاختبارية المرسلة إلى وإشارات مرتدة مستلمة من كل بنك)؛ لا يتم فقد الزمن بواسطة محاولة إرسال رسائل معاملة إلى مسارات البنوك عبر غير متاح. أيضاء لأت كل مفتاح يقوم باختبار مفاتيح الأخرى لإتاحتهاء لا يتم فقد الزمن بواسطة محاولة إرسال رسائل المعاملة إلى مفاتيح غير متاحة. تساعد كل من هذه الخواص بالتالي ضمان أن رسائل المعاملة يتم إرسالها بفاعلية حول النظام 100 وأن المعاملة يمكن إكمالها في الحد الزمني 5 المحدد بواسطة البنوك. كميزة ‎(Al‏ باستخدام البوابة لمراقبة إتاحية مواقع المفتاح والبنوك ولإصدار التعليمات؛ ويتم تفريغ المعالجة من التطبيقات المصرفية 1102 102ب. بالتالي يتم تحسين المعالجة الكلية عند البنوك. الشكل 5 يشرح كومبيوتر 700 للاستخدام مع النظام 100. في أحد النماذج؛ يتم تنفيذ الوظائف التي يتم تنفيذها بواسطة كل من عناصر النظام 100 (حيث؛ التطبيقات المصرفية 102( 102[ب؛ 0 البوابات 104 104ب» وحدة صف الرسائل 106 106ب» 1108 108« 1112 112« المفاتيح ‎SW2 (SWI‏ 5173 5174؛ ‎the‏ قواعد بيانات 110 110ب ووحدة المكتب الخلفي 4) بواسطة واحد أو أكثر من هذه الكومبيوترات 700. يمكن أن تكون هذه الكومبيوترات عبارة عن خوادم ‎servers‏ (والتي يمكن أن تكون هي نفسها عبارة عن خوادم مادية ‎physical servers‏ أو يمكن أن تكون عبارة عن خوادم افتراضية ‎(virtual servers‏ يتم التحكم بالكومبيوتر 700 بواسطة 5 وحدة المعالجة المركزية ‎(CPU) central processing unit‏ 702« يمكن تهيئة وحدة المعالجة المركزية 702 لمعالجة التعليمات المحفوظة في الذاكرة 704. يتم توصيل البيانات مع الكومبيوتر
0 عبر الشبكة سطح بيني 706. يتضمن الكومبيوتر 700 أيضا وسط تخزين 708 (مثل سواقة قرص صلب ‎chard disk drive‏ ذاكرة ‎dls‏ صلبة ‎solid state memory‏ أو سواقة شريط ‎tape‏ ‎(drive‏ لتخزين البيانات. على الرغم من وصف النظام 100 نسبة إلى معالجة رساتئل المعاملة المالية ‎financial‏ ‎ctransaction messages 5‏ سوف يتم فهم أن النظام 100 يجب استخدامه للمعالجة وتخزين أي نوع من وحدة البيانات التي يجب إدارتها بحيث؛ أثناء أي معالجة أخرى؛ يتم اعتبار كل وحدة بيانات ويتم اعتبارها هي فقط مرة واحدة. في هذه الحالة؛ لأي نوع من وحدة بيانات مستخدمة؛ سوف يساعد النظام 100 على ضمان أن يتم تجنب أي حذف أو فساد أو مضاعفة للبيانات. ‎Sli‏ يمكن استخدام النظام 100 ‎dalled‏ وتخزين البيانات الصادرة أثناء الاختبارات العلمية أو 0 الهندسية قبل تحليل هذه البيانات. في هذه ‎calla)‏ يمكن أن تكون كل وحدة بيانات عبارة عن قياس اختباري فردي؛ مثلا. غالبا ما تكون وحدات البيانات صعبة أو مكلفة للحصول عليها؛ ‎Sully‏ ‏يكون من المهم تجنب أو حذف أو فساد البيانات. علاوة على ذلك؛ للمزيد من التحليل التالي؛ من المهم ألا تتم مزاوجة البيانات» ‎Cua‏ يمكن أن ‎gap‏ إلى استنتاجات خاطئة مشتقة من التحليل. بالتالي؛ يجب أن يكون استخدام النظام 100 مفيدا لإدارة هذا النوع من البيانات. على الرغم من وصف ما سبق بالإشارة إلى البنك؛ يتعلق الكشف ‎(gb Lad‏ مؤسسة مالية تقوم بالتعامل بالأموال ‎Jie‏ شركة بطاقة ائتمان ‎credit card‏ أو ما شابه. تمت ملاحظة أن هناك ميزة معينة خاصة بالنظام 100 المذكور أعلاه وهو أنه؛ بينما يتم تجهيز النظام لجعل النظام مرن (بما يعني أن النظام يمكن أن يستمر في معالجة المعاملات بشكل اعتمادي حتى إذا كانت هناك مكونات معينة للنظام غير ‎(Alle‏ مع حقيقة ‎oof‏ بمجرد استلام 0 رسالة المعاملة بواسطة المفتاح ‎WS)‏ هو محدد بواسطة وظيفة العنونة)؛ يتم التخزين والمعالجة عند موقع فردي قبل النقل إلى وحدة المكتب الخلفي 114 بما يعني أن يتم تقليل الكمون في النظام (بسبب نقل رسالة المعاملة بين مكونات مختلفة عند المواقع المختلفة). بالتالي يظل كمون النظام بالتالي منخفضاء حتى مع زيادة مرونة النظام. سوف يتم فهم أن؛ على الرغم من أن الشكل 1 يبين اثنين من البنوك؛ اثنين من مواقع المفتاح 5 واثنين من مفاتيح لكل موقع مفتاح (لسهولة الشرح)؛ لا يتم تقييد نماذج الاختراع بذلك. في الواقع؛ يمكن أن يكون هناك عدد كبير من البنوك المهيأة لاستخدام النظام 100؛ كل منها له التهيئة
المبينة في الشكل 1 للبنك 1 والبنك 2 (حيث؛ يتضمن التطبيق المصرفي؛ بوابة ووحدة صف رسالة). يمكن أن يكون هناك أيضا أكثر من اثنين من مواقع المفتاح المهيأة بنفس الطريقة ‎ie‏ ‏مواقع المفتاح 1 و2 (مع كل موقع مفتاح موجود في اتصال بيانات مع مواقع المفتاح الأخرى ومع كل من البنوك). علاوة على ذلك؛ يمكن أن يتضمن كل موقع مفتاح أكثر من اثنين من المفاتيح؛ كل ‎Lge‏ لتخزين رسائل معاملة في نفس قاعدة البيانات للسماح بمعالجة رسائل مرتبطة بنفس المعاملة باستخدام أي من المفاتيح عند موقع معين. سوف يفهم الخبير في المجال كيف يمكن توسيع النظام 100 كما هو موضح بالإشارة إلى الشكل 1 ليتضمن عد كبير من البنوك؛ مواقع المفتاح و/أو مفاتيح. على الرغم من وصف ما سبق بالإشارة إلى طلبات المعاملة ‎ctransaction requests‏ لن يتم تقييد 0 الكشف ويمكن تصور أي نوع من الرسائل الالكترونية. أيضاء على الرغم من وصف ما سبق بالإشارة إلى طلبات المعاملة المخزنة بشكل مؤقت في صف الرسالة 1106 قبل الإرسال إلى البوابة 104 لن يتم تقييد الكشف. ‎Sle‏ يمكن أن يتصل التطبيق البنكي 1102 مباشرة مع البوابة 1104 دون حمل طلب المعاملة في صف الرسالة ‎message queue‏ 1106 يمكن تحقيق ذلك بواسطة الحصول على منظم ‎buffer‏ في البوابة 1104 والذي يقوم بتخزين طلبات المعاملة لحين تقديم طلب 5 المعاملة بواسطة البوابة ‎J104‏ ‏بشكل واضح؛ من المحتمل أن يكون هناك العديد من التعديلات والاختلافات الخاصة بالكشف الحالي متاحة في ‎pa‏ التعليمات المذكورة أعلاه. سوف يتم بالتالي فهم أنه في منظور عناصر الحماية الملحقة؛ يمكن تنفيذ الكشف كما هو محدد سلفا. في نماذج الكشف التي تم وصفها وتنفيذهاء ‎Wha‏ على الأقل؛ بواسطة جهاز معالجة بيانات ‎data‏ ‎processing apparatus 0‏ تتحكم في البرمجيات» سوف يتم فهم أن وسط قابل للقراءة بواسطة ماكينة ‎machine-readable medium‏ غير انتقالية تحمل هذه البرمجيات؛ ‎Jie‏ قرص ‎optical Gra‏ ‎«disk‏ قرص مغناطيسي ‎magnetic disk‏ ذاكرة شبه موصلة ‎semiconductor memory‏ أو ما شابه؛ يتم اعتبارها على أنها تمثل أحد النماذج الكشف الحالي. سوف يتم فهم أن الوصف أعلاه قد شرح نماذج بالإشارة إلى وحدات وظيفية ‎functional units‏ 5 مختفة؛ دارة و/أو معالجات 08:50:8:م. مع ذلك سوف يتضح أن أي توزيع مناسب للوظيفية بين الوحدات الوظيفية المختلفة؛ دارة و/أو المعالجات يمكن استخدامها دون الخروج من النماذج.
يمكن تنفيذ النماذج الموضحة بأي صورة مناسبة شاملة البرمجيات والأجهزة وتوليفة منهما. يمكن تنفيذ النماذج الموضحة اختياريا ‎Wiha‏ على الأقل كبرمجيات كومبيوتر تعمل على واحد أو أكثر من معالجات البيانات ‎data processors‏ و/أو معالجات الإشارات الرقمية ‎digital signal‏ ‎(Sa .0 5‏ أن تكون عناصر ومكونات أي من النماذج مادية أو وظيفية ويتم تنفيذها منطقيا بأي طريقة مناسب. يمكن تنفيذ الوظيفة في وحدة فردية ؛ في مجموعة من الوحدات أو كجزء من وحدات وظيفية أخرى. بالتالي يمكن تنفيذ النماذج المكشوف عنها الوحدات أو الدارات أو المعالجات المختلفة. على الرغم من وصف الكشف الحالي باعتبار بعض النماذج؛ ليس مقصودا تقييد الصورة الحالية المذكورة الحالية. بشكل إضافي؛ على الرغم من أن الخاصية يمكن أن تبدو وقد تم شرحها باعتبار 0 نماذج معينة؛ قد يعرف الخبير في المجال أن العديد من خواص النماذج الموضحة يمكن دمجها بطريقة مناسبة لتنفيذ التقنية. قائمة التتابع: ‎he‏ بنك ‎SW "15‏ ‎z"‏ سجل ملخص المعاملة لد" ‎TU‏ ‏"ها موقع مفتاجح "و" - نعم «ز" الا ‎a‏ غير مسموح حيث يتخطى السعة الانتمائية للموقع ‎"Ln‏ دين عي" السعة الانتمائية الكلية "ىق" السعة الانتمائية "ل" ‎SRP‏ الكلى ‎SRP 2 aise "a‏
"ان" موقع 1 ‎SRP‏ ‏"س" . مسموح بسعة انتمائية أقل من 5000 جنية 2 موقع تعديل "ف" معاملة جديدة ‎"a" 5‏ معدل ‎SRP‏
2 102« تطبيق بنكي ‎(i104‏ 104ب بوابة ‎i106‏ 1108 2108« 1112 112ب صف رسالة 60 10ب قاعدة البيانات
0 114 مكتب خلفي 200« 216« 900 بداية 218.02 استلام رسالة 204 استلام وظيفة عنونة 206 أولا التبديل في قائمة الأولوية المتاحة
208 التوجيه إلى التبديل الأول في قائمة الأولية 212 بعد ذلك التبديل في قائمة التبديل المتاحة؟ 214 التوجيه إلى التبديل التالي في قائمة الأولوية 210 الطرف 220 هل الرسالة 811؟
0 222 هل الرسالة عبارة عن تكرار؟ 224 هل الرسالة ‎M4‏ متاحة؟ 226 إعادة إرسال 1,14 228 هل قاعدة بيانات حالة المعاملة قابلة للوصول إليها؟ 230« 920 رسالة العملية
5 232 922 النهاية 2 651 السعة الانتمائية
603 موقع 1 ‎SRP‏ ‏604 موقع 2 ‎SRP‏ ‎SRP 605‏ الكلى 656 دورة تعديل 902 استلام رسالة المعاملة للتحويل
904 تحليل بنية الرسالة 906 هل بنية ‎Alay‏ سليمة ؟ 908 العودة إلى البنك 910 تسجيل
0 912 تحويل 914 تحقق 916 التحقق ناجح 918 عودة ‎CPU 702‏
5 704 الذاكرة 706 السطح البيني للشبكة

Claims (1)

  1. عناصر الحماية 1- نظام لتلقي الرسائل الالكترونية ‎electronic messages‏ من مؤسسة مالية؛ النظام يتضمن: مجموعة من مفاتيح ‎switches‏ مهيأة للاإتصال ببعضها ‎(anal)‏ وتتضمن مجموعة المفاتيح ‎switches‏ مفتاح أول ‎first switch‏ ومفتاح ثان ‎csecond switch‏ حيث يتضمن المفتاح الأول ‎first‏ ‎switch‏ دارة ‎processing circuitry dallas‏ مهيأة لأجل: استلام رسالة إلكترونية ‎electronic message‏ لمعاملة ‎ctransaction‏ وتتضمن الرسالة الإلكترونية ‎electronic message‏ محدد فريد ‎unique identifier‏ للمعاملة ‎¢transaction‏ ‏تحديد واحد من ‎de gana‏ المفاتيح ‎switches‏ لمعالجة الرسالة الإلكترونية ‎electronic message‏ على أساس محدد المعاملة الفريد ‎tunique transaction identifier‏ ‎dallas‏ الرسالة الإلكترونية ‎electronic message‏ عندما يكون المفتاح الأول ‎first switch‏ هو 0 المفتاح المحدد من مجموعة المفاتيح ‎eswitches‏ وتسجيل أو تحديث ‎Ala‏ المعاملة ‎transaction‏ ‏التي ترتبط بها الرسالة الإلكترونية ‎electronic message‏ في قاعدة بيانات ‎database‏ واحدة على الأقل للإشارة إلى عدد إجمالي للرسائل الإلكترونية ‎electronic messages‏ المستلمة والواردة فيما يتعلق بالمعاملة ‎transaction‏ حيث يتم تسجيل ‎Ala‏ المعاملة ‎transaction‏ أو تحديثها في قاعدة البيانات ‎database‏ الواحدة على الأقل للإشارة إلى أن المعاملة ‎transaction‏ مكتملة عندما يستوفي 5 العدد الإجمالي المذكور عدد حدي؛ و إرسال الرسالة الإلكترونية ‎electronic message‏ إلى المفتاح الثاني ‎second switch‏ من أجل المعالجة عندما يكون المفتاح الثاني ‎second switch‏ هو المفتاح المحدد من مجموعة المفاتيح ‎switches‏ حيث يمكن للمفتاح الثاني ‎second switch‏ تسجيل أو تحديث حالة المعاملة ‎transaction‏ التي ترتبط بها الرسالة الإلكترونية ‎electronic message‏ في قاعدة البيانات ‎database‏ ‏0 الواحدة على الأقل. 2- النظام وفقا لعنصر الحماية 1؛ حيث يحدد محدد المعاملة ‎unique transaction All‏ ‎identifier‏ بشكل فريد المعاملة ‎transaction‏ والتي ترتبط بها الرسالة الإلكترونية ‎electronic‏
    ‎.message‏ ‏25
    3- النظام وفقا لعنصر الحماية 2 حيث تتم تهيئة دارة المعالجة ‎processing circuitry‏ للمفتاح الأول ‎first switch‏ بصورة إضافية لتنفيذ وظيفة عنونة ‎hashing function‏ على الرسالة الإلكترونية unique all ‏محدد المعاملة‎ hashing function ‏وتستخدم وظيفة العنونة‎ «electronic message ‎transaction identifier‏ للرسالة الإلكترونية ‎electronic message‏ وعدد من مجموعة المفاتيح ‎switches 5‏ لتحديد المفتاح ‎switch‏ من مجموعة المفاتيح ‎switches‏ الخاص بمعالجة الرسالة
    ‎.electronic message ‏الإلكترونية‎ ‏4— النظام وفقا لعنصر الحماية 1؛ حيث تتضمن قاعدة البيانات ‎database‏ الواحدة على الأقل ‏قاعدة بيانات ‎database‏ أولى وقاعدة بيانات ‎database‏ ثانية؛ و ‏0 حيث تشتمل مجموعة المفاتيح ‎switches‏ على: مجموعة أولى من المفاتيح ‎switches‏ تتضمن المفتاح الأول ‎first switch‏ والمفتاح الثاني ‎second‏ ‎«switch‏ تقع المجموعة الأولى من المفاتيح ‎switches‏ في موقع أول وتتصل بقاعدة البيانات ‎database‏ الأولى؛ حيث يمكن للمفاتيح ‎switches‏ من المجموعة الأولى من المفاتيح ‎switches‏ ‏تسجيل أو تحديث حالات المعاملات ‎transactions‏ في قاعدة البيانات ‎database‏ الأولى؛ و ‏5 مجموعة ثانية من المفاتيح ‎switches‏ تقع في موقع ثان وتتصل بقاعدة البيانات ‎database‏ الثانية؛ حيث يمكن للمفاتيح ‎switches‏ من المجموعة الثانية من المفاتيح ‎switches‏ تسجيل أو تحديث حالات المعاملات ‎transactions‏ في قاعدة البيانات ‎database‏ الثانية؛ و حيث تتم تهيئثة دارة ‎processing circuitry dallas‏ للمفتاح الأول ‎first switch‏ عندما يكون المفتاح الأول ‎first switch‏ هو المفتاح المحدد من مجموعة المفاتيح ‎switches‏ بصورة إضافية ‏0 لأجل: تسجيل أو تحديث حالة المعاملة ‎transaction‏ في قاعدة البيانات ‎database‏ الأولى للإشارة إلى أن المعاملة ‎transaction‏ مكتملة عندما يكون الرقم الإجمالي المذكور للرسائل الإلكترونية ‎electronic‏ ‏08 المستلمة والواردة ‎Lad‏ يتعلق بالمعاملة ‎transaction‏ مستوفي للحد؛ ويعد ذلك إنتاج رسالة تأكيد للمعاملة ‎transaction confirmation message‏ وإرسال رسالة تأكيد المعاملة ‎transaction confirmation message 5‏ إلى واحد على الأقل من المفاتيح ‎switches‏ من المجموعة الثانية من المفاتيح 9»10:8» حيث يمكن لواحد على الأقل من المفاتيح ‎switches‏ من المجموعة
    الثانية من المفاتيح ‎switches‏ تسجيل أو تحديث حالة المعاملة ‎transaction‏ قاعدة البيانات
    ‎database‏ الثانية مما يشير إلى أن المعاملة ‎transaction‏ مكتملة.
    ‏5- النظام وفقا لعنصر الحماية ‎of‏ حيث ‎adie‏ يكون المفتاح الثاني ‎second switch‏ هو المفتاح
    ‏5 المحدد من مجموعة المفاتيح ‎switches‏ التي يتعين إرسال الرسالة الإلكترونية ‎electronic message‏
    ‏إليها وعندما لا يعمل المفتاح الثاني ‎second switch‏ لمعالجة الرسالة الإلكترونية ‎electronic‏
    ‎message‏ فإن دارة المعاتلجة ‎processing circuitry‏ للمفتاح الأول ‎first switch‏ تكون مهيأة بصورة
    ‏إضافية لأجل:
    ‏إرسال الرسالة الإلكترونية ‎electronic message‏ إلى مفتاح ‎switch‏ آخر من المجموعة الأولى من 0 المفاتيح ‎switches‏ لمعالجة الرسالة الإلكترونية ‎telectronic message‏ أو
    ‏معالجة الرسالة الإلكترونية ‎.electronic message‏
    ‏6- النظام وفقا لعنصر الحماية 4؛ حيث عندما يكون المفتاح الثاني ‎second switch‏ هو المفتاح
    ‏المحدد من مجموعة المفاتيح ‎switches‏ التي يتعين إرسال الرسالة الإلكترونية ‎electronic message‏ إليها وعندما لا يعمل المفتاح الثاني ‎second switch‏ لمعالجة الرسالة الإلكترونية ‎electronic‏
    ‎message‏ وعندما لا يعمل أي مفتاح آخر من المجموعة الأولى من المفاتيح ‎switches‏ لمعالجة
    ‏الرسالة الإلكترونية ‎celectronic message‏ فإن دارة المعالجة ‎processing circuitry‏ للمفتاح الأول
    ‎first switch‏ تكون مهيأة بصورة إضافية لأجل:
    ‏إرسال الرسالة الإلكترونية ‎electronic message‏ إلى مفتاح ‎switch‏ من المجموعة الثانية من 0 المفاتيح ‎switches‏ لمعالجة الرسالة الإلكترونية ‎telectronic message‏ أو
    ‏معالجة الرسالة الإلكترونية ‎.electronic message‏
    ‏7- مفتاح ‎switch‏ لتلقي الرسائل الالكترونية ‎electronic messages‏ من مؤسسة مالية؛ يشتمل
    ‏المفتاح ‎switch‏ على دارة ‎processing circuitry dallas‏ مهيأة لأجل: 5 - استلام رسالة إلكترونية ‎electronic message‏ تتضمن محدد فريد ‎tunique identifier‏
    تطبيق وظيفة عنونة ‎hashing function‏ على الرسالة الإلكترونية ‎electronic message‏ باستخدام المحدد الفريد ‎tunique identifier‏ عندما تحدد وظيفة العنونة ‎hashing function‏ المفتاح ‎switch‏ المذكور؛ معالجة الرسالة الإلكترونية ‎¢electronic message‏ وعندما تحدد وظيفة العنونة ‎hashing function‏ مفتاح ‎switch‏ غير المفتاح ‎switch 5‏ المذكورء إرسال الرسالة الإلكترونية ‎electronic message‏ إلى المفتاح ‎switch‏ الآخر
    المحدد بواسطة وظيفة العنونة ‎hashing function‏ من أجل المعالجة. 8- طريقة لتلقي الرسائل الالكترونية ‎electronic messages‏ من مؤسسة مالية في نظام ‎dado‏ ‏مجموعة من المفاتيح ‎switches‏ المهيأة للاتصال ببعضها البعض»؛ وتشمل الطريقة:
    0 استلام؛ في مفتاح أول ‎first switch‏ من مجموعة المفاتيح ‎cswitches‏ رسالة إلكترونية ‎electronic‏ ‎message‏ لمعاملة ‎ctransaction‏ وتتضمن الرسالة الإلكترونية ‎electronic message‏ محدد فريد ‎unique identifier‏ للمعاملة ‎¢transaction‏ ‏تحديد» بواسطة المفتاح الأول ‎first switch‏ واحد من مجموعة المفاتيح ‎switches‏ لمعالجة الرسالة الإلكترونية ‎electronic message‏ على أساس المحدد الفريد ‎tunique identifier‏
    استجابة لأن المفتاح الأول ‎first switch‏ هو المفتاح المحدد من مجموعة المفاتيح ‎cswitches‏ ‏معالجة؛ بواسطة المفتاح الأول ‎«first switch‏ الرسالة الإلكترونية ‎electronic message‏ وتحديثء بواسطة المفتاح الأول ‎first switch‏ حالة المعاملة ‎transaction‏ في قاعدة بيانات ‎‘database‏ و استجابة لأن المفتاح الثاني ‎second switch‏ من مجموعة المفاتيح ‎switches‏ هو المفتاح المحدد من مجموعة المفاتيح ‎switches‏ إرسال؛ بواسطة المفتاح الأول ‎switch‏ )515» الرسالة الإلكترونية
    ‎electronic message 0‏ إلى المفتاح الثاني ‎second switch‏ من أجل المعالجة. 9- الطريقة وفقًا لعنصر الحماية 8( ‎Cus‏ يتضمن المحدد الفريد ‎unique identifier‏ محدد معاملة فريد ‎unique transaction identifier‏ يحدد بشكل فريد المعاملة ‎transaction‏ والتي ترتبط بها الرسالة الإلكترونية ‎.electronic message‏
    ‎25
    0- الطريقة وفقًا لعنصر الحماية 8« تشمل أيضًا ‎«duit‏ بواسطة المفتاح الأول ‎first switch‏ وظيفة عنونة ‎hashing function‏ على الرسالة الإلكترونية ‎celectronic message‏ وتستخدم وظيفة العنونة ‎hashing function‏ المحدد الفريد ‎unique identifier‏ للرسالة الإلكترونية ‎electronic‏ ‎message‏ لتحديد المفتاح من مجموعة المفاتيح ‎switches‏ لمعالجة الرسالة الإلكترونية ‎electronic‏ ‏ذا ‎.message‏ ‏1- الطريقة وفقًا لعنصر الحماية 8( حيث ‎Jai‏ مجموعة المفاتيح ‎switches‏ على مجموعة أولى من المفاتيح ‎switches‏ تتضمن المفاتيح الأول والثاني؛ تقع في موقع أول وتتصل بقاعدة بيانات ‎database‏ أولى ومجموعة ثانية من المفاتيح ‎switches‏ تقع في موقع ثان وتتصل بقاعدة 10 بيانات ‎database‏ ثانية. 2- الطريقة وفقًا لعنصر الحماية 11؛ تشمل ‎(Lal‏ استجابة لأن المفتاح الثاني ‎second switch‏ هو المفتاح المحدد من مجموعة المفاتيح ‎switches‏ التي يتعين إرسال الرسالة الإلكترونية ‎electronic message‏ إليها ولأن المفتاح الثاني ‎second switch‏ لا يعمل لمعالجة الرسالة الإلكترونية ‎:W| «electronic message 15‏ إرسال»؛ بواسطة المفتاح الأول ‎first switch‏ الرسالة الإلكترونية ‎electronic message‏ إلى مفتاح ثالث ‎third switch‏ من المجموعة الأولى من المفاتيح ‎switches‏ لمعالجة الرسالة الإلكترونية ‎telectronic message‏ أو معالجة؛ بواسطة المفتاح الأول ‎efirst switch‏ الرسالة الإلكترونية ‎.clectronic message‏ 20 3- الطريقة وفقًا لعنصر الحماية 11؛ تشمل أيضًاء استجابة لأن المفتاح الثاني ‎second switch‏ هو المفتاح المحدد من مجموعة المفاتيح ‎switches‏ التي يتعين إرسال الرسالة الإلكترونية ‎electronic message‏ إليها ولأن المفتاح الثاني ‎second switch‏ لا يعمل ولا يعمل أي مفتاح ‎AT‏ ‏من المجموعة الأولى من المفاتيح ‎switches‏ لمعالجة الرسالة الإلكترونية ‎«electronic message‏ بإما:
    إرسال»؛ بواسطة المفتاح الأول ‎first switch‏ الرسالة الإلكترونية ‎electronic message‏ إلى مفتاح ‎switch‏ من المجموعة الثانية من المفاتيح ‎switches‏ لمعالجة الرسالة الإلكترونية ‎electronic‏ ‎‘message‏ أو معالجة؛ بواسطة المفتاح الأول ‎efirst switch‏ الرسالة الإلكترونية ‎.clectronic message‏
    14- المفتاح ‎Gg switch‏ لعنصر الحماية © حيث تتم تهيئة دارة ‎processing circuitry dallas‏ بصورة إضافية لتسجيل أو تحديث ‎Ala‏ معاملة ‎transaction‏ والتي ترتبط بها الرسالة الإلكترونية ‎electronic message‏ في قاعدة بيانات ‎database‏ عندما تحدد وظيفة العنونة ‎hashing function‏ المفتاح ‎switch‏ المذكور.
    5- المفتاح ‎switch‏ وفقًا لعنصر الحماية 7» حيث ترتبط الرسالة الإلكترونية ‎electronic‏ ‎message‏ بمعاملة ‎transaction‏ تتضمن حساب 0000001 في مؤسسة مالية أولى وحساب ‎account‏ ‏في مؤسسة مالية ثانية؛ و حيث تتم تهيئة دارة ‎processing circuitry dallas‏ بصورة إضافية لأجل:
    ‎gal 5‏ رسالة رد ‎response message‏ على أساس الرسالة الإلكترونية ‎electronic message‏ إرسال رسالة الرد ‎response message‏ إلى صف انتظار الرسائل ‎queue‏ عع0168588؛ حيث يمكن لصف انتظار الرسائل ‎message queue‏ توجيه رسالة الرد ‎response message‏ إما إلى المؤسسة المالية الأولى أو المؤسسة المالية الثانية.
    ‏0 16- الطريقة ‎Gay‏ لعنصر الحماية 8؛ تشمل أيضًا: استلام» بواسطة المفتاح الثاني ‎switch‏ 960000» الرسالة الإلكترونية ‎electronic message‏ من المفتاح الأول ‎first switch‏ استجابة للمفتاح الثاني ‎second switch‏ الذي يكون هو المفتاح المعرف من مجموعة المفاتيح ‎fswitches‏ و تحديث؛ بواسطة المفتاح الثاني ‎Ala ¢second switch‏ المعاملة ‎transaction‏ التي ترتبط بها الرسالة
    ‏25 الإلكترونية ‎electronic message‏ في قاعدة البيانات ‎-database‏
    ٠ 5 6 — ١ wr 0 we ! = | + | 858 avers Sl BE |)" | ‏يليم‎ ‏ا‎ / Th ‏سس‎ | N aA [% ‏"انبل‎ ‎8 ‏ا لس ست , لسلس 5 | ملستست‎ 7 LA RAT ‏يي — ص‎ es] 8 fy d i) ٍ ‏با‎ ‎ِ ١ 1 2 ‏...م ووو الا‎ 1 ‏إْ 5 6 لهست حمس‎ | fF Ji Ey oo : hd ‏لإا ل 0 ب“‎ we [ ' iy | | | ب1٠١‎ ‏مج‎ ‎١ fn A x 5 - 4 - a 1 ¥ 1 A i a . Yaa ١لكش‎
    — 5 7 — ( I Ng Ya. rm J ‏م‎ Yo ٍِ %, J ¥a.% i.
    Yah J 1 ‏و‎ ٍ
    Pp Pa 3 AY vit 7 “ i » 1 5) 8 ab AAR iv ‏شكل‎
    الا مس
    ‎PARE YY‏ يمد ٍ ا« ا 8 : أو" 3 م“ ‎yg‏
    ‏ازا 55 "0 { با ممأ يسمي ِِ :
    ‏و
    ‏و ‏شكل ‎GY‏
    ٠١١.١ enw Su LF SER 5. itn 1 x 1 won ‏يا و دن \ ل اج انيل‎ ‏ا‎ A N, \ \ 0 No : teen 2 Se 0 ‏ا ل المسسسيم مت تيد‎ ‏لم لدي تيع‎ H N 7 * Hy ¢ 1 « 1 5 R= Town : ‏ومو 4 مقر‎ .: 0 ‏ا‎ H , 1 : , 2 1 1] £ ¢ » , ‏ل‎ : 0 0 Ya ; nr 3 ‏ءات‎ om ‏مز ؟‎ ¥en : YA.
    Cove : 0 7 ¥ 2 0: H t 5 1 3 : 3 ¥ # ‏امام‎ hank Oo cm 1 ; H Pasa 1 34 Lt ER , ‏ل‎ tre Fel jr ‏شكل‎
    Te) 05 ‏اماد راض‎
    8. ‏لخدي‎ & Era iy ١ ‏أي كارا‎ 1 Bog ‏ل‎ ١ 2 9 5 5 bd i — rt : ‏لق‎ ‎2 * 1 5 5 1] » ar Hi : ‏.ا‎ : ‏صقر لماجا مط‎ + 5. en Xin ; ‏د‎ ‎: : L] 5 5, 3 , H ¥ ‏ل‎ ‎: : : ‏مذ‎ ; FA ¥ 2 ore leas von H 1 ‏ل‎ 1] 3 x 5 3 : > 1 2 Aven : : 0 0 0 ‏اب‎ 0 ¥ T 1 . : 5 5 3 5 H 2 YA fp! b XA : Ne vm - Hatt ‏؟‎ Aa em fe ‏اسح‎ xe. = VE Poe ‏علج ا‎ ¥ : A H Hi 5 ; R 0 7 1) 2 FAR ENT : ‏لأ‎ : 1 pa 1] 3 1] 3 LH] 3 0 0 ‏ا‎ * 5" El ow 0 ‏صن + أ تس‎ dt $ 1 ; 1 > XN ‏بحم ا : بصخم‎ : ‏جداطء8؟ جام‎ + +): Fane ل١١ ‏صقر د‎ : ¥ 4 ‏5ك‎ 3, 3 1] : 1 : ‏مار ّوج‎ H th I ‏داف‎ 8 7 , ‏ل‎ ¥ ¢ HS ‏ب‎ ‎= ‎& ‎Yo ‏شكل‎
    ٠ 6 1 ٠ I (a ‏اط‎ ‎~ 4 oh 8% 0 ‏م" ل‎ ٍ nw 3 537 ‏سك ا‎ 44 ‏تم‎ ‏ا‎ 4 i 4 ‏ا‎ 1 Np rl “, . ny Sn ‏إٍ‎ "yg SAN ¢ ‏شكل‎
    ب ا ‎Vas‏ ‎J a‏ , ِ ض ‎ees 0 |‏ 0 ض شكل هه
    لاله الهيلة السعودية الملضية الفكرية ا ‎Sued Authority for intallentual Property‏ ‎RE‏ .¥ + \ ا 0 § 8 ‎Ss o‏ + < م ‎SNE‏ اج > عي كي الج ‎TE I UN BE Ca‏ ‎a‏ ةا ‎ww‏ جيثة > ‎Ld Ed H Ed - 2 Ld‏ وذلك بشرط تسديد المقابل المالي السنوي للبراءة وعدم بطلانها ‎of‏ سقوطها لمخالفتها ع لأي من أحكام نظام براءات الاختراع والتصميمات التخطيطية للدارات المتكاملة والأصناف ع النباتية والنماذج الصناعية أو لائحته التنفيذية. ‎Ad‏ ‏صادرة عن + ب ب ‎٠.‏ ب الهيئة السعودية للملكية الفكرية > > > فهذا ص ب ‎101١‏ .| لريا ‎1*١ v=‏ ؛ المملكة | لعربية | لسعودية ‎SAIP@SAIP.GOV.SA‏
SA517381730A 2014-12-18 2017-06-15 نظام، طريقة ومنتج برنامج كومبيوتر لتلقي الرسائل الالكترونية SA517381730B1 (ar)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
GB1422640.1A GB2537087A (en) 2014-12-18 2014-12-18 A system, method and computer program product for receiving electronic messages
PCT/GB2015/053037 WO2016097674A1 (en) 2014-12-18 2015-10-14 A system, method and computer program product for receiving electronic messages

Publications (1)

Publication Number Publication Date
SA517381730B1 true SA517381730B1 (ar) 2021-07-12

Family

ID=54337808

Family Applications (1)

Application Number Title Priority Date Filing Date
SA517381730A SA517381730B1 (ar) 2014-12-18 2017-06-15 نظام، طريقة ومنتج برنامج كومبيوتر لتلقي الرسائل الالكترونية

Country Status (11)

Country Link
US (1) US10997568B2 (ar)
EP (2) EP3234890A1 (ar)
JP (1) JP6450471B2 (ar)
AU (2) AU2015365698A1 (ar)
CA (1) CA2971679C (ar)
CO (1) CO2017007201A2 (ar)
EA (1) EA201791341A1 (ar)
GB (1) GB2537087A (ar)
SA (1) SA517381730B1 (ar)
SG (1) SG11201704895RA (ar)
WO (1) WO2016097674A1 (ar)

Families Citing this family (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8725607B2 (en) 2004-01-30 2014-05-13 The Clearing House Payments Company LLC Electronic payment clearing and check image exchange systems and methods
US10395223B2 (en) 2012-03-07 2019-08-27 Early Warning Services, Llc System and method for transferring funds
US11593800B2 (en) 2012-03-07 2023-02-28 Early Warning Services, Llc System and method for transferring funds
US11295308B1 (en) 2014-10-29 2022-04-05 The Clearing House Payments Company, L.L.C. Secure payment processing
GB2533562A (en) 2014-12-18 2016-06-29 Ipco 2012 Ltd An interface, method and computer program product for controlling the transfer of electronic messages
GB2533379A (en) 2014-12-18 2016-06-22 Ipco 2012 Ltd A system and server for receiving transaction requests
US11042882B2 (en) 2015-07-01 2021-06-22 The Clearing House Payments Company, L.L.C. Real-time payment system, method, apparatus, and computer program
US11694168B2 (en) 2015-07-01 2023-07-04 The Clearing House Payments Company L.L.C. Real-time payment system, method, apparatus, and computer program
US11386410B2 (en) 2015-07-21 2022-07-12 Early Warning Services, Llc Secure transactions with offline device
US11436577B2 (en) 2018-05-03 2022-09-06 The Clearing House Payments Company L.L.C. Bill pay service with federated directory model support
US11501267B2 (en) * 2019-08-06 2022-11-15 Paypal, Inc. System and method for implementing fast payouts
US20210142328A1 (en) * 2019-11-13 2021-05-13 Early Warning Services, Llc System and method for preventing fraud in real-time payment transactions
CN112087373B (zh) * 2020-09-21 2022-05-13 全通金信控股(广东)有限公司 一种消息发送方法及业务装置

Family Cites Families (82)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4100533A (en) 1976-12-06 1978-07-11 Bell Telephone Laboratories, Incorporated Multipoint polling technique
US5283897A (en) * 1990-04-30 1994-02-01 International Business Machines Corporation Semi-dynamic load balancer for periodically reassigning new transactions of a transaction type from an overload processor to an under-utilized processor based on the predicted load thereof
IL112126A0 (en) 1994-01-05 1995-03-15 Transaction Technology Inc Wireless banking system and method using cellular telephone communication
US7613659B1 (en) 1994-11-28 2009-11-03 Yt Acquisition Corporation System and method for processing tokenless biometric electronic transmissions using an electronic rule module clearinghouse
US5931961A (en) 1996-05-08 1999-08-03 Apple Computer, Inc. Discovery of acceptable packet size using ICMP echo
US6039245A (en) 1996-06-10 2000-03-21 Diebold, Incorporated Financial transaction processing system and method
US6304860B1 (en) 1997-10-03 2001-10-16 Joseph B. Martin, Jr. Automated debt payment system and method using ATM network
AU1099099A (en) 1997-10-20 1999-05-10 Foxboro Company, The Method and system for fault-tolerant network connection switchover
US6629135B1 (en) * 1998-09-17 2003-09-30 Ddr Holdings, Llc Affiliate commerce system and method
US6470342B1 (en) 1999-03-12 2002-10-22 Compaq Computer Corporation Process of maintaining a distributed map of transaction identifiers and using hashing to access these maps
CA2384242A1 (en) 1999-09-24 2001-04-05 Mary Mckenney System and method for providing payment services in electronic commerce
US8271336B2 (en) 1999-11-22 2012-09-18 Accenture Global Services Gmbh Increased visibility during order management in a network-based supply chain environment
US7366695B1 (en) 2000-02-29 2008-04-29 First Data Corporation Electronic purchase method and funds transfer system
AU4958801A (en) 2000-03-29 2001-10-08 Mastercard International Inc Method and system for processing messages in a bill payment and presentment system over a communications network
US7131108B1 (en) * 2000-04-17 2006-10-31 Ncr Corporation Software development system having particular adaptability to financial payment switches
JP2002042038A (ja) 2000-07-25 2002-02-08 Dai-Ichi Kangyo Bank Ltd 支払明細情報を提供可能な代金回収システム
US20020138431A1 (en) 2000-09-14 2002-09-26 Thierry Antonin System and method for providing supervision of a plurality of financial services terminals with a document driven interface
US20050171811A1 (en) 2000-09-26 2005-08-04 Bottomline Technologies (De) Inc. Electronic financial transaction system
US7020713B1 (en) * 2000-10-10 2006-03-28 Novell, Inc. System and method for balancing TCP/IP/workload of multi-processor system based on hash buckets
JP2002133306A (ja) 2000-10-20 2002-05-10 Canon Inc 情報処理装置、情報処理システム、情報処理方法、及び記憶媒体
US6980550B1 (en) * 2001-01-16 2005-12-27 Extreme Networks, Inc Method and apparatus for server load balancing
US7444335B1 (en) 2001-02-28 2008-10-28 Oracle International Corporation System and method for providing cooperative resource groups for high availability applications
JP2002269482A (ja) 2001-03-14 2002-09-20 Canon Sales Co Inc 機器管理システム及びその制御方法及び記憶媒体、プログラム
US6745197B2 (en) 2001-03-19 2004-06-01 Preston Gates Ellis Llp System and method for efficiently processing messages stored in multiple message stores
JP2002319058A (ja) 2001-04-20 2002-10-31 Hitachi Ltd 国際オンライン現金自動取引システム
US7742984B2 (en) 2001-07-06 2010-06-22 Hossein Mohsenzadeh Secure authentication and payment system
US20030023877A1 (en) * 2001-07-30 2003-01-30 Michael Luther System and method of managing data transmission loads
US20030065702A1 (en) * 2001-09-24 2003-04-03 Ravinder Singh Cache conscious load balancing
US20030065623A1 (en) 2001-10-01 2003-04-03 Chad Corneil Service, method and apparatus for receipt, authentication, transformation and delivery of transactions using a computer network
GB2381713A (en) 2001-11-01 2003-05-07 3Com Corp Failover mechanism involving blocking of access of a malfunctioning server and continuing monitoring to enable unblocking of access if server recovers
US20030125969A1 (en) 2001-12-28 2003-07-03 Wireless Checking, Inc. Method and apparatus for processing financial transactions over a paging network
WO2003088609A2 (en) * 2002-04-12 2003-10-23 Nokia Corporation System, device and method for improving throughput in a communication network, preferably a mobile ipv6-based network
JP3737460B2 (ja) 2002-07-09 2006-01-18 株式会社東京三菱銀行 コンピュータ・システム
US7379978B2 (en) 2002-07-19 2008-05-27 Fiserv Incorporated Electronic item management and archival system and method of operating the same
US7216937B2 (en) 2002-08-02 2007-05-15 Bend All Automotive Incorporated Press-formed keyway for headrest mounting tube
JP2004134879A (ja) 2002-10-08 2004-04-30 Hitachi Information Technology Co Ltd ルータ装置
US7260066B2 (en) 2002-10-31 2007-08-21 Conexant Systems, Inc. Apparatus for link failure detection on high availability Ethernet backplane
JP2004159146A (ja) 2002-11-07 2004-06-03 Nippon Telegr & Teleph Corp <Ntt> 通信ネットワーク及びパケット転送装置
US20050021836A1 (en) * 2003-05-01 2005-01-27 Reed Carl J. System and method for message processing and routing
US7284147B2 (en) 2003-08-27 2007-10-16 International Business Machines Corporation Reliable fault resolution in a cluster
US20050058063A1 (en) 2003-09-15 2005-03-17 Dell Products L.P. Method and system supporting real-time fail-over of network switches
PT1687725T (pt) 2003-11-26 2020-10-21 Veroguard Systems Pty Ltd Sistema de pagamento seguro
US7583661B2 (en) * 2004-03-05 2009-09-01 Sid Chaudhuri Method and apparatus for improved IP networks and high-quality services
US7761375B2 (en) 2004-03-16 2010-07-20 Hewlett-Packard Development Company, L.P. Transaction switch and a method for use thereof
US8762283B2 (en) 2004-05-03 2014-06-24 Visa International Service Association Multiple party benefit from an online authentication service
US20070263571A1 (en) * 2004-06-04 2007-11-15 Sven Hermann Dynamic and Traffic-Driven Optimization of Message Routing to Geographical Addresses
JP2006120036A (ja) * 2004-10-25 2006-05-11 Hitachi Ltd トランザクション転送システム
US20070061379A1 (en) 2005-09-09 2007-03-15 Frankie Wong Method and apparatus for sequencing transactions globally in a distributed database cluster
WO2007064878A2 (en) 2005-12-01 2007-06-07 Firestar Software, Inc. System and method for exchanging information among exchange applications
JP2007164535A (ja) 2005-12-14 2007-06-28 Nomura Research Institute Ltd 業務統合方法、業務統合装置、業務統合システムおよび業務統合プログラム
EP1989862B1 (en) 2006-01-25 2009-09-09 Telefonaktiebolaget LM Ericsson (publ) Gateway entity
US7801846B2 (en) 2006-04-04 2010-09-21 Computer Associates Think, Inc. Generating log sequence identifiers to apply a transaction to a storage system
US8413160B2 (en) * 2006-06-22 2013-04-02 American Express Travel Related Services Company, Inc. Systems, methods, and computer program products for transaction based load balancing
US20080071664A1 (en) * 2006-09-18 2008-03-20 Reuters America, Inc. Limiting Counter-Party Risk in Multiple Party Transactions
US20080109335A1 (en) 2006-11-08 2008-05-08 Keohane Susann M Delivering electronic messages from a user's electronic message service provider to a system for facilitating financial transactions
US8804486B2 (en) 2007-03-05 2014-08-12 Alcatel Lucent Base stations routing traffic over a packet backhaul network to multiple routing elements
US20090006233A1 (en) * 2007-03-30 2009-01-01 Roland Chemtob Electronic Fund Transfers Using an Electronic Mail Interface
US7725440B2 (en) 2007-09-26 2010-05-25 Yahoo! Inc. Restoring a database using fuzzy snapshot techniques
US8140483B2 (en) 2007-09-28 2012-03-20 International Business Machines Corporation Transaction log management
US20090144220A1 (en) 2007-11-30 2009-06-04 Yahoo! Inc. System for storing distributed hashtables
US9338176B2 (en) * 2008-01-07 2016-05-10 Global Dataguard, Inc. Systems and methods of identity and access management
JP5088234B2 (ja) * 2008-05-23 2012-12-05 富士通株式会社 メッセージ紐付け処理装置、方法及びプログラム
US9077684B1 (en) 2008-08-06 2015-07-07 Mcafee, Inc. System, method, and computer program product for determining whether an electronic mail message is compliant with an etiquette policy
JP4722973B2 (ja) * 2008-08-12 2011-07-13 株式会社日立製作所 リクエスト処理方法及び計算機システム
JP5308148B2 (ja) 2008-12-26 2013-10-09 株式会社大和証券グループ本社 回線障害処理システムおよびプログラム
US8296624B2 (en) * 2009-06-30 2012-10-23 Comcast Cable Communications, Llc Variable interleave data transmission
US8713027B2 (en) 2009-11-18 2014-04-29 Qualcomm Incorporated Methods and systems for managing electronic messages
US20110225091A1 (en) 2010-03-12 2011-09-15 Franco Plastina Methods, systems, and computer readable media for transactional fraud detection using wireless communication network mobility management information
EP2577579A2 (de) * 2010-05-25 2013-04-10 Paycash Labs AG Verfahren zum erzeugen eines transaktionssignals
JP2011249979A (ja) * 2010-05-25 2011-12-08 Nec Corp 通信システム
US8898333B1 (en) * 2010-08-31 2014-11-25 Juniper Networks, Inc. Methods and apparatus related to a virtual multi-hop network topology emulated within a data center
US8751355B2 (en) 2010-09-29 2014-06-10 Stephen Edward Rossi System and method for credit enhancing a debt issuance and creating a present value investable arbitrage
US10263888B2 (en) * 2010-09-30 2019-04-16 Trading Technologies International, Inc. Sticky order routers
JP5678723B2 (ja) 2011-02-28 2015-03-04 富士通株式会社 スイッチ、情報処理装置および情報処理システム
US20120271765A1 (en) 2011-04-20 2012-10-25 Karen Cervenka Routing optimization
JP5620881B2 (ja) * 2011-05-18 2014-11-05 日本電信電話株式会社 トランザクション処理システム、トランザクション処理方法、および、トランザクション処理プログラム
US8732191B2 (en) 2011-06-27 2014-05-20 Oracle International Corporation System and method for improving application connectivity in a clustered database environment
US20130013516A1 (en) * 2011-07-08 2013-01-10 Hamilton Andrew R Social network financial portal
US8630954B2 (en) 2011-12-15 2014-01-14 Visa International Service Association System and method of using load network to associate product or service with a consumer token
US20130339189A1 (en) 2012-06-18 2013-12-19 Jonathan Minerick Method and apparatus for facilitating real estate transactions
US10318911B1 (en) 2013-03-14 2019-06-11 Jpmorgan Chase Bank, N.A. Persistenceless business process management system and method
GB2533432A (en) 2014-12-18 2016-06-22 Ipco 2012 Ltd A device system, method and computer program product for processing electronic transaction requests

Also Published As

Publication number Publication date
US10997568B2 (en) 2021-05-04
US20170344960A1 (en) 2017-11-30
JP2018504862A (ja) 2018-02-15
JP6450471B2 (ja) 2019-01-09
EP3234890A1 (en) 2017-10-25
CA2971679A1 (en) 2016-06-23
CA2971679C (en) 2023-10-17
SG11201704895RA (en) 2017-07-28
AU2015365698A1 (en) 2017-07-06
AU2020202554A1 (en) 2020-05-07
EA201791341A1 (ru) 2017-11-30
EP4220514A1 (en) 2023-08-02
CO2017007201A2 (es) 2017-09-29
GB2537087A (en) 2016-10-12
WO2016097674A1 (en) 2016-06-23

Similar Documents

Publication Publication Date Title
SA517381730B1 (ar) نظام، طريقة ومنتج برنامج كومبيوتر لتلقي الرسائل الالكترونية
SA517381770B1 (ar) جهاز، نظام، طريقة ومنتج برنامج كومبيوتر لمعالجة طلبات معالجة إلكترونية
SA517381771B1 (ar) سطح بيني، نظام، طريقة ومنتج برنامج كومبيوتر للتحكم في نقل الرسائل الإلكترونية
SA517381772B1 (ar) سطح بيني، طريقة ومنتج برنامج كومبيوتر للتحكم في نقل الرسائل الالكترونية
US11521212B2 (en) System and server for receiving transaction requests