DETAILED ACTION
Authorization for Internet Communications
The examiner encourages Applicant to submit an authorization to communicate with the examiner via the Internet by making the following statement (from MPEP 502.03):
“Recognizing that Internet communications are not secure, I hereby authorize the USPTO to communicate with the undersigned and practitioners in accordance with 37 CFR 1.33 and 37 CFR 1.34 concerning any subject matter of this application by video conferencing, instant messaging, or electronic mail. I understand that a copy of these communications will be made of record in the application file.”
Please note that the above statement can only be submitted via Central Fax (not Examiner's Fax), Regular postal mail, or EFS Web using PTO/SB/439.
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 .
Priority
Should applicant desire to obtain the benefit of foreign priority under 35 U.S.C. 119(a)-(d) prior to declaration of an interference, a certified English translation of the foreign application must be submitted in reply to this action. 37 CFR 41.154(b) and 41.202(e).
Failure to provide a certified translation may result in no benefit being accorded for the non-English application.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 02/20/2025 is being considered by the examiner.
Specification
The abstract of the disclosure is objected to because the first occurrence of the acronym “DID” should be spelled out.
A corrected abstract of the disclosure is required and must be presented on a separate sheet, apart from any other text. See MPEP § 608.01(b).
The title of the invention is not descriptive. A new title is required that is clearly indicative of the invention to which the claims are directed.
The specification is objected to as failing to provide proper antecedent basis for the claimed subject matter. See 37 CFR 1.75(d)(1) and MPEP § 608.01(o). Correction of the following is required:
Claims 1 and 7 recite that the SSI management function provides the certificate holder (Holder) with “a private key corresponding to the public key for the DID of the certificate issuing organization (Issuer)” and further recite that the Holder signs the verifiable presentation (VP) “using the private key”.
However, the specification recite that the Holder signs the verifiable presentation (VP) “using the private key.” However, the specification does not clearly identify this claimed key relationship. The specification describes the certificate issuing organization (Issuer) signing the verifiable credential (VC) using a private key corresponding to the Issuer’s public key (para 0051). The specification further describes the certificate holder (Holder) singing the verifiable presentation (VP) using a private key corresponding to the Holder’s public key (para 0052). Further, figure 8 depicts that issuance to the Holder of a “private key for the automobile CAR1.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1 - 12 are rejected under 35 U.S.C. 112, first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor(s), at the time the application was filed, had possession of the claimed invention.
Independent claims 1 and 7 recite “the SSI management function provides…a private key corresponding to the public key for the DID of the certificate issuing organization (Issuer);…the verifiable presentation (VP) signed by the certificate holder (Holder) using the private key”. However, the specification as originally filed discloses the Issuer signs the verification credential (VC) using he private key corresponding to the Issuer’s public key (para 0051). Further discloses the Holder signs the verification presentation (VP) using the private key corresponding to the Holder’s public key (para 0052). Accordingly, although the specification separately describes (1) an Issuer private key corresponding to an Issuer public key, (2) a Holder signing a VP using a Holder private key, and (3) providing a Holder with a private key associated with a target object, the specification does not reasonably convey position of the claimed combination in which the Holder is provided with the private key corresponding to the Issuer’s DID public key and uses that private key to sign the VP.
Therefore, the specification as originally filed does not provide support for claims as recited.
Claims 2 – 6 and 8 - 12 are dependent claims and thus also rejected.
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.
Claims 2 – 5 and 8 - 11 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 claims 2 and 8, the limitation “if the signature attached to the verifiable credential (VC) and the verifiable presentation (VP) have not been tampered with, allowing the certificate holder (Holder) to access the information about the target object” renders the claim indefinite because it is unclear whether the recited step is required in all embodiments or only conditionally performed. The claims do not specify what occurs if the condition is not met. Thus, the scope of the claim is not reasonably certain.
Claims 3 – 5 and 9 - 11 are dependent claims and thus also rejected.
Regarding claims 3 and 9, the limitation “if the organization that issued the verifiable credential (VC) is included in the organization management ledger, allowing the certificate holder (Holder) to access the information about the target object” renders the claim indefinite because it is unclear whether the recited step is required in all embodiments or only conditionally performed. The claims do not specify what occurs if the condition is not met. Thus, the scope of the claim is not reasonably certain.
Claims 4 – 5 and 10 - 11 are dependent claims and thus also rejected.
Regarding claims 4 and 10, the limitation “if they match, allowing the certificate holder (Holder) to access the information about the target object” renders the claim indefinite because it is unclear whether the recited step is required in all embodiments or only conditionally performed. The claims do not specify what occurs if the condition is not met. Thus, the scope of the claim is not reasonably certain.
Claims 5 and 11 are a dependent claim and thus also rejected.
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(s) 1 - 12 are rejected under 35 U.S.C. 103 as being unpatentable over Michaelis et al., (US 11,429,958 B1) (hereinafter “Michaelis”) in view of KASSIS et al., (US 2023/0421386 A1) (hereinafter “Kassis”).
Regarding claim 1, Michaelis discloses; an information processing system comprising:
a plurality of nodes configured using information processing apparatuses operated by each of a plurality of organizations and coupled so as to be communicable with each other [i.e., resource-access system 100 includes issuer node 102, user device 104, access-policy-evaluation node 106, blockchain authorization nodes 112, credential-verification nodes 116, and storage nodes 120, interconnected via WAN 122/LAN 124 (see figure 1) Note; defines “node” or “computing node” as a networked computing device capable of communicating digitally with other nodes], wherein at least some of the plurality of nodes function as nodes making up a distributed ledger system that provides a distributed ledger [i.e., blockchain authorization network 110, blockchain verifiable-credential network 114 and distributed storage network 118 comprise plural blockchain/storage node. Authorization records are stored across nodes 112 as verified blockchain transaction (see figure 1)], the distributed ledger system is capable of executing a smart contract in response to a transaction sent from the plurality of nodes [i.e., after a node verifies a condition, it reports the verification by sending a transaction to blockchain authorization network 110, where a smart contract verifies the transaction…verifying nodes provide indications to the smart contract and the smart contract verifies when all condition have been met (see figure 3B)], the distributed ledger system manages, in the distributed ledger, information about a target object [i.e., resource 108 (see figure 1) i.e., resource 108 may be digital or physical, may be stored in distributed storage network 118 according to distributed-ledger technology and may be assign a DID (see ref. 300 – 308 of figure 3A)] and DID (Decentralized Identity) documents including a DID of each participating organization, which is an organization participating in the distributed ledger, and a public key for the DID [i.e., users may be grouped into organization/domains/realms; DID blockchain relationship tables associate users/resources; VC/VP structures employ a public key generated by the Issuer and DIDs (see ref. 306,312 – 320 of figure 3A and figure 4)], at least some of the plurality of nodes provide an SSI management function, which is a function for managing a verifiable credential (VC) issued by a participating organization that is a certificate issuing organization (Issuer) using SSI technology (SSI: Self-Sovereign Identity) and a verifiable presentation (VP) issued by a participating organization that is a certificate holder (Holder) based on the verifiable credential (VC) [i.e., Issuer generates a VC, signs it using the private key of the Issuer’s DID, provides the signed VC to the user, creates a resource specific VP template and the user’s VP contains attributes from the user’s VC (see ref. 312 – 326 of figure 3A)], the SSI management function provides the certificate holder (Holder) with the verifiable credential (VC) issued by the participating organization that is the certificate issuing organization (Issuer) for the target object [i.e., Issuer provides the signed VC to the user, the requested resource is identified and the resulting VP is specifically associated with accessing that resource (see ref. 316 – 326 of figures 3A – 3B)] and corresponding to the public key for the DID of the certificate issuing organization (Issuer), and the SSI management function manages, as the smart contract, a program that implements a function of determining whether to allow the certificate holder (Holder) to access the information about the target object managed in the distributed ledger, based on the verifiable presentation (VP) [i.e., resource specific VP permits access policy evaluator 106 to determine whether the requesting entity is authorized to access the requested resource…smart contract logic to enforce access condition (see ref. 326 – 340 of figures 3A – 3B)].
Michaelis does not disclose;
a private key and signed by the certificate holder (Holder) using the private key
However, Kassis discloses;
Verifiable presentation (VP) signed by holder using the private key [i.e., the Holder authorized trader’s private key signs that presentation proof (para 0088) and (para 0094 – 0096), (see ref. 502 – 522 of figure 5)]; and smart contract verifies that singed VP/Holder [i.e., verifiers smart contract calculates the presentation hash, verifies the presentation digital signature, recovers the signer and checks that the recovered signer corresponds to the VC subject (para 0108 – 0113), (see figures 6A – 6B)].
Before the effective filing date of the claimed invention, it would have been obvious to a person of ordinary skill in the art to modify the teachings of Michaelis by adapting the teachings of Kassis to using digital identity framework to access and interact with decentralized application (See Kassis; page 1, para 0002).
Regarding claim 2, Michaelis discloses; the information processing system according to claim 1, wherein the smart contract implements a function of, when determining whether to allow the certificate holder (Holder) to access the information about the target object, checking signatures attached to the verifiable credential (VC) [i.e., issuer signs the VC using the private key of Issuer’s DID, the corresponding public kye permits other nodes to verify that the VC was issued by the issuer (see ref. 312 – 324 of figure 3A)].
Michaelis does not disclose;
the verifiable presentation (VP) based on the DID document and, if the signatures attached to the verifiable credential (VC) and the verifiable presentation (VP) have not been tampered with, allowing the certificate holder (Holder) to access the information about the target object.
However, Kassis discloses;
the verifiable presentation (VP) based on the DID document and, if the signatures attached to the verifiable credential (VC) and the verifiable presentation (VP) have not been tampered with, allowing the certificate holder (Holder) to access the information about the target object [i.e., verifier smart contract verifies presentation proof/signature, recovers the signer and verify the signer against the VC subject (para 0097 – 0099), (see figures 6A – 6B and 7A – 7B) i.e., successful identity credential verification permits proxy smart contract processing execution of the requested transaction (para 0064 – 0070), (see figures 2A – 2B)].
Before the effective filing date of the claimed invention, it would have been obvious to a person of ordinary skill in the art to modify the teachings of Michaelis by adapting the teachings of Kassis to using digital identity framework to access and interact with decentralized application (See Kassis; page 1, para 0002).
Regarding claim 3, Michaelis discloses; the information processing system according to claim 2, wherein the distributed ledger system stores an organization management ledger including information indicating the participating organizations [i.e., users are grouped into organizations, domain, realm with associated DID blockchain information that identifies relationships between users and resources and is considered when evaluating resource access (see ref. 306 of figure 3A)].
Michaelis does not disclose;
the smart contract implements a function of, when determining whether to allow the certificate holder (Holder) to access the information about the target object, checking whether the organization that issued the verifiable credential (VC) is included in the organization management ledger and, if the organization that issued the verifiable credential (VC) is included in the organization management ledger, allowing the certificate holder (Holder) to access the information about the target object.
However, Kassis discloses;
the smart contract implements a function of, when determining whether to allow the certificate holder (Holder) to access the information about the target object [i.e., authorized trader, trusted entity and root issuer registry DIDs with DID registry 144 (para 0039), (para 0045) and 0049), (see figure 1], checking whether the organization that issued the verifiable credential (VC) is included in the organization management ledger and, if the organization that issued the verifiable credential (VC) is included in the organization management ledger, allowing the certificate holder (Holder) to access the information about the target object [i.e., verifies smart contract validates the credential chain of trust (para 0098), (see figures 6A – 6B) i.e., concern verifying credential/issuer information, the verifier confirms trusted entity root issuer identities (para 0102 – 0107)].
Before the effective filing date of the claimed invention, it would have been obvious to a person of ordinary skill in the art to modify the teachings of Michaelis by adapting the teachings of Kassis to using digital identity framework to access and interact with decentralized application (See Kassis; page 1, para 0002).
Regarding claim 4, Michaelis discloses; the information processing system according to claim 3, wherein the verifiable credential (VC) includes an identifier of the target object [i.e., resource 300…resource 108 may be assigned a unique DID identifying the resource (see ref. 300 of figure 3)], the information about the target object managed in the distributed ledger includes the identifier [i.e., authorization event/VP template is associated with the particular resource, request may identify the requested resource by DID (see ref. 306, 318 – 326) i.e., identifies a credential subject by DID (see figure 4)].
Michaelis does not disclose;
the smart contract implements a function of, when determining whether to allow the certificate holder (Holder) to access the information about the target object, checking whether the identifier of the target object included in the verifiable credential (VC) matches the identifier included in the information about the target object and, if they match, allowing the certificate holder (Holder) to access the information about the target object.
However, Kassis discloses;
the smart contract implements a function of, when determining whether to allow the certificate holder (Holder) to access the information about the target object, checking whether the identifier of the target object included in the verifiable credential (VC) matches the identifier included in the information about the target object and, if they match, allowing the certificate holder (Holder) to access the information about the target object [i.e., verifies smart contract performs filed identify comparison and credential verification (para 0097 – 0113), (see figures 6A – 7B)].
Before the effective filing date of the claimed invention, it would have been obvious to a person of ordinary skill in the art to modify the teachings of Michaelis by adapting the teachings of Kassis to using digital identity framework to access and interact with decentralized application (See Kassis; page 1, para 0002).
Regarding claim 5, Michaelis discloses; the information processing system according to claim 4, wherein the verifiable credential (VC) includes information specifying information disclosable to the certificate holder (Holder) among the information about the target object [i.e., credential access information including read and store permissions (see figure 4)], and the smart contract implements a function of, when determining whether to allow the certificate holder (Holder) to access the information about the target object, allowing the certificate holder (Holder) to access the information disclosable to the certificate holder (Holder) among the information about the target object [i.e., conditions and permissions are assigned to the resources, permissions may include read, write, print, store copy, forwarding and rendering restrictions (see ref. 302 – 306 of figure 3A and figure 4) i.e., when conditions permissions are satisfied, processor provides the permitted resource access, otherwise it denies access (see ref. 302 – 342 of figure 3B)].
Regarding claim 6, Michaelis discloses; the information processing system according to claim 1, wherein the target object is a target of a transaction conducted between the plurality of organizations, and the information about the target object is information about a history of the transaction [i.e., nodes send verification transactions to blockchain authorization network 110 and smart contract verifies them (see figure 3B)].
Regarding claim 7, Michaelis discloses; an information processing method executed by an information processing system including a plurality of nodes configured using information processing apparatuses operated by each of a plurality of organizations and coupled so as to be communicable with each other [i.e., resource-access system 100 includes issuer node 102, user device 104, access-policy-evaluation node 106, blockchain authorization nodes 112, credential-verification nodes 116, and storage nodes 120, interconnected via WAN 122/LAN 124 (see figure 1) Note; defines “node” or “computing node” as a networked computing device capable of communicating digitally with other nodes], wherein at least some of the plurality of nodes function as nodes making up a distributed ledger system that provides a distributed ledger [i.e., blockchain authorization network 110, blockchain verifiable-credential network 114 and distributed storage network 118 comprise plural blockchain/storage node. Authorization records are stored across nodes 112 as verified blockchain transaction (see figure 1)], the distributed ledger system is capable of executing a smart contract in response to a transaction sent from the plurality of nodes [i.e., after a node verifies a condition, it reports the verification by sending a transaction to blockchain authorization network 110, where a smart contract verifies the transaction…verifying nodes provide indications to the smart contract and the smart contract verifies when all condition have been met (see figure 3B)], the information processing method comprising:
managing, in the distributed ledger, information about a target object [i.e., resource 108 (see figure 1) i.e., resource 108 may be digital or physical, may be stored in distributed storage network 118 according to distributed-ledger technology and may be assign a DID (see ref. 300 – 308 of figure 3A)] and DID (Decentralized Identity) documents including a DID of each participating organization, which is an organization participating in the distributed ledger, and a public key for the DID [i.e., users may be grouped into organization/domains/realms; DID blockchain relationship tables associate users/resources; VC/VP structures employ a public key generated by the Issuer and DIDs (see ref. 306,312 – 320 of figure 3A and figure 4)];
providing, by at least some of the plurality of nodes, an SSI management function, which is a function for managing a verifiable credential (VC) issued by a participating organization that is a certificate issuing organization (Issuer) using SSI technology (SSI: Self-Sovereign Identity) and a verifiable presentation (VP) issued by a participating organization that is a certificate holder (Holder) based on the verifiable credential (VC) [i.e., Issuer generates a VC, signs it using the private key of the Issuer’s DID, provides the signed VC to the user, creates a resource specific VP template and the user’s VP contains attributes from the user’s VC (see ref. 312 – 326 of figure 3A)];
providing, by the SSI management function, the certificate holder (Holder) with the verifiable credential (VC) issued by the participating organization that is the certificate issuing organization (Issuer) for the target object and a private key corresponding to the public key for the DID of the certificate issuing organization (Issuer) [i.e., Issuer provides the signed VC to the user, the requested resource is identified and the resulting VP is specifically associated with accessing that resource (see ref. 316 – 326 of figures 3A – 3B)] and corresponding to the public key for the DID of the certificate issuing organization (Issuer); and
managing, as the smart contract, a program that implements a function of determining whether to allow the certificate holder (Holder) to access the information about the target object managed in the distributed ledger, based on the verifiable presentation (VP) [i.e., resource specific VP permits access policy evaluator 106 to determine whether the requesting entity is authorized to access the requested resource…smart contract logic to enforce access condition (see ref. 326 – 340 of figures 3A – 3B)].
Michaelis does not disclose;
a private key and signed by the certificate holder (Holder) using the private key
However, Kassis discloses;
Verifiable presentation (VP) signed by holder using the private key [i.e., the Holder authorized trader’s private key signs that presentation proof (para 0088) and (para 0094 – 0096), (see ref. 502 – 522 of figure 5)]; and smart contract verifies that singed VP/Holder [i.e., verifiers smart contract calculates the presentation hash, verifies the presentation digital signature, recovers the signer and checks that the recovered signer corresponds to the VC subject (para 0108 – 0113), (see figures 6A – 6B)].
Before the effective filing date of the claimed invention, it would have been obvious to a person of ordinary skill in the art to modify the teachings of Michaelis by adapting the teachings of Kassis to using digital identity framework to access and interact with decentralized application (See Kassis; page 1, para 0002).
Regarding claim 8, Michaelis discloses; the information processing method according to claim 7, wherein the smart contract implements a function of, when determining whether to allow the certificate holder (Holder) to access the information about the target object, checking signatures attached to the verifiable credential (VC) [i.e., issuer signs the VC using the private key of Issuer’s DID, the corresponding public kye permits other nodes to verify that the VC was issued by the issuer (see ref. 312 – 324 of figure 3A)].
Michaelis does not disclose;
the verifiable presentation (VP) based on the DID document and, if the signatures attached to the verifiable credential (VC) and the verifiable presentation (VP) have not been tampered with, allowing the certificate holder (Holder) to access the information about the target object.
However, Kassis discloses;
the verifiable presentation (VP) based on the DID document and, if the signatures attached to the verifiable credential (VC) and the verifiable presentation (VP) have not been tampered with, allowing the certificate holder (Holder) to access the information about the target object [i.e., verifier smart contract verifies presentation proof/signature, recovers the signer and verify the signer against the VC subject (para 0097 – 0099), (see figures 6A – 6B and 7A – 7B) i.e., successful identity credential verification permits proxy smart contract processing execution of the requested transaction (para 0064 – 0070), (see figures 2A – 2B)].
Before the effective filing date of the claimed invention, it would have been obvious to a person of ordinary skill in the art to modify the teachings of Michaelis by adapting the teachings of Kassis to using digital identity framework to access and interact with decentralized application (See Kassis; page 1, para 0002)..
Regarding claim 9, Michaelis discloses; the information processing method according to claim 8, further comprising storing, by the distributed ledger system, an organization management ledger including information indicating the participating organizations [i.e., users are grouped into organizations, domain, realm with associated DID blockchain information that identifies relationships between users and resources and is considered when evaluating resource access (see ref. 306 of figure 3A)].
Michaelis does not disclose;
the smart contract implements a function of, when determining whether to allow the certificate holder (Holder) to access the information about the target object, checking whether the organization that issued the verifiable credential (VC) is included in the organization management ledger and, if the organization that issued the verifiable credential (VC) is included in the organization management ledger, allowing the certificate holder (Holder) to access the information about the target object.
However, Kassis discloses;
the smart contract implements a function of, when determining whether to allow the certificate holder (Holder) to access the information about the target object [i.e., authorized trader, trusted entity and root issuer registry DIDs with DID registry 144 (para 0039), (para 0045) and 0049), (see figure 1], checking whether the organization that issued the verifiable credential (VC) is included in the organization management ledger and, if the organization that issued the verifiable credential (VC) is included in the organization management ledger, allowing the certificate holder (Holder) to access the information about the target object [i.e., verifies smart contract validates the credential chain of trust (para 0098), (see figures 6A – 6B) i.e., concern verifying credential/issuer information, the verifier confirms trusted entity root issuer identities (para 0102 – 0107)].
Before the effective filing date of the claimed invention, it would have been obvious to a person of ordinary skill in the art to modify the teachings of Michaelis by adapting the teachings of Kassis to using digital identity framework to access and interact with decentralized application (See Kassis; page 1, para 0002)..
Regarding claim 10, Michaelis discloses; the information processing method according to claim 9, wherein the verifiable credential (VC) includes an identifier of the target object [i.e., resource 300…resource 108 may be assigned a unique DID identifying the resource (see ref. 300 of figure 3)], the information about the target object managed in the distributed ledger includes the identifier [i.e., authorization event/VP template is associated with the particular resource, request may identify the requested resource by DID (see ref. 306, 318 – 326) i.e., identifies a credential subject by DID (see figure 4)].
Michaelis does not disclose;
the smart contract implements a function of, when determining whether to allow the certificate holder (Holder) to access the information about the target object, checking whether the identifier of the target object included in the verifiable credential (VC) matches the identifier included in the information about the target object and, if they match, allowing the certificate holder (Holder) to access the information about the target object.
However, Kassis discloses;
the smart contract implements a function of, when determining whether to allow the certificate holder (Holder) to access the information about the target object, checking whether the identifier of the target object included in the verifiable credential (VC) matches the identifier included in the information about the target object and, if they match, allowing the certificate holder (Holder) to access the information about the target object [i.e., verifies smart contract performs filed identify comparison and credential verification (para 0097 – 0113), (see figures 6A – 7B)].
Before the effective filing date of the claimed invention, it would have been obvious to a person of ordinary skill in the art to modify the teachings of Michaelis by adapting the teachings of Kassis to using digital identity framework to access and interact with decentralized application (See Kassis; page 1, para 0002)..
Regarding claim 11, Michaelis discloses; the information processing method according to claim 10, wherein the verifiable credential (VC) includes information specifying information disclosable to the certificate holder (Holder) among the information about the target object [i.e., credential access information including read and store permissions (see figure 4)], and the smart contract implements a function of, when determining whether to allow the certificate holder (Holder) to access the information about the target object, allowing the certificate holder (Holder) to access the information disclosable to the certificate holder (Holder) among the information about the target object [i.e., conditions and permissions are assigned to the resources, permissions may include read, write, print, store copy, forwarding and rendering restrictions (see ref. 302 – 306 of figure 3A and figure 4) i.e., when conditions permissions are satisfied, processor provides the permitted resource access, otherwise it denies access (see ref. 302 – 342 of figure 3B)].
Regarding claim 12, Michaelis discloses; the information processing method according to claim 7, wherein the target object is a target of a transaction conducted between the plurality of organizations, and the information about the target object is information about a history of the transaction [i.e., nodes send verification transactions to blockchain authorization network 110 and smart contract verifies them (see figure 3B)].
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SYED A RONI whose telephone number is (571)270-7806. The examiner can normally be reached M-F 9:00-5:00 pm (EST).
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.
/SYED A RONI/Primary Examiner, Art Unit 2432
Prosecution Insights