DETAILED ACTION
Acknowledgements
This office action is in response to the claims filed December 22, 2025.
Claims 1, 4-5, 9, 11-15 are pending
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Request for Continued Examination
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 12/22/2025 has been entered.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1, 4-5, 9, 11-15 are rejected to under 35 U.S.C 101 as not being directed to eligible subject matter based on the grounds set out in detail below:
Independent Claims 1 and 9:
Eligibility Step 1 (does the subject matter fall within a statutory category?):
Independent claim 1 falls within the statutory category of method.
Independent claim 9 falls within the statutory category of machine.
Eligibility Step 2A-1 (does the claim recite an abstract idea, law of nature, or natural phenomenon?): Independent claims 1 and 9 (claim 1 being representative) claimed invention is directed to an abstract idea without significantly more.
The claim elements which set forth the abstract idea in the independent claims (claim 1 being representative) is:
A method for vaccination management…[…]… associated with an identity certificate authority…[…]… associated with a vaccination management agency
associated with a user who is a vaccinator
an identifier of the identity certificate authority, an identifier of the vaccination management agency, and an identifier of the medical institution
the method comprising: transmitting, , a vaccination certificate issuance request including vaccination information for the user, a vaccination agency VC for the medical institution, and a signature of the medical institution
performing a first comparison, between an identifier derived from a signature of a VC issuer included in the vaccination agency VC and the identifier of the vaccination management agency
stored, in response to the vaccination certificate issuance request;
performing a second comparison, , between an owner identifier of the vaccination agency VC included in the vaccination agency VC and an identifier derived from the signature of the medical institution
issuing, a vaccination certification VC including the vaccination information
transmitting, , the vaccination certification VC
and storing, the vaccination certification VC
This abstract idea is “certain methods of organizing human activity” as it is managing personal behavior and following rules or instructions to transmit, issue, and store a vaccination certification MPEP § 2106.04(a)(2))
Eligibility Step 2A-2 (does the claim recite additional elements that integrate the judicial exception into a practical application?): For Independent claims 1 and 9 judicial exception is not integrated into a practical application.
Independent claim 1 recites the additional claim elements below:
a trusted institution server associated with a trusted institution including an identity certification server
a vaccination management server
a medical institution device associated with a medical institution;
a user device
a blockchain network that includes a public distributed ledger
a first storage space of the public distributed ledger being set to be modifiable only by the trusted institution server
a second storage space of the public distributed ledger, wherein the second storage space of the public distributed ledger is modifiable by the user device
a digital signature of the medical institution, to the trusted institution server;
a medical institution database stored in the trusted institution server
Examiner takes the applicable considerations stated in MPEP 2106.04 (d) and analyzes them below in light of the instant applications disclosure and claim elements as a whole.
No additional element is performing the abstract idea.
The additional element, a trusted institution server associated with a trusted institution including an identity certification server, merely “apply-it” as its used as a tool to apply the abstract idea
The additional element, a vaccination management server, is merely “apply-it” as it is used as tool to apply the abstract idea
The additional element, a medical institution device associated with a medical institution, is merely “apply-it” as it is used as tool to apply the abstract idea
The additional element, a user device associated with a user, is merely “apply-it” as it used as tool to apply the abstract idea
The additional element, a blockchain network that includes a public distributed ledger, is merely generally linking the abstract idea to the environment of blockchain
The additional element, a first storage space of the public distributed ledger being set to be modifiable only by the trusted institution server, is merely “apply-it” as it used as tool to apply the abstract idea
The additional element, a second storage space of the public distributed ledger, wherein the second storage space of the public distributed ledger is modifiable by the user device, is merely “apply-it” as it used as tool to apply the abstract idea
The additional element, a digital signature of the medical institution, to the trusted institution server, is merely “apply-it” as it used as tool to apply the abstract idea
The additional element, a medical institution database stored in the trusted institution server, is merely “apply-it” as it used as tool to apply the abstract idea
Accordingly, independent claims 1 and 9 as a whole do not integrate the recited abstract idea into a practical application (MPEP 2106.05(f) and 2106.04(d)(1)).
Eligibility Step 2B (Does the claim amount to significantly more?): The independent claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception because the computer element as analyzed above in step 2A prong 2, is merely applying the abstract idea and therefore, does not amount to significantly more. The claims are patent ineligible.
Dependent Claims 4-5 and 11-15:
Eligibility Step 1 (does the subject matter fall within a statutory category?):The dependent claims 4-5, 11, and 13-15 fall within the statutory category of method and claim 12 falls within the statutory category of machine.
Eligibility Step 2A-1 (does the claim recite an abstract idea, law of nature, or natural phenomenon?): Dependent claims 4-5 and 11-15 claimed invention is directed to an abstract idea without significantly more. The claims continue to limit the independent claim 1 and 9 abstract idea by (1) comparing the data (2) verifying the data , (3) generating identifiers model, and further limiting comparisons of data to present. Therefore, the dependent claims inherit the same abstract idea which is “certain methods of organizing human activity” as it is managing personal behavior and following rules or instructions to transmit, issue, and store a vaccination certification MPEP § 2106.04(a)(2))
Eligibility Step 2A-2 (does the claim recite additional elements that integrate the judicial exception into a practical application?): For claims 4-5 and 11-15 this judicial exception is not integrated into a practical application.
The dependent claims recite the below additional elements not already recited in the independent claims
A third party device
a screen displaying
World Wide Web Consortium (W3C) standard protocol
Examiner takes the applicable considerations stated in MPEP 2106.04 (d) and analyzes them below in light of the instant applications disclosure and claim elements as a whole.
The additional element, a third party device, is merely “apply-it” as it is used as a tool to manipulate data.
The additional element, a screen displaying, is merely “apply-it” as it is used as a tool to output data
The additional element, World Wide Web Consortium (W3C) standard protocol, generally linking the abstract idea to the environment of the internet
Accordingly, the dependent claims as a whole do not integrate the recited abstract idea into a practical application (MPEP 2106.05(f) and 2106.04(d)(1).
Eligibility Step 2B (Does the claim amount to significantly more?): The dependent claims do not include additional elements that amount to significantly more for the same reasons given in Prong 2. The claims are patent ineligible.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1, 4, 6, 7, 8, 9, 10, 11 and 12 are rejected under 35 U.S.C. 103 as unpatentable over DAY et. al (hereinafter DAY) (US20220191048A1) in view of Anderson et. al (hereinafter Anderson) (US20210287770A1)
As per claim 1, DAY teaches:
A method for vaccination management including a trusted institution server associated with a trusted institution, ([0039] discloses, “To summarize , each VaccineGuard vaccination certificate creates a reliable link between a specific individual , an authentic vaccine dose and a trusted healthcare institution.” ),
including an identity certification server associated with an identity certificate authority and a vaccination management server associated with a vaccination management agency (see Fig. 3 and Fig. 5 which discloses a platform with systems such as the healthcare facility which is the issuer of the vaccination certificate there for the identity certificate authority (see instant spec. definition in para. [0065]) and discloses a national /international / public health authority which verifies the certificate through management platform Vaccineguard 500 system and see [0036] discloses, “The provider of vaccination services as well as the issuer of the vaccination certificate is preferably an authorized healthcare or health data service provider . Such institutional authorization is typically provided by a government or other internationally recognized entity . VaccineGuard certificates preferably originate only from an Issuer that belongs to a trusted list , which can be digitally verified ; this provides a trust framework.” And see [0067] and see [0026] [0027] discloses, “104 : Public Health Monitoring The healthcare worker administers the vaccine to the Patient and logs it onto the user's vaccination certificate . The information can also be extracted and de - identified and automatically submitted for monitoring purposes by the Health Authority . Again , PII sharing is NOT needed.” And see Fig. 3 and Fig. 5 which discloses, and see [0053] discloses, “FIG . 3 illustrates the procedure of provably recording information generated by the certificate Issuer 310 in the KSI blockchain 500 , which will entail obtaining a KSI signature for that information , as well as the verification procedure , in which a Verifier 320 checks presented information by Patient 320 may confirm the validity of the KSI signature of the Issuer information . FIG . 3 also illustrates that the KSI blockchain , that is , the KSI signature infra structure , provides cryptographic proof t of information input into it , but does not require actual PII to do so”)
a medical institution device associated with a medical institution, (see Fig. 5, 530),
a user device associated with a user who is a vaccinator, (see Fig. 3, 310 and Fig. 5, 530 )
and a blockchain network that includes a public distributed ledger, ([0104] discloses, “For additional security , the Guardtime signatures can be extended after a number of calendar periods up through a progressively growing Merkle tree of calendar values , or a hash - chaining linkage of calendar values , to a publication value that is published in any widely witnessed manner , such as in a printed publication , an online database , in a ledger , in a blockchain , etc. It is also possible to forego the accumulation of calendar values via a Merkle tree and instead enter each calendar value into some widely witnessed data structure such as a blockchain - backed ledger ; indeed , the Guardtime KSI calendar itself has a blockchain structure , and may itself be sufficient even without additional hashing using a Merkle tree and publication.” And see [0105] discloses, “The KSI system then returns a signature ( referred to here as a “ KSI signature ” ) in the form of a vector , including , among other data , the values of sibling nodes in the hash tree that enable recomputation of the respective calendar value , or extended to the corresponding publication value , if a purported copy of the corresponding original input record is in fact identical to the original input record.” And see [0107] discloses, “One other advantage of using a Guardtime infra structure is that there is no need to store and maintain public / private ( such as PKI ) key pairs — the Guardtime system may be configured to be totally keyless except possibly for the purposes of identifying users or as temporary measures in some implementations in which calendar values are themselves combined in a Merkle tree structure for irrefutable publication . Another advantage is less apparent :Given the signature vector for a current , user - presented data record and knowledge of the hash function used in the hash tree , an entity will be able to verify ( through hash computations as indicated by the signature vector ) that a “ candidate ” record is correct even without having to access the signaturel timestamping system at all : If the same information is made available as formed the input to receive the KSI signature , then it is certain that , using the presented , purportedly correct , information to recompute “ upward ” through the KSI hash tree by iteratively hashing with the values in the signature , if the same root value is obtained ( which is also included in the KSI signature ) , then the presented information is in fact identical to the input originally used to generate the signature.” And see [0108] discloses, “Yet another advantage of the Guardtime infrastructure is that the digital input records that are submitted to the infrastructure for signature / timestamping do not need to be the “ raw " data ; rather , the raw data may optionally be combined with other input information ( for example , the salt value , or such information as input server ID , Patient ID , location , etc. ) and then hashed . Given the nature of crypto graphic hash functions , what gets input into the KSI system , and thus ultimately into the calendar blockchain , cannot be reconstructed from the hash , or from what is entered into the calendar blockchain . If an entity , in compliance with GDPR , for example , assures a user that his raw data has been “ forgotten " in its database ( an action that itself may be recorded in the blockchain ) , then the information encoded in the Guardtime KSI blockchain structure may remain as is , since it is impossible to deduce what raw data led to it . This is in contrast to many existing blockchain solutions , whose blocks include raw data : Deleting or altering any block in such a blockchain renders the chained linking data invalid ; alternatively , creating a forked , that is , parallel blockchain path to accommodate a deletion weakens or destroys the security and trustworthiness of the system as a whole” and see [0086] discloses, “Healthcare organizations that are authorized ( see above ) to have a VaccineGuard account may use the soft ware to certify vaccination records and generate vaccination certificates . The data is created on the machine , which is controlled and managed by the organization ( for example within a single physical network ) , and may also be stored within the healthcare organization's digital infrastructure . At least from the perspective of VaccineGuard , there is no need for the data of the vaccine certificate ever to be stored centrally or in some other central data structure . The certificate may , however , be sent directly to the patient by the healthcare organization or exchanged with national authorized entities , if relevant” and see [0042] discloses, “a . The identity and , in most cases , some form of national authorization identifier of an authorized healthcare provider 200” and see [0102] discloses, “KSI Signatures [ 0103 ] Digital signatures are used in the invention . Many known signature schemes may be used as long as they can be encoded in the marking ( such as QR code ) and the verifier's device is configured to read it . A particularly advantageous form of digital signature , however , and the one mentioned above by way of illustration , is the one generated using the data signature infrastructure developed and marketed under the name KSI® by Guardtime AS of / examiner notes that guard time KSI is a specific implementation of a public distributed ledger and that the trusted institution can modify as they are necessarily identified )
…[…]…the method comprising: transmitting, by the medical institution device, a vaccination certificate issuance request including vaccination information for the user, a vaccination agency VC for the medical institution, and a digital signature of the medical institution, to the vaccination management server ([0074] discloses, “For the sake of properly managing privacy , data should preferably be stored appropriately . In embodiments of VaccineGuard , data may reside wherever the data owner chooses . The data may be kept locally on a commercial computing device . As just a few examples , it may be stored on a smartphone or laptop , or in a database within a hospital network ; it can be hosted in a specific and acceptable cloud service provider , etc.” and see [0075] discloses, “use in such a traditional model environment ,however.” And see [0076] discloses, “The VaccineGuard solution manages three types of data or data objects :” and see [0077] discloses, “1 ) Vaccination Records and Vaccination Certificates [ 0078 ] These are created by authorized healthcare organizations to prove events of vaccination administration and full vaccination status.” And see [0079] discloses, “Vaccine records , stored by health organizations for record keeping and verifying vaccination progress while vaccine certificates are given to citizens.” And see [0080] discloses, “Vaccination certificates preferably do not contain personally identifiable information other than , optionally , the patient's name , signature , etc. , but do contain a mechanism to link the vaccine certificate to a valid vaccine and an authenticated citizen.” And see [0081] discloses, “2 ) Vaccine Data” and see [0082] discloses, “Vaccine data provides proof of validity for the specific vaccine and specific contextual information such as , for example , how many doses the specific serial number stands for , how many vaccine doses are required to reach adequate immunity , etc. this includes possible counterfeits”) and see [0086] discloses, “Healthcare organizations that are authorized ( see above ) to have a VaccineGuard account may use the soft ware to certify vaccination records and generate vaccination certificates . The data is created on the machine , which is controlled and managed by the organization ( for example within a single physical network ) , and may also be stored within the healthcare organization's digital infrastructure . At least from the perspective of VaccineGuard , there is no need for the data of the vaccine certificate ever to be stored centrally or in some other central data structure . The certificate may , however , be sent directly to the patient by the healthcare organization or exchanged with national authorized entities , if relevant” and see [0041] discloses, “Second , the data describing vaccination of an indi vidual— personal details , administered vaccine , relevant contextual information is then captured by the trusted healthcare provider , who guarantees that the data entry is accurate . FIG . 2 illustrates this information capture and entry in the context of vaccination certification . Information that may be included in a certificate will typically include :” and see [0042] discloses, “a . The identity and , in most cases , some form of national authorization identifier of an authorized healthcare provider 200” and see [0043] discloses, “b . Patient identity information 210 , which may established using any conventional means , such as by a national ID card , a passport , or some other approved document” and see[0044] discloses, “C. A vaccine and / or testing marking 220 , which may follow any known protocol such as GS1 or HL7” and see [0045] discloses, “d . Vaccination data 230 , such as according to the IHR or FHIR protocols” and see [0100] and [0101] and see [0053] discloses, “he connected photo - ID.” And see [0053] discloses, “FIG . 3 illustrates the procedure of provably recording information generated by the certificate Issuer 310 in the KSI blockchain 500 , which will entail obtaining a KSI signature for that information ,”)…[…]…
However DAY does not teach portions:
wherein a first storage space of the public distributed ledger is set to be modifiable only by the trusted institution server,
and the first storage space stores an identifier of the identity certificate authority, an identifier of the vaccination management agency, and an identifier of the medical institution
performing a first comparison, the vaccination management server, between an identifier derived from a digital signature of a VC issuer included in the vaccination agency VC and the identifier of the vaccination management agency stored in the first storage space of the public distributed ledger, in response to the vaccination certificate issuance request;
performing a second comparison, by the vaccination management server, between an owner identifier of the vaccination agency VC included in the vaccination agency VC and an identifier derived from the digital signature of the medical institution, in response to the vaccination certificate issuance request;
issuing, by the vaccination management server, a vaccination certification VC including the vaccination information, , and a digital signature of the vaccination management agency, based on a result of the first comparison and a result of the second comparison;
transmitting, by the vaccination management institution server, the vaccination certification VC to the user device; and storing, by the user device, the vaccination certification VC in the user device.
However, Anderson does teach:
wherein a first storage space of the public distributed ledger is set to be modifiable only by the trusted institution server, ([0042] discloses, “Referring to FIGS . 3 and 4 together , in addition to the communications through the public DIDs , participants of the diagram 300 also establish trusted , private , and crypto graphically secured lines of communication between any two participants . An issuer 302 can establish unique con nections with various patients 304 through respective con nection requests , and a verifier 306 can establish unique connections with patients 304 on an as - needed basis . Initial connection requests can be made using the public DID information of the target participant to be connected , which is stored on the public identity ledger 310. This public DID document defines the endpoint at which the participant can be reached , as well as details on how to establish a secured connection , for example , by using the public key of the target participant . Upon an initial connection being estab lished through the public DID , the two participants can then proceed to establish their private DIDs dedicated or unique for the private secured connections therebetween , which include private endpoints and key pairs for the private connections . The private DIDs are stored in the respective self - sovereign identities SSIs , e.g. , the patient mobile wallet 442 and the agents 426 , 444 , 466 of FIG . 4 , and not in the public identity ledger 310 , making the connections and all traffic on the connections hidden , private , and secure”)
and the first storage space stores an identifier of the identity certificate authority, an identifier of the vaccination management agency, and an identifier of the medical institution ([0043] discloses, “In some embodiments , issuer 302 , patient 304 , and verifier 306 exchange digital credentials through the trusted , private , cryptographically secured connections established under the private DIDs through agents 426 , 444 , 466 ( or wallet 442 when the wallet 442 includes the functions of the patient agent 444 ) . An issuer 302 includes an issuer service 420 that includes a connector service 422 and a credential issuance service 424. The credential issuance service 424 is coupled to the existing information database 430 , e.g. , a member records system 430 , of issuer 302 to create a digital credential using information retrieved from the existing database 430. In some embodiments , the credential issuance service 424 is coupled to the existing information database 430 via the connector service 422 , e.g. , an application programming interface . The issuance service 424 selects a credential template including standardized data structure and format , and populates the credential template with the information retrieved from the existing database 430 to generate the digital credential . The issuer service 420 communicates the digital credential to the respective patient 304 by means of agents 426 , 444 of the respective self - sovereign identities 402 , 404 using the trusted , private , cryptographically secured connections . The credential may also be based on data of other sources , e.g. , manually inputted data through a portal terminal or online portal page.” And see [0052] discloses, “As an illustrative example , the issuer 302 is an example hospital”)
performing a first comparison, the vaccination management server, between an identifier derived from a digital signature of a VC issuer included in the vaccination agency VC and the identifier of the vaccination management agency stored in the first storage space of the public distributed ledger, in response to the vaccination certificate issuance request; ([0071] discloses, “In example operation 655 , the issuer agent 426 digitally signs the vaccination credential with the private key of the public DID of the issuer service 420. In some embodiments , according to an agent policy registry of the self - sovereign identity 402 , the issuer agent 426 stores the private key of the issuer service 420. The issuer agent 426 also causes a public key of the issuer service 420 to be stored in the public identity ledger 310. The public key corresponds to the private key used to sign the vaccination credential and is part of the public DID of the hospital 302 , which other participants of the diagram 300 can access to verify the authenticity of the digital signature attached to the vaccination credential issued by the issuer service 420” and see [0074] discloses, Upon receiving the signed and encrypted vaccination credential , the wallet 442 decrypts it using the private key of the private DID to obtain the signed vaccination credential . In some embodiments , wallet 442 chooses to further verify the digital signature of the signed vaccination credential using the public key of the issuer service 420 as part of the public DID of the issuer service 420 stored in the public identity ledger 310. In some embodiments , the wallet 442 further digitally signs the signed vaccination credential by attaching one or more of a blinded link secret and a blinded proving secret unique to the patient 304 to the signed vaccination credential . The wallet 442 maintains the signed vaccination credential as a piece of portable credential that the patient 304 can present to a verifier 306 in a proof procedure.” / examiner notes the verification is a comparison step of digital signatures utilizing asymmetric cryptography)
performing a second comparison, by the vaccination management server, between an owner identifier of the vaccination agency VC included in the vaccination agency VC and an identifier derived from the digital signature of the medical institution, in response to the vaccination certificate issuance request; ([0083] discloses, “In example operation 750 , the verifier service 460 receives signed vaccination credential from the wallet 442 through the verifier agent 466 in the secured connection . Specifically , the wallet 442 encrypts the signed vaccination credential with the private key of the private DID dedicated for the private connection with the verifier agent 466. The signed vaccination credential includes digital signature of the issuer service 420 and the digital signature of the wallet 442 , e.g. , one or more of the blinded link secret and blinded proving secret unique to the patient 304. Upon receiving the signed and encrypted vaccination credential , the verifier agent 466 decrypts the signed and encrypted vaccination credential using the public key of the private DID of the wallet 442 to obtain the signed vaccination credential . The verifier agent 466 verifies the authenticity of the digital signatures attached to the vaccination credential using public keys of the issuer service 420 and the wallet 442 retrieved from the public identity ledger 310. The verifier agent 466 also determines whether the vaccination credential is listed in a revocation list of the issuer service 420 stored on the public identity ledger 310.” And see [0084]/ examiner notes the performance of the comparison is necessarily repeated to issue the vaccination certificate as required shown in e.g.s disclosed. )
issuing, by the vaccination management server, a vaccination certification VC including the vaccination information, , and a digital signature of the vaccination management agency, based on a result of the first comparison and a result of the second comparison; ([0072] discloses, “In example operation 660 , the issuer agent 426 encrypts the digitally signed vaccination credential with the public key of the private DID of the wallet 442 , and sends the signed and encrypted vaccination credential to the private DID of the wallet 442.” See[0083] and see[0084] / examiner notes the performance of the comparison is necessarily repeated to issue the vaccination certificate as required shown in e.g.s disclosed)
transmitting, by the vaccination management institution server, the vaccination certification VC to the user device; and storing, by the user device, the vaccination certification VC in the user device. ([0035] discloses, “The issuer 302 and verifier 306 are defined only with respect to a specific credential . An issuer 302 with respect to a first credential may be a verifier with respect to a second credential . Similarly , a verifier 306 with respect to a first credential may be an issuer 302 with respect to a second credential.” and [0049] discloses, “Upon receiving the credential from the patient agent 444 of the patient 304 , the verifier agent 466 of the verifier 306 verifies the credential as belonging to the patient 304 and as being issued by issuer 302. In some embodiments , the verification includes the verifier agent 466 obtaining from the public identity ledger 310 the public keys of one or more of the issuer 302 or the patient 304. The verifier agent 466 of the self - sovereign identity 406 of the verifier 306 uses the obtained public keys to read or verify the digital signatures that the issuer agent 426 of the issuer 302 or the patient agent 444 of the patient 304 have attached to the credential . Upon successful verification of the credential , the verifier agent 466 of the verifier 306 communicates with the verifier service 460 , e.g. , including the verification service 464 and the connector service 462 , to route the information contained in the credential into the verifier's local database system , e.g. , the existing records system 472 or the existing EMR system 474.”)
It would be obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine DAY’s teachings of Guardtime KSI blockchain with Anderson’s teachings of DID and asymmetric cryptography to issue a vaccination certification as previously cited, the motivation being that DAY’s teaches in [0006]-[0009] concern for fraudulent and truthful attestation of vaccines and Anderson teaches the importance of non-tampered issuance of information such as vaccine certifications (e.g. [0028]) therefore it would be obvious to combine the compatible Guardtime of DAY with Anderson as it would improve the comprehensive and tamper proof digital solution such as by use of the KSI signed hash in conjunction with the DID and asymmetric cryptography to enhance security and integrity and improved trust.
As per claim 4, DAY teaches:
The method of claim 1, further comprising generating by the vaccination management server, a certificate identifier corresponding to the vaccination certification VC transmitting the certificate identifier to the public distributed ledger so that the certificate identifier is stored in the first storage space. (see Fig. 4 and see [0094] discloses, “FIG . 6 also illustrates two markings . In this case , the markings are well - known QR codes , which are shown by way of example . One of the QR codes , typically one of a higher QR code version to be able to encode more information , encodes a digital signature ( see below ) of the hash value of the patient's identifier ; the other QR code encodes the “ last mile ” information of the certificate , such as that illustrated in FIG . 4” / examiner notes that the VC generated has QR code identifiers that are transmitted to blockchain network for storage)
As per claim 11, DAY does not teach:
The method of claim 1, further comprising: outputting, by the user device, a screen displaying the vaccination certificate issuance request, wherein the screen includes a code corresponding to a verifiable presentation (VP) designed according to a World Wide Web Consortium (W3C) standard protocol; and recognizing, by the medical institution device, the vaccination certificate issuance request displayed on the screen of the user device.
However, Anderson does teach:
The method of claim 1, further comprising: outputting, by the user device, a screen displaying the vaccination certificate issuance request, wherein the screen includes a code corresponding to a verifiable presentation (VP) designed according to a World Wide Web Consortium (W3C) standard protocol; and recognizing, by the medical institution device, the vaccination certificate issuance request displayed on the screen of the user device. (see [0061] discloses, “In example operation 625 , the wallet 442 of the patient 304 sends , and the issuer service 420 receives ( it is also possible that the issuer service 420 sends and the wallet 442 of the patient 304 receives ) , a connection request to issue a credential for the vaccination record of the patient 304. The connection request includes demographic information of the patient 304 and the private DID information of wallet 442 dedicated for a trusted , private , cryptographically secured connection between the self - sovereign identity 402 of the hospital.” And see [0071] discloses, “In example operation 655 , the issuer agent 426 digitally signs the vaccination credential with the private key of the public DID of the issuer service 420. In some embodiments , according to an agent policy registry of the self - sovereign identity 402 , the issuer agent 426 stores the private key of the issuer service 420. The issuer agent 426 also causes a public key of the issuer service 420 to be stored in the public identity ledger 310. The public key corresponds to the private key used to sign the vaccination credential and is part of the public DID of the hospital 302 , which other participants of the diagram 300 can access to verify the authenticity of the digital signature attached to the vaccination credential issued by the issuer service 420” / examiner notes as defined in the instant specification para. [0055] defines the VP as being digital signatures)
It would be obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine DAY’s teachings with Anderson’s teachings for the same reasons given in claim 1.
As per claims 9 and 12 they are system claims which repeat the same limitations of claims 1 and 11 the corresponding method claims, as a collection of elements as opposed to a series of process steps. Since the teachings and motivations to combine of DAY and Anderson disclose the underlying process steps that constitute the methods of claims 1 and 11 it is respectfully submitted that they provide the underlying structural elements that perform the steps as well. As such, the limitations of claims 9 and 12 are rejected for the same reasons given above for claims 1 and 11.
As per claim 13, However DAY does not teach portions:
The method of claim 1, wherein the first storage space stores an identifier of the user, and the method further comprises: receiving, by the medical institution device from the user device, an identity certification VC for the user and a digital signature of the user; transmitting, by the medical institution device to the vaccination management server, the vaccination certificate issuance request including the identity certification VC and the digital signature of the user performing a third comparison, by the vaccination management server, between an identifier derived from a VC issuer digital signature included in the identity certification VC and the identifier of the identity certificate authority stored in the first storage space; performing a fourth comparison, by the vaccination management server, between an owner identifier of the identity certification VC included in the identity certification VC and an identifier derived from the digital signature of the user; and issuing, by the vaccination management server, the vaccination certification VC including at least some data of the identity certification VC and the identifier of the user based on a result of the third comparison and a result of the fourth comparison.
However, Anderson does teach:
The method of claim 1, wherein the first storage space stores an identifier of the user, and the method further comprises: receiving, by the medical institution device from the user device, an identity certification VC for the user and a digital signature of the user; transmitting, by the medical institution device to the vaccination management server, the vaccination certificate issuance request including the identity certification VC and the digital signature of the user performing a third comparison, by the vaccination management server, between an identifier derived from a VC issuer digital signature included in the identity certification VC and the identifier of the identity certificate authority stored in the first storage space; performing a fourth comparison, by the vaccination management server, between an owner identifier of the identity certification VC included in the identity certification VC and an identifier derived from the digital signature of the user; and issuing, by the vaccination management server, the vaccination certification VC including at least some data of the identity certification VC and the identifier of the user based on a result of the third comparison and a result of the fourth comparison. (see [0060] and [0066] and see [0071] discloses, “In example operation 655 , the issuer agent 426 digitally signs the vaccination credential with the private key of the public DID of the issuer service 420. In some embodiments , according to an agent policy registry of the self - sovereign identity 402 , the issuer agent 426 stores the private key of the issuer service 420. The issuer agent 426 also causes a public key of the issuer service 420 to be stored in the public identity ledger 310. The public key corresponds to the private key used to sign the vaccination credential and is part of the public DID of the hospital 302 , which other participants of the diagram 300 can access to verify the authenticity of the digital signature attached to the vaccination credential issued by the issuer service 420” and see [0074] discloses, Upon receiving the signed and encrypted vaccination credential , the wallet 442 decrypts it using the private key of the private DID to obtain the signed vaccination credential . In some embodiments , wallet 442 chooses to further verify the digital signature of the signed vaccination credential using the public key of the issuer service 420 as part of the public DID of the issuer service 420 stored in the public identity ledger 310. In some embodiments , the wallet 442 further digitally signs the signed vaccination credential by attaching one or more of a blinded link secret and a blinded proving secret unique to the patient 304 to the signed vaccination credential . The wallet 442 maintains the signed vaccination credential as a piece of portable credential that the patient 304 can present to a verifier 306 in a proof procedure.” and see [0083] discloses, “In example operation 750 , the verifier service 460 receives signed vaccination credential from the wallet 442 through the verifier agent 466 in the secured connection . Specifically , the wallet 442 encrypts the signed vaccination credential with the private key of the private DID dedicated for the private connection with the verifier agent 466. The signed vaccination credential includes digital signature of the issuer service 420 and the digital signature of the wallet 442 , e.g. , one or more of the blinded link secret and blinded proving secret unique to the patient 304. Upon receiving the signed and encrypted vaccination credential , the verifier agent 466 decrypts the signed and encrypted vaccination credential using the public key of the private DID of the wallet 442 to obtain the signed vaccination credential . The verifier agent 466 verifies the authenticity of the digital signatures attached to the vaccination credential using public keys of the issuer service 420 and the wallet 442 retrieved from the public identity ledger 310. The verifier agent 466 also determines whether the vaccination credential is listed in a revocation list of the issuer service 420 stored on the public identity ledger 310.” And see [0084]/ examiner notes the performance of the comparison is necessarily repeated to issue the vaccination certificate as required shown in e.g.s disclosed also in light of 112(a) written description support is lacking for these third, fourth comparisons and what they entail/ examiner notes the verification is a comparison step of digital signatures utilizing asymmetric cryptography)
It would be obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine DAY’s teachings of Guardtime KSI blockchain with Anderson’s teachings of DID and asymmetric cryptography to issue a vaccination certification as previously cited, the motivation being that DAY’s teaches in [0006]-[0009] concern for fraudulent and truthful attestation of vaccines and Anderson teaches the importance of non-tampered issuance of information such as vaccine certifications (e.g. [0028]) therefore it would be obvious to combine the compatible Guardtime of DAY with Anderson as it would improve the comprehensive and tamper proof digital solution such as by use of the KSI signed hash in conjunction with the DID and asymmetric cryptography to enhance security and integrity and improved trust.
As per claim 14, However DAY does not teach portions:
The method of claim 13, further comprising: creating, by the user device, a VP including at least some information of the vaccination certification VC and the digital signature of the user and transmitting the VP to a third party device; performing a fifth comparison, by the third party device, between an identifier derived from an issuer digital signature of the vaccination certification VC included in the at least some information of the vaccination certification VC and the identifier of the vaccination management agency stored in the first storage space; performing a sixth comparison, by the third party device, between an identifier derived from the digital signature of the user and an owner identifier of the vaccination certification VC; and outputting, by the third party device, a verification result screen through a display of the third party device based on a result of the fifth comparison and a result of the sixth comparison.
However, Anderson does teach:
The method of claim 13, further comprising: creating, by the user device, a VP including at least some information of the vaccination certification VC and the digital signature of the user and transmitting the VP to a third party device; performing a fifth comparison, by the third party device, between an identifier derived from an issuer digital signature of the vaccination certification VC included in the at least some information of the vaccination certification VC and the identifier of the vaccination management agency stored in the first storage space; performing a sixth comparison, by the third party device, between an identifier derived from the digital signature of the user and an owner identifier of the vaccination certification VC; and outputting, by the third party device, a verification result screen through a display of the third party device based on a result of the fifth comparison and a result of the sixth comparison. ( [0026] discloses, “The issuer client digitally signs the credential so that the authenticity of the credential is verifiable by others . For example , the cloud - based agent digitally signs the credential using a private key of the issuer client and causes to store a corresponding public key of the issuer client on a distributed ledger that is accessible by other clients.” And see [0027] discloses, “After the user receives the credential , the credential becomes portable for the user to the extent that the user can digitally present the credential to a client of a verifier . For example , a private , trusted , and cryptographically secured connection can be established between the wallet application of the user and the verifier client , through an agent . The verifier client can verify the authenticity of the credential information based on the digital signature of the issuer client , using the public key of the issuer client . In some embodiments , the signed credential contains a public iden tifier of the issuer client , which functions as storage identi fier to locate the public key of the issuer client in the distributed ledger” [0071] discloses, “In example operation 655 , the issuer agent 426 digitally signs the vaccination credential with the private key of the public DID of the issuer service 420. In some embodiments , according to an agent policy registry of the self - sovereign identity 402 , the issuer agent 426 stores the private key of the issuer service 420. The issuer agent 426 also causes a public key of the issuer service 420 to be stored in the public identity ledger 310. The public key corresponds to the private key used to sign the vaccination credential and is part of the public DID of the hospital 302 , which other participants of the diagram 300 can access to verify the authenticity of the digital signature attached to the vaccination credential issued by the issuer service 420” and see [0074] discloses, Upon receiving the signed and encrypted vaccination credential , the wallet 442 decrypts it using the private key of the private DID to obtain the signed vaccination credential . In some embodiments , wallet 442 chooses to further verify the digital signature of the signed vaccination credential using the public key of the issuer service 420 as part of the public DID of the issuer service 420 stored in the public identity ledger 310. In some embodiments , the wallet 442 further digitally signs the signed vaccination credential by attaching one or more of a blinded link secret and a blinded proving secret unique to the patient 304 to the signed vaccination credential . The wallet 442 maintains the signed vaccination credential as a piece of portable credential that the patient 304 can present to a verifier 306 in a proof procedure.” and see [0083] discloses, “In example operation 750 , the verifier service 460 receives signed vaccination credential from the wallet 442 through the verifier agent 466 in the secured connection . Specifically , the wallet 442 encrypts the signed vaccination credential with the private key of the private DID dedicated for the private connection with the verifier agent 466. The signed vaccination credential includes digital signature of the issuer service 420 and the digital signature of the wallet 442 , e.g. , one or more of the blinded link secret and blinded proving secret unique to the patient 304. Upon receiving the signed and encrypted vaccination credential , the verifier agent 466 decrypts the signed and encrypted vaccination credential using the public key of the private DID of the wallet 442 to obtain the signed vaccination credential . The verifier agent 466 verifies the authenticity of the digital signatures attached to the vaccination credential using public keys of the issuer service 420 and the wallet 442 retrieved from the public identity ledger 310. The verifier agent 466 also determines whether the vaccination credential is listed in a revocation list of the issuer service 420 stored on the public identity ledger 310.” And see [0084]/ examiner notes the performance of the comparison is necessarily repeated to issue the vaccination certificate as required shown in e.g.s disclosed also in light of 112(a) written description support is lacking for these third, fourth comparisons and what they entail/ examiner notes the verification is a comparison step of digital signatures utilizing asymmetric cryptography)
It would be obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine DAY’s teachings of Guardtime KSI blockchain with Anderson’s teachings of DID and asymmetric cryptography to issue a vaccination certification as previously cited, the motivation being that DAY’s teaches in [0006]-[0009] concern for fraudulent and truthful attestation of vaccines and Anderson teaches the importance of non-tampered issuance of information such as vaccine certifications (e.g. [0028]) therefore it would be obvious to combine the compatible Guardtime of DAY with Anderson as it would improve the comprehensive and tamper proof digital solution such as by use of the KSI signed hash in conjunction with the DID and asymmetric cryptography to enhance security and integrity and improved trust.
As per claim 15, However DAY does not teach portions:
The method of claim 14, further comprising: displaying, by the user device, a list of information included in the vaccination certification VC; receiving, by the user device, a selection input for the at least some information from among the displayed list of information; and creating, by the user device, the VP including the selected at least some information.
However, Anderson does teach:
The method of claim 14, further comprising: displaying, by the user device, a list of information included in the vaccination certification VC; receiving, by the user device, a selection input for the at least some information from among the displayed list of information; and creating, by the user device, the VP including the selected at least some information. ([0062] discloses, “In some embodiment , the wallet 442 is configured to identify the issuer service 420 as corresponding to the issuer 302. For example , the wallet 442 is configured to provide or display a list of issuers 302 for the patient 304 to select the hospital 302 for the vaccination credential . The wallet 442 then identifies the issuer service 420 as corresponding to the hospital 302 based on the patient's selection of the hospital 302.” )
It would be obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine DAY’s teachings of Guardtime KSI blockchain with Anderson’s teachings of DID and asymmetric cryptography to issue a vaccination certification as previously cited, the motivation being that DAY’s teaches in [0006]-[0009] concern for fraudulent and truthful attestation of vaccines and Anderson teaches the importance of non-tampered issuance of information such as vaccine certifications (e.g. [0028]) therefore it would be obvious to combine the compatible Guardtime of DAY with Anderson as it would improve the comprehensive and tamper proof digital solution such as by use of the KSI signed hash in conjunction with the DID and asymmetric cryptography to enhance security and integrity and improved trust.
Claim 5 is rejected under 35 U.S.C. 103 as being unpatentable over DAY et. al (hereinafter DAY) (US20220191048A1) in view of Anderson et. al (hereinafter Anderson) (US20210287770A1) and in further view of YANG (US20170353320A1)
As per claim 5, DAY and Anderson do not teach:
The method of claim 4, further comprising transmitting, by the vaccination management server, a request to delete the certificate identifier from the first storage space to the blockchain network, when the vaccination certification VC expires.
However, YANG teaches:
The method of claim 4, further comprising transmitting, by the vaccination management server, a request to delete the certificate identifier from the first storage space to the blockchain network, when the vaccination certification VC expires. ([0073] discloses, “Periodically , or after updating the timestamp information , the SE may perform a cleanup operation on the certificates and / or CRL list store in the SE . For example , after updating the time information on the SE , the SE operating system ( OS ) may identify information that is stale based on being too old compared to the time information value . For example , any certificate with an expiration time before an actual time stored as time information can be discarded and / or the associated server moved to an untrusted list . Any certificates which are vouched - for based on OCSP stapling can be discarded if a difference between the SE time information value and the timestamp included in the OCSP stapling message falls outside of a security window . The window may , for example , correspond to one day , one week , or one month.” And see [0074] discloses, “In this way , trusted and stored public keys and certificates that have expired can be deleted from the memory or key store of the SE . Also , when a CRL list or entries in the CRL are no longer valid , the CRL list can be corrected by recognizing servers which have obtained new certificates from , for example , a CI . In addition , an untrusted list can be updated with servers whose certificates have expired or who fail the OCSP or OCSP stapling protocol . Servers which are associated with certificates having time information or OCSP information or OCSP stapling information which falls inside of a security window when compared with the SE time information may be listed on a trusted list of servers.”)
It would be obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine DAY’s teachings of Guardtime KSI blockchain and Anderson’s teachings of DID with YANG’s teachings of deleting a certification in the memory when a digital certificate expires, the motivation being that DAY’s teaches broadly in [0108] that deleting or altering any block in such a blockchain renders the chained linking data invalid and Anderson teaches important of integrity and trustworthiness (see e.g. [0028]) therefore it would be predictable to actually mark invalid or delete the data in the first storage space by new data being added to the blockchain indicating the certificate is expired, effectively marking it as invalid while still maintaining the original record of its existence on the chain as this would be immutable information and ensure the chain is not weakened to maintain security and trustworthiness.
Response to Arguments Regarding 35 U.S.C § 101 Rejection
The applicant argues on pages 2-6 of the submitted remarks that claims are rejected under 35 U.S.C. § 101 as being directed to an abstract idea without significantly more. Applicant argues The Claims Are Not Directed to an Abstract Idea Applicant respectfully disagrees with the Examiner's characterization of independent claims 1 and 9 as being directed to "certain methods of organizing human activity" under MPEP §2106.04(a)(2). As amended, independent claim 1 does not recite rules for managing human behavior, administrative procedures, or interpersonal interactions. Instead, the claim recites machine- enforced cryptographic authorization processes executed by a vaccination management server, a medical institution device, a user device, and a public distributed ledger. In particular, amended independent claim 1 expressly requires: deriving identifiers from digital signatures; performing cryptographic comparisons between derived identifiers and identifiers stored in a public distributed ledger having restricted write permissions; and issuing a vaccination certification verifiable credential (VC) only when multiple cryptographic verification steps are successfully completed. These operations cannot be practically performed by the human mind and do not constitute mental processes or organizational rules. Rather, they are inherently tied to the functioning of distributed computer systems and cryptographic infrastructure. Accordingly, independent claims 1 and 9 are not directed to an abstract idea under Eligibility Step 2A, Prong 1.
II. Eligibility Step 2A - Prong 2 Even If an Abstract Idea Were Assumed, the Claims Are Integrated into a Practical Application Even assuming, arguendo, that independent claims 1 and 9 were considered to recite an abstract idea, the claims are nevertheless patent-eligible because they integrate any such abstract idea into a practical application.
The Claims Address a Specific Technical Problem in Decentralized Systems The amended claims address a technical problem unique to decentralized environments, namely: how to securely issue vaccination certificates without relying on a centralized authority that possesses all institutional and user identity information, while ensuring that only authorized medical institutions may issue valid certificates.
This problem does not arise in conventional centralized database systems and is not related to organizing human activity. Rather, it is a distributed system trust and authorization problem. B. The Claims Recite Specific Claim Steps That Technically Enforce Authorization
As recited in amended independent claim 1, the vaccination management server does not merely receive information and issue a certificate. Instead, the claim explicitly requires multiple cryptographic verification steps that technically constrain when certificate issuance is permitted. Specifically, amended independent claim 1 requires: a public distributed ledger having a first storage space modifiable only by a trusted institution server, which stores identifiers of an identity certificate authority, a vaccination management agency, and a medical institution; a vaccination certificate issuance request including a vaccination agency VC for the medical institution and a digital signature of the medical institution; a first cryptographic comparison between an identifier derived from a digital signature of a VC issuer and an identifier of the vaccination management agency stored in the first storage space; a second cryptographic comparison between an owner identifier of the vaccination agency VC and an identifier derived from the digital signature of the medical institution; and issuance of a vaccination certification VC only when both comparisons succeed.
These claim steps technically constrain the issuance process, prevent unauthorized entities from issuing vaccination certificates, and cryptographically enforce authorization at the system level. The vaccination management server is therefore not merely applying a rule but is enforcing trust relationships using ledger-anchored decentralized identifiers. Accordingly, the claims integrate any alleged abstract idea into a practical application that improves the functioning of decentralized credential issuance systems, consistent with MPEP §2106.04(d)(2).
User-Controlled Storage Provides an Additional Technical Improvement Amended independent claim 1 further requires: transmitting, by the vaccination management institution server, the vaccination certification VC to the user device; and storing, by the user device, the received vaccination certification VC in the user device.
This design technically minimizes exposure of sensitive vaccination information by ensuring that the vaccination certification VC is not broadly distributed or centrally stored. Such privacy preservation is achieved through specific device-level storage and transmission constraints, rather than through a mere statement of intent or desired outcome. D. The Examiner's "Apply-It" Analysis Is Unpersuasive The Examiner asserts that the trusted institution server, medical institution device, user device, blockchain network, public distributed ledger, storage spaces, and digital signatures merely apply an abstract idea or generally link it to blockchain technology. However, when considered as an ordered combination, these elements: establish a public distributed ledger with restricted write permissions; require multi-stage cryptographic comparisons prior to certificate issuance; and prevent unauthorized credential issuance by system design. These features impose meaningful technical limitations on system operation and therefore integrate any alleged abstract idea into a practical application.
III. Eligibility Step 2B The Claims Recite an Inventive Concept (In the Alternative) Even if the Examiner were to maintain that independent claims 1 and 9 are directed to an abstract idea and are not integrated into a practical application, the claims nevertheless satisfy Eligibility Step 2B. The claimed combination of: a public distributed ledger including storage spaces with restricted write permissions; derivation of identifiers from digital signatures and cryptographic comparison thereof; and multi-stage authorization verification prior to issuance of a vaccination certification VC, represents a non-conventional arrangement of elements that is not shown to be well- understood, routine, or conventional at the time of the invention. The Office Action provides no factual evidence establishing that such a decentralized identity-based vaccination certificate issuance architecture was conventional. Accordingly, independent claims 1 and 9 recite significantly more than any alleged abstract idea. IV. Independent Claim 9 and Dependent Claims Independent claim 9 is a system claim that recites substantially the same technical features and operational constraints as independent claim 1, and therefore is patent-eligible for the same reasons. Dependent claims 2, 4, 5 and 11-14 further limit the independent claims and necessarily recite patent-eligible subject matter at least to the extent of the allowable independent claims. Accordingly, no separate § 101 analysis is required for the dependent claims. In view of the remarks presented hereinabove, reconsideration and withdrawal of the rejection under 35 U.S.C. § 101 are respectfully requested.
The MPEP § 2106.04(a) The sub-grouping “managing personal behavior or relationships or interactions between people" include social activities, teaching, and following rules or instructions. An example of a claim reciting managing personal behavior is Intellectual Ventures I LLC v. Capital One Bank (USA), 792 F.3d 1363, 115 USPQ2d 1636 (Fed. Cir. 2015). The patentee in this case claimed methods comprising storing user-selected pre-set limits on spending in a database, and when one of the limits is reached, communicating a notification to the user via a device. 792 F.3d. at 1367, 115 USPQ2d at 1639-40. The Federal Circuit determined that the claims were directed to the abstract idea of "tracking financial transactions to determine whether they exceed a pre-set spending limit (i.e., budgeting)", which "is not meaningfully different from the ideas found to be abstract in other cases before the Supreme Court and our court involving methods of organizing human activity." 792 F.3d. at 1367-68, 115 USPQ2d at 1640 MPEP 2106.04(a)(2) (II) states, “Finally, the sub-groupings encompass both activity of a single person (for example, a person following a set of instructions or a person signing a contract online) and activity that involves multiple people (such as a commercial interaction), and thus, certain activity between a person and a computer (for example a method of anonymous loan shopping that a person conducts using a mobile phone) may fall within the “certain methods of organizing human activity” grouping. It is noted that the number of people involved in the activity is not dispositive as to whether a claim limitation falls within this grouping.”
Examiner appreciates applicant’s arguments but does not find them persuasive. The instant application claims are “certain methods of organizing human activity” as it is managing personal behavior and following rules or instructions to transmit, issue, and store a vaccination certification MPEP § 2106.04(a)(2)). Examiner is tasked with considering the claim as a whole and determining what is abstract idea in the claim and what are additional elements. Examiner performed this analysis and did not overly simplify the claims as the claims clearly recite the management of vaccination records through communication of vaccination certification and this abstract idea is a form of human activity completed prior to the use of generic computers by humans following rules and instructions using pen and paper thus is directed to an abstract idea. The claims reciting computer elements such as blockchain or digital signatures or computers does not make the claim dispositive of being directed to an abstract idea.
In response to applicant’s argument that these claim steps technically constrain the issuance process, prevent unauthorized entities from issuing vaccination certificates, and cryptographically enforce authorization at the system level and that the vaccination management server is therefore not merely applying a rule but is enforcing trust relationships using ledger-anchored decentralized identifiers. Accordingly, the claims integrate any alleged abstract idea into a practical application that improves the functioning of decentralized credential issuance systems. Examiner notes to qualify as “a patent-eligible improvement,” the additional elements in can bring forth the practical application but the abstract idea cannot and the improvement must be directed to a specific improvement in the computer’s functionality, not simply to use of the computer “as a tool” to implement an abstract idea or other technological improvement confined to the computer environment in which the claim recites. The instant application claim language and the specification make clear, the invention is directed to the abstract idea of vaccination records through communication of vaccination certification. The instant application is confined to using the environment and elements of a general-purpose processor to carry out the abstract idea and while this does not doom the claims, the claims as recited do not reflect an improvement to the computers functionality but rather improve the abstract idea using mere application of the general computer elements (e.g. storage of information in blockchain) thus cannot bring about integration into a practical application. Furthermore, the functioning of decentralized credential issuance systems is not improved but rather the recited claims generally link to blockchain distributed ledgers as it is recited in the claim as storage with no further execution of technical implantation of this technology but rather additional data movement steps which follow rules and instructions to improve the abstract idea of transmitting and issuing vaccination certification.
Thus for the same reasons aforementioned the claims do not provide additional features which provide significantly more.
Examiner maintains the 35 U.S.C 101 rejection.
Response to Arguments Regarding 35 U.S.C § 102/103 Rejections
Applicant argues on pages 6-9 of the remarks applicant argues that that the cited combination of DAY, Anderson, and YANG fails to disclose, suggest, or otherwise render obvious the claimed combinations of features presently set forth in amended independent claims 1 and 9.
As noted above, the claimed subject matter provides a method for issuing and distributing trusted digital vaccination certificates by using blockchain-based decentralized identifiers (DIDs), verifiable credentials (VCs), and verifiable presentations (VPs) to authenticate the identities of vaccination-related entities.
In amended claim 1, whether a medical institution is authorized to perform vaccination is explicitly verified. Specifically, the issuer of the vaccination agency VC is first verified, i.e., whether the vaccination agency VC was issued by a trusted DID ("performing a first comparison, by the vaccination management server, between an identifier derived from a digital signature of a VC issuer included in the vaccination agency VC and the identifier of the vaccination management agency stored in the first storage space of the public distributed ledger, in response to the vaccination certificate issuance request").
Next, the owner of the vaccination agency VC is verified, i.e., whether the owner directly performed the digital signature ("performing a second comparison, by the vaccination management server, between an owner identifier of the vaccination agency VC included in the vaccination agency VC and an identifier derived from the digital signature of the medical institution, in response to the vaccination certificate issuance request").
Only after confirming, based on results of the first comparison and the second comparison, that the medical institution has authorization to perform vaccination, does the vaccination management server issue the vaccination certification VC.
In addition, the vaccination certification VC is stored only in the user device of its owner ("transmitting, by the vaccination management institution server, the vaccination certification VC to the user device; and storing, by the user device, the received vaccination certification VC in the user device").
The user device can generate a verifiable presentation (VP) by combining only selected portions of private information included in the vaccination certification VC, thereby enabling verification of vaccination status without disclosure of identity information to any third party.
DAY merely shares the use of blockchain for storing and distributing vaccination information but solves the problem in a fundamentally different manner from the present invention. DAY verifies the validity of information itself by obtaining a KSI signature for information generated by a certificate issuer and verifying the KSI signature. DAY merely verifies the integrity of information through a KSI signature, whereas the present invention verifies authorization of entities through decentralized identity ownership and cryptographic control. These are fundamentally different technical objectives.
Moreover, in DAY, vaccination certificate information for a patient is fully exposed and transmitted to all participating entities. Furthermore, DAY does not disclose or suggest storing a vaccination certificate exclusively in a user-controlled device, nor selectively disclosing only a subset of credential information via a verifiable presentation. Such privacy-preserving credential control is entirely absent from DAY.
Accordingly, DAY fails to teach or suggest the subject matter of amended claim 1.
The other cited references, Anderson and YANG are also silent with respect to the aforementioned features of amended claim 1, and thus, fail to remedy the deficiencies of DAY.
Thus, Applicant submits that amended independent claim 1 distinguishes over the cited references, and further, amended independent claim 1 is allowable.
Amended independent claim 9 recites the features similar to the above features of amended independent claim 1.
Accordingly, Applicant submits that the rejections under 35 U.S.C. § 103 of independent claims 1 and 9, and dependent claims 4, 5, 11 and 12, which are depending from one of independent claims 1 and 9, are overcome. The cancelation of claims 2, 3, 6-8 and 10 renders the rejection of those claims moot. As such, Applicant respectfully submits that reconsideration and withdrawal of the rejections under 35 U.S.C. § 103 are in order and respectfully requested.
New Claims: New claims 13-15 are added to recite features Applicant is entitled to claim. The new claims are allowable at least by virtue of their dependency from allowable amended claim 1, as well as for the additional features they recite.
Examiner appreciates applicant’s arguments but does not find them persuasive. In response to applicant's argument that DAY does not teach a fundamentally similar technical objective, the test for obviousness is not whether the features of a secondary reference may be bodily incorporated into the structure of the primary reference; nor is it that the claimed invention must be expressly suggested in any one or all of the references. Rather, the test is what the combined teachings of the references would have suggested to those of ordinary skill in the art. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981).
In response to applicant's argument that DAY does not teach a fundamentally similar technical objective, the fact that the inventor has recognized another advantage which would flow naturally from following the suggestion of the prior art cannot be the basis for patentability when the differences would otherwise be obvious. See Ex parte Obiaya, 227 USPQ 58, 60 (Bd. Pat. App. & Inter. 1985).
In response to applicant's argument that DAY does not teach a fundamentally similar technical objective is nonanalogous art, it has been held that a prior art reference must either be in the field of the inventor’s endeavor or, if not, then be reasonably pertinent to the particular problem with which the inventor was concerned, in order to be relied upon as a basis for rejection of the claimed invention. See In re Oetiker, 977 F.2d 1443, 24 USPQ2d 1443 (Fed. Cir. 1992). In this case, DAY (see para. [0006]) and see [0019]-[0022]) Anderson teach the equally important need to establish a system that will allow reliable verification credentials such as being immunized therefore they each have teaching and motivation to be combined in the same field of classification G16H to be combined as art.
Applicant’s arguments with respect to the independent claims 1 and 9 and by virtue the dependent claims have been considered but are moot because the ground of rejection does not rely on DAY reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Prior Art not cited but made of record
US12047517B2– Choi
A method for sequential authentication based on chain of authentication using public key infrastructure (PKI) is provided. The method includes abutting a first wearable device belonging to a first party with a second wearable device belonging to a second party; transmitting, by the first wearable device, authentication information of the first party; verifying the authentication information of the first party; transmitting, by the second wearable device, authentication information of the second party; verifying the authentication information of the second party; authorizing electronic transaction in response to successfully verifying both the authentication information of the first party and the authentication information of the second party. Each of the authentication information of the first party and the authentication information of the second party includes information configured for authentication based on a public key infrastructure (PKI) certificate.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Ashley Elizabeth Evans whose telephone number is (571) 270-0110. The examiner can normally be reached Monday – Friday 8:00 AM – 5:00 PM.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Mamon Obeid can be reached on (571) 270-1813. The fax phone number for the organization where this application or proceeding is assigned 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center. Should you have questions on access to the Patent Center, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
/ASHLEY ELIZABETH EVANS/Examiner, Art Unit 3687
/MAMON OBEID/Supervisory Patent Examiner, Art Unit 3687