Specifications

Assumptions

Theme	Assumption
Summons	It is upto the Judge’s discretion on which channels to use for summons for each time a summons is issued.
Summon Delivery	The correct contact details of the person to be summoned in present in the system
	In case summons are reissued by the court, payment of summon fees will be made again
	Each summon channel will contain atleast 1 payment i.e court fees and may contain a channel specific payment.
Warrant	No payment needs to be collected for Warrants

Configure Channels

1. Summons can be issued against multiple channels. Examples of these include SMS, Email, Post, Police etc. Channels for Summons can be configured at a tenant level.

2. Warrants may be issued against multiple channels. Currently, as per practice, only the police has the authority to execute warrants. Channels for Warrants will be configured at the tenant level. If only one channel i.e Police is updated, this will be auto-selected on the issuance of Warrant

3. For every channel, a minimum number of days for delivery can be configured by the admin.

Workflow for Summons

The overall summons lifecycle will be defined at 45 days (Configurable) from the date of issuance of an order. This will be a combination of all summons issued as part of 1 order.

1. Summons may be triggered at any point in the case lifecycle.

2. The workflow will start with the issuance of an order for summons. Summons may be issued to multiple parties at various processes of the case lifecycle:

   1. Parties to whom summons might be issued:

      1. Respondents

      2. Witness

3. The judge will issue an order for issuance of summons to a party. (Details of Order generation are mentioned here).

4. For the purpose of the product, a Summon will be a unique combination of 1 recipient, 1 address and 1 channel.

   1. Ex: A judge publishes an order to send a summons to a respondent via post and SMS. If the respondent has two associated physical addresses and one phone number, three summons are sent–one to each of the addresses via post and one via SMS.

   2. An order for Summons/Notice will contain the following information.

      1. The party who needs to appear in court

      2. Channels using which Summon/Notice has to be sent: All channels will be selected by default in the UI and the judge can deselect channels.

      3. Address to which summon is to be sent. If only 1 address exists, it will be auto selected

   3. Issue of order for summons can be done for 1 recipient at 1 time. Hence is summons needs to be sent out to 2 recipients, and 2 orders need to be generated.

   4. Prior to issuing/reissuing an order for summons, a hearing date will need to be scheduled by the judge which gets printed on the summon document. In case the hearing date for the warrant is before the end of the warrant lifecycle, a trigger to reschedule the hearing will be displayed to the judge.

   5. On the generation of an order, a pending task for payment will be triggered for the petitioner’s advocate (or petitioner, if PiP), if the channels selected have payment associated with them. For each channel, address, and respondent combination - a separate pending task will be generated for payment

   6. A pending task for signing the summons document will also be triggered for the court clerk following the issuing of the order by the judge. For each channel, address, and respondent combination - a separate pending task will be generated for signing the document.

   7. Once both the payment is completed and the document is signed, the summon is sent out (either automatically via integrations or manually updated via the summon tracking portal)

   8. If for any 1 one summon, a status of non-delivery is received, a notification will be sent to all parties and a pending task will be created for the judge. The judge can either choose to re-issue summons, issue a warrant or take no action. The bench clerk will also view this pending task and may draft an order based on the judge. However, it is required that the judge sign it

   9. If no action is taken, summons delivery is monitored over the 45-day cycle. If by the end of 45 days, no summon statuses are updated as delivered, then the judge will be notified via a pending task again and the judge can either choose to re-issue summons, issue a warrant or take no action. An order to reissue summons will retrigger the entire workflow. An order to issue warrants will trigger the warrants workflow.

Payment for Summons

1. As part of the process flow for Summons, the petitioner/advocate is required to pay a standard fee.

   1. For each channel, standard court fees will apply.

   2. For each channel, channel-specific fees may apply as well.

   3. In case both court fees and channel-specific fees apply to a channel, then payment will be considered completed only if both payments are made

   4. Channel-specific fees will be tracked online only if online payment for these fees is applicable. In case it is not, the payment will have to be manually tracked.

   5. For court fees, the litigant/advocate can make payment through the following:

      1. Pay at the counter in Court: To enable this, a screen for recording collection will be made available to the collector where the collector can record the mode of payment.

      2. Make an Online Payment: This can be enabled via different types of integrations, ex. With an e-Treasury department via APIs.

   6. For any channel for which payments are not completed, payments should no longer be valid if the number of days for summon delivery for the channel>days remaining in the summon lifecycle.

Workflow for Notices

1. Notices may be triggered at any point in the case lifecycle.

2. Notices start with the judge clicking on the Issue Notice option.

3. The judge drafts the notice and issues it.

4. Court staff looks at the list of notices created and their status. They manually send out the notice created by the judge.

5. Court staff manually monitors the status of the notice and updates the system with any change.

Workflow for Warrants

The overall warrant lifecycle will be defined at 45 days (Configurable) from the date of issuance of an order. Warrants may be triggered at any point in the case lifecycle.

1. The warrant workflow will be triggered by the issuance of an order for Warrant

2. Prior to issuing/reissuing an order for the warrant, a hearing date will need to be scheduled by the judge which gets printed on the summon document. In case the hearing date for the warrant is before the end of the warrant lifecycle, a trigger to reschedule the hearing will be displayed to the judge.

3. As per the current process, no payment for the warrant is required.

4. On issuance of an order, a pending task will be triggered to the CMO for signing the warrant document.

5. Once the order is issued, integration with the warrants system will receive the trigger for summons who will send the warrant and update the status of delivery

6. If non delivered/no status update post the warrant lifecycle, a pending action will be triggered to the judge for reissue of summons/warrant.

Responding to digital summons:

1. On receiving a summons via SMS/email, the respondent can click on the link, register, and use the Join a Case workflow to get added to the case. The respondent may confirm receipt of summons and request reschedule of hearing, if required.

2. The respondent can also share the summons with an advocate, who will use the Join a Case workflow to get added to the case.

3. The respondent or the advocate can then enter the summons ID to acknowledge receipt of the summons and confirm their attendance at the hearing.

Tracking Summon/Warrant/Notice delivery and Delivery Status update

1. A portal will be available to track the status of summon/warrant/notice delivery

2. The courtroom staff can use the portal to track the status of all summons/warrants/notices in progress.

3. For summon/warrant/notice channels where no API integration is available, the portal call be used to update the status. Delivery channels include SMS, Whatsapp, Email, Traditional post, ePost, Police system integrations, etc.

4. A dedicated dashboard will track the number of adjournments of hearings, mark the missed hearings by litigants and record the reasons for absences or requests for adjournment or extensions. The same dashboard would allow judges to track the status of summons and other critical aspects, tailored to each stage of the case. This dashboard can be accessed by the judges through their login portal.

Bail Workflow

The bail workflow is used in cases of defendants in custody who can appeal to the court for release on the provision of certain securities as mandated by the judge.

1. The bail workflow begins with the filing of a bail application by the advocate (or PiP/Party in Person). This follows the generic application process. (Application types = Application for Bail Bond or Application for Surety)

2. Once the application has been filed, a pending task is created for the Judge. The judge can review the application and either grant or reject the application.

3. If a judge grants the bail application, an order for bail is generated.

4. If the bail type is a surety bond or a bail bond, then no further action is required by any parties.

QR Code for Summon and Warrant Documents

1. Each summon/warrant document will contain a unique QR Code. On scanning the QR code, the user will be redirected to the portal where the summon document will be visible. This will serve as a verifiable credentials to verify authenticity of documents for the user.

Ideas for Future Development

1. The petitioner/petitioner advocate will be notified of the non-delivery of the summons. In case additional contact details are to be provided, a separate application will have to be raised by the petitioner’s advocate and approved by the judge. The approval of this application will be in parallel to the reissue summons workflow and will run independently.

2. Dashboard for litigants and lawyers similar to the judge dashboard to keep track of the summons, extensions, adjournments etc., The existing dashboards for advocates and litigants in v1 are information portals, with no analytics being carried out

3. Automatic re-issuance of Warrants

4. Automated Issuance of Summons/Notices to personnel outside the Parties and Witnesses registered in a case

5. UI configuration for the update of pricing of summons for the System Admin

6. Ability to escalate to Judge in case the wrong document is provided for Bail

7. Specific channels for Round 1 and Round 2 of summons. Currently, all channels will be available for all rounds, and the judge can select the relevant channels

8. Grouping of channels as per summons escalation process defined

9. Refund of Bail

10. Sending summons to non-respondents

11. Process flow for payment of cash against bail

12. Ability to dismiss pending task action for the judge

13. Payments for warrants/notices