DESC:TITLE : SAFECHAIN
FIELD OF INVENTION
[1] SafeChain is an innovative open-ended submission process which generates a unique SafeChain ID, which ensures convenience, ease, and security in application submissions for anyone and everyone. This SafeChain ID is generated through an electronic interface that has been built innovatively on the strong foundations of Identity Management, giving irrevocable and irrefutable trust on the Identity and / or Credentials and / or the purpose that an applicant is applying for or wishes to achieve

[2] SafeChain is an open-ended yet secure process that allows both registered and non-registered users of such system to undertake identified or non-identified or identified later, defined or undefined or additional, preset or formal or ad-hoc steps leading to process progress; at the same time either of the applicant or Requestor be able to add entities that may have an interest, implied or otherwise, in the said submission

[3] SafeChain is an open-ended, yet secure process, which is also privacy defined and privacy driven forming a defined sequence of smaller events in a related chain needed for desired objective of an Initiator. A privacy by default process that allows the submitter to not just drive, but also to be in loop for each step that any other party Initiates or undertakes and be in a position to stop / start, accept or decline, suggest or accept changes or modifications in the process progression at any point

[4] SafeChain is an end – to – end secure and transparent interface, wherein the applicant ( i.e. the Candidate ) utilizes his / her Credential ( s ) or Identity ( ies ) to submit an application as an Initiator or may also provide the same ( desired / expected / demanded ) details on the solicitation of a Requestor. The applicant as well as the Request or remain updated in real time on the status in the entire lifecycle of submitted application till its final disposal. Innovatively, both Candidate and Requestor are aware of any change in each submission component; changes that may have been effected by either or even an external party that may have been added by either for a specific purpose / action

[5] SafeChain, innovatively provides a uniform interface across submissions, even though such submissions could be infinitely similar / dissimilar, delivering remarkable advantage to everyone in minimizing or completely eliminating errors or mistakes that routinely creep in inadvertently at ends of both applicant ( s ) as well as the Requestor ( s ) as well as the Issuer ( s )

[6] SafeChain ID is a unique identifier, structured as alpha string or numeric string or alphanumeric string or a URI or a shortened link etc. which gets generated on the Initiation by either a Candidate ( who submits or is requested by a Request or to submit required details ) or a Requestor ( who receives the said details or requests a particular or a defined or undefined set of Candidates to submit their specified or unspecified details ) in a straight line process ( one – to – one ( Candidate to Requestor and vice-versa ) relationship ) or in a Stratified Open Process ( many – to – many ( Initiating Candidates and / or Initiating Requestors and / or Issuers ( providing inputs or addendum ) and vice-versa ) relationship );with either actor being able to call in additional parties ( Candidates or Issuers or Requestors ); not mandatory though, the said Issuer being a party who has the ability to issue a defined Credential to the said Candidate at any point in either straight-line or Stratified Open Processes and the said Issuer may or may not necessarily be part / peer / co-worker of the Candidate or Requestor. The said SafeChain ID undergoes its own lifecycle to be designated as Initiated or LIVE or closed or archived or deleted etc. to provide instant understanding of its status

[7] SafeChain also features an internal or external or optionally linked repository, which may or may not be driven by the tenets of a mature Identity Management System ( though preferred, but certainly not essential ) providing a complete record of the said submission ( s ), resultant ( s ) or status ( es ), all available in user ( Candidate / Issuer / Requestor )workspace in real -time.

[8] SafeChain innovatively provides an instant fallback / audit trail that has defined contours between the involved / participants, all the while being technology agnostic
BACKGROUND OF INVENTION WITH REGARD TO DRAWBACKS ASSOCIATED WITH KNOWN ART
[9] Anyone looking at today’s submission processes, internal or external could easily point them out as a cart drawing horses, while the expectation is contrastingly, the other way around. Furthermore surprising is that stories of someone ( each of us ) tend to forget / misplace submissions done previously, carelessly leaving behind an identity trail treasured by avoidable hunters / poachers

[10] Submissions or Applications for myriad purposes are not new for an applicant, just routine events, some important, some forgettable, some regrettable too; wherein the applicant’s submitted application remains ‘on-file’ with the Requestor ( someone who receives such application ). However, in today’s privacy-defined awakening, what happens to such ‘on-file’ details remains ‘internal’ to the said Requestor and blind to the identity owner

[11] Technology master maze is ever evolving, with advancements more in line as break-fixes than being resolutely purposeful to the core. A newer technology architecture often leads to orphaned data, yet again a treasure trove for identity hinters / poachers

[12] Even after the submission has been done, whether absolutely afresh ( with no previous details of the submitting Candidate available with the Requestor ) or re-processing any such available information for retuning Candidates, the Candidates usually get a very brief information as to the ‘status’ of the said submission, and is solely dependent on Requestor. However, in case external parties are involved, the Candidate has almost no means / rights / privileges ( seeking status or providing stimulus or guidance or requests etc. ) on such external third parties. The Candidates thus, usually remain in blind as to what is the real effort / status / issue related to the acceptance or declining of such a submission. This leads to unwanted and avoidable negativity or like, but adds up as delightful baits

[13] Submission systems today being primarily Requestor driven, need an urgent transformation wherein the submissions need to become Candidate driven and Candidate controlled, with the Candidate actually owning the process, even if it were Initiated by a Requestor, Candidates not only retain complete record of the said submission, its resultant or its status, but has all available in his / her repository in real-time, most importantly, be able to demand cessation / un-availability / zeroing of such data streams
OBJECT OF INVENTION
[14] SafeChain is a novel submission process with defined start and end points accommodating infinite open-ended middle processes; start and end points may or may not utilize a defined trusted identity emanating from a mature Identity Management System; each participating entity expected for a defined action / purpose generating feedback in real-time and providing a trusted trail
STATEMENT OF INVENTION
[15] An electronic submission system and process, between a Candidate ( submitter of details to a Requestor( s ) ) and / or from a Requestor ( Requestor being the receiver of the said details from a Candidate ( s ) ), either of the two capable of Initiating the said process, each such Initiation uniquely identified through the generation of a SafeChain ID ab-initio, each such process which could be a straight line process ( one Candidate– to – one Requestor) or Stratified Open Process ( one / many Candidates – to – many / one Requestors ) with either being able to include any third party for inputs / addendums supporting or opposing the said submission; such submissions be an application / request / solicitation / requisition / demand etc., but not limited to these alone; with each Stratified Open Process having layers of similar stratified or straight line processes or both that may have been Initiated previously or concomitantly or in future as and when Initiated by either Candidate or Requestor ( approved by Candidate for such Requestor Initiated actions )
SUMMARY OF INVENTION
[16] SafeChain is a novel process which innovatively solves the privacy aspect in routine submissions, at the same time bringing in trust, transparency, control, security with convenience; between

[17] Two defined terminal control point Actors( ideally registered, but certainly not mandatory, with such system ), called as Initiators in the system::

[18] Candidate :: a person or an entity or body corporate furnishing own details to the said Requestor ( s ) as desired

[19] Requestor :: a person or an entity or body corporate, receiving desired details from the said Candidate ( s )

[20] Infinite in-between point Actors( ideally registered, but not mandatory, with such system ) ::

[21] Candidate :: a person or an entity or body corporate, not the Initiating or an endpoint, furnishing own details or specified inputs as desired by one or more Candidates or one or more Requestor ( s )

[22] Requestor :: a person or an entity or body corporate, not the Initiating or an end point, receiving desired details from the said Candidate ( s )

[23] Issuer :: a person or an entity or body corporate, not the Initiating or an end point, capable of issuing a Credential in close time proximity or authenticating a previously issued Credential or procedurally issuing a Credential in future to a Candidate

[24] Infinite Chain Points ::

[25] Credential :: any paper or electronic document or detail, coming from mature Credential systems or generated in real-time or close time proximity or triggered ( automatically or manually ) on fulfillment of set conditions ( historically or in future ) issued to a Candidate

[26] Details :: any details manually or system generated, appended to any of the SafeChain processes that can be linked to any Candidate ( providing ownership ) or Requestor ( for reference ); the said detail being a detail / input / feedback / reference by any of the three Actors

[27] Participation :: any mode delivered to a non-participant by an existing participant of a SafeChain is able to securely participate and provide the desired / requested / needed inputs to the SafeChain. Such mode could be paper or electronic or a combination of both ( an electronically readable code printed / embedded / crafted on a paper )

[28] Template :: A simplified, structured form to fill Details / Credential Details / Input / Feedback etc.; available to all for meeting exacting requirements of SafeChain Process. Templates mimic a real form that is seen otherwise in paper / electronic form are instantly recognizable; all put together to minimize / eliminate inadvertent mistakes

[29] External Communication Requests :: Any Initiator who may need an input / detail / Credential feedback / reference etc. from one or more than one non-registered Candidate or Issuer or Requestor, can send out a request through the External Communication Requests process. Effectively, the requested non-registered entity is sent out a physical / electronic link / template / form to provide the required inputs and / or issue a Credential( physical or electronic ). Any of the contemporary or feasible communication means may include e-Mail, short messaging service ( SMS ), multimedia messaging service ( MMS ), implied service messages, explicit service messages, transactional messages, one time password messages, fax, postal mail, code scan ( QR / Bar / 2-D / 3-D etc. ), RFID ( active or passive ), etc. but either of these not being restrictively essential, with more than one means be allowed to be utilized

[30] SafeChain defines novelty in submissions in two independent open processes

[31] Straight Line Open Process :: a single process line with definitive start and end points; additional Candidates, Issuers and Requestors could be added at will; utilizing all available SafeChain Points

[32] Stratified Open Process :: a multi-dimensional prismatically layered defined process line, with two or more layers of Straight Line Open Processes adding / feeding into such layers; utilizing all available SafeChain Points

[33] Privacy Points :: the decision point allowing the Candidate ( s ) to respectively allow or restrict further process movement or withdraw previously accorded permission
DETAILED DESCRIPTION
[34] SafeChain System :: A system for managing online submissions comprising a memory, the memory comprising an electronic repository, and program instructions

[35] The electronic repository comprising a first plurality of records each representing; set of Candidate or Issuer or Requestor users registered or not registered as per role definition and execution

[36] A processor that executes the program instructions to execute communications between the electronic repository and the users

[37] The instructions configured such that Candidate or Requestor users Initiate a submission process based on the process type chosen by Initiator; such submission be for availing any type of product or services or offering candidature or declaration etc., but not limited to these alone, and may pertain to more than one such service or candidature or declaration

[38] In response to the Initiation, the said SafeChain system; on the instructions received from either Initiator, pulls in other Requestors or Issuers or Candidates for participation for successful / logical conclusion of the said SafeChain. This ‘pull’ could be manual or automatic based on the predefined parameters. Responses to such ‘pull’ requests too could be manual or automatic based on predefined parameters or previous instances

[39] The said system accessible through the internet or in a closed network for inward secure processes etc., but not limited to these alone; interfacing through a web browser or an app etc., but not limited to these alone; accessed on electronic devices such as a computer or a mobile phone or a tab etc., but not limited to these alone

[40] SafeChain Process is as easily implemented by a person skilled in the art as it is easily disclosed below in detail. It is imperative first of all to understand each role in detailed clarity ::

[41] A Candidate, who needs to submit required details to the Requestor. Any such Candidate can be of two sub-types ::

[42] CR or Candidate Registered :: simply a Candidate who has registered with the SafeChain system. Only CRs would be able to Initiate any SafeChain in the system

[43] CN or Candidate Not Registered :: simply a Candidate who has not registered with the SafeChain system

Figure 1 :: Roles – Candidate Types

[44] A Requestor, who needs to receive required details from the Candidate. Any such Requestor can be of two sub-types ::

[45] RR or Requestor Registered :: simply a Requestor who has registered with the SafeChain system. The RRs are of two further sub types ::

[46] RRI or Requestor Registered Internal :: simply a registered Requestor, but to whom the said SafeChain submission has not been Initiated with by the CR. They are the peer RR belonging to the same entity / body corporate / organization of the RR with whom the CR has actually Initiated the SafeChain

[47] RRE or Requestor Registered External ::simply a registered Requestor, but to whom the said SafeChain submission has not been Initiated with by the CR. They are not the peer RR belonging to the same entity / body corporate / organization of the RR with whom the CR has actually Initiated the SafeChain, but can be called / pulled into the SafeChain

[48] RN or Requestor Not Registered :: simply a Requestor who has not registered with the SafeChain system

Figure 2 :: Roles – Requestor Types
[49] Issuer, who has and / or can issue a Credential or detail or opinion to / for any Candidate at the request of either Candidate or Requestor. Such issuance could be in real-time, near time or in future. Any previously issued Credentials could be authenticated by the said Issuer as they remain the single source of truth forever. Any such Issuer can be of two sub-types ::

[50] IR or Issuer Registered :: simply an Issuer who has registered with the SafeChain system. The IRs are of two further sub types ::

[51] IRI or Issuer Registered Internal :: simply a registered Issuer, and are peers belonging to the same entity / body corporate / organization of the RR with whom the CR has actually Initiated the SafeChain

[52] IRE or Issuer Registered External ::simply a registered Issuer, but, not peers to the RRs of the same organization.

[53] IN or Issuer Not Registered :: simply an Issuerwho has not registered with the SafeChain system

Figure 3 :: Roles – Issuer Types
[54] Each of the above roles, Candidate, Issuer, Requestor; and their sub – types; could be an individual / entity / body corporate / organization etc.

[55] SafeChain gets Initiated by Candidate Registered ( CR ) or Requestor Registered ( RR ) only. The CR can select any of the open SafeChain positions listed by the Registered Requestor( RR ). On the other side, any Registered Requestor ( RR ) can Initiate a SafeChain and prospect any of the available CRs.

[56] SafeChain, once Initiated is a living chain, allowing every Initiator to keep it alive unless specifically closed. A closed SafeChain could be Initiated by either of Initiating end-points Initiating a re-open and the other agreeing to the same. A system defined closure could be defined, but is neither mandatory nor foreseeable.

[57] The Candidate has the privilege, convenience, and freedom to append the said SafeChain with any additional details at any point of time, till the SafeChain is marked as Closed. Such additional details could be added by the Candidate or requested for addition by other Registered Candidates or Issuers or Requestors.

[58] The Requestor has similar privileges to that of the Candidate to call in any other Candidate or Issuer or Requestor in to the said SafeChain.

[59] With above descriptions, Straight Line SafeChain and Stratified SafeChain processes are detailed below ::

[60] Straight Line Process :: a single process line with definitive start and end points; additional Candidates, Issuers and Requestors could be added at will. The definitive end points could only be the Initiators, who could in turn only be the registered users. Non-Registered Users could still participate in SafeChain only when pulled in by either of the Initiators, ( diagrammatically shown in Figure 4 :: Sample SafeChain Flow ) ::

Figure 4 :: Sample SafeChain Flow
[61] The above figure provides exceptional clarity to a person skilled in the art as to how the SafeChain process is simplified, systemized, and executed.

[62] A group of registered and non-registered users are provided a registration mechanism. This mechanism may be SafeChain system based itself or may get fed by mature Identity Management Systems. Users can register or stay unregistered. Only once registered though, either the Candidate or the Requestor users can take the role of an Initiator.

[63] If Candidate, one Candidate( CR ) simply Initiates the SafeChain by selecting one Requestor( ABC ) who would receive and to whom the said SafeChain would terminate into. The Candidate additionally can fill a form or provide templatized details or attach Credentials, review the entire submission, finalize, ( optionally, if mandated ) agree to defined terms and / or conditions and / or privacy requirements and / or consent and / or withdrawal of any of these parameters and then finally submit the SafeChain

[64] Once submitted, the SafeChain is instantly reflected in Requestor’s work area / queue for further actions. These actions may include a simple acceptance or multiple, shown in boxes S5 –S8, but not limited to the shown sample processes alone; such processes being infinite. The Requestor of an entity ‘ABC’ could pull in additional peer Requestors( Requestor RRI – 001 ( ABC ) or Requestor RRI – 002 ( ABC ) ) or peer Issuers ( Issuer IRI – 001 ( ABC ) or Issuer IRI – 002 ( ABC ) ). The said peer Requestors could undertake internal actions while the Issuers could issue Credentials to the Candidate, each resultant being instantly viewed / notified in real-time, near-time, on set-time, till defined time by the defined registered or non-registered users in the said Safe-Chain.

[65] Either of the Initiators may also optionally include non-registered users through the defined communication requests. These requests could be sent out to any external non-registered or registered Candidate or Issuer or Requestor. The registered users are shown as Requestor RRE of an entity ‘DEF’ in S1 and Requestor IRE of an entity ‘GHI’ in S2 while the non-registered users are shown as Requestor RN of an entity ‘MNO’ in S4 and Issuer IN of an entity ‘JKL’ in S3. Any of the external communication requests facilitate the non-registered users to land on the work area which allows them to take requested actions at their end.

[66] Any action, favorable or adverse, of any user of the SafeChain results in the same being available / visible / notified to all users of the said SafeChain.

[67] Either of the Initiators could Initiate the closure of the said SafeChain and on acceptance of the other, the same could get marked as Closed, as shown in SafeChain1, SafeChain2, SafeChainN. Effectively, no further actions are allowed by any user once the SafeChain is marked as closed. The closure could also be time-bound, post which the said SafeChain system would automatically get marked as closed. Participating users do not get notified of any further actions taken by either Initiator on the Closed SafeChain

[68] The closed SafeChain ( s ) could be viewed by any of the participating users at any time till they are marked as Archived by either Initiator. However, either Initiator could view them at any time. Archived SafeChain ( s ) cannot be used for any further participation / processing into other Stratified SafeChains

[69] The closed SafeChain ( s ) could be deleted by either Initiators as well, simply notifying the other of the same and debarring the other from any further viewing / usage.

[70] Stratified SafeChain Process :: a multi-dimensional prismatically defined process line, with two or more layers of straight line processes adding / feeding into such layers.

[71] This gets Initiated by specifically selecting Stratified SafeChain by either Initiator.

[72] As the next step, Initiator Initiates a Straight Line SafeChain as explained above.

[73] Initiators are able to pull in a previously closed as well as LIVE SafeChain ( with participating users duly notified / permissions taken if mandated ) into the SafeChain created in the previous step.

[74] The same figure (Figure 4 :: Sample SafeChain Flow) could be extrapolated / visualized as layers of SafeChain feeding into / out to each other forming a prismatic visualization.

[75] SafeChain on its own, acts as an enabler only. SafeChain does not add / append / influence anything / any step on its own and is governed, moved forward by the involved actors alone.

[76] SafeChain derives Privacy to the very core and thus Privacy gets engrained as a permission that Candidate alone can provide to an action in the SafeChain, even if the said action is Initiated by any other actor. Say for example, an Issuer issues an opinion or a detail or a Credential at the request of a Requestor, the same gets added as an approved opinion / detail / Credential only if the said Candidate accepts the same. Furthermore, Candidate can use the benchmark Privacy Lock process seen in industry standard Identity Systems of highest maturity, such as ::

[77] View Only, i.e. the Requestor or even the Issuer ( post issuance ) can only view the said data only approved by the Candidate. Certainly, no changes can be made by any Requestor or Issuer or even the Candidate

[78] Download Privilege, i.e. allowing anyone or defined Issuers or Requestors to download the opinion / detail / Credentials approved by the Candidate for doings so

[79] Access Conditions ::

[80] Access Period :: i.e. the time period or trigger defined by the Candidate wherein the approved opinion / detail / Credentials could be accessed

[81] Candidate Access Period :: i.e. the time period or trigger defined by the Issuer within which the Candidate could approve the opinion / detail / Credentials issued by the Issuer

[82] Access Rate :: The Candidate is clearly able to define the frequency or the rate or the number of times that the said opinion / detail / Credentials therein could be accessed

[83] Access Trigger ::Candidates can select automatic triggers, for opinion / detail / Credentials for granting access or withdrawing access or suspending access to one or many

[84] Anonymization :: SafeChain provides the option to Candidates to self-anonymize by selecting this option. Candidate’s specific / all details get meaningfully obfuscated through a cipher, unique to SafeChain providing instant, real-time stealth capabilities. This unique application of a cipher ensures security at the orifice, not just in transit or at rest. SafeChain System defined cipher can be deciphered only by SafeChain system. Additionally, innovatively, SafeChain allows user – defined cipher as well, not decipherable by SafeChain System. This ensures not only security at orifice, but also unmatched privacy

[85] SafeChain’s Safe Submit Window :: A simple process, through which the Candidate expresses an intent for Initiating a SafeChain process through a submission to Requestor, but defines a ‘Submission hold’ period and then submit the SafeChain. Once this ‘Submission hold’ period lapses, the said SafeCase would automatically get submitted or withdrawn as defined by Candidate

[86] SafeChain Requestor SafeCode ::Through this option, a Requestor may provide a specific SafeChain Requestor SafeCode, which is a numeric or alpha or alphanumeric or system generated graphical code or user defined system generated graphic code or embedded to / pulled from a physical device such as a card or biometric card etc. character string or phrase code or codified / code embedded graphic image to specific / qualifying Candidates to ensure quality / targeted participation. Candidate needs to input this SafeCode to Initiate such SafeCode SafeChain process with the said requestor

[87] SafeChain SafePassand SafeChain Candidate SafeCode ::Another privacy feature in SafeChain is SafePass which allows the Candidates to setup a SafeChain Candidate SafeCode which is a numeric or alpha or alphanumeric or system generated graphical code or user defined system generated graphic code or embedded to / pulled from a physical device such as a card or biometric card etc. character string or phrase code or codified / code embedded graphic image. In SafeChain SafePass, Candidate simply defines the frequency or times for which the SafeChain ID can be accessed by each of the other participants or as per pre-defined frequency set by SafeChain system. Additionally, Candidate users could be provided a random system generated Candidate SafeCode for additional security of the said SafeChain. The Candidate SafeCode prevents unauthorized access or forwarding of the SafeChain or SafeChain ID innovatively and assuredly securing the privacy. Candidate may at will change this SafeChain Candidate SafeCode if defined as allowed in the said SafeChain process

[88] SafeChain SafeUpdate Requests ::The process through which the both the Initiators, Candidate and Requestor are able to request the SafeCase system to check for available updates with any of the participants in a SafeChain. Once an update is identified by the SafeChain System, they are advised of the same. The Safe Update Request is a time-bound process, the request or check done expiring after user defined time-period set as default by SafeChain system or either Initiators.

[89] SafeChain SafeUpdate Auto ::The process through which the Initiators, during the process of Initiation of a SafeChain, pre-approve update requests of each other and automatically receive updates from each other, if any. The SafeUpdate Auto is valid across a pre-defined time-period which could also be set by Initiators. However, as, and when either Initiator gets an auto-SafeUpdate, the other Initiator does get the due notification for the same

[90] SafeChain SafeUpdate Issuer :: The Issuer, who has actually issued the Credential in a SafeChain to the said Candidate has a limited, but critical role in SafeChain Process. In case the said Issuer, single source of truth for the Authentication ( not Verification ) of the said Credential( s )Initiates an action, impacting the Credential or the purpose directly or indirectly, the SafeChain System generates an Alert automatically to the Initiators, such changes being ( but not limited to )Revocation, Suspension, Deletion, Invalidation due to defined time limit ( past expiry date or a change to the expiry date ) and subsequent updating actions of Reinstatement or Reissuance or Validity Extension. The Issuer is also able to define if such changes could be pushed automatically to the Credential( s )being utilized in a SafeChain. Said Requestors need to request the said Candidates for approving the said updates. In case the Issuer does push the said update, Candidate gets informed first on such actions for their records and once approved, they are received by the Requestor as well

[91] SafeChain SafeFill Process :: This process allows the registered users to instruct the SafeChain system to automatically fill the specific form during the course of their participation in a SafeChain. This process further allows the registered users to also update such information, overwriting the information automatically filled or adding the information previously not available. Further to this all such overwritten information is captured as additional information and missing information so filled is captured as available information for future usage.

[92] SafeChain SafeArchive ::Any SafeChain which is deemed as old and / or unusable and / or has outlived its defined usage life can be archived by the Initiators and / or registered participants at their ends without impacting the other Initiator or other participants.

[93] SafeDelete :: The registered participants are able to request for deletion of SafeChains where they have participated. Such SafeChains are removed from active SafeChain System and cold archived on non-accessible media as per defined security and or other SafeChain policies

[94] SafeChain can be easily and perfectly visualized as asuppositious example in the contemporary COVID-19 pandemic scenario( or even in healthy times )

[95] SafeChain 1 :: A candidate initiates a SafeChain to The Embassy of Country A. Along with the auto filled forms ( based on details already available in the system ) or fills up details diligently, attaches a copy of passport and other required credentials, attaches a fee payment cheque, and submits the SafeChain.

[96] The Embassy on its part, pulls in multiple issuers :: Passport Issuing Office; Employer if employed or Institution if a student etc. ( could be IRI or IRE or IN ). Once these issuers authenticate their respective Credentials, the SafeChain is updated.

[97] The Embassy further adds candidates ( CN or CR ( but not the initiator ) ) who have been mentioned in the application form as references. They may provide the due details and the same are updated in the SafeChain

[98] The Embassy further adds the accommodation provider, say a hotel or conference organizer or travel insurance provider or similar requestors ( RN or RRE ) who could provide the requested inputs on the purpose or duration or coverage etc

[99] The Embassy further adds the Bank ( IRI or IRE or IN ) to validate the cheque to guarantee clearance as well.

[100] The updates to the SafeChain continue till the time all such prerequisites are fulfilled for granting the requested visa.

[101] SafeChain 2 ::The Embassy directs a visa applicant to get Vaccinated or Certified for being specific disease free. Basis this SafeChain, the CR ‘pulls’ a care provider ( IRE or IN ) into the said SafeChain; who in turn issues the required credential stating their findings.

OR

[102] SafeChain 2 :: The Candidate could initiate the SafeChain, with the Hospital as the requestor to provide the Candidate with specific medical procedure or testing and issue a credential thereof.

[103] SafeChain 3 :: The Candidate requests for a room booking at a hotel ( RR ), who in turn requests the Candidate to either provide the credential dossier ( s ) and all the Candidate has to do is to pull the SafeChain 1 ( [95]and SafeChain 2 [101]as stated above.

[104] SafeChain 4 :: The Candidate initiates a SafeChain with the Airline, who checks the SafeChain including the above SafeChain 1 ( [95] and SafeChain 2 [101] and SafeChain 3 [103] ) and issues ( by IRI ) the boarding ticket, which also gets fed into SafeChain 4 ( [105] ). If this could be further supposed, candidate could get all this done even before entering the said port, wherein it would not be required to queue up at all

[105] SafeChain 5 :: Further at the port of arrival, at the immigration counter, the Candidate could simply state the SafeChain ID to the Immigration Officer ( RRI ) who was pulled in by Immigration Authority ( RR ) through a SafeChain initiated by Candidate even before leaving the port of disembarkation.

[106] This SafeChain, as the first step includes the above SafeChain 1 ( [95] and SafeChain 2 [101] and SafeChain 3 [103]and SafeChain 4 ([104]), issuing or denying the arrival stamp instantly.

[107] SafeChain 6 :: The candidate, while exiting the said country, could initiate this SafeChain which includes updated information from any and / or each participant in SafeChain 1 ( [95] and / or SafeChain 2 [101] and / or SafeChain 3 [103] and / or SafeChain 4 ( [104] )and / or SafeChain 5 ( [105] ) to request for ‘depart’ stamping.

[108] SafeChain 7 :: The Candidate could initiate a SafeChain with one’s employer too to settle travel expenses and include the above SafeChain 1 – 6 or additional SafeChain IDs supporting the said expenses.

[109] Needless to say, SafeChain IDs provide instant referencing / trail to each participant as and when the need be and very well within the tenets of privacy ::Defined, Driven, and Owned by respective participants – not just singularly.

,CLAIMS:CLAIMS
I Claim,

1. A system for managing online submissions between comprising: a memory, the memory comprising an electronic repository, and program instructions; the electronic repository comprising: a first plurality of records each representing one of a set of candidate users registered or not registered as a candidate user with the system, a second plurality of records each representing one of a set of issuer users registered or not registered as issuer with the system, and a third plurality of records each representing one of set of requestor users registered or not registered as a requestor with the system; and a processor that executes the program instructions to execute communications between the electronic repository, the candidate users, the issuer users, and the requestor users; the instructions configured such that either of the registered candidate or registered requestor initiates an online submission between them such that the candidate user provides requisite details to the said requestor who needs to process the said details to provide a service or product or similar action to the said candidate.

2. As claimed in claim 1, a SafeChain ID that gets generated on initiation by either of registered candidate or registered requestor and provides a real time update to any action taken by the said candidate or said requestor to the other; such SafeChain ID being generated for Straight Line and Stratified processes; both being readily compatible and supportive to each other, yet completely independent; outputs of either being utilized by any number of such SafeChain in real-time, near time or in future.

3. As claimed in claim 1, a SafeChain Pull Process wherein either initiator pulls or requests other candidates, registered or non-registered; or requestors, registered or non-registered; or issuers, registered or non-registered; actions of whom get notified in the said SafeChain in real time or near time or in future; including assertion on previously issued credentials or providing references; each such user notified of each action taken by pool of such participants.

4. As claimed in claim 1, Privacy defined SafeCode SafePass process which allows any of the Candidate users to define a which is a numeric or alpha or alphanumeric or system generated graphical code or user defined system generated graphic code or embedded to / pulled from a physical device such as a card or biometric card etc. character string or phrase code or codified / code embedded graphic image; and the frequency and time period of access allowed to any of the participants.