DESC:SAFESMS
FIELD OF INVENTION
[1] SafeSMS is an innovative short messaging service directed towards user’s identity management, credential management and privacy management. SafeSMS does not pertain to different messaging protocols; neither challenging any, nor being dependent on a particular protocol.
BACKGROUND OF INVENTION WITH REGARD TO DRAWBACKS ASSOCIATED WITH KNOWN ART
[2] Identity Systems are maturing rapidly, with brisk space of technological interventions brought in and massive computing and electronic storage being made available than ever before. Technology, even when it is binary, has not been able to increase the level of trust on ground. Massive programs, complex software, sophisticated and sensitive hardware are now readily available than before costing consumers and providers alike. Yet, the satisfaction or usability seems to be generally lacking or still complicated for implementation or usage

[3] A law enforcement officer, say checking a simple driving licence, or an identity card etc. either has to check back on the credential or use expensive hardware supported by numerous software and protocols or hold the credential for further check or keep a copy etc. etc., get the details matched for simple assurance of genuineness of the said credential, hence the identity

[4] Numerous admit cards are printed with varied codes such as bar codes or 3-D Bar codes or QR codes etc. for rapid admission to a particular place, involving not only short utility hardware, but involves lot of effort as well, yet, it is so easy to make a true copy and use the same with the same results ( avoidable certainly )

[5] One can imagine the threat / issues that can come up when an expired / revoked / cancelled credential totting participant comes up somewhere. The threat is not only towards physical security, but health security too, especially looking at the current COVID-19 pandemic

[6] Masquerading, Deceit, Proxy, Falsification, Untruthful, ID Theft are common place since time immemorial; despite all efforts and all claims towards a transparent and trusted identity

[7] Fake, false, similar named applications and websites ( and similar ) make it difficult for any requestor to completely trust a simple message providing the status of a credential; not to forget how it is child’s play to create screenshots or fake animated screenshots which are indeed similar to the real ones, but key data points obviously changed to suit a motive or purpose ( usually ulterior )
OBJECT OF INVENTION
[8] SafeSMSis a process easily implemented by any credential or identity repository or process to provide instant, real-time status on the said credential or identity; ensuring privacy aspects, never considered earlier, are formally in place. SafeSMS is a status message of the said credential or identity that gets triggered only on the actions of the user whose credential or identity status is being requested by anyone. SafeSMS is purpose, process, technology, platform, protocol agnostic and can adapt to any of such contemporary standards.
STATEMENT OF INVENTION
[9] SafeSMS is a simple plug in; incorporated in credential management systems or repositories or mature identity management systems or similar purpose electronic systems dealing with identity, credentials, privacy; wherein multiple pre-defined status messages get triggered by a candidate to provide the status of such credentials or identity to a requestor
SUMMARY OF INVENTION
[10] SafeSMS is a novel process which delivers a pre-configured status message to a requestor who is presented with a credential or an identity by a candidate.

[11] Definitions::

[12] Candidate :: a person or an entity or body corporate furnishing / claiming / displaying a credential to a requestor as requested / demanded by the said requestor. Candidates would be registered with a credential or identity repository or a system providing such services, whether in a matured state, standalone state, syndicated or federated state, who has been issued the said credential by an issuer and records of which are available in the said repository. The said registration of the said candidate may be voluntary or involuntary ( in case where specific databases are . can be deemed to be registration information itself for candidates )

[13] Requestor ::a person or an entity or body corporate who needs to instantly and accurately know in real-time, the status of a credential furnished/ claimed / displayed by a candidate registered with a credential or identity repository or a system providing such services, whether in a matured state, standalone state, syndicated or federated state, who has been issued the said credential by an issuer. Registration of the said requestor with such system, is ideal, but certainly not mandatory at all, the said system also not necessarily being the same where the said candidate has registered / stored the said credential ( repository / system / process )

[14] Issuer :: a person or an entity or body corporate who alone is the single source of truth for a credential and can provide the accurate status for the said credential, the said issuer be registered ( but, not necessarily or permanently ) with the same repository as that of the said candidate and has accorded the status to the credential previously when the said candidate had requested. The said Issuer may have their own independent repository or could have linkages to other Identity Repository ( ies ) or be part of such Identity Repository ( ies )

[15] Repository :: any credential management system which stores credentials ( under any status ) claimed by a candidate, providing a registration facility to its users ( candidate / issuer / requestor or any additional roles ), such registration not necessarily be voluntary and may be purposely created from one or more databases, may be government or privately or publicly controlled, may be single credential for all type repository or mature repository servicing multiple credentials of any type. The repository may be the individual Issuer itself having an independent database of the credentials issued by the said Issuer.

[16] Credential Status:: authenticated, authentication declined, authentication on hold, expired, invalid, recalled, cancelled, suspended, revoked, re-instated, re-instated with conditions, re-issued, re-issued against cancellation etc are all the status that an issuer can accord to a credential; time bound expiration of credentials could get accorded a system driven status though, but the first right for even the same remaining with the said issuer. One non-Issuer status is also enabled, viz. Self-Certified, wherein the said Credential is not yet authenticated / acted upon by the Issuer ( reasons being internal to Issuer), thus, the said Candidate owns up the authenticity of the said credential

[17] SafeSMSDestination:: based on delivery destination, SafeSMS delivers targeted assurance to Candidate or Requestor or Both.

[18] SafeSMS Candidate :: The said status message is sent to Candidate’s preferred mechanism ( which may be requested by the repository to be marked by candidate during its voluntary / involuntary registration process ), including, but not limited to cellular network based SMS services ( Mobile Phone Based ) or application based ( chat applications – web or mobile phone based ) or similar, or computer system based which allow receiving such messages or e-Mails or fax etc

[19] SafeSMS Requestor :: The said status message is sent to Requestor’s preferred mechanism, including, but not limited to cellular network based SMS services ( Mobile Phone Based ) or application based ( chat applications – web or mobile phone based ) or similar, or computer system based which allow receiving such messages or e-Mails or fax etc

[20] It needs to be clarified that the said requestor be not necessarily registered with said / any repository at all.
DETAILED DESCRIPTION
[21] SafeSMSProcess :: Any repository choosing to provide exceptional and useful service to its users would be keen to implement the simple plug in for each credential / credential type serviced by it.

[22] Program Instructions :: a simple code; technology agnostic; which needs to be configured into set of instructions which get triggered as and when chosen by the candidate for a particular credential or set of credentials or for differentiated services provided by mature credential or privacy or identity management systems ( to its candidate users ). The said code may reside as a graphical image or text or link or similar; may be a clickable / pressable button or similar facility; on one or every or only the defined credentials or similar set of credentials. Once triggered, the said set of instructions fetches the associated details of the said credential from its database and transmits the collected details to the candidate or the requestor.

[23] SafeSMS Message Variants :: Though these messages could be defined by the repositories choosing the SafeSMS service for their users, some variants are shown below ::

[24] Basic Status Message :: the basic variant is shown below which gets transmitted after the candidate initiated trigger fetches the associated details ( but necessarily not these details alone nor in the stated order shown below nor only in the format shown below ) ::

1. Candidate Name :: ABC
2. Credential Name :: My Passport
3. Credential Type :: Passport
4. Issuer Name :: Passport Office
5. Credential Status :: Authenticated by Issuer
6. Status last updated :: DD Mmm YYYY ( 1 )
7. Credential Issued :: DD Mmm YYYY ( 2 )
8. Credential Validity :: DD Mmm YYYY ( 3 )
9. SafeSMS Password :: No

[25] Secure Status Message :: the advanced / secure variant is shown below which gets transmitted after the candidate initiated trigger fetches the associated details ( but necessarily not these details alone nor only in the stated order shown below nor only in the format shown below ) and additionally is appended by a system generated password which the requestor can input on the candidate’s associated application and view the said credential for absolute certainty

1. Candidate Name :: ABC
2. Credential Name :: My Passport
3. Credential Type :: Passport
4. Issuer Name :: Passport Office
5. Credential Status :: Authenticated by Issuer
6. Status last updated :: DD Mmm YYYY ( 1 )
7. Credential Issued :: DD Mmm YYYY ( 2 )
8. Credential Validity :: DD Mmm YYYY ( 3 )
9. SafeSMS Password :: Open@1234

[26] Message Transmittal :: Based on the SMS Destination Variant and SMS Message Variant chosen to be serviced by the repository, the following steps are seen ::

[27] Option 1 :: On clicking the SafeSMS button, if SafeSMS Candidate option is chosen, then automatically the message is transmitted ( Basic Status Message or Secure Status Message ) and lands into the message receiving interface of the candidate

[28] Option 2 :: On clicking the SafeSMS button, if SafeSMS Requestor option is chosen, then automatically the message is transmitted ( Basic Status Message or Secure Status Message ) and lands into the message receiving interface of the requestor as well as the candidate.

[29] Credential View:: Mature Identity and Privacy Management Solutions may provide the facility for its users ( Candidates ) to instantly view select / all documents through a defined interface. Such systems may optionally

[30] Option 1 :: On clicking the SafeSMS button, if SafeSMS Candidate option is chosen, then automatically the message is transmitted ( Basic Status Message or Secure Status Message ) and lands into the message receiving interface of the candidate

[31] Option 2 :: On clicking the SafeSMS button, if SafeSMS Requestor option is chosen, then automatically the message is transmitted ( Basic Status Message or Secure Status Message ) and lands into the message receiving interface of the requestor as well as the candidate

[32] In case Secure Status Message is chosen, the password received by the requestor ( not the candidate ) would be able to open the said credential available in the candidate’s user interface ( provided by the repository as an app or a webapp or similar ).

[33] This would also ensure capturing the details of credential access ( in the repository ), by requestor, without the need for the requestor to register with the same repository or use the same interface, but gets recorded in the Access / Privacy Control of the Credential or Candidate.

[34] Anonymization ::SafeSMS provides the option to repositories to further provide privacy assurance by obfuscating key information of the candidate ( in part or or in full or use mature obfuscation technologies ), while fetching details from stored data and executing stored program instructions to transmit status message to intended recipient

[35] Examples for the urgently needed SafeSMS are more than one can imagine since SafeSMS perfectly patches the gap between reality and assurance, without the use of any hardware or mandated software to run the said hardware.

[36] Example 1 :: Law Enforcement Agency Officer ( LEAO )

[37] An LEAO pulls up a motorist and usually seeks the driver’s licence to drive. Rather than doing the routine things currently, all the LEAO needs to do is to seek a SafeSMS from the said driver. The repository holding the authentication status and / or issuer of the driving licence, allows the candidate to click a SafeSMS button, through its application interface. Candidate chooses Basic Status Message and the message with necessary, pre-defined details land on the candidate’s phone.

[38] Further, the LEAO seeks the Registration Certificate of the car to prove ownership. Instantly, the candidate selects the said credential and clicks on the Secure Status Message option. The pre-defined message lands on the LEAO’s phone, along with the password which is then input on the candidate’s interface to open up the credential, the Registration Certificate. Alternatively, in pandemic scenarios, where zero contact is absolutely essential, candidate is requested to input the password ( received by LEAO ) for opening the said credential.

[39] SafeSMS not only ensures trust, transparency and assurance, it does so with an easy process which is infallible. Zero contact is an added advantage, so critically essential in today’s world

[40] Example 2 :: Admission to an Examination Hall

[41] The proctor requests a candidate appearing for an examination to show the admit card to be admitted to the examination hall. Simply by seeing a Basic Status Message, the proctor views the admit card

[42] Example 3 :: Visitor to an establishment / office

[43] Perimeter security personnel would never had it that easy to decide to stop or let pass a visitor who may show any ID Card that may not be genuine; simply by requesting a Basic Status Message to be generated in real time showing if the credential being flashed is valid or not

[44] Additionally, the key details could be obfuscated to prevent any unauthorized data collection, a menace which has become so routine and not preventable in routine transactions

[45] Example 4 :: Pharmacist’s Assurance

[46] It is indeed child’s play to alter a medical prescription, which may prove to be dangerous / fatal, but an addict would not hesitate to do so. A pharmacist has expertise on pharmaceutical products, not forensics and has no means to know if the person seeking medication has indeed been given the prescription for restricted drugs or not. A Secure Status Message would provide the missing assurance and remove any doubts or ambiguities.

[47] SafeSMS provides unforeseen assurance on the authenticity of a credential, hence an Identity. With zero dependence on any specialized hardware and associated complicated software, SafeSMS provides an instant solution to eliminate ambiguities that prevent Trust and Privacy from being foundational in routine interactions.

,CLAIMS:CLAIMS
I claim,
1. A Novel process which delivers a pre-configured status message to a requestor, who is presented with a credential or an identity by a Candidate, comprising a candidate, a requestor, a issuer, a repository, credential status along with program instructions wherein, a simple code; technology agnostic; which needs to be configured into set of instructions which get triggered as and when chosen by the candidate for a particular credential or set of credentials or for differentiated services provided by mature credential or privacy or identity management systems ( to its candidate users ).

2. As claimed in claim 1, the said code may reside as a graphical image or text or link or similar; may be a clickable / pressable button or similar facility; on one or every or only the defined credentials or similar set of credentials.

3. As claimed in claim 1, once triggered, the said set of instructions fetches the associated details of the said credential from its database and transmits the collected details to the candidate or the requestor.

4. As claimed in claim 1, though these messages could be defined by the repositories choosing the SafeSMS service for their users.