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 .
Response to Amendment
The amendment filed on 2/23/2026 has been accepted and considered in this office action. Claims 1 and 10 have been amended. No claims have been canceled. No new claims have been newly added.
Response to Arguments
Applicant's arguments filed 2/23/2026 have been fully considered but they are not persuasive.
Applicant argues that the cited references (Quick/Sang/Choi/Pagni) are silent on “wherein the user terminal is further configured to display a dashboard showing enrollment information about at least one lecture that the corresponding user is taking, a completion status for each lecture, and open badges issued for each lecture that the corresponding user has completed, wherein the open badges are placed and classified for each category”
However, Quick, Section IV (A) Fig. 2-3 discloses that the user interface/dashboard displaying the learner is enrolled in multiple courses, learner’s progress in the course and completion status of course; Section IV (A) Quick discloses that each time a learner completes a course, he/she earns a Smart Blockchain Badge; Quick, Section IV (A) Fig. 2-3 further discloses that badges are classified under various skills required categories.
Applicant argues that the cited references (Quick/Sang/Choi/Pagni) are silent on “wherein the service server is further configured to, when an open badge issuance request for the corresponding user is received from the user terminal, after the service server performs user authentication, provide an issuable open badge list including at least one issuable open badge for the corresponding user, and when one of the open badges is selected from the issuable open badge list, issue the selected open badge by identifying and combining history data and format based on the DID electronic wallet of the corresponding user registered in the blockchain.”
However, Choi, Section 3.3, para 3, Fig 17, discloses that the REST API server perform operations conforming to the Open Badge standard; Section1, Introduction, para 2, Choi discloses Open Badge issuing platform (Badgr) verifies learning completion criteria and issues open badges, it therefore follows that the REST API teaches a request to the platform for issuance of an Open Badge based on completion of learning (Section 5, Conclusion); Introduction, para 2, Choi discloses Open Badge issuing platform (Badgr)verifies learning completion criteria and issues open badges; (Section 5, Conclusion, Choi discloses that the criteria (Section 2.1, para 4, e.g., completing a part of a course or an entire course) to earn a badge is verified through the network before awarding the badge. Choi, Fig. 13-17 discloses REST APIs for listing badges, badges from certain issuers, awarding badges; page 15, para 1, Choi discloses that when the badge issue button is pressed, then issued badge is displayed; Section 3.2, para 2, Choi discloses that the badge is a combination of an image and metadata which includes skills, issues, credits, microcredits gained by student; page 8, para 3, Choi discloses that the badges are managed via backpack repository and are recorded in blockchain. Sang, para 57 discloses that the digital badge DID ledger registration module (205) can be configured to register a digital badge DID issued by the digital badge DID issuance module (204) into the blockchain ledger.
Therefore, the applicant’s argument is ultimately not persuasive.
Specification
Applicant is reminded of the proper language and format for an abstract of the disclosure.
The abstract should be in narrative form and generally limited to a single paragraph on a separate sheet within the range of 50 to 150 words in length. The abstract should describe the disclosure sufficiently to assist readers in deciding whether there is a need for consulting the full patent text for details.
The language should be clear and concise and should not repeat information given in the title. It should avoid using phrases which can be implied, such as, “The disclosure concerns,” “The disclosure defined by this invention,” “The disclosure describes,” etc. In addition, the form and legal phraseology often used in patent claims, such as “means” and “said,” should be avoided.
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 and 10 are rejected under 35 U.S.C. 103 as being unpatentable over Quick (A. Mikroyannidis, J. Domingue, M. Bachler and K. Quick, "Smart Blockchain Badges for Data Science Education," 2018 IEEE Frontiers in Education Conference (FIE)) in view of Choi (Choi, M., Kiran, S. R., Oh, S.-C., & Kwon, O.-Y. (2019). Blockchain-Based Badge Award with Existence Proof. Applied Sciences) in view of Sang (KR 20240145588 A) further in view of Pagni (Pagni, F. (2022). Digital certifications and open badges. https://www.dyndevice.com/en/news/digital-certifications-and-open-badges-ELN-1726/).
Regarding Claim 1, Quick teaches:
a first institutional terminal configured to provide a learning service to a user terminal, and to create or update history information about a corresponding user by receiving learning performance result information from the user terminal (Quick, Section IV (A) discloses learning providers like Massive open online courses (MOOCs), Open Educational Resources (OERs) and online paid courses provides learning service to the learner. Each time the learner completes a course, the learner earns a Smart Blockchain Badge. These badges are stored on the Blockchain and include data about the skills that the specific learner has acquired which implies receiving learning result and updating learner history.);
the user terminal configured to perform learning through a learning service provided by the first institutional terminal, to store an open badge issued, and to request qualification recognition by submitting the stored open badge to a second institutional terminal (Quick, Section IV (A) discloses the learner learns from learning providers like Massive open online courses (MOOCs), Open Educational Resources (OERs) and online paid courses and obtains and store the Smart Blockchain Badge on the blockchain; Section IV (C) Quick discloses Smart Blockchain Badges can be used to link accreditations to jobs (employers) through the matching/recognition of badges to job profiles.);
wherein the user terminal is further configured to display a dashboard showing enrollment information about at least one lecture that the corresponding user is taking, a completion status for each lecture and open badges issued for each lecture that the corresponding user has completed, wherein the open badges are placed and classified for each category (Quick, Section IV (A) Fig. 2-3 discloses that the user interface/dashboard displaying the learner is enrolled in multiple courses, learner’s progress in the course and completion status of course; Section IV (A) Quick discloses that each time a learner completes a course, he/she earns a Smart Blockchain Badge; Quick, Section IV (A) Fig. 2-3 further discloses that badges are classified under various skills required categories);
Quick does not explicitly teach; However, Choi teaches,
making a request for open badge issuance for the learning to a service server (Choi, Section 3.3, para 3, Fig 17, discloses that the REST API server perform operations conforming to the Open Badge standard; Section1, Introduction, para 2, Choi discloses Open Badge issuing platform (Badgr) verifies learning completion criteria and issues open badges, It is inherent that the REST API constitute a request to the platform for issuance of an Open Badge based on completion of learning (Section 5, Conclusion));
the service server configured to determine whether the corresponding user has an issuance qualification for the open badge requested to be issued, when the open badge issuance is requested from the user terminal, to determine whether to issue the open badge (Introduction, para 2, Choi discloses Open Badge issuing platform (Badgr)verifies learning completion criteria and issues open badges; (Section 5, Conclusion, Choi discloses that the criteria (Section 2.1, para 4, e.g., completing a part of a course or an entire course) to earn a badge is verified through the network before awarding the badge.));
wherein the service server recommends other learning, which is related to the open badge previously issued to the user, to the user terminal such that the user is capable of receiving an additional open badge (Choi, Section 5, para 3, discloses the system reviews the collected history of the badges to student and analyzes the collected information, develops future plans for student as a career guidance; Choi, Section 2.1, para 4, discloses that personalized course recommendations are provided to learners once they earn a badge after completion of a part of a course or an entire course.);
wherein the open badge includes necessary metadata and optional metadata (Choi, Section 3.2, para 2, discloses the digital badge is a combination of an image and the metadata associate with it);
wherein the necessary metadata includes verification uniform resource locator (URL) information (Choi, Section 3.2, para 2, Fig 7, discloses metadata including verify data to help a third party verify this assertion; Section 3.1, para 3 discloses the use of URL-based badge assertion);
wherein the optional metadata includes evidence URL information (Choi, Section 3.2, para 2, discloses metadata including evidence that comprise URL of the work that the recipient did to earn the achievement.);
and wherein the service server is further configured to, when an open badge issuance request for the corresponding user is received from the user terminal, after the service server performs user authentication, provide an issuable open badge list including at least one issuable open badge for the corresponding user (Choi, Section 3.3, para 3, Fig 17, discloses that the REST API server perform operations conforming to the Open Badge standard; Section1, Introduction, para 2, Choi discloses Open Badge issuing platform (Badgr) verifies learning completion criteria and issues open badges, It is inherent that the REST API constitute a request to the platform for issuance of an Open Badge based on completion of learning (Section 5, Conclusion); Introduction, para 2, Choi discloses Open Badge issuing platform (Badgr)verifies learning completion criteria and issues open badges; (Section 5, Conclusion, Choi discloses that the criteria (Section 2.1, para 4, e.g., completing a part of a course or an entire course) to earn a badge is verified through the network before awarding the badge.);
and when one of the open badges is selected from the issuable open badge list, issue the selected open badge by identifying and combining history data and format based on the secure storage of the corresponding user registered in the blockchain (Choi, Fig. 13-17 discloses REST APIs for listing badges, badges from certain issuers, awarding badges; page 15, para 1, Choi discloses that when the badge issue button is pressed, then issued badge is displayed; Section 3.2, para 2, Choi discloses that the badge is a combination of an image and metadata which includes skills, issues, credits, microcredits gained by student; page 8, para 3, Choi discloses that the badges are managed via backpack repository and are recorded in blockchain.)
It would have been obvious to one of the ordinary skills in the art before the effective filing date to modify Quick’s system to incorporate Choi’s open badge issuance and verification architecture because both references address the same problem of securely issuing, verifying and utilizing learning achievement credentials using blockchain technology. One would be motivated to perform such modification to Quick’s system in order to integrate Choi’s standard-compliant Open Badge issuance workflow, REST-API based server thereby enhancing verification efficiency and practical deployment of Smart blockchain badges.
Choi does not explicitly teach; However, Sang teaches,
and to record and manage the issued open badge in a decentralized identifiers (DID) electronic wallet of the corresponding user registered in a blockchain (Sang, para 57 discloses that the digital badge DID ledger registration module (205) can be configured to register a digital badge DID issued by the digital badge DID issuance module (204) into the blockchain ledger.);
and the second institutional terminal configured to determine whether the corresponding user is qualified for the learning, by requesting the service server to verify a submitted open badge when the stored open badge is submitted from the user terminal (Sang, para 68, discloses that the AI human resource recruitment server (300) can be configured to verify a digital badge DID submitted online from a user terminal (100) through a blockchain ledger, and if there is no abnormality in the verification result, perform IT human resource recruitment for an IT company or IT project using an AI algorithm);
Wherein the secure storage is the DID electronic wallet (Sang, para 57 discloses that the digital badge DID ledger registration module (205) can be configured to register a digital badge DID issued by the digital badge DID issuance module (204) into the blockchain ledger.);
It would have been obvious to one of the ordinary skills in the art before the effective filing date to modify Quick’s system to incorporate Sang’s DID-based digital badge registration and verification framework because both references address the same recognized problem of securely managing, storing, and verifying learning achievement credentials using blockchain technology. One would be motivated to perform such modification to Quick’s system in order to integrate Sang’s registration of issued digital badges as DIDs in blockchain ledger thereby enhancing credential integrity, user centric badge custody through DID electronic wallet and reliable qualification verification by third-party institutions.
Sang does not explicitly teach; However, Pagni teaches,
information about a possibility of integration with another badge (Pagni, page 5, para 28 discloses that open badges are stackable which means that a badge issued by one institution can form the basis for a subsequent badge issued by another);
other service purpose information (Pagni, page 6, para 29 discloses that open Badges can be used to signal membership in groups, such as clubs, circles or organizations, or to certify qualification for certain professions.);
information about prerequisite learning requirements for course registration (Pagni, page 5, para 28 discloses that using an appropriate network of sequential open badges to define preparatory courses that enables students to fill those gaps to be filled before taking more challenging courses.);
information about connectivity with another course (Pagni, page 6, para 30 discloses that open badges issued will also need to indicate the progression of student from one course to other. If three courses are required in order of complexity, the badges must indicate this progression.);
and information about a characteristic of a qualification created by integration with another course (Pagni, page 5, para 28 discloses that open badges are stackable which means that a badge issued by one institution can form the basis for a subsequent badge issued by another; page 5, para 25, Pagni discloses open badges with greater number of description fields allows for detailed representation of the educational background of badge holders.)
It would have been obvious to one of the ordinary skills in the art before the effective filing date to modify Quick’s system to incorporate Pagni’s open-badge metadata and badge stacking framework because both references address the same recognized problem representing learning progressions, prerequisites and portable digital credential system. One would be motivated to perform such modification to Quick’s system in order to integrate Pagni’s teaching that open badges are stackable, can indicate prerequisite learning requirements, course connectivity and progression thereby enhancing the interoperability and educational usefulness of smart blockchain badges for guiding learners through sequential learning paths.
Regarding Claim 2, Quick/Choi/Sang/Pagni teaches the system of claim 1,
Choi teaches:
wherein the open badge is issued by identifying at least one of the corresponding user’s
learning chunks, proficiency, competency, and talent for the learning (Choi, Section 5, para 3 discloses open badge is issued when the student completes each microlearning units (Short learning content of education and training courses));
and is posted on at least one social network service (SNS) selected by the user terminal (Choi, Section 3.2, para 6 discloses that these digital badges can be shared via e-mail, cell phone, etc. In addition, these digital media can be promoted to a third party through a social networking service (SNS).).
It would have been obvious to one of the ordinary skills in the art before the effective filing date to modify Quick/Sang/Pagni’s system to incorporate Choi’s learning unit-based badge issuance and social networking features because all references address the same problem of representing learner’s achievement and enabling their visibility and recognition beyond the issuing institution. One would be motivated to perform such modification to Quick/Sang/Pagni’s system in order to integrate Choi’s teaching that open badges are issued based on identification of a learner’s completed learning units, competencies or proficiencies and shared by the user via social network services, thereby enhancing achievement representation, third-party recognition of blockchain-backed credentials.
Regarding Claim 3, Quick/Choi/Sang/Pagni teaches the system of claim 1,
Choi teaches:
wherein the service server is linked to the first institutional terminal based on an application programming interface (API) to perform at least one of DID user registration, open badge issuance, and DID verification for the corresponding user (Choi, Section 1, para 2 discloses a technique for certification creating/issuing/awarding system using REST API; Section 4, para 1-2, discloses the use of REST API for linking the issuance system to external terminals; Fig 11-18, Choi, shows the REST API s for badge creation, issuance and awarding to user.)
It would have been obvious to one of the ordinary skills in the art before the effective filing date to modify Quick/Sang/Pagni’s system to incorporate Choi’s API-based linkage between external terminals and server because all references address the same problem of coordinating badge issuance, user identity handling, and verification across distributed educational and verification entities. One would be motivated to perform such modification to Quick/Sang/Pagni’s system to enhancing modular integration with external platforms, efficient execution of DID-related registration and verification workflows.
Regarding Claim 4, Quick/Choi/Sang/Pagni teaches the system of claim 3,
Choi teaches:
wherein when a verification request for the issued open badge is received from the
second institutional terminal (Choi, Fig. 9 discloses verification request initiated by the third-party agency, Certification verifier contains the logic for certification check and hash mapping.)
the service server performs verification on the issued open badge based on the electronic wallet of the corresponding user registered in the blockchain (Choi, Fig. 9 discloses certificate verifier performs the verification for the digital badge; Fig 9, Fig. 4, shows the Badge wallet where badges are pushed; Section 3.2, para 1 discloses about digital badge platform operating in conjunction with blockchain.);
It would have been obvious to one of the ordinary skills in the art before the effective filing date to modify Quick/Sang/Pagni’s system to incorporate Choi’s third party-initiated badge verification mechanism based on blockchain registered badge wallet because all references address the same problem of allowing external institutions to reliably verify user held digital credentials without direct reliance on the issuing institution. One would be motivated to perform such modification to Quick/Sang/Pagni’s system to enhance trust, decentralization, and efficient third-party verification of DID-managed open badges.
Choi does not explicitly teach; However, Sang teaches,
Wherein the verification comprises DID verification; Wherein the electronic wallet comprises DID electronic wallet (Sang, para 68 discloses recruitment server configured for DID verification; para 14, Sang discloses storing digital badge DID in their digital badge DID wallet.);
It would have been obvious to one of the ordinary skills in the art before the effective filing date to modify Quick/Choi/Pagni’s system to incorporate Sang’s DID-based verification using a DID electronic wallet because all references address the same problem of securely verifying user-held digital badges. One would be motivated to perform such modification to Quick/Choi/Pagni’s system to strengthen identity binding, temper resistance, and trustworthiness of third-party badge verification.
Regarding Claim 10, Quick teaches:
when a corresponding user completely performs learning based on a learning service provided by a first institutional terminal, transmitting, by a user terminal, learning performance result information about the learning to the first institutional terminal (Quick, Section IV (A) discloses learning providers like Massive open online courses (MOOCs), Open Educational Resources (OERs) and online paid courses provides learning service to the learner. Each time the learner completes a course, the learner earns a Smart Blockchain Badge. These badges are stored on the Blockchain and include data about the skills that the specific learner has acquired which implies receiving learning result and updating learner history.);
creating or updating, by the first institutional terminal, history information about the corresponding user based on the learning performance result information (Quick, Section IV (A) discloses the learner learns from learning providers like Massive open online courses (MOOCs), Open Educational Resources (OERs) and online paid courses and obtains and store the Smart Blockchain Badge on the blockchain; Section IV (C) Quick discloses Smart Blockchain Badges can be used to link accreditations to jobs (employers) through the matching/recognition of badges to job profiles.);
displaying, by the user terminal, a dashboard showing enrollment information about at least one lecture that the corresponding user is taking, a completion status for each lecture, and open badges issued for each lecture that the corresponding user has completed, wherein the open badges are placed and classified for each category (Quick, Section IV (A) Fig. 2-3 discloses that the user interface/dashboard displaying the learner is enrolled in multiple courses, learner’s progress in the course and completion status of course; Section IV (A) Quick discloses that each time a learner completes a course, he/she earns a Smart Blockchain Badge; Quick, Section IV (A) Fig. 2-3 further discloses that badges are classified under various skills required categories);
Quick does not explicitly teach; However, Choi teaches,
when an open badge issuance request for the learning is received from the user terminal, determining, by a service server, whether the corresponding user has an issuance qualification for an open badge requested to be issued, through the first institutional terminal (Choi, Section 3.3, para 3, Fig 17, discloses that the REST API server perform operations conforming to the Open Badge standard; Section1, Introduction, para 2, Choi discloses Open Badge issuing platform (Badgr) verifies learning completion criteria and issues open badges, It is inherent that the REST API constitute a request to the platform for issuance of an Open Badge based on completion of learning (Section 5, Conclusion));
when the determination result indicates that the corresponding user has the issuance qualification for the open badge requested to be issued, issuing, by the service server, an open badge for the learning based on badge issuance data for the corresponding user (Introduction, para 2, Choi discloses Open Badge issuing platform (Badgr) verifies learning completion criteria and issues open badges; (Section 5, Conclusion, Choi discloses that the criteria (Section 2.1, para 4, e.g., completing a part of a course or an entire course) to earn a badge is verified through the network before awarding the badge.));
wherein the issuing of the open badge includes: recommending, by the service server, other learning, which is related to an open badge previously issued to the user, to the user terminal such that the user is capable of receiving an additional open badge (Choi, Section 5, para 3, discloses the system reviews the collected history of the badges to student and analyzes the collected information, develops future plans for student as a career guidance; Choi, Section 2.1, para 4, discloses that personalized course recommendations are provided to learners once they earn a badge after completion of a part of a course or an entire course.);
wherein the open badge includes necessary metadata and optional metadata (Choi, Section 3.2, para 2, discloses the digital badge is a combination of an image and the metadata associate with it);
wherein the necessary metadata includes verification URL information (Choi, Section 3.2, para 2, Fig 7, discloses metadata including verify data to help a third party verify this assertion; Section 3.1, para 3 discloses the use of URL-based badge assertion);
wherein the optional metadata includes evidence URL information (Choi, Section 3.2, para 2, discloses metadata including evidence that comprise URL of the work that the recipient did to earn the achievement.);
and when an open badge issuance request for the corresponding user is received by the service server from the user terminal, after performing user authentication by the service server, providing, by the service server, an issuable open badge list including at least one issuable open badge for the corresponding user (Choi, Section 3.3, para 3, Fig 17, discloses that the REST API server perform operations conforming to the Open Badge standard; Section1, Introduction, para 2, Choi discloses Open Badge issuing platform (Badgr) verifies learning completion criteria and issues open badges, It is inherent that the REST API constitute a request to the platform for issuance of an Open Badge based on completion of learning (Section 5, Conclusion); Introduction, para 2, Choi discloses Open Badge issuing platform (Badgr)verifies learning completion criteria and issues open badges; (Section 5, Conclusion, Choi discloses that the criteria (Section 2.1, para 4, e.g., completing a part of a course or an entire course) to earn a badge is verified through the network before awarding the badge.);
and when one of the open badges is selected from the issuable open badge list, issuing, by the service server, the selected open badge by identifying and combining history data and format based on the secure storage of the corresponding user registered in the blockchain (Choi, Fig. 13-17 discloses REST APIs for listing badges, badges from certain issuers, awarding badges; page 15, para 1, Choi discloses that when the badge issue button is pressed, then issued badge is displayed; Section 3.2, para 2, Choi discloses that the badge is a combination of an image and metadata which includes skills, issues, credits, microcredits gained by student; page 8, para 3, Choi discloses that the badges are managed via backpack repository and are recorded in blockchain.)
It would have been obvious to one of the ordinary skills in the art before the effective filing date to modify Quick’s system to incorporate Choi’s open badge issuance and verification architecture because both references address the same problem of securely issuing, verifying and utilizing learning achievement credentials using blockchain technology. One would be motivated to perform such modification to Quick’s system in order to integrate Choi’s standard-compliant Open Badge issuance workflow, REST-API based server thereby enhancing verification efficiency and practical deployment of Smart blockchain badges.
Choi does not explicitly teach; However, Sang teaches,
recording and managing, by the service server, the issued open badge in a DID electronic wallet of the corresponding user registered on a blockchain (Sang, para 57 discloses that the digital badge DID ledger registration module (205) can be configured to register a digital badge DID issued by the digital badge DID issuance module (204) into the blockchain ledger.);
and when a verification request for the issued open badge is received from a second institutional terminal, performing, by the service server, verification on the issued open badge based on the DID electronic wallet of the corresponding user, (Sang, para 68, discloses that the AI human resource recruitment server (300) can be configured to verify a digital badge DID submitted online from a user terminal (100) through a blockchain ledger, and if there is no abnormality in the verification result, perform IT human resource recruitment for an IT company or IT project using an AI algorithm);
Wherein the secure storage is the DID electronic wallet (Sang, para 57 discloses that the digital badge DID ledger registration module (205) can be configured to register a digital badge DID issued by the digital badge DID issuance module (204) into the blockchain ledger.);
It would have been obvious to one of the ordinary skills in the art before the effective filing date to modify Quick’s system to incorporate Sang’s DID-based digital badge registration and verification framework because both references address the same recognized problem of securely managing, storing, and verifying learning achievement credentials using blockchain technology. One would be motivated to perform such modification to Quick’s system in order to integrate Sang’s registration of issued digital badges as DIDs in blockchain ledger thereby enhancing credential integrity, user centric badge custody through DID electronic wallet and reliable qualification verification by third-party institutions.
Sang does not explicitly teach; However, Pagni teaches,
information about a possibility of integration with another badge (Pagni, page 5, para 28 discloses that open badges are stackable which means that a badge issued by one institution can form the basis for a subsequent badge issued by another);
other service purpose information (Pagni, page 6, para 29 discloses that open Badges can be used to signal membership in groups, such as clubs, circles or organizations, or to certify qualification for certain professions.);
information about prerequisite learning requirements for course registration (Pagni, page 5, para 28 discloses that using an appropriate network of sequential open badges to define preparatory courses that enables students to fill those gaps to be filled before taking more challenging courses.);
information about connectivity with another course (Pagni, page 6, para 30 discloses that open badges issued will also need to indicate the progression of student from one course to other. If three courses are required in order of complexity, the badges must indicate this progression.);
and information about a characteristic of a qualification created by integration with another course (Pagni, page 5, para 28 discloses that open badges are stackable which means that a badge issued by one institution can form the basis for a subsequent badge issued by another; page 5, para 25, Pagni discloses open badges with greater number of description fields allows for detailed representation of the educational background of badge holders.)
It would have been obvious to one of the ordinary skills in the art before the effective filing date to modify Quick’s system to incorporate Pagni’s open-badge metadata and badge stacking framework because both references address the same recognized problem representing learning progressions, prerequisites and portable digital credential system. One would be motivated to perform such modification to Quick’s system in order to integrate Pagni’s teaching that open badges are stackable, can indicate prerequisite learning requirements, course connectivity and progression thereby enhancing the interoperability and educational usefulness of smart blockchain badges for guiding learners through sequential learning paths.
Claims 5-7 are rejected under 35 U.S.C. 103 as being unpatentable over Quick (A. Mikroyannidis, J. Domingue, M. Bachler and K. Quick, "Smart Blockchain Badges for Data Science Education," 2018 IEEE Frontiers in Education Conference (FIE)) in view of Choi (Choi, M., Kiran, S. R., Oh, S.-C., & Kwon, O.-Y. (2019). Blockchain-Based Badge Award with Existence Proof. Applied Sciences) in view of Sang (KR 20240145588 A) further in view of Pagni (Pagni, F. (2022). Digital certifications and open badges. https://www.dyndevice.com/en/news/digital-certifications-and-open-badges-ELN-1726/) further in view of Hoon (KR 102619137 B1)
Regarding Claim 5, Quick/Choi/Sang/Pagni teaches the system of claim 3,
Quick/Choi/Sang/Pagni does not explicitly teach; However, Hoon teaches:
wherein when performing the verification, the service server verifies badge issuance
data by using a hash value of the issued open badge and a hash value of an open badge previously registered in the blockchain (Hoon, para 50 discloses the second open badge hash obtained by hashing by the host server 300 in the blockchain network 50 and the open badge hash generated by the Issuer server 100 is referred to as the first open badge hash and by using these hashes the system can verify whether the open badge has been tampered)
It would have been obvious to one of the ordinary skills in the art before the effective filing date to modify Quick/Choi/Sang/Pagni’s system to incorporate Hoon’s hash-based badge verification because all references address the same problem of securely reliably verifying the authenticity and integrity of issued open badges in blockchain. One would be motivated to perform such modification to Quick/Choi/Sang/Pagni’s system to detect tampering and to further perform DID-based verification using a DID associated with the badge and stored in a DID electronic wallet.
Hoon does not explicitly teach; However, Sang teaches,
Wherein the verification comprises DID verification (Sang, para 68 discloses recruitment server configured for DID verification;).
It would have been obvious to one of the ordinary skills in the art before the effective filing date to modify Quick/Choi/Hoon/Pagni’s system to incorporate Sang’s DID-based verification using a DID electronic wallet because all references address the same problem of securely verifying user-held digital badges. One would be motivated to perform such modification to Quick/Choi/Hoon/Pagni’s system to strengthen identity binding, temper resistance, and trustworthiness of third-party badge verification.
Regarding Claim 6, Quick/Choi/Sang/Pagni/Hoon teaches the system of claim 5,
Quick/Sang/Pagni/Hoon does not explicitly teach; However, Choi teaches:
wherein the service server performs verification on the issued open badge based on a
public key used to sign an assertion that is digitally signed in the issued open badge. (Choi, Section 3.1 discloses that the digital badge issuer generates badge assertion and digital signature through a public key-based cryptosystem … And in case of a signed assertion, a public/private key pair must be created to host the public key so verifiers can use it.)
It would have been obvious to one of the ordinary skills in the art before the effective filing date to modify Quick/Sang/Pagni/Hoon’s system to incorporate Choi’s public-key-based signed assertion verification because all references address the same problem of securely authenticating issued open badges and preventing forgery in a decentralized, blockchain system. One would be motivated to perform such modification to Quick/Sang/Pagni/Hoon’s system in order to perform verification of an issued open badge using public key corresponding to a digitally signed badge assertion to ensure authenticity, non-repudiation and cryptographic integrity of the badge.
Regarding Claim 7, Quick/Choi/Sang/Pagni/Hoon teaches the system of claim 6,
Choi/Sang/Pagni/Hoon does not explicitly teach; However, Quick teaches:
wherein the first institutional terminal includes user information about the corresponding
user and the history information, and wherein the badge issuance data is extracted from the history information (Quick, Section IV (A) discloses learning providers like Massive open online courses (MOOCs), Open Educational Resources (OERs) and online paid courses provides learning service to the learner. Each time the learner completes a course, the learner earns a Smart Blockchain Badge. These badges are stored on the Blockchain and include data about the skills that the specific learner has acquired which implies user data and updating learner history; Quick, Section I, para 4, discloses earning badges are determined upon learners reaching certain milestones in their studies, like completing part of a course or a whole course which represents utilizing history information.)
Claims 8 and 9 are rejected under 35 U.S.C. 103 as being unpatentable over Quick (A. Mikroyannidis, J. Domingue, M. Bachler and K. Quick, "Smart Blockchain Badges for Data Science Education," 2018 IEEE Frontiers in Education Conference (FIE)) in view of Choi (Choi, M., Kiran, S. R., Oh, S.-C., & Kwon, O.-Y. (2019). Blockchain-Based Badge Award with Existence Proof. Applied Sciences) in view of Sang (KR 20240145588 A) further in view of Pagni (Pagni, F. (2022). Digital certifications and open badges. https://www.dyndevice.com/en/news/digital-certifications-and-open-badges-ELN-1726/) further in view of Kap (KR 102179498 B1)
Regarding Claim 8, Quick/Choi/Sang/Pagni teaches the system of claim 1,
Quick/Choi/Sang/Pagni does not explicitly teach; However, Kap teaches:
wherein when a DID user registration request is received from the user terminal, the
service server verifies user identity through one of a plurality of authentication methods while issuing an initial distributed ID to the corresponding user. (Kap, para 37 discloses DID registration step (S110) includes user authentication step(110), when a user registration is requested through the application 10, the Web application server (WAS) 20 accesses the financial institution server 40 to authenticate the user's real name to the financial institution server 40; Kap, para 38 discloses In the DID generation step (S120), as shown in FIG. 5, the WAS 20 accesses the blockchain network 30 based on the pre-stored user registration information to request the creation of a user DID, and the blockchain network (30) can generate a user DID and transmit the generated user DID to the WAS (20).)
It would have been obvious to one of the ordinary skills in the art before the effective filing date to modify Quick/Sang/Pagni/Choi’s system to incorporate Kap’s DID user registration and identity verification mechanism because all references address the same problem of securely establishing a trusted digital identity for users in a blockchain-based credential system at the time of initial registration. One would be motivated to perform such modification to Quick/Sang/Pagni/Choi’s system to secure onboarding, reliable identity binding, trustworthiness of issued and verified open badges.
Regarding Claim 9, Quick/Choi/Sang/Pagni teaches the system of claim 8,
Quick/Choi/Sang/Pagni does not explicitly teach; However, Kap teaches:
wherein the plurality of authentication methods includes at least one of biometric
authentication, a PIN number, and a pattern (KAP, para 39 discloses authentication method (S130) like user biometric authentication is requested by the WAS 20 to the application 10.)
It would have been obvious to one of the ordinary skills in the art before the effective filing date to modify Quick/Sang/Pagni/Choi’s system to incorporate Kap’s disclosure of multiple authentication methods including biometric authentication because all references address the same problem strong, user-centric authentication techniques. One would be motivated to perform such modification to Quick/Sang/Pagni/Choi’s system to enhance security, flexibility, and user convenience during DID registration and authentication.
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to AMIT KHADKA whose telephone number is (703)756-1440. The examiner can normally be reached Monday - Friday, 8:00 am - 5:00 pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Jeffrey L. Nickerson can be reached at (469) 295-9235. The fax phone number for the organization where this application or proceeding is assigned is 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 and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/AMIT KHADKA/Examiner, Art Unit 2432
/Jeffrey Nickerson/Supervisory Patent Examiner, Art Unit 2432
Prosecution Insights