Detailed Action
This is in response to application No. 19/240,310 filed on June 17, 2025. Claim 1 is canceled and new claims 2-10 are submitted for examination. Thus, claims 2-10 are pending and claim 2 is independent.
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
This application filed on 06/17/2025 is a Continuation of 18732987, filed 06/04/2024, now U.S. Patent # 12335375. Application No. 18732987 is a Continuation of 17516889, filed on 11/02/2021, now U.S. Patent # 12003620. Application No. 17516889 is a Continuation of 16774344, filed 01/28/2020, now U.S. Patent # 11165568. Application No. 16774344 Claims Priority from Provisional Application 62797439, filed on 01/28/2019.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 04/27/2026 has been considered. The submission is in-compliance with the provisions of 37 CFR 1.97. Form, PTO-1449 is signed and attached hereto.
Drawings
5. The drawings filed on June 17, 2025, are accepted.
Specification
The specification filed on June 17, 2025, is also accepted.
Internet Communications
7. Applicant is encouraged to submit a written authorization for Internet communications (PTO/SB/439, http:/www.uspto.gov/sites/default/files/documents/sb0439.pdf) in the instant patent application to authorize the examiner to communicate with the applicant via email. The authorization will allow the examiner to better practice compact prosecution. The written authorization can be submitted via one of the following methods only: (1) Central Fax, which can be found in the Conclusion section of this Office action; (2) regular postal mail; (3) EFS WEB; or (4) the service window on the Alexandria campus. EFS web is the recommended way to submit the form since this allows the form to be entered into the file wrapper within the same day (system dependent). Written authorization submitted via other methods, such as direct fax to the examiner or email, will not be accepted. See MPEP § 502.03.
Double Patenting
8. The non-statutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A non-statutory double patenting rejection is appropriate where the claims at issue are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); and In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on a nonstatutory double patenting ground provided the reference application or patent either is shown to be commonly owned with this application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The USPTO internet Web site contains terminal disclaimer forms which may be used. Please visit http://www.uspto.gov/forms/. The filing date of the application will determine what form should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to http://www.uspto.gov/patents/process/file/efs/guidance/eTD-info-I.jsp.
9. Claims 2-3 are rejected under judicially created doctrine of obviousness-type double patenting on the ground of non-statutory double patenting as being unpatentable over claims 1 and 3 of Patent No. 12/335,375 B2 (herein after referred as ‘375 patent)
Although the claims at issue are not identical, they are not patentably distinct from each other because they recite the same limitations and only differ by statutory category of invention. It would have been obvious to a person having ordinary skill in the art at the time the invention was made to have implemented the invention as any of a method, system or computer program product.
[Symbol font/0xB7] Independent claim 2 of the instant application and independent claim 1, of the ‘375 patent recite similar limitations. The above claims, namely 2 of the instant/present application, would have been obvious over claim 1, of the ‘375 patent, because every element of the above independent claim 2 of the present application is anticipated by the corresponding claim 1 of the ‘375 patent
[Symbol font/0xB7] dependent claim 3 of the instant application and dependent claim 3, of the ‘375 patent recite similar limitations. The above claims, namely 3 of the instant/present application, would have been obvious over claim 3, of the ‘375 patent, because every element of the above dependent claim 3 of the present application is anticipated by the corresponding claim 3 of the ‘375 patent
The following table maps at least each independent claim of the instant application with the corresponding claims of the ‘375 patent.
Instant application: application No. 19/240,310
US Patent No. ‘375 Patent.
2. A method of operating a receiver client device to enable a secure electronic data transfer from a sender client device, wherein the sender and receiver client devices each comprise a computing device, the method comprising:
electronically receiving Encrypted Data and a Moniker from a sender client device;
electronically delivering the Moniker to a broker device;
electronically receiving a Key DNA from the broker device in response to the step of delivering the Moniker;
generating a Key based upon the Key DNA; and decrypting the Encrypted Data using the Key.
1. A secure electronic data transfer system for use with a first client computing device, a second client computing device, and a broker computing device each connected to a network and each including a respective processor, the system comprising:
a first client non-transitory computer readable medium storing instructions executed by the processor of the first client computing device;
a second client non-transitory computer readable medium instructions executed by the processor of the second client device;
a broker non-transitory computer readable medium storing instructions executed by the processor of the broker computing device;
wherein the instructions of the first client non-transitory computer readable medium, the instructions of the second client non-transitory computer readable medium, and the instructions of the broker non-transitory computer readable medium cause the broker computing device, the first client computing device, and the second client computing device, respectively, to:
receive at the first client computing device a Key DNA and a Moniker;
store the Key DNA and the Moniker at the broker computing device;
generate at the first client computing device a Key based upon the Key DNA;
encrypt data stored on the first client computing device using the Key to generate Encrypted Data;
electronically transfer the Encrypted Data and the Moniker from the first client computing device to the second client computing device;
deliver, by the second client computing device, the Moniker to the broker computing device;
receive, by the first client computing device, the Key DNA from the broker computing device;
generate at the second client computing device the Key based upon the Key DNA; and
decrypt the Encrypted Data using the Key by the second client computing device.
3. The method of claim 2, further comprising:
following the step of
decrypting the Encrypted Data, removing the Key from the receiver client device.
3. The system of claim 2, wherein the instructions of the second client non-transitory computer readable medium further cause the second client computing device to:
remove the Key from the second client computing device after decrypting the Encrypted Data.
10. Claims 2-3 are rejected under judicially created doctrine of obviousness-type double patenting on the ground of non-statutory double patenting as being unpatentable over claims 1 and 3 of Patent No. 11/165,568 B2 (herein after referred as ‘568 patent)
Although the claims at issue are not identical, they are not patentably distinct from each other because they recite the same limitations and only differ by statutory category of invention. It would have been obvious to a person having ordinary skill in the art at the time the invention was made to have implemented the invention as any of a method, system or computer program product.
[Symbol font/0xB7] Independent claim 2 of the instant application and independent claim 1, of the ‘568 patent recite similar limitations. The above claims, namely 2 of the instant/present application, would have been obvious over claim 1, of the ‘568 patent, because every element of the above independent claim 2 of the present application is anticipated by the corresponding claim 1 of the ‘568 patent
[Symbol font/0xB7] dependent claim 3 of the instant application and dependent claim 3, of the ‘568 patent recite similar limitations. The above claims, namely 3 of the instant/present application, would have been obvious over claim 3, of the ‘568 patent, because every element of the above dependent claim 3 of the present application is anticipated by the corresponding claim 3 of the ‘568 patent
The following table maps at least each independent claim of the instant application with the corresponding claims of the ‘568 patent.
Instant application: application No. 19/240,310
US Patent No. ‘568 Patent.
2. A method of operating a receiver client device to enable a secure electronic data transfer from a sender client device, wherein the sender and receiver client devices each comprise a computing device, the method comprising:
electronically receiving Encrypted Data and a Moniker from a sender client device;
electronically delivering the Moniker to a broker device;
electronically receiving a Key DNA from the broker device in response to the step of delivering the Moniker;
generating a Key based upon the Key DNA; and
decrypting the Encrypted Data using the Key.
1. A method for enabling a secure electronic data transfer between a sender client device and a receiver client device, wherein the sender and receiver client devices each comprise a computing device, the method comprising:
receiving at the sender client device a Key DNA and a Moniker;
storing the Key DNA and the Moniker at a broker device;
generating at the sender client device a Key based upon the Key DNA;
encrypting data stored on the sender client device using the Key to generate Encrypted Data;
electronically transferring the Encrypted Data and the Moniker from the sender client device to the receiver client device;
delivering, by the receiver client device, the Moniker to the broker device;
receiving, by the receiver client device, the Key DNA from the broker device;
generating at the receiver client device the Key based upon the Key DNA; and
decrypting the Encrypted Data using the Key by the receiver client device.
3. The method of claim 2, further comprising:
following the step of decrypting the Encrypted Data, removing the Key from the receiver client device.
3. The method of claim 2, further comprising:
following the step of decrypting the Encrypted Data, removing the Key from the receiver client device
Claim Rejections - 35 USC § 102
11. 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)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale or otherwise available to the public before the effective filing date of the claimed invention.
12. Claims 2, 4-5, 8-9 are rejected under 35 U.S.C. 102 (a)(1) as being anticipated by Dimitrios Andivahis et al (Andivahis) (US Publication No. 2003/0147536 A1) (Pub. Date: August 7, 2003)
The following is referring to the independent claim 2:
As per independent claim 2, Andivahis discloses a method of operating a receiver client device to enable a secure electronic data transfer from a sender client device, wherein the sender and receiver client devices each comprise a computing device [Para. 0023, “senders and recipients are used by persons, who interact with software programs called mail user agents (MUAs) to compose and transmit Internet e-mail messages” Para. 0023 identifies the sender computer and recipient computer. Thus, sender and receivers are client programs operating on the respective computing devices], the method comprising:
electronically receiving Encrypted Data and a Moniker from a sender client device [para. 0060, “In step 652, the recipient 320 receives the composite message C2 and in step 654, ‘unpacks’ it into at least the encrypted message Me and the key retrieval information Kr” “the encrypted message Me” corresponds to the claim limitation, “Encrypted Data”. “The key retrieval information Kr” corresponds to the claim limitation, “Moniker” because it identifies the corresponding decryption key information maintained in the key server. See claim 1, “the sender receiving key retrieval information Kr which indexes the decryption key information” and “he recipient sending the key retrieval information Kr to the key server and receiving the decryption key information in response thereto”];
electronically delivering the Moniker to a broker device [Para 0062, “the recipient 320 sends and the key server/broker device, receives, a key fragment retrieval request 357. The key retrieval request preferably includes ….the key retrieval information Kr” The key server corresponds to the claim limitation “broker device” and the key retrieval information Kr is the “Moniker”];
electronically receiving a Key DNA from the broker device [Para. 0063, “n step 662, assuming the recipient's account is current and valid, the key server 340 retrieves the archived encrypted symmetric key Kse referenced by Kr, and sends a key retrieval response 358 back to the recipient 320. The key retrieval response …includes the message identifier, the encrypted symmetric key Kse. The encrypted symmetric key Kse corresponds to the claim limitation a “key DNA”], in response to the step of delivering the Moniker [Para. 0062, “Para 0062, “the recipient 320 sends and the key server/broker device, receives, a key fragment retrieval request 357. The key retrieval request preferably includes ….the key retrieval information Kr” The key server corresponds to the claim limitation “broker device” and the key retrieval information Kr is the “Moniker”];
generating a Key based upon the Key DNA [Para. 0064, “In step 664, the recipient 320, upon receiving Kse from the key server, then decrypts Kse using his own private decryption key Kd, to thereby produce symmetric key Ks”. Thus, the recipient generates a symmetric key Ks that corresponds to the claim limitation “key” based on receiving Kse/Key DNA]; and
decrypting the Encrypted Data using the Key [Para. 0065, “Finally, in step 666, the recipient may then use symmetric key Ks to decrypt the encrypted message Me sent by the sender].
The following is referring to the dependent claims 4-5 and 8-9:
As per dependent claim 4, Andivahis discloses a method as applied to claim 1 above. Furthermore, Andivahis discloses the method, wherein prior to the step of receiving Encrypted Data and a Moniker from a sender client device, the method further comprising:
installing a DASB client software program on the receiver client device, the DASB client software program comprising non-transitory computer readable medium instructions cause a processor of the receiver client device [Para. 0020, “executable software code comprising the key server, the sender and the recipient may each reside in the computer-readable memory of a general purpose, or other computer” and para. 0010-0116, teach delivering, downloading and installing from non-volatile storage media and installation as a plug-in. Para. 0115, “he client-side software may comprise a plug-in that cooperates with the user's existing e-mail system. The software installed may act as an extension to an existing Mail User Agent (MUA) or be a self-contained MUA; it may also be some software that can be used in conjunction with an MUA or a Web-based e-mail software” and para. 0116, “he process of installing the downloaded software on a user's computer results in a plugin module being installed within the user's MUA clients (for example, Microsoft Outlook, Qualcomm Eudora, and other similar programs) or Instant Messaging clients, as well as new settings being defined within the Operating System environment” and “Para. 0064, teaches the installed recipient functionality producing the symmetric key from the encrypted symmetric key received form the key server, thus requiring execution of executable software by the processor of the general-purpose computer] to generate an encryption key based upon received Key DNA [Para. 0064, “In step 664, the recipient 320, upon receiving Kse from the key server, then decrypts Kse using his own private decryption key Kd, to thereby produce symmetric key Ks”. Thus, the recipient generates a symmetric key Ks that corresponds to the claim limitation “key” based on receiving Kse/Key DNA]
As per dependent claim 5, Andivahis discloses a method as applied to claim 4 above. Furthermore, Andivahis discloses the method, wherein the DASB client software program is configured to interface with a software application operating on the receiver client device [para. 0115-0116, “The client-side software may comprise a plug-in that cooperates with the user's existing e-mail system. The software installed may act as an extension to an existing Mail User Agent (MUA) or be a self-contained MUA; it may also be some software that can be used in conjunction with an MUA or a Web-based e-mail software” and “The process of installing the downloaded software on a user's computer results in a plugin module being installed within the user's MUA clients (for example, Microsoft Outlook, Qualcomm Eudora, and other similar programs) or Instant Messaging clients, as well as new settings being defined within the Operating System environment. Depending on the user's choice, the software may install a self-sufficient MUA client or IM clients” This teaches the device access security broker client software interfacing with another software application operating on the receiver device]
As per dependent claim 8, Andivahis discloses a method as applied to claim 5 above. Furthermore, Andivahis discloses the method, wherein the step of receiving includes the software application [Para. 0058, teaches transmitting composite message using ordinary electronic-mail application functionality and para. 0060, teaches the recipient receiving and unpacking that composite message into the encrypted message and key retrieval information and para. 0015-0116 places the client software within or in cooperation with, the electronic mail application. Thus, the application receives the encrypted data and the Moniker] receiving the Encrypted Data and the Moniker [para. 0060, “In step 652, the recipient 320 receives the composite message C2 and in step 654, ‘unpacks’ it into at least the encrypted message Me and the key retrieval information Kr” “the encrypted message Me” corresponds to the claim limitation, “Encrypted Data”. “The key retrieval information Kr” corresponds to the claim limitation, “Moniker” because it identifies the corresponding decryption key information maintained in the key server. See claim 1, “the sender receiving key retrieval information Kr which indexes the decryption key information” and “he recipient sending the key retrieval information Kr to the key server and receiving the decryption key information in response thereto”]
As per dependent claim 9, Andivahis discloses a method as applied to claim 8 above. Furthermore, Andivahis discloses the method, further comprising invoking a decryption operation by the DASB client software program for the Encrypted Data received by the software application [Para. 0020, discloses that the recipient includes the client program. Para. 0064-0065, teach the recipient client functionality produces the key and decrypts the encrypted message. Para. 0118 confirms the client-side software can operate as an extension of the application used to view mail and can control decryption and display of the message and Para. 0065, “Finally, in step 666, the recipient may then use symmetric key Ks to decrypt the encrypted message Me sent by the sender].
Claim Rejections - 35 USC § 103
13. 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.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or non-obviousness.
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 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.
14. Claim 3 is rejected under 35 U.S.C. 103 as being unpatentable over Dimitrios Andivahis et al (Andivahis) (US Publication No. 20030147536 A1) (Pub. Date: August 7, 2003) in view of Erix Pizano (Pizano) ( US Publication No. 20080086646 A1, Publication Date: April 10, 2008)
As per dependent claim 3, Andivahis discloses a method as applied to claim 2 above. Further Andivahis discloses the method, further comprising: the step of decrypting the Encrypted Data [Para. 0065, “Finally, in step 666, the recipient may then use symmetric key Ks to decrypt the encrypted message Me sent by the sender].
Andivahis does not discloses “following the step of decrypting the Encrypted Data removing the Key from the receiver client device”
However, Pizano discloses: “following the step of decrypting the Encrypted Data removing the Key from the receiver client device” [Para. 0088, “The recipient client 38 also destroys the key after using the key to decrypt the encrypted transfer data”].
Andivahis and Pizano are analogous/in the same field of endeavor as they both are directed to a system providing secure data transfer.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to modify the decryption step of Andivahis by incorporating additional step such as “following the step of decrypting the Encrypted Data removing the Key from the receiver client device” as per teachings of Pizano to enhance the security of the system by reducing exposure of residual decryption keys in the system [Pizano para. 0088, “he recipient client 38 also destroys the key after using the key to decrypt the encrypted transfer data. While maintaining the key only on the key server 42 enhances security”]
15. Claims 6-7 and 10 is rejected under 35 U.S.C. 103 as being unpatentable over Dimitrios Andivahis et al (Andivahis) (US Publication No. 20030147536 A1) (Pub. Date: August 7, 2003) in view of Dustin C. Kirkland et al (Kirkland) ( US Publication No. 20160254913 A1, Publication Date: Sep 1, 2016)
As per dependent claim 6, Andivahis discloses a method as applied to claim 4 above. Further Andivahis discloses the method, further comprising: the step of receiving Encrypted Data and a Moniker from a sender client device [[para. 0060, “In step 652, the recipient 320 receives the composite message C2 and in step 654, ‘unpacks’ it into at least the encrypted message Me and the key retrieval information Kr” “the encrypted message Me” corresponds to the claim limitation, “Encrypted Data”. “The key retrieval information Kr” corresponds to the claim limitation, “Moniker” because it identifies the corresponding decryption key information maintained in the key server. See claim 1, “the sender receiving key retrieval information Kr which indexes the decryption key information” and “the recipient sending the key retrieval information Kr to the key server and receiving the decryption key information in response thereto”],
Furthermore Andivahis teaches downloading and installing client software and submitting the client’s public key and credentials to the key server during registration.
Andivahis does not however, expressly teach as registration of the client application itself with a corresponding server application. In other words, Andivahis does not disclose “the method further comprising: provisioning the DASB client software with software operating on the broker device ”
However, Kirkland discloses: “provisioning the DASB client software with software operating on the broker device ” [Para. 0048, “To register, the client application 200 performs a registration process 210 to send a registration request to the server application 240. The registration request can identify the client and include the client public key. Server application 240 stores the client's public key and assigns the client a unique client ID. According to one embodiment, each client application is identified by its public key and more particularly by a shorter hash of its public key (referred to as a “client fingerprint”). Next, the server application 240 sends the client application 200 the client ID and the server public key, which can be stored by client application 200 as Client ID 204 and server public key 206” See also para. 0047]
Andivahis and Kirkland are analogous/in the same field of endeavor as they both are directed to a system providing secure data transfer.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to modify the client software of Andivahis by incorporating additional step such as “provisioning the DASB client software with software operating on the broker device” as per teachings of Kirkland to enhance the security of the system by uniquely identifying client application and establishing an authorized client before releasing protected key information. [Kikland, para. 0048, “According to one embodiment, each client application is identified by its public key and more particularly by a shorter hash of its public key (referred to as a “client fingerprint”).]
As per dependent claim 7, the combination of Andivahis and Kikland discloses a method as applied to claim 6 above. Further Kikland discloses the method, wherein the step of provisioning includes establishing a unique Client ID for the DASB client software program as operated by the receiver client device. [Para. 0048, “The registration request can identify the client and include the client public key. Server application 240 stores the client's public key and assigns the client a unique client ID”]
As per dependent claim 10, Andivahis discloses a method as applied to claim 9 above. Further Andivahis discloses the method, wherein the step of electronically delivering the Moniker to a broker device [[Para 0062, “the recipient 320 sends and the key server/broker device, receives, a key fragment retrieval request 357. The key retrieval request preferably includes ….the key retrieval information Kr” The key server corresponds to the claim limitation “broker device” and the key retrieval information Kr is the “Moniker”];includes the DASB client software program operating receiver client device to deliver the Moniker and a client ID [Para. 0062 teaches that the recipient’s key retrieval request to the key server contains both the key retrieval information and recipient-identifying information Thus this teaches delivering the Moniker together with requester-identifying information]
Andivahis does not, however, expressly teach the requester identifier being unique to the particular client software instance.
In other words, Andivahis doesn’t explicitly teaches the following underlined claim limitation “the DASB client software program operating receiver client device to deliver the Moniker and a client ID unique to the DASB client software program as operated by the receiver client device”
However, Kirkland discloses the underlined claim limitation: “the DASB client software program operating receiver client device to deliver the Moniker and a client ID unique to the DASB client software program as operated by the receiver client device” [Para. 0048 and para. 0067, Para. 0048 assigns a unique identifier to the client application. Para. 0067 teaches that a request is signed by the client application and that the “signature can include the client ID” the server uses that information to verify the identity of the sending client application.]
Andivahis and Kirkland are analogous/in the same field of endeavor as they both are directed to a system providing secure data transfer.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to modify the client software of Andivahis by incorporating additional step such as “the DASB client software program operating receiver client device to deliver the Moniker and a client ID unique to the DASB client software program as operated by the receiver client device” as per teachings of Kirkland to enhance identification and authentication process thereby enhance the security of the system by binding each key-reference request to the registered client software instance. [Kikland, para. 0067, “the client application 240 can sign putDeposit, registerRequest and getDeposit requests with the client's private key 202 and encrypt the requests with the server's public key 206. According to one embodiment, the signature can include the client ID (e.g., fingerprint)]
Conclusion
18. The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
A. US Publication No. 20180063131A1 to Revell discloses a secure electronic data transfer system for use [Paragraph 0100, After the terminal 100 a is authenticated by the server 340 it is provided with key data necessary for establishing the secure communication with the second terminal 100 b] with a first client computing device [Figure 3, 100a] and a second client computing device [Figure 3, 100b], and a broker computing device [ Fig 3, 340, Server] each including a respective processor [Paragraph 0041, Examples of such a communication apparatus 100 are: a personal computer, desktop or laptop, an internet tablet, a mobile telephone, a smart phone, a personal digital assistant, a server, electronic key, machine-to-machine device (M2M) and a work station to name a few. See paragraph 0052, In FIG. 3 there are two terminals 100 a and 100 b, of which one is a desktop computer 100 a and the other is a smartphone 100 b. It should be noted that any terminal may be connected to the internet and the number and type of terminals 100 in FIG. 3 should not be construed as limiting.]
the system comprising:
Receive at the first client computing device a Key DNA [Paragraph 0146-0147, The server 340 then proceeds with generating 581 a first processing file PF1, which is returned 582 to the first terminal 100 a. The first terminal 100 a then extracts 583 a combined key data from the first processing file PF1. The combined key data included in file PF1 corresponds to the limitation “a Key DNA”] and a Moniker [Paragraph 0082, in FIG. 5, the server sets up an account for the terminal 100 by generating a random identification number, NodeID, 511 and a random encryption key, referenced Y, 512. The identification number, NodeID corresponds or meets the claim limitation “Moniker”]
generation at the first client computing device a Key based upon the key DNA [See paragraph 0145-0147 The first terminal 100 a then extracts 583 a combined key data from the first processing file PF1 and generates symmetric key based on combined key data as shown on figure 11, ref. 580];
encrypting data on the client computing device using the key to generate Encrypted data [Paragraph 0159, The symmetric encryption key is the result of the session setup and is to be used during the communication between the first terminal 100 a and the second terminal 100 b for encoding and decoding the communication];
electronically transfer the Encrypted Data from the first client computing device to the second client computing device [device [ See paragraph 0073 and 0159 where the generated symmetric key is used by the sender client device/ figure 3, 101a or figure 11, Terminal 1 and the receiver client device 101b or figure 2, Terminal 2 to encrypt and decrypt data and Paragraph 0147, The second terminal 100 b also sends a request 580 for generating a symmetric encryption key to the server 340 and the server 340 generates and sends 585 a second processing file PF2 to the second terminal 100b];
receive, by the first client computing device, the key DNA from the broker computing device [Paragraph 0146-0147, The server 340 then proceeds with generating 581 a first processing file PF1, which is returned 582 to the first terminal 100 a. The first terminal 100 a then extracts 583 a combined key data from the first processing file PF1. The combined key data included in file PF1 corresponds to the limitation “a Key DNA”
generate at the second client computing device the Key based upon the Key DNA [paragraph 0148, The second terminal 100 b then extracts 586 the combined key data from the second processing file PF2 and generates a second random key seed which is sent 587 to the first terminal 100 a. Both the first and the second terminals 100 then generates the symmetric encryption key, each on their own 588, 589].; and
decrypt encrypted data using the key by the second client computing device [ See paragraph 0073 and 0159 where the generated symmetric key is used by the sender client device/ figure 3, 101a or figure 11, Terminal 1 and the receiver client device 101b or figure 2, Terminal 2 to encrypt and decrypt data]
B. US Publication No. 20190020633 A1 to Leavy discloses A method, system, and non-transitory computer readable medium are described for providing a sender a plurality of ephemeral keys such that a sender and receiver can exchange encrypted communications. Accordingly, a sender may retrieve information, such as a public key and a key identifier, for the first receiver from a local storage. The retrieved information may be used to generate a key-encrypting key that is used to generate a random communication encryption key. The random communication encryption key is used to encrypt a communication, while the key-encrypting key encrypts the random communication key. The encrypted communication and the encrypted random communication key are transmitted to the first receiver.
C. US Publication No. 2019/0268420 A1 to Acharya discloses a system and method for an eSync bus protocol is provided. The eSync bus protocol uses a broker to route communications between electronic devices within an electronic environment, such as within a vehicle or the like. The electronic devices may first register with the broker, and thereafter send messages to the broker for routing to other registered electronic devices. In this way, the broker may as an intermediary to route communications using the eSync bus protocol. A multi-client architecture is also provided in which multiple domains may be defined by the functions performed by electronic devices within a respective domain.
D. US Publication No. 2015/0319151 A1 to Chastain discloses a device that incorporates the subject disclosure may perform, for example, receiving a derived encryption key from a remote management server without receiving a master key from which the derived encryption key was generated, applying a one-way function to the derived encryption key and a nonce to generate a temporary encryption key, obtaining data for transmission to a recipient device, encrypting the data using the temporary encryption key to generate encrypted data, and providing the encrypted data over a network to the recipient device.
E. See the other cited prior arts.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SAMSON B LEMMA whose telephone number is 571-272-3806. The examiner can normally be reached on M-F 8am-10pm.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Shaw Yin Chen can be reached on to 571-272-8878. 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.
/SAMSON B LEMMA/Primary Examiner, Art Unit 2498
Prosecution Insights