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 .
DETAILED ACTION
This action is in response to the communication filed on 6/4/24.
Claims 1 – 4, 7, 10, 12, 14, 15, 19, 21, 22, 31 – 34, 42, and 43 are pending.
Claims 5, 6, 8, 9, 11, 13, 16 - 18, 20, 23 – 30, and 35 – 41 are cancelled.
Claims 1 – 4, 7, 10, 12, 14, 15, 19, 21, 22, 31 – 34, 42, and 43 are rejected.
Any references to applicant’s specification are made by way of applicant’s U.S. pre-grant printed patent publication.
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, 7, 10, 12, 14, 15, 21, 22, 31 – 34, 42, and 43 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter.
Regarding claims 1 – 4, 7, 10, 12, 14, 15, 21, 22, 31 – 34, and 42, it is noted that the claimed invention is directed to a judicial exception, i.e. an abstract idea, without significantly more.
Specifically, regarding claim 1, it essentially comprise the limitations for receiving information (i.e. a request indicating an identifier) and obtaining information (i.e. “permission” information based upon the request, wherein the “permission” information characterizes non-functional descriptive material – i.e. indications of things that a person is allowed to do). Thus, the claims are directed towards the judicial exception of an abstract idea, as they broadly represent mental operations (e.g. observations, evaluations) without any integration into a practical application. Furthermore, the recitation of “computer implemented” merely amounts to instructions to apply the judicial exception to some form of generic computer component or structure as a tool, and thus, does not server to integrate the judicial exception into a practical application.
Regarding claims 2 – 4, 7, 10, 12, 14, 15, 21, 22, 31, and 32, the examiner notes that they essentially comprise recitations further directed towards mental processes and/or characterizations of information, such as making determinations of “permission information” or that the “permission information” is characterized as having “strings”, or having name-values, or being part of a hierarchy of information. These claims fail to integrate the abstract idea into any practical implementation.
Regarding claims 33 and 34, they comprise the recitations of “transmitting” information indicative of a request, however, they essentially amount to extra solution activity associated with the abstract idea, and they fail to specifically integrate the abstract idea into a practical application. The examiner notes that the language of “…for storage into a log…” and “…for inclusion on a blockchain…” are only intended use recitations, and they fail to comprise any explicit method step (e.g. “storing” data within a particular logging structure or “storing” data into a blockchain) that integrates the abstract idea into a specific practical implementation.
Regarding claim 42, it is rejected for essentially the same reasons as claim 1 because the examiner notes that, but for the additional recitations of generic computing elements (e.g. a program and storage medium), the claims fail to recite additional elements or combination of elements that impose any meaningful limits on the judicial exception so as to integrate the abstract idea into a practical implementation, but rather, simply represent the use of a generic computing means as a tool to perform the abstract idea.
Furthermore, regarding claim 43, this claim does not fall within at least one of the four categories of patent eligible subject matter because they are broadly limited to a computer program, i.e. information per se. Computer programs do not fall within any statutory category of invention. Thus, claim 43 is unpatentable.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 2 – 4, 19, and 22 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Regarding claim 2, the recitation “…the parent permit of the first permit …” (e.g. line 4) lacks antecedent basis within the claims. Specifically, the claims fail to previously recite the first permit as having a parent permit, i.e. “a parent permit of the first permit”. Thus, the claims are rendered indefinite in scope.
Regarding claim 4, the recitations “…wherein determining that the sender of the request is the computing associated with the parent permit or the holder …” (lines 2, 3), and “…confirming … is the computing associated with parent permit …” (lines 6, 7) renders the scope of the claims indefinite. Specifically, each of the recitations of “…the computing associated with the parent permit…” and “…the computing associated with parent permit…” lack antecedent basis within the claims. For the purpose of examination, the examiner notes that the applicant may be intending to reference “the computing module” as recited within claim 2.
Regarding claim 19, the recitation “…a secure computing environment…” renders the scope of the claims indefinite. Specifically, the examiner notes that there is no standard definition or meaning within the art for a “secure computing environment”.
Furthermore, the meaning of the term “secure” is subjective. In other words, what might be considered “secure” by one person may be considered to be “insecure” by another, and vice-versa (e.g. the “…perception of safety and security are subjective, localized, and quite often very personal.”, Cordero et al., US 2013/0157612 A1; par. 78). Thus, there does not exist and standard agreement within the art as to what environments qualify as “secure”.
Additionally, the applicant’s own disclosure – although using the term “secure computing environment” - fails to ever define, or even provide any exemplary disclosure, of environments that would fall within the scope of the term “secure” or of any particular security measures taken within environments so as to qualify the environment as “secure”.
Thus, the examiner notes that the scope of the claim is rendered indefinite.
Regarding claim 22, the recitation “…or a time that indicates when the permit is valid …” renders the scope of the claims indefinite. Specifically, antecedent basis within the claims exist for a number of permits, including “a first permit”, “hierarchy of permits”, “further permits”, “children permits”, and “descendent permits”. The recitation of “the permit” is unclear because the applicant fails to specifically identify which of the plurality of previously recited permits that the applicant intends to reference.
Depending claims are rejected by virtue of dependency.
Claim Rejections - 35 USC § 102
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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1 – 4, 7, 10, 12, 14, 15, 21, 22, 31 – 34, 42, and 43 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Murdoch et al. (Murdoch), US 2023/0177137 A1.
Regarding claim 1, Murdoch discloses:
A computer-implemented method for adding further permissions to a first permit (.e.g. Murdoch, Abstract, claim 16), comprising the steps:
receiving a request comprising a first permit identifier, wherein the first permit identifier identifies the first permit (e.g. Murdoch, fig. 3:312; par. 12, 49 – a request is issued to create a child verifiable credential (VC), i.e. “permit”, wherein the request comprises an identifier for identifying a parent verifiable credential (VC), i.e. “first permit identifier”);
and obtaining a first permit data based on the first permit identifier wherein the first permit data comprises data indicative of at least one permission and wherein the at least one permission provides an indication of one or more actions a holder of the first permit can take and/or what the holder of the first permit is allowed to do (e.g. Murdoch, par. 3, 49 – herein claims information, i.e. “permissions”, are obtained based upon the parent verifiable credential, wherein the claims information indicates permission data, such as authorizations and/or restrictions [e.g. permissions to drive, etc…] to be placed upon a holder of a verifiable credential)
wherein the request is to add a set of further permissions to the first permit and the request comprises the set of further permissions (e.g. Murdoch, par. 33, 38, 49, 54, 57, 80-82; fig. 4:420,411, 412; fig. 11; par. 90 - herein a child verifiable credential - comprising a further set of claims, i.e. a “set of permissions” - is combined, i.e. “added”, to the parent, or “first”, verifiable credential, such as within an identity card data structure, or DID document structure, a digital wallet, and/or a distributed blockchain ledger).
Regarding claim 2, as best determined in view of the above noted issues of clarity Murdoch discloses:
wherein the method comprises determining that a sender of the request is a computing module associated with a parent permit and/or a holder of the parent permit (e.g. Murdoch, par. 49, 61, 62, 74 – herein an issuer determines that the request is associated with a parent verifiable credential, i.e. “permit”, wherein the holder of the credential is authenticated by the issue) and wherein the parent permit is the parent permit of the first permit (e.g. Murdoch, par. 49 and/or e.g. Murdoch, par. 75, 78 – herein the “parent” VC may be considered to be the “first” permit and/or a template VC may be considered to be a “first” permit, of a “parent” VC, which may later be used to derive another VC, or “child” VC).
Regarding claim 3, Murdoch discloses:
wherein if the sender of the request is not the parent permit or the holder of the parent permit, the request is not processed (e.g. Murdoch, par. 61, 62, 74 – herein only authenticated holders, i.e. “senders”, of parent verifiable credentials can add child verifiable credentials).
Regarding claim 4, Murdoch discloses:
wherein determining that the sender of the request is the computing associated with the parent permit or the holder of the parent permit comprises:
comparing a permit identifier comprised in the received request and a parent identifier comprised in the first permit data (e.g. Murdoch, par. 49); and confirming the sender of the request is the computing associated with parent permit or the holder of the parent permit based on the comparing (e.g. Murdoch, par. 61, 62, 74 – herein holder of the VC is confirmed to be associated with the identified VC).
Regarding claim 7, Murdoch discloses:
further comprising the step of continuing processing the request based on a determination of whether the first permit has been revoked (e.g. Murdoch, par. 116, 120).
Regarding claim 10, Murdoch discloses:
determining a maximum number of sets of permissions would not be exceeded with an addition of the set of further permissions and continuing processing the request based on the determination (e.g. Murdoch, par. 46, 68 – the system can control the maximum amount of claims that may be added to a VC based upon the number of claims within a parent VC).
Regarding claim 12, Murdoch discloses:
wherein the request comprises a string to identify the set of further permissions (e.g. Murdoch, par. 49, 68, 87 – claims are represented as strings of information).
Regarding claim 14, Murdoch discloses:
further comprising the step of adding the set of further permissions to the permit (e.g. Murdoch, par. 33, 38, 49, 54, 57, 80-82; fig. 4:420,411, 412; fig. 11; par. 90 - herein a child verifiable credential - comprising a further set of claims, i.e. a “set of permissions” - is combined, i.e. “added”, to the parent, or “first”, verifiable credential, such as within an identity card data structure, or DID document structure, a digital wallet, and/or a distributed blockchain ledger).
Regarding claim 15, Murdoch discloses:
wherein data indicative of the at least one permission is an object comprising at least one name-value pair (e.g. Murdoch, fig. 11:1110, 1101; par. 13, 87, 108 – claims information are represented as name-value strings).
Regarding claim 21, Murdoch discloses:
wherein the first permit is part of a hierarchy of permits (e.g. Murdoch, Abstract; fig. 4:411, 412 – herein is disclosed a parent-child hierarchy).
Regarding claim 22, Murdoch discloses:
wherein the first permit data comprises at least one or more of:
an indication as to whether further permits may be generated that are children of the first permit;
at least one namespace, wherein each namespace defines part of a permission a child of the first permit can have;
an indication as to a maximum depth of descendants that the first permit can have;
a maximum number of children permits that the first permit can have;
an array to indicate a maximum number of descendant permits that the first permit can have at different depths;
or a time that indicates when the permit is valid from or until (e.g. Murdoch, 93 – herein the claims information may comprise a limited time period for which the VC is valid).
Regarding claim 31, Murdoch discloses:
wherein the first permit identifier obliviates the identity of the holder of the first permit (e.g. Murdoch, par. 87, 97 – the VC identifier may be random, anonymous, or pseudo anonymous).
Regarding claim 32, Murdoch discloses:
wherein the first permit identifier is a pseudo-randomly generated string of characters (e.g. Murdoch, par. 87, 97 – the VC identifier may be random, anonymous, or pseudo anonymous).
Regarding claim 33, Murdoch discloses:
transmitting data indicative of the request for storage in a log (e.g. Murdoch, par. 57, 58, 90 – herein data that results from the VC creation request, i.e. “data indicative of the request”, may be transmitted to a ledger, i.e. “a log”).
Regarding claim 34, Murdoch discloses:
transmitting data indicative of the request for inclusion on a blockchain (e.g. Murdoch, par. 57, 58, 90 – herein data that results from the VC creation request, i.e. “data indicative of the request”, may be transmitted to a ledger, wherein the ledger may be a blockchain).
Regarding claims 42 and 43, they are program and program with medium claims essentially corresponding to the claims above, and they are rejected, at least, for the same reasons, and furthermore because Murdoch discloses a program and medium (e.g. Murdoch, claim 35).
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.
Claim 19 is rejected under 35 U.S.C. 103 as being unpatentable over Murdoch et al. (Murdoch), US 2023/0177137 A1 in view of Yang et al. (Yang), US 2020/0145209 A1.
Regarding claim 19, as best understood in view of the above noted issues of clarity, Murdoch discloses a computing system comprising a software interface for enabling a user’s computing system to request an issuer’s computing system to generating a verifiable credential within a DID (e.g. Murdoch, fig. 8C; par. 12, 49, 75 – 79). However, Murdoch does not appear to explicitly teach using an “API” for sending such service requests.
However, Yang discloses that application programming interfaces, i.e. API, may be used to facilitate a issuer to smoothly create and issue DIDs and VCs for requesting users (e.g. Yang, par. 51), wherein users can use the API to directly submit requests to the issuer for a DID or VC (e.g. Yang, par. 69).
It would have been obvious to one of ordinary skill in the art to recognize the teachings of Yang for employing an API to submit VC or DID issuance requests within the system of Murdoch because .
This would have been obvious because one of ordinary skill in the art would have been motivated by the teachings that APIs enable the interaction of various computing systems to smoothly facilitate the issuance of DIDs and VCs (e.g. Yang, par. 51, 69).
Thus, the combination enables:
wherein the request is received via an API that is only provided to computing modules belonging to a secure computing environment (e.g. Murdoch, par. 12, 49, 75-79; e.g. Yang, par. 69, 70, 79, 106, 149 – API is used by user and issuer systems secured using means such as TEE).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
See Notice of References Cited.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JEFFERY L WILLIAMS whose telephone number is (571)272-7965. The examiner can normally be reached on 7:30 am - 4:00 pm.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Farid Homayounmehr can be reached on 571-272-3739. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/JEFFERY L WILLIAMS/ Primary Examiner, Art Unit 2495